Could not write to device, result == -1 errno 0 null

[kuza2010]

Hi, @magnusja Libaums version 0.7.3

Hardware devices:

• usb device 1: SanDisk dual-drive 128Gb with Fat32, 32/64 Kb cluster size;
• usb device 2: JetFlash 8Gb with Fat32, 32/4 Kb cluster size;
• android version 9(Samsung Galaxy S10e)/8(Xiaomi Redmi 5 Plus)

Problem

I try to copy about 1000 mixed size/type files (total size 2 Gb).

Expected behavior

Files were copied correctly.

Actual behavior

java.io.IOException: Could not write to device, result == -1 errno 0 null

Stacktrace of Excpetion

Code where problem occurs

UsbFileOutputStream.write(bytes);

Any hints!

Thanks a lot!

[magnusja]

Hey there,

I think this is realted to https://github.com/EtchDroid/EtchDroid/issues/10

Apparently under Pie this issue has gotten a lot worse. @Depau and I are working on a fix but as we are quite busy, this can still take a while. I hope I will have some time over the Christmas break.

[kuza2010]

Hey, it seems good. From my side, I will continue to investigate the issue. Any questions, feel free!

Thanks a lot!

[depau]

Hi, yep it looks like that issue.

Sadly I haven't been able to work on it the last few months. Hopefully I'll have some time in February, definitely not before that :(

[kuza2010]

Hi, Also, I found several similar problems:

• stack overflow
• felHR85/UsbSerial

I will try those tips and let you know if it works well for me.

[depau]

Those two links look unrelated to me.

In case anybody wants to dig into this issue and write some code before @magnusja and I have time, a few hints:

Here's some badly-taken notes: https://notes.depau.eu/ZkErsTYJQLC7AQJhcyn7VA#resetRecovery

Here's some sample code that needs testing and refinement. DO NOT blindly copy-paste, thanks ;)

private void resetRecovery() {
    bulkOnlyMassStorageReset();
    clearFeatureHALT(this.epIn);
}

private void bulkOnlyMassStorageReset() {
    byte[] bArr = new byte[2];
    // REQUEST_BULK_ONLY_MASS_STORAGE_RESET = 255
    // REQUEST_TYPE_BULK_ONLY_MASS_STORAGE_RESET = 33
    int controlTransfer = this.usbConn.controlTransfer(33, 255, 0, this.usbInterface.getId(), bArr, 0, 1000);
    // check if it succeeded
}

private void clearFeatureHalt(UsbEndpoint usbEndpoint) {
    byte[] bArr = new byte[2];
    int address = usbEndpoint.getAddress();
    // REQUEST_CLEAR_FEATURE = 1
    // REQUEST_TYPE_CLEAR_FEATURE = 2
    int controlTransfer = this.usbConn.controlTransfer(2, 1, 0, address, bArr, 0, 1000);
    // check if it succeeded
}

We basically need to implement these recovery reset methods. Whenever bulkOutTransfer returns -1 but errno is 0 or EPIPE, a reset must be done and a new attempt performed.

I think the "reset required detection" logic is best if implemented in ScsiBlockDevice.kt.

I would then place the actual reset methods in UsbCommunication.kt and its implementations. This way we can easily change implementations to work around different Android versions shenanigans; also we get a UsbEndpoint and UsbConnection for free.

Note that, however, we also require a UsbInterface reference. This is not available at the time in UsbCommunication, so you will need to patch UsbCommunicationFactory.kt and UsbMassStorageDevice.kt to hand it over.

@magnusja please review ↑ :)

[mannyzhao]

Hey, it seems good. From my side, I will continue to investigate the issue. Any questions, feel free!

Thanks a lot! hey,Have you solved this problem, man

[kuza2010]

Hey, it seems good. From my side, I will continue to investigate the issue. Any questions, feel free! Thanks a lot! hey,Have you solved this problem, man

Hi, @mannyzhao! Sorry to keep you waiting. Unfortunately no. I am still trying to find a solution

[magnusja]

Hey guys, can you please try https://github.com/magnusja/libaums/pull/240

[depau]

Well...

This is Android 10 though :P I'm going to test it on my old phone with Android 9, and maybe set a few logging breakpoints to see if the new code is actually reached.

[depau]

I can confirm it works on Android 9 too. However, I haven't seen the message logged for the reset procedure. The whole thing is quite weird.

I'll test it on the emulator, on which is was 100% required for whatever reason.

[depau]

Nope, the issue eventually occurred and it looks like the patch didn't help:

D/ScsiBlockDevice: inquiry response: ScsiInquiryResponse [peripheralQualifier=0, peripheralDeviceType=0, removableMedia=false, spcVersion=6, responseDataFormat=2]
I/ScsiBlockDevice: Block size: 512
    Last block address: 31735807
E/ScsiBlockDevice: error transferring command, sending bulk only reset
E/ScsiBlockDevice: error transferring command, sending bulk only reset
E/ScsiBlockDevice: error transferring command, sending bulk only reset
E/UsbApiImgWriteService: Could't write image to Depau EtchDrive
    eu.depau.etchdroid.utils.exception.UsbWriteException: Write failed at block 1525760, 781.2 MB written. Error: java.io.IOException: Could not write to device, result == -1 errno 0 null
        at eu.depau.etchdroid.services.UsbApiWriteService.writeInputStream(UsbApiWriteService.kt:76)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeImage(UsbApiWriteService.kt:107)
        at eu.depau.etchdroid.services.UsbWriteService.onHandleIntent(UsbWriteService.kt:36)
        at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:78)
        at android.os.Handler.dispatchMessage(Handler.java:107)
        at android.os.Looper.loop(Looper.java:214)
        at android.os.HandlerThread.run(HandlerThread.java:67)
     Caused by: java.io.IOException: Could not write to device, result == -1 errno 0 null
        at com.github.mjdev.libaums.usb.JellyBeanMr2Communication.bulkOutTransfer(JellyBeanMr2Communication.kt:35)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.transferOneCommand(ScsiBlockDevice.kt:186)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.transferCommand(ScsiBlockDevice.kt:140)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.write(ScsiBlockDevice.kt:250)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeInputStream(UsbApiWriteService.kt:74)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeImage(UsbApiWriteService.kt:107) 
        at eu.depau.etchdroid.services.UsbWriteService.onHandleIntent(UsbWriteService.kt:36) 
        at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:78) 
        at android.os.Handler.dispatchMessage(Handler.java:107) 
        at android.os.Looper.loop(Looper.java:214) 
        at android.os.HandlerThread.run(HandlerThread.java:67) 
D/UsbMassStorageDevice: close device
D/UsbDeviceConnectionJNI: close

[depau]

So, if this doesn't work, I think our last options are:

• access UsbDeviceConnection.resetDevice() using reflection (it should do a port reset unless I'm missing something)
• open the USB device, get the file descriptor, throw all the java crap away and use libusb

I'm aware of this policy, though trying is definitely easier than reimplementing the USB communication with raw libusb. If it doesn't work it should simply pretend the method does not exist, so handling that should be fine (in the sense that it won't get any worse than the current behavior).

Side note: it's quite tedious for me to develop changes and test them on EtchDroid as I have to rebuild the shim in the middle and stuff. @kuza2010, did the issue occur to you in the libaums demo app? Does somebody have some steps to reproduce it in the demo app?

[magnusja]

Hey @Depau,

thanks a lot for testing. Well that is too bad :/ I will implement the first option, we can still think about the second one. We can also only move the reset then to native code. What essentially is happening is this: https://android.googlesource.com/platform/system/core/+/master/libusbhost/usbhost.c?autodive=0#682 This can be easily implement keeping the whole Kotlin (as of now :D) code!

[magnusja]

I pushed some more changes if someone wants to try again...

[depau]

thanks a lot for testing. Well that is too bad :/ I will implement the first option, we can still think about the second one. We can also only move the reset then to native code. What essentially is happening is this: https://android.googlesource.com/platform/system/core/+/master/libusbhost/usbhost.c?autodive=0#682 This can be easily implement keeping the whole Kotlin (as of now :D) code!

Yeah, an IOCTL should be doable from Java/Kotlin.

Anyway, nope, it doesn't help:

I/UsbMassStorageDevice: MAX LUN 0
D/ScsiBlockDevice: inquiry response: ScsiInquiryResponse [peripheralQualifier=0, peripheralDeviceType=0, removableMedia=false, spcVersion=6, responseDataFormat=2]
I/ScsiBlockDevice: Block size: 512
    Last block address: 31735807
W/depau.etchdroi: JNI critical lock held for 65.871ms on Thread[5,tid=8545,Runnable,Thread*=0x6fa76c0c00,peer=0x12fc0040,"IntentService[UsbApiImgWriteService]"]
E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: sending bulk only mass storage request
W/AndroidUsbCommunication: sending clear feature halt
W/AndroidUsbCommunication: sending clear feature halt
E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: sending bulk only mass storage request
W/AndroidUsbCommunication: sending clear feature halt
W/AndroidUsbCommunication: sending clear feature halt
E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: sending bulk only mass storage request
W/AndroidUsbCommunication: sending clear feature halt
W/AndroidUsbCommunication: sending clear feature halt
E/UsbApiImgWriteService: Could't write image to Depau EtchDrive
    eu.depau.etchdroid.utils.exception.UsbWriteException: Write failed at block 0, 0.0 B written. Error: java.io.IOException: Could not write to device, result == -1 errno 0 null
        at eu.depau.etchdroid.services.UsbApiWriteService.writeInputStream(UsbApiWriteService.kt:76)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeImage(UsbApiWriteService.kt:107)
        at eu.depau.etchdroid.services.UsbWriteService.onHandleIntent(UsbWriteService.kt:36)
        at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:78)
        at android.os.Handler.dispatchMessage(Handler.java:107)
        at android.os.Looper.loop(Looper.java:214)
        at android.os.HandlerThread.run(HandlerThread.java:67)
     Caused by: java.io.IOException: Could not write to device, result == -1 errno 0 null
        at com.github.mjdev.libaums.usb.JellyBeanMr2Communication.bulkOutTransfer(JellyBeanMr2Communication.kt:35)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.transferOneCommand(ScsiBlockDevice.kt:191)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.transferCommand(ScsiBlockDevice.kt:142)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.write(ScsiBlockDevice.kt:255)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeInputStream(UsbApiWriteService.kt:74)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeImage(UsbApiWriteService.kt:107) 
        at eu.depau.etchdroid.services.UsbWriteService.onHandleIntent(UsbWriteService.kt:36) 
        at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:78) 
        at android.os.Handler.dispatchMessage(Handler.java:107) 
        at android.os.Looper.loop(Looper.java:214) 
        at android.os.HandlerThread.run(HandlerThread.java:67) 
D/UsbMassStorageDevice: close device
D/UsbDeviceConnectionJNI: close

[depau]

BTW I'm going to implement the ioctl thing and see if it works.

[magnusja]

I actually implemented that already so dont bother. I forgot to push I guess, but will do now!

[magnusja]

https://github.com/magnusja/libaums/pull/240/commits/aa50b40dde8e096157bbcd478e0ac6512f4f0598

[depau]

Ah damn I reimplemented it in the meantime :/ I'll pull your changes and test it again.

[depau]

Nope :(

D/UsbMassStorageDevice: setup device
I/UsbMassStorageDevice: MAX LUN 0
D/ScsiBlockDevice: inquiry response: ScsiInquiryResponse [peripheralQualifier=0, peripheralDeviceType=0, removableMedia=false, spcVersion=6, responseDataFormat=2]
I/ScsiBlockDevice: Block size: 512
    Last block address: 31735807
E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: sending bulk only mass storage request
W/AndroidUsbCommunication: sending clear feature halt
W/AndroidUsbCommunication: sending clear feature halt
W/AndroidUsbCommunication: Native reset
D/UsbDocumentProvider: detachDevice() UsbDevice[mName=/dev/bus/usb/001/002,mVendorId=3544,mProductId=12801,mClass=0,mSubclass=0,mProtocol=0,mManufacturerName=Depau,mProductName=EtchDrive,mVersion=11.00,mSerialNumberReader=android.hardware.usb.IUsbSerialReader$Stub$Proxy@a11f61b,mConfigurations=[
    UsbConfiguration[mId=1,mName=null,mAttributes=128,mMaxPower=50,mInterfaces=[
    UsbInterface[mId=0,mAlternateSetting=0,mName=null,mClass=8,mSubclass=6,mProtocol=80,mEndpoints=[
    UsbEndpoint[mAddress=1,mAttributes=2,mMaxPacketSize=512,mInterval=0]
    UsbEndpoint[mAddress=130,mAttributes=2,mMaxPacketSize=512,mInterval=0]]]]
E/UsbApiImgWriteService: Could't write image to Depau EtchDrive
    eu.depau.etchdroid.utils.exception.UsbWriteException: Write failed at block 0, 0.0 B written. Error: java.io.IOException: native reset unsuccessful!
        at eu.depau.etchdroid.services.UsbApiWriteService.writeInputStream(UsbApiWriteService.kt:76)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeImage(UsbApiWriteService.kt:107)
        at eu.depau.etchdroid.services.UsbWriteService.onHandleIntent(UsbWriteService.kt:36)
        at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:78)
        at android.os.Handler.dispatchMessage(Handler.java:107)
        at android.os.Looper.loop(Looper.java:214)
        at android.os.HandlerThread.run(HandlerThread.java:67)
     Caused by: java.io.IOException: native reset unsuccessful!
        at com.github.mjdev.libaums.usb.AndroidUsbCommunication.resetRecovery(AndroidUsbCommunication.kt:41)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.transferCommand(ScsiBlockDevice.kt:149)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.write(ScsiBlockDevice.kt:255)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeInputStream(UsbApiWriteService.kt:74)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeImage(UsbApiWriteService.kt:107) 
        at eu.depau.etchdroid.services.UsbWriteService.onHandleIntent(UsbWriteService.kt:36) 
        at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:78) 
        at android.os.Handler.dispatchMessage(Handler.java:107) 
        at android.os.Looper.loop(Looper.java:214) 
        at android.os.HandlerThread.run(HandlerThread.java:67) 
D/UsbMassStorageDevice: close device
E/UsbMassStorageDevice: could not release interface!
D/UsbDeviceConnectionJNI: close

Also after the "native reset" the USB does not show up any more when querying for USB devices. (which is good to know cause I might just reset the device after writing the image successfully, so people stop complaining that their USB drive is broken when Android says the filesystem is unsupported)

[magnusja]

Ah snap, that is a pity.

So this guy (https://raspberrypi.stackexchange.com/a/36664) says that we might wanna ignore the unsuccessful reset. Maybe you can comment this out (https://github.com/magnusja/libaums/pull/240/files#diff-c624845c950d217d9416054a1cb06616R41) and see what happens? Other than that I am unsure what might be worth trying next :/

[magnusja]

Might be also worth a try only doing this native reset instead of the bulk only reset and the clear feature halt.

[depau]

I tested the code in that thread on my computer on a USB drive.

(Here's my adapted code)

#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    char devicename[1024];
    const char *filename = devicename;
    int fd;

    if ( 2 > argc || 3 < argc ) {
        printf("Give USB device name as parameter\n");
        return 1;
    }

    if ( 2 == argc ) 
        filename = argv[1];
    else
        sprintf( devicename, "/dev/bus/usb/%s/%s", argv[1], argv[2] );

    printf( "Resetting USB device '%s'\n", filename );

    fd = open(filename, O_WRONLY);
    if (fd <= 0) {
        perror("USB device open failed");
        return 2;
    }
    if (ioctl((long) fd, USBDEVFS_RESET, 0) == -1) {
        // Don't care!  It usually does, when we need to reset it.
        perror("USBDEVFS_RESET device ioctl error");
        //exit(3);
    }
    close(fd);
    return 0;
}

Results: sometimes the ioctl succeeds and I get this:

[125565.446601] usb 2-1: reset SuperSpeed Gen 1 USB device number 5 using xhci_hcd

Sometimes it fails:

Resetting USB device '/dev/bus/usb/001/067'
USBDEVFS_RESET device ioctl error: No such device

and when that happens

[126888.902296] usb 1-1: USB disconnect, device number 67
[126889.025746] usb 2-1: new SuperSpeed Gen 1 USB device number 7 using xhci_hcd

Which makes me fear we need to move deviceConnection = usbManager.openDevice(usbDevice) etc from UsbMassStorageDevice to AndroidUsbCommunication, as in the second case we have to reopen it (hopefully we already have permissions).

I'm currently fighting with gradle, I'll see what I can do.

[depau]

I'm noticing that, for whatever reason, I'm getting almost always successfully writes while back then I would only be able to write ~500MB before it would show the issue.

Anyway I was tired of not seeing errors so I built the utility for Android and used it to reset the USB drive while the app was writing, which triggered the new code of course.

I'm testing with a bunch of commits on top of your changes: https://github.com/Depau/libaums/tree/feature/bulk-only-reset

Kernel log with comments:

# Manually performed reset
[ 2483.339314] usb 1-1: reset high-speed USB device number 3 using xhci-hcd
[ 2483.463313] xhci-hcd xhci-hcd.0.auto: xHCI xhci_drop_endpoint called with disabled ep 0000000000000000
[ 2483.463362] xhci-hcd xhci-hcd.0.auto: xHCI xhci_drop_endpoint called with disabled ep 0000000000000000
[ 2483.480856] xhci-hcd xhci-hcd.0.auto: hcd->state:1
[ 2483.482825] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 2483.487379] scsi host11: usb-storage 1-1:1.0
# Resets performed by the app
[ 2483.611162] usb 1-1: reset high-speed USB device number 3 using xhci-hcd
[ 2483.740874] xhci-hcd xhci-hcd.0.auto: xHCI xhci_drop_endpoint called with disabled ep 0000000000000000
[ 2483.740930] xhci-hcd xhci-hcd.0.auto: xHCI xhci_drop_endpoint called with disabled ep 0000000000000000
[ 2483.754864] xhci-hcd xhci-hcd.0.auto: hcd->state:1
[ 2484.982369] scsi 11:0:0:0: Direct-Access     Depau    EtchDrive        1100 PQ: 0 ANSI: 6
[ 2485.001798] sdg: sdg1 sdg2
[ 2487.262678] usb 1-1: usbfs: process 15663 (IntentService[U) did not claim interface 0 before use
[ 2487.372826] usb 1-1: reset high-speed USB device number 3 using xhci-hcd
[ 2487.500100] xhci-hcd xhci-hcd.0.auto: xHCI xhci_drop_endpoint called with disabled ep 0000000000000000
[ 2487.500169] xhci-hcd xhci-hcd.0.auto: xHCI xhci_drop_endpoint called with disabled ep 0000000000000000
[ 2487.508317] xhci-hcd xhci-hcd.0.auto: hcd->state:1
[ 2491.015012] usb 1-1: usbfs: process 15663 (IntentService[U) did not claim interface 0 before use
[ 2491.126074] usb 1-1: reset high-speed USB device number 3 using xhci-hcd
[ 2491.252629] xhci-hcd xhci-hcd.0.auto: xHCI xhci_drop_endpoint called with disabled ep 0000000000000000
[ 2491.252682] xhci-hcd xhci-hcd.0.auto: xHCI xhci_drop_endpoint called with disabled ep 0000000000000000
[ 2491.269768] xhci-hcd xhci-hcd.0.auto: hcd->state:1
[ 2494.777149] usb 1-1: usbfs: process 15663 (IntentService[U) did not claim interface 0 before use

All ioctls succeeded so it didn't act like the drive was reinserted:

E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: Native reset
W/AndroidUsbCommunication: ioctl returned true; errno 0 null; ignoring
E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: Native reset
W/AndroidUsbCommunication: ioctl returned true; errno 0 null; ignoring
E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: Native reset
W/AndroidUsbCommunication: ioctl returned true; errno 0 null; ignoring
E/UsbApiImgWriteService: Could't write image to Depau EtchDrive
    eu.depau.etchdroid.utils.exception.UsbWriteException: Write failed at block 161792, 82.8 MB written. Error: java.io.IOException: Could not write to device, result == -1 errno 0 null
        at eu.depau.etchdroid.services.UsbApiWriteService.writeInputStream(UsbApiWriteService.kt:76)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeImage(UsbApiWriteService.kt:107)
        at eu.depau.etchdroid.services.UsbWriteService.onHandleIntent(UsbWriteService.kt:36)
        at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:76)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loop(Looper.java:193)
        at android.os.HandlerThread.run(HandlerThread.java:65)
     Caused by: java.io.IOException: Could not write to device, result == -1 errno 0 null
        at com.github.mjdev.libaums.usb.JellyBeanMr2Communication.bulkOutTransfer(JellyBeanMr2Communication.kt:35)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.transferOneCommand(ScsiBlockDevice.kt:170)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.transferCommand(ScsiBlockDevice.kt:142)
        at com.github.mjdev.libaums.driver.scsi.ScsiBlockDevice.write(ScsiBlockDevice.kt:255)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeInputStream(UsbApiWriteService.kt:74)
        at eu.depau.etchdroid.services.UsbApiWriteService.writeImage(UsbApiWriteService.kt:107) 
        at eu.depau.etchdroid.services.UsbWriteService.onHandleIntent(UsbWriteService.kt:36) 
        at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:76) 
        at android.os.Handler.dispatchMessage(Handler.java:106) 
        at android.os.Looper.loop(Looper.java:193) 
        at android.os.HandlerThread.run(HandlerThread.java:65) 
D/UsbMassStorageDevice: close device
E/UsbMassStorageDevice: could not release interface!
D/UsbDeviceConnectionJNI: close
D/UsbApiImgWriteService: Written 0 bytes to Depau EtchDrive using API
W/System: A resource failed to call close. 

I'll try moving the opening code inside the communication class, so the USB connection can eventually be reopened after reset.

[depau]

It works! The sequence reset -> close -> open seems to do it. I was able to reset the device multiple times while it was writing, libaums would handle it gracefully by performing the recovery procedure.

I re-dumped the image from the USB drives and checksums were correct :tada:

At some point while testing my injected ioctl failed, though, so the device showed up as a new device. This probably needs to be handled at a higher level, like a physical reconnection.

EDIT: nevermind, I tried on my other device and this happens:

E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: Native reset
W/AndroidUsbCommunication: ioctl returned true; errno 0 null; ignoring
E/AndroidUsbCommunication: could not release interface!
D/UsbDeviceConnectionJNI: close
D/AndroidUsbCommunication: setup device
E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: Native reset
W/AndroidUsbCommunication: ioctl returned true; errno 0 null; ignoring
E/AndroidUsbCommunication: could not release interface!
D/UsbDeviceConnectionJNI: close
D/AndroidUsbCommunication: setup device
E/ScsiBlockDevice: error transferring command, sending bulk only reset
W/AndroidUsbCommunication: Native reset
W/AndroidUsbCommunication: ioctl returned true; errno 0 null; ignoring
E/AndroidUsbCommunication: could not release interface!
D/UsbDeviceConnectionJNI: close
D/AndroidUsbCommunication: setup device

I can't get the kernel logs from this one as it's not rooted, so I have to do that first.

[magnusja]

Hey @Depau

thanks a lot for your help and all the debugging! I guess you could call that progress at least :D If it is working reliably on one of your devices I guess it till makes sense merging this.

Let me know if you know something more about the failing device. Thanks!

[depau]

I'm currently not able to root it for whatever reason I'm not aware of. I'll try it again on QEMU and see if I'm able to reproduce it there. If not, I don't think I'll be able to work on it any more for this month :/

[depau]

Alright, it looks like trying over and over to reset the device works some times, I saw it resume writing after one or two attempts. In one test it halted a few times and recovered again.

Sometimes though, the reset ioctl fails and the USB device "disappears".

I think that for the time being the changes can be merged; in the worst case the USB device will "disappear". In the best case the communication will resume.

Ultimately, looking at libusb code, I think that eventually wrapping it would solve lot of issues and that it might be worth spending time on that. They seem to have a lot of checks for "suspiciously specific" issues and comparing libusb and the Android usbhost lib it looks like Android is taking a lot of shortcuts (see libusb's reset device vs Android's for example)

[magnusja]

Hey @Depau

so I merged and released a new version to see if people still open bug reports regarding this error :D

In general I like the idea with libusb, but I am not sure how this is affecting the license as LGPL is quite restrictive I think. In addition all the Linux fs implementations are under GPL which would make closed apps using lbaums impossible unfortunately.

@kuza2010 @mannyzhao please try latest version

[depau]

In general I like the idea with libusb, but I am not sure how this is affecting the license as LGPL is quite restrictive I think

IANAL but according to this, linking is fine even with proprietary software as linking to an LGPL-licensed library is not considered derivative work. So for libaums itself should be fine.

Thinking about it, even proprietary software using libaums should be good too, as long as they stay compliant with the LGPL license too i.e. by publishing changes made to libusb itself and only those (not those made to libaums). In general it seems that it's the same as if the other program itself were linking to it.

Anyway it's up to you, let me know what's your decision :)