[svlug] 137GB HD limit?
Bryan K. Watson
bwatson at nettracers.com
Wed Jul 23 01:35:39 PDT 2003
So what you are saying is that linux does NOT even look at bios
initially to determine info for the drive? (I am really asking, not
arguing with that question.)
You did find an interesting bit of code. How about modifying it to
force the required bits? I am not a coder...just a sysadmin/network
if (drive->addressing == 1) /* 48-bit LBA */
return lba_48_rw_disk(drive, rq, (unsigned long long)
I'll run this by someone who may know more.....any ideas dd?
On Tue, 2003-07-22 at 17:52, Rafael Skodlar wrote:
> On Tue, Jul 22, 2003 at 04:38:41PM -0700, Erik Steffl wrote:
> > Bill Kendrick wrote:
> > >On Tue, Jul 22, 2003 at 07:37:11AM -0700, Bryan K. Watson wrote:
> > >
> > >>On Tue, 2003-07-22 at 01:53, Erik Steffl wrote:
> > >>
> > >>> Is there a 137GB HD limit in linux kernel? It looks like I can only
> > >>>access about that much of 250GB SATA (Serial ATA drive).
> > >>
> > >>Probably a BIOS limitation. Many (even current) BIOS don't support that
> > >>large of an HD. This applies to any OS that you use on it. It has to
> > >>do with the number of bits allocated to address the drive. 2^28*512.
> > >
> > >
> > >That was my thought at first, too. I had to run some BIOS-flashing
> > >software on my
> > >PC to get my 120GB drive to work, when I bought it. (The BIOS software
> > >from my
> > >motherboard manufacturer was MSDOS-based, so I had to make a DOS boot
> > >floppy and
> > >run it from there. I think I used 'FreeDOS' or some-such.)
> > >
> > >
> > >OTOH, though, I believe Erik said the drive works fine under Windows.
> > >My assumption was that he's dual-booting, and therefore the BIOS is fine
> > >(since Windows can see all 137GB).
> > >
> > >
> > >Indeed, though, it could have been under Windows on an entirely different
> > >box
> > >(one whose BIOS doesn't have the 137GB limit). Or, perhaps Windows itself
> > >might
> > >have some way of getting around the BIOS limitation. (I obviously don't
> > >use
> > >or know much about Windows, personally :^) )
> > I had to get SP1 for win xp (without SP1 it showed it as 137GB drive,
> > with SP1 it shows it as 250GB, I can format it etc.). It's the same box
> > (dual boot). Bios shows it as 250GB in setup, not sure if that means
> > anything...
> > Linux show it as 250GB (cfdisk, mkfs, badblocks etc. all recognize it
> > as 250GB disk), it's just that reading only goes up to 137GB, the other
> > half is unreadable...
> > BTW since linux doesn't use BIOS for disk reads what would BIOS not
> > supporting disks over 137GB mean? I had a disk that was too big for BIOS
> > before and while I couldn't boot off of it it worked fine in linux. I
> > just disabled the disk in BIOS (otherwise BIOS would freeze). [that was
> > back in the days when 40GB was too much:-) IIRC the limit was 37GB and
> > large disk howto was still usable... those were the days...]
> > I guess it's SATA driver, but I can't find any details...
> BIOS has noting to do with this issue IMO. At least not in the
> later stage after you bootup.
> Have yout tried to split the drive into two partitions and see if that
> makes it usable?
> You might need to go deep into the source code to solve the problem
> There is interesting piece of code:
> * 268435455 == 137439 MB or 28bit limit
> * need to add split taskfile operations based on 28bit
> if (drive->addressing == 1) /* 48-bit LBA */
> return lba_48_rw_disk(drive, rq, (unsigned long long)
> if (drive->select.b.lba) /* 28-bit LBA */
> return lba_28_rw_disk(drive, rq, (unsigned long) block);
> /* 28-bit CHS : DIE DIE DIE piece of legacy crap!!! */
> return chs_rw_disk(drive, rq, (unsigned long) block);
> that's from linux-2.4.21
> Other option is to try SCSI. Check CONFIG_BLK_DEV_IDESCSI in kernel
> config file if that can help you.
> > erik
> A nice problem you have
More information about the svlug