Bug 529 - Yenta + ACPI = lockup, unless pci=noacpi
Summary: Yenta + ACPI = lockup, unless pci=noacpi
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: i386 Linux
: P2 blocking
Assignee: Len Brown
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-01 11:17 UTC by Matthew Harrell
Modified: 2004-04-12 21:16 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.5.50 - 2.5.66 at least.
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Matthew Harrell 2003-04-01 11:17:20 UTC
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.
Comment 1 Dave Jones 2003-04-04 13:28:51 UTC
FWIW, I see exactly the same issue on a Sony Vaio Z600TEK.
just hangs at the ACPI: Embedded Controller [EC0] (gpe 1) message.
Comment 2 Matthew Harrell 2003-05-13 18:33:31 UTC
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
Comment 3 Andy Grover 2003-05-21 14:11:40 UTC

*** This bug has been marked as a duplicate of 430 ***
Comment 4 Dave Jones 2003-05-21 14:38:51 UTC
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)
Comment 5 Matthew Harrell 2003-05-21 15:01:31 UTC
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
Comment 6 Andy Grover 2003-05-21 15:16:21 UTC
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?
Comment 7 Matthew Harrell 2003-05-21 15:29:18 UTC
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.
Comment 8 Andy Grover 2003-05-21 22:41:10 UTC
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.
Comment 9 Matthew Harrell 2003-05-22 05:05:39 UTC
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.
Comment 10 Luming Yu 2003-09-09 00:02:57 UTC
Are there any new test results with the recent ACPI? 
Comment 11 Matthew Harrell 2003-09-09 04:57:33 UTC
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
Comment 12 Luming Yu 2003-09-15 03:03:12 UTC
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.
Comment 13 Luming Yu 2003-09-15 18:10:20 UTC
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).
Comment 14 Matthew Harrell 2003-09-15 19:24:11 UTC
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
Comment 15 Luming Yu 2003-09-17 00:54:02 UTC
Would you please have patch at bug 1186 a try? thanks a lot.
Comment 16 Matthew Harrell 2003-09-17 13:28:41 UTC
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.
Comment 17 Matthew Harrell 2003-09-17 17:05:59 UTC
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.
Comment 18 Len Brown 2003-11-04 08:07:22 UTC
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 
 
Comment 19 Shaohua 2003-12-02 20:00:47 UTC
please try the patch in Bug 1564
Comment 20 Len Brown 2004-04-12 21:16:43 UTC
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 
 
 

Note You need to log in before you can comment on or make changes to this bug.