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): kernel-2.4.21-20.1.2024.2.1.nptl How reproducible: Always 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:
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 hang: 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
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.
Created attachment 93170 [details] acpidmp output
Created attachment 93171 [details] dmidecode output Unfortunately, dmidecode doesn't seem to be able to extract information on this laptop :-(
does it boot (or can you load yenta_socket.o) with just pci=noacpi ?
Yes, booting with pci=noacpi is enough to work around the hang at yenta_socket.o load.
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 help.
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.
Looks like a problem wiht the ACPI interpreter to me. CONFIG_ACPI_DEBUG-enabled kernel should be helpful for debugging it.
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; ) http://www.csd.toshiba.com/cgi-bin/tais/su/su_sc_dtlViewDL.jsp?soid=356848&moid=1073769806&BV_SessionID=@@@@0349052097.1061221100@@@@&BV_EngineID=ccchadcjeemdelfcgfkceghdgngdglj.0&ct=DL
Created attachment 93717 [details] Dump$PIR table on current machine Usage: # make pirqdmp # ./pirqdmp
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.
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) } Else { If (LEqual (Arg0, 0x61)) { Store (\_SB.PCI0.FNC0.IRQB, Local0) } Else { If (LEqual (Arg0, 0x62)) { Store (\_SB.PCI0.FNC0.IRQC, Local0) } Else { Store (\_SB.PCI0.FNC0.IRQD, Local0) } } } If (LEqual (Local0, 0x80)) { Return (0x09) } Else { 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
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.
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.
Created attachment 93718 [details] Boot messages with a Severn kernel + CONFIG_ACPI_DEBUG=y
Created attachment 93719 [details] pirqdmp output (BIOS 2.30)
> 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) } Else { 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: http://www.nongnu.org/dmidecode/ If so, you might want to upgrade what is shipped in Severn.
Indeed, upgrading to 2.50 didn't change the boot messages in any way, and it still hangs the same.
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.
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.
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
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!
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.
acpi=off (or pci=noacpi) is still needed with kernel-2.4.22-20.1.2024.2.36.nptl
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 ready.
oops, meant to be logged in as me when i wrote that note...
Upcoming as in already available from the RHN Severn updates channel. It's supposed to be in the next Rawhide as well.
2097 kernel still hangs right after pcmcia services start (without rhgb).
*** Bug 104320 has been marked as a duplicate of this bug. ***
Err... I meant it still fails with acpi=on. With acpi=off (now the default), it works.
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?
can you try the patch in http://bugme.osdl.org/show_bug.cgi?id=1564
No change with the patch :-(
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.
Still present in both FC2 test 1 and 2.6.2-1.74.
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: [omitted] [...] handlers: [<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 :-(
why closed/rawhide?
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.
Bug 116205 is the one I alluded to in the previous comment.
Doh! Stupid me had pci=noacpi in the boot command line, which is why the problem appeared to be fixed. Sorry.
[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.
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
For the toshiba, please test the "ASL implicit return" workaround here: http://bugzilla.kernel.org/show_bug.cgi?id=1729 The Sony must be different root cause, as it still fails with acpi=off.
Fix verified on the Toshiba Tecra 8100, thanks.
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.
But _STA itself does not return a value: Method (_STA, 0, NotSerialized) { STAL (0x60) } Should be: Method (_STA, 0, NotSerialized) { Return (STAL (0x60)) }
wow, my oldest open bug :-) Still around with latest packages ?
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.