mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rob Rhoads <errhoads@linux.co.intel.com>
To: "Feldman, Scott" <scott.feldman@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: RE: [BUG] e100 driver fails to initialize NIC on 2.5.44
Date: 23 Oct 2002 16:28:53 -0700	[thread overview]
Message-ID: <1035415733.676.446.camel@beer.co.intel.com> (raw)
In-Reply-To: <288F9BF66CD9D5118DF400508B68C44604758C30@orsmsx113.jf.intel.com>

On Wed, 2002-10-23 at 13:07, Feldman, Scott wrote:
> Rob Rhoads wrote:
> > -#define E100_MAX_SCB_WAIT	100	/* Max udelays in wait_scb */
> > +#define E100_MAX_SCB_WAIT	2000	/* Max udelays in wait_scb */
> 
> I'm not in favor of increasing a hardware timeout value 20x without knowing
> root-cause of the failure.  What is unique about your environment?  I'd like
> to know if there are others out there that have run into this same failure.
> List?

Can't blame you on that one. :-) 

It's a standard Intel STL2 Server Board, nothing really unique about it.
But here is more detail on how it is configured:

o 2 x Intel® Pentium® III Processors @ 1-GHz
o 2.5 GB PC133 ECC Registered SDRAM Memory
o Integrated SCSI (Adaptec* AIC7899 dual-channel SCSI controller)
o ServerWorks* ServerSet* III LE Chipset
o ATI Rage* IIC PCI graphics controller with 4 MB of memory
o Integrated Intel® Pro/100+ Server Adapter (Intel® 82559 Controller)
o Dual-Peer PCI, Six Available PCI Slots
  - Bus A-four 32-bit/33MHz PCI slots
  - Bus B-two 64-bit/66MHz PCI slots

We've seen this same problem before on the STL2 & the 2.4.18 kernel
running the 2.1.15 version of the Intel e100 driver. This same problem
had also been previously reported to the kernel mailing list, but I
don't recall the exact version of either the 2.4.x kernel or e100
driver.

Upon further investigation, when I set E100_MAX_SCB_WAIT to 2000 on the
2.5.44 kernel, as in my original patch, it only works for when the e100
driver is compiled into the kernel. I had to bump it up to 5000 to make
it work as a loadable module. When I dumped the value of the loop
variable 'i', it would succeed at either 4078 or 4095 iterations of the
for-loop. So 5000 may very well NOT work for other configurations.

Also the comment for the function states that the driver may need to
wait up to 1 millisecond, yet the original for-loop uses a udelay(1) for
a max of 100 iterations. Since 100 usecs. != 1 millisecond, this is what
clued us into increasing the max. loop count. Experimentation is what
got us to 2000 and now 5000.

Let me know if there is anything else I can do to help root cause this
problem.

-RobR


  reply	other threads:[~2002-10-23 23:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-23 20:07 Feldman, Scott
2002-10-23 23:28 ` Rob Rhoads [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-10-23  3:10 Rob Rhoads

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=1035415733.676.446.camel@beer.co.intel.com \
    --to=errhoads@linux.co.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=scott.feldman@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

all inboxes | Powered by JetHome®