Bug 18345
| Summary: | [sound] sbc / pcm not fully recognizing AWE64 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | jjm7570 <jjm7570> |
| Component: | kern | Assignee: | freebsd-multimedia (Nobody) <multimedia> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
jjm7570
2000-05-02 16:20:01 UTC
Responsible Changed From-To: freebsd-bugs->cg Over to pcm maintainer. unknown0: <Game> at port 0x200-0x207 on isa0
unknown1: <WaveTable> at port 0x620-0x623 on isa0
unknown2: <IDE> at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0
these devices are not required for pcm.
if pcm does not function, there is some other reason.
-cg
Hello everybody,
This could be a generic PnP problem, not a pcm/sbc problem only.
I am now hit by a related/similar problem in 4.9-STABLE.
The difference is though that in my case the kernel does not
recognize even the actual pcm/sbc audio (logical) device.
This became kind of long because I am quoting quite a lot of
the kernel messages from a verbose boot.
So, what happens in my environment at boot time goes like...
aic7896/97: Ultra2 Wide Channel B, SCSI Id=7, 32/253 SCBs
pcm0: <AudioPCI ES1373-B> port 0xef00-0xef3f irq 9 at device 12.0 on pci0
pcm0: <TriTech TR28023 AC97 Codec (id = 0x54524103)>
pcm0: Codec features 6 bit master volume, no 3D Stereo Enhancement
using shared irq9.
pcm0: sndbuf_setmap 1f138000, 1000; 0xc2204000 -> 1f138000
pcm0: sndbuf_setmap 1f0fa000, 1000; 0xc2206000 -> 1f0fa000
fxp0: <Intel 82559 Pro/100 Ethernet> port 0xee80-0xeebf mem 0xff900000-0xff9ffff
f,0xffafd000-0xffafdfff irq 2 at device 13.0 on pci0
fxp0: using memory space register mapping
using shared irq2.
fxp0: Ethernet address 00:e0:81:10:36:f0
fxp0: PCI IDs: 8086 1229 8086 000c 0008
fxp0: Dynamic Standby mode is disabled
So, another Ensonic sound device integrated in the mother board
is found OK, and the story continues...
pcib1: <Intel 82443GX host to AGP bridge> on motherboard
pci2: <PCI bus> on pcib1
ex_isa_identify()
ata-: ata0 exists, using next available unit number
ata-: ata1 exists, using next available unit number
Trying Read_Port at 203
Trying Read_Port at 243
CTL0042: start dependant
CTL0042: adding irq mask 0x20
CTL0042: adding dma mask 0x2
CTL0042: adding dma mask 0x20
CTL0042: adding io range 0x220-0x22f, size=0x10, align=0x1
CTL0042: adding io range 0x330-0x331, size=0x2, align=0x1
CTL0042: adding io range 0x388-0x38b, size=0x4, align=0x1
CTL0042: start dependant
CTL0042: adding irq mask 0x6a0
CTL0042: adding dma mask 0xb
CTL0042: adding dma mask 0xe0
CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
CTL0042: adding io range 0x300-0x331, size=0x2, align=0x30
CTL0042: adding io range 0x388-0x38b, size=0x4, align=0x1
CTL0042: start dependant
CTL0042: adding irq mask 0x6a0
CTL0042: adding dma mask 0xb
CTL0042: adding dma mask 0xe0
CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
CTL0042: adding io range 0x300-0x331, size=0x2, align=0x30
CTL0042: start dependant
CTL0042: adding irq mask 0x6a0
CTL0042: adding dma mask 0xb
CTL0042: adding dma mask 0xe0
CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
CTL0042: start dependant
CTL0042: adding irq mask 0x6a0
CTL0042: adding dma mask 0xb
CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
CTL0042: adding io range 0x300-0x331, size=0x2, align=0x30
CTL0042: adding io range 0x388-0x38b, size=0x4, align=0x1
CTL0042: start dependant
CTL0042: adding irq mask 0x6a0
CTL0042: adding dma mask 0xb
CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
CTL0042: adding io range 0x300-0x331, size=0x2, align=0x30
CTL0042: start dependant
CTL0042: adding irq mask 0x6a0
CTL0042: adding dma mask 0xb
CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
CTL0042: start dependant
isa0: too many dependant configs (8)
CTL7002: start dependant
CTL7002: adding io range 0x200-0x207, size=0x8, align=0x1
CTL7002: start dependant
CTL7002: adding io range 0x200-0x20f, size=0x8, align=0x8
CTL7002: end dependant
CTL0022: start dependant
CTL0022: adding io range 0x620-0x623, size=0x4, align=0x1
CTL0022: start dependant
CTL0022: adding io range 0x620-0x683, size=0x4, align=0x20
CTL0022: end dependant
CTL2011: start dependant
CTL2011: adding irq mask 0x400
CTL2011: adding io range 0x168-0x16f, size=0x8, align=0x1
CTL2011: adding io range 0x36e-0x36f, size=0x2, align=0x1
CTL2011: start dependant
CTL2011: adding irq mask 0x800
CTL2011: adding io range 0x1e8-0x1ef, size=0x8, align=0x1
CTL2011: adding io range 0x3ee-0x3ef, size=0x2, align=0x1
CTL2011: start dependant
CTL2011: adding irq mask 0x9c00
CTL2011: adding io range 0x180-0x1bf, size=0x8, align=0x8
CTL2011: adding io range 0x306-0x33f, size=0x2, align=0x8
CTL2011: start dependant
CTL2011: adding irq mask 0x8000
CTL2011: adding io range 0x170-0x177, size=0x8, align=0x1
CTL2011: adding io range 0x376-0x376, size=0x1, align=0x1
CTL2011: end dependant
isa_probe_children: disabling PnP devices
isa_probe_children: probing non-PnP devices
orm0: <Option ROMs> at iomem 0xc0000-0xccfff,0xd0000-0xd57ff on isa0
pmtimer0 on isa0
So, this is definitely the SB-AWE64 talking here
CTL0042 being the audio device, CTL7002 being the
joystick / game port, CTL0022 the wave table, and
CTL2011 the IDE interface.
Notice that now the PnP devices become disabled for
non-PnP probes to take place. Everything goes just
fine until...
isa_probe_children: probing PnP devices
unknown: <Audio> can't assign resources
unknown: <Audio> at port 0x220-0x22f irq 10 on isa0
joy1: <Generic PnP Joystick> at port 0x208-0x20f on isa0
adv1: Invalid baseport of 0x620 specified. Nearest valid baseport is 0x330. Fai
ling probe.
pcf1: can't reserve irq, polled mode.
pcf1: <PCF8584 I2C bus controller> at port 0x620-0x62f on isa0
So, when the PnP devices should be probed for real the AWE64
board is not recognized. The piggy-back joystick interface on
the same card is found OK, but the wave table and IDE interfaces
are not seen at all.
It sort of looks like the PnP boards should be explicitly
enabled again before any further PnP probes are properly
replied. If that is the case the SB-AWE64 problems are
actually problems in how the PnP probes are done.
When the system is up and running the "pnpinfo" program
finds all of the logical devices without a flaw.
In case someone wonders the devices pcm and sbc have been
compiled static in the kernel.
The almost comical thing about this is that with older
3.5.1 kernels there is no problem in finding the SB audio
device.
I hope this helps.
// jau
This could be the same problem as in kern/51308 <http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/51308> // jau Right, I am still ranting on about SB-AWE-64 probe problem... This time I even have the answer. ;-) It seems my hypothesis about the PnP mechanism itself being broken in 4.x was entirely correct. When I simply disabled the part of isa_common.c which generates the note... isa_probe_children: disabling PnP devices and disables the PnP devices my "broken" SB-AWE-64-ISA card was probed successfully and started working just fine again immediately after the next boot. (The "SoundBlaster 16" type shown below is obviously an echo of a mistaken device ID code or simply due to shared sb16/sbc module, but since the cards are largely the same this does not really matter.) sbc0: <SoundBlaster 16> at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm1: <SB16 DSP 4.16> on sbc0 pcm1: sndbuf_setmap 48000, 1000; 0xd9f6f000 -> 48000 pcm1: sndbuf_setmap 49000, 1000; 0xd9f70000 -> 49000 pca0 at port 0x40 on isa0 joy0 at port 0x201 on isa0 Let me put it this way. I am not happy - not because the fully operational sound card were some sort of disappointment to me, but because the bug has been such an obvious one and it has been lingering on through several minor releases though there have been complaints hinting to the roots of the problem. What actually happens is that some Sound Blaster cards really are obedient little cards, and after being told to remain quiet they really do exactly that. They refuse to talk actively even if requested to assign an IRQ. When the kernel after probing for the legacy ISA devices starts telling the PnP devices the communication settings they should use these cards simply remain quiet. They start reacting again when pnpinfo is used to probe for them, but the autoconfigure phase is already over and done with then. Even though majority of PnP devices maybe interpret silence being over when the kernel starts to assign communication settings all devices are not alike. The ones that still refuse to do any active communication may well be in error in doing so, but they at least err on the safe side. Stubbornly sticking to the idea that the current PnP logic is the "proper" way to do it simply makes some otherwise perfectly good devices unusable. In fact it does not even matter which ones are in error, those that keep silent or those that do not. The old golden rule should still be followed: "Be pedantic about what you make others accept from you, and liberal about what you are willing to accept from others." The Sound Blaster cards definitely being the others here. Sound Blaster cards can hardly be changed, but the PnP logic can. And supposedly some SB cards are not the only PnP devices that interpret being disabled this way. So, this is a generic PnP problem. I do not wish to propose any particular way to solve this. There are alternatives of course, but it should be the PnP code administrators to decide as long as they do not stick to the current method. 1) One could simply drop the disabling phase completely and check all legacy ISA communication settings against the PnP settings catalog and marking any overlapping configurations void/unusable before the PnP devices communication settings are assigned. 2) One could leave the disabling as is and resolve to resetting and reprobing the PnP devices after and the legacy ISA devices have been configured. 3) Find some other logic to avoid devices being left disabled. I really, really hope this helps - and preferably quickly. // jau In message: <409A9A29.7020502@mawit.com> "Jukka A. Ukkonen" <Jukka.Ukkonen@mawit.com> writes: : : Right, I am still ranting on about SB-AWE-64 probe problem... : This time I even have the answer. ;-) : : It seems my hypothesis about the PnP mechanism itself being broken : in 4.x was entirely correct. When I simply disabled the part of : isa_common.c which generates the note... : : isa_probe_children: disabling PnP devices : : and disables the PnP devices my "broken" SB-AWE-64-ISA card was : probed successfully and started working just fine again immediately : after the next boot. (The "SoundBlaster 16" type shown below is : obviously an echo of a mistaken device ID code or simply due to : shared sb16/sbc module, but since the cards are largely the same : this does not really matter.) : : sbc0: <SoundBlaster 16> at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0 : sbc0: setting card to irq 5, drq 1, 5 : pcm1: <SB16 DSP 4.16> on sbc0 : pcm1: sndbuf_setmap 48000, 1000; 0xd9f6f000 -> 48000 : pcm1: sndbuf_setmap 49000, 1000; 0xd9f70000 -> 49000 : pca0 at port 0x40 on isa0 : joy0 at port 0x201 on isa0 : : : Let me put it this way. I am not happy - not because the fully : operational sound card were some sort of disappointment to me, : but because the bug has been such an obvious one and it has been : lingering on through several minor releases though there have : been complaints hinting to the roots of the problem. Generally speaking, exposing a whiny attitude generally isn't conducive to accomplishing your goals of getting this fixed. Human nature being what it is and all that. However, having said that, I'm reading past your attitude to try to resolve the problem. : What actually happens is that some Sound Blaster cards really : are obedient little cards, and after being told to remain quiet : they really do exactly that. They refuse to talk actively even : if requested to assign an IRQ. : When the kernel after probing for the legacy ISA devices starts : telling the PnP devices the communication settings they should : use these cards simply remain quiet. They start reacting again : when pnpinfo is used to probe for them, but the autoconfigure : phase is already over and done with then. What does this refusal look like? What port reads doesn't it reply to? It seems odd that pnpinfo would work and the kernel probe wouldn't. : Even though majority of PnP devices maybe interpret silence being : over when the kernel starts to assign communication settings all : devices are not alike. The ones that still refuse to do any active : communication may well be in error in doing so, but they at least : err on the safe side. Stubbornly sticking to the idea that the : current PnP logic is the "proper" way to do it simply makes some : otherwise perfectly good devices unusable. : In fact it does not even matter which ones are in error, those : that keep silent or those that do not. The old golden rule should : still be followed: "Be pedantic about what you make others accept : from you, and liberal about what you are willing to accept from : others." The Sound Blaster cards definitely being the others here. : Sound Blaster cards can hardly be changed, but the PnP logic : can. And supposedly some SB cards are not the only PnP devices : that interpret being disabled this way. Where do you get this information. It is news to me. : So, this is a generic PnP problem. I do not wish to propose : any particular way to solve this. There are alternatives of : course, but it should be the PnP code administrators to decide : as long as they do not stick to the current method. My PNP cards work just fine. I'm surprised that you are having problems. I'm upgrading to 4.10 RC tonight and will try the few PnP ISA cards I have. : 1) One could simply drop the disabling phase completely and : check all legacy ISA communication settings against the PnP : settings catalog and marking any overlapping configurations : void/unusable before the PnP devices communication settings : are assigned. Can't do that. It violates the spec. Also, what's the PnP catalog here? Is it the list you get from the BIOS or is it pnp cards. if it is the pnp cards, then you MUST disable them so you can enumerate them. There's no way around that. that's how pnp Isa cards work. : 2) One could leave the disabling as is and resolve to resetting : and reprobing the PnP devices after and the legacy ISA devices : have been configured. Can't do that either. : 3) Find some other logic to avoid devices being left disabled. That's not likely a viable option either. Maybe you could offer a suggested patch? Warner Responsible Changed From-To: cg->sound With permission, reassign to mailing list alias. State Changed
From-To: open->closed
Too much changes in 5.x. Please open a new PR with 5.x debugging info
("pciconf -v -l", ...) in case you still can reproduce it there.
|
