On Mon, May 30, 2022 at 12:16 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>
> On Sat, 28 May 2022 at 21:28, Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> wrote:
> >
> > On Sat, May 28, 2022 at 3:14 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > >
> > > On Sat, May 28, 2022 at 3:01 PM Yegor Yefremov
> > > <yegorslists@xxxxxxxxxxxxxx> wrote:
> > > > On Sat, May 28, 2022 at 11:07 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > > > In file included from ./include/linux/irqflags.h:17,
> > > > from ./arch/arm/include/asm/bitops.h:28,
> > > > from ./include/linux/bitops.h:33,
> > > > from ./include/linux/log2.h:12,
> > > > from kernel/bounds.c:13:
> > > > ./arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’:
> > > > ./arch/arm/include/asm/percpu.h:32:9: error: ‘__per_cpu_offset’
> > > > undeclared (first use in this function); did you mean
> > > > ‘__my_cpu_offset’?
> > > > 32 | return __per_cpu_offset[0];
> > > > | ^~~~~~~~~~~~~~~~
> > > > | __my_cpu_offset
> > > > ./arch/arm/include/asm/percpu.h:32:9: note: each undeclared identifier
> > > > is reported only once for each function it appears in
> > >
> > > I think you just missed the line in my patch that adds the
> > > "extern unsigned long __per_cpu_offset[];" variable declaration.
> >
> > My bad.
> >
> > So, I tried both variants and both led to stalls.
> >
>
> Could you please try running slcand under strace (and use the -F
> option on slcand), and bring up the link from another terminal
> session? That way, we may be able to narrow down the cause of the
> stall from the strace output.
>
> On my BB white, it never gets past
>
> openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 3
> ioctl(3, TCGETS, {B3000000 -opost -isig -icanon -echo ...}) = 0
> ioctl(3, TIOCGSERIAL, 0xbec564fc) = 0
> ioctl(3, TIOCSSERIAL) = 0
> ioctl(3, TCGETS, {B3000000 -opost -isig -icanon -echo ...}) = 0
> ioctl(3, SNDCTL_TMR_STOP or TCSETSW, {B3000000 -opost -isig -icanon
> -echo ...}) = 0
> ioctl(3, TCGETS, {B3000000 -opost -isig -icanon -echo ...}) = 0
> write(3, "C\rS8\r", 5) = 5
> write(3, "O\r", 2) = 2
> ioctl(3, TIOCSETD, [17]
>
> but I don't have any actual CAN-to-USB-serial hardware so I'm not sure
> if I'm even able to reproduce this.
Triggering the stall is not that straight forward. slcand just loads
the slcan driver and creates an slcan0 network device. This alone
doesn't lead to a stall. First when I send some CAN frames, the system
stalls after some seconds.
My CAN test script can also work directly with /dev/ttyUSB0 omitting
the slcan driver. In this case, the system stays stable.
Yegor
