OSDev.org

Hello again, I've finally gotten my ATA driver to read sectors successfully from my primary master drive. However, when I use the same code to try to access my secondary master drive, I get an exception (99.99% sure it's exception 6, Invalid Opcode). The only change I make is changing the 0x1f0 in the finddrive() function to 0x170.

Here's the code:

<removed>

The strange thing is, the exception is never thrown at the same point. Once (and only once) it managed to successfully read in the secondary master drive's MBR with no problem. Sometimes it gets halfway through a kprint() before the exception comes. Other times it doesn't get past the READSECTORS command.

I'm not sure if it has any relevance at all, but the hardware *might* have something to do with it. My motherboard has a JMicron AHCI for its IDE interface, so I can't communicate with my ATA drives like I would be able to in most computers (my Gentoo couldn't see my ATA drive until I recompiled my Linux kernel with JMicron support).

I have two SATA drives in the computer, one that is my main and one for storage. My motherboard does ATA emulation with these; the main drive appears as a Primary Master ATA disk, and the storage drive appears as the Secondary Master ATA disk. I can read from my main hard drive (the "primary master") fine, but the problem comes up when I try to read from the storage drive (the "secondary master").

Well the simplest thing I can think of that might be causing you trouble is that the master and secondary controller have different interrupt numbers. Make sure you are either masking the interrupts at the PIC or have a suitable ISR for both controllers, unless of course you are putting the drives in interrupt disable mode, but I would still have the ISRs just in case.

Basically, I agree with frank. But it's confusing .... Why are you reading BOTH the alternate status and the regular status ports? You only need to loop on one or the other, AFAIK. The fact that you take the time to read the alternate port once probably does mean that you are not pre-empting the IRQ in time -- so it probably does fire. So look at your IRQ14 handler very closely.

Argh, you guys were right. I went in and found out that my handler array had 15 elements for 16 IRQ's, and IRQ 15 was being fired. Thanks for the help, and sorry for the noob mistake