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").
Secondary ATA Controller causes exception (SOLVED)
-
thewonderidiot
- Posts: 19
- Joined: Sat May 05, 2007 1:27 pm
Secondary ATA Controller causes exception (SOLVED)
Last edited by thewonderidiot on Fri Oct 12, 2007 2:43 pm, edited 1 time in total.
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.
-
thewonderidiot
- Posts: 19
- Joined: Sat May 05, 2007 1:27 pm
