0

I have an MSI Optix MAG245R 23.8" display. It features USB connections.

When I start up my Debian-based machine (BunsenLabs), I get warnings that say:

May  4 19:41:51 localname kernel: [  240.573980] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=4060, sector_sz=512)
May  4 19:41:51 localname kernel: [  240.573986] sd 9:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
May  4 19:41:51 localname kernel: [  240.573988] sd 9:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
May  4 19:41:51 localname kernel: [  240.573990] print_req_error: I/O error, dev sdc, sector 0
May  4 19:41:51 localname kernel: [  240.673838] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:51 localname kernel: [  240.673846] sd 9:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
May  4 19:41:51 localname kernel: [  240.673850] sd 9:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 04 00
May  4 19:41:51 localname kernel: [  240.673852] print_req_error: I/O error, dev sdc, sector 0
May  4 19:41:51 localname kernel: [  240.673859] Buffer I/O error on dev sdc, logical block 0, async page read
May  4 19:41:51 localname kernel: [  240.860367] Buffer I/O error on dev sdc, logical block 1, async page read
May  4 19:41:52 localname kernel: [  241.500663] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=4060, sector_sz=512)
May  4 19:41:52 localname kernel: [  241.612517] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=4060, sector_sz=512)
May  4 19:41:52 localname kernel: [  241.697840] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:52 localname kernel: [  241.785872] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:52 localname kernel: [  241.818899] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=16348, sector_sz=512)
May  4 19:41:52 localname kernel: [  241.909838] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:52 localname kernel: [  241.993839] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:55 localname kernel: [  244.842973] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=16348, sector_sz=512)
May  4 19:41:55 localname kernel: [  244.942219] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:55 localname kernel: [  245.034140] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:56 localname kernel: [  245.473992] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:56 localname kernel: [  245.557874] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:57 localname kernel: [  246.425872] sd 9:0:0:0: [sdc] Unaligned partial completion (resid=2012, sector_sz=512)
May  4 19:41:57 localname kernel: [  246.425881] sd 9:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
May  4 19:41:57 localname kernel: [  246.425884] sd 9:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 04 00

Then, I went ahead to launch GParted to inspect my storage volumes. I know what /dev/sda and /dev/sdb are; these are what I just expected. Thus I was surprised why a /dev/sdc was detected.

enter image description here

There, Device Information says its an MSI Optix Driver. I have tried isolating only the display's USB connection (no keyboard connections, dongles, whatever), and this is being detected as /dev/sdc.

What can I do to get rid of those errors? My non-expert idea is to find some way to tell my machine that this device with UUID0123456789 is not a storage device, so don't bother testing it as a storage device. How do I do that?

Or any other way?

1
  • The interesting part of dmesg is where the USB devices get detected. At least have a look at that to understand what's going on. Assuming the USB storage part isn't actually needed for anything, you can use udev rules to disable assignment of device node. Alternatively, you could use different udev rules to make sure it's not touched by partition detection etc.
    – dirkt
    May 4 at 18:16

2 Answers 2

1

The display seems to be a dual-mode device, and the default mode is a storage device that contains a Windows and/or Mac driver intended for that device. More and more USB devices that need a driver seem to do that these days.

If you run ls -l /sys/block/sdc, you'll see it's a symbolic link to a path like

../devices/<PCI device path for the USB controller>/usb#/<USB device path>/host#/target#:#:#/#:#:#:#/block/sdc

... where #'s are numbers depending on your exact hardware configuration, and not important here.

You'll want to move to a directory just before the host# part:

cd /sys/devices/<PCI device path for the USB controller>/usb#/<USB device path>/

... and then see if the directory contains file named bNumConfigurations and bConfigurationValue. If it doesn't, move up one level (cd ..) and check again.

Once you find the correct directory, cat bNumConfigurations will tell you how many possible configurations (modes) the USB device has. A USB device that provides its own driver will most likely have at least two modes, so the command will probably output 2.

cat bConfigurationValue will tell you the number referring to the current configuration. Most likely the storage device configuration is the first one, 1.

To switch the USB device to its second configuration, run:

echo 2 | sudo tee bConfigurationValue

(or if you are running as root, just echo 2 > bConfigurationValue. Note the space between 2 and >, as 2> has a special meaning to many shells.)

This should cause the "USB storage device" to vanish and be replaced with the actual functionality of the USB device in question.

To automate this process, most modern distributions have an usb-modeswitch component/utility. The fact that it did not already switch your device means you'll need to add information about your device to its configuration. Once you know the configuration number needed, you can create a text file at /etc/usb_modeswitch.d/XXXX:YYYY where XXXX:YYYY is the vendor:product ID of the USB device that needs switching. The content of the file should be a line identifying the configuration you want. For example, if you found out that configuration 2 provides the actual functionality of the device, you'd write a line like this:

Configuration=2

And that's it. (You might actually want to send a copy of your file to the usb-modeswitch developers, so they can add the information to the future versions of the utility.)

Some devices may use a different switching method, which is more tricky to figure out. If the sysfs file bNumConfigurations indicates there is only one configuration for the USB device in question, you would need to e.g. build a Windows VM, present the USB device to it, install the driver offered by the device, and then snoop the USB traffic while the VM is starting up to capture the USB message sent by the Windows driver to the device to trigger the configuration switch. The usb-modeswitch utility can be configured to send such a message automatically, and its data files will include a number of existing examples of such cases.

Generally, a Windows "driver" for a display might contain little more than an *.icc colour calibration profile, which could be used in Linux too. If the display is optimized for high refresh rates (= a gaming display) or has weird color reproduction characters for some other reason, you might be able to improve the colour reproduction of your display by finding the colour calibration profile within the Windows driver package, and telling your desktop environment to use it with your display.

1
  • Thank you for the in-depth answer! Unfortunately, for cat bNumConfigurations, I only get 1. Perhaps I could force it anyway, and write 2 into bConfigurationValue? On a different track, I'll try out the usb-modeswitch route.
    – Kit
    May 5 at 8:53
0

Thanks to @telcoM for the clues. I have fixed the problem.

tl;dr

De-authorize the offending USB device using udev rules.

How to do it

  1. Run dmesg in follow mode:
$ dmesg -w
  1. Disconnect and reconnect the display's USB cable.
  2. In the output of dmesg, take note of the bus number of the device you want to disable (covered in yellow)

enter image description here

  1. Exit dmesg with CTRL+C.
  2. Now run the following to get the device attributes. Substitute xxxusbxxx with the bus number you got from dmesg
$ udevadm info -a -p /sys/bus/usb/devices/xxxusbxxx
  1. This is the first part of the output, the one you care about. Take note of the following attributes and the path covered in the red box.
DRIVER=="usb-storage"
ATTR{bInterfaceClass}=="aa"
ATTR{bInterfaceNumber}=="bb"
ATTR{bInterfaceProtocol}=="cc"
ATTR{bInterfaceSubClass}=="dd"

enter image description here

  1. Now create a new file /etc/udev/rules.d/10-disable-MSI-optix-storage.rules. The number 10 indicates that the rule is executed before other rules with higher numbers. Keep the .rules extension. The rest of the filename does not matter. These should be the contents of the file. Substitute strings accordingly.

enter image description here

  1. Reboot your computer and see that the read error message no longer appear.

What this actually does

When a USB device that matches the attributes specified in the udev rules file is detected, its authorized flag is immediately set to 0 and can no longer be used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.