On Monday 24 July 2006 2:04 am, Naveen Mamindlapalli wrote:
> Thanks for your reply.
>
> I am doing FPGA testing of EHCI host controller which
> is under development.
>
> Even In standard Intel PC ( Intel 82801DB/DBM USB 2.0
> Enhanced Host Controller ) which is running
> Linux-2.6.14 , this code path is traversed some times
> but every thing seems ok ( no irq nobody cared
> messages ).
The issue is clearly the code you're loading into the FPGA;
you should fix that hardware race before it turns into real
silicon (assuming that's the intent).
> But In my case as soon as I entered this function with
> splinlock_irq_save , I am getting an EHCI interrupt
> with STS_IAA bit set and I am clearing the same bit in
> this function and now there are no status bits for
> indicating the occurence of that interrupt.So when I
> go back to ehci_irq after spinunlock_irq_save in
> ehci_watchdog , the following piece of code is
> executed.
>
> if (!status) { __/* irq sharing? */
> spin_unlock(&ehci->lock);
> return IRQ_NONE;
> }
So to restate: the problem is that your FPGA code is
issuing an IRQ when it shouldn't be. As if the IRQ
line is still held high even when none of the enabled
IRQ sources is still reporting the IRQ.
The issue is actually twofold. Not just the fact that
the IRQ is still triggered ... but also that the IAA
IRQ was delayed for so long that the watchdog fired.
> But copy is fine even with this problem.Does any
> memory leakage will happen
> with this problem in long run.
I can't see why there would be leakage.
- Dave
> Is there any harm if
> this problem is not fixed in the hardware.
>
> I have observed that in my PC , this interrupt is not
> coming when I am in ehci_watchdog function.
>
> Due to some problems while booting up the Linux-2.6.17
> , I am not able to do FPGA testing on the latest
> kernel.But codewise everything seems same with respect
> to asynchronous transfers.So I am expecting the same
> behaviour with this kernel also.
>
> Please give me some suggestion with respect to this
> problem.
>
> Thanks you very much,
> Naveen
>
> --- David Brownell <[EMAIL PROTECTED]> wrote:
>
> > From: David Brownell <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: irq nobody cared in EHCI - Linux-2.6.14
> > Date: Tue, 18 Jul 2006 14:46:02 -0700
> > CC: Naveen Mamindlapalli
> > <[EMAIL PROTECTED]>
> >
> > On Tuesday 18 July 2006 5:30 am, Naveen
> > Mamindlapalli wrote:
> > >
> > > Why ehci_watchdog is encountering the condition
> > > if(ehci->reclaim) & if (status * STS_IAA) only
> > some times.
> >
> > Because the silicon bug being worked around by the
> > watchdog doesn't
> > appear all the time. Whose EHCI silicon are you
> > using? (Note
> > that I'm assuming you mean "&" not "*" ... very
> > different.)
> >
> >
> > > CODE in ehci-hcd.c : ehci_watchdog function:
> > >
> >
> ------------------------------------------------------------------
> > > if (ehci->reclaim) {
> > > u32 status = readl (&ehci->regs->status);
> > > if (status & STS_IAA) {
> > >
> >
> -------------------------------------------------------------------
> > >
> > > I doubt why we should clear any interrupt status
> > bits in a function which is
> > > not an interrupt service routine.
> >
> > It's _status_ not specifically "interrupt" status
> > ... so it would be set
> > even if the IRQ were not enabled. And the silicon
> > bug is that STS_IAA
> > sometimes gets set without the IRQ triggering, even
> > if the IRQ is enabled,
> > leading to hangs -- unless the watchdog is there to
> > cause the IAA handling
> > to happen in those cases. (Seen reasonably often on
> > VIA hardware.)
> >
> >
> > > Can anybody give some suggestions on this.
> >
> > If you're getting the "nobody cared" that implies
> > your EHCI controller
> > has such a silicon problem, yes? It also implies
> > your code doesn't
> > match any recent version ... IRQ_NONE is never
> > returned.
> >
> >
> > USB issues like this are best brought up on the USB
> > list, since they're
> > not going to be ARM-specific. And as has been
> > noted, 2.6.14 is kind of
> > old ... try a current kernel. There seem to be some
> > glitches still in
> > the unlink paths, but none that show up on hardware
> > I have access to.
> >
> > - Dave
> >
> >
>
>
>
>
> __________________________________________________________
> Yahoo! India Answers: Share what you know. Learn something new
> http://in.answers.yahoo.com/
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> linux-usb-devel@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
