> On Mon, 5 Nov 2007 11:41:14 -0500, "DaddyJim"
> <jj2145@yahoo.com> wrote:
>
>
>>Guess I've really ******* up now. Took first posts advice, tried repair, now
>>I get the Verifying DMI Pool Data with 2 Y's at bottom of screen with crazy
>>symbol beside each Y. Have no idea what this means, except messed up drive
>>even more I suppose. I have installed another drive, loaded win xp, and
>>everything working fine. Point is, I wanted to salvage data on other drive,
>>(which I know for a fact was good drive), but I took bad advise. Live and
>>learn I guess.
>>
>
>
>
> I know of no particular issues with your motherboard or
> chipset, it should've been fairly straightforward to install
> and boot XP. I also wonder if the drive label shows the
> jumpering in a confusing way and the jumpers are still
> wrong.
>
> You wrote that you booted the XP CD, it saw the drive and
> existing XP installation on it, and it seemed to do a repair
> on that installation and complete successfully, but still it
> does not boot? Had you yet rechecked the jumpering to be
> "single" and disconnected the other drives? Regardless,
> if the old XP installation won't boot on the new system then
> the current goal is getting the motherboard bios to properly
> detect the drive then to just boot to the new drive, new XP
> installation and proceed to copy the data off the other
> drive.
>
> If the other/old drive is unresponsive in windows and/or not
> properly detected in the bios then it is time to run the HDD
> manufacturer's utilities. Having "repaired" XP would not
> have done away with your data, it should still be on the
> drive as before the repair... unless you really meant you
> did a new clean install which included formatting the drive
> (chosing specifically to do so) right before beginning that
> install to that drive and partition.
These are some pretty broad assumptions that would have no consequence
had the error reported by the "verifying DMI pool data" message. But the
mis-detection or the wrong detection of the track arrangements of a hard
drive stems from the corruption of the bios tables. In the plug-and-play
bioses, the corruption is so much easier due to the Windows OS being able,
in particular, to write to and update the bios tables through the data
management interface (DMI). Whilst there are conventions established by
the DMTF, an improper write to the bios tables, including a 1-bit frame
shift, is enough to corrupt the tables. Think that the PnP Windows OSes
are that perfect when sending device data to the system bios?
The precaution written by GHalleck should have been taken into advisement.
If the bios table data for the hard drive is missing or incorrect, then
imagine what the Windows repair did to the drive's existing geometry.
On Mon, 05 Nov 2007 15:11:08 -0800, Ghostrider
<-00-@fitron.142> wrote:
>
>kony wrote:
>
>> On Mon, 5 Nov 2007 11:41:14 -0500, "DaddyJim"
>> <jj2145@yahoo.com> wrote:
>>
>>
>>>Guess I've really ******* up now. Took first posts advice, tried repair, now
>>>I get the Verifying DMI Pool Data with 2 Y's at bottom of screen with crazy
>>>symbol beside each Y. Have no idea what this means, except messed up drive
>>>even more I suppose. I have installed another drive, loaded win xp, and
>>>everything working fine. Point is, I wanted to salvage data on other drive,
>>>(which I know for a fact was good drive), but I took bad advise. Live and
>>>learn I guess.
>>>
>>
>>
>>
>> I know of no particular issues with your motherboard or
>> chipset, it should've been fairly straightforward to install
>> and boot XP. I also wonder if the drive label shows the
>> jumpering in a confusing way and the jumpers are still
>> wrong.
>>
>> You wrote that you booted the XP CD, it saw the drive and
>> existing XP installation on it, and it seemed to do a repair
>> on that installation and complete successfully, but still it
>> does not boot? Had you yet rechecked the jumpering to be
>> "single" and disconnected the other drives? Regardless,
>> if the old XP installation won't boot on the new system then
>> the current goal is getting the motherboard bios to properly
>> detect the drive then to just boot to the new drive, new XP
>> installation and proceed to copy the data off the other
>> drive.
>>
>> If the other/old drive is unresponsive in windows and/or not
>> properly detected in the bios then it is time to run the HDD
>> manufacturer's utilities. Having "repaired" XP would not
>> have done away with your data, it should still be on the
>> drive as before the repair... unless you really meant you
>> did a new clean install which included formatting the drive
>> (chosing specifically to do so) right before beginning that
>> install to that drive and partition.
>
>
>These are some pretty broad assumptions that would have no consequence
>had the error reported by the "verifying DMI pool data" message. But the
>mis-detection or the wrong detection of the track arrangements of a hard
>drive stems from the corruption of the bios tables. In the plug-and-play
>bioses, the corruption is so much easier due to the Windows OS being able,
>in particular, to write to and update the bios tables through the data
>management interface (DMI). Whilst there are conventions established by
>the DMTF, an improper write to the bios tables, including a 1-bit frame
>shift, is enough to corrupt the tables. Think that the PnP Windows OSes
>are that perfect when sending device data to the system bios?
>
>The precaution written by GHalleck should have been taken into advisement.
>If the bios table data for the hard drive is missing or incorrect, then
>imagine what the Windows repair did to the drive's existing geometry.
The entirety of what you have written is exceedingly
unlikely if not impossible. DMI does not generate a drive
table used to access the drive before
booting/causing-failure, DMI is a reporting function
separate from the main bios functionality.
The message comes up on any system whose bios is designed to
display it, then simply stays on screen when nothing boots
to cause the screen to display something else instead.
There is zero evidence there was even windows running when
the non-booting drive was installed, then subsequently a
different drive then works to install and boot windows.
There might be a bug in the motherboard bios having nothing
to do with DMI, that has misdetected or was not set to
auto-detection and has thus misunderstood the drive
parameters, but given that this variable then became static
and XP was writing it, that static variable should allow the
drive to then be equally accessed upon next reboot attempt
if it were the only problem.
> On Mon, 05 Nov 2007 15:11:08 -0800, Ghostrider
> <-00-@fitron.142> wrote:
>
>
>>kony wrote:
>>
>>
>>>On Mon, 5 Nov 2007 11:41:14 -0500, "DaddyJim"
>>><jj2145@yahoo.com> wrote:
>>>
>>>
>>>
>>>>Guess I've really ******* up now. Took first posts advice, tried repair, now
>>>>I get the Verifying DMI Pool Data with 2 Y's at bottom of screen with crazy
>>>>symbol beside each Y. Have no idea what this means, except messed up drive
>>>>even more I suppose. I have installed another drive, loaded win xp, and
>>>>everything working fine. Point is, I wanted to salvage data on other drive,
>>>>(which I know for a fact was good drive), but I took bad advise. Live and
>>>>learn I guess.
>>>>
>>>
>>>
>>>
>>>I know of no particular issues with your motherboard or
>>>chipset, it should've been fairly straightforward to install
>>>and boot XP. I also wonder if the drive label shows the
>>>jumpering in a confusing way and the jumpers are still
>>>wrong.
>>>
>>>You wrote that you booted the XP CD, it saw the drive and
>>>existing XP installation on it, and it seemed to do a repair
>>>on that installation and complete successfully, but still it
>>>does not boot? Had you yet rechecked the jumpering to be
>>>"single" and disconnected the other drives? Regardless,
>>>if the old XP installation won't boot on the new system then
>>>the current goal is getting the motherboard bios to properly
>>>detect the drive then to just boot to the new drive, new XP
>>>installation and proceed to copy the data off the other
>>>drive.
>>>
>>>If the other/old drive is unresponsive in windows and/or not
>>>properly detected in the bios then it is time to run the HDD
>>>manufacturer's utilities. Having "repaired" XP would not
>>>have done away with your data, it should still be on the
>>>drive as before the repair... unless you really meant you
>>>did a new clean install which included formatting the drive
>>>(chosing specifically to do so) right before beginning that
>>>install to that drive and partition.
>>
>>
>>These are some pretty broad assumptions that would have no consequence
>>had the error reported by the "verifying DMI pool data" message. But the
>>mis-detection or the wrong detection of the track arrangements of a hard
>>drive stems from the corruption of the bios tables. In the plug-and-play
>>bioses, the corruption is so much easier due to the Windows OS being able,
>>in particular, to write to and update the bios tables through the data
>>management interface (DMI). Whilst there are conventions established by
>>the DMTF, an improper write to the bios tables, including a 1-bit frame
>>shift, is enough to corrupt the tables. Think that the PnP Windows OSes
>>are that perfect when sending device data to the system bios?
>>
>>The precaution written by GHalleck should have been taken into advisement.
>>If the bios table data for the hard drive is missing or incorrect, then
>>imagine what the Windows repair did to the drive's existing geometry.
>
>
>
> The entirety of what you have written is exceedingly
> unlikely if not impossible. DMI does not generate a drive
> table used to access the drive before
> booting/causing-failure, DMI is a reporting function
> separate from the main bios functionality.
>
> The message comes up on any system whose bios is designed to
> display it, then simply stays on screen when nothing boots
> to cause the screen to display something else instead.
>
> There is zero evidence there was even windows running when
> the non-booting drive was installed, then subsequently a
> different drive then works to install and boot windows.
>
> There might be a bug in the motherboard bios having nothing
> to do with DMI, that has misdetected or was not set to
> auto-detection and has thus misunderstood the drive
> parameters, but given that this variable then became static
> and XP was writing it, that static variable should allow the
> drive to then be equally accessed upon next reboot attempt
> if it were the only problem.
>
>
The DMI is just an "interface". That is all it is. The issue is what has
happened with the data pool, or the built-in tables that comprise the bios
and its ability to function. I still have my original e-mails with the
original DMTF, when it was known as the "Desktop Management Task Force",
after a particular manufacturer's bios revisions were bringing down all
of our computers of a specific make in the mid-1990's. And the solution
was to shut down the write ability of Windows PnP and stick to the built-
in bios tables and parameters for hardware and avoiding any translational
changes through interpolation by the PnP OS.
Once the corruption has been introduced into the HD bios tables, then it
is not going to be corrected if the hard drive fails to boot, should the
boot sector remains unlocatable. Interesting conumdrum. Even Windows 98
systems were affected but Windows NT systems and their derivatives were
not. We replaced a lot of bioses and, unfortunately, threw away a lot of
good hard drives until someone realized that Windows NT was a non-PnP OS,
meaning that it did not write back to the DMI data pools.
Daddy Jim's motherboard and bios evidently came from a time period when
Windows was being debugged to near-perfection and the DMTF truly came
into being as a significant force for interoperability in computing. This
is why the outcome did not surprise me, especially when a stripped down
bios (? HP) might also have been involved. Been there...seen that.
On Mon, 05 Nov 2007 18:41:30 -0800, Ghostrider
<-00-@fitron.142> wrote:
>The DMI is just an "interface". That is all it is. The issue is what has
>happened with the data pool, or the built-in tables that comprise the bios
>and its ability to function. I still have my original e-mails with the
>original DMTF, when it was known as the "Desktop Management Task Force",
>after a particular manufacturer's bios revisions were bringing down all
>of our computers of a specific make in the mid-1990's. And the solution
>was to shut down the write ability of Windows PnP and stick to the built-
>in bios tables and parameters for hardware and avoiding any translational
>changes through interpolation by the PnP OS.
>
>Once the corruption has been introduced into the HD bios tables, then it
>is not going to be corrected if the hard drive fails to boot, should the
>boot sector remains unlocatable. Interesting conumdrum. Even Windows 98
>systems were affected but Windows NT systems and their derivatives were
>not. We replaced a lot of bioses and, unfortunately, threw away a lot of
>good hard drives until someone realized that Windows NT was a non-PnP OS,
>meaning that it did not write back to the DMI data pools.
>
>Daddy Jim's motherboard and bios evidently came from a time period when
>Windows was being debugged to near-perfection and the DMTF truly came
>into being as a significant force for interoperability in computing. This
>is why the outcome did not surprise me, especially when a stripped down
>bios (? HP) might also have been involved. Been there...seen that.
There is no evidence that DMI has done anything to any HDD
tables. There is however evidence that the 2nd drive
connected did work before windows booted fully again.
This just isn't going to be any kind of DMI issue, the DMI
message seen is just a generic message always displayed
momentarily before the boot device boots. What problems you
might have seen with some boards, and NT in the mid-'90s is
not applicable to this board and XP today.
The OP can try a few things to determine the problem still,
like booting the other drive, which was reported to work
then trying to access the old drive to read from it, or
moving this old drive to another system for subsequent read
or boot attempts.
Frankly I still suspect the drive is jumpered wrong.
Somewhere on the interweb "Ghostrider" typed:
> kony wrote:
>
> > On Mon, 5 Nov 2007 11:41:14 -0500, "DaddyJim"
> > <jj2145@yahoo.com> wrote:
> >
> >
> > > Guess I've really ******* up now. Took first posts advice, tried
> > > repair, now I get the Verifying DMI Pool Data with 2 Y's at
> > > bottom of screen with crazy symbol beside each Y. Have no idea
> > > what this means, except messed up drive even more I suppose. I
> > > have installed another drive, loaded win xp, and everything
> > > working fine. Point is, I wanted to salvage data on other drive,
> > > (which I know for a fact was good drive), but I took bad advise.
> > > Live and learn I guess.
> >
> >
> >
> > I know of no particular issues with your motherboard or
> > chipset, it should've been fairly straightforward to install
> > and boot XP. I also wonder if the drive label shows the
> > jumpering in a confusing way and the jumpers are still
> > wrong.
> >
> > You wrote that you booted the XP CD, it saw the drive and
> > existing XP installation on it, and it seemed to do a repair
> > on that installation and complete successfully, but still it
> > does not boot? Had you yet rechecked the jumpering to be
> > "single" and disconnected the other drives? Regardless,
> > if the old XP installation won't boot on the new system then
> > the current goal is getting the motherboard bios to properly
> > detect the drive then to just boot to the new drive, new XP
> > installation and proceed to copy the data off the other
> > drive.
> >
> > If the other/old drive is unresponsive in windows and/or not
> > properly detected in the bios then it is time to run the HDD
> > manufacturer's utilities. Having "repaired" XP would not
> > have done away with your data, it should still be on the
> > drive as before the repair... unless you really meant you
> > did a new clean install which included formatting the drive
> > (chosing specifically to do so) right before beginning that
> > install to that drive and partition.
>
>
> These are some pretty broad assumptions that would have no consequence
> had the error reported by the "verifying DMI pool data" message.
I've snipped the rest of this as it follows a false assumption; That the
"verifying DMI pool data" is an error message. It's not, it's just the last
thing shown on screen before the machine locks up.
Thanks for all replys and info on this motherboard and hard drive issue I'm
having. Thought I would give an update on whats happened. The computer I'm
building for granddaughter, I put an entirely different drive in, installed
win xp, and everythings fine. The drive that I was having trouble with came
out of pent 4, HP pavillion which takes a small power supply that I don't
have. I took one of my bigger power supplys, hooked up and left outside case
( HP case that drive originally came from), put hard drive back in, and to
my surprise it picked back up on the repair operation with the HP recovery,
and is now working. Working that is with the original motherboard. My guess
is that with XP and HP recovery stuff being preinstalled at factory, this
drive just didn't want to work with another motherboard unless a format was
done. However I really have no idea, but it's working, just not in system I
wanted it for. Thanks again.
Re: motherboard & harddrive-Update 
Linear Mode
