System tap use case

System tap use case

[Phil Muldoon]

Here's a use case that I had several years back when I worked in GES.

"We had a board we ported the Linux kernel and supporting libraries to.
The processor did not have an MMU. During the debugging phase we found
that if you subjected the  board to a ping flood, it would lock up and
require a complete power off/power on. The board was embedded in nature,
and was accessed via ssh.

As the crash only happened during a ping flood - not during a normal
ping - it was very difficult to debug the network stack in the kernel,
and in the actual network driver. 

The crashes happened at random intervals during the ping flood, and it
would never happen during a "normal" ping rate. ICMP with a higher
payload *seemed* to cause the crash more quickly, but that was purely
observational in nature."

How could system-tap help in this scenario?

Regards

Phil
-- 

Re: System tap use case

[Richard J Moore]

I don't think anyone answered this did they?

You have the extreme of extreme problems. Unless you can get data out of
your system you can't debug it deductively with any tools that are
contained within the system.

However if you can extract data, for example by triggering a crashdump from
an NMI interrupt then you're in with a chance. A few vital clues in the
dmsg buffer, whether from SystemTap instrumentation or from any other
source might just give you the temporal information you need to go with a
dump. If it doesn't then systemtap will at least allow you to easily add
additional or alternative instrumentation. You also have the choice of
dumping trace data into a relayfs channel so you can be somewhat
independent of the dmesg buffer size.


systemtap-owner@sourceware.org wrote on 21/03/2006 17:10:48:

> Here's a use case that I had several years back when I worked in GES.
>
> "We had a board we ported the Linux kernel and supporting libraries to.
> The processor did not have an MMU. During the debugging phase we found
> that if you subjected the  board to a ping flood, it would lock up and
> require a complete power off/power on. The board was embedded in nature,
> and was accessed via ssh.
>
> As the crash only happened during a ping flood - not during a normal
> ping - it was very difficult to debug the network stack in the kernel,
> and in the actual network driver.
>
> The crashes happened at random intervals during the ping flood, and it
> would never happen during a "normal" ping rate. ICMP with a higher
> payload *seemed* to cause the crash more quickly, but that was purely
> observational in nature."
>
> How could system-tap help in this scenario?
>
> Regards
>
> Phil
> --
>