DragonFlyBSD

:Booting 1.8 using VMWare Fusion on OS X works fine.
:
:Both systems showed messages like this at shutdown of the LiveCD:
:(this one's from the VMWare environment)
:unmount(/dev): Cannot unmount: 0 namecache references still present
:unmount(/dev): Cannot unmount: 5 process references still present
:unmount(/var): Cannot unmount: 0 namecache references still present
:unmount(/var): Cannot unmount: 5 process references still present
:
:and after the disk sync:
:unmount(0xc12d57c0): Forced unmount: 2 namecache references still present
:unmount(0xc12d57c0): Forced unmount: 4 process references still present
:EXDEV case 1 0xc10c4238

Yah, those can be ignored.  The CD is read-only anyhow.  Getting rid
    of them means cleaning up the installer a bit.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Does this message show up very quickly? If not, can you try to drop
into the boot loader(press "6" on Fred menu):
set debug.acpi_semaphore_debug=1
then boot, and write down some messages beginning with "AcpiOsWaitSemaphore"
and "AcpiOsSignalSemaphore".

I couldn't find the DSDT for 600E, but only for 600 on the Internet:
http://acpi.sourceforge.net/dsdt/view.php?id=457

according to this one, the trace is something like:
\_TZ.THM0._TMP
--> \_SB.PCI0,ISA0,EC0.UPDT
--> \_SB.PCI0,ISA0,EC0.I2RB
--> (access to one of members of ECOR, trying to acquire a semaphore)

The only place where AE_TIME is returned is AcpiOsWaitSemaphore(),
so it's either
- there's four or more threads waiting for the same semaphore,
- msleep(9) failed for some reason, or
- AcpiOsWaitSemaphore() was instructed to return immediately
(but it's only in AcpiExSystemWaitSemaphore() and no warnings
should show up)

There's a mechanism to show you extra debugging information, but
unfortunately acpi.ko gets compiled without ACPI_DEBUG defined,
so it's not available via release ISO (but in this case,
debug.acpi_semaphore_debug should help). I think making ACPI_DEBUG
enabled for snapshot ISOs is a good idea.

I think debug.acpi.disabled="thermal" (or "ec") in the boot loader can be
used as a workaround for now.

Cheers.

(Resurrecting ancient issue)

Tested this with a 1.9 CD from yesterday, with debug.acpi_semaphore_debug set:

AcpiOsWaitSemaphore: Acquire 1, units 0, pending 0, sem 0xc1080b28, thread 1
AcpiOsWaitSemaphore: Sleep 1000, pending 1, semaphore 0xc1080b28, thread 1
AcpiOsWaitSemaphore: Timeout 1000, pending 0, semaphore 0xc1080b28
ACPI Exception (evregion-0529): AE_TIME, Returned by Handler for
[EmbeddedControl] [20061109]
AcpiOsSignalSemaphore: Release 1, units 1, pending 0, semaphore 0xc1080b28, thread 1
ACPI Error (psparse-0638): Method parse/execution failed
[\_SB_.PCI0.ISA0.EC0_.I2RB] (Node 0xc1084e78), AE_TIME
ACPI Error (psparse-0638): Method parse/execution failed
[\_SB_.PCI0.ISA0.EC0_.UPDT] (Node 0xc1084dd0), AE_TIME
ACPI Error (psparse-0638): Method parse/execution failed [\_TZ_.THM0._TMP]
(Node 0xc1084a10), AE_TIME

I do notice early on a number of ACPI messages about "cannot release global
lock" - they scroll by fast enough I haven't been able to capture them. Setting
debug.acpi.disabled="thermal" (or "ec") gave a slightly new set of errors, which
I can write out if they're important.

I uploaded an ISO image built from yesterday's source code
on my leaf account, with ACPI_DEBUG=yes defined:
http://leaf.dragonflybsd.org/~y0netan1/dfly-20070708.iso.bz2
Please drop into boot loader, and type following commands:
set debug.acpi.layer=ACPI_OS_SERVICES
set debug.acpi.level=ACPI_LV_MUTEX
This should enable some more debugging messages which may be useful.

Besides that, can you send me the acpidump output on your computer?

I'd like to know whether setting debug.acpi.disabled="thermal" (or "ec")
fixes the first (looping) message?

Cheers.

I finally got a chance to test this ACPI issue. Setting
debug.acpi.disabled="thermal" lets it boot, using the dfly-20070708.iso image.

Output of acpidump -t is below:

/*
RSD PTR: OEM=IBM, ACPI_Rev=1.0x (0)
RSDT=0x11fd0000, cksum=155
/
/
RSDT: Length=44, Revision=1, Checksum=52,
OEMID=IBM, OEM Table ID=TP600R, OEM Revision=0x1,
Creator ID=, Creator Revision=0x0
Entries={ 0x11fd0100, 0x11fd0040 }
/
/
FACP: Length=116, Revision=1, Checksum=231,
OEMID=IBM, OEM Table ID=TP600R, OEM Revision=0x1,
Creator ID=, Creator Revision=0x0
FACS=0x11fd0100, DSDT=0x11fd0200
INT_MODEL=PIC
Preferred_PM_Profile=Unspecified (0)
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0xa0, ACPI_DISABLE=0xa1, S4BIOS_REQ=0xa2
PSTATE_CNT=0x0
PM1a_EVT_BLK=0xef00-0xef03
PM1a_CNT_BLK=0xef04-0xef05
PM2_CNT_BLK=0x22-0x22
PM_TMR_BLK=0xef08-0xef0b
GPE0_BLK=0xef0c-0xef0f
P_LVL2_LAT=1 us, P_LVL3_LAT=65 us
FLUSH_SIZE=32768, FLUSH_STRIDE=32
DUTY_OFFSET=1, DUTY_WIDTH=3
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
IAPC_BOOT_ARCH=
Flags={WBINVD,PROC_C1,P_LVL2_UP,SLP_BUTTON,RTC_S4,DCK_CAP}
/
/
FACS: Length=64, HwSig=0x00000106, Firm_Wake_Vec=0x00000000
Global_Lock=
Flags=
Version=0
/
/
DSDT: Length=50233, Revision=1, Checksum=131,
OEMID=IBM, OEM Table ID=TP600R, OEM Revision=0x106,
Creator ID=MSFT, Creator Revision=0x100000c
/
/
BOOT: Length=40, Revision=1, Checksum=107,
OEMID=IBM, OEM Table ID=TP600R, OEM Revision=0x1,
Creator ID=, Creator Revision=0x0
*/

So ... does it boot with more recent official snapshot?
debug.acpi.disabled="thermal" works on an ACPI module compiled
without ACPI_DEBUG, so it's either because turning on ACPI_DEBUG
changes something in ACPI-CA code, or the recent changes up to 20070708
have fixed something for your laptop PC to be able to boot.

And if the network interface works, can you send me the dmesg.boot
file, and the DSDT output (you need to specify "-d" or "-o file"
to acpidump to obtain it).

Cheers.

It boots under 1.10.1 the same - with thermal off, it's fine.

It's not online, so it'll take a while to obtain the other data.

Ah, that's OK, it narrowed down the thing a bit. I'll try to pick up
some recent(well, almost three years ago) changes which look relavant
and port them over for us.

Cheers.

Justin,
Do you have that old Thinkpad 600E to give it a try with current HEAD?

Marking resolved; it's being resolved by age, not by actually having it work.
The laptop is so old I practically have to shovel coal in to get it started;
it's not worth worrying about when faster, more compatible models exist for <$200.