Thread: Re: [Madwifi-users] Mysterious crashes
Status: Beta
Brought to you by:
otaku
From: Misha S. <m_s...@ho...> - 2003-08-07 03:06:53
|
Try to make the kernel crash while you are in the console window (Ctrl-Alt-F1 from X). The kernel may write some errors to the console before it dies. You won't see them in X. Helped in my case. My laptop stopped crashing after I spreaded interrupts. Don't know if it helps in your case. Misha >From: Richard Stevens <ma...@ri...> >To: mad...@li... >Subject: Re: [Madwifi-users] Mysterious crashes >Date: Thu, 07 Aug 2003 04:16:34 +0200 > >Me once again. > >This starts to feel more like a blog than anything else. I have to correct >my previous statements. The problems are _not_ directly SMP related, they >just happen more quickly on my workstation. No matter what, the >gateway-machine will crash at some stage with caps-lock and scroll-lock >leds blinking. > >One thing I get every once in a while are the following warnings: > >Aug 7 04:09:27 analysis kernel: ath0: ath_tx_start: bogus xmit rate 0x0 >Aug 7 04:09:29 analysis kernel: ath0: ath_tx_start: bogus xmit rate 0x0 >Aug 7 04:13:25 analysis kernel: NETDEV WATCHDOG: ath0: transmit timed out >Aug 7 04:13:30 analysis kernel: NETDEV WATCHDOG: ath0: transmit timed out > >Does anyone have any idea how to further investigate this? I don't see >anything in the logs when the machine freezes. From what I found the >blinking leds indicate that there is still some crippled bit of kernel left >running somewhat. Anyone know if there is a way to extract some sort of >state information that might be of interest to people who know what they >are doing? > >Thanks, > >Richard > > _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
From: William S. K. <ws...@ya...> - 2003-08-07 16:10:17
|
I've also run into the mysterious crashes a few times. In once case = sending lots of pings from the station in question "ping -df" to the AP with ath_debug turned on did the trick. Another trigger I have seen a = couple times on a different machine is to simply reload the driver (i.e. rmmod everything and then insmod everything right away). I need to find some = time to do a more rigorous investigation. -----Original Message----- From: mad...@li... [mailto:mad...@li...] On Behalf Of Richard Stevens Sent: Thursday, August 07, 2003 7:19 AM To: Sam Leffler; mad...@li... Subject: Re: [Madwifi-users] Mysterious crashes Me again, I hope I don't get on your nerves to much. This problem seems to be a hard one to debug. As I mentioned before, I patched=20 the kernel source with the kdb patches, all I changed in the = configuration=20 was enabling the debug functionality. Everything else is *exactly* the = same. After compiling the kernel, I recompiled and reinstalled the madwifi modules,=20 and did a reboot. I tried to reproduce the problem and get some info as=20 described in my last mail. I rebooted again, kernel debugger enabled but = not used and started the ssh dd if=3D/dev/zero piped to void thing again. It = has=20 been running for about 2 hours without any problem at all. Before, the = error appeared at most an hour after beginning to use the connection. This is=20 weird, isn't it? Regards, Richard |
From: Richard S. <ma...@ri...> - 2003-08-07 16:33:16
|
Hi, On Thursday 07 August 2003 18:10, William S. Kish wrote: > I've also run into the mysterious crashes a few times. In once case > sending lots of pings from the station in question "ping -df" to the AP > with ath_debug turned on did the trick. Another trigger I have seen a > couple times on a different machine is to simply reload the driver (i.e. > rmmod everything and then insmod everything right away). I need to find > some time to do a more rigorous investigation. yes there seem to be various triggers. I can confirm the module reloading=20 trigger. Didn't test yet the ping load thing. Using WEP is another way of=20 making it hard for the driver not to crash :-). Also using the linux part i= n=20 master mode and having another machine connect and disconnect to the master= =20 will eventually crash things for me. I use my XP laptop for this and load a= nd=20 reload the driver. Sometimes even rescanning will do the trick. By the way, now that I set up everything for actually being able to gather = the=20 oopses or make backtraces and assuming I did gather the information in a=20 usable manner, would anyone with the necessary skills be interested in this= =20 data for the various ways I can trigger a crash? I'm afraid I can't do much more than providing info since I'm completely=20 clueless on what to do with the data. Regards, Richard |
From: Mitch S. <mw...@ca...> - 2003-08-07 17:03:52
|
Richard, The crash during insmod is due to processing interrupts before all of the device structures have been set up (in particular, the pointer to the HAL entry points). There's an unofficial patch for the 20030802 drop on sourceforge, and some email on madwifi-devel. I don't know about the other crashes... Cheers, Mitch On Thursday 07 August 2003 09:23, Richard Stevens wrote: > Hi, > > On Thursday 07 August 2003 18:10, William S. Kish wrote: > > I've also run into the mysterious crashes a few times. In once case > > sending lots of pings from the station in question "ping -df" to the AP > > with ath_debug turned on did the trick. Another trigger I have seen a > > couple times on a different machine is to simply reload the driver (i.e. > > rmmod everything and then insmod everything right away). I need to find > > some time to do a more rigorous investigation. > > yes there seem to be various triggers. I can confirm the module reloading > trigger. Didn't test yet the ping load thing. Using WEP is another way of > making it hard for the driver not to crash :-). Also using the linux part > in master mode and having another machine connect and disconnect to the > master will eventually crash things for me. I use my XP laptop for this and > load and reload the driver. Sometimes even rescanning will do the trick. > > By the way, now that I set up everything for actually being able to gather > the oopses or make backtraces and assuming I did gather the information in > a usable manner, would anyone with the necessary skills be interested in > this data for the various ways I can trigger a crash? > > I'm afraid I can't do much more than providing info since I'm completely > clueless on what to do with the data. > > Regards, > > Richard |
From: Vittorio B. <vit...@in...> - 2003-11-28 11:30:50
|
It happens the same exact thing to me to. I'm using latest CVS madwifi driver with kernel 2.6.0-test9 |