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 INT
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 hamm
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 heav
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 heav
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 m
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 disabl
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 wil
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 aro
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
> > >> d
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_m
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().
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/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
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 MSI/INTx/
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()
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
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
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
>
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
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 handle
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 ha
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 handle
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 at
23 matches
Mail list logo
