Re: [PATCH,RFC] Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)

[Lennert Buytenhek <buytenh@wantstofly.org>]

On Sun, Aug 20, 2006 at 11:35:58PM +0200, Francois Romieu wrote:

> > 2. SYSErr asserts pretty soon after upping eth0, and the PCI status
> >    register reports a parity error when this happens.  In this case,
> >    the restart logic seems to make things worse, and in fact, when
> >    commenting it out, things work a lot better.
> 
> [snip]
> 
> 2 - I have already experienced SYSErr storms on startup. If memory serves me
>     right, they were "cured" simply by disabling a bit in the irq mask
>     (not sure if it was SYSErr, RxOverflow or RxFIFOOver though).
> 
> Can you try against -rc4:
> 1) the serie at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc4/r8169
>    There is a minor difference in the init of Realtek's driver for the 8110sb
>    (patch 011). It could hurt different chipset but it should do no harm to
>    the 8110sb.
> 2) same as 1) + your hunk below:
> @@ -484,7 +488,7 @@ static int rtl8169_poll(struct net_devic
>  #endif
>  
>  static const u16 rtl8169_intr_mask =
> -	SYSErr | LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
> +	LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
>  static const u16 rtl8169_napi_event =
>  	RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr;
>  static const unsigned int rtl8169_rx_config =
> 3) same as 2) + your TxDesc change.

I tried your series from step (1) plus my TxDesc change (so I didn't
include the hunk from (2)), and that seems to work fine.  I.e. I don't
need to disable error interrupts anymore to keep it working.

So really the only thing that would need addressing would be the TXDesc
MMIO bug (either by using I/O accesses, or doing the top/bottom writes
the other way round) and we can dump the vendor driver.

Thanks a lot!


cheers,
Lennert