On 8/9/18 4:02 AM, Konstantin Belousov wrote:
> On Thu, Aug 09, 2018 at 10:26:06AM +0100, Johannes Lundberg wrote:
>> On Thu, Aug 9, 2018 at 9:29 AM Konstantin Belousov <kostik...@gmail.com>
>> wrote:
>>> On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote:
>>>> Hi
>>>> So I believe the reason I'm not seeing and printf output in dmesg is that
>>>> it is too early in some functions.
>>>> For example
>>>> machdep.s
>>>>  getmemsize()
>>>>  add_efi_map_entries()
>>>>  etc
>>>> However, these functions do contain debug printf statements so if they're
>>>> logging to somewhere, where/how can I see this?
>>>> I also tried booting in bhyve too see if I could get any output via
>>> serial
>>>> console but nothing there either.
>>> Disable efi console, only leaving comconsole around, then set
>>> debug.late_console=0
>>> in loader.
>> Thanks for the tip. I found the comment in machdep.c that explains this
>> now.
>> However, running in bhyve with
>> console="comconsole" (not needed in bhyve I guess?)
>> debug.late_console=0
>> Boot hangs after
>> Booting...
>> output.
>> Caused by late_console=0.
> That early hangs are typically due to an exception occuring before
> IDT is set up and trap machinery operational.  Double-check that
> there is no any early framebuffer access, as a drastic measure remove
> all framebuffer drivers from your kernel config.
> I do not remember, where gdb stubs added to bhyve ?  Is there a way
> to inspect the vm guest state in bhyve by other means ?

For this case the gdb stub in FreeBSD head should be sufficient.  You need
to add '-G 1234' to the command line when starting bhyve and then you can
use 'target remote localhost:1234' from either gdb or kgdb.

John Baldwin
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to