af_packet: Don't use skb after dev_queue_xmit()
in [Kernel]
|
Prev: New HID device Philips Remote RC 153_Vista
Next: tpm_infineon: Fix suspend/resume handler for pnp_driver
From: Michael Breuer on 8 Jan 2010 23:50 On 1/8/2010 4:48 PM, Michael Breuer wrote: > On 1/8/2010 4:29 PM, Jarek Poplawski wrote: > ... >> BTW, don't hurry with that yet, but in the next test, please try >> alternative 2 again (i.e. with MMAP + no DMAR + disable_msi). >> > Will do - still up from yesterday... no more dropped packets... none > of the dns errors either. To be expected I suppose as long as I'm > trying to sniff it. Assuming no immediate erorrs with alt2, no DMAR + > disable_msi I'll report back after it's been up for a while. > -- Ok - ran alt1 and alt2, both with MMAP, no DMAR and disable_msi. Both seem to behave similarly. No logged errors; large numbers of dropped RX packets. One odd thing: when driving every sort of traffic through, I was able to hose the client adapter (win7) repeatedly by runnnig the win7 backup and connecting Windows Media Player to a Mediatomb stream while also running a remote X11 session. Looks like the SSDP traffic that occurs at the same time as the SMB traffic and X11 traffic takes out the adapter on Win7 - Nforce. Reran with msi enabled, MMAP and no DMAR. Also no errors; much faster, and the Win7 side survives the same conditions that don't work when msi is disabled. Doesn't make sense to me, but it is what it is. Going to leave this up for a while and see if things remain functional. > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Breuer on 9 Jan 2010 00:50 On 1/8/2010 11:45 PM, Michael Breuer wrote: > On 1/8/2010 4:48 PM, Michael Breuer wrote: >> On 1/8/2010 4:29 PM, Jarek Poplawski wrote: >> ... >>> BTW, don't hurry with that yet, but in the next test, please try >>> alternative 2 again (i.e. with MMAP + no DMAR + disable_msi). >>> >> Will do - still up from yesterday... no more dropped packets... none >> of the dns errors either. To be expected I suppose as long as I'm >> trying to sniff it. Assuming no immediate erorrs with alt2, no DMAR + >> disable_msi I'll report back after it's been up for a while. >> -- > Ok - ran alt1 and alt2, both with MMAP, no DMAR and disable_msi. Both > seem to behave similarly. No logged errors; large numbers of dropped > RX packets. One odd thing: when driving every sort of traffic through, > I was able to hose the client adapter (win7) repeatedly by runnnig the > win7 backup and connecting Windows Media Player to a Mediatomb stream > while also running a remote X11 session. Looks like the SSDP traffic > that occurs at the same time as the SMB traffic and X11 traffic takes > out the adapter on Win7 - Nforce. > Reran with msi enabled, MMAP and no DMAR. Also no errors; much faster, > and the Win7 side survives the same conditions that don't work when > msi is disabled. Doesn't make sense to me, but it is what it is. > Tracked it down - this appears to be result of Win7 enabling "EnableDeadGWDetect" by default. Long story short, if this is set and a packet sent to the gw is retransmitted more than, 1/2 the value of maxdataretransmissions (default of 5), then the gateway is declared dead and the next one selected. If there is only one gateway, then the default gateway is effectively removed. So under load where the server is the default gateway, this is not a surprising result. With msi enabled, the system responds better, fewer retransmissions, no dropping the link. > Going to leave this up for a while and see if things remain functional. >> To unsubscribe from this list: send the line "unsubscribe >> linux-kernel" in >> the body of a message to majordomo(a)vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jarek Poplawski on 9 Jan 2010 07:30 On Fri, Jan 08, 2010 at 11:45:35PM -0500, Michael Breuer wrote: > On 1/8/2010 4:48 PM, Michael Breuer wrote: > >On 1/8/2010 4:29 PM, Jarek Poplawski wrote: > >... > >>BTW, don't hurry with that yet, but in the next test, please try > >>alternative 2 again (i.e. with MMAP + no DMAR + disable_msi). > >> > >Will do - still up from yesterday... no more dropped packets... > >none of the dns errors either. To be expected I suppose as long as > >I'm trying to sniff it. Assuming no immediate erorrs with alt2, no > >DMAR + disable_msi I'll report back after it's been up for a > >while. > >-- > Ok - ran alt1 and alt2, both with MMAP, no DMAR and disable_msi. > Both seem to behave similarly. No logged errors; Ok - since alt2 introduces less changes and is acked by Stephen already, I'll resend it with your "Tested-by" in a new thread to clear things a bit. > large numbers of dropped RX packets. You might try some tweaking with another sky2 parameter "copybreak" or even editing its "NAPI_WEIGHT" variable. > One odd thing: when driving every sort of > traffic through, I was able to hose the client adapter (win7) > repeatedly by runnnig the win7 backup and connecting Windows Media > Player to a Mediatomb stream while also running a remote X11 > session. Looks like the SSDP traffic that occurs at the same time as > the SMB traffic and X11 traffic takes out the adapter on Win7 - > Nforce. > Reran with msi enabled, MMAP and no DMAR. Also no errors; much > faster, and the Win7 side survives the same conditions that don't > work when msi is disabled. Doesn't make sense to me, but it is what > it is. > > Going to leave this up for a while and see if things remain functional. It looks like DMAR is the main candidate for a new linux-kernel@ or bugzilla bug report. You should also consider reporting these ipv6 problems, especially if you think they can trigger TX timeouts. (In both cases it would be good to try current mainline first, when you get it workable.) Thanks, Jarek P. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Breuer on 9 Jan 2010 13:40 On 1/9/2010 7:28 AM, Jarek Poplawski wrote: > On Fri, Jan 08, 2010 at 11:45:35PM -0500, Michael Breuer wrote: > >> On 1/8/2010 4:48 PM, Michael Breuer wrote: >> >>> On 1/8/2010 4:29 PM, Jarek Poplawski wrote: >>> ... >>> >>>> BTW, don't hurry with that yet, but in the next test, please try >>>> alternative 2 again (i.e. with MMAP + no DMAR + disable_msi). >>>> >>>> >>> Will do - still up from yesterday... no more dropped packets... >>> none of the dns errors either. To be expected I suppose as long as >>> I'm trying to sniff it. Assuming no immediate erorrs with alt2, no >>> DMAR + disable_msi I'll report back after it's been up for a >>> while. >>> -- >>> >> Ok - ran alt1 and alt2, both with MMAP, no DMAR and disable_msi. >> Both seem to behave similarly. No logged errors; >> > Ok - since alt2 introduces less changes and is acked by Stephen > already, I'll resend it with your "Tested-by" in a new thread to clear > things a bit. > > Ok - good, and thank you for all your help. >> large numbers of dropped RX packets. >> > You might try some tweaking with another sky2 parameter "copybreak" > or even editing its "NAPI_WEIGHT" variable. > > I'll play around with this after I figure out what's actually being dropped and why. Looking at ethtool, over 99% of RX packets are in the >=1024 bucket. I'll play with weight and perhaps rmem as time permits. >> One odd thing: when driving every sort of >> traffic through, I was able to hose the client adapter (win7) >> repeatedly by runnnig the win7 backup and connecting Windows Media >> Player to a Mediatomb stream while also running a remote X11 >> session. Looks like the SSDP traffic that occurs at the same time as >> the SMB traffic and X11 traffic takes out the adapter on Win7 - >> Nforce. >> Reran with msi enabled, MMAP and no DMAR. Also no errors; much >> faster, and the Win7 side survives the same conditions that don't >> work when msi is disabled. Doesn't make sense to me, but it is what >> it is. >> >> Going to leave this up for a while and see if things remain functional. >> > It looks like DMAR is the main candidate for a new linux-kernel@ or > bugzilla bug report. You should also consider reporting these ipv6 > problems, especially if you think they can trigger TX timeouts. (In > both cases it would be good to try current mainline first, when you > get it workable.) > Ok - I'll get onto mainline and then deal with DMAR. > Thanks, > Jarek P. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Breuer on 13 Jan 2010 15:50
On 1/9/2010 1:34 PM, Michael Breuer wrote: > On 1/9/2010 7:28 AM, Jarek Poplawski wrote: ... >> It looks like DMAR is the main candidate for a new linux-kernel@ or >> bugzilla bug report. You should also consider reporting these ipv6 >> problems, especially if you think they can trigger TX timeouts. (In >> both cases it would be good to try current mainline first, when you >> get it workable.) > Ok - I'll get onto mainline and then deal with DMAR. Just an FYI - 2.6.32.3 with alt 3 af_packet patch & sky2 pskb_may_pull runs OK with DMAR (re)enabled and msi enabled. >> Thanks, >> Jarek P. > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |