On Mon, Feb 18, 2008 at 05:39:03PM +0200, Pekka Pietikainen wrote:
> When playing with some L2 level fuzzing I started getting lots of
> "protocol 0300 is buggy, dev eth3" spew in dmesg. That interface is also
> capturing the traffic that's being sent, that's probably
When playing with some L2 level fuzzing I started getting lots of
"protocol 0300 is buggy, dev eth3" spew in dmesg. That interface is also
capturing the traffic that's being sent, that's probably why the
dev_queue_xmit_nit codepath is getting called in the first place.
Tested on 2.6.23-as-shipped-
ith MTU discovery enabled.
And probably others too. Then again, the information there isn't wrong, it's
just totally useless these days :P
--
Pekka Pietikainen
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PR
interrupt load.
Probably not a problem then, since those acks probably cover many
sent packets. Current interrupt mitigation schemes are pretty
dynamic, balancing between latency and bulk performance so the acks
might be fine (thousands vs. tens of thousands/sec)
--
Pekka Pietikainen
-
To unsub
akpm's with yantt) :-)
And yes. TCP stacks do have bugs, especially when things get outside the
equipment most people have. Having a dedicated transatlantic 2.5Gbps
connection found a really fun one a long time ago ;)
--
Pekka Pietikainen
-
To unsubscribe from this list: send the line "un
Just had to spend some time figuring out why a bnx2 card connected to
a switch monitor port didn't see any vlan tags (when in our scenario the
tags are pretty vital). Found the following explanation:
[BNX2]: Fix VLAN on ASF
Always set up the device to strip incoming VLAN tags when ASF is
On Thu, Jan 18, 2007 at 08:55:37AM -0500, Brandon Craig Rhodes wrote:
> to debugging messages! In some circumstances, debug messages are
> always produced; in several others, net_ratelimit() is called to
> decided whether to print an error (but why in these cases and not
> others?); and in many ca
On Wed, Jan 17, 2007 at 11:46:35AM -0500, Brandon Craig Rhodes wrote:
> Having further reviewed my code, I have changed my mind; the
> ieee80211_crypt_tkip routines are not designed to be responsible for
> creating enough headroom and tailroom. The "hostap" driver should be
> doing this. In fact,
On Sun, Sep 17, 2006 at 02:18:26PM +0200, Marcel Holtmann wrote:
> Hi Pekka,
>
> > Got this from a 2.6.18rc7-based fedora-devel kernel:
> >
> > =
> > [ INFO: possible recursive locking detected ]
> > 2.6.17-1.2647.fc6 #1
> > sdpd/4955 is trying to acqu
Hiya!
Got this from a 2.6.18rc7-based fedora-devel kernel:
=
[ INFO: possible recursive locking detected ]
2.6.17-1.2647.fc6 #1
-
sdpd/4955 is trying to acquire lock:
(sk_lock-AF_BLUETOOTH){--..}, at: [] bt_a
On Tue, Aug 08, 2006 at 02:38:51PM +0300, Pekka Pietikainen wrote:
> Hmm... I retried with a 2.6.18rc4-based rawhide kernel and the warning
> is still there, previous one was rc3-git7.
>
> Could be http://marc.theaimsgroup.com/?l=linux-netdev&m=115461336523555&w=2
> w
On Tue, Aug 08, 2006 at 09:16:13PM +1000, Herbert Xu wrote:
> Pekka Pietikainen <[EMAIL PROTECTED]> wrote:
> > Only aironet lockdep related report I could find was
> > http://marc.theaimsgroup.com/?l=linux-netdev&m=115406279721287&w=2
> >
> > this look
Only aironet lockdep related report I could find was
http://marc.theaimsgroup.com/?l=linux-netdev&m=115406279721287&w=2
this looks a bit different:
Linux version 2.6.17-1.2528.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1 20060802
(Red Hat 4.1.1-14)) #1 SMP Sun Aug 6 01:43:42 EDT 2006
===
On Tue, Jan 31, 2006 at 01:45:18PM -0800, Stephen Hemminger wrote:
> The driver doesn't handle overlength packets properly.
> Someone maybe sending you jumbo frames or some other crap.
>
> The vendor driver doesn't handle over size frames either;
> it just resets itself every 5 seconds so you don
On Tue, Jan 24, 2006 at 06:36:29PM +0200, Pekka Pietikainen wrote:
> On Mon, Jan 23, 2006 at 08:03:15PM +0200, Pekka Pietikainen wrote:
> > The box is a Nexcom NSA 1086 with 4x skge ports and 4x sky2. acpi=off made
> > the driver work apparently, haven't used it with much loa
On Mon, Jan 30, 2006 at 04:15:51PM -0800, Stephen Hemminger wrote:
> Okay, what is the hardware version:
> dmesg | grep skge
> Maybe that chip rev is no good.
skge 1.3 addr 0xd042c000 irq 169 chip Yukon-Lite rev 7
skge eth0: addr 00:10:f3:06:83:d4
skge 1.3 addr 0xd042 irq 193 chip Yukon-L
On Fri, Jan 27, 2006 at 11:22:42PM +1100, Herbert Xu wrote:
> OK, although we can't rule out sky2/netfilter from the enquiry, I've
> identified two bugs in ppp/pppoe that may be responsible for what you
> are seeing. So please try the following patch and let us know if the
> problem still exists (
On Wed, Jan 25, 2006 at 04:28:44PM -0800, Stephen Hemminger wrote:
> Mostly a collection of bug fixes. The most critical is the pci express
> fix. Also adds Message Signaled Interrupt and entropy support.
Patches seemed to be mangled. Actually having a "version I want
people to test" tarball would
On Mon, Jan 23, 2006 at 08:03:15PM +0200, Pekka Pietikainen wrote:
> The box is a Nexcom NSA 1086 with 4x skge ports and 4x sky2. acpi=off made
> the driver work apparently, haven't used it with much load yet, though.
Ran the box for a while with some load (the sky2 ports on the box are
> On Wed, 11 Jan 2006 14:00:17 -0800
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>> On Wed, 11 Jan 2006 21:16:40 +0300
>>
>> > 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E
>> > Gigabit Ethernet Controller (rev 19)
>>
>> What is the chip revision, reported on dmesg
On Thu, Aug 04, 2005 at 11:51:02PM +0200, Mateusz Berezecki wrote:
> Jeff Garzik wrote:
>
> >
> >Nothing in that tree has changed the b44 driver...
> >
>
> Ok, so I will try to find out what has changed as soon as I have some
> more time
>
> also please ignore forwarded e-mail. I just upd
21 matches
Mail list logo
