On Tue, 6 Jan 2004, Bernd Walter wrote: > On Tue, Jan 06, 2004 at 12:39:42AM +0100, Bernd Walter wrote: > > On Mon, Jan 05, 2004 at 04:33:45PM -0700, M. Warner Losh wrote: > > > In message: <20040105233138.GR17023_at_cicely12.cicely.de> > > > Bernd Walter <ticso_at_cicely12.cicely.de> writes: > > > : On Mon, Jan 05, 2004 at 04:24:27PM -0700, M. Warner Losh wrote: > > > : > In message: <20040105231533.GQ17023_at_cicely12.cicely.de> > > > : > Bernd Walter <ticso_at_cicely12.cicely.de> writes: > > > : > : The point is that it shouldn't take an IRQ for PCI which is configured > > > : > : for an ISA device in device.hints. > > > : > > > > : > We don't do that. > > > : > > > : We do! > > > : > > > : /boot/device.hints: > > > : hint.sio.0.irq="4" > > > : > > > : pci_cfgintr_virgin: using routable interrupt 4 > > > : pci_cfgintr: 0:4 INTD routed to irq 4 > > > > > > Ah, I see what you are saying. That would be hard to implement. Presumably pci is configured first, so the isa hint is ignored. > After rethinking - it wouldn't be a good idea either, because > GENERIC.hints would block to many possible IRQs :( > Too bad that ISA components have to be attached after PCI. Hints (including configurations read from the BIOS) should be mostly just hints, and accidental ordering of the probes should have no effect on which hint is preferred. Accidental ordering also causes longstanding problems for configuring fast interrupts -- it is not know at bus_setup_intr() time whether an interrupt can be fast, since subsequent bus_setup_intr()'s on the same irq may require it to be non fast. Drivers could handle this by delaying bus_setup_intr() until the device is active, but most don't (exception for a non-fast intr: lpt repeats bus_setup_intr() on every write()!), but they shouldn't have to. Even this is inadequate if devices are attached after boot time (other devices that use the same interrupt may be active, and the interrupt may need significant reorganization). BruceReceived on Mon Jan 05 2004 - 23:26:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:36 UTC