On 04/01/2016 08:36 AM, Adrien Destugues wrote:
A tedious, but working strategy to find the exact location of the
triple fault is to bisect the code by adding an infinite loop.
I wanted to try this, but the KDiskDeviceManager is run twice (first
for the boot archive, then for the root filesystem), so I will need
something a bit more complex than just an infinite loop (I guess I
can add a static variable to count how many times the function has
been executed already).
do we have a way to send the logs on UDP broadcast or some other
thing over the network?
Unfortunately not (yet). Having an alternative to serial debugging
would be very useful, though.
I tried to implement this in a form similar to
http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/debugger/bochs
(replacing the out to a fixed port with writing to an UDP socket, of
course). I added my module to the boot archive and added a symlink in
boot/, but as far as I can tell the module init was never called
before my reboot problem. Is there another place where I should plug
for this to work, or a way to force loading the module early? Do I
need to make my module depend on the network stack (since it uses
sockets) and how do I accomplish that? Is it safe to just try
creating a socket (and retry each time debug_puts is called, until it
succeeds)?
Or any other way I could get the logs?
There's the debug syslog feature. It doesn't always work on all
computers. If it doesn't for you, you could try a different
(greater?) base address [1].
This works on my machine, but I'm not sure the very last logged
messages are always available after reboot. Sometimes the log was
ending earlier than what I saw with on-screen debug paging. I'm not
sure why this would happen.
