Bugzilla – Bug 115228
repeated unloading of ohci1394 locks the PowerBook pismo
Last modified: 2007-09-27 12:10:11 UTC
I will check this with beta 4 as soon as I can get it to download. When I have powersaved and pbbuttonsd running with suspend to memory set for closing the screen, it works fine when we are on battery power and will recover. When on AC power, however, suspend appears sucessful, but cannot be recovered from. When trying to recover from suspend, best that happens is getting a bunch of iptables messages on a black screen, but it is not possible to interrupt with keyboard, etc. Let me know what information you need regarding this.
does it work better if you unload ohci1394? my pismo locks up during system if its loaded. that worked better with sles9...
If I remove ohci1394 and ieee1394 it does work. On battery this isn't required.
Oddly, probably related, I can reliably hang the system after running this script a few times, regardless of if power is on or off. It always hangs on removing ohci1394 but sometimes takes a couple runs to reproduce it. #!/bin/bash echo "rmmod ohci1394" rmmod ohci1394 echo "rmmod ieee1394" rmmod ieee1394 echo "modprobe ohci1394" modprobe ohci1394 echo "modprobe ieee1394" modprobe ieee1394
Er, AC on or off, not power on or off, btw.
Puhh, I can't help here. this is a USB problem -> assigning to olh CC'ing pavel -> kernel/suspend
Well, if it is broken even on insmod/rmmod, no wonder it breaks during suspend. Why it depends on AC available I have no idea... perhaps timing is slightly changed?
this happens also with vanilla 2.6.13 and a minimal config.
works ok on a G4 and a pegasos.
bug still present in 2.6.16.
Does the controller of affected machines match PCI_DEVICE_ID_APPLE_UNI_N_FW == 0x0018? (Can be checked with "lspci; lcpci -n".)
yes, its 00:0e.0 Class 0c00: 106b:0018 (rev 01)
What if you allow for a pause between modprobe and rmmod? for ((i=0; i<9; i++)); do echo load; modprobe ohci1394; echo OK; sleep 9; echo unload; modprobe -r ohci1394; echo OK; sleep 1; done If this avoids the bug, then it is not specific to the PowerBook but actually the same as this upstream bug: http://bugzilla.kernel.org/show_bug.cgi?id=6706
Created attachment 94270 [details] build-pismo-ohci1394.sh if I load sungem first, then a few insmod/rmmod cycles are possible. Same is true for current Linus tree. if config_sungem=y, the second modprobe dies due to machine check in ohci1394_pci_probe() -> ohci_soft_reset(). if config_sungem=n, the first rmmod hangs the system as usual.
Created attachment 94271 [details] config-2.6.18rc2-pismo-minimal.txt
The upstream bug is fixed for me on x86 by 2.6.19-rc2, perhaps already by 2.6.18. "for ((i=0; i<9; i++));do echo $i; echo load; modprobe ohci1394 && echo unload && modprobe -r ohci1394 || break;done" works. Could you test 2.6.18 and if necessary 2.6.19-rc2, without and with CONFIG_SUNGEM?
A new related upstream bug was filed: http://bugzilla.kernel.org/show_bug.cgi?id=7431 "ohci1394 Oops after a rmmod/modprobe cycle" > When I 'rmmod ohci1394' and then 'modprobe ohci1394', I get a "Bus error" > message from modprobe and my backlight is set to full brightness.
Proposed patch: http://bugzilla.kernel.org/attachment.cgi?id=9407&action=view Please test.
makes no difference
the insmod/rmmod loop works ok with firewire-ohci with 2.6.23-rc8