Bug 107666 - firewire (ohci) goes wild on toshiba when acpi on
firewire (ohci) goes wild on toshiba when acpi on
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-21 16:27 EDT by Warren Hedley
Modified: 2015-01-04 17:03 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-07 00:46:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg -s 4000 with acpi off (3.75 KB, text/plain)
2004-03-16 23:28 EST, Warren Hedley
no flags Details
dmesg -s4000 with acpi on (3.83 KB, text/plain)
2004-03-16 23:28 EST, Warren Hedley
no flags Details
/proc/interrupts with acpi on (685 bytes, text/plain)
2004-03-16 23:38 EST, Warren Hedley
no flags Details
/proc/interrupts with acpi off (421 bytes, text/plain)
2004-03-16 23:38 EST, Warren Hedley
no flags Details
dmesg -s40000 with acpi off (12.63 KB, text/plain)
2004-03-31 22:54 EST, Warren Hedley
no flags Details
dmesg -s40000 with acpi on (15.26 KB, text/plain)
2004-03-31 22:55 EST, Warren Hedley
no flags Details
dmesg -s40000 with acpi on and pci=nnoacpi (14.19 KB, text/plain)
2004-03-31 22:56 EST, Warren Hedley
no flags Details
dmesg -s40000 with 2.6.5-1.322 and acpi on (12.51 KB, text/plain)
2004-04-15 00:40 EDT, Warren Hedley
no flags Details

  None (edit)
Description Warren Hedley 2003-10-21 16:27:10 EDT
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:
Comment 1 fedora user 2003-12-18 03:07:45 EST
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.
Comment 2 Len Brown 2004-03-12 22:39:06 EST
can you attach the /proc/interrupts?
Can you test with Fedora Core2?

thanks,
-Len
Comment 3 Warren Hedley 2004-03-15 22:45:16 EST
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



Comment 4 Len Brown 2004-03-15 23:22:23 EST
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 
 
Comment 5 Warren Hedley 2004-03-16 23:28:05 EST
Created attachment 98596 [details]
dmesg -s 4000 with acpi off
Comment 6 Warren Hedley 2004-03-16 23:28:52 EST
Created attachment 98597 [details]
dmesg -s4000 with acpi on
Comment 7 Warren Hedley 2004-03-16 23:38:04 EST
Created attachment 98598 [details]
/proc/interrupts with acpi on
Comment 8 Warren Hedley 2004-03-16 23:38:57 EST
Created attachment 98599 [details]
/proc/interrupts with acpi off
Comment 9 Warren Hedley 2004-03-16 23:40:37 EST
> 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? 
Comment 10 Len Brown 2004-03-24 16:50:11 EST
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 
Comment 11 Warren Hedley 2004-03-31 22:54:34 EST
Created attachment 99024 [details]
dmesg -s40000 with acpi off
Comment 12 Warren Hedley 2004-03-31 22:55:16 EST
Created attachment 99025 [details]
dmesg -s40000 with acpi on
Comment 13 Warren Hedley 2004-03-31 22:56:09 EST
Created attachment 99026 [details]
dmesg -s40000 with acpi on and pci=nnoacpi
Comment 14 Warren Hedley 2004-03-31 23:01:32 EST
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.
Comment 15 Len Brown 2004-04-11 02:49:13 EDT
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) 
 
Comment 16 Warren Hedley 2004-04-15 00:40:35 EDT
Created attachment 99437 [details]
dmesg -s40000 with 2.6.5-1.322 and acpi on
Comment 17 Warren Hedley 2004-04-15 00:46:37 EDT
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.
Comment 18 Dave Jones 2004-11-21 16:02:52 EST
still a problem with latest kernel update ?
Comment 19 Warren Hedley 2004-11-21 18:27:58 EST
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.

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