Re: [linux-usb-devel] Re: USB troubles in rc2

[Michael Guterl]

Okay, due to my lack of detail from previous posts, I thought I'd
restate everything with a little more detail.  Previously I was using
2.6.7-mm7 (bk-acpi.patch and bk-usb.patch were reversed), everything
worked fine.  Upgraded to 2.6.8-rc2 and my machine would just stop at
starting cupsd.  Previous to reversing bk-acpi.patch and bk-usb.patch,
2.6.7-mm7 showed the same behavior.  I unplugged all my USB devices,
and booted, and 2.6.8-rc2 started fine.  I plugged in the keyboard and
I tried to use the keyboard and the result was whichever key was
pressed, that character was repeated numerous times.  No matter what I
could not get a single character to appear, the always appeared like
"sssssssssssssssssssssss".  Went and grabbed an old PS/2 Keyboard, and
proceeded to gather the information David Brownell suggested.

Attached are my dmesg's from each kernel, each time I booted fully,
then plugged the USB keyboard in, and then the USB mouse.  My kernel
config is also attached, along with the output of lspci -v, (David
Brownell mentioned "lspci -w" but this isn't a valid option, and I
assume he meant -v).  Also thought it might be worth mentioning that
I'm using a Belkin USB Keyboard, and Logitech USB Mouse.  It might
also be worth mentioning I don't have a USB printer at all, I use cups
for network printing.

On Wed, 4 Aug 2004 18:20:50 -0700, David Brownell <david-b@xxxxxxxxxxx> wrote:
> On Wednesday 04 August 2004 13:32, Michael Guterl wrote:
> 
> > As stated earlier machine hangs on Starting cups.
> 
> The "usblp" driver hasn't changed recently.
> 
> 
> > If I disconnect all
> > USB devices it boots, but when I plug my keyboard in, nothing works
> > unless I hold down a key for a few seconds.
> 
> One data point:  rc3 worked just fine for me on one machine, OHCI
> and EHCI under light testing (which included a keyboard).
> 
> Please be sure to provide full debug info with future reports,
> including "lspci -vv" info, "dmesg" output showing usb init
> and showing the failure, info about the USB devices you're
> using, and "how I broke it" info.  "alt-sysrq-t" traces are good
> for kernel hangs...
> 
> There seem to be a bunch of reports floating around that
> are basically "it doesn't work for me" ... and devoid of enough
> info that anyone could actually track down the problem
> 
>

Attachment: lspci
Description: Binary data

Attachment: dmesg-2.6.7-mm7
Description: Binary data

Attachment: dmesg-2.6.8-rc2
Description: Binary data