This may be related to the problem reported in the "pcm0 play interrupt timeout, channel dead" thread. The problem in that the Crystal Audio sound card on my ThinkPad 600E is inconsistently probed. The result is that it is sometimes pcm0 and sometimes pcm1. If I get this from my device probe, the CS423x is pcm1: csa0: <Crystal Semiconductor CS4610/4611 Audio accelerator> mem 0x50000000-0x500fffff,0x50100000-0x50100fff irq 11 at device 6.0 on pci0 pcm0: <CS461x PCM Audio> on csa0 pcm0: ac97 codec invalid or not present (id == 0) device_probe_and_attach: pcm0 attach returned 6 pcm1: <CS423x-PCI> at port 0x530-0x537,0x388-0x38b,0x220-0x233 irq 5 drq 1,0 on isa0 But, it it probes like this, the "real" sound device is pcm0: csa0: <Crystal Semiconductor CS4610/4611 Audio accelerator> mem 0x50000000-0x500fffff,0x50100000-0x50100fff irq 11 at device 6.0 on pci0 device_probe_and_attach: csa0 attach returned 6 pcm0: <CS423x-PCI> at port 0x530-0x537,0x388-0x38b,0x220-0x233 irq 5 drq 1,0 on isa0 It seems about 50/50 on which way it probes for any given reboot. Of course, every time it flips, I need to log in a s root and switch the device over. This is at least a bit of a pain. Has anyone got an explanation of why this happens and if there is a chance of getting it fixed? It bothers me when my system acts in a non-deterministic fashion in something that should be as repeatable as a device probe! It also wastes irq 11 in the first case and I have a tight IRQ situation on that system, in any case. It's been doing this since I upgraded to 4.0-Stable about a month after 4.0 was released and about three days after Xircom Ethernet support went in. It may have been doing it under 3.4, but I never used the audio, so I really don't know. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
