[PATCH v5 17/20] test: Try to shut down the lab console gracefully

[Tom Rini]

On Thu, Sep 05, 2024 at 06:50:20PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 3 Sept 2024 at 12:48, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Sun, Sep 01, 2024 at 02:09:58PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 30 Aug 2024 at 08:26, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Thu, Aug 29, 2024 at 07:04:36PM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 29 Aug 2024 at 10:59, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Aug 29, 2024 at 09:01:17AM -0600, Simon Glass wrote:
> > > > > > > Hi Neil,
> > > > > > >
> > > > > > > On Thu, 29 Aug 2024 at 08:26, <neil.armstrong at linaro.org> wrote:
> > > > > > > >
> > > > > > > > On 29/08/2024 00:08, Simon Glass wrote:
> > > > > > > > > Send the Labgrid quit characters to ask it to exit gracefully. This
> > > > > > > > > typically allows it to power off the board being used.
> > > > > > > >
> > > > > > > > Sending those characters every time could collide with other CI systems,
> > > > > > > > I don't think it's a good idea.
> > > > > > >
> > > > > > > What systems are you thinking about and what sort of collision would occur?
> > > > > > >
> > > > > > > What do you suggest instead?
> > > > > >
> > > > > > Why do we need this at all? Did I miss where we send picocom the
> > > > > > disconnect nicely key-combination?
> > > > >
> > > > > When labgrid gets a signal, it exits. It doesn't continue its
> > > > > co-routines and execute the end strategy to power things off, etc. I
> > > > > suspect it could be made to do that, but I already have 62 Labgrid
> > > > > patches, so I thought this would be expedient...
> > > > >
> > > > > I can make this conditional on the new USE_LABGRID variable.
> > > >
> > > > It sounds to me like we need to make generic improvements to our hooks
> > > > then, if there's not a "now call poweroff" hook.
> > >
> > > The thing is, Labgrid has its own internal console, which allows me to
> > > see all the output from reset. If I use picocom or some other program
> > > then some of the output is gone by the time I connect, particularly
> > > when using USB download. Because of that, just killing Labgrid, which
> > > is what pytest does, is a pretty heavy hammer and leaves things in an
> > > unknown state. So I added this method to give it a software signal.
> >
> > OK, but we shouldn't care? You can have the console available to pytest
> > and a terminal at the same time, with labgrid. If you need to see before
> > pytest grabs it, have the terminal be the first console, not pytest?
> 
> I'm a bit lost at this point...'labgrid-client console' creates a
> console connection and it keeps running until killed, with that
> console connection connected between its stdin/stdout. Then pytest
> uses that.
> 
> There is only one console.
> 
> I care because missing output makes it impossible to see what went
> wrong, if something went wrong.

There's not one console, is what I'm saying. You can connect to the
console via a terminal while pytest is running from another terminal. So
if you have a problem and it's in that window where we're just starting
up, grab the console for you first and then let pytest go second.
 
> > This gets back again I think to your specific way of making use of
> > labgrid contrasting with just generally supporting labgrid with however
> > another physical lab has set it up. Does killing one connection really
> > reset all of them? Or was it just a conflict with your
> > auto-acquire/release?
> 
> Are you talking about the Labgrid exporter, perhaps? This patch is for
> the client and we have one client process running for each board we
> connect to. You can see that in the Labgrid version of the
> u-boot-test-console script which basically runs labgrid-client and
> let's it do the talking.

It's about the assumptions that are true for your lab (and possibly
others) that aren't true for my lab (and possibly others).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240906/a58c2253/attachment.sig>