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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox