Ethernet Controller Stopping

I have a powerpc based embedded system with intel 82551 as the ethernet controller. Linux-2.6.24 is ported into the system.

The problem is that after the system boot up, exactly after 1hr 30minutes ethernet controller stops. If I give an ifconfig, it shows no problem, but i am unable to ping to this machine. What could be the issue?

Gives me the impression there is an IP lease issue somewhere??? I don't believe in faulty hardware that reads a clock. Look for some issue that does.

Hi jefro,
There shouldnt be any ip issues as only the powerpc machine and its host are in the hub. But today i found another interesting thing, that Ethernet controller stops even if we stop at the bootloader(uboot) exactly after 1hr 30 minutes...!!!

What is the evidence that suggests the the 'Ethernet controller stops'? Are you sure the problem is with the ethernet controller? How? What exactly do you mean by 'stops'? What symptoms are you seeing in general? What is the response from the usual host of tools such as ifconfig, ethtool, etc?

--- rod.

Hi theNbomr,
ifconfig and ethtool both shows my eth0 has no issues. But the thing is when i try to ping another machine, which was happening fine for 1hr 30minutes, is NOT happening. And from the another machine, I am unable to ping my PowerPC machine. The other machine do not have any issue as i could ping it and ping from a 3rd machine, but only this PowerPC machine do not respond. But as I told, ethtool or ifconfig have no issues at all!!!

Okay, that characterizes the problem a little better. So what happens if you bring the interface down, and then up again? When I asked about tools like ethtool, I didn't really wonder whether they would run, as much as what information they could provide. When you try to acquire statistics both before and after the problem appears, how does the data differ?

ethtool -S eth0

I think this is the same info visible in /proc/net/dev, but just for completeness, is there any non-normal data there?
If your driver is a loadable module, does it have any effect to unload it and reload it?
Are there link/speed LEDs on the interface? Do they change behavior when the fault occurs? Do you have any other similar hardware that exhibits the same behavior? How is the ethernet interface attached to the network: through a hub/switch, direct to another host through a crossover cable, etc. I have seen the latter configuration cause problems when the peer host drops it's link status as on a reboot.

--- rod.

The ethtool and ifconfig outputs before and after the problem looks the same.
Driver is not a loadable module, it is part of the kernel...Its 2.6.24 kernel and the eth controller is intel 82551
The link and the activity LEDs are glowing fine.
This eth interface is connected via a CISCO switch.
One more information - This happens even at the bootloader level. I use uboot as my bootloader and after poweron if i stop the boot procedure and wait on the uboot prompt, and ping it works fine till 1hr 30minutes, after that it says "cannot reset/restart the ethernet controller"

Okay, since the problem manifests independently for both a bootloader and an OS, it sounds like either a hardware fault or a design fault. If you have multiple devices which all exhibit the same behavior, then it is probably a design error, or is a design which requires additional software support that isn't in either the kernel or bootloader. What specific hardware (motherboard, SBC, or SoM) are you using?

--- rod.

Hi,
the system is a custom designed hardware with PowerPC 7410 as the processor, Tsi107 as host bridge and intel 82551 as the ethernet controller.
But if there is a hardware issue, how is it manifesting after 1hr 30minutes...not initially? whether anything to do with some timeout setting?

Well, there are probably hardware timers on the board, perhaps to clock the data out of the ethernet chip. If the timer stops running for some reason, it would affect the operation of the ethernet chip. It is possible to imagine a scenario where a timer starts by default in a mode that counts down and then terminates, but software is expected to change the timer mode to one that simply rolls over to a maximum count and resumes. I'm sure there are other scenarios which match the fault condition, but it is all just spitballing without knowing a lot of detail. That the failure occurs under two different software scenarios makes me think it is a hardware oriented fault. Are there other instances of the device which do not exhibit the fault? Did the faulty device in question ever work correctly? Have you consulted the designer of the board?

--- rod.