On Wed, 27 Nov 2002, M. Warner Losh wrote:
> Well, right now the following code is trying to force INTA#: .. > sp->putb(sp, PCIC_INT_GEN, /* Assume INTA# */ > (sp->getb(sp, PCIC_INT_GEN) & 0xF0) | 3); Which seems to cause the hang. Commenting this out will resort in the 'normal' timeout problem. Now as I understand it; the wiring on the board simply maps all outogoing INT pins A-D and the ISA pins to the same INTA# on the PCI bus. This seems a bit suspect to me; as INTA-D are active low/open drain type (or should be) and the ISA pin's are/should be of the active high ISA variety. Which seems mutually exclusive to me ? So can they be cross connected and yet still allow us to program the PCIC_INT_GEN register so that an IRQ gets through ? Secontly - So without the above being set; only the management IRQ for the PCIC actions gets through ? And not that of the card in the pcmcia slot. Once the PCIC is correctly programmed - both will come through through the same INTA pin (which is mapped to irq 9, 10 or 11) - where is the routing done to make sure that both the pcic driver and the relevant pcmcia driver sees the IRQ; or can one of the two accidentally 'claim' the pin and not pass on to the other ? Where is this done ? > This doesn't force the interrupt to be IRQ3, but rather tells the card > to use INTA#. The probe line for wi card should say irq N where N is > the same as the bridge's irq. Ack - it does. Dw. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
