Florian, thanks a lot for suggestions I followed when I understood more 
clearly what to do....

Here is linux-6.15.1 kernel panic captured by netconsole remotely and 
decoded by stacktrace script.

I guess next step is bisecting between 6.14.11 (good) and 6.15.1 (bad).

Regards,

Bernard

Le 27/08/2025 à 19:30, Florian Westphal a écrit :

F6BVP [off-list ref] wrote:

quoted

Here I am. Next step is probably to discover why the call to
receive_buf() fails when bytes are not small and tty_ldisc_deref() is
acting after flush_to_ldisc probably leading to an error. What value is
wrong ? ld->tty , p, f ?

Did you enable CONFIG_KASAN?

Also, since you seem to be able to reproduce this easily, did you
try a 'git bisect' to identify the breaking change?

That would allow to CC the author of that change.

quoted

4,19346,153786988,-;Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020
4,19347,153786990,-;Workqueue: events_unbound flush_to_ldisc
4,19348,153786998,-;Here I am: tty_ldisc_deref:283 !tty
4,19349,153787003,-;Here I am: tty_ldisc_deref:283 !tty
4,19350,153787005,-;RIP: 0010:__netif_receive_skb_core.constprop.0+0xfe5/0x12d0
4,19398,153787265,-; __netif_receive_skb_one_core+0x3d/0xa0

as Eric noted, you need to pipe this through

scripts/decode_stacktrace.sh so this gets translated to line numbers.