Date: Tue, 26 Oct 1999 02:18:19 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gallatin@cs.duke.edu (Andrew Gallatin) Cc: tlambert@primenet.com, dfr@nlsystems.com, alpha@FreeBSD.ORG Subject: Re: small fix for irq mappig probelm Message-ID: <199910260218.TAA25849@usr06.primenet.com> In-Reply-To: <199910260051.UAA09280@storm.cs.duke.edu> from "Andrew Gallatin" at Oct 25, 99 08:51:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > > de0: <Digital 21143 Fast Ethernet> irq 0 at device 3.0 on pci0 > > > pci_map_int: can't allocate interrupt > > > > > > > > > The appended patch fixes it, but I am unsure it is correct. Can you > > > approve it? > > > > Same thing on some Intel motherboards, FWIW. SMP seems to be the > > way to fix it; perhaps we could do whatever the equivalent is on > > Alpha? > > Huh? I'm not talking about running out of irqs, I'm talking about > having a valid inline which happens to be zero. My point was more toward virtualizing the interrupts via an APIC would be an acceptable workaround, if the system had APIC's. I bet Alphas don't, but they have to have some type of MP coherency and "virtual wire" model that might be there in all Alphas, that could do in a pinch. > (Most) Alphas aren't limited to 16 irqs like PCs, even without SMP > support. Many support up to 64 irqs. Starting at 0 & including 0. > > Having 0 as a valid intline is the problem. My patch assumes that an > intpin should never be 0. Is this true? Julian Elisher would be a good person to ask about this on the PC hadware side of things, since he dealt with all of the Cyrix Media GX chipset problems for Whistle just recently. ...OK, I'm back from asking him. 8-). The answer is that zero isn't allowed under any circumstances, and that you are probably missing a mapping somewhere in the PCI chipset configuration. According to: PCI System Architecture Tom Shanley, Don Anserson MindShare, Inc. ISBN: 0-201-40993-3 Chapter 17: Configuration Registers ... Interrupt Pin Register The read-only interrupt pin register defines which of the four PCI interrupt request pins, INTA# through INTD#, a PCI functional device is connected to. The values one through four correspond to PCI interrupt request lines INTA# through INTD#. A return value of zero indicates that the device doesn't use interrupts. For additional information, refer to the chapter entitled "Interrupt- Related Issues". ... Julian says: The BIOS is supposed to twiddle with the registers on the board, and some number is supposed to show up there. Then after the number shows up there, the BIOS is supposed to read that number back from the IPR, then using its own internal knowledge of the traces on the motherboard, map that number into an ICU interrupt number. It then is supposed to write than number into the Interrupt Line Register. Then the OS is supposed to be able to independantly read the ILR, and get the right interrupt for the CPU to associate with the driver (the ILR is not attached to any hardware, its sole purpose is to act as an IPC mechanism between the BIOS and the OS). So, it looks like your BIOS is not setting things up right; Julian also says: The BIOS on the motherboard is responsible for the mapping IPR->ILR mapping, and the BIOS code stored on the card is responsible for twiddling the bits in a device dependent fashion in order to make the value turn up in the IPR. The BIOS on the motherboard is responsible for the BIOS code on the card, which of INTA# through INTD# are avaiable on that slot, and then the card gets to grab one (or more) to play with. On a lot of motherboards, all the Interrupt pin lines, INTA# thorugh INTD#, are all wired together on most motherboards, so you only have 4 lines coming from the PCI to the interrupt controller. This makes the mapping discussed above rather simple, which is why the PCI BIOS' give you an option to hook PCI interrupts lines to some specific interrupt. But since not all motherboards are wired this way, particularly some of the high performance ones that seperate the interrupts so that they are not shared (think SMP), the mapping process is necessary for full PCI compliance. Well, pretty clearly, the BIOS on the card is not being run; big surprise, since it's x86 code, and your processor is an Alpha. 8-(. I think you will need to deal with the card specific setup directly, as if you were the BIOS on the card. Generally, the IPR is not writeable, but there is some other register on the card, which, when written, lets you change the value visible in the IPR. Well, we all knew that there would be some BIOS arrows to take in the back over the non-x86 platforms. It might be useful to look at what NetBSD does to deal with the PCI issues over on their side of the fence; they've had to deal with this on both their Alpha and PowerPC ports, so they probably have a generic way of doing things. I believe that the DEC approach was to run the x86 code in an emulator in the firmware; this was also the approach taken on the Motorolla PowerStack (PowerPC) systems. Some of the later DEC systems "knew" what hardware was "allowed" to be installed; these are generally the ones that twiddle the hardware directly through promiscuous knowledge of the hardware, and they can (usually) be identified by whether the SRM is small enough to fit in the same firmware as the "AlphaBIOS" of "ARC" code. It may be that your firmware is broken or the wrong version, or just doesn't have this code... you might want to look at what is supposed to be happening here, according to CGD's documents for Alpha that he collected during the NetBSD port. Anyway, hope that gives you enough from the PC side of the fence that you can get this problem solved the right way. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199910260218.TAA25849>