Bug 500214 - Kernel hang in rt61pci
Kernel hang in rt61pci
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: John W. Linville
Red Hat Kernel QE team
Depends On:
  Show dependency treegraph
Reported: 2009-05-11 13:26 EDT by Terry Griffin
Modified: 2009-09-11 10:51 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-11 13:14:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Strace of 'ifdown wlan0' showing hang in ioctl() call. (780.04 KB, text/plain)
2009-05-11 13:28 EDT, Terry Griffin
no flags Details

  None (edit)
Description Terry Griffin 2009-05-11 13:26:06 EDT
Description of problem:

The kernel hangs somewhere in the rt61pci driver stack during interface
configuration. The calling user-space program (typically ifconfig) pegs
the CPU and never returns suggesting the driver is blocked on a spin lock.
Debugging with strace shows the hang to be inside an ioctl() system call.

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

The problem was new in 2.6.18-128.1.6.el5 and is still present in

The problem was not present in kernel-2.6.18-128.el5.

How reproducible:


Steps to Reproduce:

1. On system with network card using the rt61pci driver. In my case
lspci reports:

06:00.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
        Subsystem: RaLink Unknown device 2561
        Flags: bus master, slow devsel, latency 64, IRQ 11
        Memory at 36000000 (32-bit, non-prefetchable) [size=32K]
        Capabilities: [40] Power Management version 2

2. Configure the wlan0 interface. In my case for a 802.11g WEP access
point and DHCP.

3. Bring the interface up using 'ifup wlan0'.

4. Bring the interface down using 'ifdown wlan0' (or perform some other
action on the wlan0 interface).
Actual results:

Kernel will hang in step #4. The calling user-space program will peg
the CPU.

Expected results:

No hang, no pegging of CPU, operation completes and returns to user

Additional info:

strace output from 'ifdown wlan0' is attached.
Comment 1 Terry Griffin 2009-05-11 13:28:31 EDT
Created attachment 343483 [details]
Strace of 'ifdown wlan0' showing hang in ioctl() call.
Comment 3 John W. Linville 2009-05-15 09:16:16 EDT
On a hunch, could you try the test kernels here?


Do they solve the problem w/ rt61pci?
Comment 4 John W. Linville 2009-05-15 19:55:58 EDT
Please try these instead:

Comment 5 Terry Griffin 2009-05-15 22:44:05 EDT
Reading #499999 it certainly looks like the same problem. Unfortunately I was unable to verify this with the test kernels. Both the bz499999test and
jwltest.87 test kernels fail to boot on my machine. They hang right after
the Red Hat nash start message.
Comment 6 John W. Linville 2009-05-18 13:23:32 EDT
That sounds like an initrd problem.  You might try installing the rpm again, or running mkinitrd manually...?
Comment 7 Terry Griffin 2009-05-19 00:02:51 EDT
No luck, but the post-nash hang was not quite what it seemed. I could see occasional blinks of the disk-activity light after the Red Hat nash start message so I decided to wait. Roughly five minutes later the boot process continued, but very slowly. It got as far as starting cpuspeed, but after that nothing. I let it sit for an hour then I gave up.

This was with a fresh install of the jwltest.87 kernel and manually created initrd.
Comment 8 John W. Linville 2009-06-11 09:42:28 EDT
Whatever that was, I doubt if it was caused by any jwltest patches. :-)

I have a jwltest.88 now, based on a later RHEL5 kernel.  Perhaps you could give that a try?
Comment 9 Terry Griffin 2009-06-11 12:33:16 EDT
Ahh, much better. Kernel jwltest.88 boots and I'm able to take the wireless interface up and down repeatedly without hanging the kernel.
Comment 10 John W. Linville 2009-06-11 13:14:00 EDT
Cool...5.4 should fix things for you... :-)

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