s, CHR reading is used if MBR has failed.
P.S. please include my email when you send me the messages, I saw this
maillist-only post only by pure coincidence.
Le mar. 10 oct. 2023, 21:30, ValdikSS via Grub-devel <mailto:grub-devel@gnu.org>> a écrit :
Increase the value from
Daniel, just FYI, I can't send emails to your email server. It was the
issue back then and it is still now. There's no web site on this domain
and no contact information in whois.
: host dibed.net-space.pl[84.10.22.86] said: 553 5.7.1
Hello [185.177.150.13], for your MAIL FROM address
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,
On 10.10.2023 14:34, Daniel Kiper wrote:
ValdikSS, Vladimir and I agreed we will take patch #1 into the release.
The patch #2 will be merged after the release. Though please update both
patches and post v3 now.
Thank you for debugging and fixing this issue!
Daniel
Done, check v3.
OpenPGP_si
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 06.10.2023 23:54, Vladimir 'phcoder' Serbinenko wrote:
Le ven. 6 oct. 2023, 19:13, ValdikSS via Grub-devel <mailto:grub-devel@gnu.org>> a écrit :
Increase the value from 63 to speed up reading process.
This commit increases two limits: the low-level int 13h rea
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 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 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
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.
According to Wikipedia and various sources, the recommended
value for LBA read using IBM/MS INT13 Extensions is 127 sectors.
---
include/grub/disk.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/grub/disk.h b/include/grub/disk.h
index be032a72c..608deb034 100644
There's no need to obey CHS layout restrictions for LBA reads
on LBA disks, it only slows down booting process.
See: https://lists.gnu.org/archive/html/grub-devel/2023-07/msg1.html
---
grub-core/disk/i386/pc/biosdisk.c | 5 -
include/grub/disk.h | 3 +++
2 files changed, 7 i
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.
This fixes greatly increased boot times on WYSE C10LE x86 thin
client with Phoenix bios.
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.org/bugs/?45149
See: commit 25492a0f047cb7a6583ae195568599c296a604d6
---
grub-core/kern/i386/pc/init.c | 11 +
The code used to flush the cache on VIA processors unconditionally,
which is excessive.
Check for cpuid family and execute wbinvd only on C7 and earlier.
See: https://savannah.gnu.org/bugs/?45149
See: commit 25492a0f047cb7a6583ae195568599c296a604d6
---
grub-core/kern/i386/pc/init.c | 11 +
Hello list,
I noticed that GRUB 2.06 menu and Linux kernel and initrd load times are
greatly influenced by the "last sector" data in the first partition
entry (byte 0x06 in MBR partition entry, offset 0x1c4 from the beginning
of the disk for the first partition) on my WYSE C10LE x86 thin clien
28 matches
Mail list logo
