Author Message

<  Everything Coding  ~  Why "read_bulk" need to do "usb_bulk_read" twice?

PostPosted: Mon Jan 27, 2014 9:40 am Reply with quote
Posts: 7 Joined: Mon Jan 27, 2014 9:27 am
Hi,

I'm using usb-modeswitch-1.2.6 pakage. And I found the source code of "read_bulk" is :
int read_bulk(int endpoint, char *buffer, int length)
{
int ret;
ret = usb_bulk_read(devh, endpoint, buffer, length, 3000);
usb_bulk_read(devh, endpoint, buffer, 13, 100);
if (ret >= 0 ) {
SHOW_PROGRESS(output," OK, response successfully read (%d bytes).\n", ret);
} else
if (ret == -19) {
SHOW_PROGRESS(output," Device seems to have vanished after reading. Good.\n");
} else
SHOW_PROGRESS(output," Response reading got error %d\n", ret);
return ret;

}

Why need to do "usb_bulk_read" twice? one of them with fix length to 13. And the judge result is from the first "usb_bulk_read" with length as input. I checked the newest release usb-modeswitch-2.0.1. It change to call "usb_bulk_io" but still call twice.
Please help me.
Thanks.


Offline
PostPosted: Mon Jan 27, 2014 5:11 pm Reply with quote
Site Admin Posts: 6378 Joined: Sat Nov 03, 2007 12:30 am
This is the reading of the status as specified in the USB mass storage reference.

http://www.usb.org/developers/devclass_ ... ulk_10.pdf

See "5.2 Command Status Wrapper (CSW)"

We throw away the result but read it anyway to be compliant to the standard.

It's true that the error reporting is somewhat flawed; I'll correct it.


Offline
PostPosted: Tue Jan 28, 2014 3:24 am Reply with quote
Posts: 7 Joined: Mon Jan 27, 2014 9:27 am
Josh wrote:
This is the reading of the status as specified in the USB mass storage reference.

http://www.usb.org/developers/devclass_ ... ulk_10.pdf

See "5.2 Command Status Wrapper (CSW)"

We throw away the result but read it anyway to be compliant to the standard.

It's true that the error reporting is somewhat flawed; I'll correct it.



Thanks.

I found an issue when mode switch my ZTE-MF631. In the "read_bulk", ret is -145 and mode switch stopped and failed. But if I modified as follow, which is ignore the ret value. The device can be switched successfully. Have you ever meet such issue? Could you give me some suggestion? Thanks again.

INT32 read_bulk(int endpoint, CHAR *buffer, int length)
{
INT32 ret;

ret = usb_bulk_read(devh, endpoint, buffer, length, 3000);

usb_bulk_read(devh, endpoint, buffer, 13, 100);
#if 0
if (ret >= 0 )
{
OssUserLogError(" OK, response successfully read (%d bytes).\n", ret);
}
else if (ret == -19)
{
OssUserLogError(" Device seems to have vanished after reading. Good.\n");
}
else
{
OssUserLogError(" Response reading got error %d\n", ret);
}
return ret;
#else
return 0;
#endif
}


Offline
PostPosted: Tue Jan 28, 2014 6:59 pm Reply with quote
Posts: 1158 Joined: Wed Jul 11, 2012 3:14 pm Location: Koh Samui, TH
Sonya@zte wrote:
I found an issue when mode switch my ZTE-MF631. In the "read_bulk", ret is -145 and mode switch stopped and failed. But if I modified as follow, which is ignore the ret value. The device can be switched successfully. Have you ever meet such issue? Could you give me some suggestion? Thanks again.



I have seen this error before and it is sometimes harmless, depending on when/where it occurs.
It is an error (ECONNREFUSED, Connection refused) which normally should not happen unless there is
something wrong in the usb stack,the usb host controller, or in an usb device.

Can you tell a bit about the hardware you get this error on, the linux version, and also paste the usb_modeswitch log.
What is the default usb id (before switching) of your MF631, 19d2:2000 ?


Offline
PostPosted: Tue Jan 28, 2014 9:01 pm Reply with quote
Site Admin Posts: 6378 Joined: Sat Nov 03, 2007 12:30 am
After taking a closer look at the code, I came to the conclusion that the CSW reading inside the "read_bulk" is a bogus left-over from testing. So thank you for pointing it out.

Usually, the "NeedResponse" parameter controls the issuing of the CSW request during the sending of "MessageContents". If the parameter is set, the CSW request is initiated by the "switchSendMessage" function, by using "read_bulk" again - so an implicit response request inside that function is totally redundant.

In theory, it should not affect the switching process - but who knows?

Just comment the one line out:
Code:
//    usb_bulk_read(devh, endpoint, buffer, 13, 100);

You can also try to remove the config parameter "NeedResponse" so that no CSW is requested at all. I recommend this only for a single MessageContent. If you need to send a sequence, the CSW should always be requested.

Any error returned from a bulk I/O request is interpreted as a probable switching success. It's no problem to treat some return codes as special, should the need arise.
Error 19 means "No such device" and is a clear indication of a successful mode switch initialization.

Error 145 (which I can't find in Linux' errno.h) is explained elsewhere as BSD "timeout", but in reference to networking. I'm not sure this applies to your system.


Offline
PostPosted: Tue Mar 11, 2014 11:14 am Reply with quote
Posts: 7 Joined: Mon Jan 27, 2014 9:27 am
Josh wrote:
After taking a closer look at the code, I came to the conclusion that the CSW reading inside the "read_bulk" is a bogus left-over from testing. So thank you for pointing it out.

Usually, the "NeedResponse" parameter controls the issuing of the CSW request during the sending of "MessageContents". If the parameter is set, the CSW request is initiated by the "switchSendMessage" function, by using "read_bulk" again - so an implicit response request inside that function is totally redundant.

In theory, it should not affect the switching process - but who knows?

Just comment the one line out:
Code:
//    usb_bulk_read(devh, endpoint, buffer, 13, 100);

You can also try to remove the config parameter "NeedResponse" so that no CSW is requested at all. I recommend this only for a single MessageContent. If you need to send a sequence, the CSW should always be requested.

Any error returned from a bulk I/O request is interpreted as a probable switching success. It's no problem to treat some return codes as special, should the need arise.
Error 19 means "No such device" and is a clear indication of a successful mode switch initialization.

Error 145 (which I can't find in Linux' errno.h) is explained elsewhere as BSD "timeout", but in reference to networking. I'm not sure this applies to your system.



Hi Josh,

Sorry for long time no update. I'm starting to work on the issue again.

If the function deviceInquire() return >=0, then InquireDevice = 2. Later, in the funtion switchSendMessage(), it won't do usb_claim_interface if ten InquireDevice = 2. But it will do usb_release_interface.

So I need you to help me this question:
usb_claim_interface and usb_release_interface should keep be a couple, right?
Please help me cause my environment will always show that "usbfs: process xxx did not claim interface 0 before use" and mode switch failed.

Thanks again.


Offline
PostPosted: Tue Mar 11, 2014 11:21 am Reply with quote
Posts: 7 Joined: Mon Jan 27, 2014 9:27 am
LOM wrote:
Sonya@zte wrote:
I found an issue when mode switch my ZTE-MF631. In the "read_bulk", ret is -145 and mode switch stopped and failed. But if I modified as follow, which is ignore the ret value. The device can be switched successfully. Have you ever meet such issue? Could you give me some suggestion? Thanks again.



I have seen this error before and it is sometimes harmless, depending on when/where it occurs.
It is an error (ECONNREFUSED, Connection refused) which normally should not happen unless there is
something wrong in the usb stack,the usb host controller, or in an usb device.

Can you tell a bit about the hardware you get this error on, the linux version, and also paste the usb_modeswitch log.
What is the default usb id (before switching) of your MF631, 19d2:2000 ?


Thanks, LOM.

Yes,19d2:2000. This issue is delayed since another issue need to resolve first. Later I will update the log. My linux version is very old, 2.6.30.


Offline
PostPosted: Tue Mar 18, 2014 7:38 am Reply with quote
Site Admin Posts: 6378 Joined: Sat Nov 03, 2007 12:30 am
Sonya@zte,

it looks like you have found annother bug.

The idea of setting "InquireDevice" to 2 was to claim the storage interface only once for all bulk traffic.

The "deviceInquire" function is supposed to keep the interface claimed if a "MessageContent" is provided for the mode switching. The following call to "switchSendMessage" will notice the value 2 of "InquireDevice" and assume that the interface is already claimed.

However, there is a pair of brackets missing at the end of the "deviceInquire" function, after the "out:" mark. This is how it should have looked like:
Code:
out:
    if (strlen(MessageContent) == 0) {
        libusb_clear_halt(devh, MessageEndpoint);
        libusb_release_interface(devh, Interface);
    }

The indentation was correct but useless ... So the bug caused the interface to be always released after a call to "deviceInquire" ...

Thanks for the find!


Offline

Display posts from previous:  Sort by:

All times are UTC+02:00
Page 1 of 1
8 posts
Users browsing this forum: No registered users and 1 guest
Search for:
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum