From: Per Oberg <pero@wolfram.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: xenomai@lists.linux.dev
Subject: Re: RTNet unable to handle kernel NULL pointer dereference at 0000000000000068
Date: Wed, 4 Oct 2023 09:15:00 -0500 (CDT) [thread overview]
Message-ID: <471929520.3420035.1696428900861.JavaMail.zimbra@wolfram.com> (raw)
In-Reply-To: <962e9533-26a2-4a02-a5c8-21791e86fdf3@siemens.com>
----- Den 4 okt 2023, på kl 15:57, Jan Kiszka jan.kiszka@siemens.com skrev:
> On 04.10.23 15:01, Per Oberg wrote:
> > I just had another hickup. This is 100 pct reproducible
>> To get it up and running I had to remove rtpacket,rttcp,rtudp,rtipv4 and then
>> forcibly remove rt_igb driver and then rtnet. This gave me another set of
> > errors, also listed below.
> What does "forcibly" mean here? Actually "rmmod --force"? Then you get
> what you deserve ;).
Yes, intentionally. I expected that the "rmmod --foce" would reek havok but I thought that perhaphs the actual havok caused could give more pointers to the actual problem.
I wanted to see if I could recover from the first crash (not the one from my first email) without rebooting.
> > [15018.436248] ------------[ cut here ]------------
>> [15018.436249] [Xenomai] switching rtnet-stack to secondary mode after exception
> > #6 in kernel-space at 0xffffffffb837064b (pid 1438)
>> [15018.436258] WARNING: CPU: 0 PID: 1438 at
> > /usr/src/kernel/kernel/xenomai/rtdm/fd.c:299 __put_fd+0x26b/0x2c0
> You are not using the latest release, not even of your stable series.
> This is needlessly risky.
I am currently updating the kernel and xenomai libraries to see what that can do. I could not, however, find any patches that looked relevant for the issue.
> There is some imbalance in the reference counter for the socket, and
> later on are complaints about leaking buffers in the pool. The real
> problem may rather be that you didn't shut down the interface properly -
> or that we don't do that when pulling the plugs in the order you describe.
To be clear, the
"[Xenomai] switching rtnet-stack to secondary mode after exception #6 in kernel-space at 0xffffffffb837064b (pid 1438)"
happens after a fresh reboot, not something I kept alive with artifial life support.
> Can you reproduce this rather generic issue over latest master as well?
I'm working on it. Hopefully not.
> Jan
> --
> Siemens AG, Technology
> Linux Expert Center
Per Öberg
next prev parent reply other threads:[~2023-10-04 14:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-04 8:45 RTNet unable to handle kernel NULL pointer dereference at 0000000000000068 Per Oberg
2023-10-04 9:42 ` Jan Kiszka
2023-10-04 13:01 ` Per Oberg
2023-10-04 13:57 ` Jan Kiszka
2023-10-04 14:15 ` Per Oberg [this message]
2023-10-05 14:19 ` Per Oberg
2023-10-05 14:21 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=471929520.3420035.1696428900861.JavaMail.zimbra@wolfram.com \
--to=pero@wolfram.com \
--cc=jan.kiszka@siemens.com \
--cc=xenomai@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.