Bochs error in ATA device: out of bounds

[Creature]

Lately I keep stumbling upon the same ATA error:

Code: Select all

00015145707e[HD   ] calc_log_addr: out of bounds (0/20160)
00015145707e[HD   ] ide_read_sector() reached invalid sector 0, aborting

It occurs only when I try to read/write in LBA28 (PIO) mode. When I use CHS, everything works like a charm. I've looked through my code over and over, but can't seem to find anything that's wrong. A quick glance at the Bochs code indicates that it calculates logical_sector (which is 0, as I'm trying to read LBA 0, I also tried calculating the address myself) and then compares it with the size of the drive (maximum LBA). The values printed by the error (calc_log_addr) are as seen above: 0/20160. The Bochs source does the following (found here):

Code: Select all

if (logical_sector >= sector_count) {
    BX_ERROR (("calc_log_addr: out of bounds (%d/%d)", (Bit32u)logical_sector, sector_count));

Where logical_sector is a 64-bit signed integer and sector_count a 32-bit unsigned integer. The values printed are correct, but how can 0 >= 20160? The most reasonable explanation to me would be some kind of wrong signed/unsigned cast, but shouldn't a 64-bit signed value 1 be casted to a 32-bit unsigned value of 0 as well? Seeing as the Bochs code being faulty is rare, I've come to the conclusion that my code probably is faulty (I'm following the ATA/IDE page on the wiki), but I can't seem to figure out what's wrong. All my ATA code can be found in my SVN repository.

Has anyone had any similar issues? Any idea how to solve them? Sorry if my post sounds a bit hasty, I'm pretty tired (mostly of trying to figure out what's wrong).

PS: The wiki page switches selectors all the time, is this really necessary (or only when one needs to read/write from e.g. usermode, should one then switch to the usermode segment)?

Thanks in advance,
Creature

[bewing]

This is much more likely to be a bug in your compiler, than either a bug in your code or in the bochs source.
What compiler did you use to compile bochs with? It is simply the case that 0 can never be >= 20160 unless the 20160 value is being cast into a 16bit signed variable.

And that is very odd that bochs is using a 32bit sector count. I'll have to look at that. It shouldn't be, I don't think.
But you may want to try simply adding a couple of correctly-sized variables to that bochs function, copy the values of those two variables into your variables, and do the test on your variables -- recompile bochs, and see what happens.

That "ATA/IDE" page is a bunch of crap, BTW. Pay a lot more attention to the http://wiki.osdev.org/ATA_PIO_Mode article instead. It is much more accurate.

[NickJohnson]

I think he means switching segment selectors: I assume that is only relevant if you have user segments with different bases and probably has little or nothing to do with the ATA driver either way.

[bewing]

Well, I'm sticking to my original guess. I will bet that it's a compiler bug.

The fact that bochs is doing that 32bit calculation for the disk size is a bug in bochs. It should be using BX_SELECTED_DRIVE(channel).hard_drive->hd_size, instead. But that should not affect the calculation you are seeing.

[Creature]

This is much more likely to be a bug in your compiler, than either a bug in your code or in the bochs source.
What compiler did you use to compile bochs with?

I'm using the pre-compiled Win32 binaries of Bochs. I've tried to build Bochs from scratch a couple of times (using MinGW), but every time I bump into some compile errors regarding an invalid function call (some function gets called with 2 parameters while it expects 3 parameters, something with a bx_bool, can't exactly remember what it was). I managed to fix the error a while ago (compilation continued), which keeps giving me a fault at 0xC0000005 (which I'm presuming is a heap fault).

That "ATA/IDE" page is a bunch of crap, BTW. Pay a lot more attention to the http://wiki.osdev.org/ATA_PIO_Mode article instead. It is much more accurate.

I'll take a look at this article soon and see if there's anything I did differently (or the other article does completely different).

[Creature]

Sorry for double post, but I forgot to mention that the code works perfectly fine on QEMU, but not on VirtualBox (the latter which AFAIK uses QEMU as base). VirtualBox gives me the exact same error.

[bewing]

Sorry for double post, but I forgot to mention that the code works perfectly fine on QEMU, but not on VirtualBox (the latter which AFAIK uses QEMU as base). VirtualBox gives me the exact same error.

Nothing except bochs uses the "calc_log_addr" function. So if you are getting the exact same error on VirtualBox, then VirtualBox must be using bochs as a base.

[Creature]

Well, the bad news is: I haven't been able to fix it, but the good news is: APPARENTLY if I do the same thing again (the exact same read), it automagically works. So that must mean there must be some code that's in the wrong place or something similar. Every two reads, it works. The first read fails, the second one works, the third one fails, etc.