Re: sis190

From: Francois Romieu (romieu_at_fr.zoreil.com)
Date: 06/14/05

  • Next message: Dipankar Sarma: "Re: [PATCH 0/6] files: scalable fd management (V4)"
    Date:	Tue, 14 Jun 2005 22:04:45 +0200
    To: Pascal CHAPPERON <pascal.chapperon@wanadoo.fr>
    
    

    Pascal CHAPPERON <pascal.chapperon@wanadoo.fr> :
    [20050613-2.6.12-rc-sis190-test.patch]
    > I tried it :
    > - false mode detection
    > - as you expected, ping -s 157 was OK, ping -s 158 failed.
    >
    > Nice, it begins to work!

    Yes.

    Notice how the supposedly Rx DMA address ends in your log:
    sk_buff[0]->tail = ffff810006a3e012
                                      ^
    I have tweaked the rx copybreak path to perform a shift from two bytes
    before this address and surprisingly enough we get exactly the two
    missing bytes. The normal path has not been modified and it is taken
    as soon as there is at least 200 bytes of data, i.e. your 186 icmp
    payload: it fails as it misses two bytes. Two possible explanations:
    1 - I can not find where the two bytes are lost and it is actually a bug
        in the driver. So far, you have been quite good at detecting my mistakes.
        You know what you have to do :o)
    2 - the asic can only DMA to a 4 bytes aligned address.

    (actually the asic could also always DMA 2 bytes before the expected address,
    whatever the adress, but I'd be happily surprized).

    If 2) applies, the driver will need an extra copy to align the IP headers
    (or someone will find some secret documentation which explains how to
    remove two bytes and fix the issue).

    The patch of the day uses a 4 bytes aligned Rx buffer address (at least for
    the usual MTU) and copies the Rx data. Can you reproduce the usual testing
    and tell if it makes a difference ?

    Patch available at:
    http://www.fr.zoreil.com/people/francois/misc/20050614-2.6.12-rc-sis190-test.patch

    --
    Ueimor
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Dipankar Sarma: "Re: [PATCH 0/6] files: scalable fd management (V4)"

    Relevant Pages

    • Re: [linux-usb-devel] Re: [BK PATCH] USB update for 2.6.3
      ... to pass the struct device of the USB device but the host one instead, ... > Making the device operations explicit would be good, though, and would ... > I'd still ask that people don't do DMA on non-host devices. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.10-rc2-mm4
      ... That would also be a proprietary hook wouldn't it 8) ... So far I can find none although I can find users for a 512Mb or 1Gb DMA ... doesn't need it and even beyond the supported open source hardware ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] ide-dma.c, ide.c, ide.h, kernel 2.4.24
      ... Did you want to update the patch for those proposed ... I'm really not familiar with the complexities behind DMA ... especially when it comes to simplex devices so I'm ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: How to Force PIO mode on sata promise (Linux 2.6.10)
      ... You disable DMA and the problem goes away, that seems to point to DMA as ... has a bug in the code just for your controller, ... Have you run memtest86 on your memory? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: freezes with cdrecord
      ... >> of the writing process. ... > It maybe has to do with the lack of zerocopy support (no DMA ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)