Useful story. A great reminder that<div>right after making sure things are </div><div>plugged in, simplify. </div><div><br></div><div>Thanks. Nice bit of sleuthing.</div><div><br></div><div> -- Bob</div><div><br><br>
<div class="gmail_quote">On Fri, Mar 5, 2010 at 12:38 AM, Michael Mol <span dir="ltr"><<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This is far and away the weirdest computer glitch I've managed to<br>
resolve, so I thought I'd share the story.<br>
--<br>
<br>
So I've spent the last seven hours trying to get my desktop to boot<br>
something, anything, that's a full operating system. For much of the<br>
time, the system was hanging randomly between POST and loading the<br>
boot sector, and for much of the rest of the time, it was consistently<br>
hanging when I tried to load a Linux kernel. I even wound up going so<br>
far as to flash my BIOS, because I couldn't think of anything else to<br>
try that made any sort of sense.<br>
<br>
The flash upgrade had gotten me to the point where I could at least<br>
load boot sectors again, and I was able to run memtest off of live<br>
CDs, but I couldn't seem to boot into 32-bit or 64-bit Linux, either<br>
my installed version or from a couple Xubuntu live CDs.<br>
<br>
I was beginning to suspect some sort of weird flash corruption that<br>
was preventing me from using graphics card features, or possibly from<br>
switching to protected mode or x64 mode. (I don't know how memtest86+<br>
works, as far as accessing all 8GB of my RAM. I'm pretty sure the BIOS<br>
is still in Real mode when it runs its initial sweep, but maybe it's<br>
bouncing back and forth between Real and Protected during POST.)<br>
<br>
The thought of another outlay to continue having a nice computer at<br>
home was not appealing.<br>
<br>
Finally, a few minutes ago, I realized something. I had two relatively<br>
new pieces of hardware attached to the computer: An APC UPS and a<br>
powered USB hub. I disconnected the USB connection between the UPS and<br>
the computer, and disconnected the hub, and rebooted the computer. The<br>
32-bit Xubuntu live CD came right up. Huh. Reboot, throw in the 64-bit<br>
Xubuntu live CD, and *that* came right up. Huh.<br>
<br>
I haven't tried booting off my hard disk yet, and I think that'll<br>
require some grub command-line magic to deal with device reordering<br>
stemming from the BIOS upgrade and CMOS changes. However, I think it's<br>
ultimately workable.<br>
<br>
What I think happened is that the connection of the UPS and the<br>
powered hub to the computer via USB led to a ground loop that was<br>
messing with the internals of the USB controller on the motherboard.<br>
See, the powered hub isn't plugged into the UPS; it's a fair bit away<br>
from the computer, and I'll have to run an extension cord to get the<br>
UPS's power to it. As long as the operating system didn't try to do<br>
too much with that USB controller, things worked fine. That meant I<br>
could get into BIOS and tweak things, and it meant I could get into<br>
grub and memtest without too much trouble. Well, sortof. Remember how,<br>
before the flash upgrade, the system would hang at a random point<br>
between POST and loading the bootloader. I think the flash upgrade may<br>
have changed part of how it dealt with the USB controller, with the<br>
newer version inadvertently working around some of the<br>
ground-loop-induced weirdness.<br>
<br>
So, yeah. A little more experience for those weird situations.<br>
<font color="#888888"><br>
--<br>
:wq<br>
_______________________________________________<br>
grlug mailing list<br>
<a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br>
<a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
</font></blockquote></div><br></div>