Bug 233434 - rt73usb wireless driver causes general protection fault when unplugging USB wireless device
Summary: rt73usb wireless driver causes general protection fault when unplugging USB w...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-22 14:00 UTC by Daniel Berrangé
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version: 2.6.21-1.3228.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-23 18:29:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/messages from initial boot -> time of crash (50.96 KB, text/plain)
2007-03-22 14:03 UTC, Daniel Berrangé
no flags Details
lsusb output showing WLAN adapter details (10.45 KB, text/plain)
2007-03-22 14:04 UTC, Daniel Berrangé
no flags Details

Description Daniel Berrangé 2007-03-22 14:00:54 UTC
Description of problem:
Using an ASUS WL-167g USB WLAN adapter, which is based on the ralink rt73
chipset, I get a kernel fault when unplugging the device:

general protection fault: 0000 [1] SMP 
last sysfs file: /class/net/eth0/carrier
CPU 1 
Modules linked in: arc4 ecb blkcipher rc80211_simple rt73usb rt2x00lib mac80211
cfg80211 rt2x00debug crc_itu_t bridge autofs4 hidp rfcomm l2cap bluetooth sunrpc
nf_conntrack_ipv6 xt_state nf_conntrack nfnetlink xt_tcpudp ip6table_filter
ip6_tables x_tables video sbs i2c_ec button dock battery asus_acpi ac ipv6
parport_pc lp parport sr_mod cdrom snd_hda_intel snd_hda_codec snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq rtc_cmos rtc_core snd_seq_device rtc_lib
snd_pcm_oss k8temp forcedeth i2c_nforce2 pata_amd snd_mixer_oss hwmon shpchp
i2c_core snd_pcm serio_raw snd_timer snd soundcore snd_page_alloc pcspkr k8_edac
floppy edac_mc sg dm_snapshot dm_zero dm_mirror dm_mod sata_nv ata_generic
libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd
Pid: 178, comm: khubd Not tainted 2.6.20-1.2999.fc7 #1
RIP: 0010:[<ffffffff80313d03>]  [<ffffffff80313d03>] debugfs_remove+0x20/0xf0
RSP: 0018:ffff81012f7f5c70  EFLAGS: 00010206
RAX: ffff8101178b9f00 RBX: ffffffff8842c07c RCX: 0000000000000024
RDX: ffff8101178b8500 RSI: 0000000000000000 RDI: ffffffff8842c07c
RBP: ffff81012f7f5c80 R08: ffffffff88428d60 R09: ffff81012009cb60
R10: ffffffff802da05b R11: ffff81012fc00540 R12: 020000010cbd8041
R13: ffff81012f5b32b8 R14: ffff810121a40ce8 R15: ffff81012e506b60
FS:  00002aaaab676710(0000) GS:ffff81012fc0cd58(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00005555557665a0 CR3: 0000000000201000 CR4: 00000000000006e0
Process khubd (pid: 178, threadinfo ffff81012f7f4000, task ffff81012f7250c0)
Stack:  ffff8101178b9f48 ffff8101178b8500 ffff81012f7f5ca0 ffffffff883e501a
 ffff8101178b9f00 ffff8101178b9f00 ffff81012f7f5cc0 ffffffff88429c9b
 ffff8101178b8500 ffff8101178b9f00 ffff81012f7f5cf0 ffffffff8842aa0c
Call Trace:
 [<ffffffff883e501a>] :rt2x00debug:rt2x00debug_deregister+0x1a/0x80
 [<ffffffff88429c9b>] :rt73usb:rt73usb_free_dev+0x15/0x82
 [<ffffffff8842aa0c>] :rt73usb:rt73usb_disconnect+0x49/0x78
 [<ffffffff803d4b25>] usb_unbind_interface+0x47/0x87
 [<ffffffff803bacc8>] __device_release_driver+0x93/0xb3
 [<ffffffff803bb1d6>] device_release_driver+0x42/0x5a
 [<ffffffff803ba5c3>] bus_remove_device+0x92/0xa4
 [<ffffffff803b87b7>] device_del+0x1b4/0x229
 [<ffffffff803d255e>] usb_disable_device+0x7a/0xf2
 [<ffffffff803cecbc>] usb_disconnect+0xb7/0x14b
 [<ffffffff803cfb47>] hub_thread+0x3ae/0xb98
 [<ffffffff80263d40>] _spin_unlock_irq+0x2b/0x31
 [<ffffffff8029c2e2>] autoremove_wake_function+0x0/0x38
 [<ffffffff803cf799>] hub_thread+0x0/0xb98
 [<ffffffff8029c12f>] keventd_create_kthread+0x0/0x7c
 [<ffffffff80233581>] kthread+0xd7/0x10a
 [<ffffffff8025cfa8>] child_rip+0xa/0x12
 [<ffffffff80263d40>] _spin_unlock_irq+0x2b/0x31
 [<ffffffff8025c6bc>] restore_args+0x0/0x30
 [<ffffffff8024cc30>] run_workqueue+0x19/0x187
 [<ffffffff802334aa>] kthread+0x0/0x10a
 [<ffffffff8025cf9e>] child_rip+0x0/0x12


Code: 49 8b 44 24 38 48 85 c0 0f 84 bd 00 00 00 48 8d b8 e8 00 00 
RIP  [<ffffffff80313d03>] debugfs_remove+0x20/0xf0
 RSP <ffff81012f7f5c70>


Version-Release number of selected component (if applicable):
2.6.20-1.2999.fc7

How reproducible:
Always

Steps to Reproduce:
1. Plugin the USB device
2. Wait for udev magic to work & load the drivers
3. Unplug the USB device
  
Actual results:
general protection fault: 0000 [1] SMP 

Expected results:
Device is unregistered

Additional info:
Will attach system messages & lsusb output. I can easily reproduce so can
collect any more debug info which may be needed....

Comment 1 Daniel Berrangé 2007-03-22 14:03:37 UTC
Created attachment 150661 [details]
/var/log/messages  from initial boot -> time of crash

Comment 2 Daniel Berrangé 2007-03-22 14:04:59 UTC
Created attachment 150662 [details]
lsusb output showing  WLAN adapter details

NB, the device in question is:

Bus 002 Device 004: ID 0b05:1723 ASUSTek Computer, Inc.

Comment 3 John W. Linville 2007-03-22 17:42:41 UTC
Possibly related to bug 233345...

Comment 4 Ivo van Doorn 2007-03-22 21:29:50 UTC
The problem seems to revolve around the lines:
Mar 22 10:11:01 celery kernel: DebugFS rmdir on wiphy0 failed : directory not 
empty.
Mar 22 10:11:05 celery kernel: general protection fault: 0000 [1] SMP

For bug 233345 a similar thing is noted:
Mar 20 21:18:33 localhost kernel: DebugFS rmdir on wiphy0 failed : directory 
not empty.
Mar 20 21:18:33 localhost kernel: BUG: unable to handle kernel NULL pointer 
dereference at virtual address 0000007f

rt2x00 only creates a single debugfs directory, which is being closed at the 
last moment during deregister. The files that are being created inside that 
folder are all being removed before the folder is being removed.

Comment 5 John W. Linville 2007-03-22 21:37:49 UTC
Bug 233345 comment 3 says he didn't have debugfs mounted.  Is that 
significant?

Comment 6 Ivo van Doorn 2007-03-22 21:59:41 UTC
Don't think so, the same problem occurs while debugfs is mounted as well.

Comment 7 Ivo van Doorn 2007-04-12 17:42:38 UTC
Possible solution to this bug has been found, rt2x00debug_deregister was 
called with the reference to debugfs data which was never initialized,
but to make matters worse instead of the reference, the reference to the 
reference was passed.

That would be a very valid reason for the kernel to start panicking. ;)

The patch has gone into the rt2x00 git tree, I'll send an git-pull request so 
that the fix will go into wireless-dev and ould move further upstream.

Comment 8 John W. Linville 2007-04-24 18:24:55 UTC
FWIW, this is still not in FC6.netdev.10 or rawhide -- I will remedy 
that "soon"...

Comment 9 John W. Linville 2007-07-16 20:58:22 UTC
Does this problem persist w/ current rawhide kernels (e.g. 
kernel-2.6.23-0.29.rc0.git6.fc8 or later)?

Comment 10 Daniel Berrangé 2007-07-22 17:19:07 UTC
I don't have access to a rawhide box just at the minute, but testing on an
up2date Fedora 7 box I no longer get any kernel panic upon unplugging the
device. Verified both with debugfs mounted, and not mounted. In addition I can
actually see wifi networks & connect successfully with NetworkManager. Kernel
i'm running on this box is:

Linux macminilan 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT 2007 i686 i686
i386 GNU/Linux




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