Hi!
After upgrading from rc8 to final 2.6.29 my machine's network stops working
after some full speed (100Mb/s) downloads ifdown;ifup, or powering off the
switch won't solve the problem, however it is solved if I unload the driver
module and load it again. Tested with another NIC (e1000e based) and
couldn't reproduce the problem.
This is happening on final 2.6.29 version but doesn't seem to happen on rc8
with the same kernel config. Machine is a AMD Athlon 64 running Debian 64
bits.
I don't see any changes on the git for uli526x from rc8 to final, but the
tulip driver on which this one is based had some changes.
Don't know what else to add, just ask me for whatever data that may help on
this.
Regards...
--
Manty/BestiaTester -> http://manty.net
Santiago Garcia Mantinan a ?crit :
> Hi!
>
> After upgrading from rc8 to final 2.6.29 my machine's network stops working
> after some full speed (100Mb/s) downloads ifdown;ifup, or powering off the
> switch won't solve the problem, however it is solved if I unload the driver
> module and load it again. Tested with another NIC (e1000e based) and
> couldn't reproduce the problem.
>
> This is happening on final 2.6.29 version but doesn't seem to happen on rc8
> with the same kernel config. Machine is a AMD Athlon 64 running Debian 64
> bits.
>
> I don't see any changes on the git for uli526x from rc8 to final, but the
> tulip driver on which this one is based had some changes.
>
> Don't know what else to add, just ask me for whatever data that may help on
> this.
>
> Regards...
Hi
This is a known problem, and a fix should be available very soon for 2.6.29.1
http://www.spinics.net/lists/netdev/msg92829.html
You can check net/core/dev.c function process_backlog() should get this
updated version :
static int process_backlog(struct napi_struct *napi, int quota)
{
int work = 0;
struct softnet_data *queue = &__get_cpu_var(softnet_data);
unsigned long start_time = jiffies;
napi->weight = weight_p;
do {
struct sk_buff *skb;
local_irq_disable();
skb = __skb_dequeue(&queue->input_pkt_queue);
if (!skb) {
list_del(&napi->poll_list);
clear_bit(NAPI_STATE_SCHED, &napi->state);
local_irq_enable();
break;
}
local_irq_enable();
napi_gro_receive(napi, skb);
} while (++work < quota && jiffies == start_time);
napi_gro_flush(napi);
return work;
}
Hi Manty,
Santiago Garcia Mantinan wrote:
> After upgrading from rc8 to final 2.6.29 my machine's network stops
> working after some full speed (100Mb/s) downloads ifdown;ifup, or
> powering off the switch won't solve the problem, however it is solved if
> I unload the driver module and load it again. Tested with another NIC
> (e1000e based) and couldn't reproduce the problem.
Known issue probably. Try: http://lkml.org/lkml/2009/3/25/217
Cheers,
FJP
> Known issue probably. Try: http://lkml.org/lkml/2009/3/25/217
Yes, seems related, I'm testing that patch right now on my machine, but I'm
wondering if I should test that one or this one
(http://www.spinics.net/lists/netdev/msg92829.html) sent also by Herbert to
the netdev list but at a later time. I'll try test the second one also just
in case.
Regards...
--
Manty/BestiaTester -> http://manty.net
On Friday 27 March 2009, Santiago Garcia Mantinan wrote:
> > Known issue probably. Try: http://lkml.org/lkml/2009/3/25/217
>
> Yes, seems related, I'm testing that patch right now on my machine, but
> I'm wondering if I should test that one or this one
> (http://www.spinics.net/lists/netdev/msg92829.html) sent also by
> Herbert to the netdev list but at a later time. I'll try test the
> second one also just in case.
No, the plain revert is safer.
If you want to test another patch, you should probably try this one
instead, which AFAIK is the best real fix available:
http://lkml.org/lkml/2009/3/26/79
Cheers,
FJP
> > > Known issue probably. Try: http://lkml.org/lkml/2009/3/25/217
> > Yes, seems related, I'm testing that patch right now on my machine, but
> > I'm wondering if I should test that one or this one
> > (http://www.spinics.net/lists/netdev/msg92829.html) sent also by
> > Herbert to the netdev list but at a later time. I'll try test the
> > second one also just in case.
> No, the plain revert is safer.
Ok, I have tested both during quite a long time (hours compared to the few
minutes it took the system to hang before) and both patches seem to work ok,
I'll stick with the first one following your recommendations.
Thanks!
--
Manty/BestiaTester -> http://manty.net