Opened 16 months ago

Last modified 8 months ago

#14454 assigned bug

XHCI: Device check-sum error

Reported by: warpdesign2 Owned by: waddlesplash
Priority: normal Milestone: Unscheduled
Component: Drivers/USB/XHCI Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no 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 16 months ago.
Kernel panic while trying to boot an UEFI image on a Surface Book
haikuSmall.jpg (65.6 KB ) - added by warpdesign2 8 months 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 8 months ago.
OnScreen debug 1
logs_without_NVMe.zip (2.6 MB ) - added by warpdesign2 8 months 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 8 months ago.
logs_no_NVMe_2.jpg (1.3 MB ) - added by warpdesign2 8 months ago.

Change History (31)

by warpdesign2, 16 months ago

Attachment: kernelpanichaiku.jpg added

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

comment:2 by diver, 16 months ago

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

comment:3 by KapiX, 16 months ago

Blocked By: 9910 added

comment:4 by diver, 16 months ago

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

comment:5 by warpdesign2, 16 months ago

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

comment:6 by waddlesplash, 8 months 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, 8 months 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, 8 months 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, 8 months 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, 8 months 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, 8 months 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, 8 months 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, 8 months 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 8 months ago by warpdesign2 (previous) (diff)

comment:13 by diver, 8 months ago

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

by warpdesign2, 8 months ago

Attachment: 20190418_112145.jpg added

OnScreen debug 1

comment:14 by warpdesign2, 8 months 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, 8 months 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, 8 months 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, 8 months 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, 8 months ago

Attachment: logs_no_NVMe_1.jpg added

by warpdesign2, 8 months ago

Attachment: logs_no_NVMe_2.jpg added

comment:17 by waddlesplash, 8 months 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, 8 months 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, 8 months 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, 8 months ago

Owner: changed from nobody to waddlesplash

in reply to:  20 comment:21 by warpdesign2, 8 months ago

Ok. Let me know if you need some more testing on this one.

Last edited 8 months ago by warpdesign2 (previous) (diff)

comment:22 by warpdesign2, 8 months 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 8 months ago by warpdesign2 (previous) (diff)

comment:23 by warpdesign2, 8 months 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, 8 months ago

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

comment:25 by warpdesign2, 8 months ago

Note 2: SDCard is formatted as exFAT.

Note: See TracTickets for help on using tickets.