Bug 529
| Summary: | Yenta + ACPI = lockup, unless pci=noacpi | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Matthew Harrell (mharrell-lk) |
| Component: | Config-Interrupts | Assignee: | Len Brown (lenb) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | blocking | CC: | acpi-bugzilla, davej, john.stultz |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.5.50 - 2.5.66 at least. | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
FWIW, I see exactly the same issue on a Sony Vaio Z600TEK. just hangs at the ACPI: Embedded Controller [EC0] (gpe 1) message. There seem to be a few variations of this kind of bug - at least I've heard from a few other people who've also had problems but they're not exactly the same. In my case it looks like the hangup is a conflict between pcmcia and ACPI. If either one is disabled then it works fine. If I enable both then the system locks hard with no messages about two seconds (just time enough for me to type another command) after loading yenta_socket. I have tried playing with the algorithms in the yenta module to determine where it might be having a problem but haven't found anything yet. I'll try more soon when I get time. Not even sure where to begin looking on the ACPI side *** This bug has been marked as a duplicate of 430 *** How is this a dupe? They seem to be completely different bugs. #430 is an interrupt assignment bug, but the box still boots. #529 doesn't even get as far as init(1) Mine does get farther than init but still hangs. #430 appears to be a problem with ISA interrupts? If that's the case then that's not what's happening on mine. All of my interrupts are for PCI devices - I'm not sure anything is ISA on this laptop. I also don't have any conflict messages reported during bootup ok, I still think this one is interrupt related. Need more info. So problems go away if either pcmcia (which is ISA) or acpi are turned off? There are a few people who I've talked to (but really haven't added any comments here) that have similiar sounding but not the same problems. And, my pcmcia controller is PCI as far as I know - lspci gives 00:09.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) I don't know how to check if there's an ISA component too. Also, the actual pcmcia component that locks it solid is yenta which is a cardbus driver - aren't cardbus always pci? Anyway, back to your question. Yes, I can either boot with "acpi=off" or without loading yenta.o (which essentially means not starting pcmcia since there's nothing I can do without that module). "pci=noacpi" does not seem to help in any way. OK I'll try to replicate/dig in more on this over the weekend. In the meantime if you can nail down exactly when this started that'd be great. Was it 2.5.50? tidying up various fields and marking assigned. Guess I never did post that info. I went back and rebuilt all kernels from 2.5.45 to 2.5.48 with the same config. 2.5.45 and .46 worked fine. 2.5.47 had modules serious whacked so I can't give a reliable assessment of that one. 2.5.48 definitely has the problem. I'll try to see if I can find out more about 2.5.47. Are there any new test results with the recent ACPI? Nope, no change on my laptop with 2.6.0-test4-bk10. I'm currently running with pci=noacpi since that seems to make USB work flawlessly. Unfortunately it doesn't have an effect on pcmcia since that still hangs when yenta gets loaded So far, I didn't find boot hang with Yenta+ACPI, but I found boot hang with Yenta, please reference bug 1237. Would you please have it a try? ( I'm not sure it could resolve you problem). Thanks a lot. I think I need correct my comment#12. The boot hang I found will happen with 2.6.0-test5. (ACPI doesn't change anything for this hang). Well, I tried the patch from bug 1237 but it didn't have any effect. This was with kernel 2.6.0-test5-bk3. The kernel still locks up right after the yenta module is loaded Would you please have patch at bug 1186 a try? thanks a lot. Well, at first glance the simple patch at bug 1186 seems to do it more or less. There's a nasty five second or so lag when pcmcia starts and during card insertion / removal where the entire system locks up but it does seem to work. I'll test it some more with more than the flashram card I was using. And after that kernel mysteriously crashed when I rebooted the machine the patch did not work. The instant I started pcmcia and loaded the yenta module then the machine locked up entirely. I cannot guarantee that the previous message had anything to do with the patch and just wasn't a fluke. Does a recent 2.4 or 2.6 kernel work with yenta on this system, or does it still require pci=noacpi? If it still fails, please, attach the output from dmidecode, available in /usr/sbin/, or here: http://www.nongnu.org/dmidecode/ so we can identify the system. Also, please attach the output from acpidmp, available in /usr/sbin/, or in here http://www.intel.com/technology/iapc/acpi/downloads/pmtools-20010730.tar.gz so we can look at what the BIOS is asking us to do. lspci output would also be useful. If possible, dmesg and proc interrupts from acpi booting w/o any flags would be hepful. thanks, -Len please try the patch in Bug 1564 2.4.26 and 2.6.5 include the fix for bug 1564. If this problem persists in those releases, please re-open. thanks, -Len |
Distribution: Debian Woody / Sid Hardware Environment: HP ZT1195 laptop Software Environment: Problem Description: Ever since that that update around 2.5.50 of the ACPI system I cannot boot my laptop at all with anything other than acpi=off. I am trying to build the older kernels to determine exactly which version started this problem. I do have a working version of 2.5.48 I'm using right now which produces the following interrupts: CPU0 0: 725368 XT-PIC timer 1: 4038 XT-PIC i8042 2: 0 XT-PIC cascade 8: 4 XT-PIC rtc 9: 31 XT-PIC acpi, VIA8233 10: 581 XT-PIC uhci-hcd, eth0 11: 3160 XT-PIC PCI device 1524:1410 (ENE Technology Inc), eth1 12: 14931 XT-PIC i8042 14: 9367 XT-PIC ide0 15: 27 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 dmesg sections from 2.5.45: ACPI: have wakeup address 0xc0001000 On node 0 totalpages: 126960 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 122864 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: RSDP (v000 OID_00 ) @ 0x000e5010 ACPI: RSDT (v001 INSYDE RSDT_000 00000.00001) @ 0x1efffbc0 ACPI: FADT (v003 INSYDE FACP_000 00000.00256) @ 0x1efffac0 ACPI: BOOT (v001 INSYDE SYS_BOOT 00000.00256) @ 0x1efffb50 ACPI: DBGP (v001 INSYDE DBGP_000 00000.00256) @ 0x1efffb80 ACPI: DSDT (v001 INSYDE VT8633 00000.04096) @ 0x00000000 ACPI: BIOS passes blacklist ACPI: MADT not present .... ACPI: Subsystem revision 20021022 ACPI-0357: *** Warning: Inconsistent FADT length (0x84) and revision (0x3), using FADT V1.0 portion of table ACPI-0508: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI breakpoint: Executed AML Breakpoint opcode ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: (supports S0 S3 S4 S5) ACPI: PCI Interrupt Link [LNKA] (IRQs 5 7 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7 10, enabled at IRQ 11) ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *9 10 11) ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 *10) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Embedded Controller [EC0] (gpe 1) dmesg from my latest attempt, 2.5.66-bk7 with a fixed DSDT: On node 0 totalpages: 126960 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 122864 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: RSDP (v000 OID_00 ) @ 0x000e5010 ACPI: RSDT (v001 INSYDE RSDT_000 00000.00001) @ 0x1efffbc0 ACPI: FADT (v003 INSYDE FACP_000 00000.00256) @ 0x1efffac0 ACPI: BOOT (v001 INSYDE SYS_BOOT 00000.00256) @ 0x1efffb50 ACPI: DBGP (v001 INSYDE DBGP_000 00000.00256) @ 0x1efffb80 ACPI: DSDT (v001 INSYDE VT8633 00000.04096) @ 0x00000000 ACPI: BIOS passes blacklist ACPI: MADT not present ... ACPI: Subsystem revision 20030228 tbconvrt-0375: *** Warning: Inconsistent FADT length (0x84) and revision (0x3), using FADT V1.0 portion of table tbget-0292: *** Info: Table [DSDT] replaced by host OS tbxface-0117 [03] acpi_load_tables : ACPI Tables successfully acquired Parsing all Control Methods:................................................................................................................................................ Table [DSDT] - 664 Objects with 45 Devices 144 Methods 27 Regions ACPI Namespace successfully loaded at root c0428bbc evxfevnt-0092 [04] acpi_enable : Transition to ACPI mode successful evgpe-0416 [06] ev_create_gpe_block : GPE Block: 2 registers at 0000000000001020 evgpe-0421 [06] ev_create_gpe_block : GPE Block defined as GPE0 to GPE15 Executing all Device _STA and_INI methods:........<3>ACPI breakpoint: Executed AML Breakpoint opcode ..................................... 45 Devices found containing: 45 _STA, 5 _INI methods Completing Region/Field/Buffer/Package initialization:............................................................ Initialized 18/27 Regions 0/0 Fields 21/21 Buffers 21/21 Packages (664 nodes) ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 5 7 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7 10, enabled at IRQ 11) ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *9 10 11) ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 *10) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Embedded Controller [EC0] (gpe 1) I've downloaded and installed the latest BIOS from HP and that didn't change anything. I also followed the instructions on fixing my dsdt table and put that in the kernel but that didn't change anything either. Steps to reproduce: Just boot :) Everything appears fine until it gets to the point around where acpid starts - at that point the system slows down immensely and then freezes a few minutes later. If I prevent acpid from starting then it freezes on the next program, the alsa setup. If I take that out then it freezes on lircd. When it does freeze the hard drive light stays on solid but the hard drive makes no noise. The system is totally unresponsive and requires a hard reset.