rt73 on ARM without hotplug or udev

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

daniel_matthes

25-10-2007 12:43:01

Hello,

I have the task to get run the USB wireless adapter DWL-G122 on a Linux ARM System. I have crosscompiled the rt73 driver without any error.

insmod /lib/modules/'uname -r'/extra/rt73.ko results

[i30isag0n]rtusb init ====>
idVendor = 0x7d1, idProduct = 0x3c03
rt73 [b30isag0n]Failed to request_firmware. Check your firmware file location[/b30isag0n]
rt73 probe of 1-11.0 failed with error -2
usbcore registered new interface driver rt73 [/i30isag0n]

so I read here, I have to use udev or hotplug to fix this problem. But I got the rule to release this problem without this tool.

Is someone able to give me help, which steps i've to be observed.

- create a device link
- load the firmware manually

hennichodernich

26-10-2007 06:51:38

so I read here, I have to use udev or hotplug to fix this problem.[/quote14fkfa4i]
Correct.
But I got the rule to release this problem without this tool.[/quote14fkfa4i]
Who made that rule? Your boss?

- create a device link
[/quote14fkfa4i]
What do you mean by that? A device _node_? You won't need one.

- load the firmware manually[/quote14fkfa4i]
You could try that, run
[code14fkfa4i]echo 1 > /sys/$DEVPATH/loading
cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading
[/code14fkfa4i]
by hand. You'll have to get the variables (and the timing!) right, that's why this action is usually triggered by udev or hotplug.

The other possibility is to rewrite the driver source to have the firmware compiled in. I remember some guy mentioning this in one of these forums.

Should be no big deal if it's a commercial project you're working on.

regards
Henning

Viper

04-11-2007 23:38:06

Hello,

I have the task to get run the USB wireless adapter DWL-G122 on a Linux ARM System. I have crosscompiled the rt73 driver without any error.

insmod /lib/modules/'uname -r'/extra/rt73.ko results

[ipzlgp77l]rtusb init ====>
idVendor = 0x7d1, idProduct = 0x3c03
rt73 [bpzlgp77l]Failed to request_firmware. Check your firmware file location[/bpzlgp77l]
rt73 probe of 1-11.0 failed with error -2
usbcore registered new interface driver rt73 [/ipzlgp77l]

so I read here, I have to use udev or hotplug to fix this problem. But I got the rule to release this problem without this tool.

Is someone able to give me help, which steps i've to be observed.

- create a device link
- load the firmware manually[/quotepzlgp77l]
Did you manage to do this? I'm facing nearly the same problem, but I cannot compile the module ( /for 2.6.22/

Vern

05-11-2007 20:21:23

Hi daniel_matthes,

Please provide the following info
* driver version (including the date if it's a CVS build)
* hardware description - CPU, adapter Mfr. & model, AP if known.
* distrobution name and version
* kernel version

Thanks,

daniel_matthes

06-11-2007 12:38:10

Hello everybody,

@Vern

driver version (including the date if it's a CVS build)[/quote1k15n5h9]
driver version rt73-cvs-2007101206

hardware description - CPU, adapter Mfr. & model, AP if known.[/quote1k15n5h9]
CPU AT91RM9200
adapter DWL-G122 H/W C1
AP DWL-900AP+

distrobution name and version[/quote1k15n5h9]
self compiled linux kernel, no known distribution

kernel version[/quote1k15n5h9]
kernel-version 2.6.19

Now I would describe you my current progress.

[b1k15n5h9]1. Compiling the wlan driver for my debian lenny distribution with linux kernel 2.6.22[/b1k15n5h9]

make, make install with no warnings and errors
modprobe rt73 with no errors
ifup wlan0 with no errors

[b1k15n5h9]wlan-adapter works perfectly including WEP encryption[/b1k15n5h9]

[b1k15n5h9]2. Create Makefile for the embedded Linux System, based on the original
[/b1k15n5h9]
[quote1k15n5h9]
# Tool names
ARCH = arm
CROSS_COMPILE = ${ARCH}-linux-
AS = ${CROSS_COMPILE}as
AR = ${CROSS_COMPILE}ar
CC = ${CROSS_COMPILE}gcc
CPP = ${CC} -E
LD = ${CROSS_COMPILE}ld
NM = ${CROSS_COMPILE}nm
OBJCOPY = ${CROSS_COMPILE}objcopy
OBJDUMP = ${CROSS_COMPILE}objdump
RANLIB = ${CROSS_COMPILE}ranlib
READELF = ${CROSS_COMPILE}readelf
SIZE = ${CROSS_COMPILE}size
STRINGS = ${CROSS_COMPILE}strings
STRIP = ${CROSS_COMPILE}strip

export AS AR CC XPP LD NM OBJCOPY OBJDUMP RANLIB READELF SIZE STRINGS STRIP

MODULE_NAME = rt73
IF_NAME = wlan*

FIRM_DIR = $(PRJROOT)/rootfs/lib/firmware
FIRMWARES = rt73.bin

$(MODULE_NAME)-objs = rtmp_main.o mlme.o connect.o rtusb_bulk.o rtusb_io.o \
sync.o assoc.o auth.o auth_rsp.o rtusb_data.o \
rtmp_init.o sanity.o rtmp_wep.o rtmp_info.o \
rtmp_tkip.o wpa.o md5.o rt2x00debug.o

obj-m += $(MODULE_NAME).o

KDIR = $(PRJROOT)/kernel/linux
PWD = $(shell pwd)

MODULE_ROOT = /lib/modules/2.6.19-etwarm/extra
MODULE_OBJECT = $(MODULE_NAME).ko

all module

MODULE_CHECK = if ! [ -f $(MODULE_OBJECT) ]; then \
echo "$(MODULE_OBJECT) failed to build!"; \
exit 1; \
fi; \
if [ `du -b $(MODULE_OBJECT) | sed -e 's/\t.*//g'` -gt 1000000 ]; then \
echo "!!! WARNING Module file much too big (>1MB)"; \
echo "!!! Check your kernel settings or use 'strip'"; \
fi; \
echo "*** Module $(MODULE_OBJECT) built successfully"

module
@$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KDIR) SUBDIRS=$(PWD) 'EXTRA_CFLAGS=-DDBG modules; \
$(MODULE_CHECK)

clean
@rm -f *.o .*.{cmd,flags}
@rm -f $(MODULE_NAME).{o,ko,mod.{o,c}} built-in.o $(VERSION_HEADER) *~
@rm -fr .tmp_versions Module.symvers

modules_install
@if ! [ -f $(MODULE_OBJECT) ]; then \
echo "!!! $(MODULE_OBJECT) does not exit run 'make'"; \
exit 1; \
fi
@echo "*** Install module in $(MODULE_ROOT) ..."

$(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KDIR) SUBDIRS=$(PWD) INSTALL_MOD_PATH=$(PRJROOT)/rootfs/ modules_install

install modules_install
@echo "*** Install firmware in $(FIRM_DIR) ..."; \
if ! [ -d $(FIRM_DIR) ]; then \
mkdir $(FIRM_DIR); \
fi; \
cp -f $(FIRMWARES) $(FIRM_DIR)

[/quote1k15n5h9]

[b1k15n5h9]3. Create a new zImage[/b1k15n5h9]

including
- support for hot-pluggable devices CONFIG_HOTPLUG
- userspace firmware loading support CONFIG_FW_LOADER
- wireless LAN drivers (non-hamradio) & wireless extensions CONFIG_NET_RADIO
- OHCI HCD support CONFIG_OHCI_HCD

this includes are necessary for compiling the driver without errors.

[b1k15n5h9]4. Run make in the wlan driver folder "Module"[/b1k15n5h9]

debug output

[quote1k15n5h9]
make[1] Entering directory `/home/embedded-linux/kernel/linux-etwarm'
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_main.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/mlme.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/connect.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtusb_bulk.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtusb_io.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/sync.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/assoc.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/auth.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/auth_rsp.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtusb_data.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_init.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/sanity.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_wep.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_info.o
/home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_info.c In function `rt_ioctl_siwessid'
/home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_info.c905 Warnung Anweisung ohne Effekt
/home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_info.c In function `RTMPSetInformation'
/home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_info.c1474 Warnung Anweisung ohne Effekt
/home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_info.c In function `Set_SSID_Proc'
/home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_info.c3972 Warnung Anweisung ohne Effekt
/home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_info.c In function `rt73_ioctl'
/home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_info.c2777 Warnung Anweisung ohne Effekt
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rtmp_tkip.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/wpa.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/md5.o
CC [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rt2x00debug.o
LD [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rt73.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rt73.mod.o
LD [M] /home/embedded-linux/Ralink/rt73-cvs-2007101206/Module/rt73.ko
make[1] Leaving directory `/home/embedded-linux/kernel/linux-etwarm'
*** Module rt73.ko built successfully
[/quote1k15n5h9]

"Anweisung ohne Effekt" means "instruction without effect"

I dont know how to prevent the warnings, so I ignored them. Maybe they are the reason of my further problems???

[b1k15n5h9]5. make install[/b1k15n5h9]

--> rt73.bin in /lib/firmware
--> rt73.ko in /lib/modules/2.6.19-etwarm/extra/

[b1k15n5h9]6. insmod /lib/modules/2.6.19-etwarm/extra/rt73.ko results[/b1k15n5h9]

[quote1k15n5h9]rtusb init ====>
idVendor = 0x7d1, idProduct = 0x3c03
rt73 Failed to request_firmware. Check your firmware file location
rt73 probe of 1-11.0 failed with error -2
usbcore registered new interface driver rt73[/quote1k15n5h9]


[b1k15n5h9]7. I solved this problem[/b1k15n5h9] D

a) I forgot to mount sysfs

add "sysfs /sys sysfs defaults" in /etc/fstab

b) add hotplug-script (because I would not use hotplug or udev)

- add textfile "hotplug" in /proc/sys/kernel with entry "/sbin/hotplug"
- create executable file "hotplug" under /sbin

[quote1k15n5h9]#!/bin/sh

# Simple hotplug script sample
#
# Both $DEVPATH and $FIRMWARE are already provided in the environment.

HOTPLUG_FW_DIR=/lib/firmware

echo 1 > /sys/$DEVPATH/loading
cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading

# To cancel the load in case of error
#
# echo -1 > /sys/$DEVPATH/loading
#
#[/quote1k15n5h9]

[i1k15n5h9]thanks to hennig[/i1k15n5h9]

[b1k15n5h9]8. Include ifupdown and run-parts to the busybox, add wireless_tools to my embedded linux systems, add the following params to /etc/network/interfaces[/b1k15n5h9]

[quote1k15n5h9]auto wlan0
iface wlan0 inet static
address 141.57.27.165
netmask 255.255.252.0
network 141.57.24.0
broadcast 141.57.27.255
gateway 141.57.24.3
pre-up ifconfig wlan0 up

pre-up iwconfig wlan0 essid "*******"
pre-up iwconfig wlan0 mode Managed
pre-up iwconfig wlan0 channel 8

pre-up iwpriv wlan0 set AuthMode=WEPAUTO
pre-up iwpriv wlan0 set EncrypType=WEP
pre-up iwpriv wlan0 set Key1=**********
pre-up iwpriv wlan0 set SSID="*******"[/quote1k15n5h9]

[b1k15n5h9]9. insmod /lib/modules/2.6.19-etwarm/extra/rt73.ko results now[/b1k15n5h9]

[quote1k15n5h9]rtusb init ====>
idVendor = 0x7d1, idProduct = 0x3c03
usbcore registered new interface driver rt73
[/quote1k15n5h9]
[b1k15n5h9]
10. ifup wlan0 results[/b1k15n5h9]

[quote1k15n5h9]rt73 driver version - 1.0.3.6 CVS
***rt73*** Interface goes up for the first time, activating permanent MAC
***rt73*** Active MAC is 00195b74bf3e[/quote1k15n5h9]

[b1k15n5h9]11. ifconfig and iwconfig output[/b1k15n5h9]

[quote1k15n5h9]wlan0 Link encapEthernet HWaddr 00195B74BF3E
inet addr141.57.27.165 Bcast141.57.27.255 Mask255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU1500 Metric1
RX packets91514 errors0 dropped0 overruns0 frame0
TX packets9180 errors0 dropped0 overruns0 carrier0
collisions0 txqueuelen1000
RX bytes7118377 (6.7 MiB) TX bytes716040 (699.2 KiB)

wlan0 RT73 WLAN ESSID"FTZwlan"
ModeManaged Frequency=2.447 GHz Bit Rate54 Mb/s
RTS throff Fragment throff
Encryption key0A1B-2C3D-4E
Link Quality=0/100 Signal level-121 dBm Noise level-115 dBm
Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag0
Tx excessive retries0 Invalid misc0 Missed beacon0
[/quote1k15n5h9]

Here you can see my current problem. There is no link quality.

iwlist wlan0 scanning results
[quote1k15n5h9]
wlan0 No scan results[/quote1k15n5h9]

ifdown wlan0 results
[quote1k15n5h9]wlan0 unable to signal thread[/quote1k15n5h9] <--- ????

But the interface goes down

--> Actually I have no idea, what are the reasons of this problem. (

Maybe somebody has an idea???

Regards Daniel

Viper

06-11-2007 23:11:34

I'm still having the same problem on an ARM system. Kernel is 2.6.22, with wireless extension in, but getting the same result as you (FW cannot be loaded).

How did you solve that one? I'm not having sysfs or hotplug... Should I compule udev from it's source?

Vern

07-11-2007 02:29:11

I dont know how to prevent the warnings, so I ignored them. ...[/quoter111ona3]
What version of the compiler are you using? Mine doesn't complain, but its a good catch. Here's what it doesn't like
[coder111ona3]memcpy(Ssid.Ssid, "", 0);[/coder111ona3]
Since memcpy won't copy zero bytes of data, there's probably no real harm, but the intended effect is not produced, either.

It turns out I screwed up a fix that was intended to improve operation in an SMP environment. I've backed that out, and incorporated a patch by Graham Gower which is needed to load firmware under 2.4 kernels into CVS. The fixed source should be available in the latest CVS tarball for rt73 by now. Sorry for the mess up.

Graham has also provided a patch to implement firmware loading in the same way that Ralink's version of the driver does. I've gzipped it and attached it to this posting exactly as he provided it. If you apply it, you should be able to get by without depending on hotplug and/or udev. Let me know your results.

Thanks,

Viper

07-11-2007 09:09:39


Graham has also provided a patch to implement firmware loading in the same way that Ralink's version of the driver does. I've gzipped it and attached it to this posting exactly as he provided it. If you apply it, you should be able to get by without depending on hotplug and/or udev. Let me know your results.
[/quote1lfowf2d]
Applied the patch (compained about rtmp_main.c -> cannot comment out goto_no_firmware), complied well, inserted the module. Loaded also well, but I cannot configure the Wireless Network
[code1lfowf2d]
rtusb init ====>
idVendor = 0x148f, idProduct = 0x2573
usbcore: registered new interface driver rt73
root@(none):/etc/Wireless/RT73STA# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

tunl0 no wireless extensions.

gre0 no wireless extensions.

wlan0 RT73 WLAN
Link Quality:0 Signal level:0 Noise level:113
Rx invalid nwid:0 invalid crypt:0 invalid misc:0

root@(none):/etc/Wireless/RT73STA# iwconfig wlan0 essid ViperNET
Error for wireless request "Set ESSID" (8B1A) :
SET failed on device wlan0 ; Network is down.
root@(none):/etc/Wireless/RT73STA# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0D:33:44:57:05
inet addr:1.1.1.35 Bcast:1.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2104 errors:0 dropped:0 overruns:0 frame:0
TX packets:1382 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:465421 (454.5 KiB) TX bytes:187913 (183.5 KiB)
Interrupt:24 Base address:0xc000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1032 (1.0 KiB) TX bytes:1032 (1.0 KiB)

root@(none):/etc/Wireless/RT73STA# ifconfig wlan0 1.1.1.34 mask 255.255.255.0
ifconfig: SIOCSIFFLAGS: Input/output error
root@(none):/etc/Wireless/RT73STA# ifconfig wlan0 1.1.1.34 mask 255.255.255.0 up
ifconfig: SIOCSIFFLAGS: Input/output error
root@(none):/etc/Wireless/RT73STA# ifconfig wlan0 up
ifconfig: SIOCSIFFLAGS: Input/output error
[/code1lfowf2d]
iwlist scanning is also not working - not supported by interface...

Any idea?

daniel_matthes

07-11-2007 09:39:56

How did you solve that one? I'm not having sysfs or hotplug... Should I compule udev from it's source?[/quoteanhqt07e]

Maybe you do not read my whole post. You do not need udev!

Bevor compiling the kernel, set
CONFIG_HOTPLUG=y and CONFIG_SYSFS=y
--> now you have sysfs and hotplug

Afterwards follow step 7 in my last post.

Then firmware loading shout work.

daniel_matthes

07-11-2007 10:00:11


What version of the compiler are you using?
[/quote2roxcuzv]

arm-linux-gcc 3.4.4


Here's what it doesn't like
[code2roxcuzv]memcpy(Ssid.Ssid, "", 0);[/code2roxcuzv]
[/quote2roxcuzv]

Yes I know. This warnings are completly memcpy problems


Graham has also provided a patch to implement firmware loading ... you should be able to get by without depending on hotplug and/or udev. [/quote2roxcuzv]

OK, but firmware loading is not my current problem. Firmware loading works with the shell script described in step seven of my last post

My problem is


iwlist wlan0 scanning results

wlan0 No scan results


ifdown wlan0 results

wlan0 unable to signal thread
[/quote2roxcuzv]

modprobe rt73 brings no errors.

I can configure my adapter and bring them up. The activity led blinks. But the adapter doesnt find any ap.

Regards
Daniel

daniel_matthes

07-11-2007 13:45:11

When I probe rt73 with "debug=31", after 'ifup wlan0' I got the attached output.

Maybe someone get an idea by reading this attached textfile.

Viper

07-11-2007 14:05:29

How did you solve that one? I'm not having sysfs or hotplug... Should I compule udev from it's source?[/quotexmhyixmj]

Maybe you do not read my whole post. You do not need udev!

Bevor compiling the kernel, set
CONFIG_HOTPLUG=y and CONFIG_SYSFS=y
--> now you have sysfs and hotplug

Afterwards follow step 7 in my last post.

Then firmware loading shout work.[/quotexmhyixmj]
No sysfs in 2.6.22 with ARCH=arm... (even if I edit .config by hand...)

daniel_matthes

08-11-2007 14:19:35


No sysfs in 2.6.22 with ARCH=arm... (even if I edit .config by hand...)[/quote2vjlckke]

CONFIG_SYSFS is part of 2.6.22!!!

--> make ARCH=arm menuconfig
--> shift+7
--> search for sysfs

You should find the location of SYSFS

Vern

08-11-2007 18:03:56

When I probe rt73 with "debug=31", after 'ifup wlan0' I got the attached output.[/quote1rgv8gua]
What do you regard as the problem there?

It's best to run with debug=15, then attach a gzipped copy of /var/log/debug if you can.

Thanks,

Viper

09-11-2007 00:00:29


No sysfs in 2.6.22 with ARCH=arm... (even if I edit .config by hand...)[/quote12sl9mdg]

CONFIG_SYSFS is part of 2.6.22!!!

--> make ARCH=arm menuconfig
--> shift+7
--> search for sysfs

You should find the location of SYSFS[/quote12sl9mdg]
Finally I've found it (also had to enable CONFIG_EMBEDDED), but it didn't help my problem ( Any other idea? Should I build a debug driver and try that one?

Viper

14-11-2007 18:23:00

Compiled a new kernel (2.6.23) and it's working now just fine.... Thanks.

BTW, is SW MAC needed in the kernel?

daniel_matthes

20-11-2007 10:39:28


It's best to run with debug=15, then attach a gzipped copy of /var/log/debug if you can.
[/quote2xdp57yg]

I'm here again.

I needed some days to include the syslogd daemon in my embedded systems right.

Now I probe rt73 with "debug=15"

then
- iwlist wlan0 scanning (further no results)
- ifdown wlan0
- rmmod rt73

Finally I attached /var/log/messages and /var/log/debug to this post.
I hope sombody is able to find my error

Thanx Daniel

Vern

20-11-2007 20:12:35

Hi daniel_mathes,

Thanks for the log info. Also, it turns out that rt73 has an "arm" make target 'make arm' . This produces a compile error when tried, but a fix has been put into CVS, and should be available Soon in the hourly tarball.

So maybe while I look at these, you can try that?

Thanks,

daniel_matthes

22-11-2007 12:35:54

Hi Vern,

It seems that I have solved my problem!

I took a second look to the original Makefile. I noticed that I forgot to add DRTMP_EMBEDDED to the EXTRA_CFLAGS in my Makefile.

With this C-Flag scanning works. D

Finally I have a questions

What are the effects of

EXTRA_CFLAGS=-DRTMP_EMBEDDED and
EXTRA_CFLAGS=-I$(src)

Thanks for your effort Vern

daniel_matthes

22-11-2007 14:18:05

Hi Vern,

There is a new problem cry

Now I use rt73-cvs-2007112206

During compiling there are no errors and no warnings!

ifup wlan0 output

[code1bem3j3n]
rt73 driver version - 1.0.3.6 CVS
***rt73***: Interface goes up for the first time, activating permanent MAC
***rt73***: Active MAC is: 00:00:00:00:00:3e.
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
BUG: scheduling while atomic: rt73/0x00000001/265
[/code1bem3j3n]

The MAC-Adress is wrong now. Why?
What did this bug mean?

When I use the rt73-cvs-2007110706 driver there is no BUG, but also the same wrong MAC.

Otherwise the driver works in both cases
- iwlist scanning gives a result and ping AP-IP works.

After Compiling the Driver without EXTRA_CFLAG DRTMP_EMBEDDED and bringing up the module, the MAC is correct, but the driver doesn't work.

Regards again Daniel

P.S I have tested the driver with the original Makefile. (Modified KERNEL_SOURCE and so on). There is the same problem

Vern

22-11-2007 17:25:51

Hi daniel_mathes,

You should not need to modify the Makefile. RTMP_EMBEDDED is defined when you use 'make arm', or 'make armdebug'. Please try that. If there are problems, do 'make armdebug' and attach a gzipped copy of the debug log file to a posting here.

Thanks,

daniel_matthes

23-11-2007 12:46:42

Hi Vern

Now I have attached

- /var/log/messages
- /var/log/debug
- the modified Makefile (with the right paths for cross compiling)

My current status

- compiling without error
- ifup wlan0 (wrong [bpf7lpbut]MAC 00000000003E ???[/bpf7lpbut], only the last byte is correct and the described bug output appears)
- iwlist scanning gives a right result
- ping AP works

- sometimes ifdown wlan0 results
[codepf7lpbut]wlan0: unable to signal thread [/codepf7lpbut]

Thanks for help

daniel_matthes

03-12-2007 10:25:26

Hi Vern,

did you read my last post?

@everybody

Is sombody able to explain the highlighted code? (This are two lines of the Makefile)

[blb2tj19c]src ?= .[/blb2tj19c]
make ...[blb2tj19c]'EXTRA_CFLAGS=-I$(src)[/blb2tj19c]....

Thanx daniel

Vern

03-12-2007 22:18:36

It means "define it only if it's not already defined." "info make" is your friend.

Please try "make armdebug", run with "modprobe debug=15", and attach a gzipped copy of your /var/log/debug and /var/log/messages to a posting here. I'll take a look at them wrt the
[code2ele0umx]Active MAC is: 00:00:00:00:00:3e.[/code2ele0umx]
issue.

Thanks,

daniel_matthes

04-12-2007 09:35:32

Hi vern

Please try "make armdebug", run with "modprobe debug=15", and attach a gzipped copy of your /var/log/debug and /var/log/messages to a posting here. I'll take a look at them
[/quote1snpfg17]

I've already done this! The files are attached at the post of Fri Nov 23th!

Regards Daniel

Vern

05-12-2007 18:25:21

Hi Daniel,

As far as I can tell from looking at your log, the MAC address is really what's coming from EEPROM(!).

Could you try connnecting the adapter to a regular PC, compile the driver with debug enabled on that, and attach a copy of /var/log/debug to a posting here? That should serve as a cross check.

Thanks,

daniel_matthes

06-12-2007 10:12:14

Hi Vern,


Could you try connnecting the adapter to a regular PC, compile the driver with debug enabled on that, and attach a copy of /var/log/debug to a posting here? [/quote15c1m2n1]

Here it is.

Regards Daniel

Vern

07-12-2007 05:00:25

Hi Daniel,

Well. that copy of /var/log/debug shows
[code94hw1d3f]- Local MAC = 00:19:5b:74:bf:3e[/code94hw1d3f]
So ... it looks like we either have an alignment problem or a scribble problem with ARM.

Please feel free to dive into code if you wish. I'll be trying to see if I can't identify some usual suspects myself.

Thanks,

daniel_matthes

08-01-2008 09:35:55

Hi Vern



Well. that copy of /var/log/debug shows
[code7zzeysfg]- Local MAC = 00:19:5b:74:bf:3e[/code7zzeysfg]
So ... it looks like we either have an alignment problem or a scribble problem with ARM.

Please feel free to dive into code if you wish. I'll be trying to see if I can't identify some usual suspects myself.

[/quote7zzeysfg]

Today I got the actually version rt73-cvs-2008010802 and I have compiled the driver for ARM again. The MAC problem is also in this actual version. May I expect that this problem is solved in the near future? I need a working driver in this month, so it would be very gratifying.

Best Regards Daniel

Vern

11-01-2008 04:58:28

Hi Daniel,

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?

It's purpose is to verify that the receiving area for the MAC address starts on a 32 bit boundary and to see if that helps. I seem to recall some forum discussion about ARM alignment requirements somewhere.

Thanks,

daniel_matthes

11-01-2008 12:11:28


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?
[/quotedl4riixg]

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

[codedl4riixg]UCHAR fill[3];[/codedl4riixg]

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.

[codedl4riixg]
~ # 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
[/codedl4riixg]

What could be the cause of the error?

Regards Daniel

Vern

11-01-2008 17:36:37

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,

daniel_matthes

14-01-2008 12:27:01

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 [b1jx6vwdv]right[/b1jx6vwdv]
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

[code1jx6vwdv]
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)

[/code1jx6vwdv]

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

Vern

14-01-2008 20:25:02

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)
[code3v7925i8]touch foo.c; gcc -E -dM foo.c|sort >armconst.txt[/code3v7925i8]
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,

daniel_matthes

15-01-2008 09:42:07

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

Vern

15-01-2008 22:08:26

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,

daniel_matthes

16-01-2008 09:38:22

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.

[code35vcnucu]
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
[/code35vcnucu]

The scheduling bug is still displayed.


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?
[/quote35vcnucu]

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

Regards Daniel

Vern

16-01-2008 18:33:18

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,

daniel_matthes

17-01-2008 08:23:57

Thanks for the debug info and all the hard work.[/quote3f76awm0]

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

Change line #1393 in the patched rtmp.h so that we have aligned(2) instead of aligned(4) and see if that works?[/quote3f76awm0]

Yes, that works!

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

Regards Daniel

Vern

17-01-2008 17:57:43

Hi daniel_matthes,

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

Thanks again for your work.

daniel_matthes

21-01-2008 15:37:19

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

Vern

26-01-2008 19:07:09

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,

daniel_matthes

29-01-2008 12:45:25

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?[/quote21fri797]

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

[b21fri797]edit[/b21fri797]

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

Vern

29-01-2008 17:54:27

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,

daniel_matthes

30-01-2008 12:06:15

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

Vern

30-01-2008 17:07:18

Hi,

Can you try the attached patch? It changes the submit urb call from using GFP_KERNEL to GFP_ATOMIC.

Thanks,

daniel_matthes

31-01-2008 09:41:18

Hi Vern,

the patch has probably no effect.

/var/log/messages is attached.

Regards

Vern

06-02-2008 18:27:52

Hi daniel_matthes

Well, we did get further along before getting the "bug atomic" messages, but still no cigar.

This patch - attached as atomic1.patch.gz - basically ensures that USB Bulk input is done in process context. The intent is to avoid doing operations in interrupt context that cause complaints in ARM.

Could you give it a try and see what happens?

Also, the patch *may* reduce the load average observed in other threads in the forum. If it works, could you check that too?

Finally, I notice in your last log some messages tagged "ieee80211", which may indicate another driver at work. If so, that could be a source of problems too.

Thanks,

daniel_matthes

07-02-2008 10:39:45

Hi Vern,

Finally, I notice in your last log some messages tagged "ieee80211", which may indicate another driver at work. If so, that could be a source of problems too.
[/quoterrm3ov3h]

I had defined CONFIG_IEEE80211 in my kernel configuration for test runs. Now I have solved this bug, but this adjustment did not solve the intrinsic problem.

... Could you give it a try and see what happens?[/quoterrm3ov3h]

Unfortunately the bug is still there.
As always, I've attached the gzipped /var/log/messages

Regards

Vern

08-02-2008 18:01:08

Hi daniel_matthes,

I finally became so desperate that I decided to Read The Directions googling 'scheduling while atomic' yielded the information that this is a message issued by the 2.6 kernel scheduler (see sched.c) if a thread is scheduled out while it holds a spinlock. The thinking may be a little anal, but I understand it.

It turns out that, currently, USB bulk endpoint output can be started from both interrupt and process contexts.

The attached patch - atomic2.patch.gz - changes things to not do that. It should reduce - but I suspect may not eliminate - the "bug atomic" messages.

Could you try it?

Thanks,

daniel_matthes

11-02-2008 12:42:03

Hi Vern,

I've tested today the actually rt73 driver (rt73-cvs-2008021103) with your patch atomic2.patch

Unfortunately, I can't see any effect by using this patch.


Further I think that I can remember, that the bug doesn't occured by using my first rt73 cvs copy (rt73-cvs-2007091905). I was not sure, because in September I had other problems, described in this thread ... (so called rockie problems ;-)) So I decide to patch manually the vanilla copy of this version by using your arm4.patch to fix the mac-address problem an test it. My memories are correct. By using this driver, the scheduling bug doesn't occure.

So I have attached two /var/log/messages files to this thread. One for each driver version. And I have attached the patched copy of rt73-cvs-2007091905. Perhaps it helps?!

Regards Daniel

Vern

12-02-2008 17:03:39

OK, but your post of Wed Jan 16, 2008 238 am shows the "bug atomic" messages after having applied arm4.patch.gz. Are you sure?

In the meantime, I've (finally) got around to downloading Debug.tar.gz, and will take a look at it.

Thanks for your work,

Vern

12-02-2008 18:34:28

Hi daniel_matthes,

Me again. Thanks much for all your patient legwork.

I notice that messages_2008021103 has "bug atomic" msgs right after AsicAntennaSelect - called by AsicSwitchChannel - for ch 8. This is preceded by Set_SSID_Proc debug trace. messages_2007091905 does not have "bug atomic" messages, and also does not contain Set_SSID_Proc debug trace msgs.

The call to select the antenna appears to be issued from the open function, which can result in sleeping on USB I/O because we're in process context. If so, the ioctl to set the SSID can concurrently be invoked from another process. So I suspect the problem is really software timing related in that it crops up if we do ioctl's while the Mlme thread is sleeping on USB I/O.

If this hypothesis is correct, then it means that the problem is not a function of a particular armx patch, but rather of the sequence and timing of ioctl's with respect to internal driver ops.

Setting the channel from the open() function should be unneeded (the other USB legacy driver - rt2570 - doesn't do it). So removing the call should remove the "atomic bug" message, at least from here.

Accordingly, I've produced yet another version of the patch - atomic3.patch.gz - to remove these calls from the open function. Could you try it?

Thanks,

daniel_matthes

13-02-2008 11:38:36

Hi Vern,

Well, ... what should I say... nothing happens -(

see /var/log/messages

regards Daniel

Vern

13-02-2008 16:29:08

Hmm. Didn't make things worse, but, I see, no better either. Thanks for your efforts. Sorry to put you to them. I'll have to think and ponder this for a while.

In the meantime, what happens if you do ifup by itself, then do configuration separately? I'm trying to see what support there is for the hypothesis about concurrent driver bring-up ops and ioctl's.

Thanks again,

daniel_matthes

14-02-2008 16:10:05

Hi Vern,


In the meantime, what happens if you do ifup by itself, then do configuration separately?
[/quote1rm8hir0]

I've done what you said.

Maybe I got the key to solve this problem.

This is a part of my /etc/network/interfaces

[code1rm8hir0]
auto wlan0
iface wlan0 inet static
address 192.168.0.5
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.3
pre-up ifconfig wlan0 up

pre-up iwconfig wlan0 essid "FTZwlan"
pre-up iwconfig wlan0 mode Managed
pre-up iwconfig wlan0 channel 8
pre-up iwconfig wlan0 key on

# pre-up iwpriv wlan0 set AuthMode=WPAPSK
# pre-up iwpriv wlan0 set EncrypType=TKIP
# pre-up iwpriv wlan0 set WPAPSK=0a1b2c3d4e
# pre-up iwpriv wlan0 set SSID="FTZwlan"

pre-up iwpriv wlan0 set AuthMode=WPA2PSK
pre-up iwpriv wlan0 set EncrypType=AES
pre-up iwpriv wlan0 set WPAPSK=0a1b2c3d4e
pre-up iwpriv wlan0 set SSID="FTZwlan"

# pre-up iwpriv wlan0 set AuthMode=WEPAUTO
# pre-up iwpriv wlan0 set EncrypType=WEP
# pre-up iwpriv wlan0 set Key1=0a1b2c3d4e
# pre-up iwpriv wlan0 set SSID="FTZwlan"
[/code1rm8hir0]

When I uncomment either
[code1rm8hir0]pre-up iwconfig wlan0 essid "FTZwlan"[/code1rm8hir0]
or
[code1rm8hir0]pre-up iwpriv wlan0 set SSID="FTZwlan"[/code1rm8hir0]
there is no bug messages and the driver works correctly.

Well, It is important to define both lines? Why does the old driver version work with the configuration?

Regards Daniel

Vern

14-02-2008 17:29:47

Hi Daniel,

Do I understand you right that there are no "bug atomic" messages using atomic3.patch if your interfaces file only sets the SSID once? If so, you've uncovered a fairly deep problem that really needs to be handled separately.[quote3mwx0ybq]Well, It is important to define both lines? Why does the old driver version work with the configuration?[/quote3mwx0ybq] Actually, you should only need to use one or the other - preferably "iwconfig wlan0 essid ...". As to why one driver version works and another doesn't I've found that one characteristic of reactive (event driven) systems is that as one pushes code around - adding here, removing there - the latency and duration of software responses to external events is also changed; which can both "fix" and "solve" problems.

FWIW, since ifup does "ifconfig <ip> wlan0" itself, you should not need to do[code3mwx0ybq]pre-up ifconfig wlan0 up[/code3mwx0ybq]since it's redundant.

At any rate, if you can verify that the "bug atomic" messages don't appear if your interface file only sets the ssid once, I'll put atomic3.patch into CVS; then work on the atomic stuff based on that.

Thanks again for your work and efforts,

daniel_matthes

15-02-2008 10:02:36


Do I understand you right that there are no "bug atomic" messages using atomic3.patch if your interfaces file only sets the SSID once?
[/quotez34cjqpk]

When I set the SSID once, I don't need atomic3.patch. But also with including this patch, there are no "bug atomic messages"

Further by including the atomic3.patch, my last problem is also solved. When I run [codez34cjqpk]ifdown wlan0[/codez34cjqpk] there is no error message [codez34cjqpk]wlan0: unable to signal thread[/codez34cjqpk]

I've attached both /var/log/messages and /var/log/messages_atomic3 to show you this results. (The wlan0 error message in file messages is on line 1005)


FWIW, since ifup does "ifconfig <ip> wlan0" itself, you should not need to do[codez34cjqpk]pre-up ifconfig wlan0 up[/codez34cjqpk]since it's redundant.
[/quotez34cjqpk]

No thats wrong. When I uncomment this line. I got the following error message

[codez34cjqpk]
Error for wireless request "Set ESSID" (8B1A) :
SET failed on device wlan0 ; Network is down.
[/codez34cjqpk]

--> All wireless parameters can not be set.

Vern

15-02-2008 18:14:07

Hi daniel_matthes,

Thanks for the confirmation re. setting the SSID. The atomic3 patch should start appearing in the hourly CVS tarball soon. Also, glad to see there is a bonus fix.

While setting the SSID twice is not needed. Doing so *should* not harm anything. That it causes the "atomic bug" message is a bug in the driver. I think I may know what's happening, but it will be a fairly extensive effort to fix.

The need to do "pre-up ifconfig wlan0 up" is very confusing. I may have screwed up my own verification procedure. I'll have to check. If indeed it really is needed, then that too is a bug in the driver. In the meantime, you may be able to simplify by removing the ifconfig and changing the pre-up's to up's.

Again, thanks for your methodical approach, and for hanging in there through this work,

daniel_matthes

18-02-2008 09:54:33

Hi Vern

When I configure the driver in the following order the driver works without "ifconfig wlan0 up"

[code1ai7hcm5]
auto wlan0
iface wlan0 inet static
address 192.168.0.5
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.3

up iwconfig wlan0 essid "FTZwlan"
up iwconfig wlan0 mode Managed
up iwconfig wlan0 channel 8
up iwconfig wlan0 key on

# up iwpriv wlan0 set AuthMode=WPAPSK
# up iwpriv wlan0 set EncrypType=TKIP
# up iwpriv wlan0 set WPAPSK=0a1b2c3d4e
# up iwpriv wlan0 set SSID="FTZwlan"

up iwpriv wlan0 set AuthMode=WPA2PSK
up iwpriv wlan0 set EncrypType=AES
up iwpriv wlan0 set WPAPSK=0a1b2c3d4e
# up iwpriv wlan0 set SSID="FTZwlan"

# up iwpriv wlan0 set AuthMode=WEPAUTO
# up iwpriv wlan0 set EncrypType=WEP
# up iwpriv wlan0 set Key1=0a1b2c3d4e
# up iwpriv wlan0 set SSID="FTZwlan"
[/code1ai7hcm5]

Which solution is better? Using "pre-up" commands or ups?

Regards Daniel

Vern

20-02-2008 17:28:49

I guess in a perfect world, pre-up would be better because it would ensure that all related configuration items are set before driver operations begin. e.g. the driver would not try to do a scan just before the operating mode was switched to monitor.

However, the driver isn't set up to be able to do that, which - I suspect - is why you needed the ifconfig command it was effectively bringing the driver up before the following pre-ups were done.

So, in practical terms, using "up" commands simpifies things in the configuration script.

Vern

21-02-2008 00:02:48

Hi daniel_matthes,

Me again. I have a patch that's intended to resolve the "SIOCIFFLAGS invalid argument" problem with 2.6.24 kernels. It appears to work in my environment, but that is very restricted. Could you try it?

If it works for you, you may also find that you can now do pre-up commands without having to first do "ifconfig wlan up".

The file is attached as preup1.patch.gz.

Thanks, in advance,

daniel_matthes

21-02-2008 09:45:45

Hi Vern,

I've tested the driver rt73-cvs-2008022102 patched with preup1.patch. It doesn't work correctly.

After bringing up the device and running "iwconfig", I got the following output.

[code3gpf571z]
~ # iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 RT73 WLAN ESSID:"FTZwlan"
Mode:Managed Frequency=2.447 GHz Bit Rate=54 Mb/s
RTS thr:off Fragment thr:off
Encryption key:0000-0000-00
Link Quality=0/100 Signal level:-121 dBm Noise level:-111 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
[/code3gpf571z]

when i bring up the device after a bring down, I got the following error message

[code3gpf571z]
~ # ifdown wlan0
~ # ifup wlan0
SIOCSIFFLAGS: No such device
SIOCSIFFLAGS: No such device
route: SIOC[ADD|DEL]RT: Network is unreachable
[/code3gpf571z]

/var/log/messages is attached

regards Daniel

Vern

21-02-2008 17:38:17

Hi Daniel,

Jeez, you'd think I could have thought to do at least that much myself!

Veddy embarrassing - and thanks.

realsuamor

21-02-2008 18:16:30

Vern, is the (corrected) patch already checked in ?

Best,

Reinhard

Vern

21-02-2008 22:37:57

No.

I've modified the "preup1" patch enough that the driver will cycle through ups and downs without complaint - but it still doesn't work right. For example, after ifdown, then ifup, a scan operation does not return results.

So what I'd like to do is get that item resolved, then - if Daniel or you have the time and inclination - let him, or you, take another pass at it.

daniel_matthes

Did "preup1" at least allow you to do preups without having to do ifconfig up?

Thanks again for your work,

daniel_matthes

22-02-2008 09:20:03


Did "preup1" at least allow you to do preups without having to do ifconfig up?
[/quote1p136z08]

Not realy. After reboot it seems to work. But after "ifdown/ifup" the same error occures.

Vern

22-02-2008 22:27:05

Hi Daniel,

I've attached a modified version of the patch - preup2.patch.gz - that seems to work for me cycling through ifup -> ifdown -> ifup, etc. The main change is that it initializes the ASIC on every open.

It should also still allow you to do preup configuration without having to do an ifconfig first.

Could you try it and post your results here?

Thanks,

Vern

24-02-2008 21:46:54

Hi Daniel,

I've discovered problems with preup2. I've posted a later version - preup3 - on "SIOSSIFFLAGS Invalid argument" on ifconfig up on[/url3ofayxmx] that should fix things. It would be very helpful to also see that there are no problems with it in an ARM environment, so would it be possible for you to try that version of the patch and report your results before getting it put into CVS?

Thanks,

daniel_matthes

25-02-2008 08:53:06

Hi Vern,

Sorry, but I can not test the patches before friday. Our team is from Today till Thursday on Nuremberg on the Embedded World exhibition. And they took along the WLAN USB stick.

Regards Daniel

Vern

25-02-2008 21:34:02

Hi Daniel,

That's fine. Thanks again for your work. When and if you get a chance, making sure ARM operations are OK would be good.

Thanks,

daniel_matthes

10-03-2008 13:44:46

Hi Vern,

Now I'm back from my winter holidays. Today I've tested a vanilla copy of rt73-cvs-2008031007.

I've tested the driver in two ways. At first by using 'ups' and further by using 'pre-ups' without entering 'pre-up ifconfig wlan0 up'.

Every time it's possible to bring up the device without errors. But after bringing up there are some problems.

When I bring up the device by using 'ups', after reboot its possible to ping the ap. When I bring down the wlan adapter and bring up the device again, after that it's not possible to ping the ap. By using 'pre-ups' it is also not possible to ping the ap after reboot.

--> so I've attached some /var/log/messages files ;-)

regards daniel

Vern

11-03-2008 01:08:50

Hi daniel,

I can't reproduce the problem. I can pretty much do ifup, ifdown, ifup, ... ad infinitem, and I see in my log that the open function is called each time ifup is done, and the close function is called each time ifdown is done.

In both your logs I only see the open function called once, and the close function called once - which would imply that ifup (or ifconfig <iface> up) is only done once, and ifdown (or ifconfig <iface> down) are also only done once.

So I'm a little puzzled, here. Can you provide some detail on your procedures?

Thanks,

daniel_matthes

11-03-2008 09:29:20

Hi Vern,

I've done a new test run. I've tested two different driver versions. At first I've tested a vanilla copy of rt73-cvs-2008022102 and then a copy of rt73-cvs-2008031007.

This is my test procedure

0. /etc/network/interfaces is configured with 'ups'

1. reboot the system
2. /etc/init.d/rcS executes modprobe rt73
3. /etc/init.d/rcS executes ifup wlan0
4. ping <ap address>
5. ifdown -v wlan0
6. ifup -v wlan0
7. ping <ap address>
8. ifdown -v wlan0

By using the driver version 031007 step 7 does'nt work.

Further the step 6 output of driver version 022102 and version 031007 is different.

version 022102 output

[code1mffk4fl]run-parts /etc/network/if-pre-up.d
ifconfig wlan0 192.168.0.5 netmask 255.255.255.0 broadcast 192.168.0.255 up
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
route add default gw 192.168.0.3 wlan0
iwconfig wlan0 essid "FTZwlan"
iwconfig wlan0 mode Managed
iwconfig wlan0 channel 8
iwconfig wlan0 key on
iwpriv wlan0 set AuthMode=WPA2PSK
iwpriv wlan0 set EncrypType=AES
iwpriv wlan0 set WPAPSK=0a1b2c3d4e
run-parts /etc/network/if-up.d[/code1mffk4fl]

version 0031007 output

[code1mffk4fl]run-parts /etc/network/if-pre-up.d
ifconfig wlan0 192.168.0.5 netmask 255.255.255.0 broadcast 192.168.0.255 up
rt73: driver version - 1.0.3.6 CVS
route add default gw 192.168.0.3 wlan0
iwconfig wlan0 essid "FTZwlan"
iwconfig wlan0 mode Managed
iwconfig wlan0 channel 8
iwconfig wlan0 key on
iwpriv wlan0 set AuthMode=WPA2PSK
iwpriv wlan0 set EncrypType=AES
iwpriv wlan0 set WPAPSK=0a1b2c3d4e
run-parts /etc/network/if-up.d[/code1mffk4fl]

I've attached the log output.

Regards Daniel

Vern

13-03-2008 17:16:43

Hi Daniel,

Nice catch. Thanks for the extra legwork. It turns out that parts of the chip setup are lost during close processing. As a result, there's some chip initialization that needs to be done when the device is re-opened.

The attached patch -reopen1.patch.gtz - fixes the re-open issues I've been able to identify in my own environment. Could you apply it to a vanilla copy of the latest CVS and see if it's OK in yours?

Thanks again for your efforts,

daniel_matthes

14-03-2008 10:09:30

Hi Vern,

I have rerun the discribed test (last post) by using rt73-cvs-2008031403 an your commited patch.

This is my test result

- configured with ''ups' --> test ok.
- configured with 'pre-ups' and [b2yruooi6]pre-up ifconfig wlan0 up[/b2yruooi6] -->test ok.
- configured only with 'pre-ups' --> test bad, no ping answers from access point (ifconfig, iwconfig and iwlist scanning results looks fine)

/var/log/messages is attached.

regards daniel

Vern

14-03-2008 19:54:39

Hi Daniel,

Thanks for all the efforts you're putting in, here.

It looks like I may have zigzagged when I should have just zigged. reopen2.patch.gz (attached) works OK in my admittedly limited test environment. I hope it now works OK for you. Please try it and post your results here.

Thanks,

daniel_matthes

17-03-2008 10:16:23

Hi Vern,

I have rerun the discribed test again, using rt73-cvs-20081403 and reopen2.patch.

My test result

- configured with 'ups' or with 'pre-ups' an [b3fam3oio]pre-up ifconfig wlan0 up[/b3fam3oio] --> Everything is fine
- configured only with 'pre-ups'

1. reboot the system --> ok
2. /etc/ini.d/rcS executes modprobe rt73 --> ok
3. / etc/ini.d/rcS executes ifup wlan0 rt73 --> ok
4. ping <ap address> --> [b3fam3oio]bad[/b3fam3oio] no answers

[code3fam3oio]
PING 141.57.27.158 (141.57.27.158): 56 data bytes

--- 141.57.27.158 ping statistics ---
12 packets transmitted, 0 packets received, 100% packet loss
[/code3fam3oio]

5. ifdown wlan0 --> ok
6. ifup wlan0 --> ok
7. ping <ap address> --> seems ok, only the first, second and sometimes the third reply is missing or is to late

[code3fam3oio]
~ # ping 141.57.27.158
PING 141.57.27.158 (141.57.27.158): 56 data bytes
64 bytes from 141.57.27.158: icmp_seq=3 ttl=64 time=15.7 ms
64 bytes from 141.57.27.158: icmp_seq=4 ttl=64 time=3.4 ms
64 bytes from 141.57.27.158: icmp_seq=5 ttl=64 time=3.5 ms
64 bytes from 141.57.27.158: icmp_seq=6 ttl=64 time=3.5 ms
64 bytes from 141.57.27.158: icmp_seq=7 ttl=64 time=3.6 ms
64 bytes from 141.57.27.158: icmp_seq=8 ttl=64 time=4.6 ms
64 bytes from 141.57.27.158: icmp_seq=9 ttl=64 time=3.7 ms
64 bytes from 141.57.27.158: icmp_seq=10 ttl=64 time=3.7 ms

--- 141.57.27.158 ping statistics ---
11 packets transmitted, 8 packets received, 27% packet loss
round-trip min/avg/max = 3.4/5.2/15.7 ms
[/code3fam3oio]

[code3fam3oio]
~ # ping 141.57.27.158
PING 141.57.27.158 (141.57.27.158): 56 data bytes
64 bytes from 141.57.27.158: icmp_seq=0 ttl=64 time=2013.6 ms
64 bytes from 141.57.27.158: icmp_seq=1 ttl=64 time=1009.8 ms
64 bytes from 141.57.27.158: icmp_seq=2 ttl=64 time=11.5 ms
64 bytes from 141.57.27.158: icmp_seq=3 ttl=64 time=3.7 ms
64 bytes from 141.57.27.158: icmp_seq=4 ttl=64 time=3.8 ms
64 bytes from 141.57.27.158: icmp_seq=5 ttl=64 time=3.8 ms
64 bytes from 141.57.27.158: icmp_seq=6 ttl=64 time=2.9 ms
64 bytes from 141.57.27.158: icmp_seq=7 ttl=64 time=2.9 ms
64 bytes from 141.57.27.158: icmp_seq=8 ttl=64 time=3.0 ms
64 bytes from 141.57.27.158: icmp_seq=9 ttl=64 time=3.1 ms
64 bytes from 141.57.27.158: icmp_seq=10 ttl=64 time=3.1 ms
64 bytes from 141.57.27.158: icmp_seq=11 ttl=64 time=3.2 ms
64 bytes from 141.57.27.158: icmp_seq=12 ttl=64 time=3.3 ms

--- 141.57.27.158 ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 2.9/235.9/2013.6 ms
[/code3fam3oio]

/var/log/messages of the bad test is attached.

Vern

18-03-2008 20:40:59

Hi Daniel,

Your logs, which I guess are for the "preup only" scenario, show a couple of problem areas

1. HZ seems to be @1/10th of what driver thinks it is scan channel dwell time is about 1 sec; it should be about 0.1 sec. The periodic scan function seems to run once every 4 seconds; it should be every second.

2. There is an authentication request coming part way (chan #5) thru the first SSID scan.

The attached patch - reopen3.patch.gz - is intended to try to find out where the authentication request is coming from and also fix a couple of other items (see description). It *may* be that the scan separation referred to in the file comment part fixes the AUTH problem.

Could you give it a try?

Thanks again for doggedly ploughing thru this stuff,

daniel_matthes

19-03-2008 11:57:25

Hi Vern,

I have rerun the discribed test again( rt73-cvs-20081904, reopen3.patch).

My test result

- configured with 'ups' or with 'pre-ups' an pre-up ifconfig wlan0 up --> Everything is fine (as always)
- configured only with 'pre-ups'

- The same situation as before

I've attached /var/log/messages and my terminal output of the bad test.

Further, A new atomic scheduling bug occurs sometimes in the negative test (only "pre-ups")

Regards Daniel

Vern

22-03-2008 18:00:49

Hi Daniel,

Your latest log seems to have the same two properties that prompted the questions in my previous post. Any ideas?

Wrt[code1lt7sz90]BUG: scheduling while atomic: rt73/0x00000001/204[/code1lt7sz90]
To save turnaround time, could you go to rt_config.h, and at the the line that begins "#define MEM_ALLOC_FLAG", change GFP_ATOMIC to GFP_KERNEL? Should be safe because all kmalloc's are now done in process context. If they are not, that's (another) bug in the driver.

Oh, and let me know if the change makes the messages disappear.

Thanks,

daniel_matthes

02-04-2008 13:33:26

Hi Vern,

Here I'm again. In the last two weeks I tried to refloat my systems with kernel [bpqxvn15v]linux-2.6.24.4[/bpqxvn15v]. There was a problem in our ethernet switch driver. But now the newer kernel works. I decided to use this kernel version, because there are some interesting spi features inside.

Back to the WLAN problems.

I've tested the actually driver rt73-cvs-2008040202 including the reopen3 patch in the established way.

Further, the "pre-up-only" scenario doesn't work. The are no atomic bugs anymore, so I did not redefine the MEM_ALLOC_FLAG define.

A actually /var/log/messages is attached.

Now to your questions from Mar 18

1. HZ = 100 in linux-2.6.21, HZ = 128 in linux-2.6.24.4 (this will reduce timing errors, because the hardware clock is 32768 Hz) This defines are recommended.

2. Well... whats the problem with or the reason of this request. I do not unterstand.

Regards Daniel

Vern

02-04-2008 21:35:59

Hi Daniel,

I was able to set up a test environment that caused the open-after-close failure. There were several problems, chief of which was that the adapter lost the cipher scheme on close, so that needed to be refreshed on every open.

I've submitted the fixes for open-after-close operation to CVS, and you should see them soon in the hourly tarballs.

Could you try an hourly tarball that has the changes in it and see what happens? We'll use that as a baseline for looking at whatever problems remain.

The problem with HZ is it appears to be out of sync wrt. the actual number of jiffies per second, with the result that the driver's idea of elapsed time seems to be off by a factor of four or so.

I ask about the authentication request because there's no driver code that issues one at that point in the processing sequence; so there may be a problem with log integrity.

Anyway, please try the latest CVS when it appears and we'll take it from there.

Thanks again for your efforts,

daniel_matthes

03-04-2008 09:21:11

Hi Vern,

I rerun the established test using rt73-cvs-2008040302.

I got the same test result as ever.

Note

In the pre-up only test scenario the first iwconfig output after reboot includes no SSID and encryption KEY. Maybe thats the key to the problem.

[codea5i6ll99]
~ # iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 RT73 WLAN ESSID:"FTZwlan"
Mode:Managed Frequency=2.447 GHz Access Point: 00:1C:10:9A:00:2A
Bit Rate=54 Mb/s
RTS thr:off Fragment thr:off
Encryption key:off
Link Quality=100/100 Signal level:-16 dBm Noise level:-79 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

[/codea5i6ll99]

Further in all three test cases the first two ping replies arrive after more then 1 second, when I run ping immediately after ifup. When I wait a little moment, the replies arrive after some milliseconds (should be normal)

/var/log/messages of the pre-up-only test scenario is attached.

Vern

03-04-2008 16:27:39

Hi Daniel,

Wrt. the pre-up scenario What happens if you make setting the SSID the *last* pre-up command? I ask because the driver typically starts the scan/join sequence when it gets an ssid to look for.

[quote1pawcopo]Further in all three test cases the first two ping replies arrive after more then 1 second, ...[/quote1pawcopo]When the driver is opened, it does a scan to see what's out there. Since beacons are typically spaced about 1/10th second apart, this means that it listens a little over 1/10th second on each channel to be sure of detecting what's there. There are 12 - 14 channels to scan, so there's about 1 1/2 seconds before it switches to the target channel and tries to join up.

Thanks,

daniel_matthes

04-04-2008 08:21:20

Hi Vern,


Wrt. the pre-up scenario What happens if you make setting the SSID the *last* pre-up command? I ask because the driver typically starts the scan/join sequence when it gets an ssid to look for.[/quote3aoxjwab]

This has no effect. I got the same test-result.

Regards Daniel

Vern

04-04-2008 15:47:52

Could you attach a copy of your /etc/network/interfaces file to a posting here? I'll try to see if I can duplicate the symptoms.

Do you have anything else going on in the if-xxx.d subdirectories?

Thanks,

Vern

06-04-2008 21:32:16

Hi Daniel,

FWIW, I found an extract of your /etc/network/interfaces in one of your previous posts. I can't duplicate it exactly due to limitations in my environment, in which I'm pretty much limited to WEP encryption and adhoc mode. Here's what I have (extracted from my /etc/network/interfaces)[code2ilyhoso]...
iface wlan1 inet static
address 192.168.3.6
broadcast 192.168.3.255
netmask 255.255.255.0
pre-up iwconfig wlan1 mode Ad-Hoc
pre-up iwconfig wlan1 channel 2
pre-up iwconfig wlan1 enc `cat /etc/wireless/key1`
pre-up iwpriv wlan1 enc 2
#pre-up iwconfig wlan1 essid "Fearless Fosdick"
pre-up iwpriv wlan1 set SSID="Fearless Fosdick"
...[/code2ilyhoso]The last two lines are equally effective alternatives for setting the SSID.

This works fine in my environment. If I do[code2ilyhoso]modprobe rt73 ifname=wlan1
ifup wlan1[/code2ilyhoso] I'm able to concurrently ping and scp a kernel source file between my XP box and my Linux box while establishing an X11 session between the two over the wireless link. I can then do "ifdown wlan1" followed by "ifup wlan1" and do the whole thing all over again without problems.

This doesn't mean there can't be problems in infrastucture mode, so let me know if you find anything.

Thanks,

daniel_matthes

07-04-2008 09:10:39

Hi Vern,

I've tested the driver again.

The driver only works right after rebbot, if I write the config-commands in the following order

1. [bihz3pa4u]pre-up ifconfig wlan0 up[/bihz3pa4u]

2. [bihz3pa4u]pre-up iwconfig wlan0 essid "FTZwlan"[/bihz3pa4u] or
[bihz3pa4u]pre-up iwpriv wlan0 set SSID="FTZwlan"[/bihz3pa4u]
...
3. [bihz3pa4u]set encryption settings[/bihz3pa4u]

If I ignore this order, after reboot I cannot ping my access point an
and I got the following iwconfig output

[codeihz3pa4u]wlan0 RT73 WLAN ESSID:""
Mode:Managed Frequency=2.447 GHz Bit Rate=54 Mb/s
RTS thr:off Fragment thr:off
Encryption key:off
Link Quality=100/100 Signal level:-38 dBm Noise level:-115 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0[/codeihz3pa4u]

After a following "ifdown ifup" the interface works right. The order of the commands is apparently not important.

Regards Daniel

Vern

14-04-2008 20:29:40

Hi Daniel,

Sorry to keep you hanging so long. I've been looking through the log you posted Thu 4/3/08. It looks like the scans are pretty well hosed. Here's what a selective grep shows[code1vtkppoq]--> usb_rtusb_open: driver version - 1.0.3.6 CVS
ScanNextChannel(ch=1)
<-- usb_rtusb_open: OK
ScanNextChannel(ch=2)
ScanNextChannel(ch=3)
ScanNextChannel(ch=12)
ScanNextChannel(ch=13)
ScanNextChannel(ch=0)
ScanNextChannel(ch=9)
ScanNextChannel(ch=10)
ScanNextChannel(ch=11)
ScanNextChannel(ch=12)
-->usb_rtusb_close
<--usb_rtusb_close
--> usb_rtusb_open: driver version - 1.0.3.6 CVS
ScanNextChannel(ch=1)
<-- usb_rtusb_open: OK
ScanNextChannel(ch=2)
ScanNextChannel(ch=7)
ScanNextChannel(ch=8)
-->usb_rtusb_close
<--usb_rtusb_close[/code1vtkppoq]which is totally whacked. What you should see is two sequential scans of channels 1 through 13 inclusive - one between each open-close pair. I suspect its dumb luck that you hook up to the target channel 8 at all.

I see that there is an AP on channel 3. Could you arrange to configure that as the target channel and see if the "preup only" sequence works? That would help establish that things might be OK except for the channel selection sequence.

Also, have you built your kernel with CONFIG_4KSTACKS? The driver makes pretty heavy use of the stack (its basically seems to be a port of something developed for Windows), and 4K might not be enough to avoid stack corruption.

The attached patch - chan1.patch.gz - is designed to see if the channel list has become corrupted by the time a scan is requested. Could you apply it to the latest CVS and post the resulting log here?

Thanks,

daniel_matthes

15-04-2008 10:48:23

Hi Vern

I've tested the driver again. (rt73-cvs -2008041503, chan1.patch) In my opinion nothing will happend.


I see that there is an AP on channel 3. Could you arrange to configure that as the target channel and see if the "preup only" sequence works? That would help establish that things might be OK except for the channel selection sequence.
[/quote2iqsfujc]

That's not possible, because this ap is in another room. The owner of this access point is another institute. I got no access to this ap.


Also, have you built your kernel with CONFIG_4KSTACKS? The driver makes pretty heavy use of the stack (its basically seems to be a port of something developed for Windows), and 4K might not be enough to avoid stack corruption.
[/quote2iqsfujc]

No I have not. I'm also not able to configure this macro, because it is not part of my config file. I think it isn't defined in kernel 2.6.24, but I'm not realy sure. Maybe you can take a look at my .config file, which is attached


/var/log/messages is also attached.

Regards Daniel

Vern

15-04-2008 21:00:09

Hi Daniel,

Thanks for slogging back into the fray, here. It looks like one debug statment has changed the symptoms somewhat. The same grep on your latest log shows[code9o8oet04] SYNC - send ProbeReq @ channel=1, Len=49
SYNC - send ProbeReq @ channel=2, Len=49
SYNC - send ProbeReq @ channel=3, Len=49
SYNC - send ProbeReq @ channel=4, Len=49
SYNC - send ProbeReq @ channel=5, Len=49
SYNC - send ProbeReq @ channel=6, Len=49
SYNC - send ProbeReq @ channel=7, Len=49
SYNC - send ProbeReq @ channel=8, Len=49
SYNC - send ProbeReq @ channel=13, Len=49
SYNC - send ProbeReq @ channel=1, Len=49
...[/code9o8oet04]
Sure enough, CONFIG_4KSTACKS is not in your config file. However, this variable is standard in 2.6 kernels as provided by kernel.org. For example, in my system, changing to the kernel source directory and grepping CONFIG_4KSTACKS results in[code9o8oet04]# CONFIG_4KSTACKS is not set[/code9o8oet04]So you evidently have some non-standard version twigged for an embedded environment. As to what size stack you're actually using - who knows? But it may be worthwhile to find out, and if it is 4K, see if it can be made larger.

In addition, every log I've looked at, including the most recent one, has some anomalous content - e.g.
[code9o8oet04]Jan 1 00:00:39 192 user.debug kernel: rt73: CNTL - 1 BSS match the d
Jan 1 00:00:39 192 user.info kernel: ry: #1
Jan 1 00:00:39 192 user.debug kernel: rt73: remove none key #2
Jan 1 00:00:39 192 user.debug kernel: rt73: AsicRemoveSharedKeyEntry: #2
Jan 1 00:00:39 192 user.debug kernel: rt73: remove none key #3
Jan 1 00:00:39 192 user.debug kernel: rt73: AsicRemoveSharedKeyEntry: #3[/code9o8oet04]which would indicate something's getting stepped on.

If you can resolve these two items, I think we can make more effective progress.

As a thought, would it be possible to download a source tarball from kernel.org and build that to your ARM target?

Thanks,

daniel_matthes

16-04-2008 09:22:05

Hi Vern,

I became a little bit desperate. Because I have actually no idea, how I can help you.

1.

As a thought, would it be possible to download a source tarball from kernel.org and build that to your ARM target?
[/quote1zttq1yf]

Some weeks ago I download kernel source tarball 2.6.24.4 ( I've posted this fact) patched it with it with 2.6.24-at91.patch from MAXIM and with our etwarm_2.6.24.patch.
So I can not see the reason to retry this. This would'nt have an affect.

2.

Sure enough, CONFIG_4KSTACKS is not in your config file. However, this variable is standard in 2.6 kernels as provided by kernel.org.... But it may be worthwhile to find out, and if it is 4K, see if it can be made larger.
[/quote1zttq1yf]

I've read something about Kernel stack size. In principle the stack size is fixed. The value is the size of two pages. This means that the stack size in 32 Bit systems is at 8K. Since Kernel 2.6 it's possible to decrease the size to 4K. But this is only possible on x86 architectures, not on arm architectures. I've verified this fact. I patched the original kernel source with the MAXIM patch. Afterwards the CONFIG_4KSTACK macro cannot be configured.

3.

In addition, every log I've looked at, including the most recent one, has some anomalous content
[/quote1zttq1yf]

I've no idea what I should look out -(

Regards Daniel

Vern

16-04-2008 18:36:40

If CONFIG_4KSTACKS has disappeared, you have a pretty substantial modification. I think the basic ARM capability is a build option in the standard kernel source. As far as I can tell, the at91 patch you refer to is specific to the Atmel AT91. Can you run without it? If not, all I can say is; grep for CONFIG_4KSTACKS in the standard source, see what it affects, look for those in the patched version - or maybe contact the maxim folks - and patch the patch.

What does your etwarm patch do? Can you run without that?

Thanks,

daniel_matthes

17-04-2008 08:36:53

Hi Vern,


As far as I can tell, the at91 patch you refer to is specific to the Atmel AT91. Can you run without it?
[/quote21lz9ym4]
No thats not possible.
The at91 patch includes many drivers of the at91rm9200 peripherie, so I cannot create my operating system without this patch.

What does your etwarm patch do? Can you run without that?
[/quote21lz9ym4]
No thats also not possible.
The etwarm patch includes for example the driver of our board spezific ethernet switch ks8x93

If not, all I can say is; grep for CONFIG_4KSTACKS in the standard source, see what it affects
[/quote21lz9ym4]
I took a vanilla copy of kernel version [b21lz9ym4]linux-2.6.24.4[/b21lz9ym4] and run
[code21lz9ym4]grep -l -i -R -e CONFIG_4KSTACKS ./[/code21lz9ym4]
This is the output I got
[quote21lz9ym4]./Documentation/x86_64/kernel-stacks
./arch/m68knommu/defconfig
./arch/sh/configs/magicpanelr2_defconfig
./arch/sh/configs/r7780mp_defconfig
./arch/sh/configs/r7780rp_defconfig
./arch/sh/configs/r7785rp_defconfig
./arch/sh/configs/se7206_defconfig
./arch/sh/configs/se7712_defconfig
./arch/sh/configs/shx3_defconfig
./arch/sh/configs/titan_defconfig
./arch/x86/configs/i386_defconfig
./arch/x86/kernel/irq_32.c
./drivers/lguest/interrupts_and_traps.c
./include/asm-m68knommu/thread_info.h
./include/asm-sh/thread_info.h
./include/asm-x86/irq_32.h
./include/asm-x86/module_32.h
./include/asm-x86/thread_info_32.h[/quote21lz9ym4]
After this a found the file at91rm9200ek_defconfig in the vanilla source
I run
[code21lz9ym4]cp arch/arm/configs/at91rm9200ek_defconfig .config
make ARCH=arm menuconfig[/code21lz9ym4]
and got what I expect. I cannot define or enable CONFIG_4KSTACKS. It isn't part of the config files for the arm architecture. There is no possibility to reduce the kernel stack size in arm based systems. But I think we also do not want this, isn't it?

Regards Daniel

Vern

18-04-2008 16:36:53

Right. We don't want this; but we'd like to know the stack size that's being used. Grepping on CONFIG_4KSTACKS led me to[code1m680n63]include/asm-x86/thread_info_32.h[/code1m680n63]where I found[code1m680n63]#ifdef CONFIG_4KSTACKS
#define THREAD_SIZE (4096)
#else
#define THREAD_SIZE (8192)
#endif[/code1m680n63]Looking for THREAD_SIZE led me to[code1m680n63]include/asm-arm/thread_info.h[/code1m680n63]where I found these[code1m680n63]#define THREAD_SIZE_ORDER 1
#define THREAD_SIZE 8192
#define THREAD_START_SP (THREAD_SIZE - 8)[/code1m680n63]So it looks like finding the actual value for those constants that is used on your system may answer the question.

Thanks,

daniel_matthes

19-04-2008 09:02:31

Oh , I forgot to tell you in my last post, that I find out, that the stack size in ARM-devices is fixed by 8K. Sorry!

Regards