|
Bugzilla – Full Text Bug Listing |
| Summary: | repeated unloading of ohci1394 locks the PowerBook pismo | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Leah Cunningham <leah> |
| Component: | Kernel | Assignee: | Olaf Hering <ohering> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | stefan-r-nvbz |
| Version: | Beta 4 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
build-pismo-ohci1394.sh
config-2.6.18rc2-pismo-minimal.txt |
||
|
Description
Leah Cunningham
2005-09-04 16:17:51 UTC
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 |