Re: MSI interrupts and disable_irq

2007-10-17 Thread Manfred Spraul
Yinghai Lu wrote: Correct, but the overall point was that MSI-X conceptually conflicts with the existing lockless disable_irq() schedule, which was written when there was a one-one relationship between irq, PCI device, and work to be done. at this point, nic in mcp55 is using msi or

Re: MSI interrupts and disable_irq

2007-10-16 Thread Yinghai Lu
On 10/15/07, Jeff Garzik [EMAIL PROTECTED] wrote: Manfred Spraul wrote: Jeff Garzik wrote: I think the scenario you outline is an illustration of the approach's fragility: disable_irq() is a heavy hammer that originated with INTx, and it relies on a chip-specific disable method

Re: MSI interrupts and disable_irq

2007-10-16 Thread Jeff Garzik
Yinghai Lu wrote: On 10/15/07, Jeff Garzik [EMAIL PROTECTED] wrote: Manfred Spraul wrote: Jeff Garzik wrote: I think the scenario you outline is an illustration of the approach's fragility: disable_irq() is a heavy hammer that originated with INTx, and it relies on a chip-specific disable

Re: MSI interrupts and disable_irq

2007-10-16 Thread Yinghai Lu
On 10/16/07, Jeff Garzik [EMAIL PROTECTED] wrote: Yinghai Lu wrote: On 10/15/07, Jeff Garzik [EMAIL PROTECTED] wrote: Manfred Spraul wrote: Jeff Garzik wrote: I think the scenario you outline is an illustration of the approach's fragility: disable_irq() is a heavy hammer that

Re: MSI interrupts and disable_irq

2007-10-16 Thread Yinghai Lu
On 10/16/07, Jeff Garzik [EMAIL PROTECTED] wrote: Yinghai Lu wrote: On 10/15/07, Jeff Garzik [EMAIL PROTECTED] wrote: Manfred Spraul wrote: Jeff Garzik wrote: I think the scenario you outline is an illustration of the approach's fragility: disable_irq() is a heavy hammer that

Re: MSI interrupts and disable_irq

2007-10-16 Thread Jeff Garzik
Yinghai Lu wrote: On 10/16/07, Jeff Garzik [EMAIL PROTECTED] wrote: Yinghai Lu wrote: On 10/15/07, Jeff Garzik [EMAIL PROTECTED] wrote: Manfred Spraul wrote: Jeff Garzik wrote: I think the scenario you outline is an illustration of the approach's fragility: disable_irq() is a heavy hammer

Re: MSI interrupts and disable_irq

2007-10-15 Thread Jeff Garzik
Manfred Spraul wrote: Jeff Garzik wrote: I think the scenario you outline is an illustration of the approach's fragility: disable_irq() is a heavy hammer that originated with INTx, and it relies on a chip-specific disable method (kernel/irq/manage.c) that practically guarantees behavior

Re: MSI interrupts and disable_irq

2007-10-14 Thread Yinghai Lu
On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote: Jeff Garzik wrote: I think the scenario you outline is an illustration of the approach's fragility: disable_irq() is a heavy hammer that originated with INTx, and it relies on a chip-specific disable method (kernel/irq/manage.c) that

Re: MSI interrupts and disable_irq

2007-10-14 Thread Manfred Spraul
Yinghai Lu wrote: On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote: Someone around with a MSI capable board? The forcedeth driver does dev-irq = pci_dev-irq in nv_probe(), especially before pci_enable_msi(). Does pci_enable_msi() change pci_dev-irq? Then we would disable the wrong

Re: MSI interrupts and disable_irq

2007-10-14 Thread Yinghai Lu
On 10/14/07, Manfred Spraul [EMAIL PROTECTED] wrote: Yinghai Lu wrote: On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote: Someone around with a MSI capable board? The forcedeth driver does dev-irq = pci_dev-irq in nv_probe(), especially before pci_enable_msi(). Does

Re: MSI interrupts and disable_irq

2007-10-14 Thread Benjamin Herrenschmidt
On Sun, 2007-10-14 at 09:15 +0200, Manfred Spraul wrote: Yinghai Lu wrote: On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote: Someone around with a MSI capable board? The forcedeth driver does dev-irq = pci_dev-irq in nv_probe(), especially before pci_enable_msi(). Does

Re: MSI interrupts and disable_irq

2007-10-14 Thread Yinghai Lu
On 10/14/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Sun, 2007-10-14 at 09:15 +0200, Manfred Spraul wrote: Yinghai Lu wrote: On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote: Someone around with a MSI capable board? The forcedeth driver does dev-irq = pci_dev-irq

Re: MSI interrupts and disable_irq

2007-10-14 Thread Benjamin Herrenschmidt
On Sun, 2007-10-14 at 16:15 -0700, Yinghai Lu wrote: On 10/14/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Sun, 2007-10-14 at 09:15 +0200, Manfred Spraul wrote: Yinghai Lu wrote: On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote: Someone around with a MSI capable

Re: MSI interrupts and disable_irq

2007-10-13 Thread Manfred Spraul
Jeff Garzik wrote: I think the scenario you outline is an illustration of the approach's fragility: disable_irq() is a heavy hammer that originated with INTx, and it relies on a chip-specific disable method (kernel/irq/manage.c) that practically guarantees behavior will vary across

Re: MSI interrupts and disable_irq

2007-10-07 Thread Manfred Spraul
Jeff Garzik wrote: Interested parties should try the forcedeth patches I just posted :) The patches look good, but I would still prefer to understand why the current implementation causes crashes before rewriting everything. I've just noticed that netpoll_send_skb() calls -hard_start_xmit()

Re: MSI interrupts and disable_irq

2007-10-06 Thread Yinghai Lu
On 10/5/07, Eric W. Biederman [EMAIL PROTECTED] wrote: Stephen Hemminger [EMAIL PROTECTED] writes: On Fri, 28 Sep 2007 22:47:16 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Ayaz Abdulla wrote: I am trying to track down a forcedeth driver issue described by bug 9047 in bugzilla

Re: MSI interrupts and disable_irq

2007-10-06 Thread Yinghai Lu
On 9/28/07, Jeff Garzik [EMAIL PROTECTED] wrote: Ayaz Abdulla wrote: I am trying to track down a forcedeth driver issue described by bug 9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy load). I added a patch to synchronize the timer handlers so that one handler

Re: MSI interrupts and disable_irq

2007-10-05 Thread Eric W. Biederman
Stephen Hemminger [EMAIL PROTECTED] writes: On Fri, 28 Sep 2007 22:47:16 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Ayaz Abdulla wrote: I am trying to track down a forcedeth driver issue described by bug 9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy load). I

Re: MSI interrupts and disable_irq

2007-10-02 Thread Manfred Spraul
Ayaz Abdulla wrote: I am trying to track down a forcedeth driver issue described by bug 9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy load). I added a patch to synchronize the timer handlers so that one handler doesn't accidently enable the IRQ while another timer

MSI interrupts and disable_irq

2007-09-28 Thread Ayaz Abdulla
I am trying to track down a forcedeth driver issue described by bug 9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy load). I added a patch to synchronize the timer handlers so that one handler doesn't accidently enable the IRQ while another timer handler is running (see

Re: MSI interrupts and disable_irq

2007-09-28 Thread Jeff Garzik
Ayaz Abdulla wrote: I am trying to track down a forcedeth driver issue described by bug 9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy load). I added a patch to synchronize the timer handlers so that one handler doesn't accidently enable the IRQ while another timer

Re: MSI interrupts and disable_irq

2007-09-28 Thread Stephen Hemminger
On Fri, 28 Sep 2007 22:47:16 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Ayaz Abdulla wrote: I am trying to track down a forcedeth driver issue described by bug 9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy load). I added a patch to synchronize the timer handlers