On Fri, Mar 24, 2000 at 10:01:46AM +0000, Chip Grandits wrote:
Hi,
<...>
> (however on bootup I get an error message that the shared memory file
> system (shm) could not be mounted - I'm not sure if this is relevant?)
No, but for >2.3.51 you have to mount the shm-filesystemtype to /var/shm if
you want to use the shm*-calls in userspace.
<...>
> When I attempt to run either the control test or the bulk test
> I get the following error from usbstress:
>
> # ./usbstress -v -b1 -d2 -tc
> usbstress V0.3 (C) 2000 by Thomas Sailer
> Length = 18
> DescriptorType = 01
> USB version = 1.00
> Vendor:Product = 1234:5678
> MaxPacketSize0 = 64
> NumConfigurations = 1
> Device version = 0.02
> Device Class:SubClass:Protocol = ff:00:ff
> Vendor class
> Control Echo test
> control_msg(0xc0, 0xe0, 48) failed with -1, errno Broken pipe (32) sequence 0
>
> Upon failure the following line is appended to kernel ring buffer
> usb-uhci.c: interrupt, status 3, frame# 989
> usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 192 rq 224 len 48 ret -32
> (the frame number varies - the bulk test also fails, in which case rq=225 or 0xe1
>instead of 224)
>
> Upon examination with gdb I notice that this call succeeds: (usbstress/tests.c line
>151)
> r = usb_control_msg(dev, USB_RECIP_DEVICE|USB_TYPE_VENDOR|USB_DIR_OUT, 0xe0, 0, 0,
>sizeof(buf), buf, 1000);
>
> This subsequent call is the one that always fails (usbstress/tests.c line 157)
> r = usb_control_msg(dev, USB_RECIP_DEVICE|USB_TYPE_VENDOR|USB_DIR_IN, 0xe0, 0, 0,
>sizeof(bufr), bufr, 1000);
usbstress sees the STALL form the Anchor as an error and aborts, from a
protocol view, the USB transfers look totally right.
I haven't checked yet, whether the Anchor firmware is doing anything wrong or
the IN-request is simply coming too fast, since the out has to copy the data.
> I don't know if this is of any help but after the ioctl call fails the value of the
>dev pointer (as reported
> by gdb) changes. It's value became 0x20, a pretty suspicious value for a pointer.
> (I could no longer dereference it, according to gdb 0x20 is not in accessible memory)
I don't see how dev can be changed from within the kernel, I assume it's a
compiler optimization (have you tried it without -O3?)
--
Bye
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
