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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > > > > > > > > > > On Thu, Aug 29, 2024 at 09:01:17AM -0600, Simon Glass wrote: > > > > > > > Hi Neil, > > > > > > > > > > > > > > On Thu, 29 Aug 2024 at 08:26, <[email protected]> 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
signature.asc
Description: PGP signature
