Black Screen on Thinkpad T400 with Intel graphics and Coreboot

[johkra]

Haiku (nightly hrev51243, both 32bit and 64 bit) fails to boot on a Lenovo Thinkpad T400 (Core 2 Duo P8600, integrated Intel graphics) with Coreboot 4.6.

After initial messages on the screen, the boot ends at a black screen. When attaching to the serial console, the following trace is shown with default boot options:

intel_extreme: CALLED status_t intel_get_frame_buffer_config(frame_buffer_config*)
PANIC: _mutex_lock(): using unitialized lock 0xffffffff801c83e0
Welcome to Kernel Debugging Land...
Thread 457 "app_server" running on CPU 1
stack trace for thread 457 "app_server"
    kernel stack: 0xffffffff81430000 to 0xffffffff81435000
      user stack: 0x00007ff7fa566000 to 0x00007ff7fb566000
frame                       caller             <image>:function + offset
 0 ffffffff81434c18 (+  16) ffffffff80140299   <kernel_x86_64> arch_debug_stack_trace + 0x13
 1 ffffffff81434c28 (+  16) ffffffff800a471d   <kernel_x86_64> stack_trace_trampoline(void*) + 0x09
 2 ffffffff81434c38 (+  24) ffffffff8012ffac   <kernel_x86_64> arch_debug_call_with_fault_handler + 0x16
 3 ffffffff81434c50 (+  96) ffffffff800a50b8   <kernel_x86_64> debug_call_with_fault_handler + 0x68
 4 ffffffff81434cb0 (+  96) ffffffff800a6068   <kernel_x86_64> kernel_debugger_loop(char const*, char const*, __va_list_tag*, int) + 0x225
 5 ffffffff81434d10 (+  80) ffffffff800a6323   <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x137
 6 ffffffff81434d60 (+ 240) ffffffff800a6580   <kernel_x86_64> panic + 0xc1
 7 ffffffff81434e50 (+  80) ffffffff8008c68b   <kernel_x86_64> _mutex_lock + 0xf0
 8 ffffffff81434ea0 (+  64) ffffffff800af3bc   <kernel_x86_64> frame_buffer_update + 0x30
 9 ffffffff81434ee0 (+  64) ffffffff800af68f   <kernel_x86_64> _user_frame_buffer_update + 0x5a
10 ffffffff81434f20 (+  24) ffffffff8013a485   <kernel_x86_64> x86_64_syscall_entry + 0xfb
user iframe at 0xffffffff81434f38 (end = 0xffffffff81435000)
 rax 0xf4                  rbx 0x1e476307460         rcx 0x1b29b90a89c
 rdx 0x320                 rsi 0x500                 rdi 0xffffffff90010000
 rbp 0x7ff7fb564880         r8 0x1400                 r9 0x104000
 r10 0x20                  r11 0x3202                r12 0x20
 r13 0x1                   r14 0x320                 r15 0x1400
 rip 0x1b29b90a89c         rsp 0x7ff7fb564818     rflags 0x3202
 vector: 0x63, error code: 0x0
11 ffffffff81434f38 (+140705176680776) 000001b29b90a89c   <libroot.so> _kern_frame_buffer_update + 0x0c
12 00007ff7fb564880 (+  96) 000001834dc10c7b   <_APP_> Screen::SetMode(display_mode const&) + 0x53
13 00007ff7fb5648e0 (+  80) 000001834dc10d08   <_APP_> Screen::SetPreferredMode() + 0x2a
14 00007ff7fb564930 (+ 112) 000001834dc344a4   <_APP_> VirtualScreen::AddScreen(Screen*, ScreenConfigurations&) + 0x94
15 00007ff7fb5649a0 (+ 304) 000001834dc3494c   <_APP_> VirtualScreen::SetConfiguration(Desktop&, ScreenConfigurations&, unsigned int*) + 0x294
16 00007ff7fb564ad0 (+ 240) 000001834dc00ed7   <_APP_> Desktop::Init() + 0x119
17 00007ff7fb564bc0 (+  80) 000001834dbf51ae   <_APP_> AppServer::_CreateDesktop(unsigned int, char const*) + 0x56
18 00007ff7fb564c10 (+ 176) 000001834dbf537f   <_APP_> AppServer::MessageReceived(BMessage*) + 0xc3
19 00007ff7fb564cc0 (+  16) 000000899296bd40   <libbe.so> BLooper::DispatchMessage(BMessage*, BHandler*) + 0x34
20 00007ff7fb564cd0 (+ 576) 0000008992965219   <libbe.so> BApplication::DispatchMessage(BMessage*, BHandler*) + 0x39b
21 00007ff7fb564f10 (+  96) 000000899296c0cc   <libbe.so> BLooper::task_looper() + 0x1dc
22 00007ff7fb564f70 (+  32) 0000008992961eee   <libbe.so> BApplication::Run() + 0x50
23 00007ff7fb564f90 (+  48) 000001834dbf56e7   <_APP_> main + 0x42
24 00007ff7fb564fc0 (+  48) 000001834dbf495e   <_APP_> _start + 0x54
25 00007ff7fb564ff0 (+  48) 000001a21b1abe48   </boot/system/runtime_loader@0x000001a21b198000> <unknown> + 0x13e48
26 00007ff7fb565020 (+   0) 00007f70db2aa260   <commpage> commpage_thread_exit + 0x00

In safemode (all safe mode options enabled), the following trace is shown:

vm_soft_fault: va 0x0 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x0, ip 0xffffffff815096e1, write 0, user 0, thread 0x61
PANIC: vm_page_fault: unhandled page fault in kernel space at 0x0, ip 0xffffffff815096e1

Welcome to Kernel Debugging Land...
Thread 97 "app_server" running on CPU 0
stack trace for thread 97 "app_server"
    kernel stack: 0xffffffff813c7000 to 0xffffffff813cc000
      user stack: 0x00007f9cc11fe000 to 0x00007f9cc21fe000
frame                       caller             <image>:function + offset
 0 ffffffff813cb648 (+  16) ffffffff80140299   <kernel_x86_64> arch_debug_stack_trace + 0x13
 1 ffffffff813cb658 (+  16) ffffffff800a471d   <kernel_x86_64> stack_trace_trampoline(void*) + 0x09
 2 ffffffff813cb668 (+  24) ffffffff8012ffac   <kernel_x86_64> arch_debug_call_with_fault_handler + 0x16
 3 ffffffff813cb680 (+  96) ffffffff800a50b8   <kernel_x86_64> debug_call_with_fault_handler + 0x68
 4 ffffffff813cb6e0 (+  96) ffffffff800a6068   <kernel_x86_64> kernel_debugger_loop(char const*, char const*, __va_list_tag*, int) + 0x225
 5 ffffffff813cb740 (+  80) ffffffff800a6323   <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x137
 6 ffffffff813cb790 (+ 240) ffffffff800a6580   <kernel_x86_64> panic + 0xc1
 7 ffffffff813cb880 (+ 240) ffffffff8011b7e8   <kernel_x86_64> vm_page_fault + 0x161
 8 ffffffff813cb970 (+  64) ffffffff8014155f   <kernel_x86_64> x86_page_fault_exception + 0x1c4
 9 ffffffff813cb9b0 (+ 536) ffffffff8013a1df   <kernel_x86_64> int_bottom + 0x56
kernel iframe at 0xffffffff813cbbc8 (end = 0xffffffff813cbc90)
 rax 0x0                   rbx 0x80001301            rcx 0x8
 rdx 0x3ce                 rsi 0x4                   rdi 0x3ce
 rbp 0xffffffff813cbd10     r8 0x0                    r9 0x27f
 r10 0x0                   r11 0x3206                r12 0x0
 r13 0x7f9cc21fd4e0        r14 0x7f9cc21fd4e0        r15 0x27f
 rip 0xffffffff815096e1    rsp 0xffffffff813cbc90 rflags 0x13202
 vector: 0xe, error code: 0x0
10 ffffffff813cbbc8 (+ 328) ffffffff815096e1   </boot/system/add-ons/kernel/drivers/dev/graphics/vesa> vga_planar_blit(vesa_shared_info*, unsigned char*, int, int, int, int, int) + 0xbc
11 ffffffff813cbd10 (+  96) ffffffff8150851d   </boot/system/add-ons/kernel/drivers/dev/graphics/vesa> device_ioctl(void*, unsigned int, void*, unsigned long) + 0x294
12 ffffffff813cbd70 (+  16) ffffffff800b95d7   <kernel_x86_64> BPrivate::AbstractModuleDevice::Control(void*, int, void*, unsigned long) + 0x19
13 ffffffff813cbd80 (+ 304) ffffffff800bffea   <kernel_x86_64> devfs_ioctl(fs_volume*, fs_vnode*, void*, unsigned int, void*, unsigned long) + 0x218
14 ffffffff813cbeb0 (+  16) ffffffff800e6d44   <kernel_x86_64> common_ioctl(file_descriptor*, unsigned long, void*, unsigned long) + 0x30
15 ffffffff813cbec0 (+  64) ffffffff800dbd6b   <kernel_x86_64> fd_ioctl(bool, int, unsigned int, void*, unsigned long) + 0x7b
16 ffffffff813cbf00 (+  32) ffffffff800dc941   <kernel_x86_64> _user_ioctl + 0x45
17 ffffffff813cbf20 (+  24) ffffffff8013a485   <kernel_x86_64> x86_64_syscall_entry + 0xfb
user iframe at 0xffffffff813cbf38 (end = 0xffffffff813cc000)
 rax 0x92                  rbx 0x27f                 rcx 0x73e5b1d27c
 rdx 0x7f9cc21fd4e0        rsi 0x2716                rdi 0x4
 rbp 0x7f9cc21fd4b0         r8 0x0                    r9 0x27f
 r10 0x20                  r11 0x3206                r12 0x0
 r13 0x1c8f599f870         r14 0x1c8f58e4ce0         r15 0x0
 rip 0x73e5b1d27c          rsp 0x7f9cc21fd448     rflags 0x3206
 vector: 0x63, error code: 0x0
18 ffffffff813cbf38 (+140313375217016) 00000073e5b1d27c   <libroot.so> _kern_ioctl + 0x0c
19 00007f9cc21fd4b0 (+ 128) 0000015b65013375   <_APP_> HWInterface::_CopyToFront const(unsigned char*, unsigned int, int, int, int, int) + 0x3f1
20 00007f9cc21fd530 (+  96) 0000015b6501359b   <_APP_> HWInterface::_CopyBackToFront(BRegion&) + 0x95
21 00007f9cc21fd590 (+ 112) 0000015b650087fa   <_APP_> AccelerantHWInterface::_CopyBackToFront(BRegion&) + 0xd8
22 00007f9cc21fd600 (+ 192) 0000015b65014f0f   <_APP_> HWInterface::CopyBackToFront(BRect const&) + 0x193
23 00007f9cc21fd6c0 (+  32) 0000015b65012a96   <_APP_> HWInterface::Invalidate(BRect const&) + 0x2e
24 00007f9cc21fd6e0 (+ 160) 0000015b6500bbca   <_APP_> DrawingEngine::FillRegion(BRegion&, rgb_color const&) + 0x13c
25 00007f9cc21fd780 (+ 112) 0000015b64fb310b   <_APP_> Desktop::_SetBackground(BRegion&) + 0x9b
26 00007f9cc21fd7f0 (+ 240) 0000015b64fb7064   <_APP_> Desktop::Init() + 0x2a6
27 00007f9cc21fd8e0 (+  80) 0000015b64fab1ae   <_APP_> AppServer::_CreateDesktop(unsigned int, char const*) + 0x56
28 00007f9cc21fd930 (+ 176) 0000015b64fab37f   <_APP_> AppServer::MessageReceived(BMessage*) + 0xc3
29 00007f9cc21fd9e0 (+  16) 00000129afb16d40   <libbe.so> BLooper::DispatchMessage(BMessage*, BHandler*) + 0x34
30 00007f9cc21fd9f0 (+ 576) 00000129afb10219   <libbe.so> BApplication::DispatchMessage(BMessage*, BHandler*) + 0x39b
31 00007f9cc21fdc30 (+  96) 00000129afb170cc   <libbe.so> BLooper::task_looper() + 0x1dc
32 00007f9cc21fdc90 (+  32) 00000129afb0ceee   <libbe.so> BApplication::Run() + 0x50
33 00007f9cc21fdcb0 (+  48) 0000015b64fab6e7   <_APP_> main + 0x42
34 00007f9cc21fdce0 (+  48) 0000015b64faa95e   <_APP_> _start + 0x54
35 00007f9cc21fdd10 (+  48) 000001dfbd55be48   </boot/system/runtime_loader@0x000001dfbd548000> <unknown> + 0x13e48
36 00007f9cc21fdd40 (+   0) 00007f74d2220260   <commpage> commpage_thread_exit + 0x00

I'll attach full serial output for different configurations to the ticket. Please tell me if I can provide any further information or run any tests to help investigate this issue.

[waddlesplash]

Woah, a VESA crash. I've never seen one of those before.

[waddlesplash]

Hmm. It looks almost like it's just completely failing to initialize a framebuffer in VESA mode, and so it tries to initialize the lowest-common-denominator mode and failing:

No VESA compatible graphics!
...
app_server: Finding best mode for 1024x768 (8, 60 Hz, strict) failed
app_server: Finding best mode for 800x600 (8, 60 Hz) failed
app_server: Use 800x525 (2) instead.

And in intel_extreme mode, there are some rather worrying trace messages:

intel_extreme: mapping VBIOS: 0xc0000 -> 0xffffffff80262000
intel_extreme: bad VBT signature:              Uª6é=6
...
intel_extreme: Analog A: using ddc @ 0x4005010
DDC: ddc2_read: DDC information read failure
Last message repeated 3 times.
...
AGP: create memory 0xffffffff8a82f300, base ffffffff90010000, size 3e8000, flags 0
AGP: allocation is made of reserved memory
AGP: reserved memory already bound

This is really weird, I don't know that we've ever seen a failure like this before.

[waddlesplash]

Does Linux successfully boot into graphics mode under Coreboot? If so, could you boot into that and then attach the output of the lspci command?

[johkra]

Yes, Linux boots into graphics mode. I've previously also booted OpenBSD into X. Both should use the kernel modesetting code.

In coreboot, the option CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT is enabled. I use SeaBIOS which uses SeaVGABios. Unfortunately, I don't know how all of these components interact, but it is possible that this setup doesn't provide the same interfaces as Intel's VGA firmware.

[waddlesplash]

OK, thanks for that. Yeah, broken VESA sounds like a possibility here; and our intel_extreme driver is known to be flaky. I'll move to that component for now, and leave the job of more fully investigating to someone who knows more than I do about that.

At any rate, welcome! Always nice to see new bug reporters :)

[johkra]

Windows 7 did not boot into a graphical UI with native VGA init either.

I build coreboot with the Intel VGA Bios and now Windows 7 booted into a graphical UI.

Haiku in fallback graphics mode boots into the graphical user interface. Haiku with default options still shows only a black screen.

(The integrated mouse and keyboard did not work. A USB mouse did work. I'll investigate a bit more and file a separate bug about this.)

[waddlesplash]

Please retest after hrev53040.

[johkra]

I've tried hrev53183. When booting from USB with default options, I get a black screen with working backlight. This is repeatable.

Enabling serial debug output is enough for Haiku to start with graphical output. Any future boots after enabling serial debug output once also start with working graphical output even if no boot options are changed. I did not change any other debug options like safe mode.

Re-creating the USB stick leads first to a black screen and than to working boot after enabling serial debug and changing no other options.

I'll provide serial logs after I can get hold of a working cable. If there are any logs I can generate from the running Haiku system, please point me towards instructions on how to do this.

(The integrated touchpad/trackpoint and keyboard don't work. An external USB mouse works.)

[pulkomandy]

I'm not surprised VESA is in trouble with Coreboot. I think the framebuffer driver for UEFI may be a better choice in this case.

As for Intel, I had a similar thing happening on one of my previous machines (which I didn't keep long enough to fix the problem, unfortunately): it woudl boot to a working screen, but with backlight off (I could see it under bright light). And when I added a serial port in the expresscard slot, suddenly it started working. I think the extra delays spent sending data to the serial port change the timings just enough that the device initializes properly.

[pulkomandy]

Please try with ​https://review.haiku-os.org/c/haiku/+/1902 and provide an updated syslog

[johkra]

Syslog of Haiku hrev53572 on T400 with Coreboot

[johkra]

I had previously reflashed coreboot on the T400 to add a video firmware. It works on the T400 with video firmware. I've attached syslog for this system.

I checked on a T200 (also with Coreboot, but without video firmware) and I'm getting a black screen. I don't have a docking station for the T200 and no idea how to get debug output without a serial port. Fail-safe graphics also failed.

I'll try to get Coreboot without video firmware on the T400, check if it still works and capture serial output if it doesn't.

[johkra]

When I don't use the video firmware, I also get a black screen on the T400.

Unfortunately, I haven't been able to get any usable serial output from the docking station (tried with T60 and T400 on the docking station, different cables and different USB->Serial adapters and a real RS-232 port; tests were run Linux to Linux) although I can send reliably to the docking station. Until I find a way to fix this or find another way to get the syslog (network?) when graphical output is failing, I can't provide more details. :-(

[pulkomandy]

The syslog is saved to disk as well.

For serial output, you need a "real" serial port (USB adapters are not handled), and if it is on the PCI bus, you may need to set the correct address for it in the kernel settings (I have to do this to use an expresscard serial port adapter, for example).

[johkra]

When booting from live USB without any input there is no syslog file on disk.

I had to re-write the image and the screen is now showing colourful lines (I'll add an attachment). The lines changes on each boot.

The syslog file was on the USB from a successful live desktop session with the video firmware. The USB got corrupted later, so I had to rewrite the image.

I'll try to re-flash with video firmware, install to HDD, reflash without video firmware and see if I can get an updated log with the failure.

The output from the first message in the bug report was from the serial port on the docking station. It's supported, but broke in some way. :-(

[johkra]

Colourful lines on screen with freshly written hrev53572.

[johkra]

Syslog of Haiku hrev53572 on T400 with Coreboot and no video firmware

[johkra]

OK, I was able to get the syslog from Haiku installed to HDD. There is no regular graphical output, only the colourful lines from the image.

This is on a T400 with coreboot master without video firmware extracted from the Lenovo firmware (BIOS). Linux with Kernel Mode Setting works fine.

[pulkomandy]

The syslog contains two boot attempts on apparently different machines? In the first one, a VBT is found in the BIOS, and things seems to go fine.

In the second, no VBT is found (which doesn't matter, but tells me something about the hardware/BIOS changed), and in the end there is this error repeated several times:

KERN: intel_extreme: engine locked up, head 0!

I think our driver still relies on the VESA BIOS to set up some things on the card, and only does the final part of the modesetting.

I think we should move this ticket out of the beta2 milestone for now, as it seems to be specific to Coreboot (not blaming them, but the combination of coreboot and haiku is uncommon so maybe a bit lower priority)

[waddlesplash]

KERN: intel_extreme: engine locked up, head 0!

Actually, this is the same message I see on my Broadwell device (which is not enabled as it is broken in the driver due to this.) When I investigated, I discovered that on this generation Intel completely redid how the engine rings work, and we only implement the old way, so the ring code does not work with them. Something similar may be true here, if it's not the same problem.

[pulkomandy]

This is a Thinkpad T400, which I'm fairly sure is not Broadwell but one of the very old generations. Unless the later part of the syslog is not from that same machine.

[johkra]

The T400 is an old Core 2 Duo system, I think Penryn.

https://dev.haiku-os.org/attachment/ticket/13580/syslog and https://dev.haiku-os.org/attachment/ticket/13580/syslog.2 are from the same physical machine with slightly different coreboot builds: One includes the Intel video firmware and one does not.

I think it makes sense to not block on this for the next release. I understand that implementing driver support for things normally set up by the video firmware is a lot of work and probably not worth implementing for older platforms if things changed a lot on newer platforms. Feel free to close as not feasible.

I run coreboot on my 'toy' systems (T400, X200, X230) on which I'd like to try other systems like Haiku on real hardware. I'll see if I can flash the X230 with video firmware and run Haiku on it.

[pulkomandy]

Well, if Linux manages, I would not say this is "not feasible". But indeed that makes it somewhat lower priority, for now (until everyone starts to use coreboot, I guess)