While booting the 2.5.44 kernel & configured with the Intel e100 driver,
I get the follow error:
kernel: e100: hw init failed
kernel: e100: Failed to initialize, instance #0
I'm running this on an Intel STL2 server motherboard w/ 2 PIII's and 2.5
GB RAM. If you need more info I can provide it.
The patch below fixes my problem by increasing the maximum number of
retries that the SCB command field is checked in the e100_wait_scb()
function.
diff -ruN linux-2.5.44/drivers/net/e100/e100.h linux-2.5.44-new/drivers/net/e100/e100.h
--- linux-2.5.44/drivers/net/e100/e100.h 2002-10-18 21:01:20.000000000 -0700
+++ linux-2.5.44-new/drivers/net/e100/e100.h 2002-10-22 14:25:24.000000000 -0700
@@ -100,7 +100,7 @@
#define E100_MAX_NIC 16
-#define E100_MAX_SCB_WAIT 100 /* Max udelays in wait_scb */
+#define E100_MAX_SCB_WAIT 2000 /* Max udelays in wait_scb */
#define E100_MAX_CU_IDLE_WAIT 50 /* Max udelays in wait_cus_idle */
/* HWI feature related constant */
--
Rob Rhoads mailto:[email protected]
Telecom Software Platforms
Intel Communications Group
<disclaimer value="pointless">
This email message solely contains my own personal views,
and not necessarily those of my employer.
</disclaimer>
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?
-scott
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