From: ebiederm@xmission.com (Eric W. Biederman)
To: Michael Fu <michael.fu@linux.co.intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BUG] e100 driver fails to initialize the hardware after kernel bootup through kexec
Date: 24 Jan 2003 07:01:56 -0700 [thread overview]
Message-ID: <m18yxaeje3.fsf@frodo.biederman.org> (raw)
In-Reply-To: <1043390954.892.10.camel@aminoacin.sh.intel.com>
Michael Fu <michael.fu@linux.co.intel.com> writes:
> After kernel was bootup through kexec command, the NIC failed to
> initialize. The 2.5.52 kernel was patched with kexec and kexec-hwfix
> patch.
Interesting... The patch goes cleanly onto newer kernels so feel
free to play with them. You are running a single cpu system
so the kexec-hwfix patch should not make a difference at this point.
Your interrupt routing is via ACPI interesting...
>
> the following was is the dmesg output:
[snip]
> Intel(R) PRO/100 Network Driver - version 2.1.24-k2
> Copyright (c) 2002 Intel Corporation
>
>
>
>
>
>
> PCI: Enabling device 02:09.0 (0000 -> 0003)
> PCI: Setting latency timer of device 02:09.0 to 64
> e100: selftest timeout
> e100: Failed to initialize, instance #0
[snip]
> I doubt this is a bug in E100 actually.
Given that everything else was working correctly this is almost
certainly an e100 driver or a hardware bug. On x86 everything has
been working well enough that finding something that is not a
hardware/driver bug as a failure case is currently quite a challenge.
Q1: Is this reproducible?
Q2: Is this reproducible with the eepro100 driver?
You were doing the easy case of 2.5.52 to 2.5.52 I have gotten so many
false positives with things working when I reboot the exact same kernel
I barely consider it a valid test case any more...
If it is a bug in the driver a shutdown method can be used to clean up
before reboot to place the device is a quiescent state.
Either that or the drivers initialization code can be enhanced to
handle more strange states.
I know the eepro100 driver issues a reset before playing with the
card. The e100 driver is doing this in a different order, and it is
dying before it resets the card so that looks like the issue to me.
Doing a clean user space shutdown may also help. Though your kexecwrapper
script looked like it was probably doing that o.k.
Eric
next prev parent reply other threads:[~2003-01-24 13:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1042450072.1744.75.camel@aminoacin.sh.intel.com>
2003-01-24 6:49 ` [BUG] e100 driver fails to initialize the hardware after kernel bootup through kexec Michael Fu
2003-01-24 14:01 ` Eric W. Biederman [this message]
2003-01-24 14:57 ` Andrey Nekrasov
2003-01-24 16:07 ` Jeff Garzik
2003-01-26 21:56 ` Henning P. Schmiedehausen
[not found] ` <mailman.1043391842.14884.linux-kernel2news@redhat.com>
2003-01-24 16:49 ` Pete Zaitcev
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=m18yxaeje3.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.fu@linux.co.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.