From: Denis V. <vd...@il...> - 2005-12-13 16:00:19
|
On Monday 12 December 2005 18:33, Carlos Mart=EDn wrote: > Cuentan por ah=ED, que el Monday 12 December 2005 07:31, Denis Vlasenko=20 > dijo: > >=20 > > It doesn't need any tx descriptors for probe requests, because fw > > sends them by itself. But you are right, something upsets fw: > >=20 > > Dec 11 18:07:30 pepe kernel: 95749545 =3D=3D> acxpci_l_alloc_tx > > Dec 11 18:07:30 pepe kernel: acx: BUG: tx_head:0 Ctl8:0x00 - failed to= =20 > find free txdesc > > Dec 11 18:07:30 pepe kernel: 95749545 <=3D=3D acxpci_l_alloc_tx > >=20 > > Maybe add more logging here, so that we can see entire > > tx ring - maybe use log_txbuffer()? >=20 > Done. >=20 > > It looks like timestamp, beacon_interval, cap fields are still there. >=20 > Oops. Gone now. For real. >=20 > >=20 > > Dec 11 18:07:28 pepe kernel: 95748216 =3D=3D> acxpci_i_interrupt > > Dec 11 18:07:28 pepe kernel: IRQ type:0009, mask:D9F5, type & ~mask:0008 > > Dec 11 18:07:28 pepe kernel: got Rx_Complete IRQ > > Dec 11 18:07:28 pepe kernel: 95748216 =3D=3D> acxpci_l_process_rxdesc > > Dec 11 18:07:28 pepe kernel: rx: buf 0 full > > Dec 11 18:07:28 pepe kernel: rx: tail=3D1 Ctl_16=3D0080 Status=3D800000= 00 > > Dec 11 18:07:28 pepe kernel: rx: MGMT/ProbeResp time:30176354 len:75=20 > signal:86 SNR:0 macstat:03 phystat:80 phyrate:10 status:1 > > Dec 11 18:07:28 pepe kernel: rx: 802.11 buf[75]: 50 00 3A 01 00 80 C8 0= 6=20 > 58 7F 00 80 5A 29 08 4B > > Dec 11 18:07:28 pepe kernel: 00 80 5A 29 08 4B 60 71 BD E6 15 1E 00 00= =20 > 00 00 > > Dec 11 18:07:28 pepe kernel: 64 00 31 00 00 07 62 61 72 72 65 72 6F 01= =20 > 04 82 > > Dec 11 18:07:28 pepe kernel: 84 8B 96 03 01 06 04 06 00 02 00 00 00 00= =20 > 2A 01 > > Dec 11 18:07:28 pepe kernel: 02 32 08 0C 12 18 24 30 48 60 6C > >=20 > > Whee, you are getting responses! :) >=20 > And that's all I'm gonna do apparently. >=20 > When I've use the USB driver with this, on rmmod, it logs that there was = a=20 > timeout on unlink, which means something's really wrong. >=20 > Log with the txbuffers attached. Dec 12 17:20:38 pepe kernel: matching station found: 00:80:5A:29:08:4B, joi= ning Dec 12 17:20:38 pepe kernel: 99291459 =3D=3D> acx_l_transmit_authen1 Dec 12 17:20:38 pepe kernel: sending authentication1 request, awaiting resp= onse Dec 12 17:20:38 pepe kernel: 99291459 =3D=3D> acxpci_l_alloc_tx Dec 12 17:20:38 pepe kernel: acx: BUG: tx_head:0 Ctl8:0x41 - failed to find= free txdesc Dec 12 17:20:38 pepe kernel: tx: desc->Ctl8's: 41 C8 8E 8E 8E 8E 8E 8E 8E 8= E 8E 8E 8E 8E 8E 8E Dec 12 17:20:38 pepe kernel: 99291459 <=3D=3D acxpci_l_alloc_tx Dec 12 17:20:38 pepe kernel: 99291459 <=3D=3D acx_l_transmit_authen1: 0= 0000001 txdesc has ACXDONE and SHORT_PREAMBLE (?!) bits set: #define DESC_CTL_SHORT_PREAMBLE 0x01 /* preamble type: 0 =3D long; 1 =3D= short */ #define DESC_CTL_FIRSTFRAG 0x02 /* this is the 1st frag of the fram= e */ #define DESC_CTL_AUTODMA 0x04 #define DESC_CTL_RECLAIM 0x08 /* ready to reuse */ #define DESC_CTL_HOSTDONE 0x20 /* host has finished processing */ #define DESC_CTL_ACXDONE 0x40 /* acx has finished processing */ /* host owns the desc [has to be released last, AFTER modifying all other d= esc fields!] */ #define DESC_CTL_HOSTOWN 0x80 This doesn't look good at all. Firmware's tx path is really upset. Can anyone sniff whether Windows driver sends probe requests? =2D- vda |