Crucial X9 USB SSD very slow on Haiku, xHCI max_burst_payload error

Help
1

System: Haiku shredder 1 hrev57937+129 Dec 10 2024 21:49 x86_64 x86_64 Haiku

Hi everyone,

I ran into a very interesting USB 3 / xHCI issue with an external Crucial X9 SSD on my ThinkPad P53.

The device is:

Crucial X9 1TB
Micron CT1000X9SSD9

The laptop is a ThinkPad P53. It has one side USB-C port with USB 3.1 Gen 1 and two rear USB-C / Thunderbolt 3 ports with USB 3.1 Gen 2.

At first I had the SSD connected to the side USB-C port. Under Linux this negotiated as 5 Gbit/s, which made sense for that port.

Then I moved the same SSD, same cable, to one of the rear USB-C / Thunderbolt 3 ports.

Under Ubuntu Linux the device is detected correctly:

Mass Storage, Driver=uas, 10000M

Raw read test under Linux:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
sudo dd if=/dev/sda of=/dev/null bs=64M count=32 status=progress

Result:

2147483648 bytes (2.1 GB, 2.0 GiB) copied, 2.07586 s, 1.0 GB/s

So the SSD, cable and rear USB-C / Thunderbolt port are clearly capable of USB 3.1 Gen 2 speed.

Under Haiku R1/beta5, on the same laptop, same SSD, same cable and same rear port, the SSD is detected and usable, but extremely slow.

Haiku syslog shows:

KERN: usb xhci -1: successfully started the controller
KERN: usb error xhci 1: ConfigureEndpoint() failed invalid max_burst_payload
KERN: usb error xhci 1: unable to configure endpoint: Invalid Argument
KERN: usb error xhci 1: ConfigureEndpoint() failed invalid max_burst_payload
KERN: usb error xhci 1: unable to configure endpoint: Invalid Argument
KERN: usb xhci -1: interface version: 0x0110

The device itself is detected as:

KERN: usb_disk: vendor_identification    "Micron  "
KERN: usb_disk: product_identification   "CT1000X9SSD9    "
KERN: usb_disk: product_revision_level   "1000"

I also checked with listdev. Haiku sees the xHCI controllers and the Crucial X9 appears as USB Attached SCSI mass storage.

Raw read test under Haiku, directly from the block device:

time dd if=/dev/disk/usb/1/0/raw of=/dev/null bs=1048576 count=2048

Result:

2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 68.5258 s, 31.3 MB/s

real    1m11.385s

I also tested both exFAT and BFS on the SSD. The file system does not seem to be the main issue:

Haiku exFAT read: about 43.6 MB/s
Haiku BFS read:   about 43.9 MB/s
Haiku raw read:   about 31.3 MB/s

So this does not look like an exFAT or BFS problem. The bottleneck seems to be below the file system layer.

For comparison:

Ubuntu Linux, same rear port, same SSD, same cable:
UAS, 10000M, raw read about 1.0 GB/s

Haiku Build, same rear port, same SSD, same cable:
xHCI detects the controller and the SSD, but raw read is only about 31 MB/s

The suspicious part seems to be:

ConfigureEndpoint() failed invalid max_burst_payload
unable to configure endpoint: Invalid Argument

I found a similar error in an older discussion about external USB SSD boot problems, although the effect there was different. In my case the SSD is detected and usable, but the speed is USB-2-like despite using a USB 3.1 Gen 2 capable port.

Is this a known xHCI / USB mass storage / UAS issue in Haiku?
Is there anything else I should test or collect for a useful bug report?

I can provide full listdev and syslog output if needed.

Greetz & Thanks
Juergen

1 Like
2

With issues like that it’s best to log a ticket at the bug tracker (https://dev.haiku-os.org/) and attach the listdev and syslog output there so the devs can look into it further.

2 Likes
3

Thanks, yes, I will open a ticket for this.

We have a pretty clear comparison now:

Ubuntu Linux:
same ThinkPad P53
same Crucial X9
same cable
same rear USB-C / Thunderbolt 3 port
Driver=uas, 10000M
raw read: about 1.0 GB/s

Haiku R1/beta5:
same hardware setup
SSD is detected and usable
raw read: about 31 MB/s
syslog shows:
ConfigureEndpoint() failed invalid max_burst_payload
unable to configure endpoint: Invalid Argument

So this does not look like a BFS, exFAT or partitioning issue anymore. It seems to be somewhere in the xHCI / USB mass storage / UAS path.

I will file this on the bug tracker and attach the listdev and syslog output.

2 Likes
4

Thanks, I tried to register an account on the bug tracker, but the registration form keeps rejecting me with:

Warning: Are you human? If so, try harder!

I filled in all required fields, including the anti-spam question, and tried it tree time. That’s just annoying. I’m also a forum admin, and we use logic questions at our forum, but not that kind of annoying stuff.

At this point I will leave the information here in the forum.

The short summary is:

ThinkPad P53
Crucial X9 1TB / Micron CT1000X9SSD9

Ubuntu Linux:
same SSD, same cable, same rear USB-C / Thunderbolt 3 port
Driver=uas, 10000M
raw read: about 1.0 GB/s

Haiku R1/beta5:
same hardware
SSD is detected and usable
raw read: about 31 MB/s

Relevant syslog:
usb error xhci 1: ConfigureEndpoint() failed invalid max_burst_payload
usb error xhci 1: unable to configure endpoint: Invalid Argument

So this does not look like a BFS, exFAT or partitioning problem. It seems to be somewhere in the xHCI / USB mass storage / UAS path.

If someone with a working bug tracker account wants to file this, feel free to use the data from this post.

have fun! :wink:

Greetz
Juergen

1 Like
5

I think those syslog errors are probably not relevant; if the endpoint failed to configure you wouldn’t be able to communicate at all.

Try using a nightly build; there were a number of changes to XHCI and usb_disk since beta5, and see if it’s any better there.

2 Likes
6

The answer is “Haiku” :slight_smile:

edit: in the future trac and discourse should be tucked under the same SSO, so this wouldn’t be as much of a problem… we aren’t there yet sadly

7

@nephele
Are you kidding me? :wink:
I know that. :smiley: but the script didn’t accept it. And I try and try and try…
And… at some point, you just tell yourself, “Forget it.” I have better things to do than waste my time on a half-baked script that doesn’t process input properly—or at all.

@waddlesplash
Thanks, but I am already using a nightly build:

Haiku shredder 1 hrev57937

Regarding the syslog messages: I would not dismiss them as irrelevant that quickly. USB communication is not all-or-nothing. A device can still answer on endpoint 0, provide descriptors, and be partially visible, while another endpoint, interface, transfer mode, reset, or xHCI-related operation fails later.

Also, the measured transfer values clearly show that when the SuperSpeed/USB 3.x part of the negotiation is missing or fails, the device falls back to USB 2.0 speeds. That is exactly the kind of behaviour one would expect from a failed or incomplete USB 3 handshake.

USB negotiation is a bit like an old modem connection: both sides first have to agree on what they can do. If the higher mode cannot be negotiated cleanly, communication may still continue, but at a lower mode or with reduced capabilities. So the fact that some communication works does not prove that the USB 3/xHCI path is healthy.

With USB storage devices, it is quite possible to get partial communication, failed configuration of a specific endpoint/interface, or problems during bulk transfers/UASP/BOT handling.

In my case the same hardware works under Windows/Linux, while Haiku reports USB/xHCI-related errors and the SSD is either not usable or only behaves like a USB 2.0 device. So I agree that the log messages alone may not prove the root cause, but they are certainly relevant clues and should not be ignored.

If needed, I can provide the full listdev and syslog output.

THX & Greetz
Juergen

8

Sure, I can understand it. I do also know that it seems to work just fine for people… In some cases people write Haiku “OS” or something instead and that fails; But I don’t know if there is a specific problem for your registration othwerwise… failures with this question are not logged in the antispam unfortunately

1 Like
9

What do you think? :wink:
Now it runs… I think, the captcha had have a crisis. :joy:

1 Like
10

Ahoy @anon81946179

It was ment to try it out on a fresh nightly build

   user  ~    01:40    catattr -d SYS:PACKAGE /system/lib/libbe.so
haiku-r1~beta5_hrev59787-1
   user  ~    17:19   

If you would be really on nightly, then you would have a

“Walter” project name in version

than

“shredder”.

So you can

  1. install elsewhere - on another partition or drive - an another instance

of a nightly Haiku version

or

  1. convert your Beta version Haiku into a Nightly one, by switching to nightly repos

====================================================================

SWITCH from BETA to NIGHTLY

====================================================================

HAIKU repo

pkgman add https://eu.hpkg.haiku-os.org/haiku/master/$(getarch)/current

HAIKUPORTS repo

pkgman add https://eu.hpkg.haiku-os.org/haikuports/master/$(getarch)/current

pkgman full sync

shutdown -r

====================================================================

SWITCH from NIGHTLY to BETA

====================================================================

HAIKU repo

pkgman add https://eu.hpkg.haiku-os.org/haiku/r1beta5/$(getarch)/current

HAIKUPORTS repo

pkgman add https://eu.hpkg.haiku-os.org/haikuports/r1beta5/$(getarch)/current

pkgman full sync

shutdown -r

====================================================================

Kind regards,

1 Like
11

“shredder” is the default hostname on a Haiku system. hrev57937 is a nightly release. All @anon81946179 needs to do is run “pkgman update” from the terminal, run the SoftwareUpdater app or select “Check for Updates…” from the HaikuDepot app to upgrade to the latest nightly release.

12

Ahoy @colmiga

Thanks to corrected me,
I remembered so that Haiku revision name was the “shredder” - so that way that is possibly ‘Haiku’ in R1BX.
I once renamed the Haiku’s host name in 2022, and then I see only if I move a higher capacity storage drive and rename to identify the instance with its drive capacity too, and when I would use uname -a command.

13

Yes, I think that was the misunderstanding.

shredder is only the hostname of the system, not the Haiku branch or release name. The hostname could be anything:

Haiku shredder ...
Haiku X9 ...
Haiku Kartoffelsalat ...

That would still not tell us whether the system is Beta5, nightly, or master. The actual package/repository state has to be checked with pkgman list-repos, uname -a, and catattr -d SYS:PACKAGE /system/lib/libbe.so.

In my case, pkgman list-repos shows the master repositories:

https://eu.hpkg.haiku-os.org/haiku/master/x86_64/current
https://eu.hpkg.haiku-os.org/haikuports/master/x86_64/current

uname -a shows:

Haiku shredder R1~beta5+development hrev59787 Jun 11 2026 06:02:29 x86_64 x86_64 Haiku

catattr -d SYS:PACKAGE /system/lib/libbe.so shows:

haiku-r1~beta5_hrev59787-1

So I understand that this is not a freshly installed nightly image. It is a converted installation using the master/nightly repositories and a development hrev. But it is also not a plain unchanged Beta5 installation anymore.

As an additional data point, the experimental NVIDIA/Nebula stack is installed and working for HDMI output.

listdev | grep -i -A4 nvidia shows the NVIDIA GPU:

vendor 10de: NVIDIA Corporation
device 1eb6: TU104GLM [Quadro RTX 4000 Mobile / Max-Q]

Nebula and the NVIDIA driver files are present:

/boot/system/packages/nebula-0.0.2-1-x86_64.hpkg
/boot/system/package-links/nebula-0.0.2-1
/boot/system/apps/Nebula/ModesetTool
/boot/system/add-ons/accelerants/nvidia.accelerant
/boot/system/add-ons/accelerants/nvidia_gsp.accelerant
/boot/system/add-ons/kernel/drivers/dev/graphics/nvidia
/boot/system/add-ons/kernel/drivers/dev/graphics/nvidia_gsp
/boot/system/data/firmware/nvidia

The syslog also shows that the NVIDIA driver initialized the GPU successfully:

KERN: nvidia_gsp: module_init
KERN: nvidia-modeset: Loading NVIDIA UNIX Open Kernel Mode Setting Driver for x86_64 570.86.16
KERN: NVRM: GPU 0000:01:00.0: RmInitAdapter
KERN: NVRM: GPU 0000:01:00.0: Successfully mapped framebuffer and registers
KERN: NVRM: GPU 0000:01:00.0: RmInitAdapter succeeded!
KERN: nvidia_module: open_gpu(256)

So the conclusion “not nightly” based on the hostname shredder is not valid. I agree that a freshly installed nightly image would be a separate and cleaner test case, but the current system is already using master/nightly repositories, a development hrev, and the NVIDIA/Nebula stack is installed and functional for HDMI output.

Greetz & a nice weekend
Juergen

1 Like
14

Ahoy JĂźrgen,

Ok, now you are on latest available in case nightly revision - I assume you upgraded to latest meanwhile.
I should have spin up a Beta5 Haiku before I wrote and released my post.

I wrote that earlier as you reported you are on hrev57937 - it was something fresh approximately in 2024, cca. around Beta5 release :cowboy_hat_face:
So that part was right from me.

Anyway ..
Me also hope if your reports help to fix/burst USB speed / protocols anyway :))

Have a rest, and enjoy your weekend,

1 Like
15

Please don’t post such huge posts with needlessly big Headers and huge dividers. If you want to show stuff like code for pkgman put that in a code block instead :slight_smile: (and don’t sign your post, that is the “regards” at the bottom)

16

There is no functional difference between an “upgraded” beta and a nightly. The only difference would be some config files or other data written before some update, but the packages (that is the “system files”) are completely identical

17

I direct copied my text file into the post about versin switches - it was interpreted this way in Discourse.

18

Yes, the forum does do some wierd markdown stuff. If you want to post plain text without it messing with formatting or so you can use a code block. It’s the </> icon in the menu bar :slight_smile: