In message <200012200604.BAA26681@dragon.tools.gtei.net>, jchacon@genuity.net w
rites:
>>>In this specific case it was conflicting with any PCI device that happens
>>>to get auto-assigned to irq 10 on a machine.
>>
>>Shouldn't we be able to fix this? Is it always the case that a PCI device
>>on IRQ 10 makes the wss driver hang the machine?
>>
>>Anyhow, this message doesn't clear you of the previously mentioned
>>documentation responsibilities -- could you act on them?:
>
>You've done ISA before, right?

Yes, though I try to keep it to a minimum.

>This is a hard coded assumed irq in the config (just like half the
>other ISA devs are also). In this case it's a bad idea since it's too
>easy for that choice to conflict with other things in a machine (say
>your scsi card) and then panic on boot.

You're not being terribly rigorous in your explanation.
You cite the case of PCI devices that get assigned to interrupt 10.
If they can't share and interrupt, then who is at fault? wss for
being on IRQ 10, or PCI for being there? Presumably the PCIBIOS code
puts the PCI stuff at interrupt 10?

In any case, we should be able to detect the problem. We certainly
know when there's PCI stuff on IRQ 10. If necessary, the wss probe
could detect that.


Or are you saying that co-existance is only _sometimes_ a problem?

[ I have some vague recollection of there being an issue where the 
wss probe succeeded when there was a sound card that was in sb
compatibility mode, but it probed as a wss anyway, as well as an sb,
and various fallout occurred. Commenting out the wss entry was
a solution for that too, but I don't imagine this is the same issue. ]

>What's to document then, ISA sucks? There's already more than a few devs
>commented out of configs to account for lossage like this. Documenting
>every isa compatible device with a section that says "BTW: config'ing possible
>conflicting devices into your kernel may cause panics" doesn't add any real
>value. This should already be in isa(4) if anywhere and I see it's not so
>I'll gladly add a BUGS section detailing this fact...

No, what's to document is for the people who ran GENERIC kernels under 1.5
for whom sound always worked out of the box, but for whom it will not
work under 1.6 because of your change. That's the CHANGES entry.

As for isa(4) or wss(4), if there's some reason why the default choice
of interrupts for wss(4) tends to not work, then yes, we should
note that conflicts are extremely common, etc. etc. I was hoping
that you had a slightly strong justification than what I'm seeing
here, and that sage information about it could be included.

>Looking in GENERIC you already can find any number of things listed but
>commented out. Just in audio ess and aria for instance.

True (and unfortunate). However, removing devices that have been enabled
in GENERIC for a long time is somewhat different from devices that have
never been enabled by default. I don't know about ess, but the aria
is commented out because the probe give sfall hists (i.e. it is buggy).

>Uhh...This is ISA, in some cases it's simply not possible without checking
>jumpers to even know where something is configured.

I thought that the MAD16 had this information in an IO port. dev/isa/madreg.h
has:

  57  #define MAD_BASE        0xf8d
  58  #define MAD_NPORT       7
  59  
  60  #define MC1_PORT        0       /* SB address, CDROM interface type, joy
  60  stick */
  61  #define MC2_PORT        1       /* CDROM address, IRQ, DMA, plus OPL4 bi
  61  t */

I'm sure there's more to the interface than that, of course...

--jhawk