Re: MSI interrupts and disable_irq

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yinghai Lu wrote:
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
doesn't accidently enable the IRQ while another timer handler is running
(see attachment 'Add timer lock' in bug report) and for other processing
protection.

However, the system still had an Oops. So I added a lock around the
nv_rx_process_optimized() and the Oops has not happened (see attachment
'New patch for locking' in bug report). This would imply a
synchronization issue. However, the only callers of that function are
the IRQ handler and the timer handlers (in non-NAPI case). The timer
handlers  use disable_irq so that the IRQ handler does not contend with
them. It looks as if disable_irq is not working properly.

This issue repros only with MSI interrupt and not legacy INTx
interrupts. Any ideas?
(added linux-kernel to CC, since I think it's more of a general kernel
issue)

I wonder if the race is between soft_timer for nv_do_nic_poll from
different CPUs

Interested parties should try the forcedeth patches I just posted :)

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux