Re: irunning, width in bits.
What about shared interrupts? How are they going to be treated? With the spl leaving the arena it somehow looks feasible to run one interrupt source on two different threads if there are two pieces of hardware attached to the same interrupt line. From what I understood from dfr, when switching away from an interrupt handler it is converted into a full thread. When the second piece of hardware fires an interrupt it could then run at the same time. I thought of this almost immediately - it's a bad idea though because it makes it hard to determine when to EOI an interrupt. If you expect to perform significant processing in your interrupt handler, you should consider a taskq. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: irunning, width in bits.
From what I understood from dfr, when switching away from an interrupt handler it is converted into a full thread. When the second piece of hardware fires an interrupt it could then run at the same time. I thought of this almost immediately - it's a bad idea though because it makes it hard to determine when to EOI an interrupt. If you expect to perform significant processing in your interrupt handler, you should consider a taskq. Right. It would be nice however to not have to go through the trouble of moving things onto different interrupts. Current BIOS's do not quite let you decide on which interrupt you would like to have assigned to the various cards. It will spread them in some way, but that might not spread the two high interrupt count cards onto separate interrupts. You have to move the hardware around in the slots to get things sorted in some cases. I guess that the perfect solution is to be able to hardwire the PCI irqs in some way once FreeBSD is doing the PnP resource allocation. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: irunning, width in bits.
On Mon, 26 Jun 2000 11:29:39 +0100 (BST), Nick Hibma [EMAIL PROTECTED] said: I guess that the perfect solution is to be able to hardwire the PCI irqs in some way once FreeBSD is doing the PnP resource allocation. On typical non-SMP motherboards, the PCI IRQs are hard-wired on the motherboard. That is to say, INTA of slot 13 is wire-OR'd with INTB of slot 14, is wire-OR'd with INTC of slot 15, is wire-OR'd with INTD of slot 16, and oh, yeah, is also wire-OR'd with INTA of every on-motherboard device. SMP motherboards tend to be significantly better in this regard. The PCI BIOS includes a function which gives you the map of how interrupts are wired together. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
irunning, width in bits.
What about shared interrupts? How are they going to be treated? With the spl leaving the arena it somehow looks feasible to run one interrupt source on two different threads if there are two pieces of hardware attached to the same interrupt line. From what I understood from dfr, when switching away from an interrupt handler it is converted into a full thread. When the second piece of hardware fires an interrupt it could then run at the same time. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: irunning, width in bits.
(Moving this to freebsd-smp, Bcc'ing current) :What about shared interrupts? How are they going to be treated? With the :spl leaving the arena it somehow looks feasible to run one interrupt :source on two different threads if there are two pieces of hardware :attached to the same interrupt line. : :From what I understood from dfr, when switching away from an interrupt :handler it is converted into a full thread. When the second piece of :hardware fires an interrupt it could then run at the same time. : :Nick :-- :[EMAIL PROTECTED] This came up at the meeting and the conclusion was that shared interrupts would run serially. That is, each 'bit' in the cpl (spl*(), also represented by ipending, the vector table dispatch, and so forth) would be treated as a single interrupt thread. If there are N interrupts hanging off that IRQ, then each of the N would be run serially from a single interrupt thread. This also came up a few months ago, you can probably find the discussion in the archives. What it comes down to is complexity and convenience. In almost all systems it is possible to rearrange the PCI boards such that you do not have two critical interrupts on the same IRQ. We are not precluding being able to schedule shared interrupts separately, but if we are going to do it it will probably be much later when things are more stable and not now. The KISS principle applies here. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
