MMC commands stall for a long time on MT1959-based drive.

[NeonMan]

Description

Calling mmc_get_configuration on my MT1959-based drive (Slim drive, over USB with OmniDrive firmware) stalls for a very long time (way above timeout) on each call, it eventually returns successfuly. straceshows it stalling during an IOCTL query. A sample program to reproduce is provided.

Tested on:

• OpenSUSE 15.6 / 16.0
• libcdio (master) / libcdio (OS package)
• Drive: HL-DT-ST BD-RE BU40N 1.00

How to Reproduce

Run the program below, change the BD_SG_PATH with the corresponding path to the drive sgX device.

#include <cdio/cdio.h>
#include <cdio/mmc.h>
#include <cdio/mmc_cmds.h>
#include <cdio/logging.h>

#include <stdio.h>
#include <assert.h>

#define BD_SG_PATH "/dev/sg7"
#define CDIO_MMC_FEATURE_BD_READ 0x0022

int main(){
  uint8_t buf[64];
  cdio_loglevel_default = 0;
  CdIo_t *p_cdio = cdio_open_am(BD_SG_PATH, DRIVER_DEVICE, "MMC_RDWR");
  assert(p_cdio);

  //HW info
  {
    uint8_t buffer[256];
    puts("--- Program WILL stall when running the next line ---");
    driver_return_code_t driver_return = mmc_get_configuration(p_cdio, buffer, sizeof(buffer), 1, CDIO_MMC_FEATURE_BD_READ, 5000);
  }
  cdio_destroy(p_cdio);
  return 0;
}

Build with cc -lcdio bugsample.c

Output Given

Does not apply

Expected behavior

The response to mmc_get_configuration on all my other drives is immediate.

Workarounds

I am using libsgutils2 to send MMC commands as an alternative, project has cdio and libsg code paths.

Priority

I presume this bug makes using all these drives near unusable with libcdio.

Additional Context

I can code and i try to provide feedback, but I'm pretty new to libcdio internals. MT1959-based drives are pretty popular for exotic media and BluRay.

[rocky]

I can code and i try to provide feedback, but I'm pretty new to libcdio internals.

You have done a great job in describing the problem and narrowing it.

There really isn't anything deep or complicated in term of what licdio does for mmc_get_configuration(). The body of the code for mmc_get_configuration is 6 C statements.
A suggestion is to compile with debug information. Then, in your favorite debugger (lldb or gdb), and then step through each of the 6 instructions to see which one is failing.

I suppose you could do exactly the same thing using libsgutils to see what it uses instead.

[tomty89]

Ah, so this is (one thing?) that you meant by "unreliable" (in the other issue)? Btw, does it make any difference if you send the call to the respective /dev/srN instead?

P.S. btw when you are working with a drive bridged to USB, it's somewhat hard to tell whether the issue is related to the drive itself or the USB bridge...(maybe less so for ATAPI devices but still...)

@rocky I think it would be the last one because strace shows it stalling during an IOCTL query...