kernel panic in update_wstats()

I'm using the at76c503a driver (0.14beta1, but it looks almost identical to a76c503a git) on Linux 2.6.18.

I got the following kernel panic while using an AT76C503A card with firmware version 1.101.2 #84 (fcs_len 4). This happens almost immediately under heavy load in ad-hoc mode. It never happened when using the device on another box which had an OHCI USB controller, and I'm currently using an UHCI controller (but I wouldn't say this is related by any means).

I tried to comment out the whole update_wstats() function, and the kernel doesn't panic anymore.

BTW: is there any related development mailing list or IRC channel? I could be interested in development, in future.

Here comes the panic message (I just copied the relevant information by hand, as I didn't set up netconsole, but I can do that if needed):

PREEMPT

Modules linked in: orinoco_cs orinoco hermes apm at76_usb snd_pcm_oss

snd_mixer_oss xt_tcpudp ipt_MASQUERADE iptable_nat ip_nat ip_conntrack ip_tables x_tables ohci_hcd parport_pc parport crc_ccitt pcspkr pcmcia
yenta_socket rsrc_nonstatic pcmcia_core ide_scsi scsi_mod CPU: 0
EIP 0060:[<c2ff61c3>] Not tainted VLI
EFLAGS: 0010246 (2.6.18 #4)
EIP is at update_wstats+0x83/0xc0 [at76_usb]

Call Trace:
 rx_mgmt+0x9e/0x1180 [at76_usb]
 hcd_submit_urb+0x1c5/0x910
 rx_tasklet+0x247/0x1660 [at76_usb]
 uhci_free_urb_priv+0x6e/0xb0
 uhci_unlink_qh+0x66/0xd0
 usb_free_urb+0x1c/0x20
 uhci_giveback_urb+0xd0/0x1e0
 kfree_skbmem+0x42/0xa0
 at76c503_tx+0x404/0x590 [at76_usb]
 __qdisc_run+0x78/0x1f0
 tasklet_action+0x3e/0x70
 __do_softirq+0x42/0x90
 do_softirq+0x26/0x30
 irq_exit+0x35/0x40
 do_IRQ+0x36/0x70
 do_setitimer+0x52a/0x570
 common_interrupt+0x1a/0x20
 sys_select+0x3/0x1c0
 sys_sigreturn+0xaf/0xc8
 syscall_call+0x7/0xb
EIP: [<c2ff61c3>] update_wstats+0x83/0xc0 [at76_usb] SS:ESP 0068:c0ba9d54
  <0>Kernel panic - not syncing: Fatal exception in interrupt

Ciao
Stefano

Are you sure you're running a version that has this fix from git:
4b50804c047272075f07edb5b62d857e3200d6a0

If you already have this fix, please try to comment out the different at76_calc_* functions to see which one causes the problem. Cheers,
-- Guido

I missed it, it works now. Thanks Pavel and sorry for the noise. BTW, stats are still bogus (link, signal, noise level == 0). But I don't think it makes sense to debug this now, as you will probably have to deal with mac80211 soon.

I had to make a little patch in order to build the driver on a kernel version < 2.6.20. I don't think you want to merge this, as you are working for inclusion into mainline, but in case, here it is:

---

index e39e31e..159901b 100644
@@ -35,6 +35,7 @@
 #include <net/iw_handler.h>
 #include <linux/firmware.h>
 #include <linux/leds.h>
+#include <linux/version.h>
 
 #include "at76_usb.h"
 #include "at76_usb_ids.h"

@@ -5961,7 +5962,12 @@ static struct at76_priv *alloc_new_device(struct usb_device *udev,
 	dev->netdev = netdev;
 
 	init_MUTEX(&dev->sem);
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
+	INIT_WORK(&dev->devent_queue, at76_devent, (void *)&dev->devent_queue);
+#else
 	INIT_WORK(&dev->devent_queue, at76_devent);
+#endif
 
 	dev->open_count = 0;
 

--
Ciao
Stefano

If you mean Ad-Hoc, I agree. Quality of an Ad-Hoc connection is not well defined. It's better implemented across the board than for every driver.

Indeed, the driver is quite "soft", and could be a good candidate for mac80211 conversion. Although it wasn't a requirement for submission.

Correct, it's not what we want at this point, but thanks anyway.

Regards,
Pavel Roskin

[email protected]
-- Guido