Bug 5904
| Summary: | wrong state of laptop lid on startup | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Fabian Zeindl (fabian) |
| Component: | Other | Assignee: | Zhang Rui (rui.zhang) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | acpi-bugzilla, bunk |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.15 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
acpidump
get LID state earlier Dmesg output with patch new dsdt |
||
>Checking 'hlt' instruction... OK.
> ACPI-0284: *** Info: Table [DSDT] replaced by host OS
Please re-test without overriding DSDT.
I've tested it without overriding. Same result... Please verify that this is still a problem with a recent kernel, such as 2.6.17.stable or 2.6.18-rc Hi, I run 2.6.17.7 and still have this problem on my laptop. please have a look at bug 5809 shown in http://bugzilla.kernel.org/show_bug.cgi?id=5809, and make sure whether you've got the same problem.:) If not, please make the test that Len Brown asked in #1, that will be helpful.:) I did the test: 1. When you boot the system with the lid open, what does state say? # cat /proc/acpi/button/lid/LID0/state state: closed 2. When you then press the lid button down (or actually close the lid and check the state from a serial console or network connection) what does state say? # cat /proc/acpi/button/lid/LID0/state state: closed 3. when you release or open the lid, what does state say? # cat /proc/acpi/button/lid/LID0/state state: open I dont't think I have the same problem, because after I closed the lid once everything is working perfectly fine. I don't have problems like I have to wait 20 seconds to change the status or things like that. Please attach your acpidump output.:) Created attachment 8847 [details]
acpidump
Created attachment 8850 [details]
get LID state earlier
Maybe OS gets a wrong LID state by evaluate "_LID" method. So i try to get the
LID state at an earlier time. if the state still shows "closed". i think this
is probably caused by a bios bug. Please try this patch and attach dmesg
again:)
Rui,
Looking at the DSDT...
Device (LID)
{
Name (_HID, EisaId ("PNP0C0D"))
Method (_LID, 0, NotSerialized)
{
If (LIDS)
{
Return (0x01)
}
Else
{
Return (0x00)
}
}
Name (_PRW, Package (0x02)
{
0x18,
0x03
})
}
and LIDS is defined here:
OperationRegion (MNVS, SystemMemory, 0x0EEEBF09, 0x40)
Field (MNVS, AnyAcc, Lock, Preserve)
{
OSYS, 16,
SMIF, 8,
PRM0, 8,
PRM1, 8,
SCIF, 8,
PRM2, 8,
PRM3, 8,
LCKF, 8,
PRM4, 8,
PRM5, 8,
DBGS, 8,
DCKS, 4,
CDCK, 4,
FPEN, 8,
FPST, 8,
LIDS, 8,
PWRS, 8,
and LIDS is accessed here:
Method (_Q2E, 0, NotSerialized)
{
Store (0x2E, P80H)
If (LEqual (\_SB.PCI0.LPCB.EC.P54, 0x00))
{
Store (0x98, \_SB.PCI0.LPCB.EC.P54S)
Store (0x00, LIDS)
}
Else
{
Store (0x88, \_SB.PCI0.LPCB.EC.P54S)
Store (0x01, LIDS)
}
Notify (\_SB.LID, 0x80)
}
Which is an Embedded Controller event handler.
and P54 is defined here:
OperationRegion (ERAM, EmbeddedControl, 0x00, 0x7F)
Field (ERAM, AnyAcc, Lock, Preserve)
{
Offset (0x01),
SCIC, 8,
Offset (0x04),
CMCD, 8,
DAT1, 8,
DAT2, 8,
DAT3, 8,
Offset (0x18),
SMPR, 8,
SMST, 8,
SMAD, 8,
SMCM, 8,
SMD0, 264,
SMAA, 8,
Offset (0x43),
P50, 1,
, 2,
P43, 1,
P54, 1,
If you can access the valuyes of P54 and LIDS before
any lid events are triggered, then that will tell us
if the values are correct in the hardware and perhaps an
EC event was necessary to update LIDS and notify the OS.
(and maybe Linux has a bug where that even was dropped
and the EC handler was not invoked?)
or if the values are incorrect in P54 and LIDS until there is
an actual LID change, then this hardware and BIOS simply
work that way and Linux will not be able to fix this bug.
Fabian,
It would be interesting if you can boot the laptop with
the lid closed, log in over the network and observe the
lid status then. presumably it will say closed, as that
is apparently the inital value no matter what.
Then on 1st open the lid state should immediately switch
to open, because this ec event handler should run for
the first time (and you should see an increment under
acpi in /proc/interrupts) and update the value to be open.
If that doesn't work, then I'm off track here and the
issue is elsewhere.
i really have the same doubt that whether LIDS/P54S is initialized the right value when the laptop boots. i suppose that adding an method (maybe the _INI) for LID0 device which will set LIDS to 1 may help this laptop boots correctly with the LID open. Any other places to set LIDS to 1 will also works. but i don't know whether this can be realized or not. Maybe i am on the wrong way from the beginning ... Rui, You can find the values of these locations at boot in two ways. 1. find the chip-set spec for the hardware, determine the addresses to read/write, and use inl(1) etc. or 2. modify the DSDT with move(variable, Debug) lines that are invoked at some boot time place before the event in question. build the DSDT into the kernel and build with CONFIG_ACPI_DEBUG so that the messages come out in the console log. 1. When I try the patch it still says "closed" after bootup. I attached dmesg. 2. When I try to boot the laptop with LID closed (by touching the sensor) it immediatly powers off again. When I reboot with LID closed it's the same. it powers off. When I wait until the grub menu comes I can close it and it will be boot. I logged in over network and lid state says "closed". Created attachment 8880 [details]
Dmesg output with patch
P.S.: I tried booting and logging in over network with the old kernel again _without_ the patch. > I logged in over network and lid state says "closed".
And when you opened it for the first time, did it correctly
switch to "open", and increment the acpi line in /proc/acpi/interrupts?
Yes, it switched to open. I don't have /proc/acpi/interrupt. >Yes, it switched to open. Everything goes well when boot with the Lid closed. This proves that Linux does not drop any events. It seems that the values remains 0 in LIDS no matter the Lid is open or closed until there is an actual LID change. This "0" value is meaningless because no one touches it since the system boots.But OS treats this as the signature of "closed" Lid state. This is rather a BIOS bug that Linux can't fix. >I don't have /proc/acpi/interrupts. cat /proc/interrupts check if there is an acpi interrupt increment when you open the Lid for the first time. No, it doesn't increment, it stays on 186 or something like this. I've to close the LID another time, then it begins to increment. So do you mean that when open the lid for the first time, State turns to "open" immediately but none acpi interrupt occurs. That's weird.:( How about this one: # /etc/init.s/acpid stop # cat /proc/acpi/event Would you please try this test and tell me the result? :) And if you can boot your laptop with Lid open and do the same two tests again, that will be great.:) I did the test again, and when I boot with lid closed it says closed and when I open it it says closed and I have to close and open it another time for correct value. sorry, I think I did something wrong before. Do you need the new tests too? OK. Sounds interesting. Let's repeat the tests again,and during the first step, i want you to give me the following information. Lid state, acpi interrupts(proc/interrupts). Boots with the lid open and lid closed, make a record every time you open/close your Lid until everything is OK.:) OK: === Boot with LID open === interrupts: 9: 149 XT-PIC acpi state: state: closed ==> LID CLOSE interrupts: 9: 156 XT-PIC acpi state: state: closed ==> LID OPEN interrupts: 9: 198 XT-PIC acpi state: state: open === Boot with LID close === interrupts: 9: 183 XT-PIC acpi state: state: closed ===> LID OPEN interrupts: 9: 218 XT-PIC acpi state: state: closed ===> LID CLOSE interrupts: 9: 225 XT-PIC acpi state: state: closed ===> LID OPEN interrupts: 9: 267 XT-PIC acpi state: state: open I hope this helps. Is the one interrupts-line OK? Is there a reason why interrupts increment now everytime? I'm on ac power so I don't think it's a "power interrupt" (if such things exist). What can that be? There is really an abnormal interrupt increment that brings me some difficulty to make sure whether there is an interrupt occurs when you open/close the Lid. This time let's try this way. Do the following soon after OS is started. # /etc/init.s/acpid stop # cat /proc/acpi/event open/close the lid for several times and record what is print out each time. And /proc/interrupts as well:) Created attachment 8914 [details]
new dsdt
override your dsdt with this one.
cat your Lid state before any Lid open/close operations.
then open/close it until everything is OK.
attach the dmesg output.:)
set CONFIG_ACPI_CUSTOM_DSDT=y and CONFIG_ACPI_CUSTOM_DSDT_FILE="/.../dsdt.hex" (the full pathname of the new dsdt file here). Make and install, and your new DSDT table will be used in place of the old one. I tried the new dsdt, this doesn't change anything. boot with lid open: interrupts:615 lid:closed ->close interrupts:661 lid:closed ->open interrups:672 lid:open boot with lid closed: interrupts:186 lid:closed ->open interrupts:223 lid:closed ->closed interrups:264 lid:closed ->open interrups:297 lid:open i remove acpid of the startup scripts for all this. I noticed that doing cat /proc/acpi/button/lid/LID0/state increases the interrupt line too. greetings PS: can't we just close this bug to won't fix or something? I'm spending far more time debugging that it annoys me. I think you should attatch the _dmesg_ output with the new dsdt. :) Debug information in the dmesg will tell us if the values are correct in the hardware. This can really help us find the key reason of this bug. Sorry to bother you too much. But we are getting closer to the right way step by step. It will be very kind of you to try it again. Thanks. Please reopen this bug if: - it is still present in kernel 2.6.19 and - you can provide the requested information. |
Distribution: Gentoo Linux Hardware Environment: Acer Travelmate 243LC Problem Description: Hi When my laptop is started and my laptop lid is open, /proc/acpi/button/lid/LID/state says "closed". When I close it once and open it again once the value is set correctly. This is very annoying cause my screensaver always invokes on startup. Linux version 2.6.15-suspend2 (root@obsidian) (gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #2 PREEMPT Sat Jan 14 23:12:45 C ET 2006 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved) BIOS-e820: 00000000000d8000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000eee0000 (usable) BIOS-e820: 000000000eee0000 - 000000000eeeb000 (ACPI data) BIOS-e820: 000000000eeeb000 - 000000000ef00000 (ACPI NVS) BIOS-e820: 000000000ef00000 - 0000000010000000 (reserved) BIOS-e820: 00000000fec10000 - 00000000fec20000 (reserved) BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved) BIOS-e820: 00000000fffffc00 - 0000000100000000 (reserved) 238MB LOWMEM available. found SMP MP-table at 000f63f0 On node 0 totalpages: 61152 DMA zone: 4096 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 57056 pages, LIFO batch:15 HighMem zone: 0 pages, LIFO batch:0 DMI present. ACPI: RSDP (v000 PTLTD ) @ 0x000f6420 ACPI: RSDT (v001 PTLTD Montara 0x06040000 LTP 0x00000000) @ 0x0eee5e05 ACPI: FADT (v001 Acer Yuhina 0x06040000 PTL 0x00000001) @ 0x0eeeaed2 ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) @ 0x0eeeafd8 ACPI: DSDT (v001 ANNI Yuhina 0x06040000 MSFT 0x0100000e) @ 0x00000000 Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. SMP mptable: bad signature [0x0]! BIOS bug, MP table errors detected!... ... disabling SMP support. (tell your hw vendor) Allocating PCI resources starting at 20000000 (gap: 10000000:eec10000) Built 1 zonelists Kernel command line: root=/dev/hda3 resume2=/dev/hda2 init=/sbin/initng lapic Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! mapped APIC to ffffd000 (fee00000) Initializing CPU#0 PID hash table entries: 1024 (order: 10, 16384 bytes) Detected 2498.310 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 238724k/244608k available (2212k kernel code, 5452k reserved, 740k data, 148k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 5002.83 BogoMIPS (lpj=10005677) Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000 CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 128K CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled mtrr: v2.0 (20020519) CPU: Intel(R) Celeron(R) CPU 2.50GHz stepping 09 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI-0284: *** Info: Table [DSDT] replaced by host OS ACPI: setting ELCR to 0200 (from 0c30) NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfd6b4, last bus=2 PCI: Using configuration type 1 ACPI: Subsystem revision 20050902 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) Boot video device is 0000:00:02.0 PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 1180-11bf claimed by ICH4 GPIO PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 10 11) *5 ACPI: PCI Interrupt Link [LNKB] (IRQs *10 11) ACPI: PCI Interrupt Link [LNKC] (IRQs *10 11) ACPI: PCI Interrupt Link [LNKD] (IRQs *11) ACPI: PCI Interrupt Link [LNKE] (IRQs 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs *10 11) ACPI: PCI Interrupt Link [LNKG] (IRQs *10 11) ACPI: PCI Interrupt Link [LNKH] (IRQs 10 11) *4 ACPI: Embedded Controller [EC] (gpe 28) usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0 PCI: Bus 3, cardbus bridge: 0000:02:04.0 IO window: 00003400-000034ff IO window: 00003800-000038ff PREFETCH window: 20000000-21ffffff MEM window: 26000000-27ffffff PCI: Bus 7, cardbus bridge: 0000:02:04.1 IO window: 00003c00-00003cff IO window: 00001400-000014ff PREFETCH window: 22000000-23ffffff MEM window: 28000000-29ffffff PCI: Bridge: 0000:00:1e.0 IO window: 3000-3fff MEM window: e0200000-e02fffff PREFETCH window: 20000000-24ffffff PCI: Setting latency timer of device 0000:00:1e.0 to 64 ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNKF] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 10 ACPI: PCI Interrupt 0000:02:04.1[B] -> Link [LNKG] -> GSI 10 (level, low) -> IRQ 10 Simple Boot Flag at 0x3c set to 0x1 Machine check exception polling timer started. SGI XFS with no debug enabled Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered vesafb: Intel Corporation, Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller, Hardware Version 0.0 (OEM: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS) vesafb: VBE version: 3.0 vesafb: VBIOS/hardware doesn't support DDC transfers vesafb: no monitor limits have been set vesafb: scrolling: redraw Console: switching to colour frame buffer device 128x48 vesafb: framebuffer at 0xe8000000, mapped to 0xcf880000, using 6144k, total 16192k fb0: VESA VGA frame buffer device ACPI: AC Adapter [AC] (on-line) ACPI: Battery Slot [BAT0] (battery present) ACPI: Power Button (FF) [PWRF] ACPI: Lid Switch [LID] ACPI: Sleep Button (CM) [SLP2] ACPI: Video Device [VGA] (multi-head: yes rom: no post: no) Using specific hotkey driver ACPI: CPU0 (power states: C1[C1] C2[C2]) ACPI: Thermal Zone [THRS] (58 C) ACPI: Thermal Zone [THRC] (52 C) Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected an Intel 855 Chipset. agpgart: Detected 16252K stolen memory. agpgart: AGP aperture is 128M @ 0xe8000000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 [drm] Initialized i915 1.1.0 20040405 on minor 0: [drm] Initialized i915 1.1.0 20040405 on minor 1: intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM chipsets intelfb: Version 0.9.2 ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 intelfb: Cannot reserve FB region. i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 serio: i8042 AUX3 port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice 8139too Fast Ethernet driver 0.9.27 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 ACPI: PCI Interrupt 0000:02:0a.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 eth0: RealTek RTL8139 at 0xcf80a000, 00:0a:e4:4a:d9:20, IRQ 11 eth0: Identified 8139 chip type 'RTL-8101' tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH4: IDE controller at PCI slot 0000:00:1f.1 PCI: Enabling device 0000:00:1f.1 (0005 -> 0007) ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 ICH4: chipset revision 3 ICH4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1810-0x1817, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1818-0x181f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... input: AT Translated Set 2 keyboard as /class/input/input0 hda: HITACHI_DK23FA-30, ATA DISK drive Synaptics Touchpad, model: 1, fw: 5.8, id: 0x9248b1, caps: 0x904713/0x4000 input: SynPS/2 Synaptics TouchPad as /class/input/input1 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: QSI CD-RW/DVD-ROM SBW-242, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 58605120 sectors (30005 MB) w/2048KiB Cache, CHS=58140/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hda3 hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNKF] -> GSI 10 (level, low) -> IRQ 10 Yenta: CardBus bridge found at 0000:02:04.0 [1025:0039] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:02:04.0, mfunc 0x00921b22, devctl 0x64 Yenta: ISA IRQ mask 0x00b8, PCI irq 10 Socket status: 30000020 pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe02fffff pcmcia: parent PCI bridge Memory window: 0x20000000 - 0x24ffffff ACPI: PCI Interrupt 0000:02:04.1[B] -> Link [LNKG] -> GSI 10 (level, low) -> IRQ 10 Yenta: CardBus bridge found at 0000:02:04.1 [1025:0039] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:02:04.1, mfunc 0x00921b22, devctl 0x64 Yenta: ISA IRQ mask 0x00b8, PCI irq 10 Socket status: 30000006 pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe02fffff pcmcia: parent PCI bridge Memory window: 0x20000000 - 0x24ffffff usbmon: debugfs is not available ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11 ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:1d.7 to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller ehci_hcd 0000:00:1d.7: debug port 1 PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:1d.7: irq 11, io mem 0xe0100000 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 hub 1-0:1.0: USB hub found hub 1-0:1.0: 6 ports detected USB Universal Host Controller Interface driver v2.3 ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:1d.0 to 64 uhci_hcd 0000:00:1d.0: UHCI Host Controller uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 uhci_hcd 0000:00:1d.0: irq 11, io base 0x00001820 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:1d.1 to 64 uhci_hcd 0000:00:1d.1: UHCI Host Controller uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 uhci_hcd 0000:00:1d.1: irq 11, io base 0x00001840 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 PCI: Setting latency timer of device 0000:00:1d.2 to 64 uhci_hcd 0000:00:1d.2: UHCI Host Controller uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4 uhci_hcd 0000:00:1d.2: irq 10, io base 0x00001860 hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected pccard: CardBus card inserted into slot 0 usb 2-2: new low speed USB device using uhci_hcd and address 2 input: Darfon USB Mouse as /class/input/input2 input: USB HID v1.10 Mouse [Darfon USB Mouse] on usb-0000:00:1d.0-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC). ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 PCI: Setting latency timer of device 0000:00:1f.5 to 64 intel8x0_measure_ac97_clock: measured 55333 usecs intel8x0: clocking to 48000 ALSA device list: #0: Intel 82801DB-ICH4 with CS4299 at 0xe0100c00, irq 10 NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 3, 32768 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available Using IPI Shortcut mode Suspend2 Core. Suspend2 Compression Driver loading. Suspend2 Encryption Driver loading. Suspend2 Swap Writer loading. ACPI wakeup devices: LID LANC MODM ACPI: (supports S0 S3 S4 S5) Suspend2 2.2-rc16: Swapwriter: Signature found. Suspend2 2.2-rc16: Suspending enabled. swapper(1): READ block 0 size 4096 on hda2 XFS mounting filesystem hda3 Ending clean XFS mount for filesystem: hda3 VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 148k freed IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com> microcode: CPU0 updated from revision 0x17 to 0x2e, date = 08112004 Adding 500464k swap on /dev/hda2. Priority:-1 extents:1 across:500464k