PC won't reboot

[VJ]

Hello,

I'm having a weird issue with my PC. When I press the reset button (or the OS reboots the system), my system just freezes. All leds (hdd, lan, scsi controller, ...) light up, screen blanks and it stays like this. The only way out of it is to press the powerbutton for 4 seconds (to shut down) and power up again. A cold boot is not a problem.

Probebely related: an IBM UltraStar 36lzx spins down occasionaly while the system is in operation and spins back up again. It is the only harddrive to do this; the voltage lines are dead stable and the OS is set never to spin down harddisks. FWIW, this drive has been sent back (and was replaced) for a similar issue (cause then was an intermittant connection in the power supply wiring of the harddisk). I have the impression reboot is always possible when this drive is not in the system.

I don't know if this is related, but I can't install new Matrox video drivers. Installation of them just crashes.


Is it the harddrive?
Or are there other possible causes I need to verify?


Jörg

[VJ]

In case anyone is interested , while I was running an exerciser test (using IBM/Hitachi Drive Fitness Test), the harddisk has stopped spinning completely and won't spin up.

Suprisingly, on one hand I find this good news: now I can send in the drive. On the other hand, it doesn't say too much for the reliability of this drive: it will be the 3rd time in 4 years time I'm sending it back.


Jörg

[UtwigMU]

Have you found reason for system instability?

I have similar issue here: MBM crashes and sensor chips hang, so system just hangs before powering off. Solution: Turn off PSU, wait a bit, turn it back on.

As for voltages, have you tried with multimeter or just by MBM, I found by measuring 3 PSUs and 3 boards that what multimeter, BIOS and MBM never tell the same value and multimeter is most reliable.

[VJ]

Well, I am quite certain the harddrive was the cause. In my case, all leds lit up (which always is the case when rebooting), but they stayed lit.
As I don't have a multimeter, I needed to resort to a softwaresolution to measure the voltages. To get the most accurate reading, I used SuperMicros own software (SuperODoctor III) and it showed all voltage lines to be dead stable.

As the problem doesn't occur without the drive present, and as the other harddisk doesn't behave like this, it most likely is caused by the IBM drive. To top it all, it doesn't spin up at all anymore.
I've had similar issues with this harddisk before (was replaced !) when it was my bootdisk. You can imagine that Windows doesn't like it when the bootdisk suddenly goes offline for 10+ seconds...

So while it looks like I have found that cause for this problem, I still don't know why the installation of the new Matroxdrivers fails.
However, I'll have to wait for my harddisk to return, as I'm currently running a sort of 'emergency system': for my normal setup I can easily restore my partitions in case of problems. I can't do this with my emergency system.


Jörg

[VJ]

I think I have isolated the reboot problem... It occured again yesterday, with the IBM drive not present.

However, the IBM drive was supplying termination power, so I'm now thinking that the lack of the IBM drive caused bus problems. I changed some settings on my cable, and now it never seems to occur.


Jörg

[Kurt]

You just wait for SAS and all SCSI quirks will disappear

[VJ]

You just wait for SAS and all SCSI quirks will disappear

Actually, I don't consider this a SCSI quirk: faulty working hardware will give weird problems on any system.
I just should have rememberd that the drive I removed supplied term power.

Jörg

[Kurt]

It's just that sometimes SCSI problems can be a PITA to eliminate.

You've got the various +/- compatible techs, then you have IDs, cable length, cable quality, termination, spin-up and whatnot, withtout talking about the controller functions.

Can't we have a nice automatic thing, please?

[VJ]

You've got the various +/- compatible techs, then you have IDs, cable length, cable quality, termination, spin-up and whatnot, withtout talking about the controller functions.

Yes... But IF the hardware works as is should, most of these issues shouldn't be a problem for someone with some knowledge (ids, cable length, termination, spin-up). Of course, if some hardware doesn''t behave, there is the issue of finding the culprit.

Still, I have had problems with 2 conner IDE harddrives (primary master and primary slave), which were caused by incorrectly placed manufacturer only jumpers. Similarly, I've had issues with a CD drive hogging the IDE bus. So any time when you have multiple devices sharing a bus, there is the problem of finding the cause when something doesn't work. (this is even the case on a network: at work we had a machine that sent out a jabber sequence at random times, for no reason whatsoever. Identifying what was causing our network problems was not straightforward)

Can't we have a nice automatic thing, please?

Actually, their was a standard for automatic SCSI id numbering, but it yielded even more problems than the manual method...



Jörg

[Kurt]

Yes, but with IDE it's simpler: disconnect the drive and see if it works. I haven't seen Conner drives in years...AFAIK they've been "bought back" by Seagate (they were ex-Seagate employees if I remember correctly).

Do that with SCSI and there's a chance you'll mess up the whole chain and nothing will work

[VJ]

Yes, but with IDE it's simpler: disconnect the drive and see if it works. I haven't seen Conner drives in years...AFAIK they've been "bought back" by Seagate (they were ex-Seagate employees if I remember correctly).

Actually, with the problem I had, each Conner drive worked flawless on its own... But put them together, and one of them failed; depending on which one was master/slave I could actually choose which drive would fail. So as far as problem locating goes, this was a tough one. (turns out that one factory jumpers was placed incorrectly on both drives; yet the drives worked for over a year in this master/slave configuration with the incorrect jumper)

Do that with SCSI and there's a chance you'll mess up the whole chain and nothing will work

I don't agree with this. The only things that one should be aware of is if the drive is the terminator (nowadays, drives cannot terminate anymore) and that there is sufficiant term power. I don't see any other reason why the rest of the drives should fail if you leave one drive out of the chain (nor have I had such issues, other than the case described above).


Jörg

[Wombat]

However, the IBM drive was supplying termination power, so I'm now thinking that the lack of the IBM drive caused bus problems. I changed some settings on my cable, and now it never seems to occur.

Strange that nothing else was providing term power.

[Wombat]

Yes, but with IDE it's simpler: disconnect the drive and see if it works. I haven't seen Conner drives in years...AFAIK they've been "bought back" by Seagate (they were ex-Seagate employees if I remember correctly).

There's tons of employee mingling in HD companies (Seagate and Maxtor trade employees faster than poker chips).

Connor the man set up Connor the company. That company was bought by Seagate. Connor then came out of retirement and started Excelstor.

[VJ]

Strange that nothing else was providing term power.

Normally, the host should supply term power. But as I had frequent SCSI issues, I tried setting one harddisk to also supply term power, and all my issues were solved.

So I guess the host isn't supplying enough power on its own.
(cable is an U320, 7 drop with built in active terminator; supplied with the mainboard)


Jörg

[Wombat]

There should be no harm in having everything trying to provide term power. AFAIK, you can't overdo it.