Bug 100528 - (ACPI) hang while loading pcmcia -- yenta_socket.o - Toshiba 8100
(ACPI) hang while loading pcmcia -- yenta_socket.o - Toshiba 8100
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
: 104320 (view as bug list)
Depends On:
Blocks: CambridgeTarget
  Show dependency treegraph
Reported: 2003-07-23 02:01 EDT by Alexandre Oliva
Modified: 2015-01-04 17:02 EST (History)
6 users (show)

See Also:
Fixed In Version: kernel-2.6.11-1.1290_FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-12 01:23:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
acpidmp output (23.07 KB, application/x-bzip2)
2003-07-26 22:34 EDT, Alexandre Oliva
no flags Details
dmidecode output (645 bytes, application/x-bzip2)
2003-07-26 22:35 EDT, Alexandre Oliva
no flags Details
Output of dmesg after an acpi-enabled boot without yenta_socket.o (8.81 KB, text/plain)
2003-08-16 14:55 EDT, Alexandre Oliva
no flags Details
Dump$PIR table on current machine (3.59 KB, text/plain)
2003-08-18 12:06 EDT, Len Brown
no flags Details
Boot messages with a Severn kernel + CONFIG_ACPI_DEBUG=y (11.12 KB, text/plain)
2003-08-18 13:14 EDT, Alexandre Oliva
no flags Details
pirqdmp output (BIOS 2.30) (975 bytes, text/plain)
2003-08-18 13:15 EDT, Alexandre Oliva
no flags Details
output from my own build of dmidecode 2.2 (it works!) (11.44 KB, text/plain)
2003-08-18 16:12 EDT, Alexandre Oliva
no flags Details
fixed compile time bug caught by Intel Iasl (162.33 KB, text/plain)
2003-08-20 04:12 EDT, Intel Linux ACPI folks
no flags Details

  None (edit)
Description Alexandre Oliva 2003-07-23 02:01:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
If I boot my Toshiba Tecra 8100 without acpi=off, it hangs when it attempts to
enable the network card, that uses the 3c574_cs module.  This happens both in
the installer and post-install.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Boot a Toshiba Tecra 8100 with acpi enabled and a 3com card that uses the
3c574_cs module

Actual Results:  As soon as it enables networking, it hangs.

Expected Results:  Err... :-)

Additional info:
Comment 1 Alexandre Oliva 2003-07-26 22:01:49 EDT
If I boot watch boot in VT1 (even with graphical boot enabled), even if the
pcmcia card is removed, it still hangs.  Here are the last few lines before the

Starting pcmcia:  PCI: Enabling device 00:0b.0 (0000 -> 0002)
PCI: No IRQ known for interrupt pin A of device 00:0b.0 - using IRQ 255
PCI: Enabling device 00:0b.1 (0000 -> 0002)
PCI: No IRQ known for interrupt pin B of device 00:0b.1 - using IRQ 255
Yenta IRQ list 04b0, PCI irq0
Socket status: 30000007
Comment 2 Alexandre Oliva 2003-07-26 22:29:49 EDT
Ok, the problem is not in 3c574_cs.o (I moved it out of /lib/modules, and it
still hang).  So I moved yenta_socket.o out, and it would no longer hang.  If I
insmod yenta_socket.o then, it hangs.
Comment 3 Alexandre Oliva 2003-07-26 22:34:39 EDT
Created attachment 93170 [details]
acpidmp output
Comment 4 Alexandre Oliva 2003-07-26 22:35:43 EDT
Created attachment 93171 [details]
dmidecode output

Unfortunately, dmidecode doesn't seem to be able to extract information on this
laptop :-(
Comment 5 Len Brown 2003-08-05 16:15:33 EDT
does it boot (or can you load yenta_socket.o) with just pci=noacpi ? 
Comment 6 Alexandre Oliva 2003-08-06 11:55:41 EDT
Yes, booting with pci=noacpi is enough to work around the hang at yenta_socket.o
Comment 7 Len Brown 2003-08-11 22:23:12 EDT
Any chance you can get the boot messages from the failure case via serial 
console?  If it is possible to config a custom kernel, CONFIG_ACPI_DEBUG might 
Comment 8 Alexandre Oliva 2003-08-16 14:55:36 EDT
Created attachment 93684 [details]
Output of dmesg after an acpi-enabled boot without yenta_socket.o

Is this what you had in mind?  If not, I can build a CONFIG_ACPI_DEBUG-enabled
kernel and give it a try.
Comment 9 Jun Nakajima 2003-08-16 17:47:08 EDT
Looks like a problem wiht the ACPI interpreter to me. CONFIG_ACPI_DEBUG-enabled
kernel should be helpful for debugging it.

Comment 10 Len Brown 2003-08-18 11:49:46 EDT
unable to verify BIOS version from garbled dmidecode output. 
Can you make sure that you've got the latest? 
Toshiba web site say the Tecra 8100 takes version 2.50 (released 10/28/2002; 
posted, 1/22/2003; ) 
Comment 11 Len Brown 2003-08-18 12:06:23 EDT
Created attachment 93717 [details]
Dump$PIR table on current machine

# make pirqdmp
# ./pirqdmp
Comment 12 Len Brown 2003-08-18 12:08:22 EDT
ACPI: Subsystem revision 20030619 
PCI: PCI BIOS revision 2.10 entry at 0xfee03, last bus=21 
PCI: Using configuration type 1 
    ACPI-0109: *** Error: No object was returned from [\_SB_.LNKA._STA] (Node 
cff6488c), AE_NOT_EXIST 
    ACPI-0109: *** Error: No object was returned from [\_SB_.LNKB._STA] (Node 
cff649cc), AE_NOT_EXIST 
    ACPI-0109: *** Error: No object was returned from [\_SB_.LNKC._STA] (Node 
cff64b0c), AE_NOT_EXIST 
    ACPI-0109: *** Error: No object was returned from [\_SB_.LNKD._STA] (Node 
cff64c4c), AE_NOT_EXIST 
    ACPI-0109: *** Error: No object was returned from [\_SB_.PCI0.FNC0.FDD_._STA] 
(Node c1312b0c), AE_NOT_EXIST 
    ACPI-0109: *** Error: No object was returned from [\_SB_.PCI0.FNC0.COM_._STA] 
(Node c1312c9c), AE_NOT_EXIST 
    ACPI-0109: *** Error: No object was returned from [\_SB_.PCI0.FNC0.PRT_._STA] 
(Node c1312e7c), AE_NOT_EXIST 
    ACPI-0109: *** Error: No object was returned from [\_SB_.PCI0.FNC0.PRT1._STA] 
(Node c1311184), AE_NOT_EXIST 
    ACPI-0109: *** Error: No object was returned from [\_SB_.PCI0.FNC0.PCC0._STA] 
(Node c13112c4), AE_NOT_EXIST 
ACPI: Interpreter enabled 
ACPI: Using PIC for interrupt routing 
ACPI: System [ACPI] (supports S0 S1 S3 S4bios S4 S5) 
    ACPI-0109: *** Error: No object was returned from [\_SB_.LNKE._PRS] (Node 
cff64db4), AE_NOT_EXIST 
ACPI: PCI Root Bridge [PCI0] (00:00) 
PCI: Probing PCI hardware (bus 00) 
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] 
ACPI: Power Resource [PIHD] (on) 
ACPI: Power Resource [PMHD] (off) 
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] 
ACPI: Power Resource [PFAN] (off) 
PCI: Probing PCI hardware 
PCI: No IRQ known for interrupt pin D of device 00:05.2 
PCI: No IRQ known for interrupt pin A of device 00:07.0 
PCI: No IRQ known for interrupt pin A of device 00:09.0 
PCI: No IRQ known for interrupt pin A of device 00:0b.0 - using IRQ 255 
PCI: No IRQ known for interrupt pin B of device 00:0b.1 - using IRQ 255 
PCI: No IRQ known for interrupt pin A of device 00:0c.0 
PCI: No IRQ known for interrupt pin A of device 01:00.0 
PCI: Using ACPI for IRQ routing 
Unclear to me why the interpreter chokes on the _STA methods for the PIRQs. 
Please run the attached pirqdmp program and attach the output so we can see if the 
platform asks us to do this differently when we're not in ACPI mode. 
Comment 13 Len Brown 2003-08-18 12:54:21 EDT
IASL complained about this DSDT when trying to re-compile the dis-assembled output 
-- exactly where the run-time interpreter choked: 
$ acpixtract DSDT acpidmp.out >dsdt 
$ iasl -d dsdt 
$ iasl dsdt.dsl 
dsdt.dsl    55:             Method (_STA, 0, NotSerialized) 
Warning  2026 -                        ^ Reserved method must return a value (_STA) 
Strange, because the STAL method called by this method _does_ return a value... 
    Scope (\_SB) 
        Device (LNKA) 
            Name (_HID, EisaId ("PNP0C0F")) 
            Name (_UID, 0x01) 
            Method (_STA, 0, NotSerialized) 
                STAL (0x60) 
   Method (STAL, 1, NotSerialized) 
        If (LEqual (Arg0, 0x60)) 
            Store (\_SB.PCI0.FNC0.IRQA, Local0) 
            If (LEqual (Arg0, 0x61)) 
                Store (\_SB.PCI0.FNC0.IRQB, Local0) 
                If (LEqual (Arg0, 0x62)) 
                    Store (\_SB.PCI0.FNC0.IRQC, Local0) 
                    Store (\_SB.PCI0.FNC0.IRQD, Local0) 
        If (LEqual (Local0, 0x80)) 
            Return (0x09) 
            Return (0x0B) 
        Device (PCI0) 
            Device (FNC0) 
                Name (_ADR, 0x00050000) 
                OperationRegion (PIX4, PCI_Config, 0x00, 0xFF) 
                Field (PIX4, ByteAcc, NoLock, Preserve) 
                    Offset (0x60), 
                    IRQA,   8, 
                    IRQB,   8, 
                    IRQC,   8, 
                    IRQD,   8 
Note that this table was built by MSFT ASL compiler: 
$ acpitbl dsdt 
Signature:        DSDT 
Length:           27899 
Revision:         0x01 
Checksum:         0xc1 
OEMID:            TOSHIB 
OEM Table ID:     8100 
OEM Revision:     0x20000614 
Creator ID:       MSFT 
Creator Revision: 0x0100000a 
Comment 14 Alexandre Oliva 2003-08-18 13:12:43 EDT
This is embarrassing.  My BIOS isn't up-to-date, indeed.  I remembered having
updated the BIOS a long time ago, and then I checked the version number in the
BIOS update file I had kept in the hard disk, and it said 2.50.  I probably
downloaded 2.50 when it came out but failed to install it. I was still running 2.30.

The next two attachments will be the output of dmesg with acpi debug enabled and
the pirqdmp output.  I still haven't upgraded the BIOS, in case you'd like some
additional information from this older BIOS.  I'm not sure I can go back after I
proceed to the update, since I no longer have the 2.30 BIOS update file, and I'm
not sure I can get them from Toshiba any longer.
Comment 15 Alexandre Oliva 2003-08-18 13:13:33 EDT
Ah, I think I figured out what happened: I had the MoBo of the laptop replaced
some time ago.  This is probably when the BIOS version got downgraded.
Comment 16 Alexandre Oliva 2003-08-18 13:14:35 EDT
Created attachment 93718 [details]
Boot messages with a Severn kernel + CONFIG_ACPI_DEBUG=y
Comment 17 Alexandre Oliva 2003-08-18 13:15:21 EDT
Created attachment 93719 [details]
pirqdmp output (BIOS 2.30)
Comment 18 Len Brown 2003-08-18 15:09:04 EDT
> INTA#:60/0800 
The "0800" here (and on all the other $PIR entries) means that 
only IRQ11 is available for all the PCI devices in PIC mode. 
This is consistent with the AML, which is hard-coded to return 9 or 11, depending on 
run-time info: 
            Return (0x09)  
            Return (0x0B)  
I don't see any ACPI related comments in Toshihba's notes for BIOS revs 2.50 and 
2.40, so I don't have high hopes the upgrade from 2.30 to help.  Note that they've got 
BIOS revs down to 1.20 on available on their web page. 
BTW regarding the garbled dmidecode info -- it would be interesting to know if the 
latest dmidecode works on this system: 
If so, you might want to upgrade what is shipped in Severn. 
Comment 19 Alexandre Oliva 2003-08-18 16:08:35 EDT
Indeed, upgrading to 2.50 didn't change the boot messages in any way, and it
still hangs the same.
Comment 20 Alexandre Oliva 2003-08-18 16:12:02 EDT
Created attachment 93730 [details]
output from my own build of dmidecode 2.2 (it works!)

Nice, dmidecode 2.2 can decode the tables that the dmidecode in our
kernel-utils-2.4-8.31 fail to decode!  Thanks for the pointer.
Comment 21 Intel Linux ACPI folks 2003-08-19 11:53:35 EDT
The bug here is that the 8100's BIOS does not put return statements 
in methods that require them.  Andy tells me we've hit this before and 
Toshiba has been told about it before.  (Indeed, my new Satellite Pro 
doesn't have this problem). 
The 8100 is taking advantage of a bug in the MSFT AML interpreter 
implementation.  But just like forgetting a return statementout in C, you 
just can't do that and expect it will always work.  Also, I'm told that it would 
be quite difficult to change the ACPICA interpreter to add the same bug. 
I'll blacklist this platform in the ACPI patch, and Severn can pick it up from there. 
BTW. In my comments above, I was incorrect about the 0x9 and 0xB return values. 
The return values from _STA are bit vectors that say if the device is present 
and enabled etc -- not IRQ numbers. 
Comment 22 Intel Linux ACPI folks 2003-08-20 04:12:33 EDT
Created attachment 93773 [details]
fixed compile time bug caught by Intel Iasl

Would you like to try  overridding the DSDT using this file, and see what will
happen. --Thanks
Comment 23 Alexandre Oliva 2003-08-20 04:54:10 EDT
Err...  If you're asking me to do something with this file, I'm afraid I'll need
more detailed instructions (or pointers to them :-)  I'm just a GCC hacker, as
clueless as possible as far as this ACPI stuff goes.  Thank you all for looking
into this, anyway!
Comment 24 Len Brown 2003-08-21 19:48:46 EDT
I'll need to black-list the 8100 in the acpi patch -- which is the Linux resolution to this 
bug.  (unfortunately the DMI has a blank product name for this one, grrr) 
Re: the modified DSDT 
An "enthusiast" or an ACPI BIOS writer may want it, but Red Hat shouldn't mess with it 
-- unless you want to be in the business of supporting modified BIOS.  It is Toshba's 
problem to fix the root cause. 
ps. sorry for the logging-in-as-an-alias thing, I'll fix that. 
Comment 25 Alexandre Oliva 2003-09-03 19:34:52 EDT
acpi=off (or pci=noacpi) is still needed with kernel-2.4.22-20.1.2024.2.36.nptl
Comment 26 Intel Linux ACPI folks 2003-09-03 23:22:58 EDT
I assume that kernel-2.4.22-20.1.2024.2.36.nptl is an upcoming Severn update
based on 2.4.22, yes?  I didn't blacklist the toshiba in 2.4.22, so unless RH
did it, then this is expected.  I'll be pushing some fixes, including this one
into a 2.4.22-based tree on bkbits this week where RH can pick it up when 

Comment 27 Len Brown 2003-09-03 23:25:22 EDT
oops, meant to be logged in as me when i wrote that note...
Comment 28 Alexandre Oliva 2003-09-04 01:00:59 EDT
Upcoming as in already available from the RHN Severn updates channel.  It's
supposed to be in the next Rawhide as well.
Comment 29 Alexandre Oliva 2003-10-19 16:06:17 EDT
2097 kernel still hangs right after pcmcia services start (without rhgb).
Comment 30 Bill Nottingham 2003-10-21 16:23:35 EDT
*** Bug 104320 has been marked as a duplicate of this bug. ***
Comment 31 Alexandre Oliva 2003-10-25 15:26:31 EDT
Err...  I meant it still fails with acpi=on.  With acpi=off (now the default),
it works.
Comment 33 Chris Ricker 2003-11-05 09:29:52 EST
I have a laptop (see Bug #104320; standard AMD / ALi / ATI mobile
athlon combo) which still hangs when yenta_socket loads with
kernel-2.4.22-1.2115.nptl if eth0 (internal natsemi NIC) is already
enabled. What other info is needed about this one?
Comment 34 shaohua li 2003-12-03 00:13:45 EST
can you try the patch in http://bugme.osdl.org/show_bug.cgi?id=1564
Comment 35 Alexandre Oliva 2003-12-03 22:19:49 EST
No change with the patch :-(
Comment 36 Alexandre Oliva 2003-12-18 00:36:54 EST
Same problem still present in kernel-2.6.0-0.test11.1.13.i686.rpm. 
Explicitly disabling ACPI gets it to not hang when loading
yenta_socket, with or without the work around in init.d/pcmcia
proposed for bug 100920.
Comment 37 Alexandre Oliva 2004-02-13 12:01:44 EST
Still present in both FC2 test 1 and 2.6.2-1.74.
Comment 38 Alexandre Oliva 2004-02-25 22:52:42 EST
It works in 2.6.3-1.106, but not without some hurdles.  See bug 116205
for details.  It still prints a stack trace when yenta_socket is
loaded, presumably becuase of the buggy acpi tables.  It goes like this:

Starting pcmcia:  PCI: Enabling device 0000:00:0b.0 (0000 -> 0002)
ACPI: No IRQ known for interrupt pin A of device 0000:00:0b.0 - using
IRQ 255
irq 11: nobody cared!
Call Trace:
[<d090be53>] (usb_hdc_irq+0x0/0x4b [usbcore])
Disabling IRQ #11
PCI: Enabling device 0000:00:0b.1 (0000 -> 0002)
ACPI: No IRQ known for interrupt pin B of device 0000:00:0b.1 - using
IRQ 255
Disabling IRQ #11

afterwards, it seems to hang while starting cups.

If I avoid loading yenta_socket during the boot sequence, then log
into VT1, load yenta_socket and restart pcmcia, everything works fine.
 A nice improvement, but still not quite there :-(
Comment 39 Len Brown 2004-03-24 03:03:31 EST
why closed/rawhide?
Comment 40 Alexandre Oliva 2004-03-24 12:11:56 EST
Err...  Odd, I thought I'd added a comment here pointing to a pcmcia
patch posted by twaugh in another bug that got everything to work fine
with the current rawhide kernel.
Comment 41 Alexandre Oliva 2004-03-24 12:15:03 EST
Bug 116205 is the one I alluded to in the previous comment.
Comment 42 Alexandre Oliva 2004-03-25 12:25:51 EST
Doh!  Stupid me had pci=noacpi in the boot command line, which is why
the problem appeared to be fixed.  Sorry.
Comment 43 Toshio Kuratomi 2004-06-03 14:52:46 EDT
[Toshiba Tecra 8000]
[3C59x Driver: 3cCFE575BT Cyclone]
[kernel 2.6.6-1.383]
[FC 2]

I am not hanging but otherwise am experiencing this bug.  Msgs similar
to #12 at boot and #38 when loading the 3c59x driver (not the
yenta_socket).  The interface is unable to come up, presumably because
the kernel doesn't have the correct IRQ.

Booting with pci=noacpi works around the problem fine.

Let me know if this is still an actively worked on bug and you want
more info, otherwise I'm just going to use the boot option.
Comment 44 Alan Cox 2004-06-21 12:13:26 EDT
Same problem on a sony vaio zr1k except that acpi=off isn't sufficient
and pci-=usepirqmask is needed. 2.4 is fine.

Also seen with a docking station on TP600 with both 2.4 and 2.6. No
workaround found
Comment 45 Len Brown 2004-06-21 23:42:19 EDT
For the toshiba, please test the "ASL implicit return" workaround here: 
The Sony must be different root cause, as it still fails with acpi=off. 
Comment 46 Alexandre Oliva 2004-07-09 14:46:12 EDT
Fix verified on the Toshiba Tecra 8100, thanks.
Comment 47 Alexandre Oliva 2004-08-27 08:02:24 EDT
This problem came back yesterday, as I upgraded to initscripts-7.70-1
in FC devel.  kernel is kernel-2.6.8-1.526 (latest in rawhide, like
everything else), and this kernel had been working just fine for the
past few days, before the initscripts update.

As it turned out, /etc/rc.d/rc.sysinit now modprobes a number of
modules early in the boot (Initializing hardware...) and, when it
loads the yenta_socket module, it sort-of hangs.  Keyboard input
ceases to be accepted, and the machine just sits there, but SysRq
still works, sort of.  It won't dump active processes/threads nor
memory, but it will let me reboot.  Not sure whether this is still
related with acpi, but it might very well be, since the old work
around, pci=noacpi, fixes it.

It doesn't print any relevant messages when it hangs, unfortunately.
Comment 48 Robert Moore 2004-09-02 15:51:49 EDT
But _STA itself does not return a value:
            Method (_STA, 0, NotSerialized) 
                STAL (0x60) 

Should be:
            Method (_STA, 0, NotSerialized) 
                Return (STAL (0x60)) 
Comment 49 Dave Jones 2005-04-21 22:44:53 EDT
wow, my oldest open bug :-)

Still around with latest packages ?
Comment 50 Alexandre Oliva 2005-05-12 01:23:18 EDT
Nope, it sort-of works now.  The catch is that pci=noacpi is still needed to get
reasonable network performance.  I guess the IRQs get messed up otherwise or
something like that, because NFS is insanely slow and often triggers `server not
responding' messages during an NFS install.  It's been like that for a few
Fedora releases already, and still happens in FC4test3.  With pci=noacpi,
networking works just fine AFAICT.

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