rt2x00.serialmonkey.com

Support forum for the rt2x00 project
It is currently Fri Sep 10, 2010 7:33 am

View unanswered posts | View active topics


Board index » Legacy Driver Support » rt73 (usb) Legacy 802.11b/g MIMO Support

All times are UTC


Forum rules


Important: Read Project restructuring announcement regarding the pending removal of the legacy drivers from this project.



Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 3 of 7
  [ 97 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
  Print view Previous topic | Next topic 
Author Message
daniel_matthes
 Post subject:
PostPosted: Fri Jan 11, 2008 12:11 pm 
Offline

Joined: Thu Oct 25, 2007 12:21 pm
Posts: 50
Vern wrote:
Could you apply the attached patch (arm1.patch.gz) to a vanilla copy of the latest CVS, build with debug enabled, and try it on your ARM machine?


Done! I took the rt73-cvs-2008011104 version an patched it! The driver reads the MAC-Address correctly now.

The added line in rtmp.h

Code:
UCHAR         fill[3];


fixes the problem. THANX

I have attached the debug output, so you can see the working result.

But when I bring up the interface wlan0, I can read the scheduling BUG. Actually I get now performance problems by ignoring this bug, but l think it would be better to fix this bug.

Code:
~ # ifup wlan0
rt73: driver version - 1.0.3.6 CVS
rt73: net_device supplies MAC, activating this one
rt73: Active MAC is: 00:19:5b:74:bf:3e.
rt73: Local MAC = 00:19:5b:74:bf:3e
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345
BUG: scheduling while atomic: rt73/0x00000001/345


What could be the cause of the error?

Regards Daniel


Attachments:
File comment: debug output of modul rt73
debug_rt73.gz [4.55 KiB]
Downloaded 30 times
Top
 Profile  
 
Vern
 Post subject:
PostPosted: Fri Jan 11, 2008 5:36 pm 
Offline
User avatar

Joined: Sat Jan 14, 2006 6:29 pm
Posts: 897
Location: Carlsbad, California
Thanks. By any chance, does the latest CVS work *without* the patch?

(edit)
I've modified the Makefile (see arm2.patch.gz) to compile the ARM target with a structure alignment flag - more satisfactory than hacking the adapter control structure to (hopefully) pad to the right boundary. Could you also apply that to a vanilla copy of the latest CVS and see if that also helps?

Thanks,

(edit again)
Could you also attach a copy of the result of doing a "gcc -E -dM" (i.e. get the active compiler flags) for ARM?

Thanks again,


Attachments:
File comment: Makes with ARM-specific structure boundary flag.
arm2.patch.gz [692 Bytes]
Downloaded 38 times
Top
 Profile  
 
daniel_matthes
 Post subject:
PostPosted: Mon Jan 14, 2008 12:27 pm 
Offline

Joined: Thu Oct 25, 2007 12:21 pm
Posts: 50
Hi Vern

Here are my test results.

CVS work: rt73-cvs-2008011402

without patches --> the MAC address is wrong
inluding patch arm1 --> the MAC address is right
including patch arm2 --> the MAC address is wrong

A have attached the debug output.

Finally I have added the gcc flags to the Makefile in this way

Code:
arm:   
   @$(MAKE) $(KBUILD_PARAMS) 'EXTRA_CFLAGS=-mstructure-size-boundary=8 \
               -DRTMP_EMBEDDED \
               -I$(src) -E -dM' modules; \
   $(MODULE_CHECK)

armdebug:
   @$(MAKE) $(KBUILD_PARAMS) 'EXTRA_CFLAGS=-mstructure-size-boundary=8 \
               -DRTMP_EMBEDDED \
               -I$(src) -E -dM -DDBG' modules; \
   $(MODULE_CHECK)



and forwarded the 'make armdebug' output to 'debug_gcc_flags'
I think the output includes not the information that you want. Maybe I have added the flags at the wrong position???

Thanks for your help!

Regards Daniel


Attachments:
debug_latest_cvs_patch.tar.gz [8.19 KiB]
Downloaded 27 times
debug_latest_cvs.gz [4 KiB]
Downloaded 27 times
debug_gcc_flags.gz [292 Bytes]
Downloaded 26 times
Top
 Profile  
 
Vern
 Post subject:
PostPosted: Mon Jan 14, 2008 8:25 pm 
Offline
User avatar

Joined: Sat Jan 14, 2006 6:29 pm
Posts: 897
Location: Carlsbad, California
Hi daniel_matthes,

Looks like I was a little sloppy - as well as confusing - on my request for compilation constants. It should have been "gcc -E -dM", as in (assuming foo.c does not exist):
Code:
touch foo.c; gcc -E -dM foo.c|sort >armconst.txt

Also, it looks like I may have screwed up the alignment spec in the make file. The attached patch (in arm3.patch.gz) changes that. It may not make everything work, but it may result in providing the correct MAC address.

So, could you try to get the - hopefully more clearly explained - compilation constants, and a debug log of the results of applying the latest patch to a vanilla copy of the latest CVS?

Finally, in the interests of reducing turnarounds, if - and only if - you get the correct MAC address after applying arm3.patch.gz, could you go to the Makefile, uncomment the commented out arm:/armdebug: targets, comment out the current arm:/armdebug: targets, and see if that works?

Thanks,


Attachments:
File comment: 32 bit structure alignment for ARM.
arm3.patch.gz [738 Bytes]
Downloaded 32 times
Top
 Profile  
 
daniel_matthes
 Post subject:
PostPosted: Tue Jan 15, 2008 9:42 am 
Offline

Joined: Thu Oct 25, 2007 12:21 pm
Posts: 50
Hi Vern,

Thanks for your daily replies

At first I have attached the compilation constants for arm.

Further, I have tested the arm3.patch. Sorry, but I haven't good news. The MAC address is still wrong. I have also attached the debug output.

Thanks and Regards
Daniel


Attachments:
debugOutput_and_armConst.tar.gz [5.43 KiB]
Downloaded 31 times
Top
 Profile  
 
Vern
 Post subject:
PostPosted: Tue Jan 15, 2008 10:08 pm 
Offline
User avatar

Joined: Sat Jan 14, 2006 6:29 pm
Posts: 897
Location: Carlsbad, California
Hi daniel_matthes,

It looks like the ARM USB subsystem has a minimum alignment requirement for I/O, at least on the control pipe. The attached patch (arm4.patch.gz) is intended as a proof of hypothesis. The only intended result is to have a debug message displaying the proper MAC address. Line #1393 in rtmp.h has the meaningful mod.

There also seems to be a problem with WEP keys; so the patch also has debug code to get info on that, too.

If - and only if - there is a proper MAC address displayed, could you go to the Makefile, uncomment the commented out arm:/armdebug: targets, comment out the current arm:/armdebug: targets, and see if that works?

Thanks,

(edit)
If it doesn't work, could you try changing line#1393 of rtmp.h to align 8?

Thanks again,


Attachments:
File comment: Aligns MAC receiving area.
arm4.patch.gz [1.5 KiB]
Downloaded 35 times
Top
 Profile  
 
daniel_matthes
 Post subject:
PostPosted: Wed Jan 16, 2008 9:38 am 
Offline

Joined: Thu Oct 25, 2007 12:21 pm
Posts: 50
Hi Vern,

Here are my new test results.

I have patched the rt73-cvs-2008011602 with the last patch. The MAC address output is ok.
I have attached two debug output files. I've created the first by using WEP Keys and the second by using WPA2 keys.

Code:
rtusb init ====>
idVendor = 0x7d1, idProduct = 0x3c03
usbcore: registered new interface driver rt73
rt73: driver version - 1.0.3.6 CVS
rt73: Interface up for first time, activating permanent MAC
rt73: Active MAC is: 00:19:5b:74:bf:3e.
rt73: Local MAC = 00:19:5b:74:bf:3e
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257
BUG: scheduling while atomic: rt73/0x00000001/257


The scheduling bug is still displayed.

Vern wrote:
If - and only if - there is a proper MAC address displayed, could you go to the Makefile, uncomment the commented out arm:/armdebug: targets, comment out the current arm:/armdebug: targets, and see if that works?


Yes, I got the same result, by trying this.

Regards Daniel


Attachments:
debug_arm4patch.tar.gz [8.57 KiB]
Downloaded 27 times
Top
 Profile  
 
Vern
 Post subject:
PostPosted: Wed Jan 16, 2008 6:33 pm 
Offline
User avatar

Joined: Sat Jan 14, 2006 6:29 pm
Posts: 897
Location: Carlsbad, California
Hi daniel_matthes,

Thanks for the debug info and all the hard work. Last request (I promise - I think). Could you change line #1393 in the patched rtmp.h so that we have aligned(2) instead of aligned(4) and see if that works? The reason is that resources are constrained in embedded environments and we should save wherever we can, before the issue is forgotten.

After the alignment issue is put to bed, I'll take a look at the atomic scheduling stuff.

Thanks,
Top
 Profile  
 
daniel_matthes
 Post subject:
PostPosted: Thu Jan 17, 2008 8:23 am 
Offline

Joined: Thu Oct 25, 2007 12:21 pm
Posts: 50
Vern wrote:
Thanks for the debug info and all the hard work.


Don't mention it! It's also in my interest!

Vern wrote:
Change line #1393 in the patched rtmp.h so that we have aligned(2) instead of aligned(4) and see if that works?


Yes, that works!

Still one question. Do you include this changes to the CVS-Repository?

Regards Daniel


Attachments:
debug_aligned2.gz [5.55 KiB]
Downloaded 29 times
Top
 Profile  
 
Vern
 Post subject:
PostPosted: Thu Jan 17, 2008 5:57 pm 
Offline
User avatar

Joined: Sat Jan 14, 2006 6:29 pm
Posts: 897
Location: Carlsbad, California
Hi daniel_matthes,

You should see the changes soon in the hourly CVS tarball.

Thanks again for your work.
Top
 Profile  
 
daniel_matthes
 Post subject:
PostPosted: Mon Jan 21, 2008 3:37 pm 
Offline

Joined: Thu Oct 25, 2007 12:21 pm
Posts: 50
Hi Vern,

I've tested the rt73-cvs-2008012108 build. The MAC-address output is correct. Good job!

Is there any idea, how to fix the atomic scheduling bug?

Regards Daniel
Top
 Profile  
 
Vern
 Post subject:
PostPosted: Sat Jan 26, 2008 7:07 pm 
Offline
User avatar

Joined: Sat Jan 14, 2006 6:29 pm
Posts: 897
Location: Carlsbad, California
Hi daniel_matthes,

I'm having trouble getting a good fix on the atomic scheduling business. Could you do a debug run long enough to get the error, then attach a copy of /var/log/kern.log for that time period (making sure that /etc/syslog.conf routes debug priority messages there) to a posting here?

Thanks,
Top
 Profile  
 
daniel_matthes
 Post subject:
PostPosted: Tue Jan 29, 2008 12:45 pm 
Offline

Joined: Thu Oct 25, 2007 12:21 pm
Posts: 50
Vern wrote:
Could you do a debug run long enough to get the error, then attach a copy of /var/log/kern.log for that time period (making sure that /etc/syslog.conf routes debug priority messages there) to a posting here?


I've a problem, I use syslogd daemon from the busybox.The daemon ignores the file /etc/syslogd.conf. So I get only the /var/log/messages output. Is there another way to get the Informations or should I try to compile syslogd as stand alone for ARM

edit:

I've attached a copy of /var/log/messages. The driver was running without debug. You can find the bug output in the file.

Regards Daniel


Attachments:
messages.gz [1.1 KiB]
Downloaded 29 times
Top
 Profile  
 
Vern
 Post subject:
PostPosted: Tue Jan 29, 2008 5:54 pm 
Offline
User avatar

Joined: Sat Jan 14, 2006 6:29 pm
Posts: 897
Location: Carlsbad, California
Hi daniel_matthes,

Do debug messages also go unconditionally to /var/log/messages? If so, could you then run the driver with debug on, and attach a gzipped copy of the resulting /var/log/messages file to a posting here?

Thanks,
Top
 Profile  
 
daniel_matthes
 Post subject:
PostPosted: Wed Jan 30, 2008 12:06 pm 
Offline

Joined: Thu Oct 25, 2007 12:21 pm
Posts: 50
Hi,

I attached two copies of /var/log/messages. The first inludes the bug output. (but I don't now how I got this by playing with the dmesg levels) The second did not include the output. I don't know why? I can read it on terminal, of course.

Regards


Attachments:
messages.tar.gz [16.47 KiB]
Downloaded 29 times
Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 3 of 7
  [ 97 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

Board index » Legacy Driver Support » rt73 (usb) Legacy 802.11b/g MIMO Support

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group