| Author |
Message |
J. Clarke
Guest
|
 Posted:
Wed Nov 09, 2005 6:46 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
Barry OGrady wrote:
| Quote: | On Mon, 07 Nov 2005 08:19:22 -0500, "J. Clarke"
jclarke.usenet@snet.net.invalid> wrote:
Barry OGrady wrote:
On Mon, 7 Nov 2005 12:09:29 +0100, "Peter T. Breuer"
ptb@oboe.it.uc3m.es> wrote:
John Doue <notwobe@yahoo.com> wrote:
You have been clear enough. I am not sure I follow Peter (I recognize
my technical limitations in this area) but recognized size limitations
due to bios are a well known problem (see the second link at end of
post)
No they AREN'T. Please stop letting vague concepts step in front of your
frontal cortex! If you don't grok "bios is not used in disk i/o" you
are at a serious disadvantage from the get-go and you need to work on
assimilating that idea first. The bios can do no "limiting", since it is
not used.
What I daresay is happening is that the win o/s starts up with the cpu
in real mode (I don't know why ... to emulate dos?) and asks the bios
how big the disk is, then carries that info over to the multitasking o/s
that takes over in virtual 386 mode. A multitasking o/s cannot run in
real mode. Bios can only be used in real mode. You need to appreciate
those two facts to understand why the idea of the bios playing any
part in disk i/o is preposterous, not to mention fact three: "it would
be ridiculously slow" (it would be a kind of programmed i/o mode, but
since it's got to be done in real mode anyway, everything is dead).
The o/s can perfectly well ask the disk how big it is without asking
the bios anything. To illustrate, here's a query directed at my disk
from my TP:
% sudo hdparm -I /dev/hda
/dev/hda:
non-removable ATA device, with non-removable media
Model Number: IC25N030ATCS04-0
Serial Number: CSH305DADKY0NB
Firmware Revision: CA3OA71A
Standards:
Used: reserved
Supported: 2 3 4 5
Likely used: 5
Configuration:
Logical max current
cylinders 16383 16383
heads 15 15
sectors/track 63 63
bytes/track: 0 (obsolete)
bytes/sector: 0 (obsolete)
current sector capacity: 15481935
LBA user addressable sectors = 58605120
(the LBA addressing mode is the one that even the bios would be asked
to use by the o/s, if it asked the bios to do anything!)
Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 1768.0kB ECC bytes: 4 Queue depth: 1
Standby timer values: spec'd by Vendor, no device specific
minimum
r/w multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 16512
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
(these are the standard methods of talking to the disk for i/o).
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow
(this is slow "programmed i/o" - the bios is likely to use that, but
since one would have to go to real mode to use the bios, uh, uh, no
way).
control=120ns
Commands/features:
Enabled Supported:
* NOP cmd
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* look-ahead
* write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
SET MAX security extension
Address offset used (large drive)
Power-Up In Standby feature set
* Advanced Power Management feature set
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
34min for SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
%
and I am surprised Peter seems to dispute this fact (but may be I
misunderstand him).
Quite probably. My typing at you seems to be wasted! Please try and
understand - the "overlay" nomenclature probably comes from MSDOS and is
probably either a bios extension (which could only be used by msdos,
since bios is only available in real mode), or a hook of some interrupt
vector (which could again only be used by msdos, since interrupts hooks
are rewritten to pass interrupts to the o/s by anything more recent
than msdos!). Either way, it's simply either "not used" or "not there"
by the time a more modern o/s gets running.
The only chance the extra boot code has to do something is while the
cpu is still in real mode, before the o/s gets going. It could
conceivably diddle the size parameters for the disk kept in the bios.
That's trivial. One ne then have to suppose that the windows o/s,
while still in the "loader" phase, running in real mode, grabs the
bios data and makes it available in some memory location or register
for its later incarnation as a modern o/s running in 386 virtual mode.
But when up and running, the o/s would have no reason not to query the
disk directly as to what it knows abut itself, as I just did! So the
design of windows must be perverse in that respect.
You are completely out of your depth on this one.
The limitation is the number of bits used to count the sectors. EG. 16
bits allows for 65,535 sectors. As hard drives get bigger more bits are
needed, hence the 48 bits needed for drives over 137 gigs.
What the overlay does is to take over the disk I/O with more bits so it
can address larger hard drives. My K6/2/500 system has a bios limitation
of 32 gigs but I had a 120 gig and a 60 gig running in it. I set a link
on one drive and sent a command to the other so the bios would see them
as 32 gigs, then used an overlay on each so that windows could see the
full size.
You are confusing a number of issues. There's a good rundown on this at
http://web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm> with links for
more details.
The only time that the number of bits used to count the sectors was an
issue
was with the 128GB barrier. Prior to that the limit was related to the
cylinders/heads/sectors addressing scheme.
The overlays in general enable logical block addressing on machines whose
BIOS doesn't support it directly. They do _not_ fix the 128 GB limit,
which needs 48-bit support in the host adapter.
My 486/66 had logical block addressing.
|
And? I never had any trouble accessing drives larger than the BIOS
supported on '486 machines under any OS but DOS or consumer Windows.
| Quote: | Any current OS should have no trouble querying the disk directly for its
parameters once it has gotten its own drivers loaded--actually getting it
to that stage is the problem and this had been handled in various ways by
various systems, as until the kernel and disk driver are loaded the
machine is still running on the BIOS boot code.
You may be right, but without an overlay the O/S can't access beyond the
limit set by the bios.
|
When you say "the O/S", what specific operating system are you talking
about? No NT derivative needs an overlay to access the full capacity of a
disk, Novell doesn't, Linux doesn't, BSD doesn't. The general rule is that
the boot code has to be within the first 1024 cylinders--that includes the
loader, the kernel, the disk driver if it's not compiled into the kernel,
and anything else that has to load to get the disks into operation.
As a general rule, overlays should be avoided if at all possible.
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net) |
|
| Back to top |
|
 |
Barry OGrady
Guest
|
| Posted:
Fri Nov 11, 2005 8:26 am Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
On Wed, 9 Nov 2005 12:33:51 +0100, "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
| Quote: | Barry OGrady <atheist.xxx@gmail.com> wrote:
On Mon, 7 Nov 2005 15:46:27 +0100, "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
It's like talking to the wall!
It must be frustrating that some people don't believe you know everything.
It is pretty annoying. The bigger problem is that some people don't
understand that not understanding something means that they don't
understand what is being talked about.
|
I understand.
| Quote: | So, on my AMD K6/500, which has a 32 gig bios limit, all I had to do to
use the full capacity of my 120 gig drive was to set the jumper on the
driver to 32 gigs, and Windows would see the full size?
Windows can see whatever it likes to see - it can talk to the disk as
well as I can, if not better. The point is that the bios is not involved
in disk i/o. To find out how big a disk is, one only has to ask it.
|
And yet Windows seems to be unable to see beyond the bios limit.
| Quote: | bits allows for 65,535 sectors.
Uh, please stop speaking vaguely.
Sorry. I should have written 65,535.0000
That's better.
"Needed" WHERE? Your o/s is the one that talks to your controller,
and your controller is the one that talks to your disk. Note that the
bios is not involved!
What is the cause of the 8, 32 etc limits?
8GB? As far as I recall that was the result of insisting on asking the
bios for a c/h/s estimate of the size of the disk, instead of asking the
disk directly how big it is. The c/h/s nomenclature has field sizes that
make arbirarily large head per cylinder and sector per head (or whatever
the meaningless things are) numbers impossible, and maybe there's a
limit on cylinder numbers too. Thus drives lie and bioses lie using
certain conventions to get across their meaning (git wot I men?) if using
c/h/s to communicate in. This gave rise to several problems. The solution
is "don't do that then", and "just give us the sector count, straight"
(LBA). The ultimate solution is "don't ask the bios, then", and "ask
the disk instead, silly".
|
I understand what LBA is about. My 486/66 had LBA but was still
limited, presumably by the number of bits.
| Quote: | hence the 48 bits needed for drives over 137 gigs.
Sigh. The appropriate commands sent to/by IDE controllers to disks
with more than 137GB do indeed require 48 bits or so in their internal
format. So?
Is that a limitation of the O/S?
?? No. It's not a limitation at all - simply a prerequisite, like using
electricity.
|
How would you overcome a 137 gig limit?
| Quote: | What the overlay does is to take over the disk I/O with more bits so it
Nonsense. Complete balderdash. There is no such thing as "take over
the disk i/o".
Are overlays a con job?
There is no such thing in a modern context. It would make sense only for
msdos. The o/s is your "overlay" in the sense you mean.
|
Interesting. I should be able to use a 40 gig drive in my Latitude CPI running
XP pro without an overlay.
| Quote: | You are confusing a number of issues. There's a good rundown on this at
http://web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm> with links for more
details.
Thank goodness!
The only time that the number of bits used to count the sectors was an issue
was with the 128GB barrier. Prior to that the limit was related to the
cylinders/heads/sectors addressing scheme.
The overlays in general enable logical block addressing on machines whose
BIOS doesn't support it directly. They do _not_ fix the 128 GB limit,
which needs 48-bit support in the host adapter.
LBA alone does not overcome size limits.
LBA means several things. To your bios it means approximately "don't use
c/h/s to talk about the disk size". But that's irrelevant to disk i/o.
It WOULD mean that you could probably get a decent size estimate out of
your bios to about 128GB (random guess).
In the context of disk i/o it DOES mean "linear block addressing", and
simply means what has always been the way of talking to disks, since
msdos went its merry way to the grave.
My 486/66 had LBA.
Then you should have used it.
|
I did, with a 3 gig drive.
| Quote: | Any current OS should have no trouble querying the disk directly for its
parameters once it has gotten its own drivers loaded--actually getting it
to that stage is the problem and this had been handled in various ways by
various systems, as until the kernel and disk driver are loaded the machine
is still running on the BIOS boot code.
Are overlays a con job?
In the sense that you appear to think they exist, and maybe do something,
yes, you have been conned.
|
I'll keep that in mind.
Barry
=====
Home page
http://members.iinet.net.au/~barry.og |
|
| Back to top |
|
|
J. Clarke
Guest
|
| Posted:
Fri Nov 11, 2005 6:18 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
Barry OGrady wrote:
| Quote: | On Wed, 9 Nov 2005 12:33:51 +0100, "Peter T. Breuer" <ptb@oboe.it.uc3m.es
wrote:
Barry OGrady <atheist.xxx@gmail.com> wrote:
On Mon, 7 Nov 2005 15:46:27 +0100, "Peter T. Breuer"
ptb@oboe.it.uc3m.es> wrote:
It's like talking to the wall!
It must be frustrating that some people don't believe you know
everything.
It is pretty annoying. The bigger problem is that some people don't
understand that not understanding something means that they don't
understand what is being talked about.
I understand.
So, on my AMD K6/500, which has a 32 gig bios limit, all I had to do to
use the full capacity of my 120 gig drive was to set the jumper on the
driver to 32 gigs, and Windows would see the full size?
Windows can see whatever it likes to see - it can talk to the disk as
well as I can, if not better. The point is that the bios is not involved
in disk i/o. To find out how big a disk is, one only has to ask it.
And yet Windows seems to be unable to see beyond the bios limit.
bits allows for 65,535 sectors.
Uh, please stop speaking vaguely.
Sorry. I should have written 65,535.0000
That's better.
"Needed" WHERE? Your o/s is the one that talks to your controller,
and your controller is the one that talks to your disk. Note that the
bios is not involved!
What is the cause of the 8, 32 etc limits?
8GB? As far as I recall that was the result of insisting on asking the
bios for a c/h/s estimate of the size of the disk, instead of asking the
disk directly how big it is. The c/h/s nomenclature has field sizes that
make arbirarily large head per cylinder and sector per head (or whatever
the meaningless things are) numbers impossible, and maybe there's a
limit on cylinder numbers too. Thus drives lie and bioses lie using
certain conventions to get across their meaning (git wot I men?) if using
c/h/s to communicate in. This gave rise to several problems. The solution
is "don't do that then", and "just give us the sector count, straight"
(LBA). The ultimate solution is "don't ask the bios, then", and "ask
the disk instead, silly".
I understand what LBA is about. My 486/66 had LBA but was still
limited, presumably by the number of bits.
hence the 48 bits needed for drives over 137 gigs.
Sigh. The appropriate commands sent to/by IDE controllers to disks
with more than 137GB do indeed require 48 bits or so in their internal
format. So?
Is that a limitation of the O/S?
?? No. It's not a limitation at all - simply a prerequisite, like using
electricity.
How would you overcome a 137 gig limit?
What the overlay does is to take over the disk I/O with more bits so
it
Nonsense. Complete balderdash. There is no such thing as "take over
the disk i/o".
Are overlays a con job?
There is no such thing in a modern context. It would make sense only for
msdos. The o/s is your "overlay" in the sense you mean.
Interesting. I should be able to use a 40 gig drive in my Latitude CPI
running XP pro without an overlay.
You are confusing a number of issues. There's a good rundown on this
at <http://web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm> with links
for more details.
Thank goodness!
The only time that the number of bits used to count the sectors was an
issue
was with the 128GB barrier. Prior to that the limit was related to
the cylinders/heads/sectors addressing scheme.
The overlays in general enable logical block addressing on machines
whose
BIOS doesn't support it directly. They do _not_ fix the 128 GB limit,
which needs 48-bit support in the host adapter.
LBA alone does not overcome size limits.
LBA means several things. To your bios it means approximately "don't use
c/h/s to talk about the disk size". But that's irrelevant to disk i/o.
It WOULD mean that you could probably get a decent size estimate out of
your bios to about 128GB (random guess).
In the context of disk i/o it DOES mean "linear block addressing", and
simply means what has always been the way of talking to disks, since
msdos went its merry way to the grave.
My 486/66 had LBA.
Then you should have used it.
I did, with a 3 gig drive.
Any current OS should have no trouble querying the disk directly for
its parameters once it has gotten its own drivers loaded--actually
getting it to that stage is the problem and this had been handled in
various ways by various systems, as until the kernel and disk driver
are loaded the machine is still running on the BIOS boot code.
Are overlays a con job?
In the sense that you appear to think they exist, and maybe do something,
yes, you have been conned.
I'll keep that in mind.
|
Something I think that all the self-proclaimed experts around here ought to
do is take the sophomore or junior level operating systems lab at a
university with a decent computer science department. Once they've
actually written a boot loader they won't be so adamant about how "Windows
can this" and "Windows can that".
The difficulty that the overlook is that Windows doesn't get burned into
firmware and it doesn't load itself by teleportation--it has to be read off
of the disk, and while it is being read off of the disk the machine is
under the control of something other than Windows, specifically it is under
the control of the boot loader built into the firmware on the motherboard,
and that firmware accesses the disk via the BIOS routines and has the
limitatoins of that BIOS. Once the firmware has transferred control to
Windows, _then_ Windows can query the disk for its capacity and respond
accordingly, but until that happens the Windows has no part in the matter.
Linux addresses this issue by having a small boot partition with a copy of
the OS kernel on it, with the necessary drivers built into the kernel.
Novell accomplishes this by using MS-DOS as a second stage boot loader--you
boot DOS, then boot Novell from a folder that has the OS kernel and disk
drivers in it. I'm not sure exactly _what_ Microsoft has done, but they do
seem to have managed to get NT and its descendants to under some
circumstances boot from partitions larger than the BIOS can access--it's my
understanding though that there are limitations on where the kernel and
drivers can be located on that partition--sometimes a defrag can move one
of the files outside of the range that can be accessed using the BIOS
routines and all of a sudden Windows won't boot anymore for no apparent
reason.
Overlays work, but they shouldn't be used until all other options have been
explored, and they should be used with an understanding of how they operate
and what their limitations are and what problems can occur as a result of
their use. For example "fdisk /mbr", a common step in the removal of a
boot-sector virus, usually wipes the overlay and all of a sudden the system
is unusable until the overlay is restored.
Ontrack's latest overlay for Windows does, I am surprised to find, address
the 48-bit issue and support Windows 2K and XP with NTFS (with some
limitations), so they're still working at it--Ontrack's is the one that is
usually bundled with disk drives, but they seldom include the latest
version and it's never full featured.
You might want to google '"Dynamic Disk Overlay" +NTFS' (include the double
quotes, not the single) for more information about this. Also, Ontrack's
page for their latest version is at <http://www.ontrack.com/diskmanager/>.
Note that toward the bottom of the page there is a link to a "tech paper"
that gives the rundown on what the current version can and cannot do.
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net) |
|
| Back to top |
|
|
Peter T. Breuer
Guest
|
| Posted:
Fri Nov 11, 2005 9:13 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
J. Clarke <jclarke.usenet@snet.net.invalid> wrote:
| Quote: | Something I think that all the self-proclaimed experts around here ought to
do is take the sophomore or junior level operating systems lab at a
university with a decent computer science department. Once they've
|
Thank you, but some of us are university professors of computer science,
hardware and software engineering, with twenty years of experience in
writing boot loaders and operating systems, and indeed, hardware, of
various sorts. Not to mention the books on it, not to mention the hundred
odd peer reviewed articles.
| Quote: | actually written a boot loader they won't be so adamant about how "Windows
can this" and "Windows can that".
|
Windows can do whatever it wants to do. That is a given of computing!
| Quote: | The difficulty that the overlook is that Windows doesn't get burned into
firmware and it doesn't load itself by teleportation--it has to be read off
of the disk, and while it is being read off of the disk the machine is
under the control of something other than Windows, specifically it is under
the control of the boot loader built into the firmware on the motherboard,
and that firmware accesses the disk via the BIOS routines and has the
limitatoins of that BIOS. Once the firmware has transferred control to
Windows, _then_ Windows can query the disk for its capacity and respond
accordingly, but until that happens the Windows has no part in the matter.
|
It's hard to answer this without saying "so what"! The bios only needs
access to the bit of the disk it needs to have access to in order to
boot the o/s kernel. After that the kernel takes over. Windows kernel
needs (or needed, up to winnt) to be placed in the first 2GB of the disk
for that to happen, because it actually used signed 32-bit byte offsets
(as far as I recall) in its internal early setup routines. The bios can
always reach that far in any remotely modern system.
| Quote: | Linux addresses this issue by having a small boot partition with a copy of
the OS kernel on it,
|
No it doesn't. I am a linux kernel driver author - I should at least
KNOW. YOU (not linux) CAN address "this [bios] issue" by placing the
o/s kernel in a zone where the bios can boot it, which may well be in a
small boot partition near the front of the disk, whch will confine it
nicely, thanks. Or on a floppy. Anywhere the bios can boot it without
problems, in fact!
That's neither here nor there. The O/P's confusion apparently comes
because he thinks there is some kind of "magic overlay" intervening in
the disk i/o (or he doesn't know what disk i/o means). No. Not. Nix. Nyet.
I hope that is absolutely clear!
He doesn't seem to grok that figuring out how big the disk is an
administrative thing the o/s does while starting up, and has nothing to
do with disk i/o. The o/s is free to ask the disk how big it is, or ask
the bios how big it thinks the disk is, or simply try reading further
and further ahead until it gets an error! Anything will work.
Windows apparently asks the bios and then handicaps itself to the relayed
size. There is no good reason for doing that. It means that one must get
the bios to lie about it if the bios doesn't know. The so-called
"overlay" merely fixes the bios before the o/s boots in order that it
will give the right answer when asked. As soon as the o/s has got a
millisecond or two int bootup, the bios is history. Gone. Inaccessible.
Nada.
| Quote: | with the necessary drivers built into the kernel.
|
Absolutely.
| Quote: | Novell accomplishes this by using MS-DOS as a second stage boot loader--you
|
No, LINUX (or anybody) accomplishes it that way. See freedos. See
loadlin.exe. This is all irrelevant (heh - and your theory doesn't take
into account that according to the OP msdos can't "see" the disk yet).
| Quote: | boot DOS, then boot Novell from a folder that has the OS kernel and disk
drivers in it. I'm not sure exactly _what_ Microsoft has done, but they do
seem to have managed to get NT and its descendants to under some
circumstances boot from partitions larger than the BIOS can access--it's my
|
That's because it's completely irrelevant. The only thing that matters is
the (bios) commands placed in the MBR or in secondary boot sequences
elsewhere. THOSE commands merely have to use an addressing scheme that
can correctly address the next stage in the boot procedure. For linux,
the boot process is generally either two stage (lilo plus kernel) or
three stage (grub plus grub secondary loader plus kernel), but any
sequence can be followed. You can boot it from winnt if you want!
The only important point is that the bios commands placed in the early
stage boot loaders must use an addressing scheme supported by the bios to
load the next stage. That means, if you are using LBA addressing
commands for the BIOS, the next stage can be located anywhere within
2^28 512B sectors of the start of the disk. I.e. 128GB (I think the
sector offset field in those bios commands is 28 bits wide, by memory).
| Quote: | understanding though that there are limitations on where the kernel and
drivers can be located on that partition--sometimes a defrag can move one
|
Thanks, but we understand just fine.
| Quote: | Overlays work, but they shouldn't be used until all other options have been
|
No they don't - they don't exist when the o/s starts running! They can
only work by enhancing (or replacing) the bios, which is only helpful if
you place your kernel is some outlandish position, or by hooking
interrupts in msdos. The bios is HISTORY after the o/s has started
booting, as soon as the cpu leaves real mode.
| Quote: | explored, and they should be used with an understanding of how they operate
and what their limitations are and what problems can occur as a result of
|
Exactly.
| Quote: | their use. For example "fdisk /mbr", a common step in the removal of a
boot-sector virus, usually wipes the overlay and all of a sudden the system
is unusable until the overlay is restored.
|
No - it's usable perfectly fine thanks. The mswindows fdisk /mbr merely
restores a standard MBR.
| Quote: | Ontrack's latest overlay for Windows does, I am surprised to find, address
the 48-bit issue and support Windows 2K and XP with NTFS (with some
limitations), so they're still working at it--Ontrack's is the one that is
|
No "support" is required. You can boot windows from linux if you like!
| Quote: | usually bundled with disk drives, but they seldom include the latest
version and it's never full featured.
You might want to google '"Dynamic Disk Overlay" +NTFS' (include the double
|
It turns up nothing for me! It points to
http://www.sysopt.com/forum/showthread.php?threadid=148235
which is just some silly commercial company promoting its bogusware via a
bogus agony aunt page.
| Quote: | quotes, not the single) for more information about this. Also, Ontrack's
page for their latest version is at <http://www.ontrack.com/diskmanager/>.
Note that toward the bottom of the page there is a link to a "tech paper"
that gives the rundown on what the current version can and cannot do.
|
I'd have to ask if you are employed by ontrack. There is no real
substance in what you are trying to say. To my eyes it looks like
pompous, self-important rubbish.
| Quote: | --John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
|
Peter |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in