rt73 on RT-Kernel 2.6.24 with Mandriva 2008

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

realsuamor

16-02-2008 14:23:01

Hi,

I just downloaded the recent CVS-Daily driver (about half an hour ago) and was happy to se the adaptions to the current kernel 2.6.24 (as I had no luck with previous drivers on that kernel)

I use a Edimax 7318usg USB stick running fine with the original 2.6.24 rt73usb driver however I do not get WPA/PSK running at all (iwprism-> no support, wpa_supplicant gives error during start).

Having run rt73 succesfully with WPA on another card I tried today the second time to get it running.

After succesful compilation I do
./insmod rt73.ko debug=31

I get the following error in dmesg
there_is_no_init_MUTEX_LOCKED_for_RT_Semaphores

Any ideas what happened ? The module does no longer load at all -(

Also I noticed that a fully stripped modules does not load either but as far as I remember that was already discussed here on this forum (strip -d worked up to now for me).

My kernel has Realtime scheduling activated (this works fine with my soundcard and jack sound daemon). My internal wlan card works too (iwl4965) but the signal is too weak to be useful for me. And WPA is unreliable on that driver too.

Reinhard

Vern

16-02-2008 16:48:15

Apparently there's a conflict in 2.6.24 between initializing semaphores using init_MUTEX_LOCKED() and Realtime scheduling. What happens if you disable Realtime scheduling?

Thanks,

realsuamor

16-02-2008 17:08:37

Apparently there's a conflict in 2.6.24 between initializing semaphores using init_MUTEX_LOCKED() and Realtime scheduling. What happens if you disable Realtime scheduling?

Thanks,[/quote5k3cx1gj]

I cannot disable realtime scheduling, that's why I downloaded & compiled this special kernel. Apparently something broke it, because it worked when I downloaded the driver on 2. of february.

The old driver version was not working with 2.6.24 though, so I just waited until there was a compatible version.

The only thing I could do is completely recompile the kernel with another scheduling.. maybe I try just to change to config as a start.

Thanks for the hint -(

Reinhard

Sorry, I could not answer to this thread anymore.. I'm getting forbidden messages any idea ? I just did some tests...

realsuamor

16-02-2008 19:29:24

Hi,

I just did change the config options of my kernel to low latency while I compiled a new kernel.
To my surprise I could load the rt73.ko module via insmod on my old kernel.

When I inserted my USB card I got an ooops kernel message though. Do you have any more ideas ? (will post the detailed ooops later).

I tell you about the tests with my low latency driver too soon.

Reinhard

realsuamor

16-02-2008 20:52:56

Hi,

Below are the kernel log messages from the above try to load rt73.ko with changed .config settings without reboot. MIght still be helpful on tracing the problems with the module I hope.

If you need the syslog config entries having created the log I can post them too, but they haven't changed since quite some releases on Mandriva.

Reinhard

P.S. I needed to rename my .log files to .txt files as .log files are not allowed here.

realsuamor

16-02-2008 22:28:40

Hi,

I still have no luck with the driver (similar effect like the driver version on beginning of february). I insmodded as last time with the debug module.

Logs and insmods are in the attachment.

[]$ lsmod|grep iwl
iwl4965 111976 0
firmware_class 12032 2 rt73,iwl4965
mac80211 130444 1 iwl4965

Complete lsmod list is in the attachment lsmod.txt.

Tell me if you need lspci -v or lspcidrake -vv or similar information about my card.

Hint wlan0 is my internal WLAN card (iwl4965)

[]$ ifconfig wlan1 up
SIOCSIFFLAGS Das Argument ist ungültig

[]$ sudo iwconfig wlan1 essid xxxxxxx
Error for wireless request "Set ESSID" (8B1A)
SET failed on device wlan1 ; Network is down.

I checked that debug output is in info.log(txt). There were no errors shown in the errors.log.

Reinhard

realsuamor

17-02-2008 07:47:21

I've collected some drive informations

rt73 Ralink|802.11 bg WLAN (vendor148f device2573)

If you need lsusb output just tell me )

Reinhard

realsuamor

17-02-2008 11:40:12

Hi,

I once read a thread about a similar problem when bringing up the interface but it was never answered completely and seemed not related to my problem.

There is now a new thread from start of January 2008. So all interested persons should go to this thread concerning my ifconfig wlan1 up problem (mac address related as it seems with a temporary workaround available). I will post my experiences in this thread when needed

Klick[/url2s8c0i6j]

This thread should be left for the broken real time kernel support.

Thanks,

Reinhard

Vern

18-02-2008 03:57:33

Hi realsuamor,

Have you done "make tags" on your kernel source tree? If so, does "vim -t init_MUTEX_LOCKED" land you anywhere? On my system, I end up in include/asm-x86/semaphore_32.h.

I'm not too sure how you broke out all the separate warning, info etc. but your info.txt doesn't really have debug info in it. Have you compiled using "make clean debug"? If so, then all debug messages go to /var/log/debug - or wherever /etc/syslog.conf has pointed them to; and those are what's needed.

A couple of other questions

1. Is there a compile time constant available that is defined when compiling into this "Realtime" kernel?

2. Is there a "Realtime" equivalent to init_MUTEX_LOCKED? Keep in mind that the core intent of that call is to initialize the semaphore structure with an initial count of zero.

Where I'm going with this is the idea of replacing references to init_MUTEX_LOCKED in the mainline code with references to a suitably named macro, which will be set up in rt_config.h to conditionally expand to one variant or another if we're compiling under 2.6.24.

Finally, you've obviously done a lot of work, here Thanks very much,

realsuamor

19-02-2008 18:43:51

a) Low Latency kernel config
make tags ...
vim .... -> rt_lock.h, line 169

b) Realtime kernel config
make tags ...
vim .... -> rt_lock.h, line 169

#define init_MUTEX_LOCKED(sem) \
PICK_SEM_OP(compat_init_MUTEX_LOCKED, rt_init_MUTEX_LOCKED, sem)

Akkording to package kernel-rt-2.6.24-1.rt1
NOTE This kernel has no Mandriva patches and no third-party drivers,
only Ingo Molnar -rt (realtime) series patches applied to vanille kernel.org kernels.

c) syslog config
grep kern /etc/syslog.conf
kern.=debug;kern.=info;kern.=notice -/var/log/kernel/info.log
kern.=warn -/var/log/kernel/warnings.log
kern.err /var/log/kernel/errors.log

I just noticed a "-" before the path but don't know what that means
I definitively did a debug version as there were many more messages put out
than without on my log files. dmesg did not show more than was printed into the
kernel logs.

d) modprobe troubles (low latency kernel)

make clean; make; strip -d rt73.ko; make install
modprobe rt73
-> FATAL Module rt73 not found.

ls -al /lib/modules/2.6.24-1.ll1.1mdvcustom/extra/rt73.ko
-rw-r--r-- 1 root root 270200 2008-02-17 1120 /lib/modules/2.6.24-1.ll1.1mdvcustom/extra/rt73.ko

grep rt73 /lib/modules/2.6.24-1.ll1.1mdvcustom/modules.* | grep -v rt73usb
-> no results

Something goes really wrong here, though depmod is executed without errors.

depmod -e -F /boot/config-2.6.24-1.ll1.1mdvcustom

-> See depmodres.txt
(Beginning of file show several missing symbols, insmod though works fine)

e) Questions

1) No idea what you mean, the I appended the diffs betweend those kernel configs
-> kernel-config-diff.txt
-> config-2.6.24-1.rt1sm

2) I just know that beginning of february the rt73 driver did compile well and
also modprobe worked without troubles. Wasn't able to test though because
of the MAC adress problem I wasn't aware off

Hope this helps,

Reinhard

Vern

20-02-2008 17:54:09

It looks like init_MUTEX_LOCKED exists in your system. If so, then it appears something needed to direct the build process to it in the standard setup is missing. So something may need to be changed to accommodate your particular variant.

Wrt
[code2upiu9fa][]$ ifconfig wlan1 up
SIOCSIFFLAGS: Das Argument ist ungültig

[]$ sudo iwconfig wlan1 essid xxxxxxx
Error for wireless request "Set ESSID" (8B1A) :
SET failed on device wlan1 ; Network is down. [/code2upiu9fa]
This is a problem with 2.6.24. We're working on a change to adapt to it.

What I mean by
[quote2upiu9fa]1. Is there a compile time constant available that is defined when compiling into this "Realtime" kernel?[/quote2upiu9fa]
is 'Is there something like "__linux__" that can be made the operand of a #ifdef statement?'.

realsuamor

20-02-2008 19:11:50

It looks like init_MUTEX_LOCKED exists in your system. If so, then it appears something needed to direct the build process to it in the standard setup is missing. So something may need to be changed to accommodate your particular variant.
[/quotewscxhoj3]

You can always reproduce it with an 2.6.24 from kernel.org including the realtime patch or the rpm source I pointed to.

[quotewscxhoj3]
What I mean by
[quotewscxhoj3]1. Is there a compile time constant available that is defined when compiling into this "Realtime" kernel?[/quotewscxhoj3]
is 'Is there something like "__linux__" that can be made the operand of a #ifdef statement?'.[/quotewscxhoj3]

It's in the kernel Makefile (and some drivers/headers have references on it). It's defined as

CHECKFLAGS = -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ -Wbitwise $(CF)

Though I did not check the kernel logic I found that this flag seems to get exported later.

Makefile.rules have similar definitions but seem to be part of something more generic.

Reinhard

Vern

20-02-2008 23:45:55

Hi realsuamor,

For me, there is no probem with init_MUTEX_LOCKED. Things compile without a murmur using 2.6.24 as downloaded from kernel.org.[quote3ce9qxyg]It's in the kernel Makefile (and some drivers/headers have references on it). It's defined as[/quote3ce9qxyg](sigh). Forget it.

realsuamor

21-02-2008 18:13:47

Hi Vern,

The compile process works splendid on my system too! The problem is the loading of the driver itself at runtime only. There must be something in the realtime kernel patch that makes changes to the locking mechanism symbols which I don't understand.

If you're out of ideas you could still ask the maintainer of the realtime kernel patch about ideas of this failure. But note that I'm also unable to modprobe the rt73 driver because of other symbols missing (you remember the depmod log) so I guess there is another bug here. I just don't understand why other 2.6.24 users don't seem to have that problem I encounter.

Best,

Reinhard

Linkin

23-02-2008 18:44:44

Hi!

Seems like I'm having the same problem. I'm using the 2.6.24.2 Kernel on ArchLinux and cant bring the device up.

[root@uplink packages]# ifconfig wlan0 up
SIOCSIFFLAGS Invalid argument

The driver Im using is the latest rt73 cvs version

[root@uplink packages]# modinfo rt73
filename /lib/modules/2.6.24-ARCH/kernel/drivers/net/wireless/rt73.ko
license GPL
description Ralink RT73 802.11abg WLAN Driver 1.0.3.6 CVS CVS Release

If you want me to post some more info please let me know but I think its pretty much the same thing realsuamor describes.

realsuamor

24-02-2008 07:59:04

No you have a different problem, discussed in the thread I mentioned above. This thread is about the problem that modprobe / insmod does not load the module due to missing symbols in the 2.6.24(.1) kernel.

In a different thread[/url1bpd8fgc] there is also a driver patch that could fix the problem.

Reinhard

Linkin

25-02-2008 15:03:35

Thank you for the hint. It led me right to the solution )

realsuamor

10-05-2008 09:11:55

Hi,

I just tried out the latest cvs version and still have no luck to even get it modprobed
or included into the kernel (same kernel, vanilla with RT patch on it). Also when
manually insmoding the rt73 module I get a general protection fault... I'll post more
information later (files, debug output etc.)

Reinhard

erlingh

13-05-2008 22:35:52

OK here's a [b1ot7wcp4]hack[/b1ot7wcp4] that at least fixed the compile/insmod problem for a realtime-patched kernel for me.
Note that I'm running bog-standard ubuntu-rt from release 8.04 (Hardy) on a single-core CPU.
It might well be that this little cludge will make your n-core processor equipped pc really unhappy, as
this could introduce race-conditions or worse for all I know. At least, the name there_is_no_init_MUTEX_LOCKED_for_RT_Semaphores might suggest that bad things could happen...

What my little hack does, is define a function that'll initialize and lock a semaphore in rtmp_init.c. Then I
#define init_MUTEX_LOCKED into calling that function.

Hopefully this will work for some of you guys as well
Or maybe this can inspire someone with more detailed knowledge
about the reason init_MUTEX_LOCKED is abandoned on rt-kernels to dig deeper and solve this
problem properly once and for all.

Enjoy,
Erling