Date: Fri, 09 Feb 2001 21:59:17 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: freebsd-alpha@FreeBSD.ORG Subject: Re: Nonsense IRQs in -current Message-ID: <20010209215917.A7855@gsmx07.alcatel.com.au> In-Reply-To: <20010209103917.B90937@gsmx07.alcatel.com.au>; from peter.jeremy@alcatel.com.au on Fri, Feb 09, 2001 at 10:39:18AM %2B1100 References: <20010209103917.B90937@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-Feb-09 10:39:18 +1100, Peter Jeremy <peter.jeremy@alcatel.com.au> wrote: >I've just upgraded a Multia from -stable to -current and the PCI >interrupts no longer make sense. dmesg shows: After much poking around in the kernel... In -stable, the Alpha interrupts are re-arranged in pci_read_device() immediately after the config registers are read. In -current, a new route_interrupt() method has been created. This method should be invoked via the alloc_resource() method for interrupt requests. In my Multia, pci_read_device() (invoked from from pci_add_children()) is reading initialised (!= 255) but incorrect intline values from the PCI device configuration registers. When the device attach() method invokes pci_alloc_resource(), intline!=255 so the PCIB_ROUTE_INTERRUPT() call is skipped - leaving an invalid IRQ value. In particular, dec_axppci_33_intr_route() is never called at all. I'm not sure what the correct fix is. I kludged it by just deleting the check for intline!=255 in pci_alloc_resource() - but that is a hack that just happens to work for me. I'm not sure whether this is a bug in the SRM, AXPpci/33 or LCA - which makes it difficult to work out where to fix it. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010209215917.A7855>