82574L hangs (with r233708 e1000 driver).

[Konstantin Belousov]

On Thu, Apr 12, 2012 at 03:40:27PM -0400, Ryan Stone wrote:
> On Thu, Apr 12, 2012 at 2:38 PM, Konstantin Belousov
> <kostikbel at gmail.com> wrote:
> > And, on receive, the atom board does receive interrupts, em0:rx 0 counter
> > in vmstat -i increases. Even more fun, the sysctl dev.em.0.debug
> > shows increasing hw rdh (as I understand, this is hardware 'last
> > received' packet pointer for rx ring). So I looked at the packet
> > descriptor at hw rdt index, and there I see
> > (kgdb) p/x ((struct adapter *)0xffffff80010e4000)->rx_rings->rx_base[78]
> > $11 = {buffer_addr = 0x12a128800, length = 0x5ea, csum = 0x3c2b, status = 0x0,
> >  errors = 0x0, special = 0x0}
> 
> This looks like a buffer address, not a written-back
What do you reference by 'This' ? 0x12a128800 is indeed buffer address,
because it is the content of the first eight bytes of the descriptor.

The next descriptor in the ring had the status 0x63, which is quite
reasonable value for filled descriptor.

> descriptor(0x12a128800 being aligned to a 2048 byte boundary is a big
> clue).  Is it easy to check the mbuf in
> rx_rings->rx_buffers[78].m_head and see whether the buffer in the mbuf
> there has that physical address?
Probably so, I will recheck later today.

> 
> If that is a buffer address then the driver must be updating
> descriptors in rx_base that are owned by hardware, or somehow
> forgetting to update rdt and rxr->next_to_check.
Yes, there is a bug somewhere.

On the other hand, it is very specific to exactly this model and
might be a revision, because I have tons of em interfaces working
flawlessly with the same version of the driver.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20120413/d0ffdff4/attachment.pgp