> <CC'ed to linux-kernel since Erik and Andre might be interested, not to
> mention the three or four people experiencing similar hangs....>
Guys, I have screamed violently at my DMA-CDrom drive and have launched
piles of code and it has always failed. I am at a loss with the any and
all DMA transfers that are not hard-disk related.
My DMA CDROM/TAPE/IDE-Floppy have all broken with a DMA-disable.
As I have said, I am no Mark Lord, but I am banging away. I need to get
a second keyboard (the should explain how intense this problem is for me).
I am suspect that the lack of building a DMA transfer-read table could
be a beginning point again. I am trying to get one of the venders of
UIDE-DMA PCI cards to fully disclose how they hand CDROMs with (U)DMA,
not that I have a binding NDA with them for another few months until.
> On Sun, 13 Sep 1998, Gordon Chaffee wrote:
>
> > Bill Hawes writes:
> > > Chris has a case where enabling IDE DMA causes a hang, but without DMA
> > > it works. I don't see how anything in isofs/inode.c could affect DMA,
> > > but there may be some subtle interaction with timing.
> Gordon, to bring you up to speed completely, my box doesn't hang. The mount
> process hangs. The bug first appeared in 2.1.117 (I don't use cd-roms very
> often, obviously), so I worked forward from 2.1.96 which was the previous
> one I'd used a cd with. What I found was that 2.1.101 and previous were
> fine. The first time I try to mount a cd on those after bootup, the mount
> returns an error and then all subsequent mounts would work (which is also
This is normal, if the first one cause the DMA transfers to bew disabled.
> what 2.0.x does on that box with that cdrom). Starting with 2.1.102, the
> initial mount after bootup hangs infinitely, making subsequent mount
> attempts impossible (though I suspect they would work). I worked throught
> the 101 and 102 patches file-change by file-change, and it's definitely the
> fs/isofs/inode.c changes that are breaking things. 2.1.102 with only the
I have started to poke in here, but I got distracted with other events.
> 2.1.102 inode.c changes backed out works fine, and 2.1.101 with just 2.1.102
> inode.c changes added breaks. I don't think it's actually the inode.c
> rearrangement per se, but rather an overly sensitive DMA and a not-quite
> compliant (or perhaps even compliant, but closer to the edge than the Linux
> DMA code expects) cdrom. Furthermore, I now have another ide cd-rw on that
Humor me and name the hardware that works and breaks. Second, have you
got clear/any reports that show transfer rates are what they should be
expected?
A side note is that CD-RWers are somewhat like a regular hard-disk, so
it may have a more compliant firmware like what hard-disks have.
> same bus, and it works great with all kernels and with or without dma, so
> it's probably not that my bus is broken.
Cheers,
Andre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html