On Monday 11 October 2004 7:42 am, Olaf Hering wrote:
> On Thu, Sep 02, David Brownell wrote:
>
> > Can you try this patch? Ideally the entire first scan
> > would be aborted and the second scan started.
> > But it's a lot simpler to just not start the second one,
> > and trust the I/O watchdog
On Thu, Sep 02, David Brownell wrote:
> On Thursday 02 September 2004 3:24 pm, Olaf Hering wrote:
>
> > Maybe the call chain is something like this:
> >
> > ehci_irq
> > spin_lock (&ehci->lock)
> > ehci_work ehci_watchdog
> > end_unlink_async
> >
* David Brownell <[EMAIL PROTECTED]> [2004-09-03]:
>
> Great to know! But I don't think that'll explain Richard's
> problem, unless his new arch was SMP or his early port
> work didn't quite handle the IRQ/timer interaction right.
At the time we were seeing this, it was quite early into our port
On Fri, Sep 03, David Brownell wrote:
> On Friday 03 September 2004 5:00 am, Olaf Hering wrote:
> > On Thu, Sep 02, David Brownell wrote:
>
> > > Can you try this patch? Ideally the entire first scan
> > > would be aborted and the second scan started.
> > > But it's a lot simpler to just not s
On Friday 03 September 2004 5:00 am, Olaf Hering wrote:
> On Thu, Sep 02, David Brownell wrote:
> > Can you try this patch? Ideally the entire first scan
> > would be aborted and the second scan started.
> > But it's a lot simpler to just not start the second one,
> > and trust the I/O watchdog
On Thu, Sep 02, David Brownell wrote:
> On Wednesday 01 September 2004 5:15 am, Olaf Hering wrote:
>
> > I wonder, why has the ->dummy ehci_qtd struct no initialized list
> > pointers?
>
> ehci_qtd_init() initializes qtd->qtd_list ... or do you mean
> instead "why is it not a member of some li
On Thu, Sep 02, David Brownell wrote:
> On Thursday 02 September 2004 3:24 pm, Olaf Hering wrote:
>
> > Maybe the call chain is something like this:
> >
> > ehci_irq
> > spin_lock (&ehci->lock)
> > ehci_work ehci_watchdog
> > end_unlink_async
> >
On Thu, Sep 02, Olaf Hering wrote:
> Sep 2 20:38:59 banana kernel: ehci_hcd 0001:02:0b.2: irq status 0001 INT
> Sep 2 20:38:59 banana kernel: ehci_irq(807) dmesg(5121):c1,j4294737421
> Sep 2 20:38:59 banana kernel: qh_completions(246) dmesg(5121):c1,j4294737422 enter
> cfc5f330 c0
On Wednesday 01 September 2004 5:15 am, Olaf Hering wrote:
> I wonder, why has the ->dummy ehci_qtd struct no initialized list
> pointers?
ehci_qtd_init() initializes qtd->qtd_list ... or do you mean
instead "why is it not a member of some list"?
The code was originally written so qh->qtd_list
On Thursday 02 September 2004 3:24 pm, Olaf Hering wrote:
> Maybe the call chain is something like this:
>
> ehci_irq
> spin_lock (&ehci->lock)
> ehci_work ehci_watchdog
> end_unlink_async
> qh_completions
> ehci_urb_done
> spin_unl
On Thursday 02 September 2004 1:27 pm, Olaf Hering wrote:
> On Thu, Sep 02, David Brownell wrote:
>
> > On Thursday 02 September 2004 12:30 pm, Olaf Hering wrote:
> >
> > > Here is a little debug output attached, generated with this patch.
> > > It shows that qh 0xcfca0140 is passed to q
On Thu, Sep 02, David Brownell wrote:
> On Thursday 02 September 2004 1:27 pm, Olaf Hering wrote:
> > On Thu, Sep 02, David Brownell wrote:
> >
> > > On Thursday 02 September 2004 12:30 pm, Olaf Hering wrote:
> > >
> > > > Here is a little debug output attached, generated with this patch.
> >
On Thu, Sep 02, David Brownell wrote:
> On Thursday 02 September 2004 12:30 pm, Olaf Hering wrote:
>
> > Here is a little debug output attached, generated with this patch.
> > It shows that qh 0xcfca0140 is passed to qh_completions on both
> > cpus.
>
> Well now, that'd be evil. Maybe
On Thursday 02 September 2004 12:30 pm, Olaf Hering wrote:
> Here is a little debug output attached, generated with this patch.
> It shows that qh 0xcfca0140 is passed to qh_completions on both
> cpus.
Well now, that'd be evil. Maybe there needs to be a flag making sure
that ehci_work()
On Thu, Sep 02, David Brownell wrote:
> On Thursday 02 September 2004 11:06 am, Olaf Hering wrote:
> >
> > > It dereferences an already freed struct list_head after a few minutes.
> > > I will try to reproduce it on a dual G5.
> >
> > unmodified 2.6.9-rc1-bk9 dies after a few seconds on the G5.
On Thursday 02 September 2004 11:06 am, Olaf Hering wrote:
>
> > It dereferences an already freed struct list_head after a few minutes.
> > I will try to reproduce it on a dual G5.
>
> unmodified 2.6.9-rc1-bk9 dies after a few seconds on the G5.
> I wonder, what protects the list operations in qh
> It dereferences an already freed struct list_head after a few minutes.
> I will try to reproduce it on a dual G5.
unmodified 2.6.9-rc1-bk9 dies after a few seconds on the G5.
I wonder, what protects the list operations in qh_completions()? Its
called from a few places, but I dont see much locki
On Wed, Sep 01, Olaf Hering wrote:
> I tried this patch, it leads to a hard crash after 1 minute.
> Very strange...
>
> --- ./drivers/usb/host/ehci-q.c.kaputt2004-08-31 14:21:51.794068000 +0200
> +++ ./drivers/usb/host/ehci-q.c 2004-09-01 14:17:10.732679974 +0200
> @@ -857,7 +857,
On Thu, Aug 12, David Brownell wrote:
> On Thursday 12 August 2004 4:26 am, Olaf Hering wrote:
> > On Tue, Jun 15, David Brownell wrote:
> >
> > > Richard Curnow wrote:
> > > >
> > > >One problem I'm hitting is in EHCI, I was wondering if you had any ideas
> > > >as to what I could start lookin
On Thu, Aug 12, David Brownell wrote:
> On Thursday 12 August 2004 4:26 am, Olaf Hering wrote:
> > On Tue, Jun 15, David Brownell wrote:
> >
> > > Richard Curnow wrote:
> > > >
> > > >One problem I'm hitting is in EHCI, I was wondering if you had any ideas
> > > >as to what I could start lookin
On Thursday 12 August 2004 4:26 am, Olaf Hering wrote:
> On Tue, Jun 15, David Brownell wrote:
>
> > Richard Curnow wrote:
> > >
> > >One problem I'm hitting is in EHCI, I was wondering if you had any ideas
> > >as to what I could start looking at, annotating etc to debug this. The
> > >problem
On Tue, Jun 15, David Brownell wrote:
> Richard Curnow wrote:
> >
> >One problem I'm hitting is in EHCI, I was wondering if you had any ideas
> >as to what I could start looking at, annotating etc to debug this. The
> >problem seems to be here:
> >
> >static inline void list_del(struct list_head
22 matches
Mail list logo
