#8663 closed enhancement (invalid)
Allow boot loader debug menu to write the trace buffer to USB if available
Reported by: | anevilyak | Owned by: | bonefish |
---|---|---|---|
Priority: | low | Milestone: | R1 |
Component: | System/Boot Loader | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
If tracing is enabled, it would be nice if the boot loader could find and attach to the kernel trace buffer in order to capture that to USB rather than the syslog, since that one potentially has much more detailed and not truncated information. Don't know how feasible this is due to the potential size and such.
Change History (2)
comment:1 by , 12 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 12 years ago
That's unfortunate. The reason I actually was wondering about that feature was because my new system lacks a serial header so I can no longer copy data from kernel debugging sessions to tickets that way. Thanks for the clarification in any event.
Note:
See TracTickets
for help on using tickets.
There's a feature that the kernel tracing reattaches to the tracing buffer of the previous session http://cgit.haiku-os.org/haiku/tree/src/system/kernel/debug/tracing.cpp#n406. In theory that should work -- Michael and I improved it a bit at last year's BeGeistert -- but I wouldn't rule out that it still has problems or doesn't work at all for you. If it works for you, you should be able to enter KDL after rebooting and work with the tracing buffer as usual, including things ending up in the syslog after leaving KDL (the kernel's syslog buffer has a limited size, so don't print too much at a time, if you want it in the syslog). Trace entries from a kernel module can be problematic, if the module isn't loaded at the same address as before.
In the boot loader the tracing buffer is utterly useless, since it doesn't contain data that can be used directly. It's all object data of
TraceEntry
subclasses that need to be printed by the respective class'sDump()
method. While writing a program to interpret the data is theoretically possible, it's so much work that I wouldn't bother, particularly if the buffer reattachment feature works.