Re: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up
On 09.07.19 18:33, Jan Kiszka wrote: > On 09.07.19 18:21, Lange Norbert wrote: >> Hello, >> >> maxcpus=1 still causes the spurious int, this time fully locking up. >> >> I attached the debug/irq directory after the cause. >>> Some things that might be relevant: >> - the SOC would use PINCTRL_BROXTON under linux, but this is disabled (not >> fixed up for Xenomai) >> - I have the regular igb driver in use, and am unbinding the network card >> prior to binding the rt_igp driver >> > > Thanks. What's the interrupt number that Xenomai is using? Should be the same > that the Linux driver is using as well. Found already: Should be IRQ 130-132 for device 00:03.0. If the directory state was like that while Xenomai was still holding those interrupts, the problem it that there are no vectors assigned to them. Can you confirm that rt_igb was still loaded and the interface was up? Are those interrupts MSI or MSI-X? Can't read that from the logs. I probably need to get some rt_igb running somewhere... Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
RE: ipipe 4.19: spurious APIC interrupt when setting rt_igp to up
> >>>
> >>> raw_spin_lock_irqsave(>lock, flags);
> >>> - if (desc->istate & IPIPE_IRQS_NEEDS_STARTUP) {
> >>> + if (desc->istate & IPIPE_IRQS_NEEDS_STARTUP &&
> >>> + !WARN_ON(irq_activate(desc))) {
> >>> desc->istate &= ~IPIPE_IRQS_NEEDS_STARTUP;
> >>> chip->irq_startup(>irq_data);
> >>> }
> >>
> >> Problem still persists for me with that patch. I use a nfsroot (with
> >> a
> >> USB->ETH adapter so I can kick out the linux igb driver),
> >> Maybe that’s related.
> >
> > Does reducing your machine to maxcpus=1 resolve the issue? I could
> > imagine we an affinity problem on top.
> >
>
> We do have an affinity problem, will try to fix it soon, but that didn't
> allow me
> to reproduce your issue with my patch applied.
>
> Could you turn on CONFIG_GENERIC_IRQ_DEBUGFS and grab the content of
> /sys/kernel/debug/irq? Maybe Linux considers the interrupt in question
> here as "affinity managed by kernel", and then my patch is nop. Still need to
> understand all implications of this managed mode for I-pipe.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
> Competence Center Embedded Linux
This message and any attachments are solely for the use of the intended
recipients. They may contain privileged and/or confidential information or
other information protected from disclosure. If you are not an intended
recipient, you are hereby notified that you received this email in error and
that any review, dissemination, distribution or copying of this email and any
attachment is strictly prohibited. If you have received this email in error,
please contact the sender and delete the message and any attachment from your
system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
-- next part --
A non-text attachment was scrubbed...
Name: debugirq.tar.xz
Type: application/octet-stream
Size: 1808 bytes
Desc: debugirq.tar.xz
URL:
<http://xenomai.org/pipermail/xenomai/attachments/20190709/8de577f3/attachment.obj>
Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)
Hi, I am opening a packetsocket, which is supposed to be realtime. Unfortunatly if the rtpacket (rtnet?) module is not loaded, then this will just silently fall back to a linux packet socket. Then later demote thread during accesses. How would I be able to detect this early during startup? I could __STD(close) the descriptor and check the returncode for EBADF I suppose... Mit besten Grüßen / Kind regards NORBERT LANGE AT-DES ANDRITZ HYDRO GmbH Eibesbrunnergasse 20 1120 Vienna / AUSTRIA p: +43 50805 56684 norbert.la...@andritz.com andritz.com This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You
