From: Denis V. <vd...@il...> - 2005-09-11 09:55:17
|
On Saturday 10 September 2005 18:07, Marcelo Bezerra wrote: > On Sat, Sep 10, 2005 at 02:14:37PM +0300, Denis Vlasenko wrote: > > On Saturday 10 September 2005 04:22, Marcelo Bezerra wrote: > > Awwww pity you did not insert yet another dump() > > inside acxpci_l_tx_data() > > > > tx_desc->tx_time = cpu_to_le32(jiffies); > > wmb(); /* make sure all descr writes finish before we tell the adapter that it's its turn now */ > > <==================================== HERE > > acx_write_reg16(priv, IO_ACX_INT_TRIG, INT_TRIG_TXPRC); > > acx_write_flush(priv); > > > > That would allow us to know exact txdesc contents before we hand it to acx. > > Can you do this and retest? > > New log file with proposed changes @ http://mosca.yi.org/~mosca/acx2.log > > > Sep 9 22:12:22 localhost kernel: 100325699 <== acxpci_l_tx_data > > ... > > > > > > Next time we see it (when it returns from acx tx engine processing), it has > > botched hostdesc ptr: > > > > > > Sep 9 22:12:25 localhost kernel: 1003264df ==> acx_i_interrupt > > Sep 9 22:12:25 localhost kernel: 1003264df ==> acx_l_clean_tx_desc > > Sep 9 22:12:25 localhost kernel: tx: cleaning up bufs from 0 > > Sep 9 22:12:25 localhost kernel: txdesc @ffffc20000292dd4: pNextDesc=12E08 HostMemPtr=13000 AcxMemPtr=0 > > tx_time=0 total_length=1E Reserved=1 dummy[16]=12AAC328,FFFF8100,13000,FF8100 Ctl_8=C0 Ctl2_8=0 error=0 > > ^^^^^^^^^^^^ > > ack_failures=0 rts_failures=8F rts_ok=49 u.r2.rate111=1 queue_info=0 acx111_tail=0 > > Sep 9 22:12:25 localhost kernel: tx: cleaned 0: !ACK=0 !RTS=143 RTS=73 r111=0001 > > > > > > Cleaning procedure doesn't care, but next acx_i_start_xmit() does: > > > > > > Sep 9 22:12:48 localhost kernel: 10032bab6 ==> acx_i_start_xmit > > Sep 9 22:12:48 localhost kernel: 10032bab7 ==> acxpci_l_alloc_tx > > Sep 9 22:12:48 localhost kernel: tx: got desc 0, 31 remain > > Sep 9 22:12:48 localhost kernel: 10032bab7 <== acxpci_l_alloc_tx > > Sep 9 22:12:48 localhost kernel: txdesc @ffffc20000292dd4: pNextDesc=12E08 HostMemPtr=13000 AcxMemPtr=0 tx_time=0 total_length=1E Reserved=1 dummy[16]=12AAC328,FFFF8100,13000,FF > > 8100 Ctl_8=80 Ctl2_8=0 error=0 ack_failures=0 rts_failures=0 rts_ok=0 u.r2.rate111=1 queue_info=0 acx111_tail=0 > > Sep 9 22:12:48 localhost kernel: CORRUPTION DETECTED! hostdesc=00ff810000013000 > > > > > > Also you can add a hack into acx_l_clean_tx_desc(): > > > > ??????if ( ((long)pTxDesc.fixed_size.s.host_desc >> 48) == 0x00ff) { > > void *old = pTxDesc.fixed_size.s.host_desc; > > pTxDesc.fixed_size.s.host_desc = (void*) ( ((long)old) || (0xff000000L << 32) ); > > printk("CORRUPTION DETECTED txdesc @%p! fixing hostdesc_ptr: %p -> %p\n", pTxDesc, old, pTxDesc.fixed_size.s.host_desc); > > ??????} > > > > which "patches back in" correct hostdesc ptr. Tell us whether it helps. > > I added this right affter the txdesc dump in the next: label > > #ifdef __x86_64__ > if ( ((long)(pTxDesc->fixed_size.s.host_desc) >> 48) == 0x00ff) { > void *old = pTxDesc->fixed_size.s.host_desc; > pTxDesc->fixed_size.s.host_desc = (void*) ( ((long)old) | (0xff000000L << 32) ); > printk("CORRUPTION DETECTED txdesc @%p! fixing hostdesc_ptr: %p -> %p\n", pTxDesc, old, pTxDesc->fixed_size.s.host_desc); > } > #endif > > Does this makes things clearer? > I guess we could add this as a temp. workarround to the next snapshots. Maybe with #if defined(__x86_64__) && LINUX_VERSION_CODE > KERNEL_VERSION(2,6,10) This hack is too ugly for words, let alone for inclusion in the driver in any form. Let's just stop using that area of txdesc. struct txdesc { acx_ptr pNextDesc ACX_PACKED; /* pointer to next txdesc */ acx_ptr HostMemPtr ACX_PACKED; /* 0x04 */ acx_ptr AcxMemPtr ACX_PACKED; /* 0x08 */ u32 tx_time ACX_PACKED; /* 0x0c */ u16 total_length ACX_PACKED; /* 0x10 */ u16 Reserved ACX_PACKED; /* 0x12 */ /* The following 16 bytes do not change when acx100 owns the descriptor */ /* BUG: fw clears last byte of this area which is supposedly reserved ** for driver use. amd64 blew up. We dare not use it now */ u32 dummy[4] ACX_PACKED; > With this correction, it exibited the same behavior as 2.6.10, doesn't oops, Please try acx-20050912. Will be at http://195.66.192.167/linux/acx_patches/ tomorrow. If you are impatient, http://195.66.192.167/linux/acx_patches/current/ > but fails @ radio recalibration. -- vda |