On Wed, Oct 04, 2023 at 00:43:18 +, Lidong Chen wrote:
> - if (filename + direntry->len - 1 > (char *) tail)
> + if (filename + direntry->len + 1 > (char *) end)
> return grub_error (GRUB_ERR_BAD_FS, "invalid XFS directory entry");
>
> There were these lines in the source after the diff:
>
>
On 06.10.2023 23:49, Vladimir 'phcoder' Serbinenko wrote:
Is Windows XP slow as well?
(windows first-stage bootloader is really tiny and these 1-sector reads
don't feel slow compared to 2-sector reading of 4.5MB Linux kernel by GRUB).
OpenPGP_signature
Description: OpenPGP digital signature
_
On 06.10.2023 23:49, Vladimir 'phcoder' Serbinenko wrote:
Is Windows XP slow as well?
Nope, it's fast. The slowness is fixed by the first patch (1/2), without
which GRUB reads by only 2 sectors at once. With the patch, GRUB reads
up to 63 sectors.
The second patch only increases 63 to 127,
On Fri, 6 Oct 2023 23:27:34 +0300
ValdikSS wrote:
> On 06.10.2023 21:33, Glenn Washburn wrote:
> > 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
Le ven. 6 oct. 2023, 19:13, ValdikSS via Grub-devel a
écrit :
> Increase the value from 63 to speed up reading process.
>
> This commit increases two limits: the low-level int 13h reading code
> and a high-level reading code with disk cache.
>
These are 2 independent changes and need to be discu
Is Windows XP slow as well?
We should avoid doing anything with firmware API that windows doesn't as
manufacturers use it as sole compatibility test and it's not unusual for
them to just not care about other OS. Like when they shipped bunch of
computers with ACPI code that is basically
if (_OSI("Li
On 06.10.2023 21:21, Glenn Washburn wrote:
Commit messages should not use links to downstream projects. The commit
hash referred to in that link does not exist in GRUB master. Here's a
more appropriate link:
https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/disk/i386/pc/biosdisk.c?h=grub
On 06.10.2023 21:33, Glenn Washburn wrote:
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
On 06.10.2023 21:34, ValdikSS wrote:
What can change my mind:
1) Proof that windows does such calls
Windows XP **bootloader** uses single-sector reads with int 13h to read
the kernel (just checked with qemu). But the kernel seem to use direct
IDE controller method reading.
I was checking i
On 05.10.2023 20:53, Vladimir 'phcoder' Serbinenko wrote:
This has a very high risk of breaking existing configs. "Specification
allows" doesn't mean that real-world BIOSes actually react well to it.
Some BIOS may read just reads 63 instead of 127 sectors and we end up
with garbage in this case
On Fri, 6 Oct 2023 19:24:11 +0300
ValdikSS 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
This reverts commit 7aab03418ec6a9b991aa44416cb2585aff4e
7972.
Original commit is
wrong because grub_file_get_device_na
me can
return NULL if we use implicit $root.
grub_errno is guaranteed to be 0 at the beginning of a command
Signed-o
On Fri, 6 Oct 2023 20:10:13 +0300
ValdikSS via Grub-devel wrote:
> Increase the value from 63 to speed up reading process.
>
> This commit increases two limits: the low-level int 13h reading code
> and a high-level reading code with disk cache.
> The disk cache imposes an overall limitation of
On 05.10.2023 19:57, Daniel Kiper wrote:
On Fri, Jul 07, 2023 at 12:33:32AM +0300, ValdikSS via Grub-devel wrote:
The code used to flush the cache on VIA processors unconditionally,
which is excessive.
Check for cpuid family and execute wbinvd only on C3 and earlier.
See: https://savannah.gnu.o
The code used to flush the cache on VIA processors unconditionally,
which is excessive.
Check for cpuid family and execute wbinvd only on C3 and earlier.
Fixes: https://savannah.gnu.org/bugs/?45149
Fixes: commit 25492a0f047cb7a6583ae195568599c296a604d6
Signed-off-by: ValdikSS
Reviewed-by: Daniel
Increase the value from 63 to speed up reading process.
This commit increases two limits: the low-level int 13h reading code
and a high-level reading code with disk cache.
The disk cache imposes an overall limitation of a higher-layer reading
code. The original comment regarding 16K is incorrect,
Current code impose limitations on the amount of sectors read
in a single call according to CHS layout of the disk, even in LBA
read mode.
There's no need to obey CHS layout restrictions for LBA reads
on LBA disks, it only slows down booting process.
See:
https://lore.kernel.org/grub-devel/d42a1
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 does not have
such limit and it is safe to read up to 127 sectors in a single call.
This fixes greatly increased boot times on WYSE C10LE x86
On 05.10.2023 22:11, Glenn Washburn wrote:
According to Wikipedia and various sources, the recommended
value for LBA read using IBM/MS INT13 Extensions is 127 sectors.
Please cite references. I'm not seeing that on Wikipedia or osdev.org.
I do see where Wikipedia says that some Phoenix bioses a
On 05.10.2023 22:10, Glenn Washburn wrote:
--- a/include/grub/disk.h
+++ b/include/grub/disk.h
@@ -190,6 +190,9 @@ typedef struct grub_disk_memberlist *grub_disk_memberlist_t;
#define GRUB_DISK_MAX_MAX_AGGLOMERATE ((1 << (30 - GRUB_DISK_CACHE_BITS - GRUB_DISK_SECTOR_BITS)) - 1)
+/* Maximu
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.
On Thu, 14 Sep 2023 15:08:00 -0500
Glenn Washburn wrote:
> On Thu, 14 Sep 2023 17:37:10 +0200
> "Vladimir 'phcoder' Serbinenko" wrote:
>
> > Le lun. 14 août 2023, 20:58, Glenn Washburn a
> > écrit :
> >
> > > Currently when given a path to a file, ls will open the file to determine
> > > if i
22 matches
Mail list logo
