My system will not boot nightly cd's newer than hrev53659

[WildKeccak]

I am booting off an external LG blu-ray drive. These are DVD media. x86_64, AMD Ryzen 5 3400G December 31,2019 at 7:23:55 AM. x570 chipset Ryzen 5700 XT video card.

[pulkomandy]

I suspect it's because of ​https://git.haiku-os.org/haiku/commit/?id=7b4d924f98c08c57e6566b33aeda00cac2f6fec7 (same as #15658).

[pulkomandy]

Should be fixed in hrev53777.

[WildKeccak]

The issue remains. I think hrev53672 and hrev53673 are relevant.

[diver]

Yep, looks like hrev53672 is the culprit.

[waddlesplash]

The messages in the picture have appeared in other XHCI tickets long before I made that change. Can you please confirm that a hrev < hrev53672 actually works? (Make sure to use the exact same USB drive and port when testing as this can affect results.)

[waddlesplash]

If hrev53672 is really the culprit, I'll need a full syslog from a failed boot.

[WildKeccak]

The file is never made, even on a flash stick. The mobo is MSI X570-A Pro.

[waddlesplash]

Yes, you will have to capture it via serial log, or taking pictures of the syslog pages using "on screen debug output" mode.

[waddlesplash]

Please retest after hrev53855.

[WildKeccak]

hrev53864, serial log

[WildKeccak]

It still doesn't work.

[waddlesplash]

usb xhci 1: transfer error on slot 3 endpoint 1: Length invalid

This error also showed up in #15333 recently. Interesting.

[waddlesplash]

OK, actually this is just due to the StopEndpoint command being invoked on the endpoint; we should ignore it.

It is very odd that there are no errors before the first timeout, after which it seems everything just fails. But since there is just one commit that is the clear break, I guess trying to determine what I did wrong may not be so difficult.

[waddlesplash]

So, I just noticed that the stalling pipe and requests are pipe 0 (i.e. the default control pipe.) The changes in hrev53672 should not change pipe 0 initialization at all (the refactors should not amount to a functional change, and the SubmitNormalRequest items will not affect it either, as Control transfers go through SubmitControlRequest.)

WildKeccak, if possible, can you do a git-revert hrev53672 locally, rebuild Haiku ("@nightly-anyboot" target, probably) and test to see if it is still broken under that? Either way, please post a syslog. (Also, if you have a syslog from a successful boot with this setup, that will also be helpful.)

[WildKeccak]

Working on the build, but I've noticed that there is activity on the DVD drive, long after the computer has "crashed".

[WildKeccak]

Boot of a system log from a (definitely) homebrew cd of hrev 53671 after successful boot

[WildKeccak]

Some ingredients are missing, such as a boot logo and ability to press space and get a special boot menu when I make my nightlies. I don't know how.

[pulkomandy]

The logo is not included because only official images provided by Haiku have it (you can use "--distro-compatibility official" argument to configure to enable it in your own builds).

However the boot menu should be there in either case, but the timing can be a bit tight. For the BIOS loader it's easier to hold shift, but for the EFI one you have to spam the space key very quickly, I guess.

[WildKeccak]

A serial capture of hrev53672 struggling to boot on hrev53672

[WildKeccak]

An extra capture of hrev53672

[waddlesplash]

Can you add a TRACE_ALWAYS statement where "endpoint->max_burst_payload" is assigned, and capture a new serial log? That's the only thing that changed in hrev53672, so somehow that is the cause here.

[WildKeccak]

Yah, I should've added a newline, but I did that.

The format is 'trbSize is n'.

At first, n is 1, and then it's 512 until the end.

Attachment will be here momentarily

[WildKeccak]

Attachment from working laptop momentarily

trbSize is 64, period.

[waddlesplash]

In your working version, usb_disk never initializes, so it may be the case that the 1-sized TRB is always constructed anyway.

Otherwise, 512 should be an entirely reasonable size and in accordance with the specification here. However, I noticed there is a bug in the breaking commit which makes TD Size incorrectly computed, which may be relevant.

[WildKeccak]

Is this happening? ​https://www.ti.com/lit/pdf/sllz076

Number 5

[waddlesplash]

The four XHCI controllers you have appear to be two of:

PCI:   vendor 1022: Advanced Micro Devices, Inc. [AMD]
PCI:   device 149c: Matisse USB 3.0 Host Controller

and then:

PCI:   vendor 1022: Advanced Micro Devices, Inc. [AMD]
PCI:   device 15e0: Raven USB 3.1

PCI:   vendor 1022: Advanced Micro Devices, Inc. [AMD]
PCI:   device 15e1: Raven USB 3.1

I don't see any indications that these are really TI controllers in disguise...

Also, the problem here is actually a transfer stall, as noted above. So we are actually getting an error condition from the hardware. So, no, it's not item 5 under any circumstance.

[waddlesplash]

See if hrev53889 changes anything here.

[WildKeccak]

It works!

[WildKeccak]

A (modest) success

[waddlesplash]

Thanks for testing!

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone