RT73 lockup on Ubuntu Gutsy

Live forum: http://rt2x00.serialmonkey.com/viewtopic.php?t=4526

SingingWing

01-01-2008 14:09:18

I previously used the serialmonkeys RT73 CVS downloads to compile a version for Ubuntu Feisty and it worked just fine using a USB Belkin F5D9050. This uses a RT2671F chip.

Since upgrading to Gutsy (7.10) it will no longer work after a recompile. During the iwpriv wlan0 set WPAPSK= command the notebook locks up solidly needing a power reset. None of the CVS versions work including an archived version posted by Dannyboy on the Ubuntu forums and reputed to work. The result is always a locked computer whichever version is used.

I've narrowed it down to the length of key submitted to the iwpriv set WPAPSK command. I supply a hex WPA2PSK key and if I reduce the length of key it no longer locks up. It doesn't work of course since the key is wrong but it no longer locks. Almost like a string buffer overrun situation. I have determined that less than 58 hex chars is acceptable, 58 or more will cause instant lockup. My hex key for WPA2 is naturally exactly 64 chars long.

Any suggestions?
--
Steve

defcon

04-01-2008 02:19:07

I am having the same issue here with Ubuntu Gutsy and my belkin f5d7050 rt73, i can only use wep, wpa locks up system completely

Spy84464

04-01-2008 12:57:56

Hello,
defcon, if you set a shorter key, does the freeze still happen? Just to know if the behavior SingingWing described is reproducible on your box.

Regards,
Romain

defcon

04-01-2008 18:11:06

thanks for the prompt reply, i'll be testing this after work today

defcon

05-01-2008 09:23:40

awesome, im using a 20character passphrase and its working, now we know the issue, can it be fixed so I can use a longer passphrase?
Thanks!
Kyle

Vern

05-01-2008 20:36:20

SingingWing, defcon

The attached patch (in key641.patch.gz) is intended to catch what's going on when a 64 character key is attempted in your environments. It addresses some exception handling issues in the key handler, and fixes up some debug message misdirection that was keeping messages from always going where they should.

Could you apply it to a vanilla version of the latest CVS, compile with debug on, run with debug=15, and post a copy of your /var/log/debug file(s) here?

Thanks,

defcon

05-01-2008 20:40:22

sure, i'll be happy to assist you with that when I get home 5 hours from now from work, once this driver is fixed, tons of ppl will be happy, thanks for the hard work guys, you rock
Kyle

sefs

06-01-2008 06:50:27

Hi all

Someone also mentioned only using up to 20 characters over at launchpad and when I truncated my key down to 20 characters the hard lock went away while i was using wpa2+aes.

good stuff.

SingingWing

06-01-2008 20:14:48

SingingWing, defcon

The attached patch (in key641.patch.gz)

[SNIP]

Could you apply it to a vanilla version of the latest CVS, compile with debug on, run with debug=15, and post a copy of your /var/log/debug file(s) here?
[/quote24x8whmu]

Thanks Vern,

I have a debug log ready but it's large-ish, around 380k. Anywhere you'd like me to post it if it's too large for here?
--
Steve

defcon

06-01-2008 20:35:39

tar.gz it and attach it

SingingWing

06-01-2008 21:30:45

tar.gz it and attach it[/quotefd776srs]

OK here goes -

FWIW this is the console output during the kernel panic-

[codefd776srs][ 233.708000] kobject_add failed for :d-0000008 with -EEXIST, don't try to register things with the same name in the same directory.
[ 233.708000] Kernel panic - not syncing: Creation of kmalloc slab kmalloc_dma-2 size=2 failed.[/codefd776srs]
--
Steve

defcon

06-01-2008 21:31:52

I got the same exact error

Vern

07-01-2008 02:59:16

Hi SingingWing,

Well, your log shows code running in places it doesn't look like it should run (e.g. Set_AuthMode_Proc, Set_EncrypType_Proc). Also, I don't see any attempt there to set the encryption key.

Would it be possible to grep out the Oops from your kern.log (particularly the call trace and the Code line) and post it here?

Also, could you attach a file with a copy of the commands you're issuing to a posting here?

The attached patch - key642.patch.gz has some more exception handling and yet more trace statements. Could you try that, too?

Thanks,

wkpangleo

07-01-2008 17:30:17

My linux box Gutsy have the exact symptom as you with a RT73 chipset USB Wifi. But finally, i find a solution, see if it work on you.

1. AUTHMODE should use WPAPSK NOT WP2PSK
2. WPAPSK should use "ASCII-TEXT"


whole shell script:

ifconfig wlan0 up
iwconfig wlan0 ESSID "MY-ESSID"
iwpriv wlan0 set AuthMode=WPAPSK
iwpriv wlan0 set WPAPSK="ASCII-KEY"
iwpriv wlan0 set EncrypType=AES
iwconfig wlan0


Hope this can help.

I previously used the serialmonkeys RT73 CVS downloads to compile a version for Ubuntu Feisty and it worked just fine using a USB Belkin F5D9050. This uses a RT2671F chip.

Since upgrading to Gutsy (7.10) it will no longer work after a recompile. During the iwpriv wlan0 set WPAPSK= command the notebook locks up solidly needing a power reset. None of the CVS versions work including an archived version posted by Dannyboy on the Ubuntu forums and reputed to work. The result is always a locked computer whichever version is used.

I've narrowed it down to the length of key submitted to the iwpriv set WPAPSK command. I supply a hex WPA2PSK key and if I reduce the length of key it no longer locks up. It doesn't work of course since the key is wrong but it no longer locks. Almost like a string buffer overrun situation. I have determined that less than 58 hex chars is acceptable, 58 or more will cause instant lockup. My hex key for WPA2 is naturally exactly 64 chars long.

Any suggestions?
--
Steve[/quotefvd34uzo]

zero_knowledge

07-01-2008 21:38:52

Hi,

i don't have a solution for this, just a little hint for people experiencing freezes. To decrease the risk of data loss, you could try the magic sysrq key before powering off, if this feature is enabled in your kernel. See Documentation/sysrq.txt in the kernel sources for more.

It came quite handy for me more than once.

Best regards,
Lothar

defcon

08-01-2008 05:27:18

Here is my config that works well in gutsy with latest cvs
auto wlan0
iface wlan0 inet dhcp
pre-up ifconfig wlan0 up
pre-up iwconfig wlan0 essid myrouter
pre-up iwconfig wlan0 mode managed
pre-up iwpriv wlan0 set Channel=9
pre-up iwpriv wlan0 set AuthMode=WPAPSK
pre-up iwpriv wlan0 set EncrypType=TKIP
pre-up iwpriv wlan0 set WPAPSK=kljhsdfkjhsdfkjHSDKLFHkJSDHFkh
pre-up iwpriv wlan0 set TxRate=0
mtu 1500

SingingWing

08-01-2008 17:05:53

Hi SingingWing,
Well, your log shows code running in places it doesn't look like it should run (e.g. Set_AuthMode_Proc, Set_EncrypType_Proc). Also, I don't see any attempt there to set the encryption key.[/quote15aw7xnv]
Yes, it IS odd. You don't seen any attempt to set the key because the ../interfaces ifup script has that line commented out. The last thing I do is enter the key manually from a console. It panics immediately at that point and doesn't make any entry into the kern.log or debug.log files. I better check whether syslogd has buffering enabled and so has missed it. The panic message I posted is lifted directly from the console screen.
[quote15aw7xnv]Would it be possible to grep out the Oops from your kern.log (particularly the call trace and the Code line) and post it here?[/quote15aw7xnv]
Well the actual Oops doesn't appear - see above, but I can try increasing the debug level to show what leads up to it.. Will a grep on 'rt73' show the lines you want?
[quote15aw7xnv]Also, could you attach a file with a copy of the commands you're issuing to a posting here?[/quote15aw7xnv]
[code15aw7xnv] #from xxx/interfaces
auto wlan0
iface wlan0 inet dhcp
pre-up ifconfig wlan0 up
pre-up iwpriv wlan0 set SSID="Rxxxxxxxxx Dxxxxxxxxxxx"
pre-up iwconfig wlan0 mode managed
pre-up iwpriv wlan0 set AuthMode=WPA2PSK
pre-up iwpriv wlan0 set EncrypType=AES
# pre-up iwpriv wlan0 set WPAPSK=<64 char hex wpa2psk key>
[/code15aw7xnv]
This script worked OK on Feisty.

[quote15aw7xnv]The attached patch - key642.patch.gz has some more exception handling and yet more trace statements. Could you try that, too?,[/quote15aw7xnv]

Will do, and thanks for the support.
--
Steve

Vern

08-01-2008 23:17:40

Hi SingingWing,

Please try the attached patch - key643.patch.gz. It probably won't completely work, but it may not crash, either. (Pretty positive stuff, huh?)

Anyway,see what happens when you get to "iwpriv set WPAPSK=...".

Thanks,

SingingWing

09-01-2008 18:59:02

Thanks Vern,

I had an initial problem with the new code upon initialising the module WITHOUT entering the key, when the m/c froze. It only happened once and I haven't been able to repeat it. There are no routine such occurrences on this m/c.

Subsequent trials with the patched code have generated logs and no kernel panic.

I've attached debug & kern.log files.

Thanks again,
--
Steve

Vern

09-01-2008 19:59:14

Hi SingingWing,

First, thanks for doing all this testing work over the last week or so.

I have two questions

First, what's an m/c, and what did you observe when it froze?

Second, it sounds like you're saying that - aside from the m/c freeze - this is now working. Is it? Looking at your log info, it looks like it is. Are you able to do the things you normally expect to be able to to?

Thanks again,

SingingWing

09-01-2008 20:44:50

Aahh! I wasn't expecting it to actually work at this point! D It seems the AP had been reset since my last attempts and MAC filtering was enabled, thus my wlan MAC address wasn't accepted for routing.

Having corrected that, YES - it does indeed now work and I get a DHCP lease and routing. D

I've been somewhat distracted whilst doing this and haven't looked at the patches too closely - what did you have to change? Are you close to a fresh release?

A m/c is a machine/computer/PC etc. The freeze had no visible outward sign, no flashing keyboard lights, a static display, but simply zero response to the keyboard apart from the magic attn sequence. In previous kern-panics I got the usual flashing kb lights. I synced and rebooted, then noticed the Belkin adaptor was still inserted, yet I had no complaint from the auto initialisation.
I've had no recurrence.

You're very welcome to what time I've spent, it pales in comparison to yours...

best regards,
--
Steve

Vern

10-01-2008 02:38:02

Hi SingingWing,

The latest changes should by now be in CVS. Thanks again for your work. We'll declare victory and go home, provisionally, at least.

If by any chance you encounter the freeze problem again, could you try a ALT-Sysrq-p? That would at least give a register dump that might help us find out what's going on. The reason is that it would be nice if the driver is going to fail that it do so in a manner that leaves the system as a whole operable.

It seems that the heart of the problem is that somewhere along the line, the length value for the ioctl parameter stopped including the terminating null character, with the effect that occasionally there would be no null at the end of a string that had been copied into kernel space. When a driver then trustingly did a strlen(), it could wander off into the weeds.

Most of the changes simply fix up debug output so it actually goes to the debug file.

The changes that actually deal with the problem are to rtmp_info.c in the function Set_WPAPSK_Proc(), and the ioctl handler for RTPRIV_IOCTL_SET.

Thanks,

SingingWing

11-01-2008 10:55:01

Hi SingingWing,

If by any chance you encounter the freeze problem again, could you try a ALT-Sysrq-p? That would at least give a register dump that might help us find out what's going on.[/quote19tyzt0u]
Will do. It's been OK so far.

[quote19tyzt0u]Most of the changes simply fix up debug output so it actually goes to the debug file.[/quote19tyzt0u]
OK, Thanks
--
Steve

defcon

11-01-2008 12:58:17

hey, thanks allot guys for doing such a great job hacking this driver and getting it to work, im sure there will be allot of happy people!

maniqui

11-01-2008 21:27:23

Not sure if I understood what issue has been fixed...

Does this patch fix the problem of the computer totally freezing when trying to connect using RutilT in the exact moment the user introduce the wep/wpa key?

Also, is this patch already included in the latest rt73 CVS daily tarball?

I ask because a friend uninstalled the drivers and reinstalled the latest CVS tarball but the issue is still there the computer freezes when connectin using RutilT.

Thanks.

SingingWing

12-01-2008 18:27:17

It is intended to fix a kernel panic issue with the RT73 driver when invoking the iwpriv utility with the wpa key. It fixed the problem in my case but I wasn't using rutilt.

The latest CVS seems to include the patches.

I have just started using rutilt and DO now seem to have a problem with the system freezing but haven't had time to investigate further yet.
--
Steve

sefs

13-01-2008 02:17:21

Does this mean we can use longer keys again? like 63 char keys as before?

Thanks.

Vern

13-01-2008 18:39:08

Yes.

sefs

19-01-2008 12:40:43

What would i need to do to get the fix, just download and re-install the latest CVS?

sefs

20-01-2008 02:41:21

Just to alert....

Downloaded latest which unzips to folder rt73-cvs-2008011919. This version of the CVS still produces a hardlock with WPA2+AES and a key over 20 characters in length.

Vern

20-01-2008 02:49:25

Well, I might have missed a path. Does it happen with WPA, or just WPA2?

By hardlock, do you mean an oops, or no response from the console?

Could you compile and run with debug enabled? If you're getting an oops, please attach the relevant extract from /var/log/kern.log. Otherwise /var/log/debug is good enough.

Thanks,

zit

20-01-2008 02:49:40

Just to alert....

Downloaded latest which unzips to folder rt73-cvs-2008011919. This version of the CVS still produces a hardlock with WPA2+AES and a key over 20 characters in length.[/quote1ipinj4c]

yes me too (

ratulb

20-01-2008 20:21:48

Yup...this sounds very familiar cry

I'll try the non-RutilT approach and see what happens.

It is intended to fix a kernel panic issue with the RT73 driver when invoking the iwpriv utility with the wpa key. It fixed the problem in my case but I wasn't using rutilt.

The latest CVS seems to include the patches.

I have just started using rutilt and DO now seem to have a problem with the system freezing but haven't had time to investigate further yet.
--
Steve

zit

24-01-2008 22:49:45

Me with or without RutilT nothing change, computer freeze on kubuntu 7.10 / Linksys WUSB54GC / WPA .
And kernel panic on boot with dongle plugged (always wpa mode)

Is it possible is only a ubuntu bug?
What is your linux distribution?

spartan777

12-02-2008 00:36:51

i installed the rt73-cvs-2008021018 yesterday, and used rutilt to work my adapter. i have a linksys wusb54gr. ill show a video to make it easier, but i get this same lock up everyone's getting, even though im using wpa, not wpa2. My password is 11 regular characters long (not hex). HOWEVER, my computer doesn't freeze when i do the following; boot, login, unplug adapter, plugin adapter, initialize wireless w/ rutilt. everything works fine if i do that. if i keep my adapter plugged in, i always get the lock up.

the video [url2lvjmjtq]http://www.box.net/shared/4c76sfk840[/url2lvjmjtq]

also note that the status alternates between disconected and apparently connected in the beginning of the video. i don't know if this is a rutilt issue or what. also note that my ssid, minerhome, ends in gxiong, part of the ssid of our neighbors. this is obviously another bug, and one that goes away when i do the aforementioned reconnecting my adapter.

this message is to provide whatever information i can. i'd love to help get this bug resolved! and thanks a million to all the hackers who put so much into these drivers!

spartan777

12-02-2008 06:53:37

ok, it seems it was a coincidence that everything worked when i unplugged my adapter. my computer freezed about 7 times out of 8 when trying to connect. i can't find anything that could influence when it doesn't freeze.

its been a while since the previous posts, im wondering if this is still an issue for everybody else. anyone have the progress on this bug?

stevenk

16-02-2008 23:47:34

It happens to me as well.
I am using Gutsy 7.10 64bit AMD. While everything was OK before, using driver CVS 2008011205, when i updated to the new kernel and the new wicd version (both of them on the same update, so you can't know whose fault it is), the wireless stopped working.
Furthermore, if i boot with the usb adapter plugged in, the system waits indefinitely for something and presents me with a blank screen. If I boot with the adapter unplugged, the system boots normally. If i plug the adapter later on, the adapter finds all wireless networks, and reports connection to my network (my default network in wicd), although with link quality zero and no IP (which i set manually, anyway).
I downloaded then the latest CVS (2008021614), and now the adapter reports connected, 60 to 75 link quality (normal range), IP, AP, the works. But, still cannot even ping my router. I am using a 10 meter cable right now ?
It definitely has something to do with the new kernel, since I didn't saw people complaining about the new wicd..

Any ideas?

StevenK

spartan777

17-02-2008 22:53:44

i would be willing to compile my driver with debug and logging and whatnot if i knew that nobody had any information, however i was sure that somebody else had already done that and that things were being worked on.

anybody have any information on the status of the aforementioned issue? i'd be more than willing to do what i need to help.

lesshaste

12-03-2008 10:23:57

Did you try the full set of instructions at the end of https//bugs.launchpad.net/ubuntu/+bug/34902 ?

I had terrible problems with my Edimax rt73 usb dongle and after following points 1-18 from https//bugs.launchpad.net/ubuntu/+bug/ ... mments/177 it all works fine now.

lsusb gives me Bus 003 Device 002 ID 148f2573 Ralink Technology, Corp.

Raphael

thebaer

30-03-2008 18:28:43

Hy,
few days ago I upgraded from Dapper to Gutsy.I used a serialmonkey driver on Dapper Drake over a year without any problem (WPA mode), I really appreciate your work. Due to constant connection disconnects on Gutsy using the default rt73 driver I removed the modules and downloaded the serialmonkey driver a few hours ago (rt73-cvs-2008033009).
The installation went quite well but I'm facing the same problems as SingingWing had described earlier.
I get the same message on the console when i enter the wpapsk and my box just freezes and a hard reboot is necessary,

[quote1vcizytt][ 233.708000] kobject_add failed for d-0000008 with -EEXIST, don't try to register things with the same name in the same directory.
[ 233.708000] Kernel panic - not syncing Creation of kmalloc slab kmalloc_dma-2 size=2 failed.[/quote1vcizytt]

Does anyone have a clue?

alex_l

10-04-2008 11:48:07

I have the very same problem; dlink rt73-based usb adapter; with legacy driver i can't associate with my wpa2-psk enabled router, i'm using a 63 chars passkey and whenever i set the passphrase with iwpriv or rutilt ( tried 0.15 and latest 0.16), i get a super-hard freeze, even SysRq key doesn't respond. I tried also other key lengths such as 8 chars or 10+ chars, with the same result on two different computers, my main athlon xp3200 tower and an eeepc, both running Ubuntu Gutsy.

What I'm using to connect

[code3rl9zw6d] 1. iwpriv wlan0 set NetworkType=Infra
2. iwpriv wlan0 set AuthMode=WPA2PSK
3. iwpriv wlan0 set EncrypType=AES
4. iwpriv wlan0 set SSID="AP's SSID"
5. iwpriv wlan0 set WPAPSK="passkey"
6. iwpriv wlan0 set SSID="AP's SSID"
[/code3rl9zw6d]

[code3rl9zw6d] 1. iwconfig wlan0 mode managed
2. iwpriv wlan0 auth 4
3. iwpriv wlan0 enc 4
4. iwconfig wlan0 essid "AP's SSID"
5. iwpriv wlan0 wpapsk 12345678
6. iwconfig wlan0 essid "AP's SSID"
[/code3rl9zw6d]
even with RutilT ,i get the evil crash. For iwpriv usage i referred to iwpriv_usage.txt found in the driver tarball.

I'm available for testing, and hope to see this bug squashed soon.

Alex

[b3rl9zw6d]EDIT1[/b3rl9zw6d] I have two rt-73 usb adapters, usb ids

[code3rl9zw6d]07d1:3c03 D-Link System
148f:2573 Ralink Technology, Corp.[/code3rl9zw6d]
obviously both producing the same results.


[b3rl9zw6d]EDIT2[/b3rl9zw6d] from some days (2-3 maybe 4) cvs snapshots, networkmanager doesn't see the adapter, however with some hot-(un)plugging the adapter shows up in networkmanager and whener I try to connect I get the hard crash.


[b3rl9zw6d]EDIT3[/b3rl9zw6d]With latest snapshots i have to put up the interface manually with ifconfig.

Vern

11-04-2008 01:45:33

available for testing, and hope to see this bug squashed soon.[/quote2v04jmds]
Please compile with debug enabled, modprobe with "debug=15", and post a gzipped copy of the resulting /var/log/debug and /var/log/kern.log files here, if possible.

Thanks,

alex_l

11-04-2008 12:36:05

available for testing, and hope to see this bug squashed soon.[/quote2nnv0x9n]
Please compile with debug enabled, modprobe with "debug=15", and post a gzipped copy of the resulting /var/log/debug and /var/log/kern.log files here, if possible.

Thanks,[/quote2nnv0x9n]

Here the logs, thanks for looking into it.

Vern

12-04-2008 18:42:35

alex_l

Thanks for the log info. Unfortunately, I don't see any attempt there to set the key value. I've tried to replicate your bringup sequence - with some differences due to limitations in my environment - but can't reproduce the problem.

If you have sysrq enabled could you try to compile and run with debug enabled. When the keyboard lockup happens, do this[list1vezsiof]Enter ALT-sysrq-p. If a stack trace appears, snap a picture.
Enter ALT-sysrq-s
Enter ALT-sysrq-u
Enter ALT-sysrq-b[/listu1vezsiof]This should sync your disk(s), unmount them, then start a reboot.

When things recover, attach a gzipped copy of the picture (if available) and a gzipped copy of /var/log/kern.log (forget about /var/log/debug) to a posting here.

Thanks,

alex_l

12-04-2008 20:57:20

alex_l

Thanks for the log info. Unfortunately, I don't see any attempt there to set the key value. I've tried to replicate your bringup sequence - with some differences due to limitations in my environment - but can't reproduce the problem.

If you have sysrq enabled could you try to compile and run with debug enabled. When the keyboard lockup happens, do this[list36hfeomg]Enter ALT-sysrq-p. If a stack trace appears, snap a picture.
Enter ALT-sysrq-s
Enter ALT-sysrq-u
Enter ALT-sysrq-b[/listu36hfeomg]This should sync your disk(s), unmount them, then start a reboot.

When things recover, attach a gzipped copy of the picture (if available) and a gzipped copy of /var/log/kern.log (forget about /var/log/debug) to a posting here.

Thanks,[/quote36hfeomg]

Ok, I was able to take a picture of the kernel crash, unfortunately Alt+SysReq doesn't respond ( however it is enabled in kernel - i use it a lot).
This is what i did

compiled the module with [code36hfeomg]make debug[/code36hfeomg]

then unloaded beta drivers, loaded rt73.ko with debug=15 and put the interface up all with the script attached to to the archive in this post, along with the picture of the kernel messages in the console (had to run the script in single user mode, to watch at the console for the output.

The psk in the script is (obviously) an old key that i don't use anymore in my router. I tried also to load the module with debug=31, however no change in the error output.

Vern

13-04-2008 17:49:30

Hi alex_l,

Thanks for going the extra mile, here. I looked at the picture and I looked at your script; and I wonder if we may not have a module dependency problem here. Have you tried this using modprobe instead of insmod?

If you just do the "insmod" part, what happens when you then do "lsmod|egrep rt"? You should see something like this[code36gw4ukh]rt73 304736 0 (unused)
firmware_class 3852 0 [rt73][/code36gw4ukh]Do you?

If not, try "make modules_install", then "modprobe rt73 ...". (This puts the module in /lib/modules/uname -r`/extra and does a depmod *without* changing the content of the modules configuration directory).

If you then see both modules, try the remaining steps of your script and see what happens.

Thanks,

alex_l

13-04-2008 19:39:20

Hi alex_l,

Thanks for going the extra mile, here. I looked at the picture and I looked at your script; and I wonder if we may not have a module dependency problem here. Have you tried this using modprobe instead of insmod?

If you just do the "insmod" part, what happens when you then do "lsmod|egrep rt"? You should see something like this[codekvgzhltv]rt73 304736 0 (unused)
firmware_class 3852 0 [rt73][/codekvgzhltv]Do you?

If not, try "make modules_install", then "modprobe rt73 ...". (This puts the module in /lib/modules/uname -r`/extra and does a depmod *without* changing the content of the modules configuration directory).

If you then see both modules, try the remaining steps of your script and see what happens.

Thanks,[/quotekvgzhltv]

doing[codekvgzhltv]lsmod|egrep rt[/codekvgzhltv]

leads to this[codekvgzhltv]rt73 301184 0
parport_pc 37412 1
parport 37448 3 ppdev,lp,parport_pc
agpgart 35016 2 fglrx,nvidia_agp
usbcore 138632 11 rt73,snd_usb_audio,snd_usb_lib,xpad,pwc,usbhid,usb_storage,libusual,ehci_hcd,ohci_hcd
[/codekvgzhltv]

when loading rt73.ko from compilation dir and after [codekvgzhltv]make modules_install[/codekvgzhltv] as well; also, doing a [codekvgzhltv] modprobe firmware_class[/codekvgzhltv] gives
[codekvgzhltv]FATAL: Module firmware_class not found.[/codekvgzhltv]

D'OH!

However, loading the module with debug=31 gives this

[codekvgzhltv][ 3522.536125] rt73: init
[ 3522.536490] rt73: --> usb_rtusb_probe (2.6)
[ 3522.536494] rt73: idVendor = 0x7d1, idProduct = 0x3c03
[ 3522.536595] rt73: usb device name wlan0
[ 3522.536597] rt73: BulkOutMaxPacketSize 512
[ 3522.537186] rt73: rt73_get_ether_stats --->
[ 3522.537352] rt73: --> LoadFirmware
[ 3522.597572] rt73: 2048 bytes written to device.
[ 3522.598029] rt73: <-- LoadFirmware (status: 0, loaded: 2048)
[ 3522.598033] rt73: --> PortCfgInit
[ 3522.598036] rt73: <-- PortCfgInit
[ 3522.598037] rt73: --> RTMPInitAdapterBlock
[ 3522.598040] rt73: <-- RTMPInitAdapterBlock
[ 3522.598042] rt73: --> NICInitTransmit
[ 3522.598623] rt73: --> NICInitRecv
[ 3522.598740] rt73: <-- NICInitRecv status=0
[ 3522.598742] rt73: --> MlmeInit
[ 3522.598779] rt73: ==> MlmeInitMemoryHandler
[ 3522.599322] rt73: <== MlmeInitMemoryHandler Status=0
[ 3522.599351] rt73: <-- MlmeInit
[ 3522.599352] rt73: --> NICInitializeAsic
[ 3522.618632] rt73: BBP version = 22
[ 3522.632867] rt73: <-- NICInitializeAsic
[ 3522.632874] rt73: --> NICReadEEPROMParameters
[ 3522.639131] rt73: - Local MAC = 00:19:5b:8d:e8:2c
[ 3522.641376] rt73: E2PROM: Version = 1, FAE release #3
[ 3522.694944] rt73: Tx power for channel 1 : 0x18
[ 3522.694949] rt73: Tx power for channel 2 : 0x17
[ 3522.694951] rt73: Tx power for channel 3 : 0x17
[ 3522.694953] rt73: Tx power for channel 4 : 0x16
[ 3522.694955] rt73: Tx power for channel 5 : 0x15
[ 3522.694956] rt73: Tx power for channel 6 : 0x15
[ 3522.694958] rt73: Tx power for channel 7 : 0x14
[ 3522.694959] rt73: Tx power for channel 8 : 0x14
[ 3522.694961] rt73: Tx power for channel 9 : 0x14
[ 3522.694963] rt73: Tx power for channel 10 : 0x13
[ 3522.694964] rt73: Tx power for channel 11 : 0x13
[ 3522.694966] rt73: Tx power for channel 12 : 0x13
[ 3522.694968] rt73: Tx power for channel 13 : 0x13
[ 3522.694969] rt73: Tx power for channel 14 : 0x13
[ 3522.719665] rt73: Tx power for channel 36 : 0xff
[ 3522.719670] rt73: Tx power for channel 40 : 0xff
[ 3522.719672] rt73: Tx power for channel 44 : 0xff
[ 3522.719674] rt73: Tx power for channel 48 : 0xff
[ 3522.719675] rt73: Tx power for channel 52 : 0xff
[ 3522.719677] rt73: Tx power for channel 56 : 0xff
[ 3522.719679] rt73: Tx power for channel 60 : 0xff
[ 3522.719680] rt73: Tx power for channel 64 : 0xff
[ 3522.719682] rt73: Tx power for channel 100 : 0xff
[ 3522.719684] rt73: Tx power for channel 104 : 0xff
[ 3522.719685] rt73: Tx power for channel 108 : 0xff
[ 3522.719687] rt73: Tx power for channel 112 : 0xff
[ 3522.719689] rt73: Tx power for channel 116 : 0xff
[ 3522.719691] rt73: Tx power for channel 120 : 0xff
[ 3522.719692] rt73: Tx power for channel 124 : 0xff
[ 3522.719694] rt73: Tx power for channel 128 : 0xff
[ 3522.719696] rt73: Tx power for channel 132 : 0xff
[ 3522.719697] rt73: Tx power for channel 136 : 0xff
[ 3522.719699] rt73: Tx power for channel 140 : 0xff
[ 3522.719701] rt73: Tx power for channel 149 : 0xff
[ 3522.719703] rt73: Tx power for channel 153 : 0xff
[ 3522.719704] rt73: Tx power for channel 157 : 0xff
[ 3522.719706] rt73: Tx power for channel 161 : 0xff
[ 3522.719708] rt73: Tx power for channel 165 : 0xff
[ 3522.726037] rt73: Tx power for channel 34 : ffffffff
[ 3522.726044] rt73: Tx power for channel 38 : ffffffff
[ 3522.726046] rt73: Tx power for channel 42 : ffffffff
[ 3522.726048] rt73: Tx power for channel 46 : ffffffff
[ 3522.736402] rt73: E2PROM: G Tssi[-4 .. +4] = 255 255 255 255 - 255 -255 255 255 255, step=255, tuning=0
[ 3522.746770] rt73: E2PROM: A Tssi[-4 .. +4] = 255 255 255 255 - 255 -255 255 255 255, step=255, tuning=0
[ 3522.749014] rt73: E2PROM: RF freq offset=0x19
[ 3522.758002] rt73: <-- NICReadEEPROMParameters
[ 3522.758009] rt73: --> NICInitAsicFromEEPROM
[ 3522.758012] rt73: pAd->RfIcType = 2
[ 3522.758325] rt73: Use Hw Radio Control Pin=0; if used Pin=0;
[ 3522.758328] rt73: RFIC=2, LED mode=0
[ 3522.758330] rt73: <-- NICInitAsicFromEEPROM
[ 3522.758332] rt73: using permanent MAC addr
[ 3522.758334] rt73: - using permanent MAC addr
[ 3522.758336] rt73: Active MAC addr: 00:19:5b:8d:e8:2c
[ 3522.758338] rt73: Local MAC = 00:19:5b:8d:e8:2c
[ 3522.758341] rt73: - RTUSBWriteHWMACAddress: Local MAC = 00:19:5b:8d:e8:2c
[ 3522.759423] rt73: RTMPSetPhyMode(=0)
[ 3522.759428] rt73: country code=129/129, RFIC=2, PHY mode=0, support 13 channels
[ 3522.759430] rt73: channel # 1 2 3 4 5 6 7 8 9 10 11 12 13
[ 3522.759612] rt73: Exptected ACK rate[1] = 1 Mbps
[ 3522.759614] rt73: Exptected ACK rate[2] = 2 Mbps
[ 3522.759616] rt73: Exptected ACK rate[5] = 5 Mbps
[ 3522.759618] rt73: Exptected ACK rate[11] = 11 Mbps
[ 3522.759620] rt73: Exptected ACK rate[6] = 6 Mbps
[ 3522.759621] rt73: Exptected ACK rate[9] = 6 Mbps
[ 3522.759623] rt73: Exptected ACK rate[12] = 12 Mbps
[ 3522.759625] rt73: Exptected ACK rate[18] = 12 Mbps
[ 3522.759626] rt73: Exptected ACK rate[24] = 24 Mbps
[ 3522.759628] rt73: Exptected ACK rate[36] = 24 Mbps
[ 3522.759630] rt73: Exptected ACK rate[48] = 24 Mbps
[ 3522.759632] rt73: Exptected ACK rate[54] = 24 Mbps
[ 3522.759634] rt73: MlmeUpdateTxRates (MaxDesire=54, MaxSupport=54, MaxTxRate=54, Rate Switching =1)
[ 3522.759636] rt73: MlmeUpdateTxRates (TxRate=54, RtsRate=2, BasicRateBitmap=0x015f)
[ 3522.762638] rt73: AsicSetSlotTime(=9 us)
[ 3522.762719] rt73: - (CreateThreads) Mlme pid=15380, Cmd pid=15381
[ 3522.762722] rt73: <-- common_probe: Status = 0
[ 3522.762724] rt73: <-- usb_rtusb_probe: res=0
[ 3522.762895] usbcore: registered new interface driver rt73
[ 3522.766198] rt73: --> MlmeThread (2.6)
[ 3522.766337] rt73: --> RTUSBCmdThread (2.6)
[/codekvgzhltv]

So, maybe the firmware loading facility is statically compiled in the kernel, instead of being compiled as module (pure speculation).

Now i'm using ndiswrapper+winxp drivers because rt73usb is too unstable (D'OH! number 2).

Let me know if I can provide more help.

Alex

Vern

13-04-2008 22:43:23

Hi alex_l,

Thanks for your efforts.... as well; also, doing a
Code
modprobe firmware_class[/quotewdse4s03]What I asked for was[codewdse4s03]modprobe rt73[/codewdse4s03]That will bring in any dependencies.
[quotewdse4s03]So, maybe the firmware loading facility is statically compiled in the kernel, instead of being compiled as module (pure speculation).[/quotewdse4s03]Try[codewdse4s03]egrep FW_LOADER .config[/codewdse4s03]
Thanks,

alex_l

13-04-2008 23:00:57

Hi alex_l,

Thanks for your efforts.... as well; also, doing a
Code
modprobe firmware_class[/quote1gfopz82]What I asked for was[code1gfopz82]modprobe rt73[/code1gfopz82]That will bring in any dependencies.
[quote1gfopz82]So, maybe the firmware loading facility is statically compiled in the kernel, instead of being compiled as module (pure speculation).[/quote1gfopz82]Try[code1gfopz82]egrep FW_LOADER .config[/code1gfopz82]
Thanks,[/quote1gfopz82]

Yes, what i intended was that after doing 'make modules_install ' and 'modprobe rt73' the 'lsmod|egrep rt' output was the same as with 'insmod ./rt73.ko', with firmware_class not showing up;

'egrep FW_LOADER .config' in /usr/src/linux gives
[quote1gfopz82]CONFIG_FW_LOADER=y[/quote1gfopz82]

Vern

13-04-2008 23:13:43

So it looks like doing "modprobe rt73 ...", the driver comes up. What happens if you then try the remaining commands in your "legacy_up" script?

Thanks,

alex_l

14-04-2008 14:36:32

So it looks like doing "modprobe rt73 ...", the driver comes up. What happens if you then try the remaining commands in your "legacy_up" script?

Thanks,[/quote3l4hreyr]

I just tried replacing insmod with modprobe in the script, the result is the same hard crash.

Vern

14-04-2008 20:40:40

Hmm. What happens if you use 64 hex characters (0-9 and a-f, or A-F only) when you do the "set WPAPSK"?

alex_l

14-04-2008 23:35:38

Hmm. What happens if you use 64 hex characters (0-9 and a-f, or A-F only) when you do the "set WPAPSK"?[/quote2opp9ntz]

setting a 64 hex chars psk leads to the same crash with the same console output as seen in the picture.

Vern

16-04-2008 18:54:23

I run this variant of your "legacy_up" script (as root)[code1gka7fzl]#!/bin/bash

modprobe rt73 debug=15 ifname=wlan1;klogd -i
iwconfig wlan1 mode managed
ifconfig wlan1 up
iwconfig wlan1 essid "CCC"
iwpriv wlan1 set AuthMode=WPA2PSK
iwpriv wlan1 set WPAPSK="JumrMfgrphfCr5DktBpAASFXjEoetRJvXYqxjjXkUKv9RohjAPzo85VfEUpS9cp"
iwpriv wlan1 set EncrypType=AES[/code1gka7fzl]and do not get the problem.

Hail Mary! What happens if you log in as root and do likewise, instead of using sudo?

We're grabbing at straws, folks,

alex_l

17-04-2008 15:15:38

I run this variant of your "legacy_up" script (as root)[code2gs54qpc]#!/bin/bash

modprobe rt73 debug=15 ifname=wlan1;klogd -i
iwconfig wlan1 mode managed
ifconfig wlan1 up
iwconfig wlan1 essid "CCC"
iwpriv wlan1 set AuthMode=WPA2PSK
iwpriv wlan1 set WPAPSK="JumrMfgrphfCr5DktBpAASFXjEoetRJvXYqxjjXkUKv9RohjAPzo85VfEUpS9cp"
iwpriv wlan1 set EncrypType=AES[/code2gs54qpc]and do not get the problem.

Hail Mary! What happens if you log in as root and do likewise, instead of using sudo?

We're grabbing at straws, folks,[/quote2gs54qpc]

I tried your modified script from a root console, unfortunately the result is the same kernel crash and alt+sysrq not working.

Vern

18-04-2008 16:02:06

OK.

How about stack size? Is CONFIG_4KSTACKS set? If so, can you unset it, rebuild the kernel, and see what happens?

Thanks,

alex_l

19-04-2008 19:58:19

OK.

How about stack size? Is CONFIG_4KSTACKS set? If so, can you unset it, rebuild the kernel, and see what happens?

Thanks,[/quote2ecvitss]

'cat .config|grep CONFIG_4KSTACKS' gives
[code2ecvitss]
# CONFIG_4KSTACKS is not set
[/code2ecvitss]

Vern

23-04-2008 19:01:55

Hi alex_l,

(BTW, when you say sysrq, you do mean "ALT-sysrq-p", right?)

Just to refresh What is your machine, kernel, and adapter?

Thanks,

alex_l

24-04-2008 14:49:14

Every possible combination of alt+sysrq doesn't work, +p, +r, +e, +i and so on, my machine is an athlon xp 3200+, 2 gigs ddr400 ram, nforce2-ultra400 chipset and my adapter is an atlantis land A02-UP1-W54, usb id == '148f2573 Ralink Technology, Corp.'

Vern

25-04-2008 17:56:12

[code2tgn0s3p]id == '148f:2573 Ralink Technology, Corp.'[/code2tgn0s3p]is starting to become bothersome (see here[/url2tgn0s3p]). What happens if you try the rt2570 driver?

Thanks,

alex_l

28-04-2008 01:26:49

[code132iwkc3]id == '148f:2573 Ralink Technology, Corp.'[/code132iwkc3]is starting to become bothersome (see here[/url132iwkc3]). What happens if you try the rt2570 driver?

Thanks,[/quote132iwkc3]

rt2570 driver won't recognize the hardware, also, i physically unscrewed the usb stick and noticed the chipset, wich is labeled rt2571, however, now that i'm up and running with hardy, the legacy driver works with no lockups at all..however i still have to put up the interface manually and networkmanager doesn't recognize the ethernet adapter; are these two things worked on eventually?