Opened 6 years ago
Closed 3 years 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)
Change History (33)
by , 6 years ago
Attachment: | kernelpanichaiku.jpg added |
---|
comment:1 by , 6 years ago
I used this image: https://keybase.pub/kallisti5/haiku-nightly-anyboot-efi.iso
comment:2 by , 6 years ago
Component: | - General → System/Boot Loader |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 6 years ago
Blocked By: | 9910 added |
---|
According to https://www.ifixit.com/Teardown/Microsoft+Surface+Book+Teardown/51972 Surface Book has NVMe storage.
comment:4 by , 6 years ago
Component: | System/Boot Loader → Drivers |
---|---|
Owner: | changed from | to
follow-up: 7 comment:6 by , 6 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 , 6 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.
comment:7 by , 6 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 , 6 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 , 6 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 , 6 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 , 6 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 , 6 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.
comment:13 by , 6 years ago
Try smashing space bar instead of holding shift. IIRC holding shift doesn't work on EFI machines.
comment:14 by , 6 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 , 6 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 , 6 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 , 6 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 , 6 years ago
Attachment: | logs_no_NVMe_1.jpg added |
---|
by , 6 years ago
Attachment: | logs_no_NVMe_2.jpg added |
---|
comment:17 by , 6 years ago
Component: | Drivers → Drivers/USB/XHCI |
---|---|
Keywords: | uefi surface book removed |
Summary: | Cannot boot UEFI images on a Surface Book: kernel panic → XHCI: 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 , 6 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 , 6 years ago
Actually it looks like the quirks are unrelated; we should just resolve the errors by disabling and re-enabling the slots.
follow-up: 21 comment:20 by , 6 years ago
Owner: | changed from | to
---|
comment:21 by , 6 years ago
Replying to waddlesplash: Ok. Let me know if you need some more testing on this one.
comment:22 by , 6 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.
comment:23 by , 6 years ago
Note: the Surface Book has two GPUs. The integrated Intel one, and an NVidia GPU: maybe that could be related?
comment:27 by , 3 years ago
Milestone: | Unscheduled → R1/beta4 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
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.
Kernel panic while trying to boot an UEFI image on a Surface Book