FW: SB drivers freeze 2.1.95/2.1.96 every time!

Mark Orr (markorr@intersurf.com)
Mon, 13 Apr 1998 21:04:08 -0500 (CDT)


<grumble> <fume>

I'm getting a very reproducable hard lockup (no magic-sysrq sync or kill
possible) with the SB sound drivers (sb.o/uart401.o/sound.o) -- compiled
as modules and loaded by kmod.

First time they get loaded, they seem to work okay...but if you unload
them (manually or automatically via kmod) and they're reloaded...instant
lockup. No messages on the log/console other than SB (4.5) detected.

Well, the wave driver does that at least...the MIDI driver just refuses
to work after the first load/unload -- /dev/midi00 device not configured.
The message logs say:

Apr 13 20:45:02 darkstar kernel: Soundblaster audio driver Copyright (C) by
Hannu Savolainen 1993-1996
Apr 13 20:45:02 darkstar kernel: SB 4.5 detected OK (220)
Apr 13 20:45:02 darkstar kernel: sbmpu: I/O port conflict (330)

Yes, the addresses/IRQs/DMAs are all correct, this is not a PnP card.
(options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330)

----

ObRant: You know what really ticks me off about linux? It's not so
much that there arent drivers for particular hardware...but that
drivers get written...AND THEY DONT --STAY-- WRITTEN... The module
interface changes, the kernel calls change, and if the driver isnt
actively maintained...well that device just doesnt work anymore.

Unlike Win95 (and just about everything else), if the drivers are
buggy, most of the time, you CANNOT go back to older ones -- at
least not without going back to an older kernel...where ALL the
drivers are older.

I think it's obscene that a driver like GLIDE (which, thankfully, is
NOT a kernel module) continues to work version-after-version, reliably,
and with good performance...while things like the soundcard drivers,
much simpler devices than any 3d accelerator, break continually.

I'm starting to lean toward the opinion that we should just throw
ALL the damned drivers out of the kernel, and set them up as user-space
libraries or servers. Maybe someone can come up with a hack to allow
them to serve non-root users too. ugh...

----

Mark Orr
markorr@intersurf.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu