[9fans] A shot in the dark

[9fans] A shot in the dark

[ron minnich]

OK, this is a long shot, but i'm running out of ideas.

Long, long ago, at a Usenix, I saw a talk by some adventurous
australians (are there any other kind?). It was concerning some neat
hardware designed for kernel monitoring.

They had done a very neat hack. Basically, they modified the C
compiler so that, on function entry and exit, the code would emit a
16-bit quantity to the parallel port. They had some simple hardware to
grab the data.

WIth this, they were able to get some nice kernel performance numbers,
all for the (low at the time) cost of an outw to the parallel port.

OK, I have done some searching and can't find this. IIRC it was
pre-website usenix. I am going to UCB this week and may have time to
hunt it down in the paper archives, but ... just wondering ... anyone
else remember this?

thanks

ron

Re: [9fans] A shot in the dark

[Pietro Gagliardi]

No, I wasn't around that time :-) But I was looking for the Hello
World X11 paper a while back, which was pre-website USENIX. But on the
USENIX website it seems that you can purchase papers from before
1991(?). Perhaps they had a paper?

On May 27, 2008, at 6:02 PM, ron minnich wrote:

> OK, this is a long shot, but i'm running out of ideas.
>
> Long, long ago, at a Usenix, I saw a talk by some adventurous
> australians (are there any other kind?). It was concerning some neat
> hardware designed for kernel monitoring.
>
> They had done a very neat hack. Basically, they modified the C
> compiler so that, on function entry and exit, the code would emit a
> 16-bit quantity to the parallel port. They had some simple hardware to
> grab the data.
>
> WIth this, they were able to get some nice kernel performance numbers,
> all for the (low at the time) cost of an outw to the parallel port.
>
> OK, I have done some searching and can't find this. IIRC it was
> pre-website usenix. I am going to UCB this week and may have time to
> hunt it down in the paper archives, but ... just wondering ... anyone
> else remember this?
>
> thanks
>
> ron
>

Re: [9fans] A shot in the dark

[ron minnich]

On Tue, May 27, 2008 at 3:54 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> No, I wasn't around that time :-) But I was looking for the Hello World X11
> paper a while back, which was pre-website USENIX. But on the USENIX website
> it seems that you can purchase papers from before 1991(?). Perhaps they had
> a paper?


They had a paper, I just don't have the proceedings any more, I was
hoping someone else remembered it.

ron

Re: [9fans] A shot in the dark

[Digby Tarvin]

Don't know where to find that paper, but it reminds of a friend
at UNSW (in Sydney) that used to instrument the OS9 kernel by setting
and clearing bits in the parallel port.

The monitoring hardware was indeed simple - an analogue voltmeter
connected to the bit of interest to produce a simple but effective
short term average.

For example, a bit that is cleared when in the system idle loop
produced a 'tacho' style analogue load meter.

That must have been in the early 80's, but I still find the parallel
interface a good method of getting real-time diagnostics, or front
panel style indicators for statuses such as system/user mode.
Consequently I don't welcome the current trend toward optimising
them out of new hardware. USB parallel interfaces may be ok for
driving printers, but they are no substitute if you want a very low
overhead, low latency i/o mechanism.

Regards,
DigbyT

On Tue, May 27, 2008 at 06:54:58PM -0400, Pietro Gagliardi wrote:
> No, I wasn't around that time :-) But I was looking for the Hello
> World X11 paper a while back, which was pre-website USENIX. But on the
> USENIX website it seems that you can purchase papers from before
> 1991(?). Perhaps they had a paper?
>
> On May 27, 2008, at 6:02 PM, ron minnich wrote:
>
> >OK, this is a long shot, but i'm running out of ideas.
> >
> >Long, long ago, at a Usenix, I saw a talk by some adventurous
> >australians (are there any other kind?). It was concerning some neat
> >hardware designed for kernel monitoring.
> >
> >They had done a very neat hack. Basically, they modified the C
> >compiler so that, on function entry and exit, the code would emit a
> >16-bit quantity to the parallel port. They had some simple hardware to
> >grab the data.
> >
> >WIth this, they were able to get some nice kernel performance numbers,
> >all for the (low at the time) cost of an outw to the parallel port.
> >
> >OK, I have done some searching and can't find this. IIRC it was
> >pre-website usenix. I am going to UCB this week and may have time to
> >hunt it down in the paper archives, but ... just wondering ... anyone
> >else remember this?
> >
> >thanks
> >
> >ron
> >
>

--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

Re: [9fans] A shot in the dark

[Bakul Shah]

On Tue, 27 May 2008 15:02:15 PDT "ron minnich" <rminnich@gmail.com>  wrote:
> OK, this is a long shot, but i'm running out of ideas.
>
> Long, long ago, at a Usenix, I saw a talk by some adventurous
> australians (are there any other kind?). It was concerning some neat
> hardware designed for kernel monitoring.
>
> They had done a very neat hack. Basically, they modified the C
> compiler so that, on function entry and exit, the code would emit a
> 16-bit quantity to the parallel port. They had some simple hardware to
> grab the data.
>
> WIth this, they were able to get some nice kernel performance numbers,
> all for the (low at the time) cost of an outw to the parallel port.
>
> OK, I have done some searching and can't find this. IIRC it was
> pre-website usenix. I am going to UCB this week and may have time to
> hunt it down in the paper archives, but ... just wondering ... anyone
> else remember this?

Not quite the same but perhaps you are thinking of "Hardware
Profiling  of Kernels" by Andrew McRae in Winter 1993 usenix.
>From his paper:

    Three basic building blocks are used in the proling system
    proposed; the first is a hardware device that is used to
    record time and event data into a RAM block. The second is a
    modified C compiler that allows event triggering code to be
    inserted into key locations, and finally the last building
    block is analysis software that is used to decode the
    backtrace of events and relate it to the source code.

http://mcrae.homeunix.net/papers/final_usenix.pdf

He plugs his simple h/w in an Eprom socket and captures upto
16K events. Each event has a 16 bit tag and 24 bit us clock
value (so events can be upto 16 seconds apart).  Makes more
sense as access to a parallel port would be much slower.  For
today's processors, this would be far too slow.

Re: [9fans] A shot in the dark

[ron minnich]

On Tue, May 27, 2008 at 5:16 PM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:

> Not quite the same but perhaps you are thinking of "Hardware
> Profiling  of Kernels" by Andrew McRae in Winter 1993 usenix.
> From his paper:

it's good enough, and my memory probably is bad enough that this is
the right one.

Thanks!

ron

Re: [9fans] A shot in the dark

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FWIW, we used a similar technique just last summer debugging some PS3
code.  The dev system is kind enough to include 4 front panel lights
and a very lightweight API for setting them.  We wound up "printing"
out the program counter during a deadlock by mashing too many calls
to set the lights into the suspect areas.

I miss hardware debuggers.

Paul

On May 27, 2008, at 5:06 PM, Digby Tarvin wrote:

> Don't know where to find that paper, but it reminds of a friend
> at UNSW (in Sydney) that used to instrument the OS9 kernel by setting
> and clearing bits in the parallel port.
>
> The monitoring hardware was indeed simple - an analogue voltmeter
> connected to the bit of interest to produce a simple but effective
> short term average.
>
> For example, a bit that is cleared when in the system idle loop
> produced a 'tacho' style analogue load meter.
>
> That must have been in the early 80's, but I still find the parallel
> interface a good method of getting real-time diagnostics, or front
> panel style indicators for statuses such as system/user mode.
> Consequently I don't welcome the current trend toward optimising
> them out of new hardware. USB parallel interfaces may be ok for
> driving printers, but they are no substitute if you want a very low
> overhead, low latency i/o mechanism.
>
> Regards,
> DigbyT
>
> On Tue, May 27, 2008 at 06:54:58PM -0400, Pietro Gagliardi wrote:
>> No, I wasn't around that time :-) But I was looking for the Hello
>> World X11 paper a while back, which was pre-website USENIX. But on
>> the
>> USENIX website it seems that you can purchase papers from before
>> 1991(?). Perhaps they had a paper?
>>
>> On May 27, 2008, at 6:02 PM, ron minnich wrote:
>>
>>> OK, this is a long shot, but i'm running out of ideas.
>>>
>>> Long, long ago, at a Usenix, I saw a talk by some adventurous
>>> australians (are there any other kind?). It was concerning some neat
>>> hardware designed for kernel monitoring.
>>>
>>> They had done a very neat hack. Basically, they modified the C
>>> compiler so that, on function entry and exit, the code would emit a
>>> 16-bit quantity to the parallel port. They had some simple
>>> hardware to
>>> grab the data.
>>>
>>> WIth this, they were able to get some nice kernel performance
>>> numbers,
>>> all for the (low at the time) cost of an outw to the parallel port.
>>>
>>> OK, I have done some searching and can't find this. IIRC it was
>>> pre-website usenix. I am going to UCB this week and may have time to
>>> hunt it down in the paper archives, but ... just wondering ...
>>> anyone
>>> else remember this?
>>>
>>> thanks
>>>
>>> ron
>>>
>>
>
> --
> Digby R. S. Tarvin                                          digbyt
> (at)digbyt.com
> http://www.digbyt.com
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFIPMllpJeHo/Fbu1wRAtBGAJ49Ngab2WyOW+bYQ0wiUmJrqBKyeACfYhhn
A9b4diGkwg2fiiLyjXVWIGY=
=3r1V
-----END PGP SIGNATURE-----

Re: [9fans] A shot in the dark

[Bruce Ellis]

I went to that fest, it was an early AUUGM.

I think it was the BFI interface team at UNSW.

I'll check the c-side library (I keep everythng).

brucee

On 5/28/08, ron minnich <rminnich@gmail.com> wrote:
> On Tue, May 27, 2008 at 5:16 PM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
>
> > Not quite the same but perhaps you are thinking of "Hardware
> > Profiling  of Kernels" by Andrew McRae in Winter 1993 usenix.
> > From his paper:
>
> it's good enough, and my memory probably is bad enough that this is
> the right one.
>
> Thanks!
>
> ron
>
>

Re: [9fans] A shot in the dark

[Bruce Ellis]

When I did the port to the PS2 there wasn't even a light to blink. To
get thru l.s I discovered a register I could write that resets the
video.

Only a hundred lines (most innocent) to binary chop.

Ken has a better tale of a device that only had a speaker and
debugging by tones.

brucee

On 5/28/08, Paul Lalonde <plalonde@telus.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> FWIW, we used a similar technique just last summer debugging some PS3

Re: [9fans] A shot in the dark

[Digby Tarvin]

Way back in the dim distant pre-IBMPC days of Z80 PCs, my favourite
debugging technique was to use the screen memory.

My original Exidy Sorcerer had 1920 bytes of character oriented
screen memory (this was when 8K was a respectable amount of main
memory). Each byte displayed a 8x8 character defined by 8
bytes of the character generator memory, to top half of which
(the non-ascii characters) was writeable memory.

Not only could diagnostics be written to the display with a single
assembly language instruction, but it was even possible to just
run the entire program on the screen, which was entertaining as
well as often quite informative. I had no assembler, so with
hand assembly 1920 bytes seemed like quite a large piece of code.

Running the firmware monitor memory test routines on the screen
ram was also an endless source of entertainment.

I have recently been tinkering with using the memory on PC text
mode VGA adapters to provide a realtime visual display of what is
going on inside the Linux kernel, but it seems to be one of the less
well documented areas of the software and hardware, so there has been a
lot of trial and error and reverse engineering involved..

If anyone knows of any good resources please let me know...

Regards,
DigbyT

On Wed, May 28, 2008 at 05:31:27PM +1000, Bruce Ellis wrote:
> When I did the port to the PS2 there wasn't even a light to blink. To
> get thru l.s I discovered a register I could write that resets the
> video.
>
> Only a hundred lines (most innocent) to binary chop.
>
> Ken has a better tale of a device that only had a speaker and
> debugging by tones.
>
> brucee
>
> On 5/28/08, Paul Lalonde <plalonde@telus.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > FWIW, we used a similar technique just last summer debugging some PS3

--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

Re: [9fans] A shot in the dark

[Digby Tarvin]

That brings back memories. I think it was Dave Milway who gave
a talk on the BFI at UNSW, where he revealed during question
time at the end that 'BFI' stood for 'Beut Fast Interface'.

Regards,
DigbyT

On Wed, May 28, 2008 at 05:17:07PM +1000, Bruce Ellis wrote:
> I went to that fest, it was an early AUUGM.
>
> I think it was the BFI interface team at UNSW.
>
> I'll check the c-side library (I keep everythng).
>
> brucee
>
> On 5/28/08, ron minnich <rminnich@gmail.com> wrote:
> > On Tue, May 27, 2008 at 5:16 PM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
> >
> > > Not quite the same but perhaps you are thinking of "Hardware
> > > Profiling  of Kernels" by Andrew McRae in Winter 1993 usenix.
> > > From his paper:
> >
> > it's good enough, and my memory probably is bad enough that this is
> > the right one.
> >
> > Thanks!
> >
> > ron
> >
> >

--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

[9fans] OT: supporting multiple VGA cards (was "A shot in the dark")

[Digby Tarvin]

On the subject of diagnostic tools (this is not specifically a Plan9
issue, but someone on this list might know...):

I am interested in connecting more than one graphics adapter so that
one can be dedicated to low level diagnostics (rather than the more
usual dual head user interface).. but I am not sure how the hardware
deals with that given that the VGA standard seems to imply that all
the cards would be using identical memory addresses and IO ports.
Otherwise I would expect PCI to be able to automatically
map resources to non-conflicting addresses/IO ports.

In any case my BIOS has a setting which allows selection between AGP and
PCI as 'primary' Video, suggesting that it is indeed possible to have at
least one of each.

The only thing I can think of is that perhaps the VGA/CGA/EGA etc modes
are suppressed in the non-primary card, leaving only the more advanced
and less standard mode available. But this would be less ideal, as text
mode would be more useful for low overhead diagnostics.

Does anyone know what actually happens?

Regards,
DigbyT

On Wed, May 28, 2008 at 05:31:27PM +1000, Bruce Ellis wrote:
> When I did the port to the PS2 there wasn't even a light to blink. To
> get thru l.s I discovered a register I could write that resets the
> video.
>
> Only a hundred lines (most innocent) to binary chop.
>
> Ken has a better tale of a device that only had a speaker and
> debugging by tones.
>
> brucee
>
> On 5/28/08, Paul Lalonde <plalonde@telus.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > FWIW, we used a similar technique just last summer debugging some PS3

--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

Re: [9fans] OT: supporting multiple VGA cards (was "A shot in the dark")

[ron minnich]

On Wed, May 28, 2008 at 11:34 AM, Digby Tarvin <digbyt@acm.org> wrote:
>
> I am interested in connecting more than one graphics adapter so that
> one can be dedicated to low level diagnostics (rather than the more
> usual dual head user interface).. but I am not sure how the hardware
> deals with that given that the VGA standard seems to imply that all
> the cards would be using identical memory addresses and IO ports.

There are Rules such that only one terminal gets to own the "legacy" ports.

> Otherwise I would expect PCI to be able to automatically
> map resources to non-conflicting addresses/IO ports.

They do. It's just the legacy stuff that gets weird.

>
> In any case my BIOS has a setting which allows selection between AGP and
> PCI as 'primary' Video, suggesting that it is indeed possible to have at
> least one of each.

it is.

>
> The only thing I can think of is that perhaps the VGA/CGA/EGA etc modes
> are suppressed in the non-primary card, leaving only the more advanced
> and less standard mode available. But this would be less ideal, as text
> mode would be more useful for low overhead diagnostics.

if you can convince the OS to use the non-legacy addresses, you could
configure BIOS to put your desired debug terminal at legacy addresses
and use it for debug.

ron