Aliexpress BU40N inside USB3.0 enclosure. How to in Archlinux...

The place to discuss linux version of MakeMKV
Post Reply
Message
Author
UltraRip
Posts: 2
Joined: Tue Mar 31, 2026 11:19 pm

Aliexpress BU40N inside USB3.0 enclosure. How to in Archlinux...

#1 Post by UltraRip » Wed Apr 01, 2026 1:43 am

BU40N (INIC-1618L enclosure) – Stable UHD ripping on Linux (Arch)

First, thanks to the MakeMKV community for the tooling and documentation around UHD-friendly drives.

This post documents a reproducible setup for stabilizing a BU40N drive in a USB enclosure based on the INIC-1618L bridge, specifically under Linux where UASP-related issues can cause disconnects during UHD reads.

Hardware / Software Stack
  • Drive: BU40N (UHD-friendly, reflashed to firmware 1.00)
  • Enclosure: INIC-1618L (USB 3.0, single micro-B port)
  • OS: Arch Linux
  • Kernel: 6.19
  • MakeMKV: 1.18.3
The enclosure supports SAT passthrough and firmware flashing without disassembly.

Observed Failure Modes (Linux only)

All issues below were reproducible under Linux but not present in Windows 10:
  • USB device reset/disconnect during reads of dual-layer UHD (66GB) media
  • Intermittent mount failures / excessive spin-up retries
  • Inconsistent readability across UHD discs (especially layer transitions)
  • Excessive seek noise during TOC read / initial access
  • Device disconnect when inserting media with MakeMKV already polling the drive
Root Cause (Likely)

The INIC-1618L bridge advertises UASP support, but in practice:
  • UASP command queueing conflicts with optical drive behavior
  • Layer transitions (L0 → L1) introduce latency interpreted as timeouts
  • This triggers USB resets at the bridge level (visible in dmesg)
This aligns with known instability of UASP for optical media, especially UHD Blu-ray.

Mitigation: usb-storage quirks (disable UASP + stabilize probing)

Force fallback to BOT (Bulk-Only Transport) and reduce aggressive probing:

Code: Select all

options usb-storage quirks=13fd:0840:mku
Where:
  • 13fd:0840 → INIC-1618L VID:PID
  • u → disables UASP (critical)
  • m → reduces aggressive probing
  • k → avoids HID report ID conflicts (bridge quirk)
Implementation (Arch Linux)
  1. Identify device:

    Code: Select all

    lsusb
    
    Example:

    Code: Select all

    Bus 003 Device 005: ID 13fd:0840 Initio Corporation INIC-1618L SATA
    
  2. Create quirk config:

    Code: Select all

    echo 'options usb-storage quirks=13fd:0840:mku' | sudo tee /etc/modprobe.d/usb-storage-quirks.conf
    
  3. Include in initramfs:

    Code: Select all

    sudo nano /etc/mkinitcpio.conf
    
    Modify:

    Code: Select all

    FILES=(/etc/modprobe.d/usb-storage-quirks.conf)
    
  4. Rebuild initramfs:

    Code: Select all

    sudo mkinitcpio -P
    
  5. Reboot
Verification

Code: Select all

cat /sys/module/usb_storage/parameters/quirks
Expected:

Code: Select all

13fd:0840:mku
Also confirm in dmesg that:
  • Device binds to usb-storage (not uas)
  • No UAS driver attachment occurs
Multi-device quirks

Combine entries as comma-separated:

Code: Select all

options usb-storage quirks=174c:1153:u,13fd:0840:mku
Example:
  • 174c:1153:u → disables UASP on ASM1153 bridge (UGREEN adapter)
Operational Notes (Important for stability)
  • Do not insert media while MakeMKV is open (avoid concurrent polling + spin-up)
  • Allow kernel to fully enumerate and stabilize (~5 seconds) before launching MakeMKV
  • Allow cooldown between long UHD reads (~30 minutes recommended)
  • Keep discs clean to reduce read retries
Alternative (Power-related instability)

If disconnects persist:
  • Remove drive from enclosure
  • Use a powered SATA → USB adapter
  • Use a Slimline SATA adapter
This helps mitigate power delivery limitations of some enclosures.

What NOT to do
  • Avoid USB hubs (even powered)
  • They add latency and increase transport-level instability
  • They can worsen UASP-related issues
Summary

The key fix is:

Disable UASP ("u" quirk) for INIC-1618L-based enclosures

Everything else is secondary tuning.

UPDATE May 8 2026, after About 150 UHD Rips
The drive started to make weird noises, it seems that the motor started to fail, causing the drive to stop mid rip. There are no scratches in the disks, but the mechanical noises are noticeable.
I cannot limit the speed by any means yet (tried using MakeMKV config file, sdparm, hdparm, nothing works maybe because of the USB adapter), if someone knows how to do it in Linux it would be really appreciated!
I'm discarding this unit for now and using another I had before.

UPDATE May 15 2026. Technical Note: Mitigating LG BU40N Rip Failures and Vibrations via External Power (ASM1153)

I have identified a major hardware bottleneck regarding the LG BU40N slim drive when ripping demanding UHD media. Testing indicates that utilizing a SATA-to-USB adapter with an ASMedia ASM1153 chipset and an external 12VDC power supply significantly outperforms standard, bus-powered USB 3.0 enclosures.

The Power Bottleneck

While USB 3.0 bus power suffices for nominal operations, the BU40N mechanism draws peak current during high-load scenarios—such as seeking outer layers on 100GB discs or handling scratched media. These spikes frequently exceed the standard 900mA USB 3.0 limitation.

When the port fails to supply adequate current:
  • The spindle motor struggles to maintain precise synchronization.
  • A temporary voltage drop occurs as the hardware compensates.
  • This drop induces heavy harmonic motor vibration and often triggers a USB bridge reset, abruptly terminating the process in MakeMKV.
Advantages of Dedicated 12V DC & ASM1153

Transitioning to an externally powered ASM1153 bridge stabilizes the drive's environment by providing:
  • Clean, Uncapped Current: The external PSU absorbs power spikes effortlessly, eliminating voltage sag.
  • Thermal & Mechanical Stability: Operating temperatures are reduced, and motor resonance is heavily minimized.
  • Improved Sector Recovery: Stable RPM maintenance allows the optical pick-up block a higher tolerance for reading and recovering problematic or heavily budgeted sectors.
How to Connect
Use a powered SATA to USB adapter, in conjunction with a SATA to SlimLine adapter like these: Remember to configure the quirks accordingly!
Last edited by UltraRip on Sat May 16, 2026 12:14 am, edited 4 times in total.

georgesgiralt
Posts: 92
Joined: Thu Jun 04, 2020 12:40 pm

Re: Aliexpress BU40N inside USB3.0 enclosure. How to in Archlinux...

#2 Post by georgesgiralt » Wed Apr 01, 2026 4:35 am

Thank you, this explains some strange things I get.
Could you post a link for your metal enclosure ? I'm looking for one...

UltraRip
Posts: 2
Joined: Tue Mar 31, 2026 11:19 pm

Re: Aliexpress BU40N inside USB3.0 enclosure. How to in Archlinux...

#3 Post by UltraRip » Wed Apr 01, 2026 2:10 pm

georgesgiralt wrote:
Wed Apr 01, 2026 4:35 am
Thank you, this explains some strange things I get.
Could you post a link for your metal enclosure ? I'm looking for one...
Hi!, I added the link to the Aliexpress item in the main post. Take into account that there are several similar enclosures in Aliexpress, some of them include 2 cables which you would need to connect simultaneously to 2 USB ports in your PC, and there are other enclosures which have only one USB 3.0 cable, this is the one I'm using. The drive that I purchased came already inside this kind of enclosure.

I think this is the same enclosure I'm using:
https://es.aliexpress.com/item/1005008737120645.html
If you still have USB bridge reset problems, you can open the enclosure and use use a SATA to USB3.0 adapter with external power supply like this, which I use to backup my movies in HDDs:
https://www.amazon.com/dp/B00MYU0EAU
And an additional Sata to Mini-sata adapter like this:
https://www.amazon.com/dp/B00S6I9D7E
This also worked for me before using the quirks configuration, allowing me to read a 2 layer UHD disk that was having issues, but it still can throw some errors in dmesg.

Another alternative is to use a powered USB3.0 hub.

georgesgiralt
Posts: 92
Joined: Thu Jun 04, 2020 12:40 pm

Re: Aliexpress BU40N inside USB3.0 enclosure. How to in Archlinux...

#4 Post by georgesgiralt » Thu Apr 02, 2026 3:28 am

Thank you !

Post Reply