Bug 81 - New sound support hard locks my machine with ad1848 module
New sound support hard locks my machine with ad1848 module
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 1998-11-15 19:26 EST by Edward Schlunder
Modified: 2014-03-16 22:08 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1998-12-04 10:53:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Edward Schlunder 1998-11-15 19:26:24 EST
I have two sound cards that use the ad1848 module -- one
is a Yamaha SA3 isa pnp card and the other an old Oak
Technology OTI601 Mozart card. These both used to work when
I manually entered configuration stuff for them in
/etc/conf.modules with RH5.1 and kernel 2.0.35 (yes, Red
Hat's kernel, not a custom compile).

If I boot into single user mode and play an MP3 with mpg123,
I can listen to it for around a minute and then it suddenly
hard locks. If there is anything else going on in the
computer, such as hard disk accesses, the computer is sure
to crash. That is, if I put mpg123 in the background and do
a ls -lR /, the machine locks immediately instead of playing
for a minute or two.

My system specs:
	AMD K6-166
	Achitec ACHI156 motherboard
	128MB 10ns SDRAM
Comment 1 Bill Nottingham 1998-11-20 07:23:59 EST
Haven't had problems with the ad1848 module here. Does this
occur with both sound cards, or just one of them? Are you
just using the ad1848/mpu401 combination on the OPL3-SA3,
or are you using the beta OPL3-SAX driver?

One thing you might try is using hdparm to turn off DMA mode
on your hard drive; on some motherboard/IDE chipset combinations,
there have been problems reported with DMA and sound cards.
(This is just a stab in the dark - it might not work.)
Comment 2 Bill Nottingham 1998-12-03 15:58:59 EST
I've talked with Alan; he confirmed that it's a problem with
the VIA chipset on your motherboard and a (needed) fix that
went into the sound drivers in 2.0.36. What you can try is the
patch (see the 'email' section in bugzilla); apply it, rebuild, &
reinstall the kernel - does that solve your problem?
Comment 3 Edward Schlunder 1998-12-03 20:50:59 EST
This looks promising. The 2.1.129ac6 kernel (which included this fix,
I assume) worked with sound on my computer and was the first 2.1.x
kernel to ever work on my computer with sound (but 2.1.129ac6 is still
unusable for day to day use -- it randomly crashes for no reason). I
will try this patch on the kernel 2.0.36 SRPM and see if it works
Comment 4 Edward Schlunder 1998-12-04 03:07:59 EST
This patch fixed it. Thanks!
Comment 5 Edward Schlunder 1998-12-12 13:06:59 EST
Oops, spoke too soon. The new sound support, even with the DMA patch,
still hard locks my machine once in a while.

In x11amp, it only crashes at the end of a song (when playing a whole
list of songs). It doesn't always crash, but once in a while it does.
I've never seen it crash in the middle of a song, just the end (maybe
that could be viewed as the beginning of the next song, I dunno).

2.1.131ac9 also hard locks due to sound. Same symptoms, and I got it
to crash once when I pressed the pause button in x11amp. This when
sound was playing and I wanted it to stop.

On 2.0.36 with the dma patch, it crashed one time in the middle of a
WAV played back by the "play" command in Red Hat 5.2. So it's not
specific to x11amp.

Is there any way to print out a list of the kernel sound calls x11amp
makes when the pause button is pressed? As it is, I don't know where
to look in the kernel sound code for the problem.

Note: in 2.1.131-ac9 I had to steal the 2.0.36 mad16.c file because
the one that comes with 2.1.131-ac9 breaks support for my Oak
Technology Mozart sound card (can't detect it).
Comment 6 zblaxell 1998-12-12 20:02:59 EST
To find out system calls run 'strace':

strace x11amp		(dumps all x11amp system calls)
strace -f x11amp	(if x11amp is multithreaded, use this)
strace -p 13516		(attach to already running process 13516)

You may have to manually decode the hex ioctl() calls.  strace tries
but doesn't always keep up with all the existing kernel calls.

This probably won't successfully display the one system call that is
crashing the system unless you run it (strace) on a virtual console.
It might show the system call previous to the one that causes a crash,
then, well, crash.

Note You need to log in before you can comment on or make changes to this bug.