netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: "Guenther Thomsen" <GThomsen@bluearc.com>
Cc: "John W. Linville" <linville@redhat.com>, <netdev@vger.kernel.org>
Subject: Re: kernel panic (on DHCP discover?) in sky2 driver of 2.6.17-rc1
Date: Wed, 7 Jun 2006 12:44:36 -0700	[thread overview]
Message-ID: <20060607124436.20fdf9fa@localhost.localdomain> (raw)
In-Reply-To: <CECD6E8A589E8447BC6E836C8369AFF506828728@us-email.terastack.bluearc.com>

On Wed, 7 Jun 2006 12:33:21 -0700
"Guenther Thomsen" <GThomsen@bluearc.com> wrote:

> I was perhaps a bit quick to declare victory. While the results below stand and the machine survived the last few days (idle), it occurred to me only today, to have a look at the kernel's message buffer, where I found following:
> --8<--
> sky2 eth0: enabling interface
> sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control none
> sky2 eth1: enabling interface
> sky2 eth1: Link is up at 1000 Mbps, full duplex, flow control none
> audit(1149379670.514:3): audit_pid=1915 old=0 by auid=4294967295
> <unknown>: hw csum failure.
> sky2 eth1: rx error, status 0x7ffc0001 length 444
> 
> Call Trace: <ffffffff811de741>{__skb_checksum_complete+76}
>        <ffffffff812030cb>{__tcp_checksum_complete_user+33}
>        <ffffffff812080d8>{tcp_rcv_established+817} <ffffffff8120f3ee>{tcp_v4_
> do_rcv+43}
>        <ffffffff811da2ee>{sk_wait_data+203} <ffffffff811fe5a8>{tcp_prequeue_p
> rocess+121}
>        <ffffffff811ff71d>{tcp_recvmsg+1104} <ffffffff811d9712>{sock_common_re
> cvmsg+48}
>        <ffffffff811d7d4f>{do_sock_read+209} <ffffffff811d7e7e>{sock_aio_read+
> 83}
>        <ffffffff811e2ca1>{dev_queue_xmit+0} <ffffffff8106dce9>{do_sync_read+1
> 99}
>        <ffffffff8103d699>{remove_wait_queue+18} <ffffffff8103d530>{autoremove
> _wake_function+0}
>        <ffffffff8106df83>{vfs_read+228} <ffffffff8106ea12>{sys_read+69}
>        <ffffffff81009b0d>{tracesys+209}
> <unknown>: hw csum failure.
> sky2 eth1: rx error, status 0x7ffc0001 length 444

Different problem, I have seen it before.  Basically if the receiver gets overloaded, the
packet FIFO gets full. The driver needs to have some kind of recovery logic for this;
probably just shutting down the receiver and restarting.

  reply	other threads:[~2006-06-07 19:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-07 19:33 kernel panic (on DHCP discover?) in sky2 driver of 2.6.17-rc1 Guenther Thomsen
2006-06-07 19:44 ` Stephen Hemminger [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-06-04  4:05 Guenther Thomsen
2006-05-16 20:15 Guenther Thomsen
2006-04-12 21:42 Guenther Thomsen
2006-04-12 21:48 ` Stephen Hemminger
2006-04-12 22:26   ` Guenther Thomsen
2006-04-17 18:18     ` Stephen Hemminger
2006-05-16 19:11 ` Stephen Hemminger

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=20060607124436.20fdf9fa@localhost.localdomain \
    --to=shemminger@osdl.org \
    --cc=GThomsen@bluearc.com \
    --cc=linville@redhat.com \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).