Re: APPLE SSD SM0256G: host bus errors above 1280 KiB writes since 9b8b84879d4a

Re: APPLE SSD SM0256G: host bus errors above 1280 KiB writes since 9b8b84879d4a

[Ric Lewis]

Adding CCs

  Ric Lewis
  riclewis@gmail.com

________________________________________
From: Ric Lewis <riclewis@gmail.com>
Sent: Friday, July 31, 2026 2:10 PM
To: linux-ide@vger.kernel.org <linux-ide@vger.kernel.org>
Cc: dlemoal@kernel.org <dlemoal@kernel.org>; cassel@kernel.org <cassel@kernel.org>; linux-block@vger.kernel.org <linux-block@vger.kernel.org>
Subject: APPLE SSD SM0256G: host bus errors above 1280 KiB writes since 9b8b84879d4a
 
Hi,

Since 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") this
Apple/Samsung SSD throws AHCI host bus errors on sustained writes and ends
read-only. It needs an ATA_QUIRK_MAX_SEC entry with value 2560 — the
existing 8191 entries are not low enough for this device.

    Machine:    MacBookPro11,4
    Controller: 144d:a801 Samsung S4LN058A01[SSUBX] AHCI SSD (Apple slot)
                PCIe 3.0 x4
    Drive:      APPLE SSD SM0256G, fw BXW1SA0Q, 251 GB
    Kernel:     Ubuntu 7.0.0-28.28~24.04.1 (upstream 7.0.12); good: 6.8.0-100


## Matrix

    kernel              max_sectors_kb   result
    ------------------------------------------------
    6.8.0-100           1280 (default)   PASS
    6.8.0-100           4096 (forced)    PASS   <-- unexplained, see below
    7.0.0-28            4096 (default)   FAIL
    7.0.0-28            2048 (forced)    FAIL
    7.0.0-28            1280 (forced)    PASS

Each PASS is ~28 GB plus 16,000 small files across three workloads in one
boot, 0 errors.

Time-to-failure varies with workload. Writing incompressible data from
/dev/urandom, a fresh boot faulted 55 s in. With /dev/zero it often took a
second workload in the same boot session. I have not isolated which factor
dominates.

Single-variable check: in one 7.0 session, 16 GB wrote cleanly at 1280,
then the value was raised to 2048 live — the next workload failed. Same
boot, same kernel.

Reproducer (buffered; O_DIRECT does not reproduce, it caps on segment count
~511 KiB):

    dd if=/dev/zero of=big.bin bs=4M count=2048 conv=fsync
    for i in $(seq 1 4000); do echo x > f$i.txt; done; sync

## Failure

Verbatim, 7.0.0-28, max_sectors_kb=2048:

    ata1.00: exception Emask 0x20 SAct 0x3ff0c0 SErr 0x0 action 0x6 frozen
    ata1.00: irq_stat 0x20000000, host bus error
    ata1.00: failed command: WRITE FPDMA QUEUED
    ata1.00: cmd 61/00:30:00:a0:1d/10:00:1b:00:00/40 tag 6 ncq dma 2097152 out
             res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error)

Then hard link reset, recurrence, ext4 journal abort, remount-ro.

- Every initiating failure is a max-size write: at 4096 all are `dma
  4194304`, at 2048 all are `dma 2097152`. Smaller sizes are collateral
  from the reset.
- `SErr 0x0` — the link reports nothing. Host/DMA-side fault.
- Raw interrupt status is `irq_stat 0x20000000` in 108 of 113 cases (5 were
  `0x20000008`), i.e. PORT_IRQ_HBUS_ERR (BIT 29, host bus *fatal* error) —
  never PORT_IRQ_HBUS_DATA_ERR (BIT 28, `0x10000000`).
- 91 distinct LBAs, so not a bad region. Reads are clean (233 GB pass, 0
  errors).
- No FLUSH involved. 34 C at failure. SMART PASSED,
  Reallocated_Sector_Ct=1, no growth.

## Workaround (verified)

`libata.force=max_sec=2560` on 7.0:

    ata1.00: FORCE: modified (max_sec=)
    ata1.00: maxsec quirk is using value: 2560

This sets max_hw_sectors_kb=1280 (stock 32767), so it cannot be raised back
up. ~28 GB plus 16,000 files across three workloads in one boot, 0 errors.

## Patch

    --- a/drivers/ata/libata-core.c
    +++ b/drivers/ata/libata-core.c
    @@ static const struct ata_dev_quirk_value __ata_dev_max_sec_quirks[] = {
      { "INTEL SSDSC2KG480G8",      "XCV10120", 8191 },
    + { "APPLE SSD SM0256G",        "BXW1SA0Q", 2560 },
      { },
     };

    @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
      { "DELLBOSS VD",  "MV.R00-0", ATA_QUIRK_MAX_SEC },
     
    + /*
    +  * Apple/Samsung S4LN058A01[SSUBX] AHCI SSD reports host bus errors on
    +  * writes larger than 1280 KiB since commit 9b8b84879d4a.
    +  */
    + { "APPLE SSD SM0256G",  "BXW1SA0Q", ATA_QUIRK_MAX_SEC },

    Fixes: 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP")
    Cc: stable@vger.kernel.org


## Size check
The safe value measured here is 2560 sectors (1280 KiB), the pre-9b8b84879d4a
default.  Tried 8191 sectors = 4095.5 KiB, one sector under 4 MiB. This device
already fails at 4096 sectors (2048 KiB).


## Perf Impact
6.8, both values working, buffered+fsync, incompressible data, caches
dropped, 3 reps:

    1280:  834.9 / 840.8 / 846.7 MB/s   (avg request ~1160 KiB)
    4096:  847.3 / 833.6 / 839.1 MB/s   (avg request ~3950 KiB)

Mean 840.8 vs 840.0 — inside noise. Knob confirmed engaged (3.4x fewer,
larger commands at 4096 for identical bytes). Raw read is ~1695 MB/s
against a ~3.4 GB/s PCIe 3.0 x4 ceiling, so the device had headroom to
benefit and did not.

## Oddity:  Why does 6.8 tolerate 4096?
Instrumented both kernels with kprobes on `ahci_qc_prep()`. Two plausible
mechanisms are ruled out.

**1. Not PRDT entry count or SG coalescing.** For 4 MiB writes:

    6.8 (passes):  1024 cmds, qc->n_elem avg 64, max 66, ~64,885 bytes/segment
    7.0 (fails):    258 cmds, qc->n_elem avg 63, max 64, ~65,518 bytes/segment

Effectively identical, and far below AHCI_MAX_SG (168). If anything 7.0
coalesces slightly better. On 7.0 all 258 of those 4 MiB writes generated
host bus errors.

**2. Not DMA address width or placement.** Reading the coherent structures
out of `ahci_port_priv` (offsets from module BTF) and the first mapped SG
address:

    both kernels:  cmd_slot_dma 0xFFFC0000
                   cmd_tbl_dma  0xFFFC0500
                   rx_fis_dma   0xFFFC0400
    above 4 GiB:   0 of 768 (6.8), 0 of 297 (7.0) — coherent and streaming alike

The coherent addresses are byte-identical between kernels, and nothing —
coherent structures or data segments — is ever placed above 4 GiB on this
machine, despite 15 GB RAM. Streaming data lands around 1.9 GB on both.
Consistent with this, booting 7.0 with `swiotlb=force` changed nothing.

That implies an `AHCI_HFLAG_32BIT_ONLY` quirk would be a no-op here.

Caveat: I captured only the first SG segment address per command, not all
~64, so a later segment crossing a boundary is not excluded. I also have
not compared H2D FIS bytes, command-header opts, or PxSACT/PxCI at issue
time. Those remain open.

`ahci_qc_prep()` / `ahci_fill_sg()` are unchanged between 6.8 and 7.0, and
AHCI_MAX_SG / LIBATA_MAX_PRD / .sg_tablesize are identical, so whatever
differs is not in libata's advertised limits.


For this issue, I'm happy to run further instrumentation — both kernels are installed
And the reproducer is reliable.

I have only tested SM0256G/BXW1SA0Q, so the entry is deliberately narrow.

The same S4LN058A01 controller ships as SM0128G/SM0512G/SM1024G in
2013-2015 Macs and may share the limitation. If anyone with those parts can
reproduce, a `"APPLE SSD SM*"` wildcard would likely be the better entry —
but I did not want to assert coverage I have not measured.


Thanks,
Ric

Re: APPLE SSD SM0256G: host bus errors above 1280 KiB writes since 9b8b84879d4a

[Niklas Cassel]

Hello Ric,

On Fri, Jul 31, 2026 at 09:10:53PM +0000, Ric Lewis wrote:
> ## Patch
> 
>     --- a/drivers/ata/libata-core.c
>     +++ b/drivers/ata/libata-core.c
>     @@ static const struct ata_dev_quirk_value __ata_dev_max_sec_quirks[] = {
>       { "INTEL SSDSC2KG480G8",      "XCV10120", 8191 },
>     + { "APPLE SSD SM0256G",        "BXW1SA0Q", 2560 },
>       { },
>      };
> 
>     @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
>       { "DELLBOSS VD",  "MV.R00-0", ATA_QUIRK_MAX_SEC },
> 
>     + /*
>     +  * Apple/Samsung S4LN058A01[SSUBX] AHCI SSD reports host bus errors on
>     +  * writes larger than 1280 KiB since commit 9b8b84879d4a.
>     +  */
>     + { "APPLE SSD SM0256G",  "BXW1SA0Q", ATA_QUIRK_MAX_SEC },
> 
>     Fixes: 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP")
>     Cc: stable@vger.kernel.org

Patch looks good to, could you please send it as a formal patch?

https://docs.kernel.org/process/submitting-patches.html


Kind regards,
Niklas