On Sun, 28 Jan 2007, Prakash Punnoor wrote: > 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?
The patch has worked for other people. Git-bisect is well-known for sometimes pointing to the wrong patch. The only way to find out for sure is to investigate some more... > Where can I get that > patch as standalone? So I could revert it in rc6 and test... You won't be able to revert it directly because at least one later patch depends on it. > 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. No it isn't. 1-1 is the "empty" hub, and 1-1.3 is a device attached to port 3 of that hub. This might be an internal port and the device might be built into the same package as the hub, so you don't realize it is actually an independent device. > 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)? The kernel touches the hub because your program tells it to. In more detail: sane uses libusb to handle its communications with USB devices, and libusb starts out by surveying all the USB devices attached to the computer -- thereby causing any suspended devices to be woken up. I would still like the see the usbmon logs. Please run the experiments and post the logs. In fact, to be completely thorough try doing three experiments: one with 2.6.19, one with 2.6.20-rc6 and CONFIG_USB_SUSPEND turned off, and one with 2.6.20-rc6 and CONFIG_USB_SUSPEND turned on. We expect the first two tests to succeed and the third to fail. Alan Stern ------------------------------------------------------------------------- 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
