lkml.org 
[lkml]   [2010]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] af_packet: Don't use skb after dev_queue_xmit()
    On Sun, Jan 17, 2010 at 06:15:22PM -0500, Michael Breuer wrote:
    > On 1/17/2010 6:05 PM, Jarek Poplawski wrote:
    >> On Sun, Jan 17, 2010 at 05:34:19PM -0500, Michael Breuer wrote:
    >>
    >>> On 1/17/2010 5:17 PM, Jarek Poplawski wrote:
    >>>
    >>>> On Sun, Jan 17, 2010 at 11:26:46AM -0500, Michael Breuer wrote:
    >>>>
    >>>>> On 01/13/2010 04:16 PM, Michael Breuer wrote:
    >>>>>
    >>>>>> On 1/13/2010 4:09 PM, Jarek Poplawski wrote:
    >>>>>>
    >>>>>>> On Wed, Jan 13, 2010 at 03:39:37PM -0500, Michael Breuer wrote:
    >>>>>>>
    >>>>>>>
    >>>>> Update: after leaving the system up for a few days, I hit the DMAR
    >>>>> error again.
    >>>>>
    >>>> My proposal is to send some summary as a new thread, with dmar in the
    >>>> subject, and cc-ed dmar maintainers.
    >>>>
    >>>>
    >>> Not sure I agree. The symptoms are identical to those I hit without
    >>> DMAR earlier on. Also, as this issue only happens when there is high
    >>> receive load, I'm thinking there's some sort of race between TX and
    >>> RX within the sky2 driver, or hardware. I think that DMAR is
    >>> correctly catching the error.
    >>>
    >> Hmm... OK, then let's wait with this report and go back to testing
    >> it "really really long" ;-) without DMAR, and maybe without the
    >> last Stephen's patch either? (So only the two things in the current
    >> linux-2.6.)
    >>
    >> Jarek P.
    >>
    > Ok - but absent the last patch, I think I still need the pskb_may_pull
    > patch... so it'd be pskb_may_pull and afpacket v3 and no DMAR.

    Exactly. Or if it's working for you already, the mainline (2.6.33-rc4)
    with the pskb_may_pull patch. And check for warnings from the latter.

    >
    > Also - not sure if related, but there's still the odd tx side behavior
    > when RX is under load. That I CAN reproduce at will (yesterday's report
    > - no crash, but I confirmed that DHCPOFFER packets are being dropped
    > somewhere after wireshark sees them and before hitting the wire.

    I'm not sure either, but until there is no crash it might be some
    minor bug or/and missing stat. Btw, you could probably try alternative
    test with ping from this overloaded box to the router and win7.

    >
    > I am also wondering whether or not that testing I did yesterday set up
    > today's hang - perhaps those lost TX packets are corrupting something
    > that manifests worse later.

    Maybe, but you wrote earlier they had to fix something around this
    DMAR in the meantime, because it triggered much faster during your
    previous tests. So, I don't know why you assume this DMAR has to be
    correct this time.

    Jarek P.


    \
     
     \ /
      Last update: 2010-01-18 08:33    [W:0.027 / U:1.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site