I was trying to modularize the sound in my 5.0R machine, which has two
sound cards:

$ dmesg | grep pcm.:
pcm0: <VIA VT82C686A> port 0xb000-0xb003,0xb400-0xb403,0xb800-0xb8ff irq
9 at device 4.5 on pci0
pcm1: <AudioPCI ES1373-B> port 0xa000-0xa03f irq 9 at device 10.0 on pci0

In order for them to work properly as modules, the files
snd_{pcm,via82c686,es137x}.ko have to be loaded in the beginning AFAIK.
Or else they won't be recognized and will be given as PCI devices with
"no driver attached".

Well, two issues:

1)
If they aren't loaded (I forgot them on the 1st try by mistake), the
kernel panics if I try to change hw.snd.maxautovchans (that odd "bwrite:
buffer is not busy???" message again!). That shouldn't happen: if I
don't have any soundcards, this oid shouldn't _exist_ either!

2)
If they're loaded, an attempt to unload snd_via82c686.ko results in a
panic with the funny message in the subject. But: Aren't modules
supposed to be unloadable? What's the fun with modules then?

Any hints on solving this?

My attempt to load modules instead of the monolithic solution (which
always works) comes due to an odd behaviour of pcm0 (multiplexed with
hw.snd.pcm0.vchans=8) telling that some /dev/dsp{W,}0.[0-7] devices are
busy after their first usage. I wanted to address it by unloading the
affected module and loading it again, but... that'll panic the system.

Has someone had something similar?

Thanks in advance,
David.

: I was trying to modularize the sound in my 5.0R machine, which has two
: sound cards:

: $ dmesg | grep pcm.:
: pcm0: <VIA VT82C686A> port 0xb000-0xb003,0xb400-0xb403,0xb800-0xb8ff irq
: 9 at device 4.5 on pci0
: pcm1: <AudioPCI ES1373-B> port 0xa000-0xa03f irq 9 at device 10.0 on pci0

: In order for them to work properly as modules, the files
: snd_{pcm,via82c686,es137x}.ko have to be loaded in the beginning AFAIK.
: Or else they won't be recognized and will be given as PCI devices with
: "no driver attached".

: Well, two issues:

: 1)
: If they aren't loaded (I forgot them on the 1st try by mistake), the
: kernel panics if I try to change hw.snd.maxautovchans (that odd "bwrite:
: buffer is not busy???" message again!). That shouldn't happen: if I
: don't have any soundcards, this oid shouldn't _exist_ either!

: 2)
: If they're loaded, an attempt to unload snd_via82c686.ko results in a
: panic with the funny message in the subject. But: Aren't modules
: supposed to be unloadable? What's the fun with modules then?

: Any hints on solving this?

This is an old bug in FreeBSD that people have found many years ago, and
has not been solved. I have in the past paniced my machine by doing:
-remove ipl.ko (the ipfilter module) while ipmon is listening on it.
-writing to a write-protected floppy (this one has been more or less
tampered, but there are still {*filter*} side-effects).
-removing the sound module while sound is playing.
I am quite sure there are many others of the same sort.

Moreover for sound cards the behavior is very model dependent. On my laptop
loading the module after boot gives nothing, the card is not recognized.
I have to load the module with /boot/loader. However, after boot i can
unload and then reload the module, sound still works. But if i suspend resume,
sound is killed and reloading module has no effect. Other people report
that reloading sound module works for them. In a few words, the module system
is not as well polished as in Linux, by far.

: My attempt to load modules instead of the monolithic solution (which
: always works) comes due to an odd behaviour of pcm0 (multiplexed with
: hw.snd.pcm0.vchans=8) telling that some /dev/dsp{W,}0.[0-7] devices are
: busy after their first usage. I wanted to address it by unloading the
: affected module and loading it again, but... that'll panic the system.

: Has someone had something similar?

: Thanks in advance,
: David.

--

Michel TALON

Report it to the developers (curr...@freebsd.org)

Kris