Opened 6 years ago

Closed 23 months ago

#14454 closed bug (fixed)

XHCI: Device check-sum error

Reported by: warpdesign2 Owned by: waddlesplash
Priority: normal Milestone: R1/beta4
Component: Drivers/USB/XHCI Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Trying to boot an UEFI image on a Surface Book gives a kernel panic

Attachments (6)

kernelpanichaiku.jpg (400.4 KB ) - added by warpdesign2 6 years ago.
Kernel panic while trying to boot an UEFI image on a Surface Book
haikuSmall.jpg (65.6 KB ) - added by warpdesign2 5 years ago.
For reference: on left is a small pocket boot. The text on the screen appears a lot smaller and is very difficult to read.
20190418_112145.jpg (972.4 KB ) - added by warpdesign2 5 years ago.
OnScreen debug 1
logs_without_NVMe.zip (2.6 MB ) - added by warpdesign2 5 years ago.
Logs with NVMe disabled (I had to take two shots to have the whole screen).
logs_no_NVMe_1.jpg (1.4 MB ) - added by warpdesign2 5 years ago.
logs_no_NVMe_2.jpg (1.3 MB ) - added by warpdesign2 5 years ago.

Change History (33)

by warpdesign2, 6 years ago

Attachment: kernelpanichaiku.jpg added

Kernel panic while trying to boot an UEFI image on a Surface Book

comment:2 by diver, 6 years ago

Component: - GeneralSystem/Boot Loader
Owner: changed from nobody to jessicah
Status: newassigned

comment:3 by KapiX, 6 years ago

Blocked By: 9910 added

comment:4 by diver, 6 years ago

Component: System/Boot LoaderDrivers
Owner: changed from jessicah to nobody

comment:5 by warpdesign2, 6 years ago

How relevant is it? I'm trying to boot from an USB stick...

comment:6 by waddlesplash, 5 years ago

Blocked By: 9910 removed

Not at all.

Probably this was an XHCI problem. Please retest under a recent nightly. If you still get the panic on first try, use a USB2 drive.

by warpdesign2, 5 years ago

Attachment: haikuSmall.jpg added

For reference: on left is a small pocket boot. The text on the screen appears a lot smaller and is very difficult to read.

in reply to:  6 comment:7 by warpdesign2, 5 years ago

Replying to waddlesplash:

Not at all.

Probably this was an XHCI problem. Please retest under a recent nightly. If you still get the panic on first try, use a USB2 drive.

Do recent build support UEFI?

I downloaded an anyboot file from here: https://download.haiku-os.org/nightly-images/x86_64/

I get a panic with the error "PANIC: did not find any boot partitions!".

Btw, on small high DPI display, the text appears so small that it's almost unreadable.

comment:8 by waddlesplash, 5 years ago

Yes, they do.

Did you test this with a USB2 drive as I requested, or only a USB3 one? The former usually works, the latter currently does not.

comment:9 by warpdesign2, 5 years ago

Yes I did. Tried with both USB3 and USB2 drive: got the same panic error. Btw the keyboard doesn't work when in kernel panic.

comment:10 by waddlesplash, 5 years ago

OK. I'll need a syslog before I can try to debug this more. If you soft-reset the device while it is in KDL, the bootloader should be able to save a copy of the previous syslog, see here: https://www.haiku-os.org/docs/userguide/en/bootloader.html

Otherwise, using the "on-screen debug output" (with "on screen paging" disabled) and hoping that the relevant information is in the final screen may be a possibility.

comment:11 by warpdesign2, 5 years ago

I can't softboot since the keyboard does not work in KDL.

Tried pressing shift before booting Haiku but it doesn't appears to work: it continues to boot and crashes again and do not go to the boot menu.

comment:12 by warpdesign2, 5 years ago

I also tried plugging in an USB keyboard but it still doesn't show the boot menu when pressing shift.

Is there a way to change default boot options on the usb stick by modifying some text file maybe? This way I could enable the on-screen debug output by default.

Last edited 5 years ago by warpdesign2 (previous) (diff)

comment:13 by diver, 5 years ago

Try smashing space bar instead of holding shift. IIRC holding shift doesn't work on EFI machines.

by warpdesign2, 5 years ago

Attachment: 20190418_112145.jpg added

OnScreen debug 1

comment:14 by warpdesign2, 5 years ago

Space bar works, so I enabled "on-screen debug output" and disabled "screen paging". Here is the last things that appear (see third thread attachment). If needed I may increase the screen resolution so that more debug may appear (I reduced it in the boot loader to make text appear bigger).

comment:15 by waddlesplash, 5 years ago

Please re-test with the NVMe driver blacklisted in the bootloader (it's in add-ons/kernel/drivers/disk/nvme_disk.) But even this may not be enough for us to see precisely what the issue is, and we may need to figure out some other method of getting the whole syslog.

by warpdesign2, 5 years ago

Attachment: logs_without_NVMe.zip added

Logs with NVMe disabled (I had to take two shots to have the whole screen).

comment:16 by diver, 5 years ago

Please don't attach zip files, it makes it hard to view as they need to be downloaded and unzipped first. Trac has a built-in image viewer.

by warpdesign2, 5 years ago

Attachment: logs_no_NVMe_1.jpg added

by warpdesign2, 5 years ago

Attachment: logs_no_NVMe_2.jpg added

comment:17 by waddlesplash, 5 years ago

Component: DriversDrivers/USB/XHCI
Keywords: uefi surface book removed
Summary: Cannot boot UEFI images on a Surface Book: kernel panicXHCI: Device check-sum error

Indeed, the second picture shows what the problem is: all attempts to fetch the device descriptors for all attached devices gives "Device check-sum error".

The device ID of the XHCI controller is not in the pictures, but the HD audio controller is a "Sunrise Point-LP" family device, so I am guessing that the XHCI controller is also.

comment:18 by waddlesplash, 5 years ago

There appear to be some quirks in the Linux XHCI driver for this device; the "PME" quirk may be the most relevant here. I'll take a look when I have time probably in a few weeks.

comment:19 by waddlesplash, 5 years ago

Actually it looks like the quirks are unrelated; we should just resolve the errors by disabling and re-enabling the slots.

comment:20 by waddlesplash, 5 years ago

Owner: changed from nobody to waddlesplash

in reply to:  20 comment:21 by warpdesign2, 5 years ago

Replying to waddlesplash: Ok. Let me know if you need some more testing on this one.

Version 0, edited 5 years ago by warpdesign2 (next)

comment:22 by warpdesign2, 5 years ago

I had forgot, but had an SDCard plugged in (I use it as additional storage so I usually never unplug it): removing it and trying to boot Haiku again goes further.

Boot process seems to continue until the last icon is lit. Then the screen goes black and nothing happens (numlock appears to work which suggests Haiku is alive).

I'll create a separate bug report for the black screen.

So current bug appears to be related to the SDCard that's plugged in.

Last edited 5 years ago by warpdesign2 (previous) (diff)

comment:23 by warpdesign2, 5 years ago

Note: the Surface Book has two GPUs. The integrated Intel one, and an NVidia GPU: maybe that could be related?

comment:24 by warpdesign2, 5 years ago

Use "fail safe" graphics drivers fixes the black screen problem.

comment:25 by warpdesign2, 5 years ago

Note 2: SDCard is formatted as exFAT.

comment:26 by waddlesplash, 2 years ago

Please retest under a recent nightly.

comment:27 by waddlesplash, 23 months ago

Milestone: UnscheduledR1/beta4
Resolution: fixed
Status: assignedclosed

It looks like this ticket had a workaround anyway, but "device check-sum error" while fetching descriptors has also been resolved (I think someone may have even tested that on a Surface Book.) Closing as fixed.

Note: See TracTickets for help on using tickets.