rtl8139 pci mem freeze (more info)

Donald Becker becker@tidalwave.net
Thu Sep 30 18:37:12 1999


On Thu, 30 Sep 1999, Daniel Kobras wrote:
> On Thu, 30 Sep 1999, Donald Becker wrote:
> > > +	outl_f(dev->dev_addr[0], ioaddr + MAC0);
> > > +	outl(dev->dev_addr[4], ioaddr + MAC0 + 4);

> > This is incorrect -- you are only writing one byte of the station address.
> > I think that the proper code is
> > 	outl(cpu_to_le32(*(u32*)(dev->dev_addr + 0)), ioaddr + MAC0 + 0);
> > 	outl(cpu_to_le32(*(u32*)(dev->dev_addr + 4)), ioaddr + MAC0 + 4);
> 
> Hm... I admit I always get terribly confused when it comes to endianness
> issues but isn't the LE ordering already enforced by the fact that
> dev_addr is a u8[] rather than a u32[]?

The endian conversion is confusing.  The typical big-endian PCI bus
implementation orders the bytes so that host writes of addresses and
integers are correct.  When the card does bus-master operations the bytes
are ordered (reversed) so that byte streams are in the correct order, but
addresses and integers are byte reversed.

The RTL8139 doesn't have in-memory descriptors.  It's simplicity makes it
one of the easiest designs to convert to big-endian.  The only endian
conversion is on the data read from the EEPROM, the Rx status the chip
writes to memory, and perhaps generating the multicast filter.

When we do *(u32*)dev_addr on a big-endian we end up with dev_addr[0] in the
high byte, rather than the low byte where it should be on the little-endian
PCI bus.

> > > -		outw(cur_rx - 16, ioaddr + RxBufPtr);
> > > +		outw_f(cur_rx - 16, ioaddr + RxBufPtr);
> > 
> > This is very curious.  It makes me suspicious about what the motherboard
> > chipset is doing to the writes if this doesn't work correctly.
> 
> I'm puzzled as well. That's why I was extra careful that this change 
> indeed fixed the problem before sending out the patch. It did, but I don't
> have the faintest idea as to why. So I guess there are still possible
> lockups hidden in the driver (on certain chipsets). 

Does reading any register avoid the hang, or must it be RxBufPtr?


 | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
 |  body of the mail, include only the text:
 |   unsubscribe this-list-name youraddress@wherever.org
 | You will be unsubscribed as speedily as possible.