Can you see if this patch (against 2.5.44) helps get rid of those
"bad entry" problems (and siblings)?
Basically it just simplifies some logic that was trying to be
too clever about writing the "next TD" entry the hardware uses.
- Dave
--- ./drivers/usb-dist/host/ohci-q.cFri Oct 18 21:45:02
> Which included some memory trashing that was clearly not caused by OHCI,
> since it also showed up without OHCI having been loaded. Do you have
> any memory trashing symptoms like that?
Nothing at all.
> Alternatively, and not dissimilar, a TD is getting freed a bit early,
> and then when it
On Tuesday 15 October 2002 08:31, David Brownell wrote:
> Interesting ... towards the end your kernel messages had lots of messages
> among which were periodic:
>
>Oct 15 03:42:32 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad
> entry fcac7c1 Oct 15 03:42:35 hal9 kernel: drivers/usb/host
Interesting ... towards the end your kernel messages had lots of messages
among which were periodic:
Oct 15 03:42:32 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1
Oct 15 03:42:35 hal9 kernel: drivers/usb/host/ohci-q.c: 00:02.0 bad entry fcac7c1
Oct 15 03:42:41 hal9
On Tuesday 15 October 2002 01:02, Martin Diehl wrote:
> I't looks to me like some kind of donelist corruption but might be td
> hashbin or pci_pool as well. Maybe the output below would tell you
> something. It was obtained during re-enumeration after firmware download
> where a firmware bug caus
> Your patch was a very successful shot.
>
> I prepared to running through different scenarious but the system booted
> instantaneously, so i ran a little out of steam, and i'm wondering how to
> proceed best. Got the system up and running with nearly a dozen usb devices
> attached though i d
David,
Your patch was a very successful shot.
I prepared to running through different scenarious but the system booted
instantaneously, so i ran a little out of steam, and i'm wondering how to
proceed best. Got the system up and running with nearly a dozen usb devices
attached though i didn't
>>>But I believe the backtrace points to the bad context path, not the root
>>>cause which triggered the HC halt.
>>
>>Likely. If you can get me more information on that, let me know.
>
>
> I think it's somehow related to the td processing. I'm getting a lot
> of "bad entry" messages from ohci
On Mon, 14 Oct 2002, David Brownell wrote:
> > But I believe the backtrace points to the bad context path, not the root
> > cause which triggered the HC halt.
>
> Likely. If you can get me more information on that, let me know.
I think it's somehow related to the td processing. I'm getting a
> Partial fix - I'm now OK with the USB test driver loaded.
>
> However, I'm missing the second host controller (00:01.3) - it doesn't appear
> to be recognised in /proc/bus/usb/devices, nor does it appear to be init'ed
> in the boot logs:
Yes, the presence of one bug of that type (not handli
> Well, I've seen a few of this (or something appearing similar). In my case
> it was triggered by an EP0 Control transfer which timed out (firmware bug).
> This caused OHCI controller halts finally looping in a pretty unfriendly
> mode down below ohci_stop() continously hitting the "blocking do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 14 Oct 2002 14:37, David Brownell wrote:
> > I'm not getting lockups, but I am seeing this problem. It looks like the
> > device/driver "rescan" is dying somewhere.
>
> This patch addressed at least some of those problems for me.
> The driver
On Sun, 13 Oct 2002, David Brownell wrote:
> > I can complete the boot process if i plug out anything from the host, and
> > plugging in the first hub with out any devices attached does not cause a
> > lock-up then anymore. It does not make anything available either, though
>
> The good news i
>>I'm still taking a look, but maybe Lars is seeing symptoms of more that one
>>problem.
>
> Grr.
>
> usbtest -not sure what the problem is, but turning it off helped a lot.
Try that patch I just sent by.
---
This sf.net email is sponsor
> I'm not getting lockups, but I am seeing this problem. It looks like the
> device/driver "rescan" is dying somewhere.
This patch addressed at least some of those problems for me.
The driver model code was using the wrong calling convention
when probing.
- Dave
--- ./drivers-dist//base/core
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 14 Oct 2002 12:58, Brad Hards wrote:
> > This is the content of /proc/bus/usb/devices after plugging in one of the
> > hubs. Isn't it strange - Cls=hub, Driver=none.
>
> I'm not getting lockups, but I am seeing this problem. It looks like the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 14 Oct 2002 09:50, Lars Doelle wrote:
> Now comes the interesting stuff - usbdev-2 with i cite here, additionally:
> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
> B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
> D: Ver=
On Sunday 13 October 2002 19:56, David Brownell wrote:
> Hi Lars,
>
> > The problem appears durings boot time and causes a complete lock-up of
> > the system.
> >
> > FamousLastWords += "usb.c: new USB bus registered, assigned bus number 1"
> >
> > I can complete the boot process if i plug out any
Hi Lars,
The problem appears durings boot time and causes a complete lock-up of the
system.
FamousLastWords += "usb.c: new USB bus registered, assigned bus number 1"
I can complete the boot process if i plug out anything from the host, and
plugging in the first hub with out any devices attach
Folks,
desperately trying to 2.5 running since about 2.5.20, i have an issue in the
latest kernels, which seems to be related to ohci-hub from the symptoms.
Perhaps you know how to works around.
The problem appears durings boot time and causes a complete lock-up of the
system.
FamousLastWords
20 matches
Mail list logo
