Re: Ways to report trace when boot panics [Was NetBSD 7.0 i386 panic during boot]

[Robert Elz <kre%munnari.OZ.AU@localhost>]

First, I know I was a little overboard on the "RS232 is dead" theme, there
are still uses for it, and it remains useful for its purpose.

However, the time when *everything* had rs232 available has passed now,
and it was that which made it attractive as an alternative console
(boosted by many older systems having no other console than an rs232 interface)

It seems to me that we need something now to replace it (or to act as
an alternative - rs232 consoles will still exist for systems that require
or even just permit them of course) - something that can be depended upon
existing (almost) everywhere (that is relevant anyway).  To me, USB seemed
to be the obvious candidate, as USB ports exist on just about everything now,
as RS232 did in the past.

But ...

Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> said:
 | You don't need "just" a cable, but one with quite a bit logic in between.
 | USB is not designed for host-to-host communication,

Thanks - that's the kind of info I was lacking, given I know nothing about
USB...   I had naively assumed that something which calls itself a
universal serial bus would actually have some of the characteristics that
would justify such a name.

I was kind of anticipating there might be issues with USB power, but I
had a vague understanding that it might be possible to control that.

Michael van Elst <mlelstv%serpens.de@localhost> said:
 | There are such "cables",

That would kind of defeat the purpose, of allowing a connection
to be made, simply, without needing anything particularly special.
But I guess something like that might be better than nothing.

 | Then you have USB OTG   [...]  Often used in ARM systems   [...]
 | We don't support OTG.

Also might be useful I guess, perhaps allowing one of those small systems
to act as a console for any other system being debugged, but again, not
really very general.   Lack of support (currently) isn't necessarily a problem,
none of this currently has any support - any of it would require lots of
code to be written.

Mayuresh  <mayuresh%acm.org@localhost> said:
 | Even nicer if such device could be a smartphone,

That's looking like perhaps a better choice - phones are already "devices"
rather than hosts aren't they?  And they are almost as common as USB, so
requiring that would not be overly limiting.   Of course, I have no idea
whether it is possible on those systems to get low level enough access to
implement something like this.

Michael van Elst <mlelstv%serpens.de@localhost> said:
 | On the other side, USB as a low-level console is pretty limited. It requires
 | a complex software stack to work. 

That isn't necessarily a problem.   It sounds impossible, but with enough
restrictions on what needs to actually function, it might be achieved without
too much hassle.

Long long ago I did an implementation of config code (more or less a console)
for a device that had nothing but ethernet.   For that (and to avoid the
issue that would arise here, of needing specialised client code) I used telnet
over TCP.   Sounds like a complex software stack, but wasn't really.   The
TCP and telnet implementations were (I believe) fully standards compliant,
but were extremely limited. The Telnet would refuse all option negotiation
for example, and refuse to operate any way but how it wanted (legal, but not
generally useful).  The TCP IP and ethernet were all polled, lockstep
implementations (I send, you reply, one packet at a time).   That achieved
by simply setting the window size for receive very low - whatever size packets
the other end transmitted, became the window size...   Not useful in general,
and definitely not efficient in any sense, but worked just fine for the
purpose (only a single connection at a time of course.)   The whole
implementation turned out to be surprisingly small.

Whether any of that kind of thing would be useful for a USB implementation
I don't know.

I do think we need to be looking for something better than "photo of the
screen" for debugging very early problems - especially as that's a one way
transfer, no way to enter "bt" or "p/x 0xffff00000eeee0" or something from
a camera.    I am convinced that RS232 is no longer suitable, I was
hoping USB might be used as a replacement, but if not that, anyone have any
ideas on an alternative (a few years ago I might have suggested ethernet,
but wired ports are no longer endemic, and wireless does look to be too
complex for this kind of purpose.)

kre