Christophe Fergeau
2009-Apr-30 13:38 UTC
[syslinux] [1/1] [gfxboot] align buffer used to read data from disk to a 512 byte boundary
The COM API provides a function to read from disk (int 22h, AX=07h) which needs a destination buffer aligned on a 512 byte boundary. gfxboot uses this function but doesn't ensure its data buffer is properly aligned. This leads to failures on a few machines (HP Pavillion dv5): gfxboot: isolinux: Disk error 09, AX = 424F, drive FE https://qa.mandriva.com/show_bug.cgi?id=48814 has a bit more details. This patch just makes sure the buffer used to read from disk is properly aligned, this fixes the boot failures on the aforementioned machines. Signed-off-by: Christophe Fergeau <cfergeau at mandriva.com> --- modules/gfxboot.asm | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/modules/gfxboot.asm b/modules/gfxboot.asm index e3aed13..2c3f809 100644 --- a/modules/gfxboot.asm +++ b/modules/gfxboot.asm @@ -871,6 +871,8 @@ drivenumber db 0 sectorshift db 0 sectorsize dw 0 trackbufsize equ 16384 +align 512 ; must be 512 byte aligned because it will be passed + ; to int 22h, AX=07h trackbuf times trackbufsize db 0 BufSafe dw 0 file_length dd 0 -- 1.6.2.4
H. Peter Anvin
2009-Apr-30 14:45 UTC
[syslinux] [1/1] [gfxboot] align buffer used to read data from disk to a 512 byte boundary
Christophe Fergeau wrote:> The COM API provides a function to read from disk (int 22h, AX=07h) > which needs a destination buffer aligned on a 512 byte boundary. gfxboot > uses this function but doesn't ensure its data buffer is properly > aligned. This leads to failures on a few machines (HP Pavillion dv5): > > gfxboot: > isolinux: Disk error 09, AX = 424F, drive FE > > https://qa.mandriva.com/show_bug.cgi?id=48814 has a bit more details. > This patch just makes sure the buffer used to read from disk is properly > aligned, this fixes the boot failures on the aforementioned machines.The data segment isn't directly aligned, so this won't work. Furthermore, there is no reason for this stuff to be in the .data segment; I was rather shocked to find out that 90% of gfxboot.com is empty space caused by putting temporary buffers in the .data segment. This patch handles the alignment, and also moves as many all-zero-initialized variables as I felt safe to into the .bss section. I have not tested this at all, so I have no idea if I clobbered anything important. This patch should be reviewed by someone who knows what the heck the code is doing... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -------------- next part -------------- A non-text attachment was scrubbed... Name: gfxboot.patch Type: text/x-patch Size: 3671 bytes Desc: not available URL: <http://www.zytor.com/pipermail/syslinux/attachments/20090430/543578ca/attachment.bin>
H. Peter Anvin
2009-Apr-30 14:55 UTC
[syslinux] [1/1] [gfxboot] align buffer used to read data from disk to a 512 byte boundary
[Apologies for the resend] Christophe Fergeau wrote:> The COM API provides a function to read from disk (int 22h, AX=07h) > which needs a destination buffer aligned on a 512 byte boundary. gfxboot > uses this function but doesn't ensure its data buffer is properly > aligned. This leads to failures on a few machines (HP Pavillion dv5): > > gfxboot: > isolinux: Disk error 09, AX = 424F, drive FE > > https://qa.mandriva.com/show_bug.cgi?id=48814 has a bit more details. > This patch just makes sure the buffer used to read from disk is properly > aligned, this fixes the boot failures on the aforementioned machines.The data segment isn't directly aligned, so this won't work. Furthermore, there is no reason for this stuff to be in the .data segment; I was rather shocked to find out that 90% of gfxboot.com is empty space caused by putting temporary buffers in the .data segment. This patch handles the alignment, and also moves as many all-zero-initialized variables as I felt safe to into the .bss section. I have not tested this at all, so I have no idea if I clobbered anything important. This patch should be reviewed by someone who knows what the heck the code is doing... Note also the resulting difference in size of gfxboot.com. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -------------- next part -------------- A non-text attachment was scrubbed... Name: gfxboot.patch Type: text/x-patch Size: 3672 bytes Desc: not available URL: <http://www.zytor.com/pipermail/syslinux/attachments/20090430/7de96456/attachment.bin>