OK, the bad news is that reverting to pcm of Dec 5 doesn't fix my
problem. The good news is that "options PNPBIOS" does fix it. Now if
only someone could explain all this junk:
# pnpinfo
Checking for Plug-n-Play devices...
No Plug-n-Play devices were found
# dmesg
...
pcm0: <CS4231> at port 0x530-0x537,0x538-0x539 irq 5 drq 1 flags 0xa110
on isa0
unknown0: <PNP0c02> at port 0x80,0x398-0x399 iomem
0xffff0000-0xffffffff,0xc9a00-0xcffff on isa0
unknown1: <PNP0c01> at iomem
0-0x9ffff,0xe8000-0xfffff,0x100000-0x7ffffff on isa0
unknown2: <PNP0200> at port 0-0xf,0x81-0x8f,0xc0-0xdf drq 4 on isa0
unknown: <PNP0000> can't assign resources
unknown3: <PNP0100> at port 0x40-0x43 irq 0 on isa0
unknown4: <PNP0b00> at port 0x70-0x71 irq 8 on isa0
unknown: <PNP0303> can't assign resources
unknown5: <PNP0c04> at port 0xf0-0xff irq 13 on isa0
unknown: <PNP0800> can't assign resources
unknown6: <PNP0a03> at port 0xcf8-0xcff on isa0
unknown7: <PNP0c02> at port 0x4d0-0x4d1,0x8000-0x803f,0x2180-0x218f on
isa0
unknown: <YMH0021> can't assign resources
unknown: <YMH0023> can't assign resources
unknown: <PNP0400> can't assign resources
unknown: <PNP0f13> can't assign resources
unknown: <PNP0501> can't assign resources
unknown: <PNP0700> can't assign resources
unknown8: <YMH0022> at port 0x201 on isa0
unknown9: <PNP0e03> at port 0x3e0-0x3e1 on isa0
If I don't have any PnP devices, where does all that <PNPBLAH> crap come
from? Also, I'm guessing that <YMH????> stands for Yamaha, and indeed,
Windows thinks my sound card is a Yamaha. Why does ymf_test fail to
detect it then?
I never used to have "controller pnp0" in my config file. This option
disappeared on Dec. 6 as PnP stuff became a standard part of the
kernel. It also seems to have broken my *NON-PNP* ISA sound card,
unless PNPBIOS is used. Incidentally, I have PnP OS=YES in my BIOS,
but that shouldn't matter since I don't have any PnP devices, right?
What on earth is going on?
Alex
Alex wrote:
>
> PCM has been broken for me since December 1999. I would very much
> appreciate if someone could help me fix it before the code freeze (cg,
> dfr and tanimura CC'd).
>
> I have an unknown MSS-compatible non-PnP ISA sound card, which
> identifies itself as a CS4231. Unknown, because it's inside a
> laptop. Before you ask, it has always been identified as a CS4231, and
> always worked very well. The last kernel that I have which still works
> is dated 6 Dec 1999, and I'm playing mp3's with it right now. Here's
> its verbose boot message:
>
> mss_detect - chip revision 0x0a
> mss_detect() - Detected CS4231
> pcm0: <CS4231> at port 0x530-0x53f,0x310-0x311 irq 5 drq 1 flags 0xa210
> on isa0
> pcm: setmap 30000, ff00; 0xc8421000 -> 30000
> pcm: setmap 40000, ff00; 0xc8431000 -> 40000
> isa_probe_children: probing PnP devices
>
> Kernels built after 26 Dec 1999 print the following:
>
> mss_detect - chip revision 0x0a
> mss_detect() - Detected CS4231
> pcm0: <CS4231> at port 0x530-0x537,0x538-0x539 irq 5 drq 1 flags 0xa110
> on isa0
> pcm: setmap 30000, ff00; 0xc840e000 -> 30000
> pcm: setmap 40000, ff00; 0xc841e000 -> 40000
> isa_probe_children: probing PnP devices
> mss_intr: irq, but not from mss
>
> and screw up the card - there is no sound and the driver gets stuck in
> "pcmwr". Something was committed between the 6th and 26th of December
> that broke pcm. The question is: which commit broke it?
>
> What has changed?
>
> 1) I/O port allocation and flags in dmesg: 0x310-0x311 vs 0x538-0x539,
> and 0xa210 vs 0xa110
>
> 2) The "mss_intr: irq, but not from mss" line
>
> Why? My config file hasn't changed a bit, neither has my hardware or
> BIOS setup. I don't have "controller pnp" in my config file, so it
> probably has nothing to do with PnP.
>
> The list of commits that might have broken it is appended below for your
> convenience. Please let me know if I have missed something obvious.
>
> Thank you for your attention
>
> Alex
>
> -----------------------------
> (commits skipped)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
