I'm getting this panic on Raspberry. I'm running 10-stable r272221. It's booting fine until I updated. Probably the problem was introduced after r271973. DRAM: 480MB Number of U-Boot devices: 1 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice=<auto> partition=<auto>... good. Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x4ca5e4+0xada1c syms=[0x4+0x886d0+0x4+0x528af] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x0x100. Kernel entry at 0x100100... Kernel args: (null) panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 Uptime: 1s
Same problem on HEAD r272282.
I reverted just r271973 (on 10-stable) and the system boots again.
Can you attach the output from a verbose boot?
The verbose boot don't show any extra information. loader> show LINES=24 boot_multicons=YES boot_verbose=YES bootfile=kernel console=uboot currdev=disk0s2a: interpret=OK kernel=kernel kernel_options= kernelname=/boot/kernel/kernel loaddev=disk0s2a: loader_conf_files=/boot/device.hints /boot/loader.conf /boot/loader.conf.local mac_ifoff=NO module_path=/boot/kernel;/boot/modules prompt=loader> loader> boot -v Booting... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x100100... Kernel args: -v panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 Uptime: 1s
Created attachment 147966 [details] vtterm_cnprobe: Only recompute term size if screen size != 0 I see that there's no vt(4) driver built into RPI-B kernel configuration, therefore, the screen size is unknown (and set to 0). Could you please try the attached patch?
It works! Tested on 10 and head.
I never used a RaspberryPi, so my question might be stupid: does it have a video output? If yes, do you see a working console if you plug in a monitor?
At this moment I have just a usb/serial cable. I can test with a monitor but just on next Monday. Maybe someone in freebsd-arm@ can do it.
A commit references this bug: Author: dumbbell Date: Sat Oct 4 18:40:40 UTC 2014 New revision: 272537 URL: https://svnweb.freebsd.org/changeset/base/272537 Log: vt(4): Don't recalculate buffer size if we don't know screen size When the screen size is unknown, it's set to 0x0. We can't use that as the buffer size, otherwise, functions such as vtbuf_fill() will fail. This fixes a panic on RaspberryPi, where there's no vt(4) backend configured early in boot. PR: 193981 Tested by: danilo@ MFC after: 3 days Changes: head/sys/dev/vt/vt_core.c
A commit references this bug: Author: dumbbell Date: Mon Oct 13 14:40:01 UTC 2014 New revision: 273037 URL: https://svnweb.freebsd.org/changeset/base/273037 Log: vt(4): Don't recalculate buffer size if we don't know screen size (MFC of r272537) When the screen size is unknown, it's set to 0x0. We can't use that as the buffer size, otherwise, functions such as vtbuf_fill() will fail. This fixes a panic on RaspberryPi, where there's no vt(4) backend configured early in boot. PR: 193981 Tested by: danilo@ Changes: _U stable/10/ stable/10/sys/dev/vt/vt_core.c
A commit references this bug: Author: dumbbell Date: Tue Oct 14 19:10:00 UTC 2014 New revision: 273104 URL: https://svnweb.freebsd.org/changeset/base/273104 Log: vt(4): Don't recalculate buffer size if we don't know screen size MF10: r273037 MFC: r272537 When the screen size is unknown, it's set to 0x0. We can't use that as the buffer size, otherwise, functions such as vtbuf_fill() will fail. This fixes a panic on RaspberryPi, where there's no vt(4) backend configured early in boot. PR: 193981 Tested by: danilo@ Approved by: re (marius) Changes: _U releng/10.1/ releng/10.1/sys/dev/vt/vt_core.c