On Mon, 27 Dec 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Peter Wemm writes:
> : Just as a BTW, dfr and sos are exchanging patches right now (and have been
> : for quite a few days) that happen to fix the inthand_add() stuff.
>
> This may also help the pccard code cases which I ha
In message <[EMAIL PROTECTED]> Peter Wemm writes:
: Just as a BTW, dfr and sos are exchanging patches right now (and have been
: for quite a few days) that happen to fix the inthand_add() stuff.
This may also help the pccard code cases which I have floating around.
Warner
To Unsubscribe: send
Soren Schmidt wrote:
> It seems Garrett Wollman wrote:
> > <
said:
> >
> > > If you looked at the code, you would see that the ata driver only uses
> > > this ugly method when we are dealing with the standard primary &
> > > secondary controller which are bound to specific addresses and int
On Wed, 22 Dec 1999, Soren Schmidt wrote:
> It seems Garrett Wollman wrote:
> > < said:
> >
> > > If you looked at the code, you would see that the ata driver only uses
> > > this ugly method when we are dealing with the standard primary &
> > > secondary controller which are bound to specific
It seems Garrett Wollman wrote:
> < said:
>
> > If you looked at the code, you would see that the ata driver only uses
> > this ugly method when we are dealing with the standard primary &
> > secondary controller which are bound to specific addresses and interrupts.
> > Those are not configurabl
< said:
> If you looked at the code, you would see that the ata driver only uses
> this ugly method when we are dealing with the standard primary &
> secondary controller which are bound to specific addresses and interrupts.
> Those are not configurable.
That's why the resource manager allows y
It seems Bill Paul wrote:
[snip snap]
> I don't want to sound like an ungrateful wretch, unduly criticizing
> someone else's code, especially at so late a date, but there are some
> other things that just seem like they really shouldn't be there:
We've got used to it, on with matters...
> -
In an earlier post on -hackers, I mentioned that attempting to kldload the
usb.ko module after the kernel had booted would panic the system. So far
I've managed to track this problem all the way down down to
sys/i386/isa/intr_machdep.c:add_intrdesc(). The system crashes when the
uhci_pci module tr
