2.6.8-rc2-mm2 with usb and input problems

2.6.8-rc2-mm2 with usb and input problems

[Norbert Preining]

Hi Andrew, hi list!

I tried 2.6.8-rc2-mm2 and I still don't get it to work properly for me.
The last kernel which really worked was 2.6.7-mm5. I experience the
following problems:

- USB deadlocking
  USB is still deadlocky, quite often process hang in D+ state.
  Is there something similar to usb-deadlock.fix which I could
  apply to 2.6.7-mm6, but which stumbles over 2.6.8-rc2-mm2?

- psmouse/synaptics
  If I have usb as module, I cannot get synaptics to be recognized.
  Dmitry recommended making psaux driver as modules, but I cannot
  get it as module, because INPUT is automatically set to y, etc
  How is it possible to have USB modular and still get synaptics
  recognized? (or is a modular USB not necessary for S2R now that
  we have CONFIG_USB_SUSPEND?)

To recount the last question:
Is it still necessary for S2R to have USB modular, or is the usb
subsystem slowly ready for use without getting unloaded?


Thanks a lot for the great work and all the best

Norbert

-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at>         Technische Universität Wien
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
DEEPING ST NICHOLAS (n.)
			--- Douglas Adams, The Meaning of Liff
What street-wise kids do at Christmas. They hide on the rooftops
waiting for Santa Claus so that if he arrives and goes down the
chimney, they can rip stuff off from his sleigh.

Re: [linux-usb-devel] 2.6.8-rc2-mm2 with usb and input problems

[David Brownell]

On Monday 02 August 2004 09:28, Norbert Preining wrote:

> - USB deadlocking
>   USB is still deadlocky, quite often process hang in D+ state.

So what does alt-sysrq-t show you about those processes?
How do you reproduce these hangs?  I'm guesssing that
And does 2.6.8-rc (without the MM patch) acts the same.

 
> - psmouse/synaptics
>   If I have usb as module, I cannot get synaptics to be recognized.

Odd.  BIOS settings maybe?

>    (or is a modular USB not necessary for S2R now that
>   we have CONFIG_USB_SUSPEND?)

The S2R issue is caused by delivering bogus PCI
device power states to PCI drivers.  See if the patch
in http://bugme.osdl.org/show_bug.cgi?id=2886
helps at all.  (It might be better to map STANDBY
to D0 state, so long as nobody's actually checking
PCI config space there to see if D1 or D2 works.)

If you don't actually have code trying to suspend
USB devices, don't enable it.  Until some other
issues in the PM core get resolved (notably its
eagerness to self-deadlock) that's purely for use
by developers.

- Dave

Re: [linux-usb-devel] 2.6.8-rc2-mm2 with usb and input problems

[Norbert Preining]

Hi David!
On Mon, 02 Aug 2004, David Brownell wrote:
> > - USB deadlocking
> >   USB is still deadlocky, quite often process hang in D+ state.
> 
> So what does alt-sysrq-t show you about those processes?

Ok, I will write it down next time ;-) It happens during the boot
process, but I will try to get it happen after login by starting hotplug
by hand.

> How do you reproduce these hangs?  I'm guesssing that
> And does 2.6.8-rc (without the MM patch) acts the same.

Hmm, haven't tested this yet, always running -mm kernels.

> > - psmouse/synaptics
> >   If I have usb as module, I cannot get synaptics to be recognized.
> 
> Odd.  BIOS settings maybe?

No, definitely not. I think it only depends on the modules loaded, and
if usb is modular then input is loaded after psmouse/mousedev and this I
cannot reverse, because I cannot get mousedev/psaux to be build modular.

> The S2R issue is caused by delivering bogus PCI
> device power states to PCI drivers.  See if the patch
> in http://bugme.osdl.org/show_bug.cgi?id=2886
> helps at all.  (It might be better to map STANDBY

Will try this. Thanks.

> If you don't actually have code trying to suspend
> USB devices, don't enable it.  Until some other

Ok.

Best wishes

Norbert

-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at>         Technische Universität Wien
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
LOWTHER (vb.)
(Of a large group of people who have been to the cinema together.) To
stand aimlessly about on the pavement and argue about whatever to go
and eat either a Chinese meal nearby or an Indian meal at a restaurant
which somebody says is very good but isn't certain where it is, or
have a drink and think about it, or just go home, or have a Chinese
meal nearby - until by the time agreement is reached everything is
shut.
			--- Douglas Adams, The Meaning of Liff

Re: [linux-usb-devel] 2.6.8-rc2-mm2 with usb and input problems

[Norbert Preining]

Hi David, hi lists!

(Taking Andrew and Dmitry off private email, this concerns only usb I
guess)

On Mon, 02 Aug 2004, preining wrote:
> > > - USB deadlocking
> > >   USB is still deadlocky, quite often process hang in D+ state.
> > 
> > So what does alt-sysrq-t show you about those processes?

Ok, I turned off hotplug, started it by hand and found what is making
the troubles:

First, it is cups, when trying the backend usb/canon/epson accessing the
usb subsystem. So I turned this of.

Then I tried lsusb, which hang, here is what sysrq-t says:
lsusb         D C0158CDC     0  3942   3849                     (NOTLB)
d648cef4 00200086 c1621800 c0158cdc 00000000 08088000 d39ce300 00000001 
       6e50f578 00000028 d427a7f4 df4cf824 00200296 d648c000 d427a650 c02d3f5f 
       df4cf82c 00000001 d427a650 c0118cf9 df4cf82c df4cf82c d687fd40 e08e0798 
Call Trace:
 [<c0158cdc>] link_path_walk+0xa1f/0xd4e
 [<c02d3f5f>] __down+0x8b/0x116
 [<c0118cf9>] default_wake_function+0x0/0xc
 [<e08e0798>] usbdev_open+0x54/0xfa [usbcore]
 [<c02d4144>] __down_failed+0x8/0xc
 [<e08e26ba>] .text.lock.devio+0x5/0xff [usbcore]
 [<c014ba8b>] filp_open+0x4c/0x4e
 [<c014c62d>] vfs_read+0xa9/0xf5
 [<c014c846>] sys_read+0x38/0x59
 [<c0105e4f>] syscall_call+0x7/0xb

Does this help you. lsusb is in D+ state.

SOmething similar happened when I tried to remove usbhid, or anything
else related to usb.

Best wishes

Norbert

-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at>         Technische Universität Wien
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
HOGGESTON (n.)
The action of overshaking a pair of dice in a cup in the mistaken
belief that this will affect the eventual outcome in your favour and
not irritate everyone else.
			--- Douglas Adams, The Meaning of Liff

Re: [linux-usb-devel] 2.6.8-rc2-mm2 with usb and input problems

[David Brownell]

On Tuesday 03 August 2004 01:11, Norbert Preining wrote:
> Then I tried lsusb, which hang, here is what sysrq-t says:
> lsusb         D C0158CDC     0  3942   3849                     (NOTLB)
> ...
> Call Trace:
>  [<c0158cdc>] link_path_walk+0xa1f/0xd4e
>  [<c02d3f5f>] __down+0x8b/0x116
>  [<c0118cf9>] default_wake_function+0x0/0xc
>  [<e08e0798>] usbdev_open+0x54/0xfa [usbcore]
>  [<c02d4144>] __down_failed+0x8/0xc
>  [<e08e26ba>] .text.lock.devio+0x5/0xff [usbcore]
>  [<c014ba8b>] filp_open+0x4c/0x4e
>  [<c014c62d>] vfs_read+0xa9/0xf5
>  [<c014c846>] sys_read+0x38/0x59
>  [<c0105e4f>] syscall_call+0x7/0xb

Not clear how to read that stack; if it's usbdev_open()
that's making the trouble, lock_kernel() is blocked.
But that doesn't quite make sense to me.  Sorry!

- Dave

Re: [linux-usb-devel] 2.6.8-rc2-mm2 with usb and input problems

[Norbert Preining]

Hi David!

On Mit, 04 Aug 2004, David Brownell wrote:
> Not clear how to read that stack; if it's usbdev_open()
> that's making the trouble, lock_kernel() is blocked.
> But that doesn't quite make sense to me.  Sorry!

So what now? Should I make other programs hang and check for the trace
there, and hope to find another trace? Or ignore it for now?

Best wishes

Norbert

-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at>         Technische Universität Wien
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
AINDERBY STEEPLE (n.)
One who asks you a question with the apparent motive of wanting to
hear your answer, but who cuts short your opening sentence by leaning
forward and saying 'and I'll tell you why I ask...' and then talking
solidly for the next hour.
			--- Douglas Adams, The Meaning of Liff

Re: [linux-usb-devel] 2.6.8-rc2-mm2 with usb and input problems

[David Brownell]

On Wednesday 04 August 2004 23:51, Norbert Preining wrote:
> Hi David!
> 
> On Mit, 04 Aug 2004, David Brownell wrote:
> > Not clear how to read that stack; if it's usbdev_open()
> > that's making the trouble, lock_kernel() is blocked.
> > But that doesn't quite make sense to me.  Sorry!
> 
> So what now? Should I make other programs hang and check for the trace
> there, and hope to find another trace? Or ignore it for now?

You can ignore hangs?  My!

Check other traces, surely something will make more sense.

- Dave

Re: [linux-usb-devel] 2.6.8-rc2-mm2 with usb and input problems

[Norbert Preining]

Hi David!

On Don, 05 Aug 2004, David Brownell wrote:
> > > Not clear how to read that stack; if it's usbdev_open()
> > > that's making the trouble, lock_kernel() is blocked.
> > > But that doesn't quite make sense to me.  Sorry!
> > 
> 
> Check other traces, surely something will make more sense.

Ok, here are two new ones with 2.6.8-rc4-mm1: The one from lsusb, the
other from cat /proc/bus/usb/devices ...


lsusb         D C0CE8B00     0  2605      1          2611  2351 (NOTLB)
d71f0eec 00000086 00000000 c0ce8b00 c015a30d 08088000 d71f0ef0 00000000 
       000f83ad 98a6d31f 0000007b dfb8b110 dfb8b2b8 c0d2f024 00000282 d71f0000 
       dfb8b110 c02d9d6b c0d2f02c 00000001 dfb8b110 c0118fd7 c0d2f02c c0d2f02c 
Call Trace:
 [<c015a30d>] link_path_walk+0xa56/0xd91
 [<c02d9d6b>] __down+0x8b/0x122
 [<c0118fd7>] default_wake_function+0x0/0xc
 [<c0205ffc>] get_device+0xe/0x14
 [<e08cf8ae>] usb_get_dev+0x12/0x16 [usbcore]
 [<c02d9f68>] __down_failed+0x8/0xc
 [<e08da6c5>] .text.lock.devio+0x5/0x150 [usbcore]
 [<c014cdeb>] dentry_open+0xfe/0x210
 [<c014d8ee>] vfs_read+0xa9/0xf5
 [<c014db4c>] sys_read+0x47/0x76
 [<c0105e4f>] syscall_call+0x7/0xb

cat           D 80000180     0  3902   3131                     (NOTLB)
d6c23e0c 00000086 d6c26530 80000180 c15dbe80 d702cc00 80000180 d2c0b840 
       00163790 8d5506e2 000000ff d50fee70 d50ff018 e08e58ac d6c23e1c d50fee70 
       e08e58ac c02daa87 00000409 e08e58b0 e08e58b0 e08e58b0 d50fee70 00000001 
Call Trace:
 [<c02daa87>] rwsem_down_read_failed+0x8f/0x191
 [<e08dc5cb>] .text.lock.devices+0x7/0x98 [usbcore]
 [<e08dbbc7>] usb_dump_interface+0x38/0x79 [usbcore]
 [<e08dbcfc>] usb_dump_config+0x91/0xcc [usbcore]
 [<e08dbfa7>] usb_dump_desc+0x94/0xad [usbcore]
 [<e08dc12e>] usb_device_dump+0x16e/0x2fa [usbcore]
 [<e08dc3b6>] usb_device_read+0xfc/0x12f [usbcore]
 [<c014d8ee>] vfs_read+0xa9/0xf5
 [<c014db4c>] sys_read+0x47/0x76
 [<c0105e4f>] syscall_call+0x7/0xb

Best wishes

Norbert

-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at>         Technische Universität Wien
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
SNITTERBY (n.)
Someone who pins snitters (q.v.) on to snitterfields (q.v.) and is
also suspected of being responsible for the extinction of virginstows
(q.v.)
			--- Douglas Adams, The Meaning of Liff

Re: [linux-usb-devel] 2.6.8-rc2-mm2 with usb and input problems

[Alan Stern]

On Tue, 10 Aug 2004, Norbert Preining wrote:

> Ok, here are two new ones with 2.6.8-rc4-mm1: The one from lsusb, the
> other from cat /proc/bus/usb/devices ...
> 
> 
> lsusb         D C0CE8B00     0  2605      1          2611  2351 (NOTLB)
> d71f0eec 00000086 00000000 c0ce8b00 c015a30d 08088000 d71f0ef0 00000000 
>        000f83ad 98a6d31f 0000007b dfb8b110 dfb8b2b8 c0d2f024 00000282 d71f0000 
>        dfb8b110 c02d9d6b c0d2f02c 00000001 dfb8b110 c0118fd7 c0d2f02c c0d2f02c 
> Call Trace:
>  [<c015a30d>] link_path_walk+0xa56/0xd91
>  [<c02d9d6b>] __down+0x8b/0x122
>  [<c0118fd7>] default_wake_function+0x0/0xc
>  [<c0205ffc>] get_device+0xe/0x14
>  [<e08cf8ae>] usb_get_dev+0x12/0x16 [usbcore]
>  [<c02d9f68>] __down_failed+0x8/0xc
>  [<e08da6c5>] .text.lock.devio+0x5/0x150 [usbcore]
>  [<c014cdeb>] dentry_open+0xfe/0x210
>  [<c014d8ee>] vfs_read+0xa9/0xf5
>  [<c014db4c>] sys_read+0x47/0x76
>  [<c0105e4f>] syscall_call+0x7/0xb
> 
> cat           D 80000180     0  3902   3131                     (NOTLB)
> d6c23e0c 00000086 d6c26530 80000180 c15dbe80 d702cc00 80000180 d2c0b840 
>        00163790 8d5506e2 000000ff d50fee70 d50ff018 e08e58ac d6c23e1c d50fee70 
>        e08e58ac c02daa87 00000409 e08e58b0 e08e58b0 e08e58b0 d50fee70 00000001 
> Call Trace:
>  [<c02daa87>] rwsem_down_read_failed+0x8f/0x191
>  [<e08dc5cb>] .text.lock.devices+0x7/0x98 [usbcore]
>  [<e08dbbc7>] usb_dump_interface+0x38/0x79 [usbcore]
>  [<e08dbcfc>] usb_dump_config+0x91/0xcc [usbcore]
>  [<e08dbfa7>] usb_dump_desc+0x94/0xad [usbcore]
>  [<e08dc12e>] usb_device_dump+0x16e/0x2fa [usbcore]
>  [<e08dc3b6>] usb_device_read+0xfc/0x12f [usbcore]
>  [<c014d8ee>] vfs_read+0xa9/0xf5
>  [<c014db4c>] sys_read+0x47/0x76
>  [<c0105e4f>] syscall_call+0x7/0xb

Maybe the -mm series didn't get my USB device locking patches fully
reverted.  They certainly didn't get fully corrected, because the patch
for that was never accepted.  Your traces do make it look as though this
is the problem.

Check in drivers/usb/core/usb.c and see if it mentions
usb_all_devices_rwsem anywhere.  I'd do it myself, but I don't know _any_
way to get hold of a single source file from a particular kernel tree,
other than the ones currently visible via the web at bkbits.net.  :-(

Alan Stern

Re: [linux-usb-devel] 2.6.8-rc2-mm2 with usb and input problems

[Norbert Preining]

Hi Alan!

On Die, 10 Aug 2004, Alan Stern wrote:
> Maybe the -mm series didn't get my USB device locking patches fully
> reverted.  They certainly didn't get fully corrected, because the patch
> for that was never accepted.  Your traces do make it look as though this
> is the problem.
> 
> Check in drivers/usb/core/usb.c and see if it mentions
> usb_all_devices_rwsem anywhere.  I'd do it myself, but I don't know _any_

Not there, nowhere. Nothing with rwsem at all.

So we are back to a zero start again?

Best wishes

Norbert

-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at>         Technische Universität Wien
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
The story goes that I first had the idea for THHGTTG while
lying drunk in a field in Innsbruck (or `Spain' as the BBC
TV publicity department authorititively has it, probably
because it's easier to spell).
                 --- Foreward by DNA.
                 --- Douglas Adams, The Hitchhikers Guide to the Galaxy

Re: 2.6.8-rc2-mm2 with usb and input problems

[Dmitry Torokhov]

On Monday 02 August 2004 11:28 am, Norbert Preining wrote:
> Hi Andrew, hi list!
> 
> I tried 2.6.8-rc2-mm2 and I still don't get it to work properly for me.
> The last kernel which really worked was 2.6.7-mm5. I experience the
> following problems:
> 
> - USB deadlocking
>   USB is still deadlocky, quite often process hang in D+ state.
>   Is there something similar to usb-deadlock.fix which I could
>   apply to 2.6.7-mm6, but which stumbles over 2.6.8-rc2-mm2?
> 
> - psmouse/synaptics
>   If I have usb as module, I cannot get synaptics to be recognized.
>   Dmitry recommended making psaux driver as modules, but I cannot
>   get it as module, because INPUT is automatically set to y, etc
>   How is it possible to have USB modular and still get synaptics
>   recognized? (or is a modular USB not necessary for S2R now that
>   we have CONFIG_USB_SUSPEND?)
>

You should be able to compile psmouse as a module:

[root@core dtor]# grep MOUSE_PS2 /misc/arc/dtor/.config
CONFIG_MOUSE_PS2=m

You need to select it like this:

[*] Mice
  <M>  PS/2 mouse

and load psmouse.ko after USB has been loaded.

Alternatively you can try patch made by Vojtech to take over USB
system early, even before USB host controller driver is loaded:

http://marc.theaimsgroup.com/?l=linux-kernel&m=108953563609250&w=2

(use "Download message RAW" link to get the patch).

-- 
Dmitry