BzImage, Intel E1000e Driver and Dell Vostros 400 bad news.
-
[SIZE=3]Chalk one up either to flaky hardware or Gremlins! I was testing this issue further and decided to test the power cycle again, but this time I did a deep power cycle; (power the machine down, pull the plug from the power supply, wait, plug it back in, power back on). Before I was just doing a front button power cycle. Well, that seems to fix it! [/SIZE]
[SIZE=3]Just so you know I’m not mad, this is from dmesg when the network card would block;[/SIZE]
Linux Kernel 3.13.6
e1000e: Intel
PRO/1000 Network Driver - 2.3.2-K
e1000e: Copyright
1999-2013
e1000e: 0000:00:19.0 Interupt Throttling Rate(ints/sec) set to dynamic conservative mode
e1000e: 0000:00:19.0 eth0 10/100 speed disabling TSO
Sending DHCP request … timed out!
IP-Config: Reopening network devices
e1000e: eth0 NIC Link is Up 100 Mbs Full Duplex, Flow Control: Rx//TxAnyway I suspect that the deep power cycle cleaned the memory of Intel chip and forced it to reload. So now it’s working perfect and I can’t reproduce the problem.
So add deep power the machine down, pull the plug from the power supply, wait, plug it back in, power back on cycle to your bag of tricks to try with the Dell Vostros 400s.
Case closed.
-
Last night I was thinking about this, and it doesn’t make sense that a deep power cycle would correct what ever issue these cards have. After all I had set this machine up on a lab bench and that would have power cycled it before I started testing FOG. So that leaves one other possible cause of this device miraculous recovery. In trying to understand the problem, I used a new kernel 2.6.39.1 bzImage to jump to debug mode. (This is the bzImage kernel I have on my version 3.2 FOG machine and I knew it worked). That was the first time the network didn’t lock when fog instructed it to boot. I think this is the kernel that caused the firmware for the intel 82562V2 to be fixed.
So you may want to download bzImage 2.6.29.1 if you have any Dell Vostro’s 400’s to image.
Now back to something serious like Basketball.
-
82562V-2 10/100 and e1000 e100 e1000e are all different aren’t they?
-
Okay,
So I did a little research. Apparently this issue happens on Windows as well. Especially if the system goes to sleep. It is something with the power and power management, and not (seemingly) a problem with driver that’s loaded into the system. It seems, to me, that you may need to disable power management on the device. How to do so I haven’t got a clue. -
Your right Tom. I also was looking around and apparently it’s a wide spread problem. In this tread, they claim it’s power management.
Their advice is good if you have one of these machines or that type chipset. I don’t know what the 2.6.39.1 kernel did but it sure got that chip out of it’s funk.
If I understand FOG, isn’t the Kernel: parameter when your setting up a host suppose to be the Image used for booting? (like bzImage).
So in the kernel input box, I could put bzImage2.6.39.1 and it should use that image instead of the default. That could be useful for a whole class of Dell’s using this bedeviled chipset. Is that feature functioning? -
To my knowledge it worked in 0.32, I don’t know for 0.33, but I am willing to test.
-
0.33b did not, originally, have this working. I just made it work. So if your host has a special kernel associated with it, it will use that kernel. Just remember to use the proper name for the kernel.
-
Thanks Tom. I look forward to seeing that feature in a future svn. Ever since that fix, that machine has worked perfect and is now in service. By the way, I put a patch up in the Bug forum that will add Mageia linux to the Redhat group during for Fog 33b installation.
You might want to read it and see if it’s useful.Cheers.
-
It’s already in the latest of SVN. I did have to re-add it a couple of times.
One of the greatest things about this method is that if the host is registered, this works for that host even from the “default” menu.
-
It works great! I just tried it.
Thank you.
