On Friday 17 December 2004 3:25 pm, Robert Wruck wrote:
> > At which point an "alt-sysrq-t" traceback should be informative,
> > if this patch doesn't help the latest rc3-BK code.
>
> Thanks! Keeping the root hub from suspending seems to solve the
> problem..
Good -- it's already in 2.6.10-rc3-b
> At which point an "alt-sysrq-t" traceback should be informative,
> if this patch doesn't help the latest rc3-BK code.
Thanks! Keeping the root hub from suspending seems to solve the
problem..
-robert
---
SF email is sponsored by - The IT P
On Sunday 12 December 2004 4:26 pm, Robert Wruck wrote:
> Hi,
>
> I'm encountering a strange behaviour with an AMD-756 USB controller, or
> more exactly:
> :00:07.4 USB Controller: Advanced Micro Devices [AMD] AMD-756
> [Viper] USB (rev 06)
>
> There's one USB device connected at boot time
Hi,
I'm encountering a strange behaviour with an AMD-756 USB controller, or
more exactly:
:00:07.4 USB Controller: Advanced Micro Devices [AMD] AMD-756
[Viper] USB (rev 06)
There's one USB device connected at boot time (a low speed APC UPS).
When I boot up the system and issue a 'cat /proc/b
David Brownell wrote:
These symptoms are like those which have, for other folk, been
resolved by some USB patches that Greg just submitted. If all
goes as usual, they're probably in Linus' BK already ... :)
Let me know if this problem persists with that updated code.
It's better, but not quite
On Friday 12 November 2004 15:05, Olof Johansson wrote:
> Hi,
>
> USB on my 1.2GHz iBook works fine in 2.6.9, but current kernels won't
> find any devices on the bus. I've done some searching, and the last BK
> snapshot that did work was 2.6.9-bk1. As of 2.6.9-bk2 the problems
> begin, and curren
Hi,
USB on my 1.2GHz iBook works fine in 2.6.9, but current kernels won't
find any devices on the bus. I've done some searching, and the last BK
snapshot that did work was 2.6.9-bk1. As of 2.6.9-bk2 the problems
begin, and current BK is also broken.
Boot output with CONFIG_USB_DEBUG is included a
Hi!
> >>Here's a patch that makes things slightly better.
> >>
> >>Where "better" means that it seems functional after the
> >>first suspend/resume cycle, and re-enumerates the device
> >>that's connected ... but there's still strangeness. And
> >>I can see how some of it would be generic.
>
Pavel Machek wrote:
Hi!
Here's a patch that makes things slightly better.
Where "better" means that it seems functional after the
first suspend/resume cycle, and re-enumerates the device
that's connected ... but there's still strangeness. And
I can see how some of it would be generic.
For
Hi!
>
> Here's a patch that makes things slightly better. It's still
> not fully functional yet -- I forgot how many FIXMEs are in
> those PM code paths! -- and shouldn't be merged as-is, but it
> works slightly better:
>
> - Has a more informative diagnostic message (which HC died);
>
> - W
Pavel Machek wrote:
Hi!
In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
kills machine during secon suspend/resume cycle.
OK, I can see that in 2.6.0-test2 iff there's a device connected;
that's on OHCI hardware that doesn't retain power during suspend,
which means it uses th
Hi!
> >Can you try echo 4 > /proc/acpi/sleep? echo 3 breaks it, too, but that
> >is little harder to set up.
>
> I usually test with "apm -s" ... since I've yet to come up with
> an ACPI configuration that works properly. IRQ misconfiguration
> for USB is still a blocking issue for many people (
Pavel Machek wrote:
Hi!
Good morning to you too!
In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
kills machine during secon suspend/resume cycle.
Hmm, last time I tested suspend/resume it worked fine.
That was 2.5.67, but the OHCI code hasn't had any
relevant changes since
Hi!
> >In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
> >kills machine during secon suspend/resume cycle.
>
> Hmm, last time I tested suspend/resume it worked fine.
> That was 2.5.67, but the OHCI code hasn't had any
> relevant changes since then.
> Evidently your system
Pavel Machek wrote:
Hi!
In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
kills machine during secon suspend/resume cycle.
Hmm, last time I tested suspend/resume it worked fine.
That was 2.5.67, but the OHCI code hasn't had any
relevant changes since then.
Evidently your syste
Hi!
In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
kills machine during secon suspend/resume cycle.
What happens is that ohci_irq gets ohci->hcca == NULL, and kills
machine. Why is ohci->hcca == NULL? ohci_stop was called from
hcd_panic() and freed ohci->hcca.
I believe t
David Brownell wrote:
>
> Gary A. Gorgen wrote:
> >
> > Does this provide any clues ?
>
> I'm still suspecting it's a combination of (a) device bugs,
> causing the timeouts, (b) usb-ohci bugs, fixed in ohci-hcd,
> making those oopses.
What do I have to do to get /proc/ksyms in 2.5 ***
CONFI
Gary A. Gorgen wrote:
Does this provide any clues ?
I'm still suspecting it's a combination of (a) device bugs,
causing the timeouts, (b) usb-ohci bugs, fixed in ohci-hcd,
making those oopses.
- Dave
---
This SF.net email is sponsored by: Sli
Hello again:
Here are a few oop's I've been able to collect.
aa55aa55 is the data I'm reading.
Does this provide any clues ?
---
ksymoops 2.4.4 on i686 2.4.21-pre4. Options used
-V (default)
-k ksyms (specified)
-l /proc/modules (default)
-
David Brownell wrote:
>
> (Gary, your system clock is set well into the future; UTC?)
Yes UTC. It keeps Makefiles sane :-).
>
> Gary A. Gorgen wrote:
> > David Brownell wrote:
> >
> >>Thanks for the info about what 2.5.61 shows ... seems more polite.
> >>It doesn't seem to be giving you "Unrecov
By the way:
7. This is what I get when I unplug &replug a part.
...
<7>usb 3-2: unregistering device
<7>drivers/usb/core/usb.c: usb_hotplug
<7>ohci-hcd 00:11.0: bad hash for td ce116180
<7>ohci-hcd 00:11.0: bad hash for td ce116200
<7>ohci-hcd 00:11.0: bad hash for td ce116040
That message ma
(Gary, your system clock is set well into the future; UTC?)
Gary A. Gorgen wrote:
David Brownell wrote:
Thanks for the info about what 2.5.61 shows ... seems more polite.
It doesn't seem to be giving you "Unrecoverable Error" (UE) failures,
unlike the 2.4 "usb-ohci" code. (At least, not withou
David Brownell wrote:
>
> Thanks for the info about what 2.5.61 shows ... seems more polite.
> It doesn't seem to be giving you "Unrecoverable Error" (UE) failures,
> unlike the 2.4 "usb-ohci" code. (At least, not without more work!)
>
The (UE) are very rare. 2 out of 100 maybe.
> > <7>usb 5-1:
Thanks for the info about what 2.5.61 shows ... seems more polite.
It doesn't seem to be giving you "Unrecoverable Error" (UE) failures,
unlike the 2.4 "usb-ohci" code. (At least, not without more work!)
<7>usb 5-1: urb ce02e500 usb-00:12.0-1 ep-2-IN cc 5 --> status -110
<4>usbfs: USBDEVFS_BULK
Update:
Here is what happens with 2.5.61:
This is tested on the system with off the shelf parts.
1. OHCI loaded, USB-2.0 parts.
Everything works.
2. Remove 2.0 parts & replace with 1.1 parts.
<7>drivers/usb/core/usb.c: usbfs driver claimed interface c132cce0
<7>drivers/usb/core/usb.c: usbfs dri
David Brownell wrote:
>
> > ** REQUEST ***
> > Would it be possible for someone to add the controller info to the debug
> > messages, in the proper way.
> > I just stuck in what I needed, without any thought as to format.
> > **
>
> The 2.5 driver shoul
** REQUEST ***
Would it be possible for someone to add the controller info to the debug
messages, in the proper way.
I just stuck in what I needed, without any thought as to format.
**
The 2.5 driver should be better, though I've got some diagnostics
pa
Hello All:
I've been following this excellent list for a while, and been able to solve most
of my problems with the patches provided. Keep up the good work.
Thanks in advance for any help anyone can offer.
I haven't yelled for help before, because I'm working with our own hardware.
I don't want
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
48 matches
Mail list logo
