Win XP boot issue

[BOAC]

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]

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

[BOAC]

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.

[jimtherev]

Originally Posted by BOAC

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.

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.

[BOAC]

that would have cured it, too,

- yes, unless, of course, I re-used one of my cables.........................

[Jofm5]

Incidently...

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

[BOAC]

Ta Jof.........................................................

[Saab Dastard]

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]

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]

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.

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.

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]

I bow to your greater knowledge

Weenie.








In the interests of 10 characters, you're still a weenie.

[Jofm5]

Saab Dastard:

I do remember it being referred to as Plug and Pray.

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