From: Richard Fuchs <richard.fuchs@inode.info>
To: Matt Mackall <mpm@selenic.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: slab corruption in skb allocs
Date: Fri, 04 Mar 2005 23:51:59 +0100 [thread overview]
Message-ID: <4228E68F.1030609@inode.info> (raw)
In-Reply-To: <20050304220508.GA3120@waste.org>
Matt Mackall wrote:
> Which card/driver is this? Is this the same card that's showing ssh
> troubles? My theory about your ssh trouble only applies to cards with
> checksum offload.
i got the same on all three machines i was testing with, with both the
e100 and the eepro100 driver. one of those three machines was the one
with the ssh troubles, its card is identified as "Intel Corp. 82557/8/9
[Ethernet Pro 100] (rev 08)", pci id 8086:1229. plus, i couldn't
reproduce those problems on a machine with e1000, which does support all
kinds of checksum offloading. (there might still be something fishy with
the e1000 as well, as i'm not entirely trusting the errors from the slab
checkers alone. especially since i don't see those messages when i
enable page alloc debugging.)
another machine behaves even more strangely... its nic is identified as
"Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller (rev 81)", pci
id 8086:1039, also apparently not supporting hardware checksums. it does
immediately produce the slab debug errors when i bombard it with udp
packets while having disk access w/o dma, but remains silent when doing
the same with a tcp transfer instead of udp packets. neither ssh traffic
nor /dev/zero piped through netcat (no matter in which direction) makes
it catch any errors. i only got a _single_ message from the slab
debugger when sending /dev/zero through netcat in _both_ directions at
the same time (in and out). however, i do get pages and pages of those
messages when sending a simple stream of udp packets to the box...
again, this is all with the e100 driver, i couldn't produce any similar
results with the eepro100 or the e1000 driver yet, but apparently this
doesn't necessarily mean that there isn't something wrong anyway...
cheers
richard
next prev parent reply other threads:[~2005-03-04 23:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-04 9:55 slab corruption in skb allocs Richard Fuchs
2005-03-04 11:53 ` Andrew Morton
2005-03-04 12:23 ` Richard Fuchs
2005-03-04 20:11 ` Matt Mackall
2005-03-04 21:19 ` Richard Fuchs
2005-03-04 21:27 ` Matt Mackall
2005-03-04 21:52 ` Richard Fuchs
2005-03-04 22:05 ` Matt Mackall
2005-03-04 22:51 ` Richard Fuchs [this message]
2005-03-05 18:25 ` Scott Feldman
2005-03-05 19:10 ` Richard Fuchs
2005-03-06 17:44 ` Scott Feldman
2005-03-06 18:40 ` Richard Fuchs
2005-03-07 5:07 ` Scott Feldman
2005-03-07 8:30 ` Richard Fuchs
2005-03-04 18:10 ` Dave Jones
2005-03-04 18:32 ` Richard Fuchs
2005-03-04 19:29 ` Richard Fuchs
2005-03-21 22:36 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4228E68F.1030609@inode.info \
--to=richard.fuchs@inode.info \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox