Eventually, at some point whose exact location in time I've forgotten, I
started having this annoying problem in DOOM. I'd play for a while --
sometimes a few minutes, sometimes tens of minutes, but almost
inevitably the sound would cut out at some point. Quitting DOOM would
get me a message like "DMA timed out -- IRQ/DRQ conflict?" But as far
as I could tell, there was no IRQ conflict, and my GUS was the only
device that used DMA. But since the only time I ever had a problem was
in DOOM, it also didn't matter a whole lot to me. I think I asked back
then on the list if anyone had experienced such a thing. This would
have been some time after late 1994, but before mid-1995.
Recently I finally achieved the Holy Grail for my old but serviceable
ISA-bus system -- a working BusLogic BT-545C to plug a Fujitsu 1G SCSI
disk into. And it works -- almost. But it has symptoms that at least
at one level seem analogous to the GUS problem -- it gets SCSI timeouts
with messages like this:
Jun 15 00:52:18 tzadkiel linux: scsi : aborting command due to timeout : pid 26423, scsi0, channel 0, id 0, lun 0 Read (6) 00 80 32 02 00
Jun 15 00:52:23 tzadkiel linux: scsi0: Aborting CCB #26437 to Target 0
Jun 15 00:52:23 tzadkiel linux: scsi : aborting command due to timeout : pid 26424, scsi0, channel 0, id 0, lun 0 Read (6) 06 20 22 08 00
Jun 15 00:52:23 tzadkiel linux: scsi0: Aborting CCB #26438 to Target 0
Jun 15 00:52:23 tzadkiel linux: SCSI host 0 abort (pid 26423) timed out - resetting
Jun 15 00:52:23 tzadkiel linux: SCSI bus is being reset for host 0 channel 0.
Jun 15 00:52:23 tzadkiel linux: scsi0: Sending Bus Device Reset CCB #26439 to Target 0
Jun 15 00:52:23 tzadkiel linux: SCSI host 0 abort (pid 26424) timed out - resetting
Jun 15 00:52:23 tzadkiel linux: SCSI bus is being reset for host 0 channel 0.
Jun 15 00:52:23 tzadkiel linux: scsi0: Resetting BusLogic BT-54xC due to Target 0
Jun 15 00:52:23 tzadkiel linux: scsi0: *** BusLogic BT-54xC Initialized Successfully ***
(Ironically, I got these while reading /var/log/messages to paste into
this message).
This isn't fatal; my system stays up, and these don't seem to happen too
frequently -- at worst a few minutes apart. I mainly notice because
when it does happen everything hitches up for a few seconds during the
card reset. The easiest way to instigate them is to start up DOOM,
which now that I have both a GUS and a SCSI disk is initiating DMA
activity like mad as it reads in its data and starts doing sound with
the GUS.
What I'm wondering, from those of you most versed in Linux kernel
development history, is whether some change was made to DMA handling
that might account for DMA-intensive stuff once working perfectly on my
(quite probably marginal) system, which then caused tis problem to start
happening for me. This has been happening at least since the 1.2
kernels came out, and has kept happening since I went from 1.2.13 to
1.99.9 through all the versions up to 2.0.0.