Another point is that you could try to issue a call to skb_linearize prior to
sending the skb down to the driver.
The 512 byte issue sounds like buffer size being used but as I said I don't
know what's sending the packets down the stack.
Cheers,
John
> -Original Message-
> From: Ron
During shutdown it's possible for __dev_close() (which holds
rtnl_lock) to clear the __LINK_STATE_START bit, and for ixgbe
to then read that bit (without holding rtnl_lock), and then
not fail to free irqs, etc. The result is a crash like this:
[ cut here ]
kernel BUG a
The buffer containing the data is not in a single buffer coming down to the
driver. I'm not sure what kind of stack you supplying the data but maybe you
should try to have all the data in a single larger buffer that is then used in
the skb.
Cheers,
John
> -Original Message-
> From: Y
Lars,
You can change driver msglvl by running 'ethtool -s ethx msglvl 0x2c00' after
driver loads. So when issue occurs it will log hw ring info into message log.
Please give it a try and send log after issue occurs.
Just wanted to ask is this the only board that has this issue? I looked in our
On Wed, Mar 06, 2013 at 01:19:32AM +0100, Borislav Petkov wrote:
> On Wed, Mar 06, 2013 at 01:13:23AM +0100, Rafael J. Wysocki wrote:
> > I suspected that during resume from hibernation the boot kernel (the
> > one that loaded the image) did something to hardware and the restored
> > kernel didn't
Hi,
I'm sending non-IP packets with dev_queue_xmit. It's not linear as expected in
receiving side when whole packet len only 513 bytes(include mac header). 513
bytes is a boundary because if I use 512, it's ok. Anybody know what may cause
this problem? Thanks. My MTU is 1500.
In sending s
