[ros-diffs] [cwittich] 25064: fix ks.rbuild
cwittich at svn.reactos.org
cwittich at svn.reactos.org
Mon Dec 4 17:34:27 CET 2006
- Previous message: [ros-diffs] [mist] 25063: ReactOS Intel Mac compatibility commits, part 2/2 == LBA Functionality BIOS Bug == When the BIOS is asked whether it supports INT 13 extensions, it will answer yes if the device is a hard disk, but it will pretend that even the function to ask about this functionality is unsupported if asked about a CD drive. This is similar to what is documented in the code already: Some BIOSes return "doesn't support INT 13 extensions" for CDs. Code has been added to use INT 13 extensions (and therefore LBA read as opposed to CHS) even if the BIOS claims this is unsupported, if the device is a CD-ROM. The check for the drive type is done by comparing with 0x90: If the device number is 0x90 or above, it's a CD drive. (On Insyde's BIOS, it's 0x90, on most others, it's 0x9F). (Ironically, Insyde's BIOS cannot even do CHS on CDs, so if the bootloader correctly asks for LBA support, it will get a "no" and will fail when trying to do CHS: When querying the max. CHS values, the BIOS returns 0 sectors per track, which will make conversions from LBA to CHS impossible.) == LBA Read BIOS Bug == When trying to read from CD using the LBA function INT 13/42, the BIOS function will return as it is supposed to, with CF and AH cleared, but with an unchanged buffer. This is because freeldr passes a "disk address packets" that structure contains an extra 64 bit value at the end and is therefore 24 bytes long instead of 16. This is perfectly fine, and a BIOS should ignore any extra data in the structure, but Insyde's BIOS, which doesn't support the extra field (and thus the EDD-3.0 standard) just ignores the complete task and returns in this case. The extra field has been removed from the structure in freeldr, as it is not used anyway. The structure is now 16 bytes long.
- Next message: [ros-diffs] [cwittich] 25065: -revert janderwalds change until because it breaks the gcc 4.x build
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Author: cwittich
Date: Mon Dec 4 19:34:26 2006
New Revision: 25064
URL: http://svn.reactos.org/svn/reactos?rev=25064&view=rev
Log:
fix ks.rbuild
Modified:
trunk/reactos/drivers/multimedia/ks/ks.rbuild (contents, props changed)
Modified: trunk/reactos/drivers/multimedia/ks/ks.rbuild
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/multimedia/ks/ks.rbuild?rev=25064&r1=25063&r2=25064&view=diff
==============================================================================
--- trunk/reactos/drivers/multimedia/ks/ks.rbuild (original)
+++ trunk/reactos/drivers/multimedia/ks/ks.rbuild Mon Dec 4 19:34:26 2006
@@ -1,4 +1,4 @@
-<module name="ks" type="exportdriver" installbase="system32/drivers" installname="ks.sys" warnings="true">
+<module name="ks" type="exportdriver" installbase="system32/drivers" installname="ks.sys" allowwarnings="true">
<include base="ks">.</include>
<include base="ks">..</include>
<include base="ks">../include</include>
Propchange: trunk/reactos/drivers/multimedia/ks/ks.rbuild
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: trunk/reactos/drivers/multimedia/ks/ks.rbuild
------------------------------------------------------------------------------
--- svn:executable (original)
+++ svn:executable (removed)
@@ -1,1 +1,0 @@
-*
- Previous message: [ros-diffs] [mist] 25063: ReactOS Intel Mac compatibility commits, part 2/2 == LBA Functionality BIOS Bug == When the BIOS is asked whether it supports INT 13 extensions, it will answer yes if the device is a hard disk, but it will pretend that even the function to ask about this functionality is unsupported if asked about a CD drive. This is similar to what is documented in the code already: Some BIOSes return "doesn't support INT 13 extensions" for CDs. Code has been added to use INT 13 extensions (and therefore LBA read as opposed to CHS) even if the BIOS claims this is unsupported, if the device is a CD-ROM. The check for the drive type is done by comparing with 0x90: If the device number is 0x90 or above, it's a CD drive. (On Insyde's BIOS, it's 0x90, on most others, it's 0x9F). (Ironically, Insyde's BIOS cannot even do CHS on CDs, so if the bootloader correctly asks for LBA support, it will get a "no" and will fail when trying to do CHS: When querying the max. CHS values, the BIOS returns 0 sectors per track, which will make conversions from LBA to CHS impossible.) == LBA Read BIOS Bug == When trying to read from CD using the LBA function INT 13/42, the BIOS function will return as it is supposed to, with CF and AH cleared, but with an unchanged buffer. This is because freeldr passes a "disk address packets" that structure contains an extra 64 bit value at the end and is therefore 24 bytes long instead of 16. This is perfectly fine, and a BIOS should ignore any extra data in the structure, but Insyde's BIOS, which doesn't support the extra field (and thus the EDD-3.0 standard) just ignores the complete task and returns in this case. The extra field has been removed from the structure in freeldr, as it is not used anyway. The structure is now 16 bytes long.
- Next message: [ros-diffs] [cwittich] 25065: -revert janderwalds change until because it breaks the gcc 4.x build
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Ros-diffs
mailing list