From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux) Description of problem: I initially described this bug in a post to fedora-list. http://www.redhat.com/archives/fedora-list/2003-October/msg00662.html That post described 3 problems I found on a Toshiba 5205-S5151. This one is the most serious. I have now re-installed from Fedora Core 0.95 and upgraded all components to their latest editions. The kernel is currently 2.4.22-1.2097.nptl. I then installed the nvidia drivers. After enabling acpi in /etc/grub.conf, the bootup and log-in processes slow down considerably because the firewire driver goes beserk. The boot process produces error messages like crazy, and logging into KDE also slows down (I think as a result of the device initialization step). I don't actually have any firewire devices so unfortunately I can't tell you if the port worked with or without acpi. The following is from my /var/log/messages file and is repeated several times. ohci1394_0: Unrecoverable error! ohci1394_0: Async Req Tx Context died: ctrl[ffffffff] cmdptr[ffffffff] ohci1394_0: Async Rsp Tx Context died: ctrl[ffffffff] cmdptr[ffffffff] ohci1394_0: Async Req Rcv Context died: ctrl[ffffffff] cmdptr[ffffffff] ohci1394_0: Async Rsp Rcv Context died: ctrl[ffffffff] cmdptr[ffffffff] ohci1394_0: Iso Xmit 0 Context died: ctrl[ffffffff] cmdptr[ffffffff] ... <snip /> ... ohci1394_0: Iso Xmit 31 Context died: ctrl[ffffffff] cmdptr[ffffffff] ohci1394_0: Iso Recv 0 Context died: ctrl[ffffffff] cmdptr[ffffffff] match[ffffffff] ... <snip /> ... ohci1394_0: Iso Recv 31 Context died: ctrl[ffffffff] cmdptr[ffffffff] match[ffffffff] ohci1394_0: Runaway loop while stopping context: ... ohci1394_0: Runaway loop while stopping context: ... ohci1394_0: Runaway loop while stopping context: reqTxComplete... ohci1394_0: Runaway loop while stopping context: respTxComplete... ohci1394_0: Runaway loop while stopping context: RQPkt... ohci1394_0: Runaway loop while stopping context: RSPkt... ohci1394_0: Error in reception of SelfID packets [0xffffffff/0x00000000] (count: 1) ohci1394_0: Set PHY Reg timeout [0xffffffff/0x00004000/100] ohci1394_0: Unhandled interrupt(s) 0xfe7cff0c The following line was generated in /etc/modules.conf if that's any help. alias ieee1394-controller ohci1394 I'll be able to provide any more information you require. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot the machine. 2. Watch the command line output from init or log in to KDE. Actual Results: Slowdown and many error messages generated. Additional info:
Using Fedora Core 1 (clean install) with latest updates and patches installed on a Toshiba 1135-S155 Laptop. Also have acpi=on. Sytem reacts very, very slowly or hangs when try to access firewire device (hdd) via SIIG 1394 2-Port Cardbus.
can you attach the /proc/interrupts? Can you test with Fedora Core2? thanks, -Len
Here's /proc/interrupts CPU0 0: 261617 XT-PIC timer 1: 2870 XT-PIC keyboard 2: 0 XT-PIC cascade 4: 118 XT-PIC usb-ohci 5: 157513 XT-PIC nvidia 6: 6707 XT-PIC usb-ohci 8: 1 XT-PIC rtc 9: 171 XT-PIC acpi 10: 2 XT-PIC ohci1394, Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support, Intel ICH3 11: 106841 XT-PIC ehci_hcd, Texas Instruments PCI1410 PC card Cardbus Controller, orinoco_cs 12: 66 XT-PIC PS/2 Mouse 14: 71064 XT-PIC ide0 NMI: 0 ERR: 0 Note I've upgraded to the latest Fedora Core kernel: uname -a Linux wazza2003.32geeks.com 2.4.22-1.2174.nptl #1 Wed Feb 18 16:38:32 EST 2004 i686 i686 i386 GNU/Linux Note that I've been running the system happily for some time now with the firewire and floppy drivers disabled. For the benefit of anyone else who might stumble across this thread and want to know how to do this, you can add the following to the start of /etc/modules.conf: alias ohci1394 off alias ieee1394 off alias floppy off
So that is the /proc/interrupts for acpi=on, ut 1394 disabled? Can you attach the /proc/interrupts for acpi=on and 1394 enabled (the failure mode) Can you attach the output from dmesg -s40000 for the same boot? Also, can you attach the /proc/interrupts from the acpi=off boot? Can you test with the Fedora Core *2* kernel? thanks, -Len
Created attachment 98596 [details] dmesg -s 4000 with acpi off
Created attachment 98597 [details] dmesg -s4000 with acpi on
Created attachment 98598 [details] /proc/interrupts with acpi on
Created attachment 98599 [details] /proc/interrupts with acpi off
> So that is the /proc/interrupts for acpi=on, ut 1394 disabled? Can you attach the /proc/interrupts for acpi=on and 1394 enabled (the failure mode) Can you attach the output from dmesg -s40000 for the same boot? The /proc/interrupts I initally posted was with acpi=on and ohci1394 and ieee1394 enabled. I've attached dmesg -s4000 with acpi on and off above. > Also, can you attach the /proc/interrupts from the acpi=off boot? I've attached dumps of /proc/interrupts with acpi both on and off above. > Can you test with the Fedora Core *2* kernel? Does it play nice with Fedora 1 and the 2.4 kernels? Can I just install kernel-2.6.1-1.65.i686.rpm from the Fedora 2 RPMs directory and it will work? Or would I need to upgrade things like kernel-utils and pcmcia?
Can you add a '0' to the parameter to dmesg -- should be 40000, not 4000 -- this will allow the log to go back to include the interesting part of system boot. Looking at the /proc/interrupts for acpi=off, it doesn't appear that ohci1394 is loaded -- so it isn't clear that we have an apples/apples acpi on/off comparison. Does ohci1394 behave with "acpi=off", or "acpi=on pci=noacpi", but not behave when "acpi=on"? If yes, this is an ACPI bug. If no, then it is something else. thanks, -Len
Created attachment 99024 [details] dmesg -s40000 with acpi off
Created attachment 99025 [details] dmesg -s40000 with acpi on
Created attachment 99026 [details] dmesg -s40000 with acpi on and pci=nnoacpi
Sorry about the delay and the truncation of those files. The new versions are hopefully what you're after. Ohci1394 seems to behave when acpi=off but I'm not sure that this is necessarily an acpi bug. Whenever I turn acpi off (either via acpi=off or acpi=on pci=noacpi), I lose networking, and probably other devices. I have read somewhere that the majority of the devices on the Toshiba laptops are available via acpi, and I suspect that the device isn't available without acpi. Hopefully you can figure this out from the dmesg output. I don't actually have any firewire devices, so I can't test it in any case.
Re: pci=noacpi and acpi=off cases -- OHCI still looks broken in this case: PCI: Enabling device 02:07.0 (0000 -> 0002) PCI: No IRQ known for interrupt pin A of device 02:07.0. Please try using pci=biosirq. PCI: Setting latency timer of device 02:07.0 to 64 ohci1394: Failed to allocate shared interrupt 0 Re: acpi=on case Yenta IRQ list 0000, PCI irq11 Socket status: 30000010 ti113x: Routing card interrupts to PCI ohci1394_0: Unrecoverable error! There is a yenta fix in vanilla 2.4.26 and 2.6.5 -- can you can test those? Re: testing w/ 2.6 Go here http://people.redhat.com/arjanv/2.6/RPMS.kernel/ rpm -Uvh modutils... rpm -Uvh mkinitrd... rpm -ivh kernel... (or for the kernel itself, you can get vanilla from http://kernel.org)
Created attachment 99437 [details] dmesg -s40000 with 2.6.5-1.322 and acpi on
OK. So I did the following: rpm -Uvh \ mkinitrd-3.5.15.1-2.i386.rpm \ modutils-2.4.26-9.i386.rpm \ lvm2-2.00.08-2.i386.rpm \ lvm-1.0.3-17.i386.rpm \ device-mapper-1.00.07-3.1.i386.rpm rpm -ivh \ kernel-2.6.5-1.322.i686.rpm \ kernel-source-2.6.5-1.322.i386.rpm Note that I didn't update initscripts, which appears to have an older version number (7.28), than what I have installed (7.42) by default with Fedora 1. There appeared to be a problem in the kernel postinstall, possibly involving the device mapper. Stupidly, I forgot to make a note of it. I rebooted, and reached runlevel 3 with the following errors (which I re-typed) appearing on the screen: Mounting USB filesystem: fgrep: /proc/bus/usb/drivers: No such file or directory Initializing USB HID interface : FATAL : Module hid not found Initializing USB keyboard: FATAL: Module keybdev not found Initializing USB mouse: FATAL: Module mousedev not found Starting cpuspeed: Error: Could not open file for writing: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Starting readahead_early: OK Checking for new hardwaremodprobe : FATAL: Error inserting floppy (/lib/modules/2.6.5-1.322/kernel/drivers/block/floppy.ko): Device or resource busy modprobe: FATAL: Module ide_probe_mod not found. modprobe: FATAL: Module mousedev not found. modprobe: FATAL: Module mousedev not found. modprobe: FATAL: Module ide_probe not found. modprobe: FATAL: FATAL: Error inserting floppy (/lib/modules/2.6.5-1.322/kernel/drivers/block/floppy.ko): Device or resource busy In addition to this kudzu thought my mouse had disappeared and my network card had changed, wanting to reconfigure the latter. I've attached the output of dmesg -s40000. Due to the NVIDIA/FC2 issues, I wasn't able to get X going. This is yet another person hoping that that gets resolved smartly, so that I can upgrade to FC2 not long after it comes out. Let me know if I can send you anything else.
still a problem with latest kernel update ?
I'm now using Suse 9.1 on the machine I was experiencing problems with, so am unable to test this. I haven't had any problems with Suse (kernel 2.6.5) so I suspect anything based on a recent 2.6 kernel should be fine. I'm unlikely to switch again in the near future, and never used the firewire in any case, so feel free to mark this bug as closed. Thank you for following this up so persistently.