Generic int 13h driver

[Die Gestalt]

Muhahah, despite the world conspiracy against my evil plot to enslave disk
drivers with the BIOS I now manage to write to the disk.

But I get a :

kernel: stray irq14

Of course irq14 is the IRQ of the disk controller. The int13h returns with a
status time out, but the writes succeeded anyways (he had no choice: I have
sharks with laser beams attached to their heads). I can see my random bytes
when I open the disk with an hex editor. I think what happens is that the
BIOS never gets its IRQ14 "back" and cannot acknowledge that the operation
went fine.

Any hint?

On 5/21/07, Die Gestalt <die.gestalt at gmail.com> wrote:
>
> On 5/16/07, Dag-Erling Smørgrav <des at des.no > wrote:
> >
> > "Die Gestalt" < die.gestalt at gmail.com> writes:
> > > As the subject implies I'm currently doing the most unholy thing ever.
> > I'm
> > > writing a driver that accesses hard disks through BIOS int13h. The
> > reasons
> > > why I'm doing this are many, but mainly I will be in a situation where
> > I
> > > will not be able to update my kernel and where I want to support as
> > much
> > > devices as possible. I know this will be slow and I know this will
> > only work
> > > on the i386 platform, I accept that.
> >
> > It won't work nearly as universally as you intend; for some devices
> > (particularly USB devices), the BIOS tries to enter protected mode when
> > servicing requests.
>
>
> I know there will be some limitations unfortunately.
>
> > So far so good, I have a skeleton which is able to query the drive
> > > parameters and some basic stuff. But when I want to read, this doesn't
> > work,
> > > except in QEmu (http://www.qemu.org). I've tried on a VMWare and a
> > real
> > > machine, what I get is a stall for maybe 10 s (sometimes not) and the
> > > operations returns saying it's successful but my buffer is actually
> > left
> > > untouched. I get no kernel message.
> >
> > Have you verified that the buffer you write from or read into is mapped
> > correctly in virtual 8086 mode, and that you pass the correct address to
> >
> > the BIOS?
>
>
> I think so. It works when I request a buffer to be filled with
> information. For instance function 48h of the int 13h correctly fills my
> buffer.
>
> To pass the address I use vm86_addpage to update a vm86context and then I
> pass this context to vm86_datacall.
>
> I think this might be a DMA problem. When the BIOS writes to the buffer,
> it does it via DMA, and I get typical DMA problems. However I've tried to
> use a buffer allocated via buf_dmamem_alloc() to no success.
>
> Thanks for your answer.
>