TCPv4 checksum errors
Gabriel Paubert
paubert at iram.es
Thu Dec 24 00:23:30 EST 1998
On Wed, 23 Dec 1998, Geert Uytterhoeven wrote:
> In the mean time I got this from a `new' PPC hacker. I haven't tried it yet
> (still have to manually calculate checksums for my bad packets, too, sigh).
>
> --------------------------------------------------------------------------------
> >From VANDROVE at vc.cvut.cz Wed Dec 23 10:11:44 1998
> Date: Tue, 22 Dec 1998 16:44:01 MET-1
> From: Petr Vandrovec Ing. VTEI <VANDROVE at vc.cvut.cz>
> To: Geert Uytterhoeven <Geert.Uytterhoeven at cs.kuleuven.ac.be>
> Subject: PPC checksumming...
>
> Hello Geert,
> I've found that Motorola Powerstack is much more happy after
> applying folowing patch:
>
> diff -ur linux/include/asm-ppc/checksum.h linux/include/asm-ppc/checksum.h
> --- linux/include/asm-ppc/checksum.h Thu Apr 23 02:35:41 1998
> +++ linux/include/asm-ppc/checksum.h Tue Dec 22 16:19:49 1998
> @@ -83,13 +83,13 @@
> unsigned int sum)
> {
> __asm__("
> - add %0,%0,%1
> - add %0,%0,%2
> - add %0,%0,%0
> - addi %0,%0,0
> + addc %0,%0,%1
> + adde %0,%0,%2
> + adde %0,%0,%3
> + addze %0,%0
> "
> : "=r" (sum)
> - : "r" (daddr), "r"(saddr), "r"((ntohs(len)<<16)+proto*256), "0"(sum));
> + : "r" (daddr), "r"(saddr), "r"((proto<<16)+len), "0"(sum));
> return sum;
> }
>
>
> Before applying, I've got TCPv4 bad checksum instead of Connection refused,
> now it works :-) and I finnaly found that on my PPC inetd was not started...
> But because of I'm learning PPC assembler only since today morning, I'm not
> sure whether it does what I think it should... If you find it useful,
> please post it to appropriate maintainer (DaveM or ... ?) I do not know,
> who invented original code, maybe Cort (according to comments around code),
> but it was not taken from linux/include/asm-sparc - I'm pretty sure :-)
This patch looks very reasonable. You absolutely need the carry for TCP
checksums.
> With regards to matroxfb: I've found that PPC Bios did not assign addresses
> to Matrox : framebuffer was located at 0xFF800000, MMIO at FFFFC000,
> both overlapping itself :-( Unfortunately, after going through PREP PCI code
> they were relocated to 0x01800000 and 0x01FFC000 - still overlapping, but
> now values looks `normal' :-( And, it is worse, it looks like that
> only region 0x01000000 - 0x01FFFFFF is forwarded into PCI bus, so there
> is really resource starvation here... One 8MB framebuffer, 16KB MMIO,
> some MMIO of NCR825... Life is not simple.
What is your machine ? Can you try to embed you /usr/src/vmlinux
in my (relatively new) preploader found at:
ftp://vcorr1.iram.es/pub/preploader.tgz
Instructions:
tar xvzf preploader.tgz
cd preploader
make
provided your source tree is /usr/src/linux. You will get a zImage in
the preploader directory. This bootloader should reassign all I/O and
PCI memory space to something sane (provided you don't have any PCI<->PCI
bridges, not yet supported). However some S3 chips for example are buggy:
they claim they need 8Mb but actually need 64Mb. The bootloader includes
a black list to correct for this (one entry only up to now).
Gabriel.
P.S.: the output of lspci on your machine would be useful to help with
these problems. I'm also surprised that you only have 16Mb of MMIO
forwarded to PCI.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request at lists.linuxppc.org ]]
More information about the Linuxppc-dev
mailing list