Is there any value in INT 0x13, AH=0 when reading with BIOS?

[madanra]

I have the following routine in my bootloader:

Code: Select all

; Input:  lbaPacket.offset and lbaPacket.segment set up
;         edx:eax = LBA address to use
;         cx = number of sectors to read
; Output: Sectors have been read
;         All registers preserved
ReadSectors:
o32 pusha
mov word[lbaPacket.size],0x10
mov word[lbaPacket.sectors],cx
mov dword[lbaPacket.lba_low],eax
mov dword[lbaPacket.lba_high],edx
mov cx,3
.tryRead:
mov ah,0x42
mov dl,[bootData.diskId]
mov si,lbaPacket
int 0x13
jnc .success
mov ah,0
int 0x13
loop .tryRead
mov bp,ReadFail
jmp FatalError
.success:
o32 popa
ret

I know for floppy drives, it is recommended to retry reads, in order to give the drive time to spin up. But I will not be supporting floppies, so that case is not relevant.

I have two questions:

• Is it worth having a naïve retry loop, like in the above code?
• If I do have a retry loop, is there any value in calling int 0x13, ah = 0 inbetween tries?

Which boils down to:

• Do BIOS read operations on non-floppy drives ever fail temporarily?
• When a non-floppy read has failed, does calling int 0x13, ah = 0 have any positive effect on the chances of a future read succeeding?

[madanra]

I realised a good way of answering this question would be to research what existing operating systems do in their MBRs/VBRs, rather than trying to learn yet more about the BIOS calls.

So far I have found:

• Windows 7 MBR retries up to 5 times, with a call to int 0x13, ah = 0 inbetween each try, in a very similar manner to what I had written.
• Windows 7 VBR was a little tricky to decipher, but it looks like it has a retry loop, but the number of retries is set to 1, and it does not call int 0x13, ah = 0.
• GRUB MBR does not retry when reading from a non-floppy drive.

Given these - particularly that GRUB does not retry - I think I would be safe to remove the retry code from my bootloader.

[Brendan]

Hi,

Given these - particularly that GRUB does not retry - I think I would be safe to remove the retry code from my bootloader.

It's easy (or at least easier) to write crappy code that "works" when everything is perfect. It's harder to write code that doesn't fail miserably when various things are less than perfect.

When your software gets a read error; do you want your software to:

• Crash
• Report the error to the user and give up immediately
• Report the error to the user, retry a few times in the hope it might work, then give up if it won't work
• Have built in redundancy (e.g. one or more additional/separate copies of the data that can be used if the first copy can't be read); with a few retries on each copy to maximise the chance of success; with full error reporting so the user is aware if there's problems

Now assume that there are people relying on your OS to get things done. They've got all their work on the computer, they need it to access their banking, they've got family photos and other "sentimental data" on it. Do you really want your boot code to make their entire computer unusable, just because of one "slightly less than perfect" disk sector?


Cheers,

Brendan

[madanra]

Hmm...true. Certainly, when writing a disk driver, you want appropriate retries in. My two initial questions still stand, though, when considering BIOS calls in a bootloader.

[Synon]

How you handle errors depends on your design goals IMO. I wanted my OS to be clean, modern and always supporting the "latest and greatest" standards and hardware. I don't really care about backwards-compatibility and working around old, buggy BIOSes because I don't expect my OS to ever run on real hardware. If the BIOS reports an error after a disk operation, my boot sector prints a ., resets the drive and tries again for a maximum of three attempts. After a third failure it prints the drive status code, so you end up with something like "Loading stage 2 from HDD 80h...OEh".

When your software gets a read error; do you want your software to:

• Crash
• Report the error to the user and give up immediately
• Report the error to the user, retry a few times in the hope it might work, then give up if it won't work
• Have built in redundancy (e.g. one or more additional/separate copies of the data that can be used if the first copy can't be read); with a few retries on each copy to maximise the chance of success; with full error reporting so the user is aware if there's problems

Boot sectors seriously limit the amount of fault tolerance and error reporting you can have. It would be quite difficult to fit redundancy and detailed error reporting into an MBR or VBR.

[madanra]

Boot sectors seriously limit the amount of fault tolerance and error reporting you can have. It would be quite difficult to fit redundancy and detailed error reporting into an MBR or VBR.

They do indeed! I currently have fairly detailed error checking in my ext2 VBR, though the error messages are fairly generic like "Invalid or unsupported ext2 filesystem!". But it took some serious optimising to fit it in the 1024 bytes available. Adding support for ext3/4 would be very tricky! The only fault tolerance is the retry loop that was the topic of this thread.

[Synon]

Boot sectors seriously limit the amount of fault tolerance and error reporting you can have. It would be quite difficult to fit redundancy and detailed error reporting into an MBR or VBR.

They do indeed! I currently have fairly detailed error checking in my ext2 VBR, though the error messages are fairly generic like "Invalid or unsupported ext2 filesystem!". But it took some serious optimising to fit it in the 1024 bytes available. Adding support for ext3/4 would be very tricky! The only fault tolerance is the retry loop that was the topic of this thread.

I didn't bother with anything like file system support in my stage 1. For partitioned media, there's an MBR which relocates itself to 0000:0500 and loads the VBR of the active partition at 0000:7C00. The VBR also relocates to 0000:0500 and it has a DAP with the LBA of stage 2 written at install-time by the installer, so all it does is load stage 2 at 0000:1000 using the values hard-coded into the DAP. On unpartitioned media, I use a different VBR which just loads from the second sector to the end of the first cylinder, giving my second stage (which is always the same) a maximum size of 31 kiB.