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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
22 matches
Mail list logo