I am not sure where to put the code for both APIs.
> Adding another device under cpu seems like an overkill.
These can be exported as a common interface from cpufreq
(dev,cpu.X.perf_stats) and supplied by the child acpi_perf driver on
each cpu.
--
Nate
__
that indicates if Px states are global
or not. If global, you can still attach a cpufreq device to each cpu but
make changing any of their settings loop through changing all cpu
settings equally. This is how it currently works. If the flag is false,
then only apply a setting to the device it was re
This seems silly. The whole point of APIC is to avoid clustering on a
single interrupt but the BIOS put the timer on the USB controller irq?
>> It's time to implement powertop for freebsd, isn't it?
>
> Surely it is. I was even thinking about possibili
gt; cpu3: on acpi0
> PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6
> PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not
> available.
> PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245
> latency
I thi
d to execute the _REG methods. This
fixed some interdependencies across _REG methods found on some machines.
---
You might be able to work around this problem by setting:
debug.acpi.disable="ec"
or
debug.acpi.avoid="\_SB_.PCI0.SBRG"
-Nate
__
On Wed, 3 Dec 2003, Melvyn Sopacua wrote:
> On Tuesday 02 December 2003 23:34, Nate Lawson wrote:
> > Try other states (acpiconf -s 1, 2, 4). If one works, use it. If not,
> > try disabling acpi and using apm(4) to suspend and resume.
>
> Normally that would be grand,
Try other states (acpiconf -s 1, 2, 4). If one works, use it. If not,
try disabling acpi and using apm(4) to suspend and resume.
Suspend/resume is far down my list of things to troubleshoot and most of
the problems are very hw-specific.
-Nate
dmesg, please, including error.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Tue, 2 Dec 2003, Lukas Ertl wrote:
> On Tue, 2 Dec 2003, Nate Lawson wrote:
> > Um, you have no _ACx values so the fan will be controlled by the BIOS. We
> > should probably provide a way for users to supply their own _ACx values if
> > they're not happy with the BI
On Wed, 26 Nov 2003, Lukas Ertl wrote:
> On Wed, 26 Nov 2003, Nate Lawson wrote:
> > I need the output of sysctl hw.acpi.thermal to see your _ACx values.
>
> hw.acpi.thermal.tz0.temperature: 3072
> hw.acpi.thermal.tz0.active: -1
> hw.acpi.thermal.tz0.thermal_flags: 0
>
On Tue, 25 Nov 2003, John Polstra wrote:
> On 24-Nov-2003 Nate Lawson wrote:
> >
> > Please also send the output of acpidump -t -d > jdp-P2.asl
>
> I booted the 5.1R live CD in an attempt to get this output. I
> discovered that the machine hangs the same way with 5.1R
On Mon, 1 Dec 2003, Slawa Olhovchenkov wrote:
> On Mon, Dec 01, 2003 at 09:48:40AM -0800, Nate Lawson wrote:
> > Your ASL indicates that it returns different values for present (based on
> > PS2F) and current resources (based on KBDI). Please send me the URL to
> > the full
Your ASL indicates that it returns different values for present (based on
PS2F) and current resources (based on KBDI). Please send me the URL to
the full ASL so I can see what sets those two variables.
-Nate
___
[EMAIL PROTECTED] mailing list
http
On Wed, 26 Nov 2003, Lukas Ertl wrote:
> On Wed, 26 Nov 2003, Nate Lawson wrote:
> > It's possible the fan is under BIOS control so make sure you have an
> > up-to-date bios. If not, you should get a console printout when acpi
> > switches the fan on. sysctl hw.acpi
On Fri, 21 Nov 2003, Lukas Ertl wrote:
> On Fri, 21 Nov 2003, Nate Lawson wrote:
> > > > On Tue, 18 Nov 2003, Lukas Ertl wrote:
> > > > > I'm gonna try some "buildkernelstones" with the different settings. If
> > > > > you h
This should be completely resolved by the commit I just made. Please
test.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
I believe this completes the changes to acpi_cpu for 5.2. Please test on
SMP boxes and laptops and if you were disabling it before, please
re-enable it to test. (To do that, remove debug.acpi.disable from
loader.conf).
Thanks,
Nate
-- Forwarded message --
Date: Wed, 26 Nov 2003
On Tue, 25 Nov 2003, Marco Wertejuk wrote:
> | Of course, make sure you don't have local changes in /etc/rc.d first.
>
> Shouldn't these be placed in /usr/local/etc/rc.d
Sure. I was just being overly careful since I just suggested someone
rm -rf
acpidump -t -d > brooks-Intel.asl
Also, build with options ACPI_DEBUG and set these in your loader.conf:
debug.acpi.layer="ACPI_ALL_COMPONENTS"
debug.acpi.level="ACPI_LV_OPREGION"
-Nate
___
[EMAIL PROTECTED] mailing lis
On Tue, 25 Nov 2003, it was written:
> On Tuesday 25 November 2003 18:35, Nate Lawson wrote:
> > With a recent -current, I've noticed double prints for the last few
> > rc scripts, like this:
> >
> > Starting cron.
> > Local package initializat
With a recent -current, I've noticed double prints for the last few rc
scripts, like this:
Starting cron.
Local package initialization:.
Local package initialization:.
Additional TCP options:.
Additional TCP options:.
Anyone else seeing this?
On Mon, 24 Nov 2003, John Polstra wrote:
> On 24-Nov-2003 Nate Lawson wrote:
> >
> > Trace 1:
> > wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4
> > AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8
> > AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb
On Mon, 24 Nov 2003, John Polstra wrote:
> On 24-Nov-2003 Nate Lawson wrote:
> >
> > Please also send the output of acpidump -t -d > jdp-P2.asl
>
> When I try to run that command, I get:
>
> acpidump: sysctl machdep.acpi_root does not point to RSDP
>
On Mon, 24 Nov 2003, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, John Polstra writes:
> >On 24-Nov-2003 Nate Lawson wrote:
> >> It's a long shot, but what about setting kern.timecounter.hardware to
> >> i8254. It appears your ACPI timer
q
> device_probe_and_attach: fwohci0 attach returned 6
>>>>>> This one loses firewire
The problem is that your _PRS values are incorrect. Actually, I think jhb
committed some code to deal with extended irq resources. Send me the
output of acpidump -t
On Mon, 24 Nov 2003, John Polstra wrote:
> On 24-Nov-2003 Nate Lawson wrote:
> > Please add debug.acpi.disable="cpu" to loader.conf or type that in at the
> > loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup
> > path.
>
> Thanks. I
On Mon, 24 Nov 2003, John Polstra wrote:
> On 24-Nov-2003 Nate Lawson wrote:
> > Please add debug.acpi.disable="cpu" to loader.conf or type that in at the
> > loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup
> > path.
>
> Thanks. I
No way! Good (non-386) equipment is never to old. :)
Please add debug.acpi.disable="cpu" to loader.conf or type that in at the
loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup
path.
-Nate
___
[EMAIL PROTECTED] ma
On Sat, 22 Nov 2003, Lukas Ertl wrote:
> On Fri, 21 Nov 2003, Nate Lawson wrote:
>
> > Those are what is more interesting. Also, can you send me your sysctl
> > hw.acpi.cpu.cx_history after you've used it for a while with the maximum
> > cx_lowest setting?
>
>
on acpi0
> device_probe_and_attach: acpi_cpu1 attach returned 6
> acpi_button0: on acpi0
Yes, the code in cvs should not panic but I see your CPUs still do fail to
probe. I'll look into addressing that.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
x06, 0x0410, 0x06) {}
Processor (CPU4, 0x07, 0x0410, 0x06) {}
}
So all the ACPI CPU ids don't match between the MADT and the Processor
object. I'm not sure what to do to solve this.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tc for 0
> cpuid = 0;
> Debugger("panic")
> Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
> db> x/xl cpu_softc
> cpu_softc: 0
> db> x/xl cpu_softc+4
> cpu_softc+0x4: c68e8a00
> db> x/xl cpu_softc+8
> cpu_softc+0x8: 0
> db>
Ok, please
loss for IO latency benchmarks.
Those are what is more interesting. Also, can you send me your sysctl
hw.acpi.cpu.cx_history after you've used it for a while with the maximum
cx_lowest setting?
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sorry to reply to myself. Are you loading acpi as a module and have an
SMP box? If so, please try this patch, recompile the module, and go
again:
retrieving revision 1.32
diff -u -r1.32 Makefile
--- Makefile15 Nov 2003 19:26:06 - 1.32
+++ Makefile21 Nov 2003 21:37:41 -
@@ -4
Is this an SMP box? If so, please do:
x/xl cpu_softc
x/xl cpu_softc+4
x/xl cpu_softc+8
And send me the output of
acpidump -t -d > tiamat-MachineType.asl
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/free
Since both of these happen in irq handlers, you might want to look at the
new random entropy gathering use of locking.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
title FreeBSD
root (hd0,3,a)
kernel /boot/loader
title Linux
kernel (hd0,4)/boot/vmlinuz root=/dev/hda5
Thanks,
Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Wed, 19 Nov 2003, Eric Anderson wrote:
> Nate Lawson wrote:
> >You should run a benchmark with different values for
> >hw.acpi.cpu.current_speed to be sure the throttling control still works
> >ok. I left it mostly intact so you shouldn't see any problems but it&#x
On Wed, 19 Nov 2003, Harald Schmalzbauer wrote:
> On Wednesday 19 November 2003 16:31, Nate Lawson wrote:
> > Ok, here's the final patch. I believe it fixes both problems.
> >
> *SCHNIP*
>
> Yep, seems really final. I downloaded the acpi_cpi.c from cvs-web to be sure
On Wed, 19 Nov 2003, Robert Watson wrote:
> On Wed, 19 Nov 2003, Nate Lawson wrote:
> > On Wed, 19 Nov 2003, Robert Watson wrote:
> > > Success! The system rebooted without panicking. It even came back up
> > > cleanly. :-)
> >
> > Good to hear. I thin
On Wed, 19 Nov 2003, Robert Watson wrote:
> On Wed, 19 Nov 2003, Nate Lawson wrote:
>
> > Ok, here's the final patch. I believe it fixes both problems.
>
> Success! The system rebooted without panicking. It even came back up
> cleanly. :-)
Good to hear. I think D
port. Add disabled code to write the CST_CNT. It will be
enabled once _CST re-evaluation is tested (post 5.2R).
Thank you: dfr, imp, jhb, marcel, peter
-Nate
Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/
On Tue, 18 Nov 2003, Eric Anderson wrote:
> Nate Lawson wrote:
> >cvsup to -current as of today would be a good first start. The code was
> >committed Nov 15. Then boot with acpi enabled and post the output of
> >sysctl hw.acpi.cpu. You can try different l
tl hw.acpi.cpu. You can try different levels by doing sysctl
hw.acpi.cpu.cx_lowest=x where x is 0...(number_supported_states - 1)
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Tue, 18 Nov 2003, Don Lewis wrote:
> On 18 Nov, Lukas Ertl wrote:
> > On Tue, 18 Nov 2003, Nate Lawson wrote:
>
> >> This excerpt from truckman@'s asl shows that 4 Cx states are only
> >> available when the AC adapter is not attached. (The C*NA memory address
On Tue, 18 Nov 2003, Robert Watson wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
> > Could you add a printf to the start of acpi_cpu_detach()? I want to see
> > if we're being called before or after ACPI is stopped ("Shutting down
>
> So indeed, it doesn'
On Tue, 18 Nov 2003, Lukas Ertl wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
> > Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is
> > available). I'm interested in any benchmark results, especially IO. I'm
> > hoping the scheduling of sleep
On Tue, 18 Nov 2003, Robert Watson wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
>
> > Below you'll find the update patch for acpi_cpu. Please test this,
> > especially for SMP and laptops with _CST objects in their ASL.
> ...
> > Notes:
> > * Add
On Tue, 18 Nov 2003, Lukas Ertl wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
> > Below you'll find the update patch for acpi_cpu. Please test this,
> > especially for SMP and laptops with _CST objects in their ASL.
>
> Looks good here on a Centrino based laptop,
%eax,0(%edx)
> db> tr
> intr_execute_handlers(c06d5084,d763ac9c,d763ace0,c065bbae,7) at
> intr_execute_handlers+0x23
> atpic_handle_intr(7) at atpic_handle_intr+0x42
> Xatpic_intr7() at Xatpic_intr7+0x1e
> --- interrupt, eip = 0xc064d655, esp = 0xd763ace0, ebp = 0xd763ace0 ---
This i
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
Thanks,
Nate
Notes:
* Add a detach method that disables entry to acpi_cpu_idle and in the SMP
case, IPIs all processors to exit sleeping. This fixes a pan
Thanks for the info. His analysis is correct. I'll add a detach method
that disables sleeping during shutdown.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to &q
On Mon, 17 Nov 2003, Harald Schmalzbauer wrote:
> On Sunday 16 November 2003 21:11, Nate Lawson wrote:
> > The panic you see is a result of the new acpi_cpu driver, not ULE. In any
> > case, it appears that acpi_cpu_idle is being called and trying to read one
> > of
On Sun, 16 Nov 2003, Lukas Ertl wrote:
> On Sat, 15 Nov 2003, Nate Lawson wrote:
>
> > Please test this to be sure that it boots ok on your machine, especially
> > SMP boxes. Throttling should still work ok also.
>
> Seems to work here:
>
> hw.acpi.cpu.cx_sup
As a workaround, please set this in loader.conf:
debug.acpi.disable="cpu"
That will allow you to get running and give me some time to look into
this.
Thanks,
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/lis
also add more
latency so you will probably see some decrease in IO benchmarks if you
enable them.
Please test this to be sure that it boots ok on your machine, especially
SMP boxes. Throttling should still work ok also.
Thanks,
Nate
-- Forwarded message --
Date: Sat, 15 Nov 2003
On Thu, 30 Oct 2003, Jeremy Bingham wrote:
> On 29/10/03 18:18 -0800, Nate Lawson wrote:
> > I looked at a few other ASL copies I have and you have an old version.
> > Have you done a BIOS update recently?
> >
> > Yours: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x
On Wed, 1 Oct 2003, Jeremy Bingham wrote:
> > > On 30/09/03 15:04 -0700, Nate Lawson wrote:
> > > > As far as debugging prints, add the following printfs to
> > > > acpi_cmbat_get_bif():
> > > >
> > > > printf("Before gettin
On Mon, 27 Oct 2003, Thorsten Greiner wrote:
> * Nate Lawson <[EMAIL PROTECTED]> [2003-10-27 22:13]:
> > ... What you probably want to do now is do "tr " for the
> > pids below to see what they're blocked on. Likely culprits are 24
> > (since it
On Fri, 24 Oct 2003, Thorsten Greiner wrote:
> * Nate Lawson <[EMAIL PROTECTED]> [2003-10-24 22:57]:
> > Type "tr" at the DDB prompt to get a trace of what is hanging.
>
> At the time of the hang a 'ps' in DDB shows two screenful's of
> processes
-sections -Wno-deprecated -c
/home/src/contrib/libstdc++/libsupc++/tinfo.cc -o tinfo.po cc1plus:
warning: -ffunction-sections disabled; it makes profiling impossible
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo
On Fri, 10 Oct 2003, Soren Schmidt wrote:
> It seems Nate Lawson wrote:
> > Here is an updated status of ATAng for me. I periodically test it to see
> > if any of the following problems go away.
> >
> > * Panic occurs after ATAFD fails to probe. Last event: 2003/10/6
dl_opened,
so a staticially linked modern JVM can't realistically be created.
The last time we were able to create a static JVM was JDK1.1. I spent
many weeks attempting to create one for 1.2, and finally gave up.
Nate
___
[EMAIL PROTECTED] mailing list
htt
Error: Method execution failed [\\_SB_.C0D7] (Node 0xc18a6ae0),
AE_NO_MEMORY
ACPI-1287: *** Error: Method execution failed [\\_GPE._L00] (Node 0xc18ab640),
AE_NO_MEMORY
ACPI-0388: *** Error: AE_NO_MEMORY while evaluating method [_L00] for
GPE[ 0]
Have you a
break into DDB but nothing
> else...
Type "tr" at the DDB prompt to get a trace of what is hanging.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
y. Try some of the hints on this page:
http://www.cpqlinux.com/acpi-howto.html
Please also post a link to your ASL, produced by:
acpidump -t -d > fujitsu.asl
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/fre
ure
> on with ACPI disabled and there was no reboot.
How were you able to test that with it disabled? Were you suspending with
apm instead?
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Mon, 13 Oct 2003, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Nate Lawson <[EMAIL PROTECTED]> writes:
> : Given that, my biggest concern now is IO corruption. Are there any
> : devices that have a low interrupt rate (or bus mastering rate) that
On Sun, 12 Oct 2003, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Nate Lawson <[EMAIL PROTECTED]> writes:
> : I am very interested in our idle load characteristics. It seems
> : most systems I've analyzed have an average idle interrupt rat
On Mon, 13 Oct 2003, Mark Santcroos wrote:
> On Mon, Sep 15, 2003 at 02:16:47PM -0700, Nate Lawson wrote:
> > njl 2003/09/15 14:16:47 PDT
> >
> > FreeBSD src repository
> >
> > Modified files:
> > sys/dev/sound/pciich.c
> > Log:
lers. But I also need to be able to demote
quickly to short sleep states (e.g., HLT) if the system is becoming active
to decrease response times.
Thanks for any info,
Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freeb
ting about loosing an interrupt. I'll try to
get more info.
Device is Intel 82801CA/CAM ICH3 ATA100 controller. There are no slave
devices, just one master hard drive on primary and one master DVD/CDRW on
secondary.
-Nate
___
[EMAIL PROTECTED] ma
On Mon, 6 Oct 2003, Bruce Evans wrote:
> On Sun, 5 Oct 2003, Nate Lawson wrote:
> > In the past, msdosfs has taken its permissions from the mountpoint.
> > Recently I noticed that this still works for files in the root directory
> > but subdirectories are all chmod 000. Has
(i.e. command.com) but not subdirectories, which are still 000.
What's going on?
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
o help resolve this?
First, please don't hijack another thread. I've started another one for
this.
sysctl hw.acpi should show you what the power button event generates. It
should be set to S5. What does yours say?
-Nate
___
[EMAIL PROTE
On Wed, 1 Oct 2003, Jeremy Bingham wrote:
> On 01/10/03 09:33 -0700, Nate Lawson wrote:
> > > > As far as debugging prints, add the following printfs to
> > > > acpi_cmbat_get_bif():
> > > >
> > > > printf("Before getting BIF\
On Wed, 1 Oct 2003, Bruce Evans wrote:
> On Tue, 30 Sep 2003, Nate Lawson wrote:
> > Here are "iostat 5" results for my USB thumb drive on a uhci(4) controller
> > with 5.1-CURRENT. On windows on the same box, it runs reasonably quickly.
> > On FreeBSD, it real
On Wed, 1 Oct 2003, Jeremy Bingham wrote:
> On 30/09/03 15:04 -0700, Nate Lawson wrote:
> > Are you sure you tracked it down to INVARIANTS? Or was it DDB? Please
> > try with _just_ DDB and see if you can still reproduce the problem. If
> > so, then when it hangs, hit CTRL
.04
1.00 41 0.04
1.02 41 0.04
Is there something we're doing on uhci(4) that makes each transfer only
1 KB? If we upped it to 32 KB, it would be a more reasonable 1.2 MB/sec
which is still well under the USB 1.1 max speed.
Thanks,
-Nate
___
[
On Tue, 30 Sep 2003, Jeremy Bingham wrote:
> On 30/09/03 14:48 -0700, Nate Lawson wrote:
> > Please do not start new threads for the same problem as it makes it hard
> > to track down what your problem even was originally. I assume your
> > problem is hangs during boot, i
On Tue, 23 Sep 2003, Jeremy Bingham wrote:
> On 23/09/03 18:07 -0700, Nate Lawson wrote:
> > Enable options DDB. When it hangs, press CTRL-ALT-ESC and then "tr" to
> > get a traceback.
> >
> > While ACPI influences this problem, I am uncertain it is the root
Please do not start new threads for the same problem as it makes it hard
to track down what your problem even was originally. I assume your
problem is hangs during boot, it appeared since 5.1R, and it goes away if
you enable "options INVARIANTS". Is that rig
On Mon, 29 Sep 2003, Kevin Oberman wrote:
> > Date: Mon, 29 Sep 2003 13:33:06 -0700 (PDT)
> > From: Nate Lawson <[EMAIL PROTECTED]>
> > ACPI attaches the bus twice. See sys/dev/acpica/acpi.c:
> >
> > /*
> > * Scan all of the child devices
T((ACPI_DB_OBJECTS, "first bus_generic_attach\n"));
bus_generic_attach(bus);
/*
* Some of these children may have attached others as part of their attach
* process (eg. the root PCI bus driver), so rescan.
*/
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "second bus_gen
e wrong
> rate, about 52K instead of the correct 48,000.
>
> There is nothing in the tying it to any PR, but it looks like it's
> trying to do the "right thing" on resume.
>
> As before, the sysctl for the sampling rate has no effect.
>
> Any idea
; > for months before ATAng. I am running -current without ATAng with no
> > problems.
> >
> > -Nate
>
> Herm. I checked out a copy of the sys tree from 8/23, copied the files
> from sys/dev/ata over (after deleting the current ones), made the
> changes in sys/conf/f
On Thu, 25 Sep 2003, Jeremy Bingham wrote:
> On 25/09/03 11:54 -0700, Nate Lawson wrote:
> > Interesting. Try turning on ACPI_LV_FUNCTIONS (see the email I just sent
> > to -current) as well as ACPI_DEBUG and let me know the last 3-4 prints
> > before it hangs. Not blaming a
it hangs. Not blaming anyone here, but could you also try without
ATAng? I am unable to use ATAng on my laptop.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7;ll get spammed with way too many messages on boot but just ignore
these. Then do shutdown -p and log the printed messages (hopefully you
have a serial console).
I'll map the debugging tunables to a sysctl since it would be better if
you could just set this just before testing rather than fo
d off or in "Safe Mode", the computer
>boots normally.
Enable options DDB. When it hangs, press CTRL-ALT-ESC and then "tr" to
get a traceback.
While ACPI influences this problem, I am uncertain it is the root cause.
-Nate
___
[EM
gt; c
>
I'll have to look at your acpidump to have a guess. It could be that
running the _PTS method causes your laptop to enter suspend the second
time due to an improperly resumed device from the first suspend.
acpidump -t -d > andy.asl
-Nate
__
On Wed, 17 Sep 2003, Andrew Thompson wrote:
> Nate Lawson wrote:
> > On Wed, 17 Sep 2003, Andrew Thompson wrote:
> >
> >>111 sc_cur_scr = sc->cur_scp->index;
> >
> > For a temporary workaround, try changing line 111 to:
> >
st a short heads-up. I have been focusing attention on fixing panics
first and will eventually get around to other problem reports. I have
been logging reports but not working on them.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailm
On Mon, 8 Sep 2003, Soren Schmidt wrote:
> It seems Nate Lawson wrote:
> > With a fresh checkout of last night's -current, I cannot boot my laptop.
> > ATAFD panics the box by reusing freed memory. I do not have a floppy
> > drive in the laptop and when I do, it&#x
On Tue, 16 Sep 2003, Damian Gerow wrote:
> Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 16:24]:
> > I have no time to track this down but the output of acpidump -t may help
> > someone else who might be interested. You're looking for the pointers
> > that are
On Tue, 16 Sep 2003, Damian Gerow wrote:
> Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 15:00]:
> > I'm almost certain your problem is defining MAXMEM to 512 MB. Remove that
> > from your kernel config and try again. MAXMEM causes all kinds of
> > problems.
t; 110 sc = &main_softc;
> 111 sc_cur_scr = sc->cur_scp->index;
> 112
> 113 if (sc_no_suspend_vtswitch)
> 114 return (0);
> 115
For a temporary workaround, try changing line 111 to:
if (sc->cur_scp == NULL)
ret
On Wed, 17 Sep 2003, Andrew Thompson wrote:
> Nate Lawson wrote:
> >gdb kernel.debug
> >l *scsuspend+0x17
> >That should show the offending code segment.
>
> (gdb) l *scsuspend+0x17
> 0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111).
> 106
'm almost certain your problem is defining MAXMEM to 512 MB. Remove that
from your kernel config and try again. MAXMEM causes all kinds of
problems. If this doesn't solve it, start with the stock GENERIC and add
back in your custom kernel options until it fails. The last option you
ad
Please compile your kernel with debug symbols (config -g KERNEL) and load
it into gdb to get the actual line of code that is getting that NULL
deref:
gdb kernel.debug
l *scsuspend+0x17
That should show the offending code segment.
-Nate
1 - 100 of 662 matches
Mail list logo
