ATA Problems: works in VBox, not in QEMU or Bochs.

[zhiayang]

I realise there's another recent thread dealing with... what *appears* to be a similar issue, but here I am, threadjacking isn't legit.

I'm having an issue reading sectors from an ATA drive. I currently have 2 drives connected: one is an MBR drive, the other a GPT drive.
I believe with reasonable confidence that both the MBR and GPT partition reading code works correctly... However, initialising a partition (specifically, reading anything above LBA2 on the second, GPT drive) results in... some weird ****.

Here is the relevant code, before I proceed:
PIO.cpp: http://pastebin.com/ppPYQ8bd
GPT.cpp: http://pastebin.com/2R5qNXxT
MBR.cpp: http://pastebin.com/mK1f8tSj
Partition.cpp: http://pastebin.com/XbALj2xQ
ATA.cpp: http://pastebin.com/6GFZ2Que

What happens is this:
1. MBR code detects partitions on both ATA devices. The first device is simply a single-partition boot drive with FAT32. The secondary drive (bus0, drive 1) is a GPT drive with 4 HFS+ partitions.

2. MBR code detects the 0xEE partition on the second drive and calls ReadPartitions() in GPT.cpp.
3. GPT code detects the partitions.
There's a secondary problem here: Reading the partitions... doesn't guarantee a GUID of 0x00.... which is most likely a problem on my end, but...

4. GPT code therefore only detects 4 partitions. It loops through (as shown) and detects the first HFS+ partition, and calls (new Partition()) with the relevant information.

5. Partition() detects the GUID of a HFS+ partition and calls new HFSPlus().
6. In HFSPlus(), I attempt to read a couple of sectors from the second drive. That, fails -- I get 0x00 on all reads.

7. This is the worst part: after all that, it returns back to the GPT code.
8. In the next loop, somehow *everything* gets trashed and becomes 0x00: no other partitions are initialised.

9. Reading from the first drive, however, works 100%...

The best part? As seen from the title, the bugs at steps 7 and 8... simply don't exist in VBox.
If there's any other code that might be needed, find the repo at https://bitbucket.org/requimrar/orion-x3.

This probably seems like another 'solve-my-problem-for-me-plus-code-dump' kind of post... but I've been trashing my brains about this and I cannot see the problem. It's probably something ridiculously stupid...

Thanks!

[Combuster]

There's two bugs. The first one is that your disk driver only ever seems to store one sector - globally. The moment you read another sector, the other code that depends on a different sector will suddenly be stuck with the wrong data.
This is essentially a gross design failure, and it is probably the direct cause for points 7-9.


The actual disk driver is probably best tested with the I/O logging for harddisks enabled in bochs.

[zhiayang]

There's two bugs. The first one is that your disk driver only ever seems to store one sector - globally. The moment you read another sector, the other code that depends on a different sector will suddenly be stuck with the wrong data.
This is essentially a gross design failure, and it is probably the direct cause for points 7-9.


The actual disk driver is probably best tested with the I/O logging for harddisks enabled in bochs.

Oh... I knew it was something stupid. I actually planned for that to be simply a buffer things would Memory::Copy() from, but turns out in my rush to get something working (rather than working right) I inadvertently forgot about that.

What was the second bug again?