upgrading from AMD64 kernel 2.6.5-1 to 2.6.6-1-435 boot hangs kudzu ( bug# 126070 )

• Previous message: John Hearns: "Re: Building a Fedora Beowulf"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: <fedora-list@redhat.com>
Date: Wed, 16 Jun 2004 08:52:11 -0400

BUG # 126070

Bug Comments
Opened by (clyde) on 2004-06-15 14:54

>From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6)
Gecko/20040510

Description of problem:
eMachine T6000 AMD64 FC2 512MB

after upgrading from kernel 2.6.5-1 to 2.6.6-1-435 boot hangs kudzu (
checking for new hardware). Booted interactive mode with kudzu=n

Tried changing /etc/sysconfig/kudzu SAKE=yes, still no boot.

did a manual kudzu -s, and the process hangs. The reason is module
ohcil1394. ps -ax shows /sbin/modprobe -q -r ohcil1394. This is
hanging process kudzu. Temp workaround renamed module ieee1394.ko &
ohcil1395.ko and rebooted without problems. I have no devices attached
to the 1394 controllers.

kudzu -p

class: FIREWIRE
bus: PCI
detached: 0
driver: ohci1394
desc: "Texas Instruments|TSB12LV26 IEEE-1394 Controller (Link)"
vendorId: 104c
deviceId: 8020
subVendorId: 11bd
subDeviceId: 0805
pciType: 1
pcidom: 0
pcibus: 2
pcidev: c
pcifn: 0
-
class: FIREWIRE
bus: PCI
detached: 0
driver: ohci1394
desc: "VIA Technologies|IEEE 1394 Host Controller"
vendorId: 1106
deviceId: 3044
subVendorId: 1462
subDeviceId: 7410
pciType: 1
pcidom: 0
pcibus: 0
pcidev: e
pcifn: 0
-

lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host
Bridge (rev 01)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800
South]
00:06.0 PCI bridge: Intel Corp. 21152 PCI-to-PCI Bridge
00:07.0 Communication controller: Conexant HSF 56k HSFi Modem (rev 01)
00:0e.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80)
00:0f.0 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800
South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II]
(rev 78)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP
[Radeon 9600]
01:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon
9600] (Secondary)
02:04.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
02:08.0 Multimedia controller: C-Cube Microsystems E4? (rev b1)
02:0c.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394
Controller (Link)

Version-Release number of selected component (if applicable):

How reproducible:
Always

Steps to Reproduce:
1.boot
2.
3.

Actual Results: kudzu checking for new hardware freezes or hangs

Expected Results: kudzu should complete without hanging , it has a 30
second timer

Additional info:

------- Additional Comment #1 From Roger J. Allen on 2004-06-16
02:12 -------

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.

------- Additional Comment #2 From clyde on 2004-06-16 08:36 -------

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!!!!!

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

• Previous message: John Hearns: "Re: Building a Fedora Beowulf"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]