Hi,
excuse me but instead of following your suggestions I read how to use
git-bisect and found this out:
ee49fb5dc89d34f1794ac9362fa97c1a640f7ddd is first bad commit
commit ee49fb5dc89d34f1794ac9362fa97c1a640f7ddd
Author: Alan Stern <[EMAIL PROTECTED]>
Date: Wed Nov 22 16:55:54 2006 -0500
USB: keep count of unsuspended children
This patch (as818b) simplifies autosuspend processing by keeping track
of the number of unsuspended children of each USB hub. This will
permit us to avoid a good deal of unnecessary work all the time; we
will no longer have to create a bunch of workqueue entries to carry
out autosuspend requests, only to have them fail because one of the
hub's children isn't suspended.
The basic idea is simple. There already is a usage counter in the
usb_device structure for preventing autosuspends. The patch just
increments that counter for every unsuspended child. There's only one
tricky part: When a device disconnects we need to remember whether it
was suspended at the time (leave the counter alone) or not (decrement
the counter).
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
:040000 040000 a03bd42d6fabc54063b2594871177e512292357b
1a8a55cfe216f428f450c87167cd00108a7bbc5b M drivers
:040000 040000 6c5c086110209f8752719a47a8b6436f70eec3d4
1ae2122e85fdd1446387d2ffd18c6408a5bf692d M include
So does this really point to broken hw or a broken patch? Where can I get that
patch as standalone? So I could revert it in rc6 and test...
Am Samstag 27 Januar 2007 schrieb Alan Stern:
> On Sat, 27 Jan 2007, Prakash Punnoor wrote:
> > usb 1-1.3: USB disconnect, address 16
> > usb 1-1.3: new full speed USB device using ehci_hcd and address 17
> > usb 1-1.3: configuration #1 chosen from 1 choice
> >
> > every time I call sane-find-scanner. Above message refers to my hub, as
> > my scanner is
> >
> > usb 2-2: new full speed USB device using ohci_hcd and address 4
> > usb 2-2: configuration #1 chosen from 1 choice
> >
> > So, if you want something to blacklist, it should be the hub and not the
> > scanner.
>
> Let me get this straight. The scanner works fine so long as it isn't
> connected through the hub, right? And some other device connected through
> the hub (what is 1-1.3 above?) also fails?
It is the empty hub. Remember the scanner is 2-2, which brings me to my next
question: Why does the kernel poke the hub, when I want to communicate with
my scanner (which is directly connected in above scenario)?
Cheers,
--
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
