Bug 126070
Summary: | (FIREWIRE) Boot Hangs AMD64 FC2 kernel-2.6.6-1.435 (kudzu) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | clyde <lbranch1> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | lbranch1, pfrields, rja |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-12-02 04:53:01 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
clyde
2004-06-15 18:54:30 UTC
I had the same problem on different hardware and worked around it. The quick tip is to try adding: alias ieee1394-controller ohci1394 to /etc/modprobe.conf and rename the 1394 modules back to their original names. Then after the next reboot, they will get loaded by /etc/rc.sysinit, and kudzu will not have to try to remove the ohci1394 module when it probes. Here's how I came to that conclusion. When I read your bugzilla report, I decided to disable the "onboard 1394" in the bios (Soyo KT600 Dragon Ultra Platinum x86, NOT x86_64) instead of renaming the modules. I forgot that I had a Creative Audigy2 ZS Platinum, which also has 1394 firewire. When it booted, kudzu found the Creative 1394 and configured it as fw-host0, updated /etc/sysconfig/hwconf, and added the ieee1394-controller alias to /etc/modprobe.conf. While testing, I also plugged a BUSlink DVD+-RW/+-R USB/Firewire drive into the Creative 1394 port, so that may have had something to do with getting it to work. In any case, after that worked, I shutdown, re-enabled the onboard 1394, and rebooted. Then, kudzu found the Via 1394 and configured that into hwconf. The both show up in dmesg as: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[11] MMIO=[e9116000-e91167ff] Max Packet=[2048] ohci1394: fw-host1: OHCI-1394 1.0 (PCI): IRQ=[10] MMIO=[e9119000-e91197ff] Max Packet=[2048] Those should be two lines beginning with ohci1394: Notice that the Creative 1394 is a 1.1 while the Via 1394 is a 1.0. I tested it a few different ways, and found that if the Via 1394 was disabled, and the Creative 1394 was being used by the ohci1394 module, that I could: rmmod ohci1394 and the module would be removed. If the Via 1394 was enabled in the bios, then the rmmod would just sit there. I could not find a way to kill it, but the system was not hung, so either ctrl-alt-del or open another window to shutdown. So, it looks to me like the ohci1394 module has a problem releasing my: 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) but it works fine with my: 00:0b.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04) If anyone needs more info, like lspci, dmesg, syslog, etc. let me know. used your work around as above, worked like a champ, thanks for the help. Appears the module ohcil1394 does have a problem with the onboard VIA 1394 (Texas Instruments|TSB12LV26 IEEE-1394 Controller) or some type of mapping when you go from the kernel-2.6.5-1 and then update to kernel-2.6.6-1. Set /etc/sysconfig/kudzu SAFE=no. Rebooted several times both modules ieee1394 & ohcil1394 loads OK. Wish I had a device to attach and try both the TI & VIA 1394 controller. Everything I have extra uses USB devices, DVD RW, external disks etc...... Anyway again many thanks for the help!!!!! mass update for old bugs: Is this still a problem with the 2.6.9 based update kernel ? |