> From: Don Bowman [mailto:don@;sandvine.com]
> In bge_rxeof(), there can end up being a condition which causes
> the driver to endlessly interrupt.
>
> if (bge_newbuf_std(sc, sc->bge_std, NULL) == ENOBUFS) {
> ifp->if_ierrors++;
> bge_newbuf_std(sc, sc->bge_std, m);
> continue;
> }
>
> happens. Now, bge_newbuf_std returns ENOBUFS. 'm' is also NULL.
> This causes the received packet to not be dequeued, and the driver
> will then go straight back into interrupt as the chip will
> reassert the interrupt as soon as we return.
More information... It would appear that we're looping here
in the rx interrupt, the variable 'stdcnt' which counts
the number of standard-sized packets pulled off per iteration
is huge (indicating we've overrun the ring multiple times).
while(sc->bge_rx_saved_considx !=
sc->bge_rdata->bge_status_block.bge_idx[0].bge_rx_prod_idx) {
is the construct that controls when we exit the loop. Clearly
in my case this is never becoming false.
I see 'sc->bge_rx_saved_considx' as 201, and the RHS of the
expression as 38442. This doesn't seem correct, I think that
both numbers must be <= BGE_SSLOTS.
(kgdb) p/x *cur_rx
$10 = {bge_addr = {bge_addr_hi = 0x0, bge_addr_lo = 0xca2d802},
bge_len = 0x4a, bge_idx = 0xc8, bge_flags = 0x7004, bge_type = 0x0,
bge_tcp_udp_csum = 0x9992, bge_ip_csum = 0xffff, bge_vlan_tag = 0x0,
bge_error_flag = 0x0, bge_rsvd = 0x0, bge_opaque = 0x0}
Any suggestions anyone?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
