Re: problems with em(4) since update to driver 7.2.2

From: Jack Vogel <jfvogel_at_gmail.com>
Date: Wed, 4 May 2011 23:59:18 -0700
OK, but what this does not explain is why I do not see this if
its so easily reproduced, what causes the failure case, any idea?

As I said, given the code was not feasible for igb anyway I would not
be unhappy about returning to the old way of doing things.

Jack


On Wed, May 4, 2011 at 11:03 PM, Arnaud Lacombe <lacombar_at_gmail.com> wrote:

> Hi,
>
> On Thu, May 5, 2011 at 1:20 AM, Arnaud Lacombe <lacombar_at_gmail.com> wrote:
> > Hi,
> >
> > On Wed, May 4, 2011 at 5:38 PM, Jack Vogel <jfvogel_at_gmail.com> wrote:
> >> I have had my validation engineer busy all day, we have tried both
> >> a 9 kernel as well as 8.2,  using the code from HEAD, and we
> >> cannot reproduce this problem.
> >>
> > Actually, it can be trivially reproduced by tainting `error'. As it is
> > uninitialized in HEAD, it's value can be _anything_, so let's mark it
> > as explicitly invalid.
> >
> > diff -u ./if_em.c /data/src/freebsd/em-7.2.2/src/if_em.c
> > --- ./if_em.c   2011-02-18 01:18:23.000000000 -0500
> > +++ /data/src/freebsd/em-7.2.2/src/if_em.c      2011-05-05
> > 01:12:01.000000000 -0400
> > _at__at_ -3912,7 +3912,7 _at__at_
> >        struct  adapter         *adapter = rxr->adapter;
> >        struct em_buffer        *rxbuf;
> >        bus_dma_segment_t       seg[1];
> > -       int                     i, j, nsegs, error;
> > +       int                     i, j, nsegs, error = -1;
> >
> > The error pointed out in this thread pops up in the next boot.
> >
> I put a call to kdb_enter() at the beginning of the function, helped
> with some textdump I got all the backtrace [0] for all the time
> em_setup_receive_ring() is called. All are exactly the same:
>
> kdb_enter_why(0,c09f6511,f391aaa8,c09be1e2,c09f6511,...) at
> kdb_enter_why+0x3b
> kdb_enter(c09f6511,0,3810,ffffffff,5dc,...) at kdb_enter+0x19
> em_setup_receive_ring(c3c8d600,c3c8d7a4,c3c96004,310000fa,c3c8d600,...)
> at em_setup_receive_ring+0x22
> em_setup_receive_structures(c3c96000,f15f2000,38,8100,3,...) at
> em_setup_receive_structures+0x26
> em_init_locked(c3c96000,0,c09f5de5,414,10000,...) at em_init_locked+0x2f2
> em_ioctl(c3c7d000,80206934,c3ce9d00,c07b7a0b,c3f2a230,...) at
> em_ioctl+0x1c3
> ifhwioctl(c3f2a230,f391ac34,c07b7a0b,c3f3e3d0,c08df1c0,...) at
> ifhwioctl+0x4b8
> ifioctl(c3f3e3d0,80206934,c3ce9d00,c3f2a230,c3f2a230,...) at ifioctl+0x82
> kern_ioctl(c3f2a230,3,80206934,c3ce9d00,c3ce9d00,...) at kern_ioctl+0xa8
> ioctl(c3f2a230,f391acf8,c,c,f391ad2c,...) at ioctl+0xc5
> syscall(f391ad38) at syscall+0x17d
> Xint0x80_syscall() at Xint0x80_syscall+0x20
> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x4816ee23, esp =
> 0xbfbfe67c, ebp = 0xbfbfe698 ---
>
> This fully explain why the main loop in em_setup_receive_ring() is
> never entered, as we always verify `j == rxr->next_to_check' (provided
> that mbuf have been refreshed if some packet were transfered) and
> return the value on the stack. As of now, beside changing the
> call-site of em_setup_receive_ring() to ensure it is never re-entered,
> I'd guess that the patch I sent earlier today, is the only way to
> ensure that no junk is returned.
>
> I'd guess that the driver _is_ able to transmit, if the code was not
> explicitly calling em_stop() upon em_setup_receive_structures()
> failure.
>
>  - Arnaud
>
> [0]: I wish that would have been as easy as in Linux, where a WARN()
> call do all the job automatically, but still, I should not hope for
> that much unless I am the one implementing it ... yes, free whining,
> it's 2a.m. ...
>
> >  - Arnaud
> >
> >> The data your netstat -m shows suggests to me that what's happening
> >> is somehow setup of the receive ring is running more than once maybe??
> >>
> >> You asked at one point how this could go into STABLE, well, because
> >> not only here at Intel, but at lots of external customers this code has
> been
> >> used and tested thoroughly.
> >>
> >> I am not calling into question your problem, but until I understand what
> it
> >> is I cannot "fix" it :)
> >>
> >> The thing I am guessing right now is the culprit is the setup code, the
> >> reason
> >> is that when I ported to the igb driver I found that it did not work on
> our
> >> newer
> >> hardware, and so I went back to the older version of setup for igb. Now,
> >> even
> >> though I have not seen hardware fail with em, maybe there is some.
> >>
> >> To help me give me a complete pciconf -lv, and if its a namebrand system
> >> tell me that, including all hardware in it.
> >>
> >> If you like Olivier I can make a version of em for you that also reverts
> the
> >> setup code the way I did for igb, see if that fixes it for you?
> >>
> >> Thanks for your patience,
> >>
> >> Jack
> >> _______________________________________________
> >> freebsd-current_at_freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "
> freebsd-current-unsubscribe_at_freebsd.org"
> >>
> >
>
Received on Thu May 05 2011 - 04:59:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:13 UTC