e1000: assertion hit in e1000_clean(), kernel 2.6.21.1

e1000: assertion hit in e1000_clean(), kernel 2.6.21.1

[Chuck Ebbert]

We have several reports now of hitting this assertion in
netif_rx_complete(), inlined in e1000_clean():

        BUG_ON(!test_bit(__LINK_STATE_RX_SCHED, &dev->state));

 [<c0431162>] __queue_work+0x51/0x5e
 [<c059eea1>] et_rx_action+0x94/0x185
 [<c042837d>] __do_softirq+0x5d/0xba
 [<c0407837>] do_softirq+0x59/0xb1
 [<c04281e9>] local_bh_enable_ip+0x35/0x40
 [<c059e46b>] dev_open+0x44/0x62
 [<c059ce8c>] dev_change_flags+0x46/0xe3
 [<c05d9e09>] devinet_ioctl+0x250/0x56a

The second function is "net_rx_action", corrupted
by the serial connection. 

The source file has four extra lines at the top because of a
trivial wireless patch, so 898 in that code is really 894 in
the stock kernel.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240339

Re: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1

[Kok, Auke]

Chuck Ebbert wrote:
> We have several reports now of hitting this assertion in
> netif_rx_complete(), inlined in e1000_clean():
> 
>         BUG_ON(!test_bit(__LINK_STATE_RX_SCHED, &dev->state));
> 
>  [<c0431162>] __queue_work+0x51/0x5e
>  [<c059eea1>] et_rx_action+0x94/0x185
>  [<c042837d>] __do_softirq+0x5d/0xba
>  [<c0407837>] do_softirq+0x59/0xb1
>  [<c04281e9>] local_bh_enable_ip+0x35/0x40
>  [<c059e46b>] dev_open+0x44/0x62
>  [<c059ce8c>] dev_change_flags+0x46/0xe3
>  [<c05d9e09>] devinet_ioctl+0x250/0x56a
> 
> The second function is "net_rx_action", corrupted
> by the serial connection. 
> 
> The source file has four extra lines at the top because of a
> trivial wireless patch, so 898 in that code is really 894 in
> the stock kernel.

please shared that code then.

> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240339

this is lacking a lot of debugging info. Please post *all* the dmesg output, 
lspci -vvv, ethtool -e ethX, etc. in the bugzilla.

Auke

Re: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1

[Curtis Doty]

4:03pm Kok, Auke said:

> Chuck Ebbert wrote:
>>  We have several reports now of hitting this assertion in
>>  netif_rx_complete(), inlined in e1000_clean():
>>
>>          BUG_ON(!test_bit(__LINK_STATE_RX_SCHED, &dev->state));
>>
>>   [<c0431162>] __queue_work+0x51/0x5e
>>   [<c059eea1>] et_rx_action+0x94/0x185
>>   [<c042837d>] __do_softirq+0x5d/0xba
>>   [<c0407837>] do_softirq+0x59/0xb1
>>   [<c04281e9>] local_bh_enable_ip+0x35/0x40
>>   [<c059e46b>] dev_open+0x44/0x62
>>   [<c059ce8c>] dev_change_flags+0x46/0xe3
>>   [<c05d9e09>] devinet_ioctl+0x250/0x56a
>>
>>  The second function is "net_rx_action", corrupted
>>  by the serial connection.
>>  The source file has four extra lines at the top because of a
>>  trivial wireless patch, so 898 in that code is really 894 in
>>  the stock kernel.
>
> please shared that code then.
>

http://cvs.fedora.redhat.com/viewcvs/devel/kernel/linux-2.6-wireless.patch

Re: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1

[Herbert Xu]

Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>
>> The source file has four extra lines at the top because of a
>> trivial wireless patch, so 898 in that code is really 894 in
>> the stock kernel.
> 
> please shared that code then.

I've had a look and e1000 is definitely buggy.

The problem is that you're calling netif_poll_enable on startup.
This is *wrong*.

netif_poll_enable can only be called if you've previously called
netif_poll_disable.  Otherwise a poll might already be in action
and you may get a crash like this.

So perhaps you should divide e1000_up into two sections, one that
is called on both start and restart and another which is only
called on restart (i.e., after e1000_down).

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1

[Kok, Auke]

Herbert Xu wrote:
> Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>>> The source file has four extra lines at the top because of a
>>> trivial wireless patch, so 898 in that code is really 894 in
>>> the stock kernel.
>> please shared that code then.
> 
> I've had a look and e1000 is definitely buggy.
> 
> The problem is that you're calling netif_poll_enable on startup.
> This is *wrong*.
> 
> netif_poll_enable can only be called if you've previously called
> netif_poll_disable.  Otherwise a poll might already be in action
> and you may get a crash like this.
> 
> So perhaps you should divide e1000_up into two sections, one that
> is called on both start and restart and another which is only
> called on restart (i.e., after e1000_down).

OK, that would explain the recent frenzy of reports in this matter. That code 
was only recently merged. I will dig into this and get a patch out as soon as I 
can so you can test this.

Thanks Herbert.

Auke