grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/2] disk: use maximum number of sectors for LBA


From: Glenn Washburn
Subject: Re: [PATCH 0/2] disk: use maximum number of sectors for LBA
Date: Fri, 6 Oct 2023 13:33:51 -0500

On Fri, 6 Oct 2023 19:24:11 +0300
ValdikSS <iam@valdikss.org.ru> wrote:

> On 05.10.2023 22:09, Glenn Washburn wrote:
> >> GRUB2 limits number of sectors read at once in LBA mode to the
> >> number reported in CHS disk geometry by BIOS.
> >> This is unnecessary, as IBM/MS INT13 Extensions allows reading
> >> up to 127 sectors in a single call.
> > 
> > Please provide more documentation for this. Wikipedia[1] suggests that
> > IBM/MS INT13 Extensions allows reading up to 64K sectors in a single
> > call. But that "some Phoenix BIOSes are limited to a maximum of 127
> > sectors". So the above seems misleading.
> 
> Rephrased as "upper safe value for LBA read". Check v2.
> 
> >>
> >> This fixes greatly increased boot times on WYSE C10LE x86 thin
> >> client with Phoenix bios.
> >>
> >> See: https://lists.gnu.org/archive/html/grub-devel/2023-07/msg00001.html
> > 
> > First, this seems risky to me to be added for the release.  Why do we
> > believe that some other bios doesn't have a limit less than 127?
> 
> I've checked Wikipedia and OSDev, as well as Russian forum (don't 
> remember which), and tested on two of my old machines with Phoenix and 
> Award BIOS.

My concern isn't with Phoenix but testing for other BIOS manufacturers.
However...

> 
> syslinux also limits to 127 if EBIOS is detected:
> 
>          hard_max_transfer = 63;
>          ...
>          if (!(oreg.eflags.l & EFLAGS_CF) &&
>              oreg.ebx.w[0] == 0xaa55 && (oreg.ecx.b[0] & 1)) {
>              ebios = true;
>              hard_max_transfer = 127;
> 
> https://github.com/geneC/syslinux/blob/5e426532210bb830d2d7426eb8d8c154d9dfcba6/core/fs/diskio_bios.c#L349
> 
> That's why I assume it should be safe to enable.

This gives me more confidence in using 127, although its not clear to
me without digging in the syslinux code that 127 is actually being
used as the transfer size (or when it is). It appears to be a hard max
transfer, which means the actual transfer size could be lower. In this
series, we're using 127 as the transfer size always. So questions that
would help clear that up are: where does MaxTransfer ultimately come
from and when can it be less than 127? How is disk.maxtransfer used and
when does it not represent the actual transfer size.

> 
> > 
> > Also, based on reading the email in the link above, am I correct in
> > concluding that your bios set the CHS values returned in
> > grub_biosdisk_rw_int13_extensions() from the values in the MBR?
> 
> Yes, this is correct.

Ok, this lends more weight to not taking those values too seriously
then. Do you have an explanation of how you got an MBR with sectors ==
2? I would have a hard time believing that debian would produce that.

> 
> > 
> > Glenn
> > 
> > [1]
> > https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH=42h:_Extended_Read_Sectors_From_Drive



reply via email to

[Prev in Thread] Current Thread [Next in Thread]