| Author |
Message |
Barry OGrady
Guest
|
 Posted:
Mon Nov 07, 2005 5:53 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
On Mon, 7 Nov 2005 12:09:29 +0100, "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
| Quote: | 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.
Barry
=====
Home page
http://members.iinet.net.au/~barry.og |
|
| Back to top |
|
 |
Barry OGrady
Guest
|
| Posted:
Mon Nov 07, 2005 5:55 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
On 7 Nov 2005 01:10:02 -0800, "Danny" <dannyandsherri@gmail.com> wrote:
| Quote: | Sorry I wasn't specific enough and left room for such confusion.
I have desktop witha p2l97 motherboard that refused to recognize a
40gig drive without jumpering it down to 30someting gig. It would be a
shame to go out of my way to purchase a new drive, spent the extra
money for a 60 or 80 gig drive only to find that it ABSOLUTELY cannot
be seen as anything over XX. I was hoping that someone had either
personal experience installing a 30 or 40- or knew of a listing from
Dell or wherever that lists an exact limitation.
|
<raises hand> I put a 40 gig drive in a Latitude CPI using an overlay.
I think the bios limit is 8 gigs.
| Quote: | I have Suse 9.0
installed on my desktop, and unless there is a utility that I am
unaware of I still cannot get back that last 7-8 gig lost to the
jumper. Thanks to all who responded. Danny
|
Barry
=====
Home page
http://members.iinet.net.au/~barry.og |
|
| Back to top |
|
|
Barry OGrady
Guest
|
| Posted:
Mon Nov 07, 2005 6:02 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
On Mon, 7 Nov 2005 10:06:31 +0100, "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
| Quote: | Barry OGrady <atheist.xxx@gmail.com> wrote:
as long as the disk boots, the size seen by the Bios does not matter and
that the OS will be able to use all the usable capacity of the disk,
That is not the case. Unless you use an overlay the bios will limit how much
of the drive the os can see.
The bios does no "limiting" - the bios is not used to talk to the
disk, of course!
|
We may be talking cross purposes here. The bios sets the number of bits used
to address the hard drive thus limiting the size. The overlay overcomes that
limitation. A small amount of code is loaded from the boot sector before the
O/S starts up.
| Quote: | The only feasible mechanism for imposing such a limit would be for the
bios to be interrogated as to the disk size while the o/s kernel is
still in real mode, before it starts up properly and the o/s to
use that value. But once it is running it can ask the IDE controller
directly how big the disk says it is, so there is no reason to believe
the bios value.
|
It still can't address the larger hard drive due to the number of bits limitation.
| Quote: | That's correct - modulo your o/s of course. But indeed, modern o/s's do
not use the bios calls to access the disk. That would be horribly
slow! I dn't think any o/s since dos and windows 3.0 (or whatever) has
even tried to do things that way.
It would be inefficient to use an overlay when not required.
I really don't think you understand what you are talking about.
|
I have used an overlay with a 120 gig drive on a board that was otherwise
limited to 32 gigs.
| Quote: | I've no idea what it would do - is that some windows particular thing
or a piece of bot record code that is run before anything else?
Its code that is stored in the boot record of the hard drive.
Aha - then yes, it would be just added real-mode boot code that
diddles the bios to lie about the disk size when queried. I doubt
it resides fully on the (tiny) mbr, however. But that's by and by.
|
It has to load before the O/S starts up.
| Quote: | One may be able to set a link or send a command to make the drive appear
of lower capacity so it can load the overlay which then replaces the bios for
disk i/o.
The bios does not "load an overlay" in the sense I think you mean - the
bios is not used when talking to the disk. The idea is preposterous.
|
You are probably right. The bios does set the number of bits for disk I/O however.
Barry
=====
Home page
http://members.iinet.net.au/~barry.og |
|
| Back to top |
|
|
Peter T. Breuer
Guest
|
| Posted:
Mon Nov 07, 2005 6:47 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
Barry OGrady <atheist.xxx@gmail.com> wrote:
| Quote: | On Mon, 7 Nov 2005 10:06:31 +0100, "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
Barry OGrady <atheist.xxx@gmail.com> wrote:
as long as the disk boots, the size seen by the Bios does not matter and
that the OS will be able to use all the usable capacity of the disk,
That is not the case. Unless you use an overlay the bios will limit how much
of the drive the os can see.
The bios does no "limiting" - the bios is not used to talk to the
disk, of course!
We may be talking cross purposes here. The bios sets the number of bits used
to address the hard drive thus limiting the size.
|
That's not true. The bios keeps in its lil' head a number that can be
queried with the appropriate bios call. One has to make that bios call
to ask it what that number is (which is darn difficult to do, since
the bios can only be called while the cpu is in ieal mode, and no o/s
since msdos has run in real mode, and going into real mode would require
the whole system state to be saved - just like "hibernation" - and then
brought back afterwards). An o/s would just query the disk directly
instead of going through that!
| Quote: | The overlay overcomes that
limitation. A small amount of code is loaded from the boot sector before the
O/S starts up.
|
And then thrown away, since the o/s does not use the bios and the first
thing any o/s does is hook the interrupt vectors for itself, thanks.
That's what makes an o/s "work". I really think you would do better not
to use the term "overlay"! It smacks of msdos, which is the only
situation in which a bios extension could make sense, and even then,
only until you load a driver that does the job directly. The bios is
only used (as the o/s of last resort) when you don't have an o/s there!
| Quote: | The only feasible mechanism for imposing such a limit would be for the
bios to be interrogated as to the disk size while the o/s kernel is
still in real mode, before it starts up properly and the o/s to
use that value. But once it is running it can ask the IDE controller
directly how big the disk says it is, so there is no reason to believe
the bios value.
It still can't address the larger hard drive due to the number of bits
limitation.
|
This statement unfortunately makes anything you say difficult to take
seriously. Hard drives are addressed by controllers, ide controllers,
whatever. They are talked to by the o/s, along the bus, via dma, etc.
The bios is not involved, cannot be involved, is not available to be
involved, is an ex-concept at that point, etc. If the o/s wants to make
a hard effort to interrogate the bios just once about its idea of the
disk size just befre the o/s properly gets going it can choose to do so,
but it has no reason to do so or to stick with or believe that number in
favor of the number it can get simply and easily by interrogating the
disk controller directly, along the bus, using its ide driver, while it
is running normally. It would be "perverse" to make an o/s that did so.
I'm not saying that windows is not perverse, but that it is, umm,
perverse, to invent difficulties that way!
Out of interest, I've traced the call my o/s makes to get the disk's
size and other info directly out of the disk, and it is
ioctl(3, HDIO_DRIVE_CMD, 0xbffff124) = 0
and looking at the code that implements that ioctl, I see that it's
just a normal command issued along the ide bus, with the address argument
in the call pointing to a struct filled with certain params. I see that
some chipsets are excepted:
if (HWIF(drive)->chipset == ide_pdc4030 && rq->buffer != NULL)
return -ENOSYS; /* special drive cmds not supported */
but for the rest, it's an IDE format command with the fields filled in
the normal way and coming back in the normal way. The bios is not
involved (hic - the idea is preposterous anyway 0).
Peter |
|
| Back to top |
|
|
William P.N. Smith
Guest
|
| Posted:
Mon Nov 07, 2005 7:11 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
"Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
| Quote: | John Doue <notwobe@yahoo.com> wrote:
recognized size limitations due
to bios are a well known problem
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.
|
While that might be true in the Eunuchs World, it's demonstrably not
true in WinDoze. We all get it that the BIOS should be out of the
loop, that the OS should talk directly to the drive, that 32-bit
multitasking operating systems should have no constraints imposed by
the BIOS on disk size, but Bill The AntiChrist doesn't see it your
way.
[Yeah, I know, "Yes, it is", "No it isn't!" Rinse, Lather, Repeat.] |
|
| Back to top |
|
|
J. Clarke
Guest
|
| Posted:
Mon Nov 07, 2005 7:19 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
Barry OGrady wrote:
| Quote: | 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.
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.
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net) |
|
| Back to top |
|
|
John Doue
Guest
|
| Posted:
Mon Nov 07, 2005 8:03 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
William P.N. Smith wrote:
| Quote: | "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
John Doue <notwobe@yahoo.com> wrote:
recognized size limitations due
to bios are a well known problem
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.
While that might be true in the Eunuchs World, it's demonstrably not
true in WinDoze. We all get it that the BIOS should be out of the
loop, that the OS should talk directly to the drive, that 32-bit
multitasking operating systems should have no constraints imposed by
the BIOS on disk size, but Bill The AntiChrist doesn't see it your
way.
[Yeah, I know, "Yes, it is", "No it isn't!" Rinse, Lather, Repeat.]
|
Thanks for this statement. True, all this discussion from Peter and
Barry go over my head and I wish it were not the case; my own "bios"
must play a limiting role here :)!
Still, at the end of the day, it is nice to see acknowledged in clear
language (the one I need, admittedly!) the fact that, even if it should
not, bios are a limiting factor for Windows and that, again, was at the
heart of the matter raised by the OP.
Regards
--
John Doue |
|
| Back to top |
|
|
Peter T. Breuer
Guest
|
| Posted:
Mon Nov 07, 2005 8:46 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
J. Clarke <jclarke.usenet@snet.net.invalid> wrote:
| Quote: | Barry OGrady wrote:
On Mon, 7 Nov 2005 12:09:29 +0100, "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
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.
|
It's like talking to the wall!
| Quote: | The limitation is the number of bits used to count the sectors. EG. 16
|
No it isn't! The IDE controller talks to your disk, not you. Sector
counts up to 2048GB (2^32 512B sectors) or a large number you don't want
to know about (2^64 512B sectors) are part of all o/s's architecture -
the question is what kind of IDE command is sent by the controller - one
with a 28 bit field for the sector offset (if I remember rightly) or one
with a bigger field. Anyway, whatever it sends, it's the format that it
ought to be between controller and disk, and the bios has absoultely
nothing to say about it. The only thing that could have anything to say
is the driver in your o/s. THAT has the job of talking to the
controller, and it had better talk to it good.
| Quote: | bits allows for 65,535 sectors.
|
Uh, please stop speaking vaguely.
| Quote: | As hard drives get bigger more bits are
needed,
|
"Needed" WHERE? Your o/s is the one that talks to yoru controller,
and your controller is the one that talks to your disk. Note that the
bios is not involved!
| 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?
| 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".
Thank goodness!
| Quote: | 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.
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.
|
Amen.
Peter |
|
| Back to top |
|
|
Peter T. Breuer
Guest
|
| Posted:
Mon Nov 07, 2005 9:57 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
William P.N. Smith <news05@compusmiths.com> wrote:
| Quote: | "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
John Doue <notwobe@yahoo.com> wrote:
recognized size limitations due
to bios are a well known problem
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.
While that might be true in the Eunuchs World, it's demonstrably not
true in WinDoze. We all get it that the BIOS should be out of the
|
I deduce that windows, while still in ("dos") cpu real mode at bootup,
asks the bios how big it thinks the disk is, and passes that information
to itself in its 32bit virtualized i386 existence as a multitasking o/s,
and never bothers to actually ask the disk controller directly via its
own ide drivers how big the disk really is. Which is pretty darn
strange!
Which means that if a specially adapted boot record on the disk
fixes anything, that it either fixes the numbers stored in the bios just
prior to control being passed to real mode windows (i.e. dos), or else
it rewrites some of the bios functions so that they report false numbers
when real-mode windows asks the bios via those functions when it boots
up.
That may be the origin of the OP's term "overlay" (you could probably
find the bios call in the real-mode windows startup code and replace
it with some numbers of your choice, but I'm not going to search the
disassembled code). It should be the case that people complain that
windows is driving them batty. This is a dead simple thing to fix.
| Quote: | loop, that the OS should talk directly to the drive, that 32-bit
multitasking operating systems should have no constraints imposed by
the BIOS on disk size, but Bill The AntiChrist doesn't see it your
way.
[Yeah, I know, "Yes, it is", "No it isn't!" Rinse, Lather, Repeat.]
|
Peter |
|
| Back to top |
|
|
Peter T. Breuer
Guest
|
| Posted:
Mon Nov 07, 2005 10:17 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
J. Clarke <jclarke.usenet@snet.net.invalid> wrote:
Actually, it doesn't seem that good to me! It discusses various ways
in which using the bios to access the disk might screw you up, but
since no running modern o/s uses the bios to access the disk, that is
irrelevant (well, there might be some relevance for the pre-o/s bootu
loader code, but I don't recall that windows can boot its first or
second stage from elsewhere than the first 2GB of disk anyway).
| Quote: | The only time that the number of bits used to count the sectors was an issue
was with the 128GB barrier.
|
That's not connected with the bios - that's a question of what format
IDE command to talk to the controller with from the driver, and how
the controller talks to the disk.
| Quote: | Prior to that the limit was related to the
cylinders/heads/sectors addressing scheme.
|
Yep, but nobody nowadays uses c/h/s addressing anywhere, not even when
making bios calls in a boot loader! Linear addressing is unversally
used since about 1997.
| Quote: | The overlays in general enable logical block addressing on machines whose
BIOS doesn't support it directly.
|
Via bios calls. But nobody uses bios calls.
| Quote: | They do _not_ fix the 128 GB limit,
which needs 48-bit support in the host adapter.
|
Indeed.
| 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
|
Exactly so.
| Quote: | various systems, as until the kernel and disk driver are loaded the machine
is still running on the BIOS boot code.
|
Perhaps the simplest explanation is to be found at the end of the
document you quoted (and which I lambasted):
LBA works with a 64-bit sector address, so we can (theoretically)
access the staggering amount of 8,796,093,022,208 GB! Due to
limitations of the ATA interface, only the lower 28 bits of the LBA
address can used by an EIDE drive resulting in a, still formidable,
limit of 128 GB.
So without doing anything about the way it talks to the controller,
your o/s can address 128GB of disk just as it always has. Bios is not
involved.
Windows 95/98 is ready for this because it already uses LBA
internally.
Even win 95/98 could "already" do so.
Except in Safe or Compatibility Mode, the protected mode diskdriver
takes over the BIOS Int 13h interface and can access a drive
directly in LBA.
Notice that it says that out of real mode, once the o/s is up and
running, bios is waved goodbye to by being smashed off the face of the
planet. But nobody even does that kind of programmed i/o nowadays. And
hasn't for years. When was that doc written?
Peter |
|
| Back to top |
|
|
Jerry Bloomfield
Guest
|
| Posted:
Tue Nov 08, 2005 3:56 am Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
On Mon, 07 Nov 2005 22:55:23 +1100, Barry OGrady
<atheist.xxx@gmail.com> wrote:
| Quote: | On 7 Nov 2005 01:10:02 -0800, "Danny" <dannyandsherri@gmail.com> wrote:
raises hand> I put a 40 gig drive in a Latitude CPI using an overlay.
I think the bios limit is 8 gigs.
|
As I mentioned in my previous post, I used a 60Gb drive, without any
overlay software, and using the latest BIOS for my CPi, it worked
fine. BIOS saw it all, as well as Windows.
I don't have access to a working CPi to test it with a larger drive
now, so I can't say if any larger will work, but it's a safe bet
that it will, since it accepted a 60GB drive.
To get the OP's system to work without the overlay, they may need to
perform a BIOS update, similarly for yours. |
|
| Back to top |
|
|
Barry OGrady
Guest
|
| Posted:
Wed Nov 09, 2005 9:18 am Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
On Mon, 07 Nov 2005 08:19:22 -0500, "J. Clarke" <jclarke.usenet@snet.net.invalid> wrote:
| Quote: | 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.
| 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.
| Quote: | Peter
Barry
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
|
Barry
=====
Home page
http://members.iinet.net.au/~barry.og |
|
| Back to top |
|
|
Barry OGrady
Guest
|
| Posted:
Wed Nov 09, 2005 9:18 am Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
On Mon, 7 Nov 2005 15:46:27 +0100, "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote:
| Quote: | 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:
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.
It's like talking to the wall!
|
It must be frustrating that some people don't believe you know everything.
| Quote: | The limitation is the number of bits used to count the sectors. EG. 16
No it isn't! The IDE controller talks to your disk, not you. Sector
counts up to 2048GB (2^32 512B sectors) or a large number you don't want
to know about (2^64 512B sectors) are part of all o/s's architecture -
the question is what kind of IDE command is sent by the controller - one
with a 28 bit field for the sector offset (if I remember rightly) or one
with a bigger field. Anyway, whatever it sends, it's the format that it
ought to be between controller and disk, and the bios has absoultely
nothing to say about it. The only thing that could have anything to say
is the driver in your o/s. THAT has the job of talking to the
controller, and it had better talk to it good.
|
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?
| Quote: | bits allows for 65,535 sectors.
Uh, please stop speaking vaguely.
|
Sorry. I should have written 65,535.0000
| Quote: | As hard drives get bigger more bits are
needed,
"Needed" WHERE? Your o/s is the one that talks to yoru 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?
| 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?
| 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?
| 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.
My 486/66 had LBA.
| 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?
Barry
=====
Home page
http://members.iinet.net.au/~barry.og |
|
| Back to top |
|
|
Peter T. Breuer
Guest
|
| Posted:
Wed Nov 09, 2005 5:33 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
Barry OGrady <atheist.xxx@gmail.com> wrote:
| Quote: | 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.
| 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.
| Quote: | bits allows for 65,535 sectors.
Uh, please stop speaking vaguely.
Sorry. I should have written 65,535.0000
|
That's better.
| Quote: | "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".
| 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.
| 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.
| 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.
| Quote: | My 486/66 had LBA.
|
Then you should have used it.
| 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.
Peter |
|
| Back to top |
|
|
Peter T. Breuer
Guest
|
| Posted:
Wed Nov 09, 2005 5:36 pm Post subject:
Re: maximum hard drive size in Latitude cpi |
|
|
Barry OGrady <atheist.xxx@gmail.com> wrote:
| Quote: | 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.
|
Nonsense. Try looking around at the number of operating systems running
huge disks with no such thing as your precisous "overlay".
You've had it explained to you. Persistence in repeating your
statements in the face of all the explanations isn't intelligent.
Peter |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in