Hello all,
2.5.58 hangs during booting, at this place:
......
BIO: pool of 256 setup, 15Kb (60 bytes/bio)
biovec pool[0]: 1 bvecs: 256 entries (12 bytes)
biovec pool[1]: 4 bvecs: 256 entries (48 bytes)
biovec pool[2]: 16 bvecs: 256 entries (192 bytes)
biovec pool[3]: 64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
ACPI: Subsystem revision 20030109
2.5.56 was working OK, except the usual usb problems.
Thank you,
Michael
karpfen:/home/dreher # lspci -v
00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266]
Subsystem: VIA Technologies, Inc. VT8367 [KT266]
Flags: bus master, 66Mhz, medium devsel, latency 0
Memory at e0000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP] (prog-if 00
[Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: e8000000-e80fffff
Prefetchable memory behind bridge: e4000000-e7ffffff
Capabilities: [80] Power Management version 2
00:06.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 50) (prog-if
00 [UHCI])
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at d000 [size=32]
Capabilities: [80] Power Management version 2
00:06.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 50) (prog-if
00 [UHCI])
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 32, IRQ 5
I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
00:06.2 USB Controller: VIA Technologies, Inc.: Unknown device 3104 (rev
51) (prog-if 20)
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 32, IRQ 7
Memory at e8111000 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
(rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at d800 [size=256]
Memory at e8110000 (32-bit, non-prefetchable) [size=256]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [50] Power Management version 2
00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3147
Subsystem: VIA Technologies, Inc.: Unknown device 3147
Flags: bus master, stepping, medium devsel, latency 0
Capabilities: [c0] Power Management version 2
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
(prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc. Bus Master IDE
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at dc00 [size=16]
Capabilities: [c0] Power Management version 2
00:11.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 23) (prog-if
00 [UHCI])
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 32, IRQ 7
I/O ports at e000 [size=32]
Capabilities: [80] Power Management version 2
00:11.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 23) (prog-if
00 [UHCI])
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 32, IRQ 7
I/O ports at e400 [size=32]
Capabilities: [80] Power Management version 2
00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 40)
Subsystem: AOPEN Inc.: Unknown device 01ae
Flags: medium devsel, IRQ 5
I/O ports at e800 [size=256]
Capabilities: [c0] Power Management version 2
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro TF
(prog-if 00 [VGA])
Subsystem: Unknown device 1787:0100
Flags: bus master, stepping, 66Mhz, medium devsel, latency 32,
IRQ 11
Memory at e4000000 (32-bit, prefetchable) [size=64M]
I/O ports at c000 [size=256]
Memory at e8020000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [50] AGP version 2.0
Capabilities: [5c] Power Management version 2
karpfen:/home/dreher #
> From: Michael Dreher [mailto:[email protected]]
> 2.5.58 hangs during booting, at this place:
>
> ......
> BIO: pool of 256 setup, 15Kb (60 bytes/bio)
> biovec pool[0]: 1 bvecs: 256 entries (12 bytes)
> biovec pool[1]: 4 bvecs: 256 entries (48 bytes)
> biovec pool[2]: 16 bvecs: 256 entries (192 bytes)
> biovec pool[3]: 64 bvecs: 256 entries (768 bytes)
> biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
> biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
> ACPI: Subsystem revision 20030109
>
> 2.5.56 was working OK, except the usual usb problems.
Hi Michael,
Can you stick a printk in ev_sci_handler and see if that's being called
repeatedly?
If not, then could you please narrow down where after the version
printout things are getting hung up?
Thanks -- Regards -- Andy
Hi Andrew, all.
I have the same problem here with 2.5.57/8/9 with a Toshiba 2410 Laptop.
Very funny also. The exact system lockup varies according to printk's
inserted in the code.
>Can you stick a printk in ev_sci_handler and see if that's being called
>repeatedly?
>
Yes it is.
do_IRQ() is called for irq line 9, calls handle_IRQ_event() which then
calls acpi_irq and finally ev_sci_handler().
This repeats 'ad infinitum'. Didn't wait for more than a few minutes,
but it looks like it will.
The interrupts are handled at acpi_ev_gpe_detect (), which returns 1. At
this point in_irq() returns 0x00010000 (or 0x00001000, don't have a
serial console :/)
Any ideas ??? Need some more debugging ?
Funny enough, without the printk's it usually hangs at
create_workqueue(), while doing wait_for_completion() - seems the kernel
thread simply fails to get run.
--
?lvaro Lopes
---------------------
A .sig is just a .sig
> This repeats 'ad infinitum'. Didn't wait for more than a few minutes,
> but it looks like it will.
>
> The interrupts are handled at acpi_ev_gpe_detect (), which returns 1.
> At this point in_irq() returns 0x00010000 (or 0x00001000, don't have a
> serial console :/)
>
I have done some debugging, and here are the not-so-exciting results:
GPE08 is dispatched. My debug shows something like this:
* Is a control method
* Method at AML address d08047a4 length 39D
* Begin method parse Entry=cff43904 obj=cff4238c
* State=cff4ec00
* Completed one call to walk loop, AE_OK, state=cff4ec00
* Parser exiting, status AE_OK
* Begin method execution Entry=cff43904 obj=cff4238c
* State=cff4ec00
* Completed one call to walk loop, AE_CTRL_TRANSFER State=cff4ec00
* Execute Method 00000000, current state cff4ec00
* State=cff4e800
* Completed one call to walk loop, AE_OK, State=cff4e800
* Parser exiting, status AE_OK
* Starting nested execution, newstate=cff4e800
* Completed one call to walk loop, AE_OK, state=cff4e800
* Completed one call to walk loop, AE_OK, state=cff4ec00
* Parser exiting, status AE_OK
And keeps doing this every time GPE08 is enabled.
Any ideas ? Right now I have disabled the GPE and can trigger an enable
via /proc, so if you need more info, please tell me.
The hex dump at 0xd08047a4 + 1 shows something like:
5c 2f 04 5f 53 42 5f 50 43 49 30 50 43 49 42 42 52 47 42 60 79 60 0a 18
60 0c 0b b1 20 00 60 70 0a af
5c 2f 03 5f 53 42 5f 4d 45 4d 5f 49 45 44 49 53 4d 42 52 0b 00 ff 60 0a
00 0a 00 0a b2 a2 4b 35 91
5c 2f 03 5f 53 42 5f 4d 45 4d 5f 47 50 35 30 91
....
And now a stupid question: on the second line I believe it reads as
"Root" "Multiname" "3 Segments", but it looks like it has 4
(_SB_.MEM_.IEDI.SMBR). Is this correct ?
--
?lvaro Lopes
---------------------
A .sig is just a .sig