<div dir="ltr"><div dir="ltr">Hello Andrea,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 16, 2020 at 4:28 PM Andrea Bastoni <<a href="mailto:bastoni@sprg.uniroma2.it">bastoni@sprg.uniroma2.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Joshua,<br>
<br>
On 16/05/2020 21:40, Joshua Bakita wrote:<br>
> Hello all,<br>
> <br>
> I've been implementing the EDF-SC scheduler (Hobbs, Tong, Anderson RTNS 2019) in<br>
> LITMUS^RT, and occasionally run into kernel panics that prevent pending I/O from<br>
> being flushed to the serial console. The system under test is in a QEMU VM, so<br>
> gdb can easily be attached and the lx-dmesg command can be used to get the<br>
> kernel log messages. However, this obviously doesn't include pending TRACE messages.<br>
> <br>
> Is anyone aware of a way to get at the pending TRACE message buffer from gdb? It<br>
> seems like you could read the trace buffer off the ftdev_minor struct easily<br>
> enough in gdb, but I can't figure out a way to get a handle to that without<br>
> trying to parse through the VFS state in gdb.<br>
<br>
I haven't looked into it in a while, but IIRC I just dumped the memory of the<br>
(possibly per CPU) trace buffers into a file and then read the log or parsed the<br>
binary data structure (depending on whether the trace was plain text or binary<br>
feather trace events).<br>
<br>
If you know the kernel VA of the log buffers (possibly per CPU) it shouldn't be<br>
hard to do, because it's constant across tasks, and you should have access to it<br>
when you crash.<br>
<br>
IIRC I used something like:<br>
<br>
dump binary memory trace.txt log_buffer.buf.kfifo->buffer<br>
log_buffer.buf.kfifo->buffer+log_buffer.buf.kfifo->size<br></blockquote><div><br></div><div>This works almost as written! The actual command works out to:</div><div> `dump binary memory trace.txt debug_buffer.buf debug_buffer.buf+(debug_buffer.kfifo.in-debug_buffer.kfifo.out)`.<br></div><div>Running that seems to work perfectly for dumping all the pending trace messages from the</div><div>global buffer to trace.txt.</div><div><br></div><div>Thank you so much for your help!</div><div>- Joshua</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Where the log_buffer symbol was the kernel VA where the ft was storing the data.<br>
<br>
Hope it helps,<br>
Andrea<br>
<br>
> <br>
> If anyone can help me figure this out, I'd be happy to contribute the result<br>
> back up to LITMUS^RT as a new helper script for gdb. I can also provide the core<br>
> dump if someone else would like to take a look at it.<br>
> <br>
> Best,<br>
> <br>
> Joshua Bakita<br>
> PhD Student - UNC Chapel Hill<br>
> <br>
> _______________________________________________<br>
> litmus-dev mailing list<br>
> <a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
> <a href="https://lists.litmus-rt.org/listinfo/litmus-dev" rel="noreferrer" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
> <br>
</blockquote></div></div>