Date: Tue, 13 Apr 1999 09:15:42 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: "Gooderum, Mark" <mark@jumpweb.com> Cc: "'freebsd-alpha@freebsd.org'" <freebsd-alpha@freebsd.org> Subject: RE: FreeBSD Alpha and NICs Message-ID: <Pine.BSF.4.05.9904130912090.51054-100000@herring.nlsystems.com> In-Reply-To: <50C732FEDE87D211954300A024786203A6B2@archeron.good.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 Apr 1999, Gooderum, Mark wrote: > The saga continues... > > > -----Original Message----- > > From: Doug Rabson [mailto:dfr@nlsystems.com] > > Sent: Saturday, April 10, 1999 12:35 PM > > To: Gooderum, Mark > > Cc: 'freebsd-alpha@freebsd.org' > > Subject: Re: FreeBSD Alpha and NICs > > > > > > On Fri, 9 Apr 1999, Gooderum, Mark wrote: > > > >> ... > > > > I fixed a bug in subr_rman.c where more than two clients attempted to > > share a resource. Can you check that you have version 1.5 of > > subr_rman.c > > The 3/26 snapshot has V1.4, however, the copy of current I've been building > has V1.5. > > But I was stubborn and bored and got curious...first I went snooping and > found dec_axppci_33_intr_map() in dec_axppci_33.c. A minor fix to some > debugging code gave me the following information: > > ... > Probing for devices on PCI bus 0: > dec_axppci_33_intr_map: slot 6, pin A: pirq 3, reg = b0f0f0a > dec_axppci_33_intr_map: slot 6, pin A: mapped to line 11 > ncr0: <ncr 53c810 fast10 scsi> rev 0x01 int a irq 11 on pci0.6.0 > chip0: <Intel 82378ZB PCI to ISA bridge> rev 0x03 on pci0.7.0 > dec_axppci_33_intr_map: slot 8, pin A: pirq 2, reg = b0f0f0a > dec_axppci_33_intr_map: slot 8, pin A: mapped to line 15 > de0: <Digital 21040 Ethernet> rev 0x23 int a irq 15 on pci0.8.0 > de0: DEC 21040 [10Mb/s] pass 2.3 > de0: address 08:00:2b:e2:c7:eb > dec_axppci_33_intr_map: slot 11, pin A: pirq 0, reg = b0f0f0a > dec_axppci_33_intr_map: slot 11, pin A: mapped to line 10 > dec_axppci_33_intr_map: slot 12, pin A: pirq 1, reg = b0f0f0a > dec_axppci_33_intr_map: slot 12, pin A: mapped to line 15 > pn0: <82c168/82c169 PNIC 10/100BaseTX> rev 0x21 int a irq 15 on pci0.12.0 > > fatal kernel trap: > ... > > Tracing things out, each slot corresponds to one byte in the > SIO_PCIREG_PIRQ_RTCTRL PCI config register. The mapping of which slot to > which byte is based on some magic number (pirq) that is calculated based on > the slot number and the "intpin" PCI config value. (Whatever the magic is, > the 2100 machine code has it in common). > > BTW...the "mystery" device in slot 11 has a vendor ID of 0041011 and a rev > of 03800002 according to sniff_pci_bus in the SRM console, not sure what it > is, the builtin IDE interface? > > I got similar results with both a second DEC Ethernet and with a Netgear > card. > > The pirqreg value is 0x0b0f0f0a. Going by the bit logic and code, this > works out to IRQ 11 (0b) for ncr0, IRQ 15 for de0 and de1 and/or pn0, and > IRQ 10 for the mystery device in slot 11. > > Earlier I hacked kern_intr.c and pci_compat.c to gracefully return errors > all the way back to xx_attach()instead of falling through and dereferencing > NULL pointers. This allowed the box to boot but would cause a lockup (if > 2nd card another DEC card) or a panic (if 2nd card the Netgear card) which > sort of makes sense. > > So feeling really, really bored with what I should be working on... > > I modified dec_axppci_33_intr_map() with a rude hack (see below) to force > changing the the PCI/IRQ mapping config register to give the 2nd Ethernet > card a seperate IRQ, and viola, the system boots, the card probes, it can be > ifconfiged, etc. > > However, trying to use the card fails. Basically the arp never succeeds. I > haven't gone so far as to sniff to see if the packet is making it onto the > wire. The Netgear card gives an occaisional watchdog timer error, the DEC > based (21140) card gives nothing. Doing an ifconfig shows that the media > autosense for both cards worked properly (whether 10BaseT or 100BaseTX). So > the card on the original IRQ works and the remapped one doesn't quite. > > So, next step was to change the hack to force the IRQ on the builtin > interface instead of the 2nd interface. I did this on the 2nd card and it > seems to work, so again, the remapped card doesn't. So the card functions, > but my hack to rewrite the PCI config register isn't enough to change the > mapping. I made one more try w/forceing to IRQ 5 but gave a panic right > after the remapped interface was ifconfig'ed. > > So that's how far I am. I don't know if there are any references on the > Alpha and/or Multia architechure. Unfortunately there is no SRM analouge > for isacfg like pcicfg. > > Also I can't think of any elegant general work around, the system seems to > just plain come up with the cards configured to a shared IRQ - which FreeBSD > just doesn't tolerate. By the looks of it, your workaround modifications to the IRQ mapping haven't hit the right part of the mutlia hardware. The watchdog etc. symptoms sound exactly light missed interrupts. FreeBSD should support shared interrupts. Can I ask you to turn on RMAN_DEBUG in subr_rman.c to get some (extremely verbose) debugging logs of the irq resource allocation. I have a tarball of some mutlia hardware documentation if you are interested... -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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?Pine.BSF.4.05.9904130912090.51054-100000>