Lubuntu on the Lenovo MIIX 3-1030

Short version

The hardware was not broken. The card and host negotiated SDIO high-speed mode, but host-to-card CMD53 data writes were unreliable in that signaling mode. Lowering the clock alone was not enough. Clearing the card's high-speed-enable bit before the first Realtek I/O, switching the host to legacy timing, and running at 25 MHz fixed Wi-Fi completely.

The base Lubuntu installation already reached the graphical login screen. We used the tablet's working Bluetooth PAN connection as a recovery and SSH channel while Wi-Fi was disabled. The temporarily missing network icon and hanging ip/ifconfig commands occurred only when an experimental SDIO path wedged the kernel; they returned to normal after that diagnostic was removed and the final fix was installed.

Failing state

CCCR speed register 0x03
Host timing mode 2 (high speed)
50 MHz—or 25 MHz with high-speed timing still active
CMD53 writes fail with -EILSEQ / data CRC errors

Working state

CCCR speed register 0x01 (EHS cleared)
Host timing mode 0 (legacy)
25 MHz, four-bit, 3.30 V, push-pull
Normal CMD53 data transfer with no CRC errors

Recognizing this particular failure

The confusing part was that Wi-Fi was not simply dead. The receive and transmit paths behaved very differently:

Observed behavior	What it proved
Nearby SSIDs appeared in scans	Firmware execution, RF reception, antenna, channel changes, RX FIFO, and card-to-host CMD53 reads worked.
CMD52 register access worked	The card accepted SDIO commands and control traffic.
Association sometimes completed	The radio and much of the driver were functional; this was not a missing-firmware symptom.
Outgoing packets failed or timed out	The broken path was Linux host → SDIO data bus → RTL8723BS, specifically CMD53 writes.
`ip addr`, shutdown, or NetworkManager could hang during aggressive diagnostics	A wedged kernel I/O path can make userspace networking appear frozen. Avoid live module reloads while investigating.

The smallest legal one-byte CMD53 write failed with zero bytes transferred, so chopping packets into smaller sections was not a solution. CMD52 could write registers byte by byte, but could not reliably emulate the transmit FIFO.

What the patch changes

The patch is intentionally opt-in. It adds two module parameters to the in-kernel staging r8723bs driver:

force_sdio_legacy=1 reads SDIO_CCCR_SPEED, clears SDIO_SPEED_EHS, sets MMC_TIMING_LEGACY, and applies a 25 MHz clock before any Realtek I/O.
force_cmd52_write32=1 sends aligned 32-bit register writes as four CMD52 bytes. Bulk firmware/data transfers and the TX FIFO still use CMD53.

Why the earlier 25 MHz experiment failed: setting the clock to 25 MHz after negotiation did not change the host's timing mode or clear the card's EHS bit. Frequency and signaling mode are separate settings.

The small standalone patch documents the two decisive mode changes and targets the RTL8723BS source layout in Ubuntu kernel 7.0.0-28. The recommended DKMS download contains the complete, exact driver source used for the final test, including the transfer-path corrections retained from our earlier experiments. Use the DKMS package if you want the tested result rather than treating the small patch as a complete replacement driver.

Installing the fix

Important safety rule: build and install the module for the next boot. Do not repeatedly unload/reload r8723bs on a live affected machine. A wedged SDIO interrupt path can panic the kernel. Keep a known-good kernel in the boot menu and use Bluetooth PAN or USB Ethernet as a recovery connection.

Recommended: install the tested DKMS package

DKMS means Dynamic Kernel Module Support. It keeps the patched driver source in /usr/src and automatically rebuilds the module when Ubuntu installs a new kernel with matching headers. This package contains the exact RTL8723BS source that passed the reboot and concurrent Wi-Fi stress test described below.

tar -xzf r8723bs-miix3-dkms-1.1.tar.gz
cd r8723bs-miix3-dkms-1.1
sudo bash install.sh
sudo reboot

The installer obtains DKMS and the running kernel's headers using apt, builds and installs r8723bs-miix3/1.1, installs the two module options, runs depmod, and rebuilds the initramfs. It deliberately does not unload the live driver.

SHA-256: 8001b5facc144029cc1236d953a2f02b8026bcee039565ce08a5cd7e2d2e9064

Confirm that the hardware matches

uname -r
cat /sys/bus/sdio/devices/mmc0:0001:1/{vendor,device} 2>/dev/null
readlink -f /sys/bus/sdio/devices/mmc0:0001:1/driver
dmesg | grep -Ei 'INT33BB|mmc0|8723bs'

The tested combination reports vendor/device 0x024c/0xb723 and an ACPI Bay Trail host named INT33BB:00.

Manual alternative: patch matching kernel source

Install the headers and obtain source matching the kernel you intend to boot. From the root of that source tree:

patch -p1 < r8723bs-miix3-legacy-sdio.patch

# Prepare the tree as required by your distribution, then build the driver.
make -j2 M=drivers/staging/rtl8723bs modules

Ubuntu's full source/config preparation varies by release. The important rule is that the resulting module's vermagic must match uname -r exactly:

modinfo drivers/staging/rtl8723bs/r8723bs.ko | grep vermagic
uname -r

Install a manually built module and its options

sudo install -D -m 0644 \
  drivers/staging/rtl8723bs/r8723bs.ko \
  /lib/modules/$(uname -r)/updates/r8723bs.ko

sudo install -m 0644 r8723bs-miix3.conf \
  /etc/modprobe.d/r8723bs-miix3.conf

sudo depmod -a
sudo update-initramfs -u
sudo reboot

Connect normally

nmcli radio wifi on
nmcli device wifi list ifname wlan0
nmcli device wifi connect "YOUR_SSID" password "YOUR_WIFI_PASSWORD" ifname wlan0
nmcli connection modify "YOUR_SSID" connection.autoconnect yes

What happens after a kernel update?

Without DKMS, a newly installed kernel would boot its own unpatched in-tree r8723bs module, so this tablet could lose working Wi-Fi. With the package above registered, Ubuntu's kernel/header installation hooks ask DKMS to compile and install the fixed module for each new kernel automatically.

Check before rebooting into the new kernel

dkms status
modinfo -k "NEW_KERNEL_VERSION" -n r8723bs

For the new kernel, dkms status should say installed, and modinfo should resolve to a path below updates/dkms. If the build did not run, first make sure the matching headers are installed, then ask DKMS to retry:

sudo apt install linux-headers-NEW_KERNEL_VERSION
sudo dkms autoinstall -k NEW_KERNEL_VERSION

Keep the previous kernel until the new one has passed a Wi-Fi test. DKMS automates rebuilding, but it cannot guarantee that a future kernel has not changed an internal driver API. If a build fails, continue booting the previous kernel from GRUB and adapt the source before trying the new kernel again. Do not run apt autoremove on the fallback kernel prematurely.

On systems enforcing Secure Boot, a locally built unsigned module may also require Machine Owner Key enrollment or signing. The tested MIIX installation loaded the DKMS module successfully without that extra step.

Verify the mode before stressing it

sudo dmesg | grep -E 'forced legacy SDIO|forcing 32-bit SDIO'
sudo cat /sys/kernel/debug/mmc0/ios
nmcli -f GENERAL.STATE,GENERAL.CONNECTION,IP4.ADDRESS,IP4.GATEWAY \
  device show wlan0

The MMC output should contain:

clock:          25000000 Hz
actual clock:  25000000 Hz
bus width:     2 (4 bits)
timing spec:   0 (legacy)
signal voltage: 0 (3.30 V)

If debugfs is not mounted, mount it first with sudo mount -t debugfs none /sys/kernel/debug.

Controlled load test

Replace the gateway below if your router uses another address. Run the ping and download together, then inspect counters and the kernel log.

ping -I wlan0 -c 5000 -i 0.01 -s 1400 -q 192.168.0.1 &
curl --interface wlan0 -L -o /dev/null \
  'https://speed.cloudflare.com/__down?bytes=67108864'
wait

paste -d' ' /sys/class/net/wlan0/statistics/{\
rx_packets,tx_packets,rx_bytes,tx_bytes,tx_errors,tx_dropped}
sudo dmesg | grep -Ei 'CMD53|timeout|crc|deauth|disassoc|mmc.*fail'

Results on the repaired tablet

5,000 / 5,000full-sized ping replies during load

0 errors, 0 dropsin Wi-Fi transmit counters

64 MiB at ~1.9 MB/swhile the ping load ran concurrently

16 MiB at ~2.2 MB/sseparate upload test

The complete combined test was repeated after a clean reboot into the downloadable DKMS 1.1 build. Wi-Fi autoconnected, legacy timing was still active, all 5,000 replies arrived, the 64 MiB download completed at approximately 1.97 MB/s, RX/TX error counters remained zero, and the kernel log contained no SDIO CRC, timeout, or disconnect errors. Bluetooth remained connected as a separate control channel.

What did not solve it

These tests are recorded so somebody with the same symptoms does not have to repeat weeks of elimination work.

Kernel, DMA, width, frequency, and transfer size

Stock Ubuntu 5.15 and a custom Ubuntu 7.0 driver failed in the same direction.
ADMA and forced PIO both failed.
Four-bit and one-bit SDIO both failed.
50 MHz, 25 MHz, and roughly 400 kHz all failed while high-speed timing remained negotiated.
One-byte CMD53 writes failed, ruling out only-large-transfer and alignment explanations.

Firmware and Windows-driver comparisons

The decompressed Linux firmware was byte-for-byte identical to the known-working RTL8723BS repository firmware: SHA-256 a52b5a7be4841b4b2839eddf5122b3300a3610866abe4bb3c3c9e444c8ab7969.
Lenovo's Windows driver version 3008.66.1013.2017 pads blocks and retries CMD53 transfers with short delays. Reproducing those behaviors did not recover a write.
A complete two-minute power-off with the charger disconnected did not change the failure.

CMD52 and addressing experiments

CMD52 was reliable for small control-register operations.
Replacing an entire TX FIFO write with bytewise CMD52 operations timed out partway through ordinary 84–92 byte frames.
Incrementing and fixed-address TX conventions did not fix native CMD53 writes.
Natural register read-back after selected failed writes was mixed and not reliable enough to diagnose bit patterns.

A diagnostic mistake worth avoiding

One early test passed a stack variable to sdio_memcpy_toio(). The Bay Trail controller attempted to DMA-map it and produced an Oops in dma_direct_map_sg. That panic was caused by the diagnostic buffer, not by the final workaround or evidence of broken hardware. Buffers passed to DMA-capable MMC helpers must be DMA-safe.

Why some older installations worked

The exact-model Linux reports were not using the same setup we initially had. A 2016 MIIX guide used an external Realtek driver on Linux 4.5.1 plus a set of Bay Trail MMC patches. The driver repository explicitly lists the MIIX 3-830/1030 and says the Bay Trail SDIO patches are required. One patch constrains DMA latency to prevent deep CPU sleep states while an SDIO transfer is active.

Those reports do not explicitly say that they forced legacy timing, so it would be speculation to claim that they used this exact fix. They do show that the working systems differed in the MMC/ACPI host stack as well as the Realtek driver. A later Lubuntu report also shows successful RTL8723BS authentication and association on the same family of tablet.

On this tablet, the decisive A/B result was direct: high-speed timing produced write CRC errors; clearing EHS and selecting legacy timing made the same card, firmware, four-bit bus, and CMD53 data path reliable.

References and downloads

Last updated: 8 August 2026. This is a field report, not an upstream-supported Lenovo or Realtek fix. Keep recovery media and a fallback kernel available.