Hi,
>> Earlier, i used file=/dev/mmcblk0p1. Now i use
>> file=/mnt/sd/backing_file. This backing_file is a dummy file system
>> that i created. I attached two jpeg files. One show the MBR and Boot
>> Sector of the backing_file. Another shows the usbmon of the Linux Host
>
> Why did you send jpeg files? Plain text files are a lot easier to work
> with. Now I can't copy and paste the lines from your files into this
> email message. :-(
>
>> PC. I also attached the udc log which shows the MBR and Boot Sector
>> content which are read from the backing_file.
>
> The UDC log indicates that the MBR and boot sectors were read
> correctly.
>
>> From the usbmon jpeg,
>> that first SCSI_READ_10 command got a overflow error, the second
>> SCSI_READ_10 command got a connection reset error. Is the overflow
>> error occurred because the host PC cannot handle the data returned
>> from the gadget device?
>
> The usbmon log shows that the host sent the gadget a READ(10) command
> for 8 sectors, which 4096 bytes. It then requested a 4096-byte
> transfer on the bulk-in endpoint, expecting the gadget to reply with
> eight packets, each containing 512 bytes (because the bulk-in
> wMaxPacketSize is 512).
>
> But the gadget did not reply correctly. The UDC sent a data packet
> containing only 256 bytes, instead of 512 bytes. The overflow occurred
> when it sent a second data packet, again containing the wrong number of
> bytes.
>
>> > Call the gadget driver's ->reset handler. If the ->reset pointer is
>> > NULL, call the ->disconnect handler instead. See the code in
>> > net2280.c's handle_stat1_irqs() as an example.
>> >
>> > Alan Stern
>> >
>>
>> i read the net2280.c code. Is it the usb_reset() function, called by
>> stop_activity()? I am sorry if i understand incorrectly.
>
> No, it is the handle_stat1_irqs() function, as I wrote above. In
> particular, this part of the code, which handles both disconnects and
> resets:
>
> if (disconnect || reset) {
> stop_activity(dev, dev->driver);
> ep0_start(dev);
> spin_unlock(&dev->lock);
> if (reset && dev->driver->reset)
> (dev->driver->reset)(&dev->gadget);
> else
> (dev->driver->disconnect)(&dev->gadget);
> spin_lock(&dev->lock);
> return;
> }
>
I use kernel 3.4.4, the code in handle_stat1_irqs() is as below. There
is no reset or disconnect member function in "struct
usb_gadget_driver" in kernel 3.4.4.
if (stat & (1 << SUSPEND_REQUEST_INTERRUPT)) {
if (dev->driver->suspend)
dev->driver->suspend (&dev->gadget);
if (!enable_suspend)
stat &= ~(1 << SUSPEND_REQUEST_INTERRUPT);
} else {
if (dev->driver->resume)
dev->driver->resume (&dev->gadget);
/* at high speed, note erratum 0133 */
}
>> Another usbmon trace showing 3 SCSI_READ_10 command.
>
>This trace shows that the READ(10) commands worked correctly. Good.
>But it also shows that the gadget did not respond correctly to the 0xA1
>command near the end. The UDC was supposed to set the Halt feature
>for the bulk-in endpoint and send a STALL packet, but it didn't.
In gadget driver, when do_scsi_command() receives an unknown command,
the return value is -EINVAL. Will this value be returned to UDC
driver, so that UDC driver can set the Halt feature for the bulk-in
endpoint and send a STALL packet? For now, UDC driver does not set
Halt when unknown SCSI command is received.
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
