SB16 crashes

SB16 crashes

Post by Jason P Hey » Thu, 14 Apr 1994 06:11:22

        Maybe someone can help me here.  I'm running Linux 1.0 on a
486dx2 8 mb with a Sound Blaster 16 set to: port 220h, irq 5, 8 bit
dma channel 1, 16 bit channel 5. The next device starts at 240H and
irq 5 is not in use. Overall, I can't find any conflicts. I have tried
using a base port of 260h and I tried only installing the SB/SBpro
drivers and excluding the SB16 one. Operation in Dos gives me no
problems but vplay (from the 2.4 sound.util source) crashes after 0 to
30 seconds of 8 or 16 bit sound play.
        Here is the kernel's screen dump just before everything froze.
At the time, I had only included SB, SBpro and FM in zImage. This
particular error occurred seconds after a fresh reboot as I was
experimenting. Nothing that I did seemed to affect the problem.

general protection: 0000
EIP: 0010:0010e38a
EFLAGS: 00010246
eax: ffffffff   ebx: 00850f00   ecx: 00000202   edx: 00000000
esi: 00000000   edi: 00001000   ebp: 0017f804   esp: 0017f7ec
ds: 0018        es: 0016        fs: 002b        gs: 002b  gg: 0018
pid: 0 process nr: 0 (swapper)
Stack: ffff0000 0010ce2b 00000010 001752f0
Code: 68 c4 ea 10 00 e9 d4 fe ff ff 00 00 00 00 68 d4 e8 10 00 e9
Task[0] (swapper) Killed: unable to recover
Kernel Panic: Trying to free up swapper memory space
In swapper task - not syncing

My bootup looked like this:

Snd2 <SoundBlaster Pro 4.5> at 0x220 irq 5 drq 1
Snd1 <Yamaha opl-3 FM> at 0x388 irq 0 drq 0

Does this appear ok?

Please respond to this email address.


1. SNDCTL_DSP_GETOSPACE bug for SB16 (was: SB16: 2.4.18 lockup on odd-numbered 16bit sound input)

[following up on my mail yesterday]

Hi all,

write()ing an odd number of bytes to a SB16 when using format
AFMT_S16_LE completely froze my system on 2.4.18.
By making sure that drivers/sound/sb_audio.c/sb16_copy_from_user()
discards the remainder of odd-numbered byte inputs, I was able to
correct this.

However digging deeper, I found that Wine sent odd-numbered amounts of
bytes to the Soundblaster due to SNDCTL_DSP_GETOSPACE returning odd
This happens because SNDCTL_DSP_GETOSPACE strictly returns the amount
of memory available in the DSP (DMA memory).
BUT: the SB16 driver does a 16bit -> 8bit conversion for AFMT_S16_LE
input data !!
Thus the amount of bytes you are able to immediately write() to the
driver is *twice* the "bytes" count of SNDCTL_DSP_GETOSPACE, since the
SB16 driver converts two input bytes into 1 DSP byte.

IMHO this is a bug of the SNDCTL_DSP_GETOSPACE bytes value in case of
the SB16 driver.
The various docus for SNDCTL_DSP_GETOSPACE that I found always said that
"bytes" is the amount of bytes you can write() to the driver without
blocking, so this would hint at a SNDCTL_DSP_GETOSPACE bug for SB16.

Or should instead the application program (here: Wine) figure out somehow
that in fact two bytes sent get converted to 1 byte in the sound driver ?
I don't think so.

How should the kernel driver (drivers/sound/audio.c/dma_ioctl())
get modified to handle the input byte count properly ?
Can someone show me an easy way, or should I modify the driver management
structs somewhat to let SNDCTL_DSP_GETOSPACE have an easy check for this
condition ?

BTW: the odd-numbered input happened because:

SB16: I've got 1988 bytes avail
Wine: ok, sending 1988 bytes
SB16: I've got 994 bytes avail
Wine: ok, sending 994 bytes
SB16: I've got 497 bytes avail
Wine: ok, sending 497 bytes
SB16: *BOOM*

What Wine should have sent instead is 1988*2==3976 bytes, of course,
as SNDCTL_DSP_GETOSPACE returned the buggy "real input/2" return value
due to the reasons above...
As Wine always sent one half of the data that it could have sent,
the return value always was one half of the previous "available" value,
thus leading to an odd 497 value.

It's about time for ALSA, methinks...
(provided that one doesn't have even worse bugs ;-)

Andreas Mohr                        Stauferstr. 6, D-71272 Renningen, Germany
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at
Please read the FAQ at

2. identifying serial ports

3. (for gurus) ISSUES: crashes, crash on boot, crash on shutdown

4. E4500 shutsdown without any hint in /var/adm/messages

5. 2.0.34 keeps crashing and crashing and crashing and ...

6. tip for linux?

7. Crashing Crashing Crashing

8. Linux and UDMA

9. 2.0.34 keeps crashing and crashing and crashing and ...

10. ypbind crash crash crash

11. Help with OpenBSD 3.1 crashes (/var/crash/ files included)

12. Netscape crashes, X crashes, Woe is me...

13. What to do if Linux crashes (was Re: What to do if NT crashes...)