crash on 2.6.23.9 x86_64 with ndiswrapper 1.51 and rtl8187
Status: Beta
Brought to you by:
pgiri
Menu
▾
▴
#218 crash on 2.6.23.9 x86_64 with ndiswrapper 1.51 and rtl8187
Hi,
the system is a Debian Sid (up to date), with kernel version 2.6.23.9-85.fc8, built for an Intel Core 2 Duo (x86_64).
I've tried other .23.* kernels with the same results.
The problem affect ndiswrapper 1.50 and 1.51 and if i remember correctly the 1.49 simply didn't support this kind of driver, i didn't try older versions.
The driver used is the one provided on the realtek site for the RTL8187L wireless card, version 1304_1119 (the newest available), but i tried also older ones with the same results.
After a few seconds from the module being loaded, the system presents a minor freeze, it's still somehow usable and cleanly rebootable, but it's impossible to unload the module (trying so will hang up the system, which enters in an endless loop waiting for a timeout from the driver and become impossible to shut down) or to use in any way the wireless card.
This is the kernel log and the trace that i obtain from the load of the ndiswrapper module:
ndiswrapper version 1.51 loaded (smp=yes, preempt=yes)
usb 1-3: reset high speed USB device using ehci_hcd and address 2
ndiswrapper (link_pe_images:576): fixing KI_USER_SHARED_DATA address in the driver
ndiswrapper: driver netrtuw_x64 (Realtek Semiconductor Corp.,10/23/2007,5.1304.1023.2007) loaded
wlan0: ethernet device 00:15:af:0d:f2:58 using NDIS driver: netrtuw_x64, version: 0x1, NDIS version: 0x500, vendor: 'Realtek RTL8187 Wireless LAN USB NIC ', 0BDA:8187.F.conf
wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
usbcore: registered new interface driver ndiswrapper
general protection fault: 0000 [1] PREEMPT SMP
CPU 0
Modules linked in: ndiswrapper snd_usb_audio snd_usb_lib snd_ice1724 snd_ice17xx_ak4xxx snd_ac97_codec ac97_bus snd_ak4114 snd_pt2258 snd_i2c snd_ak4xxx_adda snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_hda_intel snd_seq_midi snd_seq_midi_event snd_pcm_oss snd_mixer_oss snd_seq snd_rawmidi snd_hwdep snd_pcm snd_seq_device snd_timer pwc snd firewire_ohci firewire_core floppy snd_page_alloc soundcore
Pid: 2096, comm: ntos_wq Tainted: P 2.6.23.9-NeverLand #3
RIP: 0010:[<ffffc20000433806>] [<ffffc20000433806>]
RSP: 0018:ffff81007d5a7c08 EFLAGS: 00010202
RAX: 0000000000000007 RBX: ffffc20000485000 RCX: ffffc20000485000
RDX: ffffc200000795a0 RSI: ffffc200000795a0 RDI: ffffc20000485000
RBP: ffff81007d0b6000 R08: ffffc20000418000 R09: ffff81007d0b6000
R10: ffffffff88144280 R11: ffff81007d5a7ca0 R12: ffffc20000052000
R13: ffff81007d0b6004 R14: 0000000000000004 R15: 0000000000000010
FS: 0000000000000000(0000) GS:ffffffff806e4000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 0000000080050033
CR2: 00002aaaaad66aa0 CR3: 000000007ce44000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ntos_wq (pid: 2096, threadinfo ffff81007d5a6000, task ffff81007e283560)
Stack: 0000000000000000 0000000000000000 ffff81007d220000 0000000000000000
ffff81007d0b6000 ffffffff8025005d ffff81007d223100 ffffc200003843c8
0000000300000003 ffff81007d220007 0000000000000007 0000000000000000
Call Trace:
[<ffffffff8025005d>] param_sysfs_setup+0xd/0x120
[<ffffffff88150000>] :ndiswrapper:USBD_CreateConfigurationRequestEx+0x30/0x1b0
[<ffffffff88146027>] :ndiswrapper:IofCompleteRequest+0x47/0x180
[<ffffffff88145530>] :ndiswrapper:IoAcquireCancelSpinLock+0x10/0x20
[<ffffffff88146067>] :ndiswrapper:IofCompleteRequest+0x87/0x180
[<ffffffff8814fe90>] :ndiswrapper:wrap_urb_complete_worker+0x0/0x120
[<ffffffff8814fe90>] :ndiswrapper:wrap_urb_complete_worker+0x0/0x120
[<ffffffff8814fed8>] :ndiswrapper:wrap_urb_complete_worker+0x48/0x120
[<ffffffff8024dd39>] run_workqueue+0x89/0x120
[<ffffffff8024e860>] worker_thread+0x0/0x110
[<ffffffff8024e903>] worker_thread+0xa3/0x110
[<ffffffff80252360>] autoremove_wake_function+0x0/0x30
[<ffffffff8024e860>] worker_thread+0x0/0x110
[<ffffffff8024e860>] worker_thread+0x0/0x110
[<ffffffff80251f5b>] kthread+0x4b/0x80
[<ffffffff8020cbd8>] child_rip+0xa/0x12
[<ffffffff80251f10>] kthread+0x0/0x80
[<ffffffff8020cbce>] child_rip+0x0/0x12
Code: 66 0f 7f 74 24 70 0f 28 74 24 20 74 17 49 8d 4b 98 66 0f 7f
RIP [<ffffc20000433806>]
RSP <ffff81007d5a7c08>
Loading the module in init 1 seems to work without errors:
ndiswrapper version 1.51 loaded (smp=yes, preempt=yes)
usb 1-3: reset high speed USB device using ehci_hcd and address 2
ndiswrapper (link_pe_images:576): fixing KI_USER_SHARED_DATA address in the driver
ndiswrapper: driver netrtuw_x64 (Realtek Semiconductor Corp.,10/23/2007,5.1304.1023.2007) loaded
wlan0: ethernet device 00:15:af:0d:f2:58 using NDIS driver: netrtuw_x64, version: 0x1, NDIS version: 0x500, vendor: 'Realtek RTL8187 Wireless LAN USB NIC ', 0BDA:8187.F.conf
wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
usbcore: registered new interface driver ndiswrapper
but as soon as the interface is turned on (with ifconfig wlan0 up) i obtain this other error on whatever operations are done on the card (even simply calling a plain iwconfig):
ndiswrapper (iw_get_network_type:258): getting network type failed: C0000001
and again it become impossible to unload the module, with the same problems pointed before.
The only difference in the two situations seems to be the presence of the udev daemon running, i've done some tests and it seems that this is the only significant difference.
With udev running, the loading of the module results in the trace posted before, without it running instead it only presents the second error.
I only once managed somehow to make the card works, and it worked perfectly, i did so loading the module in init 1 and than switching to a normal mode, but i was unable to reproduce this single occasion in any other time, so i really don't know what could have been the difference.
Anyway this could mean that the problem is something trivial and there is hope :-)
In the meantime (a few months) i performed many upgrades of the system, but the problems remained always the same.
Let me know if i can provide any other informations or if i can do any other tests.
Thank you.
Logged In: YES
user_id=918798
Originator: NO
Provide debug trace (see wiki entry Bugs) with 'DEBUG=2 USB_DEBUG=1 IO_DEBUG=1' options.
And you are using Fedora kernel (2.6.23.9-85.fc8) with Debian?
complete debug trace
Logged In: YES
user_id=1979523
Originator: YES
Hi,
i've attached the debug trace as a gzipped text file to the bug report, it's huge, it's the complete trace, you can easily find the interesting part starting from the end of the file.
Yes, i use a Fedora kernel on Debian, i take the SRPM and prepare it with 'rpmbuild -bp --target=x86_64', then i compile it just like a normal kernel.
File Added: orcodio3.txt.gz
Logged In: YES
user_id=918798
Originator: NO
It looks like the crash is due to a URB being delayed (urb 4101 is completed after urb 4319). Try a different kernel (debian kernel, for example). I believe RT8187L is known to work.
Logged In: YES
user_id=918798
Originator: NO
When collecting debug trace, don't do so while using console ('init 1'); most of the CPU then is spent on printing the trace on console. Instead, load module when using X; after the crash, reboot and then collect the trace from kernel messages in /var/log.
You may also want to try different (vanilla) kernels.
complete debug trace (Debian 2.6.23-2 kernel)
Logged In: YES
user_id=1979523
Originator: YES
Hi,
It's what i just did for the previous debug trace, thanks for the hint anyway :-)
As i said in the first post, i already tried other kernels (vanilla/Debian/Fedora), all of them .23* however.
Ok, now i just tried with the current Debian one (2.6.23-2 - gcc version 4.2.3 20080102 (prerelease) (Debian 4.2.2-5) ), i'll attach the new debug trace with this comment, but the situation seems the same.
Thank you.
File Added: orcodio4.txt.gz
Logged In: YES
user_id=918798
Originator: NO
Both seem to happen due to the same issue: A URB is completed much later than normal. If you are (not) using ehci, try without (with) it and see if that helps.
Without something specific that points to an issue in ndiswrapper, I can't really do much about it. Sometimes issues in Linux kernel (usb drivers) affect how the devices behave, so you may want to try other versions of kernels.
Logged In: YES
user_id=1979523
Originator: YES
I tried with some more conservative kernel configurations, also with your suggestion regarding ehci, but nothing has changed so far.
I will try with other kernel versions in the near future, maybe i'll wait until there will be a stable 2.6.24.
Thank you for your help, i'll let you know if there will be any positive news.
I'm having the same issue with an RTL8187 (Repackaged by ASUS's P5W DH Deluxe mb) running 64-bit Debian (Lenny/testing)
Kernel: 2.6.24-1-amd64.
ndiswrapper v1.53
Driver: RTL's version 1313 for WinXP 64
Would some debug output from my system be helpful? I could try and find the time to collect some.
In any case, I'd appreciate an update on this matter.
Thanks
possibly fixed with rev. 2722, error in win2lin stubs -- but maybe I'm totally wrong with this guess
if someone encounters this problem again, please create a new report