libusbhsfs
libusbhsfs copied to clipboard
DarkMatterCore
Doesn't work on Western Digital Elements SE Portable (WDBABV)
Describe the bug Applications hangs with Western Digital Elements SE Portable (WDBABV). I tried both 500GB and 1TB variants
To Reproduce Steps to reproduce the behavior: Connect a Western Digital Elements SE Portable (WDBABV) hard disk to the Switch (I tried also by using an Y cable with external power supply) and launch libusbhsfs-example (released one and a debug-rebuilt one)
Please fill the following information:
- Horizon OS (Switch FW) version: 11.1.0
- CFW: Atmosphère
- CFW version: 0.17.0 (with or without mesosphere)
- Atmosphère launch method (if applicable): Hekate or fusee-primary
- libusbhsfs version: v0.2.2
- Homebrew launch method: title override or applet
- USB Mass Storage device specs: Western Digital Elements SE Portable (WDBABV)
Logfile
Make sure you're using an application that's linked against the debug version of the library, and upload your logfile located at sdmc:/libusbhsfs.log.
Additional context The hard disk(s) used to work with SX OS libusbfs
@drizzt Thanks for reporting this issue. I'll look into it as soon as I get back home.
It seems to be related to the Mode Sense (6) SCSI command either having issues or being unsupported. SX OS driver most likely works because it doesn't issue Mode Sense commands.
Would it be possible for you to get a USB packet dump (e.g. via Wireshark) using a PC with partition automounting disabled?
@drizzt ~~Alright, so Mode Sense (6) is indeed supported, but these WD drives definitely don't like it if *only* the 4-byte long mode parameter header is requested. Luckily, it should be something easy to fix thanks to the provided packet dump.~~
Nevermind, further inspection of the packet dump suggests that these drives don't support Mode Sense (6) at all, which is weird. Every single Mode Sense (6) request results in a broken pipe (-EPIPE) error, and even though the halt status is cleared from the endpoint, usb:hs calls still hang.
I'll try to come up with a solution.
@drizzt I'm back home. I've already pushed some changes to the dev branch. Some of these changes include reimplementing the usbHsEpPostBuffer() function from libnx to be able to pass it a timeout value - libnx waits indefinitely, so whenever an unexpected USB pipe error occurs this means the application using the library will freeze.
On the other hand, even though these changes help mitigate the freezes experienced with some drives, I've been unable to find a proper solution to your specific issue. If you're using a PC with a Linux distro, please use sg_modes on your drive to see if it can effectively retrieve Mode Sense data from it.
The suggested command lines are:
Mode Sense (6):
sg_modes --control=0 -HH --maxlen=4 --page=0x3f,0x00 --raw --six -vvvv
Mode Sense (10):
sg_modes --control=0 -HH --maxlen=4 --page=0x3f,0x00 --raw -vvvv
Hi, I tried your command line with a drive that works with your library (just to see if it works on my system and it worked) and with the drive that doesn't work:
Mode Sense (6):
found sg_bsg_major=245
found sg_nvme_char_major=239
open /dev/sdd with flags=0x800
check_file_type: file descriptor is block device
inquiry cdb: [12 00 00 00 24 00]
duration=1 ms
mode sense(6) cdb: [1a 00 3f 00 04 00]
check_file_type: file descriptor is block device
duration=0 ms
mode sense(6):
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid command operation code
Raw sense data (in hex), sb_len=18, embedded_len=18
70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00
00 00
mode sense(6): pass-through requested 4 bytes (data-in), got got 0 bytes
>>>>>> try again without the '-6' switch for a 10 byte MODE SENSE command
Illegal request, Invalid opcode, type: sense key + asc,ascq
Mode Sense (10):
found sg_bsg_major=245
found sg_nvme_char_major=239
open /dev/sdd with flags=0x800
check_file_type: file descriptor is block device
inquiry cdb: [12 00 00 00 24 00]
duration=1 ms
mode sense(10) cdb: [5a 00 3f 00 00 00 00 00 04 00]
check_file_type: file descriptor is block device
duration=1 ms
mode sense(10):
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid command operation code
Raw sense data (in hex), sb_len=18, embedded_len=18
70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00
00 00
mode sense(10): pass-through requested 4 bytes (data-in), got got 0 bytes
>>>>>> try again with a '-6' switch for a 6 byte MODE SENSE command
Illegal request, Invalid opcode, type: sense key + asc,ascq
@drizzt Thanks for your input on this matter. It seems we definitely can't use any Mode Sense commands on these drives - raw sense data from both command outputs confirms this fact.
I'll change some stuff around and provide you with a test build with logging enabled.
@drizzt Just as I promised, here's the new test build with logging enabled. Please test it whenever you can and let me know how it goes.
@drizzt (sorry for pinging you) Have you been able to test the build from my previous comment?
@drizzt Please test this new build and send me its logfile.
Same crash and I also updated atmosphere to 0.17.1 (and no logfile is generated)
@drizzt Alright then, please try this one. It won't fix the issue but it should generate the logfile.
If you have a Discord handle, we can continue these tests over there - real time communication isn't very optimal here.
@drizzt Someone else was able to reproduce this very same crash using a drive that supports Mode Sense commands. I took a closer look at the problem, and turns out there was an issue with my usbHsEpPostBuffer() reimplementation.
You see, available usb:hs documentation states that an unsigned 64-bit integer with an unknown purpose must be passed to the PostBufferAsync IPC call - both libnx and the HID sysmodule set it to 0, then proceed to wait indefinitely for the completion event to be signaled.
I was setting this value to 0 as well, but only waiting a finite number of seconds for the completion event. I suspected this unknown value used by PostBufferAsync actually represents a timeout value, and it worked! Now I'm just passing my own timeout values directly to PostBufferAsync and waiting indefinitely for the completion event.
Thus, adae94ca6d54821d4fd644645497348a500f650d fixes the crash. I'd still like to know if it fixes the freeze you were originally experiencing with Mode Sense commands, though. Whenever possible, please test this new build.