Bug in cdc-acm: variable struct usb_cdc_parsed_header h may be used
uninitialized in acm_probe.
In kernel 4.8.
/* handle quirks deadly to normal probing*/
if (quirks == NO_UNION_NORMAL)
...
goto skip_normal_probe;
}
we bypass call to
cdc_parse_cdc_header(&h, in
If this is a bug in the UPS, you can make a workaround in Linux.
It is known that rebooting the computer helps. So there should be a way
to do the same without rebooting, automatically.
On Sat, 2016-04-16 at 12:01 -0400, Alan Stern wrote:
> On Sat, 16 Apr 2016, Victor Porton wr
Sometimes my UPS (Advice) starts beeping every 20 seconds or so
(electricity is not turned off and the computer continues to work).
See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820837
UPS model is Advice PRS850.
Note that I am NOT subscribed to this mailing list!
--
To unsubscribe from
len = len;
---
> On 30 Mar 2016, at 19:29, Sergei Shtylyov
> wrote:
>
> Hello.
>
> On 3/30/2016 1:56 AM, Antonio Victor Hilario wrote:
>
>> I'd been using kernel 3.18.10-29 on a set of Beaglebone Black boards, and
>> had found and corrected this on my local build
Kernel build for an ARM target (Beaglebone Black) fails when the source file
drivers/usb/musb/musb_cppi41.c is built, with these kernel options enabled:
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_TI_CPPI41_DMA=y
The build fails with these errors, due to a misspelled constant name
EP_MODE_AUTOREQ_NONE:
I'd been using kernel 3.18.10-29 on a set of Beaglebone Black boards, and had
found and corrected this on my local build tree.
Kernel build fails when the source file drivers/usb/musb/musb_cppi41.c is
built, with these kernel options enabled:
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_TI_CPPI41_DMA=y
T
Hi Felipe,
On Mon, Mar 7, 2016 at 11:13 PM, Felipe Balbi wrote:
>
> Hi,
>
> Victor Dodon writes:
>> [ text/plain ]
>> Sorry, I accidentally pressed Send
>>
>> On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon wrote:
>>> Hi all,
>>>
>
Sorry, I accidentally pressed Send
On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon wrote:
> Hi all,
>
> I have some performance issues with the host port on a Beaglebone
> board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue
> still persists. Running a fio test with 6
a dd from the disk
mounted with iSCSI, the kernel stops at:
Kind regards,
Victor Dodon.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Get rid of the US_DEBUG macro and use instead empty inline function definitions
when CONFIG_USB_STORAGE_DEBUG is not defined
Signed-off-by: Victor Dodon
---
drivers/usb/storage/debug.h | 18 +++---
drivers/usb/storage/ene_ub6250.c | 1 -
drivers/usb/storage/freecom.c| 12
The US_DEBUGPX macro uses printk without specifying a kernel log level, so
the default kernel log level is used, which may not match LOGLEVEL_DEBUG
used in usb_stor_dbg. Remove the macro and use usb_store_dbg instead.
Signed-off-by: Victor Dodon
--
Changes in v2:
- Completely remove the macro
On Sun, Feb 14, 2016 at 05:20:21PM -0800, Greg Kroah-Hartman wrote:
> On Wed, Feb 10, 2016 at 04:13:43PM -0800, Victor Dodon wrote:
> > The US_DEBUGPX macro uses printk without specifying a kernel log level, so
> > the default kernel log level is used, which may not match LOGLEVEL
The US_DEBUGPX macro uses printk without specifying a kernel log level, so
the default kernel log level is used, which may not match LOGLEVEL_DEBUG
used in usb_stor_dbg. Use printk_emit with LOGLEVEL_DEBUG instead.
Signed-off-by: Victor Dodon
---
drivers/usb/storage/debug.h | 10 --
1
16.10.2014 14:02, Johan Hovold пишет:
On Thu, Oct 16, 2014 at 12:47:05PM +0400, Victor Ashik wrote:
Wed, Oct 15, 2014 at 6:00 PM, Johan Hovold wrote:
No, we're still supposed to support the legacy SIO type of devices,
although that code doesn't get much testing I'm afr
16.10.2014 14:02, Johan Hovold пишет:
On Thu, Oct 16, 2014 at 12:47:05PM +0400, Victor Ashik wrote:
Wed, Oct 15, 2014 at 6:00 PM, Johan Hovold wrote:
No, we're still supposed to support the legacy SIO type of devices,
although that code doesn't get much testing I'm afr
Please check below
15.10.2014 18:00, Johan Hovold пишет:
[ Adding linux-usb to CC. ]
On Wed, Oct 15, 2014 at 03:55:15PM +0400, Victor Ashik wrote:
Hello Johan,
Sorry for asking you directly, I found your address in the top comment of
ftdi_sio.c in Linux sources. I think that you know a
wrote:
> Stanescu Victor writes:
>
>> victor@victor-laptop:~$ lsusb -vd 03f0:521d
> [..]
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber4
>> bAlternateSetting
/dev/cdc-wdm2 doesn't work. Further more, instead of freezing at cat, it
freezes from echo.
Ctrl-c doesn't stop the frozen echo.
On 07/23/2014 12:45 PM, Bjørn Mork wrote:
> Stanescu Victor writes:
>
>> root@victor-laptop:~# modprobe qmi_wwan
>> root@victor-lapt
root@victor-laptop:~# modprobe qmi_wwan
root@victor-laptop:~# dmesg
[ 6005.900671] usbcore: registered new interface driver cdc_wdm
[ 6005.902682] usbcore: registered new interface driver qmi_wwan
root@victor-laptop:~# echo "03f0 521d" >
/sys/bus/usb/drivers/qmi_wwan/new_id
root@
victor@victor-laptop:~$ lsusb -vd 03f0:521d
Bus 002 Device 007: ID 03f0:521d Hewlett-Packard
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 2
bDeviceProtocol
Hello,
As I have started this discussion, I'd like to assure you that I'm
willing to do any tests you want/need in order to clarify it. Even a
teamviewer session can be an option if needed.
Thanks,
Victor
On 07/23/2014 11:52 AM, Bjørn Mork wrote:
> Lars Melin writes:
>>
=usbserial_generic
Thanks,
Victor Stanescu--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signed-off-by: Victor A. Santos
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index f4a8229..6eee0ce 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -234,6 +234,13 @@ UNUSUAL_DEV( 0x0421, 0x0495, 0x0370, 0x0370
On Sat, 2014-04-26 at 08:08 -0700, Greg KH wrote:
> On Sat, Apr 26, 2014 at 11:00:52AM -0300, Victor A. Santos wrote:
> > Asha 305 as 502 should be treated as unusual 'US_FL_MAX_SECTORS_64'.
> >
> >
> > diff --git a/drivers/usb/storage/unusual_devs.h
>
,6 +234,13 @@ UNUSUAL_DEV( 0x0421, 0x0495, 0x0370, 0x0370,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_MAX_SECTORS_64 ),
+/* Patch submitted by Victor A. Santos */
+UNUSUAL_DEV( 0x0421, 0x05af, 0x0742, 0x0742,
+ "Nokia",
+ "305",
t;>
>> receive setup data valid interrupt
>> find out the usb request field (bmRequestType, bRequest, wValue,
>> wIndex, wLength)
>> if (USB_CLEAR_FEATURE_REQUEST)
>> call usb_ep_queue()
>
> Don't you need to handle this in the hardware, just like
> U
> working right.
After i comment out the ep0_queue(fsg) in FSG_STATE_CONFIG_CHANGE case
of handle_exception(), the request does complete, but takes more time
to complete. And UDC driver queue function is still being called after
the Set-Config request.
Thanks,
Victor
--
To unsubscribe from this
d Logitech, Inc.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Thanks in advance.
--
Victor
On Thu, Sep 5, 2013 at 5:58 PM, Alan Stern wrote:
> On Thu, 5 Sep 2013, Victor Leschuk wrote:
>
>> Hello all,
formance of
g_mass_storage-emulated USB drive?
PS: I am using kernel
--
$ uname -rm
3.2.0-4-686-pae i686
--
Thanks in advance.
--
Victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a
Hi,
> Victor, if you can get hold of a USB bus analyzer, you would be able to
> see directly when the DATA1 packet does or does not get sent.
I am in the process of getting a USB bus analyzer.
> No -- the problem is that the UDC completes the Set-Config request
> before it shoul
d 00 61 00 73 00 73 00 20 00 53 00 74 00
0010: 6f 00 72 00 61 00 67 00 65 00
handle_exception begin
handle_exception wait until
handle_exception old_state 4
g_file_storage gadget: set interface 0
g_file_storage gadget: high-speed config #1
FSG_STATE_CONFIG_CHANGE 19 21 0
g_file_storage gadget: in handle_e
t out already by the host. So if the next request is Get-Config,
it will not return the latest config value.
Thanks,
victor
usbmon_july12.log
Description: Binary data
e_storage gadget: in fsg->running loop
g_file_storage gadget: in fsg->running loop
thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e exception, it
> calls do_set_config().
May i know which part of the do_set_config() or do_set_interface() has
to be run in process context?
Thanks,
Victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
; when the fsg thread handles the exception, it
> calls do_set_config().
>
> When your UDC driver calls the gadget driver's .setup() function, how
> does it handle the return value?
The code is as below:
status = dev->driver->setup(&dev->gadget, &usb_ctrlreq
the "Device Descriptor
> Test-Addressed State" can pass. It seems that Get-Config request from
> host cannot wait, so i have to return the latest config value in
> response to the request.
>
> Thanks,
> victor
In fact, the "Device Descriptor Test-Addressed State&
from
host cannot wait, so i have to return the latest config value in
response to the request.
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
00 00 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE; Dc=10, Dn=0;
Hc=10, Hn=0
g_file_storage gadget: ep0-setup, length 8:
: 80 08 00 00 00 00 01 00
g_file_storage gadget: get configuration
ept0 in queue len 0x1, buffer 0xc1289800
ep0_complete
g_file_storage
; if (fsg->config != 0) {
> DBG(fsg, "reset config\n");
> fsg->config = 0;
> rc = do_set_interface(fsg, -1);
> }
>
> /* Enable the interface */
> if (new_config != 0) {
>
onfig request with a config
> value of 0 is the second last USB request sent from the host. The last
> USB request is Get-Config, which still returns config value of 1.
In gadget driver, do_set_config(), if new_config is 0, the new_config
is not processed. So config value of zero will neve
second last USB request sent from the host. The last
USB request is Get-Config, which still returns config value of 1.
Thanks,
victor
# dmesg -c
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: i
1 > /sys/bus/usb/devices/.../bConfigurationValue", the
gadget is re-enumerated and re-appear in Linux host.
I also observe in gadget driver, there is only one config descriptor
with bConfigurationValue of 1. Is bConfigurationValue of 0 meant to
disble the device?
Thanks,
Victor
--
To unsubsc
000: 80 08 00 00 00 00 01 00
g_file_storage gadget: get configuration
g_file_storage gadget: ep0-in, length 1:
: 01
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
xception handling. Is
there any variable to track the USB device state of Figure 9-1 of the
USB 2.0 Spec? Now the gadget driver does not pass the "USB2.0 CV - Get
Device Descriptor - Address State test". So i am trying to find more
information.
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ndled by the UDC driver.
>
> Alan Stern
>
Should the UDC driver handle Get-Status before or after the call to fsg_setup()?
thanks,
victor
f2e9da80 3086290883 S Ci:1:001:0 s a3 00 0001 0004 4 <
f2e9da80 3086290911 C Ci:1:001:0 0 4 = 0001
f2e9da80 3086290919 S Ci:1:001:0 s a3 00 000
quest is not handled by the gadget driver. Isn't it so?
thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dget log.
> Normally, in high speed mode, the data of SCSI_MODE_SELECT_6 command
> is 24 byte.
The problem is in UDC driver. i made the change, it is ok now.
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ECT_6 command, when in
full speed mode, the data for SCSI_MODE_SELECT_6 command is 72 byte,
and somehow the gadget is reset. Is it because gadget is not able to
handle the amount of data? Please see the attached gadget log.
Normally, in high speed mode, the data of SCSI_MODE_SELECT_6 command
is 24 byt
e full speed), the
same problem of SCSI_READ_10 command asking 4096 bytes and gadget
returning the data, and gadget reset, still happens.
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
c. In UDC driver,
it is hardcorded to high speed in UDC driver start function. I changed
it to be set depending on hardware value. Now it is:
g_file_storage gadget: full-speed config #1
However, in usbmon, the SCSI_READ_10 command still requests for 4096
bytes of data, and this causes gadget to reset.
s 512 bytes, so i break
the 4096 bytes of data into 8 chunks of 512 bytes, before returning
them to Ubuntu. I guess it would not be the root cause, won't it?
thanks,
victor
# dmesg -c
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_e
n trace are attached in this
email. From the usbmon trace, the error (-108) is ESHUTDOWN from
SCSI_READ_10 command. From the gadget log, the last SCSI_READ_10
command is received twice. First time it is ok, second time it causes
some problem. Which side could cause the ESHUTDOWN error?
Thanks,
vi
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
Then the same process to get descriptors and receive SCSI commands are
repeated. Is the SCSI_READ_10 command or something else causing the
problem? Please see the attached gadget driver log.
Thanks,
Victor
[start_transfer] 0 0
er question, in ep0_complete():
if (req->status == 0 && req->context)
((fsg_routine_t) (req->context))(fsg);
Is req->context pointing to a function in UDC driver?
Thanks,
victor
# dmesg
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01
you notice the Set
Address request is not seen by the gadget driver? The Set Address
request is handled by the hardware. Could it be the root cause? As
gadget driver may expect the address information from the host, and
for now UDC driver just ignore the Set Address request ?
victor
--
To unsubscribe
t log. Does the log
indicate any problem that corresponds to the error message in Command
Verifier?
Thanks,
victor
# dmesg
g_file_storage gadget: disconnect or port reset
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 8a47aaf8
g_file_storage gadget: bulk-out, length 31:
0
Hi,
On Thu, May 30, 2013 at 10:44 PM, Alan Stern wrote:
> On Thu, 30 May 2013, victor yeo wrote:
>
>> I tested the g_zero with USB 2.0 Command Verifier. After the Command
>> Verifier is run, the UDC gadget driver queue function is continuously
>> being called, and the
and
Verifier is run, the UDC gadget driver queue function is continuously
being called, and the linux command prompt is frozen. Please see the
attached UDC driver log. It looks like endpoint 1 in direction is
called by USB 2.0 Command Verifier continuously. Is this weird?
thanks,
victor
# insmo
unction returning negative error code for BOS descriptor?
>
> The crash dump you attached contained this line:
>
> PC is at kagen2_irq+0x290/0x3bc [kagen2_udc]
>
> This means the crash occurred inside the UDC driver, not the gadget
> driver.
Yes, the problem was solved just no
> kagen2_ep_queue was called).
>
Now the UDC driver is working on both Linux and Windows host, meaning
the read/write operation is ok. I still use the polling method,
because waiting for interrupt is not reliable. Is it possible to
contribute the code to Linux community?
On the other hand, i
log shows:
g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442
g_file_storage gadget: bulk-in set wedge
Is it because the gadget expects 31 byte command, but 512 byte data is
received instead?
The full UDC/gadget log is attached. Hope it is useful. If not, i will
add in more printk state
mpt to be non-responsive because the
checking hardware register code is run continuously. If i add a
schedule() to the do-while loop, the kagen2_ep_queue() will not be
continued. How to go about fixing this dilemma?
thanks,
victor
--
To unsubscribe from this list: send the line "unsubscrib
me to tell you that.
>
> What you _do_ need is to find out why the crash occurred. This means
> finding out which pointer is NULL.
Thanks! Indeed, the req->buf pointer was the one causing the crash
problem. It happened when combining multiple 512 bytes data. I have
fixed this bug.
Now
)
r3:152a0e00 r2:a020d0e5
[] (kagen2_ep_queue+0x0/0x680 [kagen2_udc]) from
[] (bulk_in_complete+0x24c/0x1010 [g_file_storage])
The meaning of printk of "kagen2_ep_queue 512 16384 512" in UDC driver log:
ka_req->req.actual is 512
ka_req->req.length is 16384
length from hardware FIFO i
mplete() printout which is shown
below. The req->actual is 512 byte. The bh->bulk_out_intended_length
is 31. Is this a bug?
g_file_storage gadget: get_next_command
[start_transfer] 6f007442 7000
ept1 out queue len 0x200, buffer 0xc133
kagen2_ep_queue 512 512 512
g_file_storage gadget: bulk_out_complete --
es not correlate, right?
unsigned int rdata, rdata1;
// setup data valid
val = readl(dev->base_addr + 0+0xfb0/0x199c [kagen2_udc]
thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
> All I can tell is that the gadget got hung after receiving the second
> WRITE command. Can you figure out where it got hung and why?
>
> Victor, you don't seem to get the big pattern that keeps repeating
> here. Every time something does wrong, you tell me about it.
ill help if you enable
> CONFIG_PRINTK_TIME in the gadget's kernel.
Thanks, i will enable the CONFIG_PRINTK_TIME. Nonetheless, now the
gadget driver and UDC driver are able to process some SCSI_WRITE_10
commands (i ignore the USB reset interrupt in UDC driver). Please see
the attached
out, length 0:
g_file_storage gadget: bulk_out_complete --> 0, 0/512
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: handle_exception
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 40 00
.
Thanks,
victor
--
To unsubscrib
config
g_file_storage gadget: reset interface
g_file_storage gadget: handle_exception
"g_file_storage gadget: do_scsi_command" is from extra DBG statement
that i added in file_storage.c.
if (do_scsi_command(fsg) || finish_reply(fsg))
{
DBG(f
_lock_irqsave(&dev->lock, flags);
..
spin_unlock_irqrestore(&dev->lock, flags);
When kagen2_ep_queue function is called, the error "BUG: scheduling
while atomic: swapper/0/0x0002" occurs. I test the same spinlock
functions in other device module. It is o
bytes
> in each command should be 0, but they aren't. They are: c3 63 4a.
> Where did those values come from?
Yes, i haven't noticed the c3 63 4a. Clearly the last three bytes
should be zero. Maybe the UDC driver has a bug (Do the last 3 bytes
matter for file gadget? ). Here is the usbmon trace that corresponds
to the UDC log. It is the proof that the last three bytes are zero.
Thanks,
victor
scsi_write_10_again02.log
Description: Binary data
in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and
SCSI_WRITE_10. SCSI_WRITE_10 is not received properly.
Thanks,
victor
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 0d 01 00 00 12 00 00 00 80 00 06 03
0010: 00 00 00 12 00 00 00 00 00 00 00 00 c3 63 4a
g_file_storage gadget: SCSI
command is
>> received by UDC driver, processed by gadget driver, and UDC driver
>> sends out data and CSW to host. On usbmon trace, only one instance of
>> the SCSI_READ_10 is observed.
>
> This is probably because you are copying the same data from the FIFO to
>
unsubscribe linux-usb
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be
protected by legal privilege. If you are not the intended addressee (or
au
ed by UDC driver, processed by gadget driver, and UDC driver
sends out data and CSW to host. On usbmon trace, only one instance of
the SCSI_READ_10 is observed.
3) More severe case, if removing one printk statement in
bulk_in_complete(), USB gadget device cannot be recognised by host.
Thanks
packets from the host yet, how can you pass the packets to the
> gadget driver for processing?
>
> Alan Stern
>
For bulk out endpoint, I code the kagen2_ep_queue() to read the
packets from the USB hardware, then call bulk_out_complete() via
req->req.complete. Is this the correc
cessary to pass the packets to gadget driver for processing?
req->req.complete is mapped to bulk_out_complete() or
bulk_in_complete().
thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
f
> the connection were high speed, the second byte would be 05. See
> Section 11.24.2.7 in the USB-2.0 specification, and especially the
> description of bit 10 in Table 11-21 and 11.24.2.7.1.8.
Thanks, i found the bit 10 in Table 11-21 Port Status Field.
0 = Full-speed device attached to
full speed (12 Mb/s), not high speed (480 Mb/s) --
> which means that this line:
>
>> g_file_storage gadget: high-speed config #1
>
> in the gadget log indicates another bug in the UDC driver. It told the
> gadget driver that the connection was high speed, but the connection
> re
driver log
are attached.
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete --> 0, 0/31
I think UDC driver receives the zero length packet on bulk out endpoint.
Thanks,
victor
# dmesg
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_f
The
SCSI_WRITE_10 command often receives (-104). The usbmon trace showing
this failure is attached. Is the bulk-out endpoint unable to receive
command and data continuously, due to error in UDC driver?
Also, as in UDC driver log, sometimes the same SCSI_READ_10 command is
received repeatedly. It is
comparison, the CSW is sent out and received by the host.
> It looks like the UDC driver get hung up right here, somewhere inside
> the usb_ep_queue() routine.
I think the usb_ep_queue() routine is re-entrant. If one instance of
it hangs, the next instance will not be affected.
> At this
sfer() to read the next
CBW. After unknown command 0xa1 is received, and if UDC driver doesn't
halt the endpoint, why the get_next_command() does not call
start_transfer() to read the next CBW? Somehow, i don't understand.
Thanks,
victor
--
To unsubscribe from this list: send the line "
d UDC just by reading
> the usbmon log (which was recorded on the host).
>From the usbmon trace and driver log, i can only see that TEST UNIT
READY command is sent out but UDC driver does not receive it. May i
ask, under what circumstances, is gadget driver calling
start_transfer() to schedule reading from bulk-out endpoint ?
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2340 486236946 C Bi:2:060:1 -121 13 = 55534253 1200 0002 01
f3a2b7c0 486237000 S Bi:2:060:1 -115 13 <
f3a2b7c0 493408020 C Bi:2:060:1 -104 0
.
f3a2b7c0 493652682 S Bo:2:060:1 -115 31 = 55534243 1300
0600 0000 00
f3a2b7c0 493652755 C Bo:2:060:1
0xc133c000
>> 0: 0x53425355
>> 4: 0x12
>> 8: 0x200
>> bulk_in_complete --> 0, 13/13
>
> Instead this packet was sent.
>
> Alan Stern
Thanks! This packet is the CSW to the unknown SCSI command 0xa1. So it
should not be sent at all, and the UDC driver should sen
Bi:2:047:1 -115 13 <
I am lost. Every time i connect Linux host to the USB gadget,
different error scenario is shown in usbmon.
victor
scsi_read_10_again11.log
Description: Binary data
return usb_ep_set_halt(ep);
>
> That's when your UDC is supposed to set the Halt feature -- when its
> usb_ep_set_halt() function is called. If the controller is busy at
> this time because the bulk-in buffer is full, and it is unable to set
> the Halt feature, then usb
race 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
should have done a USB port
> reset. Either the host isn't performing the reset correctly or else
> your UDC driver didn't inform g_file_storage when the reset occurred.
Yes, the UDC driver didn't inform g_file_storage when the reset
occurred. What is to be done to
i insmod g_file_storage gadget with file=/mnt/sd/backing_file, the
SCSI_READ_10 command is still not working properly.
See the gadget log below. The g_file_storage gadget receives "SCSI
command: Unknown xa1" from the Linux host near the end of the log.
Something is wrong.
Thanks,
victor
g
acking_file
>
> Can i use an ordinary text file as the backing file?
I find a link which contains answers to my question above.
http://www.linux-usb.org/gadget/file_storage.html
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
those 0's could be unoccupied
> entries in a FAT.
For testing purpose, i would like to create a backing file, and then
use it with g_file_storage, such as below:
# modprobe g_file_storage file=/tmp/backing_file
Can i use an ordinary text file as the backing file?
Thanks,
victor
--
To unsubs
f59e1340 2705432233 C Bi:2:007:1 0 4096 =
f59e12c0 2705432234 C Bi:2:007:1 0 4096 =
f59e1540 2705432234 C Bi:2:007:1 0 4096 = 0
the
>> processing of it. In this case, 0x2000 is the FAT boot sector.
>> Shouldn't gadget driver read from MBR (master boot record) as LBA of
>> zero corresponds to MBR?
>
> The gadget driver reads from whatever you tell it to read. When you
> load g-file-storage, what
_read() in do_read() is passed in as 0. It reaches SD driver with
argument of 0x2002, . Somehow, the address got passed wrongly in the
processing of it. In this case, 0x2000 is the FAT boot sector.
Shouldn't gadget driver read from MBR (master boot record) as LBA of
zero corresponds to MBR?
T
55534243 0f00 0010
8a28 ed29 0008 00
f31a9740 4037133176 C Bo:2:071:1 0 31 >
f4a552c0 4037133184 S Bi:2:071:1 -115 4096 <
f4a552c0 4037184441 C Bi:2:071:1 0 4096 = ffff
f31a9740 4037184453 S
things.
Yes, the very first READ(10) command has a logical block address of 0
(as shown below). I will generate the fresh usbmon trace the next
day, i do not have access to the platform now.
f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010
8a28 0008 0
. So is the gadget
driver designed to work with SCSI/SATA/ATA drive only?
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 - 100 of 161 matches
Mail list logo
