Re: [patch 10/10] forcedeth: work around NULL skb dereference crash
* Ayaz Abdulla [EMAIL PROTECTED] wrote: I had responded eariler to the thread asking you to try out the patch found in bug 8058: http://bugzilla.kernel.org/show_bug.cgi?id=8058 I believe that is the caush of the NULL skb dereference issue. there's a different type of regression now: under high load i dont get a crash, i get a hung interface instead. No error packets or other weird interface state - just a hung interface. The condition happens after a stream of: eth1: too many iterations (6) in nv_nic_irq. eth1: too many iterations (6) in nv_nic_irq. eth1: too many iterations (6) in nv_nic_irq. eth1: too many iterations (6) in nv_nic_irq. eth1: too many iterations (6) in nv_nic_irq. If i increase max_interrupt_work from 5 to 50 to paper over this condition then the hangs go away. So i suspect there might still be a queue-wakeup problem in one of these paths - or that a filled up tx ring somehow gets stuck. (and i've got commits 3ba4d093fe8a26f and fcc5f2665c81e08, so all the latest stuff that is upstream at the moment) Ingo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 10/10] forcedeth: work around NULL skb dereference crash
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: Ingo Molnar [EMAIL PROTECTED] work around a NULL skb dereference crash that occurs during high load. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] Cc: Ayaz Abdulla [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] ping? No reaction from the forcedeth.c maintainer, yet. Ingo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 10/10] forcedeth: work around NULL skb dereference crash
I had responded eariler to the thread asking you to try out the patch found in bug 8058: http://bugzilla.kernel.org/show_bug.cgi?id=8058 I believe that is the caush of the NULL skb dereference issue. Thanks, Ayaz -Original Message- From: Ingo Molnar [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 4:53 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; Ayaz Abdulla Subject: Re: [patch 10/10] forcedeth: work around NULL skb dereference crash * [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: Ingo Molnar [EMAIL PROTECTED] work around a NULL skb dereference crash that occurs during high load. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] Cc: Ayaz Abdulla [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] ping? No reaction from the forcedeth.c maintainer, yet. Ingo --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 10/10] forcedeth: work around NULL skb dereference crash
* Ayaz Abdulla [EMAIL PROTECTED] wrote: I had responded eariler to the thread asking you to try out the patch found in bug 8058: http://bugzilla.kernel.org/show_bug.cgi?id=8058 I believe that is the caush of the NULL skb dereference issue. ah, sorry - i checked the wrong thread for your mail! (btw., could you please bump the default for max_interrupt_work up from 6 to at least 30? Bursts of 30 packets isnt hard to trigger, it happens commonly on my box - and 6 are trivial to trigger and the messages look quite alarming to the untrained eye and the condition also hurts performance. Thanks!) Ingo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
