>
>In message <200012200520.AAA26545@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? 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.

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

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

>>>Such a change should come along with an explanation in wss(4) about it,
>>>possibly in a BUGS section, as well as a CHANGES entry indicating
>>>that this took place.
>
>>GENERIC is what we install for any new build. The last thing you want that 
>>doing on the first reboot is panic'ing because the sound card has issues...
>>Most hardware you live with the risk, but in the case it's a sound card which
>>is to me, a secondary concern to making work.
>>
>>People treat GENERIC as the kitchen sink for all devices and all options
>>which is fine. However until it's not the default install kernel though it
>>really should boot on 99% of the systems out there.
>
>That's not the criterion we normally apply. If this is going to be
>a significant issue, we should create another kernel for these purposes.

Creating a baseline install kernel is not a bad thing, nor is a kitchen sink
one which lists all options. However they don't necessarily mix in cases
where you're dealing with legacy crap like ISA and having to know the exact
config for it up front.

>
>But I am skeptical that there is no good solution here. Like some way
>to detect the conflict and do something useful, or fail less violently?

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

James