On Thursday 18 January 2007 10:08 am, Phil Endecott wrote:
> David Brownell wrote:
> > On Thursday 18 January 2007 9:50 am, Phil Endecott wrote:
> >> David Brownell wrote:
> >> > I've checked the updated "usb.c" code into CVS; not sure when it'l be
> >> > visible on the website, presumably tomorrow
David Brownell wrote:
> On Thursday 18 January 2007 9:50 am, Phil Endecott wrote:
>> David Brownell wrote:
>> > With that and the other patches I've sent (notably the race fix, none
>> > of the others ought to matter here), I don't see problem any more.
>>
>> I still see the problem after applying
Sorry I'm talking rubbish; I'm looking at testusb.c not usb.c.
Phil.
-
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 & bu
David Brownell wrote:
> On Thursday 18 January 2007 9:50 am, Phil Endecott wrote:
>> David Brownell wrote:
>> > I've checked the updated "usb.c" code into CVS; not sure when it'l be
>> > visible on the website, presumably tomorrow morning, but I'd expect
>> > it's available from CVS already.
>>
>>
On Thursday 18 January 2007 9:50 am, Phil Endecott wrote:
> David Brownell wrote:
> > With that and the other patches I've sent (notably the race fix, none
> > of the others ought to matter here), I don't see problem any more.
>
> I still see the problem after applying all of the kernel patches, b
David Brownell wrote:
> With that and the other patches I've sent (notably the race fix, none
> of the others ought to matter here), I don't see problem any more.
I still see the problem after applying all of the kernel patches, but
I'm still using the original usb.c.
> I've checked the updated
On Monday 15 January 2007 10:08 am, David Brownell wrote:
> > > As to why they don't get up to userspace, it seems to be something after
> > > the kill_fasync() is called which doesn't work. The event loop is never
> > > notified; sigwait() never returns, the read on ep0 is never issued. This
>
On Monday 15 January 2007 9:11 am, Phil Endecott wrote:
> David Brownell wrote:
> > Further testing on my system turned up more information:
> >
> > - The string fetches done during device enumeration fail sometimes too.
> >This leads to delays, timeouts, resubmissions ... it's not just these
David Brownell wrote:
> Further testing on my system turned up more information:
>
> - The string fetches done during device enumeration fail sometimes too.
>This leads to delays, timeouts, resubmissions ... it's not just these
>cases in test #10. Do you see messages about khubd timeouts
On Monday 15 January 2007 3:35 am, Phil Endecott wrote:
>
> Actually this varies from run to run. The most common case is for subtest 2
> to fail;
> subtest 12 has failed in just a couple of runs.
Those are the only two calls in that test which go up to userspace.
> In most cases it also re
Earlier I wrote:
> Jan 15 11:15:18 egypt kernel: drivers/usb/misc/usbtest.c: subtest 12 error,
> status -71
> Jan 15 11:15:18 egypt kernel: drivers/usb/misc/usbtest.c: control queue
> 80.06, err -71, 28516 left
> Jan 15 11:15:18 egypt kernel: drivers/usb/misc/usbtest.c: subcase 13
> completed ou
David Brownell wrote:
> On Monday 08 January 2007 5:55 am, Phil Endecott wrote:
>> # ./testusb -D /proc/bus/usb/004/010 -t10
>> (Never completes, no output)
>> dmesg:
>>
>> Jan 8 12:37:38 egypt kernel: usbtest 4-4:3.0: TEST 10: queue 32
>> control calls, 1000 times
>> (no further output)
>
> Ac
Sorry, I meant to post this analysis earlier in the week but got
distracted...
On Sat, 13 Jan 2007, David Brownell wrote:
> > # ./testusb -D /proc/bus/usb/004/010 -t10
> > (Never completes, no output)
> > dmesg:
> >
> > Jan 8 12:37:38 egypt kernel: usbtest 4-4:3.0: TEST 10: queue 32
> > con
On Monday 08 January 2007 5:55 am, Phil Endecott wrote:
> Test 0-9 and 11-13 pass. Test 14 fails:
>
> # strace ./testusb -D /proc/bus/usb/004/010 -t14 -c 15000 -s 256 -v 1
> ..
> open("/proc/bus/usb/004/010", O_RDWR) = 4
> ioctl(4, USBDEVFS_IOCTL, 0xbf8df42c)= -1 EOPNOTSUPP (Operation not
14 matches
Mail list logo
