rt2x00.serialmonkey.com

Hi,

My Sitecom WL-115 rt2500 based wifi card and the Serialmonkey rt2500 drivers kept crashing my kernel as soon as I tried to connect to some random website. After many futile attempts to get it to work I thought I could at least try to compile the driver in debug mode and see if something interesting would appear in the log files. So I recompiled the latest rt2500 CVS release, loaded the module using "insmod rt2500 debug=31" and fired up a webbrowser expecting it to crash immediately as always. This time however it didn't crash and everything kept working fine! Then I removed the module from the kernel and loaded it again, this time with just "insmod rt2500". And yes, as soon as I tried to connect to a website the kernel crashed. After this I configured my system to always load the rt2500 module with "debug=31" and it has been running rock-stable since then.

Now the only problem that was left was the fact that the file /var/log/debug would become very large as time progressed, which I "solved" by making /var/log/debug a symlink to /dev/null.

Well, since everything works perfectly now I am happy but I am still wondering if there's some rational explanation for the fact that the driver crashes my kernel in "normal" mode and that it doesn't crash in debug mode. Any thoughts?

Thanks in advance!

Oh, I almost forgot to mention the system's specifications:

Slackware 11.0 with kernel 2.4.33.3 (had this driver crash on the same machine using Gentoo and a 2.6 kernel also, so it seems kernel-unrelated, but I never tried to run in debug mode when I had still Gentoo on it)
AMD K6-2 300 MHz
192 MB RAM, nVidia TNT2 video card, some unknown motherboard (has no markings whatsoever, uses a "AGPPro PC100" chipset)

Hi Kipmans,

Could you try getting an oops trace?

1. mobprobe rt2500; klogd -i
2. Do your stuff until the crash
3. Reboot and find the oops (if there is one) in /var/log/kern.log
4. Run ksymoops on it (see /var/log/ksymoops)
5. Post results here.

Thanks,

Well, I looked in various places for oopses but couldn't find any. Also, I more or less trashed my entire Slackware install when trying to upgrade to a 2.6 kernel (which I did for various reasons) so I have to reinstall everything before I can collect any more info if necessary.

Hi Kipmans,

I know the feeling. My own upgrade from Sarge to Etch was pretty much a disaster. Still is in some ways.

Well, when you get things sorted to your satisfaction, see what the situation is with the driver.

Good luck,

Hi,

My system's working again, now running nicely with Slackware 12.0 and a 2.6.21.5 kernel. The situation with the driver is still the same: crashes when loaded without "debug=31" but runs fine otherwise. I let it crash deliberately for several times and searched for information in my system's log files but I haven't been able to find something related to the crashes yet.

By the way, I just remembered that I used to have a problem very similar to this (system locks up when trying to use the network) on my other comp, which was caused by a faulty cheap RTL8139-based NIC.

When I got my own adapter - a PCI- based MSI 54G2 - I went through a couple of months of crashes, nested ISR failures, etc. Pushing code around would change symptoms, but there was never a fix.

Finally, I removed the board, aired out the PCI slot, cleaned the contacts and reseated it.

Everything has worked fine ever since.

So you might try that. Get a can of compressed air, contact cleaner, and a lint free cloth (coffee filters work fine). Remove the board, clean the adapter and bus contacts, reseat it, and see what happens.

Good luck,

Hi people.

I have exactly the same problem here. And solved it, for the moment,
using the same trick, recompile with debugging, and modprobing
with debug=31 (and redirecting the /var/log/debug)

If there has been some change, I'd like to hear from it!

Thanks.
John

Hi johncc,

Could you try getting an oops trace?

1. mobprobe rt2500; klogd -i
2. Do your stuff until the crash
3. Reboot and find the oops (if there is one) in /var/log/kern.log
4. Run ksymoops on it (see /var/log/ksymoops)
5. Post results here.

Thanks,