>>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.

Let me walk you through it then.

Most devices in the system these days get auto-assigned by the bios in some
way (pci, pnpbios,etc). The bios choses anywhere it wants for the most part
that doesn't conflict and in my case irq 10 doesn't conflict because nothing
else got assigned there, just that GENERIC hard coded something there.

These devices that auto-config of course we query for and attach where they 
tell us they've been configured to work at. For legacy ISA devices this isn't
possible so a large percentage of them exist in the config file as

wss0   at isa? port 0x530 irq 10 drq 0 drq2 1  # Windows Sound System

So, there's no choice there in the current config structure. If it finds a 
valid match at i/o 0x530 and discovers a wss it'll try and establish an
interrupt handler at irq 10. The current interrupt stuff panics if you try
and share interrupts with level and edge connected stuff on isa:

        case IST_EDGE:
        case IST_LEVEL:
                if (type == intrtype[irq])
                        break;
        case IST_PULSE:
                if (type != IST_NONE)
                        panic("intr_establish: irq %d can't share %s with %s",
                              irq,
                              isa_intr_typename(intrtype[irq]),
                              isa_intr_typename(type));
                break;

Basically once you get into isa_intr_establish there's no way to gracefully
exit back with an error in today's scheme. Probably not the best overall
working model since this comes up in a number of cases.

I'm not saying comment out anything that might come up in this scenario, but
currently I find the idea of a sound card not config'ing vs. a panic on first
install to be a reasonable tradeoff. 

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

Read above.

>
>[ 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. ]

No, this is just the standard "we had to put something in the irq section so
10 was chosen and that's conflicting".

>
>>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.

Actaully it would only not work in the legacy isa case. I didn't touch any
other wss entries in the file so the isapnp one would still work.

>
>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.

In a lot of cases irq 10 being chosen by pci bioses isn't that unusual. 
It has no idea you think there's a wss there (there isn't..In this machine's
case it's on irq 9 so the config is just plain wrong), so it happily assigned
something there.

>
>>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).

Actually checking, there are 35 cases of isa devices (now) commented out
in GENERIC for one reason or another. Note, that *none* of these have any
comments in the config file stating why and a quick perusal and some man pages
also shows no additional documentation. Documentation for configuring a 
kernel should include warnings about double assigning irq's, etc but otherwise
I'm not seeing any current model to work from.

>
>>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...

Actually let me look into that. If I can get the wss to just auto config itself
that'll be simpler. 

James