A Windows 98 & ME forum. Win98banter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » Win98banter forum » Windows 98 » General
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

Bill Blanton: Re Re MBR switch thread



 
 
Thread Tools Display Modes
  #1  
Old June 26th 04, 06:08 AM
jt3
external usenet poster
 
Posts: n/a
Default Bill Blanton: Re Re MBR switch thread

Bill,
I'll put this to you if you don't mind raking it
up--again/still--depends on which side of the 'post' you're on but after
more experimentation with the spare 850 MB hard drive ( I think the
other-the 8G- has been shotgunned) the result is this:
1) there's no problem with the primary channel/controller, at least
*normally*. After several misstarts that I didn't understand at the time, I
found that I could get W98se installed just fine, and have it run, just
fine, as long as, once the installation was complete, I only transferred
files to the disk via floppy, or from directory to directory (i.e., just
modifying the FAT). Ran the thing all day a couple of days in a row--made
no difference. However, since I can write to the hd from the floppy, it
doesn't seem to be the primary controller.
2) naturally, I installed the OS from the CD installation disk, but of
course, since it was always after a fresh format (since the disk was always
a mess from the previous time) it was always from a startup disk--DOS 7--
and *MSCDEX*, of course, since that's how it gets CD function during a fresh
install. Everything is fine at this point, and even after--*if you don't
write from the CDROM drive*.
3) even though everything looks just fine in a dir or explorer view of
the disk, * as soon as you write something to the hd from the CD drive*
you've trashed the disk!! So there must be something peculiar to the
protected mode driver that some how makes this trashing possible. Very
strange, since it worked before, and still works in real mode. I changed
the BIOS secondary channel selection to 'not installed', re-formatted,
installed, and the same thing, exactly, recurred. So it doesn't seem likely
that there's something odd with the BIOS doing it, that was only grasping at
straws, anyhow.
4) the sound card (SB) has an IDE adapter, and though I've never used it
for anything, the OS does install a Creative IDE controller (Dev Mgr) using
IRQ 10, but I can't see how that could cause anything like this. There are
certainly no conflicts in Dev Mgr. I am thinking of taking the CD R/RW
drive off the Promise secondary channel and putting it on that to see if it
works and if the same thing happens there.
5) I'll add that the difficulty I had with it sometime before would
probably fit the pattern here, since it followed, similarly, a CMOS Ni-Cd
cell failure, though I can't say that with confidence since I took no notes
and it was too long ago.

I'm running this by you--hoping you haven't gotten too tired of it--in
the hope that it might ring a bell with you.

Thanks,
Joe


  #2  
Old June 26th 04, 07:56 AM
jt3
external usenet poster
 
Posts: n/a
Default Bill Blanton: Re Re MBR switch thread

Scratch giving it any thought--this is too inconsistent to worry about any
more.
Thanks again,
Joe
"jt3" wrote in message
...
Bill,
I'll put this to you if you don't mind raking it
up--again/still--depends on which side of the 'post' you're on but

after
more experimentation with the spare 850 MB hard drive ( I think the
other-the 8G- has been shotgunned) the result is this:
1) there's no problem with the primary channel/controller, at least
*normally*. After several misstarts that I didn't understand at the time,

I
found that I could get W98se installed just fine, and have it run, just
fine, as long as, once the installation was complete, I only transferred
files to the disk via floppy, or from directory to directory (i.e., just
modifying the FAT). Ran the thing all day a couple of days in a row--made
no difference. However, since I can write to the hd from the floppy, it
doesn't seem to be the primary controller.
2) naturally, I installed the OS from the CD installation disk, but of
course, since it was always after a fresh format (since the disk was

always
a mess from the previous time) it was always from a startup disk--DOS 7--
and *MSCDEX*, of course, since that's how it gets CD function during a

fresh
install. Everything is fine at this point, and even after--*if you don't
write from the CDROM drive*.
3) even though everything looks just fine in a dir or explorer view of
the disk, * as soon as you write something to the hd from the CD drive*
you've trashed the disk!! So there must be something peculiar to the
protected mode driver that some how makes this trashing possible. Very
strange, since it worked before, and still works in real mode. I changed
the BIOS secondary channel selection to 'not installed', re-formatted,
installed, and the same thing, exactly, recurred. So it doesn't seem

likely
that there's something odd with the BIOS doing it, that was only grasping

at
straws, anyhow.
4) the sound card (SB) has an IDE adapter, and though I've never used

it
for anything, the OS does install a Creative IDE controller (Dev Mgr)

using
IRQ 10, but I can't see how that could cause anything like this. There

are
certainly no conflicts in Dev Mgr. I am thinking of taking the CD R/RW
drive off the Promise secondary channel and putting it on that to see if

it
works and if the same thing happens there.
5) I'll add that the difficulty I had with it sometime before would
probably fit the pattern here, since it followed, similarly, a CMOS Ni-Cd
cell failure, though I can't say that with confidence since I took no

notes
and it was too long ago.

I'm running this by you--hoping you haven't gotten too tired of it--in
the hope that it might ring a bell with you.

Thanks,
Joe




  #3  
Old June 26th 04, 04:40 PM
Bill Blanton
external usenet poster
 
Posts: n/a
Default Bill Blanton: Re Re MBR switch thread

"jt3" wrote in message ...

after more experimentation with the spare 850 MB hard drive ( I think the
other-the 8G- has been shotgunned) the result is this:


Is that the WD drive?
http://www1.vobis.de/bbs/support/brett24/compnote.txt

1) there's no problem with the primary channel/controller, at least
*normally*. After several misstarts that I didn't understand at the time, I
found that I could get W98se installed just fine, and have it run, just
fine, as long as, once the installation was complete, I only transferred
files to the disk via floppy, or from directory to directory (i.e., just
modifying the FAT). Ran the thing all day a couple of days in a row--made
no difference. However, since I can write to the hd from the floppy, it
doesn't seem to be the primary controller.


You mean from within Windows?

2) naturally, I installed the OS from the CD installation disk, but of
course, since it was always after a fresh format (since the disk was always
a mess from the previous time) it was always from a startup disk--DOS 7--
and *MSCDEX*, of course, since that's how it gets CD function during a fresh
install. Everything is fine at this point, and even after--*if you don't
write from the CDROM drive*.


3) even though everything looks just fine in a dir or explorer view of
the disk, * as soon as you write something to the hd from the CD drive*
you've trashed the disk!! So there must be something peculiar to the
protected mode driver that some how makes this trashing possible. Very
strange, since it worked before, and still works in real mode.


How do you know it "works in real mode"? Did you mass copy files to the
HD from real-mode DOS?


Reinstall again (if the install is now corrupt), and after it is finished, boot to
safe mode. Right-click MyComputer properties Performance (tab) File
System... (button) Troubleshooting (tab) "Disable protected-mode
hard disk interrupt handlers" reboot. Any change?

(If the Windows doesn't boot, then boot to a command prompt and run
Scanreg /restore
)

Another thing you can do for testing purposes is to disable the 32-bit
p-mode drivers altogether. On the same properties sheet. "Disable all
32-bit protected-mode disk drivers." This forces Windows to use the
16-bit real mode BIOS interrupt routines, ("DOS compatibility mode")
for all HD access.

Both of these settings affect disk I/O performance, but it will give you more
clues as to what is the cause.


I changed
the BIOS secondary channel selection to 'not installed', re-formatted,
installed, and the same thing, exactly, recurred. So it doesn't seem likely
that there's something odd with the BIOS doing it, that was only grasping at
straws, anyhow.


Are you jumpering the drives correctly? Master/Slave? Single?




  #4  
Old June 27th 04, 09:14 AM
jt3
external usenet poster
 
Posts: n/a
Default Bill Blanton: Re Re MBR switch thread


"Bill Blanton" wrote in message
...
"jt3" wrote in message

...

after more experimentation with the spare 850 MB hard drive ( I think

the
other-the 8G- has been shotgunned) the result is this:


Is that the WD drive?


Yes. Thanks for the link; it's essentially the same as I downloaded from
the Promise site a couple of years ago when first dealing with this problem,
which at the time I thought was due to Win95, and due to the note, possibly
the WD drive. I don't think so anymore.

http://www1.vobis.de/bbs/support/brett24/compnote.txt

1) there's no problem with the primary channel/controller, at least
*normally*. After several misstarts that I didn't understand at the

time, I
found that I could get W98se installed just fine, and have it run, just
fine, as long as, once the installation was complete, I only transferred
files to the disk via floppy, or from directory to directory (i.e., just
modifying the FAT). Ran the thing all day a couple of days in a

row--made
no difference. However, since I can write to the hd from the floppy, it
doesn't seem to be the primary controller.


You mean from within Windows?


That's what I meant, but I'm no longer convinced of that. After posting
that, I tried again, and the thing stopped working altogether.

2) naturally, I installed the OS from the CD installation disk, but

of
course, since it was always after a fresh format (since the disk was

always
a mess from the previous time) it was always from a startup disk--DOS

7--
and *MSCDEX*, of course, since that's how it gets CD function during a

fresh
install. Everything is fine at this point, and even after--*if you

don't
write from the CDROM drive*.


3) even though everything looks just fine in a dir or explorer view

of
the disk, * as soon as you write something to the hd from the CD drive*
you've trashed the disk!! So there must be something peculiar to the
protected mode driver that some how makes this trashing possible. Very
strange, since it worked before, and still works in real mode.


How do you know it "works in real mode"? Did you mass copy files to the
HD from real-mode DOS?


What I meant was that it had to be able to work in real mode in order to do
a fresh install from the installation CD. Did at least four of them with no
hitches--machine ran for a couple of days until I then tried to install Nero
from its installation CD. Hung nearly immediately--followed by 0E's and
0D's and then no boot--usual thing--sometimes a dir will show bits and
pieces of the original FAT contents, along with garbage, and sometimes you
can't get that far--disk isn't readable at all.


Reinstall again (if the install is now corrupt), and after it is

finished, boot to
safe mode. Right-click MyComputer properties Performance (tab) File
System... (button) Troubleshooting (tab) "Disable protected-mode
hard disk interrupt handlers" reboot. Any change?


I may try that, but it depends upon other things, as I will explain below.

(If the Windows doesn't boot, then boot to a command prompt and run
Scanreg /restore
)

Another thing you can do for testing purposes is to disable the 32-bit
p-mode drivers altogether. On the same properties sheet. "Disable all
32-bit protected-mode disk drivers." This forces Windows to use the
16-bit real mode BIOS interrupt routines, ("DOS compatibility mode")
for all HD access.


I should have thought of that, but I didn't.

Both of these settings affect disk I/O performance, but it will give you

more
clues as to what is the cause.


I changed
the BIOS secondary channel selection to 'not installed', re-formatted,
installed, and the same thing, exactly, recurred. So it doesn't seem

likely
that there's something odd with the BIOS doing it, that was only

grasping at
straws, anyhow.


Are you jumpering the drives correctly? Master/Slave? Single?


Yes, believe me, I've been through this so many times with the cranky
machines I have (all somebody else's rejects, at least in part), and
although I know some of them by heart by now, I always check the diagrams,
something I learned, say about 17 years ago when modifying my first
hand-me-down AT and thought I had messed it up!




At this point, all I'll be able to do is to salvage the old ISA card out
of the 386, actually, it's two, one that's normal and one that I patched so
that I could use it for the secondary channel, and though they might tell me
something about what's going on, they won't allow me to check anything about
the VESA channel, and unfortunately nothing about the Promise EIDE 4030+.
The last thing I did was to remove the 4030+ and install a Promise EIDE
2030+ (which I haven't used in a while--it's half as fast as the 4030, when
either of them works). This worked just fine until the first odd ball thing
I did; now it won't work at all either.
The odd-ball thing (I should have known better) was to put another disk
(Quantum 2G I had originally slaved to the Seagate) on the secondary channel
of the 2030 as a master, just to see if the 2030 BIOS was equipped to
recognize the drive. The manual for the 2030 remarks that one may use
large IDE drives on the secondary channel (they will just be slower)--but
says nothing about what it does about the drive table info that wouldn't be
enterable in the machine BIOS--I thought perhaps it's BIOS might, as the
4030 does.
It just hung Win in the loading phase, and after that, even restoring
the whole thing to what it was before, wouldn't get through POST--hd
controller failure msg, with the controller led on continuously, same as
occurred with the 4030.
I can't see what I did that should have destroyed two controllers in a
row. It shouldn't have destroyed anything, save perhaps some data on the
drives, which was a possibility I thought no big risk considering what the
state of the FATs were. Anyhow, VL bus controllers aren't too thick on the
ground, so if I do anything more it will probably be to put a SCSI drive on
the SCSI controller, which, really, is the only reason (other than trying to
figure out why) that would justify pursuing this any longer--it runs my
scanner. Trouble is, most SCSI II drives were pretty small, as I recall.
Anyhow, thanks for all the fish :-)
Joe


  #5  
Old June 30th 04, 03:35 AM
Bill Blanton
external usenet poster
 
Posts: n/a
Default Bill Blanton: Re Re MBR switch thread


"jt3" wrote in message ...

Anyhow, thanks for all the fish :-)
Joe


Yeah, a bunch o' fish, but no keepers..
:-)
Let us know if you ever figure out what the problem is..



  #6  
Old June 30th 04, 05:26 AM
jt3
external usenet poster
 
Posts: n/a
Default Bill Blanton: Re Re MBR switch thread

*If* I do, I will!
Thanks again,
Joe
"Bill Blanton" wrote in message
...

"jt3" wrote in message

...

Anyhow, thanks for all the fish :-)
Joe


Yeah, a bunch o' fish, but no keepers..
:-)
Let us know if you ever figure out what the problem is..





 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
MBR switch on FDISK jt3 General 30 June 21st 04 08:56 PM


All times are GMT +1. The time now is 03:45 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 Win98banter.
The comments are property of their posters.