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 as it does
with -current. (When I
On 23-Nov-2003 John Polstra wrote:
I have an old dual PII/400 system that I'm trying to set up as a
-current scratchbox. The motherboard is a Tyan S1836DLUAN with the
Intel 440BX chipset. I upgraded the BIOS to the latest from Tyan's
web site. It is supposed to support ACPI. I'm using
Nate Lawson writes:
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.
Speaking of which, I have a Good (see above...) motherboard
On 29-Nov-2003 George Hartzell wrote:
Speaking of which, I have a Good (see above...) motherboard looking
for a worthy home.
There's an alias [EMAIL PROTECTED] just for such offers. :-)
John
___
[EMAIL PROTECTED] mailing list
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 as it does
with -current. (When I originally installed 5.1R, the machine had
an
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. It still hangs even with debug.acpi.disable=cpu. I have
attached the verbose boot messages. They
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. It still hangs even with debug.acpi.disable=cpu. 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. It still hangs even with debug.acpi.disable=cpu. I
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
The sysctl command shows that machdep.acpi_root is 0.
Remember, though, in order to boot it I had to
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 is bad. The reason why I suggest this
is that it seems like interrupts are being lost.
I put kern.timecounter.hardware=i8254 into /boot/loader.conf, but
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 is bad. The reason why I suggest this
is that it seems like interrupts are being lost.
I put
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 is bad. The reason why I suggest this
is that it
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
The sysctl command shows that machdep.acpi_root is 0.
On 24-Nov-2003 Nate Lawson wrote:
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
The sysctl command
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,cdb64acc) at AcpiUtReleaseMutex+0x8c
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,cdb64acc) at AcpiUtReleaseMutex+0x8c
On 25-Nov-2003 Nate Lawson wrote:
Someone more familiar with ithread_loop should probably answer this. One
workaround might be to enable ACPI_NO_SEMAPHORES on your box.
I built and booted a kernel with ACPI_NO_SEMAPHORES, but it still
hangs at the same point in the boot. The stack trace is
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] mailing list
18 matches
Mail list logo
