View Full Version : Win XP boot issue
Just started getting boot failure on a SP3 setup: much 'clicking' of hard drives, Default BIOS setttings 'restored', and what appears to be happening is that the 'master' boot drive seems to be getting 'forgotten' as when I reset it (ESC, select drive to hard and appropriate disk) to the drive with boot.ini on, I get a normal bootup. At first I thought it was a dodgy power feed to the boot drive, but now I am not convinced. What can affect the ?BIOS? settings for boot drive?
Bushfiva
19th Jan 2009, 13:15
It might just be a little slow telling the system it's ready. This might be time to download a tool that will report the drive's SMART status to you: it will check several items and give you an estimated time to failure. Most drives support SMART, but unfortunately XP ignores all the warnings over many months, only acknowledging the "I'm dedded" status. There are various free utilities out there, including from the various drive manufacturers. Wikipedia will point you in the right direction if you want to read more.
You may also want to simply wiggle the data and power cables to the drive, in case it's a micron of crud in the wrong place.
I've done the 'wiggling' etc and checked the volts at pins while 'wiggling' and all seems ok - also have been running HDD Health which shows all ok on the boot drive. It seems as if the system is 'forgetting' which is the boot drive.
robdesbois
19th Jan 2009, 13:38
If the BIOS settings are being reset whenever the machine is powered up it may be that they are being corrupted due to a loss of CMOS power.
Try changing the CMOS battery - usually a CR2032 watch battery, that should fix it.
--rob
Rob - it is 'irregular - started yesterday with a blue screen shutdown and then 2 boots, one reboot yesterday and a cold start today. No rhyme nor reason.
green granite
19th Jan 2009, 15:39
I would go with Rob If the battery is getting low it could well only be intermittent at this stage. Having said that I had a similar problem with an old m/c of mine, took the battery out to find out what it was and found it a bit corroded, cleaned it up along with the contacts and it was fine. The only other possibility is low volts from the PSU to the bios chip making reading it a lottery.
The above is assuming its not a drive problem, I've also had problems mixing SATA abd IDE drives, the conclusion reached was occasionally it was seeing the IDE before the SATA one and the bios was then trying to boot from that.
As another thought, if you've got "auto-detect" on for the disk, try turning it off.
I've had a similar problem - twice, on two different machines - caused by the IDE cable being faulty. Yes, the big ribbon thing that costs about £2. I now keep a couple of spares :)
Thanks guys - a few pointers there. I boot from IDE. I'll checkout the batt and cable.
jimtherev
19th Jan 2009, 21:04
Another thing I learned the hard way. Two ATA connectors, 2 SATA connectors. Soooo,
Two hard drives plugged to SATA, two DVD writers to ATA '0'. Gave me a spare ATA for my old drive with all the archives on.
Worked!
Next day, didn't work. Disconnected ATA drive, all ok. Plugged in ATA again. Ouch. ATA drive had been killed, fortunately after giving me the archives.
Responded to a low-level format on er-indoors' machine - but haven't dared use it again in my machine.
But why did it work in the first place?
Jim - 3 IDE, one DVD and one SATA (latter in about 2 weeks)
jimtherev
19th Jan 2009, 22:12
...makes 5 channels overall?
Did I read somewhere (think I did whilst scratching my head & Googling) that some motherboards can only reliably manage 4 ATA channels of whatever flavour? Just maybe...
OK! Not sure what to do about that. I have 2 IDE conns and 2 SATA on the mobo. I assumed that would give me up to 6? A bit of a grey area for me.
Same problem this am on initial boot - it had 'lost' the boot seqeunce.
Bushfiva
20th Jan 2009, 08:07
ATA and SATA are different things. You don't add them up together. (In most cases)
If I read you right, BF, you are saying that config should be ok?
Bushfiva
20th Jan 2009, 09:49
ATA is up to 2 devices per channel, and on most motherboards there are 2 channels. Hence the cable with master & slave devices. So, 4 devices without adding another controller. SATA is one device per channel, hence one cable per device; motherboards commonly support 2 to 6 channels. All things being equal, the ATA and SATA hardware don't know/care about each other. There are exceptions, but they don't creep up on you unannounced. In your case, 2 ATA connectors + 2 SATA connectors = (4+2)=6 devices.
I still think you're in "wiggle every cable and run a SMART utility" territory at the moment. Swap out Since you've got 2 ATA cables in there, try swapping them over. I guess change the motherboard battery if it's trivial, but they're usually not CR2032 these days, and the sign of a dying battery is usually incorrect clock time when you boot rather than boot order, since boot order is set, on the ATA bus, by cable/drive connection. It's unclear from you previous messages, but have you recently changed to booting from SATA?
No, still boot via boot.ini on Disk 0, part 0. SATA is merely 'storage' at the moment.
jimtherev
20th Jan 2009, 17:36
From BFiva: " since boot order is set, on the ATA bus, by cable/drive connection. "
Not quite. Hierarchy is set by cable/drive connection. Boot order is set by bios. On my MoBo, and on 'erindoorses, too, I've used the bios to boot from channel 0 device 0 and/or channel 0 device 1 when installing new op system, thus making my former 'c' drive the new 'd' drive. Then I can copy my docs across at my leisure... or not, when I was playing with Vista in beta - what a terrible experience that was. But then I could go back to '0-0' again without losing anything.
And that of course is the sort of thing I was trying to do when using a fifth drive. I'm always trying to be too clever. :*
Bushfiva
21st Jan 2009, 01:48
Not quite
Was just going into enough detail to get the job done. BOAC, change the fekkin' battery, if it's got one, and put us out of our misery.
:) BF - I appreciate your sheltering me from the rough bits of computing, but what about the 'correct' clock time I have? It is relevant to know where the boot order is coming from.
Normal start this am :confused:
Update - several boots with no problem. No changes to anything. Still puzzled.
I'm tempted to leave well alone until the next 'outbreak':)
No 'date' issues - !and no more 'clicking'! mem check 100% but I have had a bad run of Maxtor drives up to now and I still have a couple (guarantee refurbed) installed so there are a few options.
Saab Dastard
24th Jan 2009, 13:22
BOAC,
I had a situation some years ago on a PC with 2 hard disks, when one of the 2 disk (the Win2K) disk sometimes didn't spin-up in time for the POST to recognise it, so the system booted off the 2nd disk, which was still bootable with Win98.
Neither disk was dodgy, but I eventually concluded that it was a PSU problem, and after changing it, the problem never re-occurred.
SD
Thought I should 'report back' - problem solved (I think!). Due to frequent plugging and unplugging of my failing ***** Maxtor drives I reckon the female connectors on the power lead had slackened off. A quick poke with a small screwdriver to reclose them and I then plugged that connector onto my DVDRom which was not being replaced 'under repair warranty' every 5 minutes like the drives and all well so far.
PS I have given up with Maxtor (now I believe Seagate owned) now that the last warranty repair has been used.:mad:
jimtherev
13th Feb 2009, 09:10
Thought I should 'report back' - problem solved (I think!). Due to frequent plugging and unplugging of my failing ***** Maxtor drives I reckon the female connectors on the power lead had slackened off. A quick poke with a small screwdriver to reclose them and I then plugged that connector onto my DVDRom which was not being replaced 'under repair warranty' every 5 minutes like the drives and all well so far.
Thanks - I'd been wondering if you got it sorted.
Just a thought: if you'd gone Keef's route and replaced the power supply, that would have cured it, too, and you would never have discovered what the real problem was. :hmm:
Complicated things, these 'puters, ain't they?
p.s. Nothing wrong with Keef's suggestion, of course, 'twould have worked, and psus are also inexpensive these days.
that would have cured it, too, - yes, unless, of course, I re-used one of my cables.........................:)
Jofm5
17th Feb 2009, 04:40
Plug and Play...
If you switch this off in the bios this can help to prevent this and similar problems.
Plug and Play is where the bios tries to allocate hardware resources it finds in best manner appropriate. This can be a good thing but the downside is that if your situation is constantly changing like a dodgy connection to a slave drive etc the whole config of the computer changes and the bios and windows can get its knickers in a twist big time.
Whilst plug and play is a great concept - it has never really worked well and is best switched off.
Cheers
Ta Jof.........................................................
Saab Dastard
17th Feb 2009, 10:41
Whilst plug and play is a great concept - it has never really worked well and is best switched off.
Disagree heartily on this.
For the vast majority of people, having to faff about with IRQs and port numbers was a massive headache.
P&P works sufficiently well to be the approach of choice.
Agreed that in the tiny percentage of cases where an intermittent problem is causing frequent re-allocation of resources, it can add a layer of obfuscation.
But fix the underlying problem and P&P works fine.
SD
Jofm5
17th Feb 2009, 11:01
I see what your saying but the problems are ever present.
The fact you switch of plug and play does not require the manual setting of IRQ's in any respect.
The interrupt request lines will still be set but in a cascading order, i.e. on a first come first served basis - if you enable plug and play it will try to optimise this which is where the juggling comes in - as hardware comes and goes things move about and the drivers have to reset and reconfigure themselves.
When plug and play is off - when a device drops it does not affect the other devices as it does not try to optimise.
Best to leave it off and cascade, may be more inefficient in some instances but can save alot of headaches.
Saab Dastard
17th Feb 2009, 12:10
Jofm5
It's so long since I had to look at this I bow to your greater knowledge.
I do recall the days of ISA / EISA cards when IRQs and I/O ports had to be specified - on the card (jumpers / switches) and the BIOS (reservations), and also in the OS. :yuk:
The introduction of P&P spanned the demise of ISA and the introduction of PCI, and I will admit to some confusion now as to which required what, where and how!
At the same time, Win 95 introduced P&P at the OS level.
I recall being impressed that multiple devices could now "share" a single IRQ (usually 10, IIRC).
I also remember being infuriated by Win 9x's insistence on "managing" IRQ allocations, when faced with a mix of P&P and non-P&P devices - and eventually switching off P&P!
I do remember it being referred to as Plug and Pray. :rolleyes:
But since then, I have not, to my knowledge, had a P&P related issue.
Are you referring to the BIOS level or the OS level - or both?
SD
Bushfiva
17th Feb 2009, 12:43
I bow to your greater knowledge
Weenie.
In the interests of 10 characters, you're still a weenie.
Jofm5
17th Feb 2009, 19:05
Saab Dastard:
I do remember it being referred to as Plug and Pray. :rolleyes:
But since then, I have not, to my knowledge, had a P&P related issue.
Are you referring to the BIOS level or the OS level - or both?
The plug and pray was the issue in the early days as when P&P was first introduced there were alot of cards that were not P&P and as you rightly say the jumpers had to be set to avoid conflicts.
If we look to what actually happens in a simplistic manner (You may know this but will provide a full explanation for those that dont) it will be alot clearer.
An IO card will function whilst the CPU is busy doing something else for example a network card will montior network traffic and receive until its buffer is full. When the card has something to provide to the CPU it will raise the interrupt line to the CPU alerting that it is ready. The CPU will then tell the card to put its information in an area of memory and will notify the MMU (Memory Management Unit) to move this data when it arrives to a specific location where the driver can access it.
The point of P&P and jumpers is to identify where in memory to place this temporary information for the MMU to access. Each card will require a different memory location so that it does not overwrite any information from other cards.
With P&P each card on start up will interrogate the P&P controller to see where it would like the information to be placed - so with each power on of the system if the configuration has changed the controller may provide a different address for the card to use.
When not using P&P when the system is first powered on a P&P card will default to a location and look to see if it is being used. If it is not it will use the location, if it detects a conflict it will move. Thus each time you add a card to a system it will go through the conflict resolution process. But in this instance if you remove a card it will not change the address on any existing cards remaining.
Plug and Pray was the name given because the older jumpered cards were not aware of the P&P controllers actions that could result in conflict and the P&P controller expects no conflict resolution for non P&P cards as it was assuming it had full rights over the whole address space. The answer was to switch P&P off so that each P&P card would manage conflict resolution with the jumpered cards and move elsewhere.
Legacy P&P on an OS Level is purely setting the bios of a card to a known address that is free by means of the OS detecting what is already installed - however the downfall of this legacy method was that if OS did not have the driver loaded it was not aware that a card may already be installed and could generate conflict.
Modern P&P in operating systems interrogates the P&P controller on boot to see what devices it is serving and where they are, it matches this to its current known list to see if anything has changed and whether a driver needs loading.
A well behaved driver should not care where a card places its transient information in memory however some drivers rather than let the MMU manage the memory try to manage it themselves. Thus when the P&P controller moves adresses of devices all can get a bit screwey and drivers have to be unloaded and reloaded. This issue exists as on a processor level the drivers run at the same protection level as the operating system and therefore have full remit over the physical memory of the whole machine. If anyone needs me to explain protection levels let me know - I think I have put most to sleep by now already lol.
Cheers
Jof