svn commit: r294471 - head/sys/dev/usb/wlan

[Ravi Pokala]

-----Original Message-----


From: <owner-src-committers at freebsd.org> on behalf of Adrian Chadd <adrian.chadd at gmail.com>
Date: 2016-01-20, Wednesday at 16:02
To: Andriy Voskoboinyk <avos at freebsd.org>
Cc: "src-committers at freebsd.org" <src-committers at freebsd.org>, "svn-src-all at freebsd.org" <svn-src-all at freebsd.org>, "svn-src-head at freebsd.org" <svn-src-head at freebsd.org>
Subject: Re: svn commit: r294471 - head/sys/dev/usb/wlan

>Hi,
>
>So yeah, I think it's time we just bit the bullet and wrote a
>generic-ish debug/ktr framework for drivers to use so drivers and
>infrastructure doesn't keep spinning its own damned debugging stuff.
>
>(I know people keep saying "dtrace", but ...)
>
>Let's have a think about it.

One issue I have with DTrace (and KTR, though I'm even less familiar with it than I am with DTrace) is that you only get a stream of what's happening right now - there's no way to see *what just happened*. For example, I wrote an ATA command tracing infrastructure for Panasas which keeps the last several thousand commands in a trace buffer, and a tool that extracts the buffer and saves it to a file. We can then feed that file into various analysis tools, which can show us exactly what we sent to the drive, and exactly what the drive sent back to us. (The nice thing is, the buffer is also in the vmcore, so we can easily extract it after a panic, and it's identical to what you get from the live system, so the same analysis tools can be used in both instances.) This has come in very handy when we want to see, for example, what new and stupid thing a drive did that caused an error, slowdown or panic.

-Ravi (rpokala@)

>-a