| Message ID | 20230601140950.779453-1-brgl@bgdev.pl |
|---|---|
| State | New |
| Headers | show |
| Series | [libgpiod] tools: tests: replace egrep with grep -E | expand |
On Thu, Jun 01, 2023 at 04:09:50PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Since version 3.11 egrep emits the following warning to stderr on startup: > > egrep: warning: egrep is obsolescent; using grep -E > > This makes the tests fail (though that seems to depend on BATS version) > so replace egrep with grep -E as suggested. > That works for me, so I don't have any objections. Though FWIW, my global sim cleanup script looks like: find /sys/kernel/config/gpio-sim -type d -name hog -print0 2>/dev/null | xargs -0 -r rmdir find /sys/kernel/config/gpio-sim -type d -name "line*" -print0 2>/dev/null | xargs -0 -r rmdir find /sys/kernel/config/gpio-sim -type d -name "bank*" -print0 2>/dev/null | xargs -0 -r rmdir rmdir /sys/kernel/config/gpio-sim/* So no grep at all, just find and xargs. That is for all sims, but could easily be reduced to a particular sim, given the sim name. Setting live to 0 seems to be optional - deleting everything works fine for me. Cheers, Kent. > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > --- > tools/gpio-tools-test | 2 +- > tools/gpio-tools-test.bats | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/gpio-tools-test b/tools/gpio-tools-test > index 5b6c72e..ed39ed5 100755 > --- a/tools/gpio-tools-test > +++ b/tools/gpio-tools-test > @@ -37,7 +37,7 @@ check_prog() { > check_prog bats > check_prog modprobe > check_prog timeout > -check_prog egrep > +check_prog grep > > # Check if we're running a kernel at the required version or later > check_kernel $MIN_KERNEL_VERSION > diff --git a/tools/gpio-tools-test.bats b/tools/gpio-tools-test.bats > index adbce94..c83ca7d 100755 > --- a/tools/gpio-tools-test.bats > +++ b/tools/gpio-tools-test.bats > @@ -154,7 +154,7 @@ gpiosim_cleanup() { > ls $BANKPATH/line* > /dev/null 2>&1 > if [ "$?" = "0" ] > then > - for LINE in $(find $BANKPATH/ | egrep "line[0-9]+$") > + for LINE in $(find $BANKPATH/ | grep -E "line[0-9]+$") > do > test -e $LINE/hog && rmdir $LINE/hog > rmdir $LINE > -- > 2.39.2 >
On Thu, Jun 01, 2023 at 10:28:22PM +0800, Kent Gibson wrote: > On Thu, Jun 01, 2023 at 04:09:50PM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > Since version 3.11 egrep emits the following warning to stderr on startup: > > > > egrep: warning: egrep is obsolescent; using grep -E > > > > This makes the tests fail (though that seems to depend on BATS version) > > so replace egrep with grep -E as suggested. > > > > That works for me, so I don't have any objections. > > Though FWIW, my global sim cleanup script looks like: > > find /sys/kernel/config/gpio-sim -type d -name hog -print0 2>/dev/null | xargs -0 -r rmdir > find /sys/kernel/config/gpio-sim -type d -name "line*" -print0 2>/dev/null | xargs -0 -r rmdir > find /sys/kernel/config/gpio-sim -type d -name "bank*" -print0 2>/dev/null | xargs -0 -r rmdir > rmdir /sys/kernel/config/gpio-sim/* > > So no grep at all, just find and xargs. Maybe you can even use -exec... :-) But I don't remember if it forks for each entry (and I don't remember by heart what -r does for xargs, which usually adds as many parameters as possible to the command line of the calling tool). > That is for all sims, but could easily be reduced to a particular sim, > given the sim name. > > Setting live to 0 seems to be optional - deleting everything works fine > for me.
On Thu, Jun 01, 2023 at 07:58:29PM +0300, Andy Shevchenko wrote: > On Thu, Jun 01, 2023 at 10:28:22PM +0800, Kent Gibson wrote: > > On Thu, Jun 01, 2023 at 04:09:50PM +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > Since version 3.11 egrep emits the following warning to stderr on startup: > > > > > > egrep: warning: egrep is obsolescent; using grep -E > > > > > > This makes the tests fail (though that seems to depend on BATS version) > > > so replace egrep with grep -E as suggested. > > > > > > > That works for me, so I don't have any objections. > > > > Though FWIW, my global sim cleanup script looks like: > > > > find /sys/kernel/config/gpio-sim -type d -name hog -print0 2>/dev/null | xargs -0 -r rmdir > > find /sys/kernel/config/gpio-sim -type d -name "line*" -print0 2>/dev/null | xargs -0 -r rmdir > > find /sys/kernel/config/gpio-sim -type d -name "bank*" -print0 2>/dev/null | xargs -0 -r rmdir > > rmdir /sys/kernel/config/gpio-sim/* > > > > So no grep at all, just find and xargs. > > Maybe you can even use -exec... :-) > But I don't remember if it forks for each entry (and I don't remember by heart > what -r does for xargs, which usually adds as many parameters as possible to > the command line of the calling tool). > You can indeed. The basic form execs for each file, but the '+' form execs on the set, which is preferable in this case. And the redirect is a hangover from a different form I was using previously, so that isn't necessary either. So SIMDIR="/sys/kernel/config/gpio-sim/" find $SIMDIR -type d -name hog -exec rmdir '{}' '+' find $SIMDIR -type d -name "line*" -exec rmdir '{}' '+' find $SIMDIR -type d -name "bank*" -exec rmdir '{}' '+' rmdir $SIMDIR/* is working for me. On a related(??) note, I'm occasionally seeing Oopses when testing this - when creating a basic sim with a shell script, not when deleting it. In one case after a fresh reboot and on creating the first sim, so it looks to be purely the construction. Yay :-(. Not sure if this is in anyway related to the other weirdness I've been experiencing lately. Wouldn't surprise me. The aforementioned Oops: Jun 2 09:49:58 firefly kernel: [ 612.194725] gpio-522 (hogster): hogged as input Jun 2 09:49:58 firefly kernel: [ 612.194729] gpio-528 (breath): hogged as output/low Jun 2 09:49:58 firefly kernel: [ 612.213120] BUG: kernel NULL pointer dereference, address: 0000000000000080 Jun 2 09:49:58 firefly kernel: [ 612.213436] #PF: supervisor read access in kernel mode Jun 2 09:49:58 firefly kernel: [ 612.213668] #PF: error_code(0x0000) - not-present page Jun 2 09:49:58 firefly kernel: [ 612.213899] PGD 800000015b18b067 P4D 800000015b18b067 PUD 102095067 PMD 0 Jun 2 09:49:58 firefly kernel: [ 612.214193] Oops: 0000 [#1] PREEMPT SMP PTI Jun 2 09:49:58 firefly kernel: [ 612.214391] CPU: 3 PID: 25493 Comm: cc1 Not tainted 6.4.0-rc3 #22 Jun 2 09:49:58 firefly kernel: [ 612.214657] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Jun 2 09:49:58 firefly kernel: [ 612.215049] RIP: 0010:anon_vma_interval_tree_insert+0xd/0xc0 Jun 2 09:49:58 firefly kernel: [ 612.215371] Code: 48 8d 70 c0 eb b5 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 8b 17 49 89 f8 49 89 f2 4d 8d 58 20 <48> 8b ba 80 00 00 00 48 8b 42 08 48 2b 02 48 c1 e8 0c 48 8d 74 07 Jun 2 09:49:58 firefly kernel: [ 612.216127] RSP: 0018:ffff92138079fcc8 EFLAGS: 00010202 Jun 2 09:49:58 firefly kernel: [ 612.216391] RAX: ffff8fb784053bc8 RBX: ffff92138079fd00 RCX: 000000008010000c Jun 2 09:49:58 firefly kernel: [ 612.216692] RDX: 0000000000000000 RSI: ffff8fb784053c18 RDI: ffff8fb747e7d400 Jun 2 09:49:58 firefly kernel: [ 612.216991] RBP: ffff8fb747e7d400 R08: ffff8fb747e7d400 R09: ffffffffa9624c00 Jun 2 09:49:58 firefly kernel: [ 612.217289] R10: ffff8fb784053c18 R11: ffff8fb747e7d420 R12: ffff8fb743699c80 Jun 2 09:49:58 firefly kernel: [ 612.217589] R13: ffff8fb77fd19f78 R14: 00007fd1a0a99000 R15: 00000007fd1a0a93 Jun 2 09:49:58 firefly kernel: [ 612.217891] FS: 00007fd1a0d81ac0(0000) GS:ffff8fb7d9d80000(0000) knlGS:0000000000000000 Jun 2 09:49:58 firefly kernel: [ 612.218224] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 2 09:49:58 firefly kernel: [ 612.218531] CR2: 0000000000000080 CR3: 000000013ff40000 CR4: 00000000000006e0 Jun 2 09:49:58 firefly kernel: [ 612.218883] Call Trace: Jun 2 09:49:58 firefly kernel: [ 612.219086] <TASK> Jun 2 09:49:58 firefly kernel: [ 612.219264] vma_complete+0xba/0x270 Jun 2 09:49:58 firefly kernel: [ 612.219496] vma_expand+0x116/0x190 Jun 2 09:49:58 firefly kernel: [ 612.219722] mmap_region+0x781/0x9d0 Jun 2 09:49:58 firefly kernel: [ 612.219974] ? arch_get_unmapped_area_topdown+0xf6/0x230 Jun 2 09:49:58 firefly kernel: [ 612.220274] do_mmap+0x3ad/0x5d0 Jun 2 09:49:58 firefly kernel: [ 612.220492] vm_mmap_pgoff+0xd8/0x180 Jun 2 09:49:58 firefly kernel: [ 612.220726] do_syscall_64+0x3b/0x90 Jun 2 09:49:58 firefly kernel: [ 612.220965] entry_SYSCALL_64_after_hwframe+0x72/0xdc Jun 2 09:49:58 firefly kernel: [ 612.221247] RIP: 0033:0x7fd1a0e790d2 Jun 2 09:49:58 firefly kernel: [ 612.221477] Code: e4 e8 62 64 01 00 66 90 41 f7 c1 ff 0f 00 00 75 27 55 48 89 fd 53 89 cb 48 85 ff 74 3b 41 89 da 48 89 ef b8 09 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 66 5b 5d c3 0f 1f 00 48 8b 05 89 8d 0d 00 64 Jun 2 09:49:58 firefly kernel: [ 612.222340] RSP: 002b:00007fff20f0a398 EFLAGS: 00000246 ORIG_RAX: 0000000000000009 Jun 2 09:49:58 firefly kernel: [ 612.222759] RAX: ffffffffffffffda RBX: 0000000000000022 RCX: 00007fd1a0e790d2 Jun 2 09:49:58 firefly kernel: [ 612.223111] RDX: 0000000000000003 RSI: 0000000000002000 RDI: 0000000000000000 Jun 2 09:49:58 firefly kernel: [ 612.223463] RBP: 0000000000000000 R08: 00000000ffffffff R09: 0000000000000000 Jun 2 09:49:58 firefly kernel: [ 612.223817] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000002000 Jun 2 09:49:58 firefly kernel: [ 612.224195] R13: 0000000000000000 R14: 0000000000002000 R15: 000000000000000d Jun 2 09:49:58 firefly kernel: [ 612.224550] </TASK> Jun 2 09:49:58 firefly kernel: [ 612.224728] Modules linked in: gpio_sim configfs Jun 2 09:49:58 firefly kernel: [ 612.224994] CR2: 0000000000000080 Jun 2 09:49:58 firefly kernel: [ 612.225713] ---[ end trace 0000000000000000 ]--- Jun 2 09:49:58 firefly kernel: [ 612.226407] RIP: 0010:anon_vma_interval_tree_insert+0xd/0xc0 Jun 2 09:49:58 firefly kernel: [ 612.226912] Code: 48 8d 70 c0 eb b5 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 8b 17 49 89 f8 49 89 f2 4d 8d 58 20 <48> 8b ba 80 00 00 00 48 8b 42 08 48 2b 02 48 c1 e8 0c 48 8d 74 07 Jun 2 09:49:58 firefly kernel: [ 612.228179] RSP: 0018:ffff92138079fcc8 EFLAGS: 00010202 Jun 2 09:49:58 firefly kernel: [ 612.228464] RAX: ffff8fb784053bc8 RBX: ffff92138079fd00 RCX: 000000008010000c Jun 2 09:49:58 firefly kernel: [ 612.228815] RDX: 0000000000000000 RSI: ffff8fb784053c18 RDI: ffff8fb747e7d400 Jun 2 09:49:58 firefly kernel: [ 612.229199] RBP: ffff8fb747e7d400 R08: ffff8fb747e7d400 R09: ffffffffa9624c00 Jun 2 09:49:58 firefly kernel: [ 612.229555] R10: ffff8fb784053c18 R11: ffff8fb747e7d420 R12: ffff8fb743699c80 Jun 2 09:49:58 firefly kernel: [ 612.229917] R13: ffff8fb77fd19f78 R14: 00007fd1a0a99000 R15: 00000007fd1a0a93 Jun 2 09:49:58 firefly kernel: [ 612.230285] FS: 00007fd1a0d81ac0(0000) GS:ffff8fb7d9d80000(0000) knlGS:0000000000000000 Jun 2 09:49:58 firefly kernel: [ 612.230733] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 2 09:49:58 firefly kernel: [ 612.231040] CR2: 0000000000000080 CR3: 000000013ff40000 CR4: 00000000000006e0 Not sure where to go with that. Will take another look at it later unless someone can see something obvious that I'm missing. Cheers, Kent.
On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote: > > On a related(??) note, I'm occasionally seeing Oopses when testing this > - when creating a basic sim with a shell script, not when deleting it. > In one case after a fresh reboot and on creating the first sim, so it > looks to be purely the construction. Yay :-(. > I had thought it would be difficult to reproduce this and so difficult to bisect. Fortunately(??) not. If I run my setup and cleanup scripts[1] in a tight loop it occurs very readily. Haven't bisected it yet, but did test it on 6.1-rc1 and it Oopsed there too, so I would need to go back further. What was the initial release containing gpio-sim? The sim setp is pretty simple - a couple of banks each with a few lines and hogs. Could you confirm that you can repeat the problem? Otherwise I might start thinking there is something broken in my test environment. Btw, the loop script is: #!/bin/env bash for (( ; ; )) do echo "create sim..." ./basic_sim.sh echo "destroy sim..." ./clean_sims.sh done Cheers, Kent. [1] https://github.com/warthog618/gpiosim-rs
On Fri, Jun 2, 2023 at 12:34 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote: > > > > On a related(??) note, I'm occasionally seeing Oopses when testing this > > - when creating a basic sim with a shell script, not when deleting it. > > In one case after a fresh reboot and on creating the first sim, so it > > looks to be purely the construction. Yay :-(. > > > > I had thought it would be difficult to reproduce this and so difficult > to bisect. Fortunately(??) not. If I run my setup and cleanup scripts[1] > in a tight loop it occurs very readily. Haven't bisected it yet, but did > test it on 6.1-rc1 and it Oopsed there too, so I would need to go back > further. What was the initial release containing gpio-sim? > > The sim setp is pretty simple - a couple of banks each with a few lines > and hogs. > > Could you confirm that you can repeat the problem? > Otherwise I might start thinking there is something broken in my test > environment. > > Btw, the loop script is: > > #!/bin/env bash > for (( ; ; )) > do > echo "create sim..." > ./basic_sim.sh > echo "destroy sim..." > ./clean_sims.sh > done > > Cheers, > Kent. > [1] https://github.com/warthog618/gpiosim-rs > With this script I've been able to trigger an issue but it looks different from yours: https://pastebin.com/cbsgT2ae Bart
On Fri, Jun 02, 2023 at 03:10:18PM +0200, Bartosz Golaszewski wrote: > On Fri, Jun 2, 2023 at 12:34 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote: > > > > > > On a related(??) note, I'm occasionally seeing Oopses when testing this > > > - when creating a basic sim with a shell script, not when deleting it. > > > In one case after a fresh reboot and on creating the first sim, so it > > > looks to be purely the construction. Yay :-(. > > > > > > > I had thought it would be difficult to reproduce this and so difficult > > to bisect. Fortunately(??) not. If I run my setup and cleanup scripts[1] > > in a tight loop it occurs very readily. Haven't bisected it yet, but did > > test it on 6.1-rc1 and it Oopsed there too, so I would need to go back > > further. What was the initial release containing gpio-sim? > > > > The sim setp is pretty simple - a couple of banks each with a few lines > > and hogs. > > > > Could you confirm that you can repeat the problem? > > Otherwise I might start thinking there is something broken in my test > > environment. > > > > Btw, the loop script is: > > > > #!/bin/env bash > > for (( ; ; )) > > do > > echo "create sim..." > > ./basic_sim.sh > > echo "destroy sim..." > > ./clean_sims.sh > > done > > > > Cheers, > > Kent. > > [1] https://github.com/warthog618/gpiosim-rs > > > > With this script I've been able to trigger an issue but it looks > different from yours: https://pastebin.com/cbsgT2ae > Looks similar to me. I would assume that is the same issue - even if the particulars of the crash differ. If you can fix that and my problem remains then we can be sure they are distinct. I've been doing a coarse bisect to see how far back this goes - basically looking for a known good. 5.18 crashes, but it crashed hard, so no syslog. It did run considerably longer before crashing, so that could be different issue masked by the other (later?) one. Moving on to subsequent releases... Cheers, Kent.
On Fri, Jun 2, 2023 at 3:26 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Fri, Jun 02, 2023 at 03:10:18PM +0200, Bartosz Golaszewski wrote: > > On Fri, Jun 2, 2023 at 12:34 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > > > On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote: > > > > > > > > On a related(??) note, I'm occasionally seeing Oopses when testing this > > > > - when creating a basic sim with a shell script, not when deleting it. > > > > In one case after a fresh reboot and on creating the first sim, so it > > > > looks to be purely the construction. Yay :-(. > > > > > > > > > > I had thought it would be difficult to reproduce this and so difficult > > > to bisect. Fortunately(??) not. If I run my setup and cleanup scripts[1] > > > in a tight loop it occurs very readily. Haven't bisected it yet, but did > > > test it on 6.1-rc1 and it Oopsed there too, so I would need to go back > > > further. What was the initial release containing gpio-sim? > > > > > > The sim setp is pretty simple - a couple of banks each with a few lines > > > and hogs. > > > > > > Could you confirm that you can repeat the problem? > > > Otherwise I might start thinking there is something broken in my test > > > environment. > > > > > > Btw, the loop script is: > > > > > > #!/bin/env bash > > > for (( ; ; )) > > > do > > > echo "create sim..." > > > ./basic_sim.sh > > > echo "destroy sim..." > > > ./clean_sims.sh > > > done > > > > > > Cheers, > > > Kent. > > > [1] https://github.com/warthog618/gpiosim-rs > > > > > > > With this script I've been able to trigger an issue but it looks > > different from yours: https://pastebin.com/cbsgT2ae > > > > Looks similar to me. > I would assume that is the same issue - even if the particulars of the > crash differ. If you can fix that and my problem remains then we can be > sure they are distinct. > > I've been doing a coarse bisect to see how far back this goes - > basically looking for a known good. > 5.18 crashes, but it crashed hard, so no syslog. It did run considerably > longer before crashing, so that could be different issue masked by the > other (later?) one. > > Moving on to subsequent releases... > > Cheers, > Kent. I managed to trigger a different crash: https://pastebin.com/6Gx29vHB This one happened in gpio-sim: $ ./scripts/faddr2line drivers/gpio/gpio-sim.o gpio_sim_make_bank_swnode+0x12f/0x220 gpio_sim_make_bank_swnode+0x12f/0x220: gpio_sim_make_line_names at /home/brgl/workspace/yocto-gpio-sim-crash/build/linux/drivers/gpio/gpio-sim.c:725 (inlined by) gpio_sim_make_bank_swnode at /home/brgl/workspace/yocto-gpio-sim-crash/build/linux/drivers/gpio/gpio-sim.c:837 But to me it looks like some memory corruption if the stack traces are so random... Where is Rust when you need it? :) Bart
On Fri, Jun 02, 2023 at 05:33:08PM +0200, Bartosz Golaszewski wrote: > On Fri, Jun 2, 2023 at 3:26 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > On Fri, Jun 02, 2023 at 03:10:18PM +0200, Bartosz Golaszewski wrote: > > > On Fri, Jun 2, 2023 at 12:34 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > > > > > On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote: > > > > > > > > > > On a related(??) note, I'm occasionally seeing Oopses when testing this > > > > > - when creating a basic sim with a shell script, not when deleting it. > > > > > In one case after a fresh reboot and on creating the first sim, so it > > > > > looks to be purely the construction. Yay :-(. > > > > > > > > > > > > > I had thought it would be difficult to reproduce this and so difficult > > > > to bisect. Fortunately(??) not. If I run my setup and cleanup scripts[1] > > > > in a tight loop it occurs very readily. Haven't bisected it yet, but did > > > > test it on 6.1-rc1 and it Oopsed there too, so I would need to go back > > > > further. What was the initial release containing gpio-sim? > > > > > > > > The sim setp is pretty simple - a couple of banks each with a few lines > > > > and hogs. > > > > > > > > Could you confirm that you can repeat the problem? > > > > Otherwise I might start thinking there is something broken in my test > > > > environment. > > > > > > > > Btw, the loop script is: > > > > > > > > #!/bin/env bash > > > > for (( ; ; )) > > > > do > > > > echo "create sim..." > > > > ./basic_sim.sh > > > > echo "destroy sim..." > > > > ./clean_sims.sh > > > > done > > > > > > > > Cheers, > > > > Kent. > > > > [1] https://github.com/warthog618/gpiosim-rs > > > > > > > > > > With this script I've been able to trigger an issue but it looks > > > different from yours: https://pastebin.com/cbsgT2ae > > > > > > > Looks similar to me. > > I would assume that is the same issue - even if the particulars of the > > crash differ. If you can fix that and my problem remains then we can be > > sure they are distinct. > > > > I've been doing a coarse bisect to see how far back this goes - > > basically looking for a known good. > > 5.18 crashes, but it crashed hard, so no syslog. It did run considerably > > longer before crashing, so that could be different issue masked by the > > other (later?) one. > > > > Moving on to subsequent releases... > > > > Cheers, > > Kent. > > I managed to trigger a different crash: https://pastebin.com/6Gx29vHB > > This one happened in gpio-sim: > > $ ./scripts/faddr2line drivers/gpio/gpio-sim.o > gpio_sim_make_bank_swnode+0x12f/0x220 > gpio_sim_make_bank_swnode+0x12f/0x220: > gpio_sim_make_line_names at > /home/brgl/workspace/yocto-gpio-sim-crash/build/linux/drivers/gpio/gpio-sim.c:725 > (inlined by) gpio_sim_make_bank_swnode at > /home/brgl/workspace/yocto-gpio-sim-crash/build/linux/drivers/gpio/gpio-sim.c:837 > > But to me it looks like some memory corruption if the stack traces are > so random... Where is Rust when you need it? :) > Makes sense. I'm seeing different behaviour from differnet releases, so there may be multiple issues here, and some may've been fixed or introduced at different points. Or, as you suggest, it could be a corruption that just exhibits differently depending on what ends up getting corrupted. Either way, bisecting this is problematic. e.g. 5.18 crashed hard after a while. 5.19 ran for quite a while - but then crashed when I killed the script. 6.0 behaved similar to 5.19. 6.1 looks to be where the current issue was introduced - that fails almost immediately. 6.2 crashed hard. 6.3 failed fast like 6.1. TBH, haven't been paying much attention to the crash details - for the most part the backtraces are a pretty generic syscall fell in a heap as a pointer somewhere was null. Not sure I'm being much help with this one. Anything specific you want me to try? Otherwise I'll leave you to it until you do. One other thing - is it necessary for gpio-sim to log hogs? Jun 2 23:45:13 firefly kernel: [ 39.539144] gpio-522 (hog2): hogged as input Jun 2 23:45:13 firefly kernel: [ 39.539152] gpio-528 (hog3): hogged as output/low Jun 2 23:45:13 firefly kernel: [ 39.600144] gpio-513 (hog1): hogged as output/high Jun 2 23:45:13 firefly kernel: [ 39.600365] gpio-522 (hog2): hogged as input Jun 2 23:45:13 firefly kernel: [ 39.600372] gpio-528 (hog3): hogged as output/low Jun 2 23:45:13 firefly kernel: [ 39.649662] gpio-513 (hog1): hogged as output/high Jun 2 23:45:13 firefly kernel: [ 39.650558] gpio-522 (hog2): hogged as input For the long running cases this results in a lot of logging, which could be causing issues in itself, and further muddying the waters. Cheers, Kent.
On Sat, Jun 03, 2023 at 12:07:40AM +0800, Kent Gibson wrote: > > One other thing - is it necessary for gpio-sim to log hogs? > > For the long running cases this results in a lot of logging, which could > be causing issues in itself, and further muddying the waters. > Ah, I've been looking at bisecting the problem the wrong way. I should've been bisecting the trigger condition. If I remove the hogs from the basic_sim then the test doesn't fail. It also explains why I haven't been seeing this more often - most of my tests don't include hogs. Only the info tests use hogs, the rest just use bare sims with no named lines or hogs (aka simpletons). Does that help isolate the root cause? Cheers, Kent.
diff --git a/tools/gpio-tools-test b/tools/gpio-tools-test index 5b6c72e..ed39ed5 100755 --- a/tools/gpio-tools-test +++ b/tools/gpio-tools-test @@ -37,7 +37,7 @@ check_prog() { check_prog bats check_prog modprobe check_prog timeout -check_prog egrep +check_prog grep # Check if we're running a kernel at the required version or later check_kernel $MIN_KERNEL_VERSION diff --git a/tools/gpio-tools-test.bats b/tools/gpio-tools-test.bats index adbce94..c83ca7d 100755 --- a/tools/gpio-tools-test.bats +++ b/tools/gpio-tools-test.bats @@ -154,7 +154,7 @@ gpiosim_cleanup() { ls $BANKPATH/line* > /dev/null 2>&1 if [ "$?" = "0" ] then - for LINE in $(find $BANKPATH/ | egrep "line[0-9]+$") + for LINE in $(find $BANKPATH/ | grep -E "line[0-9]+$") do test -e $LINE/hog && rmdir $LINE/hog rmdir $LINE