http://www.ntcompatible.com/article.php?sid=9564
 
might be a solution, if I could find corresponding drivers for Promise FastTrak 133 [instead of 100]

http://www.promise.com/search.asp?Keywor...=50&Send=Go
 
might just be what I'm looking for...
 
1. FastTrak TX2000
Brief: Ultra ATA/133 RAID 0, 1, and 0+1 Controller
 
FastTrak TX2000 raises consumer-based ATA RAID to professional levels. The FastTrak TX2000 ATA RAID card supports Ultra ATA/133 drives to rock workstations and boost small (or large) office servers like never before.

http://www.promise.com/support/mix_dwn_eng.asp?product_id=88&family_id=2
 
Is drivers / documentation / reviews on ATA/133, Promise TX2000 installation.
 
Loaded IDE Tools from Promise, because I noticed that the "viadsk.sys" driver was dated around april 2000, and now I get blue screen dump when the O/S boots up.
 
CAUTION!
 
Will update ....

Quote:
Re: "thekourier"

I currently speculate that the solution lies in how the O/S is accessing the information in the MBR, and whether the solution becomes yet another overlay file (like for the older, 'NORMAL' drive limit of 528 MB), creating a driver that translates the MBR information into a form that the O/S can use to access all the way to 2 terabytes, or even toying with the BIOS settings manually (like I just tried, but have not attained a solution -- yet) ... or some-such....

Master Boot Record (MBR) should have nothing to do with it. The MBR simply stores the boot code that allows the O/S to find the NT kernel. Now if you've loaded Ontrack or something else into the MBR that might cause a problem.
Personally I still think the issue lies in the BIOS. There should be a new Disk Geometry mode other than LBA, Normal, and Large. My personal speculation is that the "query the drive" mode you've chosen simply asks the disk what it's CHS parameters are. The disk reports 160GB, and the BIOS happily displays it, but can only access 132GB due to it's internal CHS limits. Pure speculation on my part.
What I'd suggest is a trip to the local Fry's and a purchase of a Maxtor ATA/133 PCI card with onboard BIOS. If it solves the problem great, if not, just return it.
Actually, I just took a look at ASUS' site, http://usa.asus.com/inside/Techref/48bithdd.htm, which says that most of the ASUS boards support 48 bit addressing. Maxtor's site has an article here about the 137 GB limit: http://www.maxtor.com/Maxtorhome.htm. So you *should* be ok. I'm very suspiscious though that this is the problem since what NT is reporting is right around 137 GB, 137,000,000,000 / 1024 =~ 133 GB. I know NT 4.0 can deal with disks greater than 137 GB since I used to do that with Compaq SCSI arrarys all the time.

I'll redo these URL's for the benefit of others...
 
http://usa.asus.com/inside/Techref/48bithdd.htm
 
Appears to support evidence that you don't even need the latest A7V333 to access "48bit Large HD."
 
The A7V133 may have been capable, with a 1008 BIOS update...
 
The Maxtor either is running Clustered Servers, or JavaScript which complicates the capturing of a selected page within their web-site...
 
On the topic of the MBR, I am definately weak on... there are 63 sectors in that "0" track, which I have yet to completely understand...
 
I do know that once I can get the O/S up and running (either NT 4 or Win2K) and primary or extended partitions have become deleted (accidently or on purpose), I can use "dskprobe.exe" on either to both find the backup NTFS sector for all the partitions and re-write them back to the FIRST (or original) sector for each partition, and be able to re-access the data from those recovered partitions...
 
The MS KB Q114841 goes into depth explaining the Boot process, and then differences between IDE, Extended IDE, and SCSI, all of which I am not familiar with:
 
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q114841
 
Windows NT Boot Process
 
On Intel-based computers, the system BIOS controls the initial operating system boot process. After the initial Power On Self Test (POST) when hardware components are initialized, the system BIOS identifies the boot device. Typically, this is a floppy disk or a hard disk. In the case of the hard disk, the BIOS reads the first physical sector on the disk, called the Master Boot Sector, and loads an image of it into memory. The BIOS then transfers execution to that image of the Master Boot Sector.
 
The Master Boot Record contains the partition table and a small amount of executable code. The executable code examines the partition table and identifies the active (or bootable) partition. The Master Boot Record then finds the active partition's starting location on the disk and loads an image of its first sector, called the Boot Sector, into memory. The Master Boot Record then transfers execution to that Boot Sector image.
 
Whereas the Master Boot Record is generally operating system independent, the Boot Sector of the active partition is dependent on both the operating system and the file system. In the case of Windows NT and Windows NT Advanced Server, the Boot Sector is responsible for locating the executable file, NTLDR, which continues the boot process. The only disk services available to the Boot Sector code at this stage of system boot up are provided by the BIOS INT 13 interface. The Boot Sector code must be able to find NTLDR and file system data structures such as the root directory, the File Allocation Table (FAT) in the case of an MS-DOS FAT volume or the Master File Table in the case of an NTFS volume. These must be present within the area of the disk addressable by the 24-bit side, cylinder, sector structure used by the BIOS INT 13 interface and the partition table. This limits the size of the system partition to 7.8 gigabytes regardless of which file system is used.
 
NOTE : Other constraints may apply depending on the computer hardware and file system. Some of these constraints are discussed below.
 
In order to accommodate partitions larger than 7.8 gigabytes, Windows NT ignores the values in the Starting and Ending sector address fields of the partition table in favor of the Relative Offset and Number Of Sectors fields. This provides eight additional bits to represent sectors. These additional bits allow partitions to be described with up to 2^32 sectors.
 
With a standard sector size of 512 bytes, the 32 bits used to represent the Relative Offset and Number of Sectors translates into a maximum possible partition size of 2 terabytes or (2,199,023,255,552 bytes).
 
When partitioning a disk, Windows NT will write the correct values to the partition table fields whenever possible. When the total number of sectors in a partition exceeds the number which can be described in Side, Cylinder, Sector notation, Windows NT writes the maximum permitted values to these fields in the partition table. This prevents the system BIOS from attempting to calculate the Starting and Ending addresses based on erroneous data.
 
For example, assume you have a 3.5GB SCSI drive attached to an Adaptec 154x series SCSI controller. If the extended sector translation feature is disabled on the adapter, it might report the following disk characteristics to the system BIOS:
Cylinders: 1023, Sides: 64, Sectors: 32
which translates to about 1 gigabyte. With the extended translation enabled, the device might be reported as having these characteristics:
Cylinders: 435, Sides: 255, Sectors: 63
which translates to about 3.5GB.
 
Once Windows NT is up and running, it uses its SCSI drivers to directly interact with the disk without using the BIOS INT 13 interface. So, during normal operation the BIOS parameters are largely unimportant. However, the differences are critical if the disk is to be formatted with a single partition and used as the boot drive.
 
Without extended translation, Windows NT notices that the disk is larger than the BIOS parameters indicate. When Windows NT partitions the drive during initial installation, the starting and ending sector addresses will be filled in with their maximum possible values. This makes it impossible for the Master Boot Record code to function correctly despite the fact that the drive is less than 7.8 gigabytes.
 
With extended translation, Windows NT will be able to write valid values for the starting and ending addresses into the partition table, and thus, the partition remains bootable.
 
[complete text at URL]

BTW... *now* I need to get rid of the BLUE SCREEN dump, and get back into the O/S... and there are other pressing items...
 
So this may take a bit....

Repair replaced most of the 100+ files requested to be restored. [How did upgrading the VIA IDE driver cause so much corruption?]
 
Some files were missing information, so all I could to is cancel through.
 
I may need to attempt to repair a couple of times [which I will try first]... but I may just need to rebuild the O/S partition... just as well.
 
May finally get this working properly anyways....
 
At least the data was on different partitions (& mirrored) - at least the data on the same drive as the O/S.
 
The data on the other drives should be ok...
 
l8tr...

Quote:
Does this help to explain, why?

Not really, no. People who persist with older OS when a newer one has a chance of solving their problems are idiots IMO.

Why don't you try Linux? You can't ***** about the price of that because its free and it'll support those hard drives (and software RAID 5 too). You want a file server? Install Samba (making sure to set up encrypted password support if you're a security nut). You want a web server? Apache is bundled with most distributions and if not, it's just a download away.

Perhaps I could be an "idiot," or as I had posted earlier "...it's cheap enough, and I happen to know just enough to know how to get done what I want to do."
 
I had always believed that I would NOT mind learning Linux &/or Unix, however, it's not simply a matter of a File Server here. It's an network & an IIS server, one with logon & Password authentication. Can anyone offer free time to train me, and then trouble shoot, at my beck and call, until I get up to speed & continue with this project?
 
Sound like all I need is to stop *everything,* and learn Samba, Apache, Linux, and whatever it takes to run a NewsGroup Server... sweep the floors, cook breakfast, lunch & dinner, dust, empty the garbage, make DOE to pay the rent with, put gas in the car, have time to date, pay for lunch.... gee...!
 
sounds so simple...
 
Am I talking to a Guru here?
 
Haven't exactly convinced me that your solutions are all that quick, neither spent any time offering a solution....
 
"I do not pretend to know what many ignorant men are sure of."
-- Clarence Darrow

OK after reading the thread through again I think I have an idea what your problem might be: NT4's NTFS drivers are probably incapable of accessing more than 127Gb. Fixing it probably isn't going to be simple seeign as though M$ are no longer providing support for it. Question: Is Disk Administrator the only program you've used to try and partition the drives? Have you tried Partition Magic or something similar?

NTFS on NT 4.0 can create and access partitions and filesystems of up to 2TB in size. It has nothing to do with NTFS. I should know. I ran a 300 GB file server on NT 4.0 Server with one filesystem. Took me 1 hour to backup with AIT-1 tape drives. Compaq arrays are sweet.
NT's disk administrator (DA) should always show the correct disk size. If NT had a partition size limit, DA would only allow you to create a partition of size X, but you could then create a 2nd partition Y on the leftover space. His problem is that NT is reporting the physical disk size is only 132GB.
Admiral LSD, you need to get a life. Calling someone an idiot just because they run a particular O/S. So you hate Microsoft. Big hairy deal. Get over it. People should run the OS that they're comfortable with and that makes business sense for them. He is comfortable with NT and is having a problem. That's what the Internet community is for, not for zealots that argue that their OS is the only solution to the world's problem.
I run Linux on a 2nd system, and believe you me, it's no picnic. Installing apache is easy? Try downloading and installing GCC, and automake, then compiling perl and apache, then getting PHP and editing a bunch of text config files. Golly gee, sounds way easier than Add/Remove Programs and choosing IIS. Granted IIS isn't perfect, but run what makes sense for you, not degrade others for their choice. It's still a free world. [/$.02]

Quote:os name[Windows XP Professional] csd[] version[5.1] build[2600] uptime[16h 46m]

Now say I hate M$ again...

And given my recent experiences with IIS I'd take Apache any day...

Another thing: You must be a real pussy if a few config files scare you... I'd rather have the cut-and-dry config files than having to dive through 6 tonnes of registry ****...

If it's on the Internet --- one must digress? )
 
Anyhoo...
 
Disk Administrator is a Administrative Tool within NT 4.0 & Win2K.
 
I perhaps could get my hands on Partition Magic, but Disk Administrator is an integral part of the O/S, and if DA can't see the whole drive, will it matter that PM can?
 
Dunno,...
 
Still have to attempt to recover the O/S, and if not re-install... this being the [currently] shortest path to a solution, and with luck, may trip across a solution... insight... while I'm meditating during the file transfer process....
 
Hang tight onto your favourite O/S strings whilst I get some sleep, go about a 'normal' day, get back here.... and give it a shot... and keep this current 'hot' thread going.... until a solution pops...

I know what DA is, my upgrade path to XP involved both NT4 and Windows 2000

Apparently the key to accessing HDD's over 137 GB is a BIOS that is capable of 48-bit LBA.
 
The older version of this motherboard, the A7V133, *WITH* BIOS 1008 will access the entire 160 GB HDD, using Win98. I'll be getting around to trying other O/S's shortly.
 
Here's a little info from Promise about 48-bit LBA:
 
http://www.promise.com/company/press_news_detail_eng.asp?press_id=36

But didn't you say that the motherboard can recognise the complete capacity (thus indicating the motherboard is capable of 48-bit LBA)?
 
Humour me for a moment: Do you know anyone with Win2k or XP that can test the drive for you?
 
I'm still thinking it has something to do with NT4's implementation of NTFS... It took 3 (or was it 4 or 5?) ervice packs to lift the 4Gb boot parition barrier and even then it only lifted it to 8. While that has no bearing on your issue it proves that NT4's implementation of NTFS isn't as perfect as thekourier would like to believe.

http://usa.asus.com/inside/Techref/48bithdd.htm
 
This URL is a list of ASUS motherboards, and the associated version of BIOS that is required to access over 137 GB HDD's.

Quote:
But didn't you say that the motherboard can recognise the complete capacity (thus indicating the motherboard is capable of 48-bit LBA)?

Quote:
While POST recognizes 163,928 MB drives



Seriously, given the fact that the POST recognises the correct capacity then that would indicate that you're barking up the wrong tree in thinking anything is wrong with the hardware.

Re: ATA/133 versus 48-bit LBA.
 
I was led to believe that to access HDD's over 137 GB, I needed a ATA/133 capable host adapter.
 
This is not the case. My recent posts are to clarify this issue for others, having been led down the garden path.
 
I could have saved myself both money & time in changing over the motherboards from the A7V133 to the A7V333.
 
All one needs is a BIOS that has been revised [if it is possible] to support 48-bit LBA.
 
Apparently, the ATA/133 is an attempt to get higher bandwidth through-put to HDD's, which by my experience, is barely noticeable. My speculation is that the bandwidth of the PCI bus is maxed out at 133 MB/sec, and trying to access 100% of that bandwidth *just* for the HDD is a fruitless chase...
 
This difference between what was necessary to access HDD's over 137 GB was not made clear to me.
 
So far, the only advantage to me of the A7V333 is DDR RAM, capable of PC2700, or 2,700 MB/s bandwidth -- a considerable jump over the SDRAM.
 
*IF* someone wants a trolley-load of toys, [particularly I/O] 1394, USB 1.1 & 2.0, ATA/133, on-board audio & NIC, and AMD XP capable... then by all means, this is a wonderful such toy...