Subject: Re: Install failure on 1.5E
To: Nathan J. Williams <nathanw@MIT.EDU>
From: None <email@example.com>
Date: 09/17/2000 02:31:13
>> 2. If not, why install it as the basic kernel? The default kernel from an
>> install should work out of the box on as much as reasonably possible IMO.
>See above. "Work" is a vector, not a scalar parameter.
Ok, but Joe end user installing netbsd and then having it panic on the way
up is gonna give up real quick.
Yes I can boot back off floppy, mount the system hard drives and compile
a new kernel. Even though I know how, this would seriously put even me
off and I've been running *bsd and/or linux since '92 or so.
Why not put the INSTALL kernel down (since if that one has issues they
didn't get real far) and also put /netbsd.GENERIC down? Then on the first
boot if things aren't configured (ala /etc) print a banner out suggesting
a recompile. At least then there's hopefully at least one working kernel I
can use the bootloader to get at.
>To sum up: Devices which can be prevented from generating interrupts
>should, ideally, be able to notice this conflict in their attach
>routine and fail gracefully. The interrupt-handler establishing code
>may not be up to that task, and not all devices will let you do that.
Well, the problem here with wss is it's hardcoded in all the configs for
i/o,irq,drq. While wssfind will bail if the drq is taken there's no choice on
the irq side. Since it's not unreasonable that irq 10 might be taken (in my
case the PCI bios assigned it to the de card) and wss somewhere else (on a
multia it's irq 9). At a minimum wss should either come out of GENERIC or at
least someone write up a map of what will conflict in a standard GENERIC
boot (aic and wds for instance I can see plus some ethernet card combo's).
Is there an easy way to check if the interrupt is already taken before
calling the handler establishment routine? I know from my brief experience
so far the drq maps can be checked but I hadn't come across irq routines.