Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]
On 2017-Apr-20, at 2:31 AM, Tom Vijlbrief wrote:
>> Op wo 19 apr. 2017 09:11 schreef Tom Vijlbrief :
>> I'm currently rebuilding world and kernel on a just completed SVN checkout.
>>
>> Note that the normal sendmail daemon which listens for incoming traffic does
>> NOT loop.
>>
>> The sendmail instance which tries local delivery (echo Hi | mail root) or
>> the msp_queue instance is looping.
>>
>> It might be an arm64 specific issue, but a few weeks ago this was not an
>> issue.
>>
> I just completed a full rebuild on the Pine64 and I cannot reproduce the
> problem, so there is probably no issue anymore...
>
> (Except the spurious interrupts issue)
FYI:
I've not seen a spurious interrupts notification on
arm64/aarch64.
I have seen such on cortex-a7 (the armv6/7 examples
that I have access to are this: so just armv7).
For cortex-a7 I build with the following local experiment
for information gathering:
# svnlite diff /usr/src/sys/arm/arm/gic.c
Index: /usr/src/sys/arm/arm/gic.c
===
--- /usr/src/sys/arm/arm/gic.c (revision 317015)
+++ /usr/src/sys/arm/arm/gic.c (working copy)
@@ -672,9 +672,13 @@
if (irq >= sc->nirqs) {
#ifdef GIC_DEBUG_SPURIOUS
+#define EXPECTED_SPURIOUS_IRQ 1023
+ if (irq != EXPECTED_SPURIOUS_IRQ) {
device_printf(sc->gic_dev,
- "Spurious interrupt detected: last irq: %d on CPU%d\n",
+ "Spurious interrupt %d detected of %d: last irq: %d on
CPU%d\n",
+ irq, sc->nirqs,
sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid));
+}
#endif
return (FILTER_HANDLED);
}
@@ -720,6 +724,16 @@
if (irq < sc->nirqs)
goto dispatch_irq;
+ if (irq != EXPECTED_SPURIOUS_IRQ) {
+#undef EXPECTED_SPURIOUS_IRQ
+#ifdef GIC_DEBUG_SPURIOUS
+ device_printf(sc->gic_dev,
+ "Spurious end interrupt %d detected of %d: last irq: %d on
CPU%d\n",
+ irq, sc->nirqs,
+ sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid));
+#endif
+ }
+
return (FILTER_HANDLED);
}
It has never reported a non-1023 IRQ.
Quoting arm_gic_architecture_specification.pdf (various places about the 1023
IRQ figure):
• A processor reads the GICC_IAR and obtains the interrupt ID 1023,
indicating a spurious interrupt. The processor can return from its interrupt
service routine without writing to its GICC_EOIR.
The spurious interrupt ID indicates that the original interrupt is no longer
pending, typically because another target processor is handling it.
and . . .
• 1023 This value is returned to a processor, in response to an
interrupt acknowledge, if there is no pending interrupt with sufficient
priority for it to be signaled to the processor.
and . . .
GICC_IAR read GICC_CTLR.AckCtl
Returned interrupt ID
Highest priority pending interrupt^a is Group 0 Non-secure x
Interrupt ID 1023
No pending interrupts^a x x
Interrupt ID 1023
Interrupt signaling of the required interrupt group by CPU interface disabled
x x
Interrupt ID 1023
^a. Of sufficient priority to be signaled to the processor if signaling by the
CPU interface is enabled.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]
Op wo 19 apr. 2017 09:11 schreef Tom Vijlbrief <tvijlbr...@gmail.com>:
> I'm currently rebuilding world and kernel on a just completed SVN checkout.
>
> Note that the normal sendmail daemon which listens for incoming traffic
> does NOT loop.
>
> The sendmail instance which tries local delivery (echo Hi | mail root) or
> the msp_queue instance is looping.
>
> It might be an arm64 specific issue, but a few weeks ago this was not an
> issue.
>
I just completed a full rebuild on the Pine64 and I cannot reproduce the
problem, so there is probably no issue anymore...
(Except the spurious interrupts issue)
> Op di 18 apr. 2017 om 21:15 schreef Mark Millard <mar...@dsl-only.net>:
>
>> Ronald Klop ronald-lists at klop.ws wrote on Tue Apr 18 09:59:50 UTC
>> 2017:
>>
>> > there is a thread ono this list about a problem in syslogd which made
>> > syslog-clients (like sendmail busy-looping on logging.
>> > That might be related to this. (it is fixed in the source already, so
>> > upgrading again might help)
>> > See the thread with subject like 'Re: r316958: booting a server takes
>> >10
>> > minutes!'
>> >
>> > Regards,
>> >
>> > Ronald.
>>
>>
>> Yes. But Tom V.'s report is for -r317039, which is after the reported
>> fixes as far as I can tell. Something besides syslogd might also cause
>> problems?
>>
>> In my nearly-default -r317015 ardm64 context [as a VirtualBox guest]
>> I've not seen the problem, where I did before. (The only reason sendmail
>> runs in my context is for the messages FreeBSD sends to it own local
>> accounts. I do not otherwise use mail in this context.)
>>
>> Tom V.'s report vs. others finding lack of a problem suggests that the
>> coverage of the fixes is incomplete somehow but useful. I happen to not
>> be doing whatever causes the problem to appear. I've no clue what might
>> be different or unusual in Tom V.'s context.
>>
>> There is also the possibility that Tom V.'s report is a fully independent
>> issue. But such does not seem all that likely on the initial information.
>>
>>
>> > On 2017-Apr-17, at 7:57 AM, Mark Millard
>> wrote:
>> >
>> >> Just an FYI of a more recent report of runaway sendmail on a
>> >> more recent system version ( -r317039 ):
>> >>
>> >> Begin forwarded message:
>> >>
>> >>> From: Tom Vijlbrief
>> >>> Subject: Sendmail eats CPU on r317039
>> >>> Date: April 17, 2017 at 3:39:37 AM PDT
>> >>> To: "freebsd-current at freebsd.org" ,
>> freebsd-arm
>> >>>
>> >>> On a recent kernel sendmail is constantly consuming CPU.
>> >>>
>> >>> truss -p PID
>> >>>
>> >>> shows:
>> >>>
>> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
>> 'No
>> >>> buffer space available'
>> >>> nanosleep({ 0.01000 }) = 0 (0x0)
>> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
>> 'No
>> >>> buffer space available'
>> >>> nanosleep({ 0.01000 })
>> >>> ...
>> >>>
>> >>> This is on an arm64 system
>> >>
>> >> Analysis of Tom V.'s context for this may be required.
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>> ___
>> freebsd-...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]
I'm currently rebuilding world and kernel on a just completed SVN checkout.
Note that the normal sendmail daemon which listens for incoming traffic
does NOT loop.
The sendmail instance which tries local delivery (echo Hi | mail root) or
the msp_queue instance is looping.
It might be an arm64 specific issue, but a few weeks ago this was not an
issue.
Op di 18 apr. 2017 om 21:15 schreef Mark Millard <mar...@dsl-only.net>:
> Ronald Klop ronald-lists at klop.ws wrote on Tue Apr 18 09:59:50 UTC 2017:
>
> > there is a thread ono this list about a problem in syslogd which made
> > syslog-clients (like sendmail busy-looping on logging.
> > That might be related to this. (it is fixed in the source already, so
> > upgrading again might help)
> > See the thread with subject like 'Re: r316958: booting a server takes >10
> > minutes!'
> >
> > Regards,
> >
> > Ronald.
>
>
> Yes. But Tom V.'s report is for -r317039, which is after the reported
> fixes as far as I can tell. Something besides syslogd might also cause
> problems?
>
> In my nearly-default -r317015 ardm64 context [as a VirtualBox guest]
> I've not seen the problem, where I did before. (The only reason sendmail
> runs in my context is for the messages FreeBSD sends to it own local
> accounts. I do not otherwise use mail in this context.)
>
> Tom V.'s report vs. others finding lack of a problem suggests that the
> coverage of the fixes is incomplete somehow but useful. I happen to not
> be doing whatever causes the problem to appear. I've no clue what might
> be different or unusual in Tom V.'s context.
>
> There is also the possibility that Tom V.'s report is a fully independent
> issue. But such does not seem all that likely on the initial information.
>
>
> > On 2017-Apr-17, at 7:57 AM, Mark Millard wrote:
> >
> >> Just an FYI of a more recent report of runaway sendmail on a
> >> more recent system version ( -r317039 ):
> >>
> >> Begin forwarded message:
> >>
> >>> From: Tom Vijlbrief
> >>> Subject: Sendmail eats CPU on r317039
> >>> Date: April 17, 2017 at 3:39:37 AM PDT
> >>> To: "freebsd-current at freebsd.org" ,
> freebsd-arm
> >>>
> >>> On a recent kernel sendmail is constantly consuming CPU.
> >>>
> >>> truss -p PID
> >>>
> >>> shows:
> >>>
> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
> 'No
> >>> buffer space available'
> >>> nanosleep({ 0.01000 }) = 0 (0x0)
> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
> 'No
> >>> buffer space available'
> >>> nanosleep({ 0.01000 })
> >>> ...
> >>>
> >>> This is on an arm64 system
> >>
> >> Analysis of Tom V.'s context for this may be required.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]
Ronald Klop ronald-lists at klop.ws wrote on Tue Apr 18 09:59:50 UTC 2017:
> there is a thread ono this list about a problem in syslogd which made
> syslog-clients (like sendmail busy-looping on logging.
> That might be related to this. (it is fixed in the source already, so
> upgrading again might help)
> See the thread with subject like 'Re: r316958: booting a server takes >10
> minutes!'
>
> Regards,
>
> Ronald.
Yes. But Tom V.'s report is for -r317039, which is after the reported
fixes as far as I can tell. Something besides syslogd might also cause
problems?
In my nearly-default -r317015 ardm64 context [as a VirtualBox guest]
I've not seen the problem, where I did before. (The only reason sendmail
runs in my context is for the messages FreeBSD sends to it own local
accounts. I do not otherwise use mail in this context.)
Tom V.'s report vs. others finding lack of a problem suggests that the
coverage of the fixes is incomplete somehow but useful. I happen to not
be doing whatever causes the problem to appear. I've no clue what might
be different or unusual in Tom V.'s context.
There is also the possibility that Tom V.'s report is a fully independent
issue. But such does not seem all that likely on the initial information.
> On 2017-Apr-17, at 7:57 AM, Mark Millard wrote:
>
>> Just an FYI of a more recent report of runaway sendmail on a
>> more recent system version ( -r317039 ):
>>
>> Begin forwarded message:
>>
>>> From: Tom Vijlbrief
>>> Subject: Sendmail eats CPU on r317039
>>> Date: April 17, 2017 at 3:39:37 AM PDT
>>> To: "freebsd-current at freebsd.org" ,
>>> freebsd-arm
>>>
>>> On a recent kernel sendmail is constantly consuming CPU.
>>>
>>> truss -p PID
>>>
>>> shows:
>>>
>>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
>>> buffer space available'
>>> nanosleep({ 0.01000 }) = 0 (0x0)
>>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
>>> buffer space available'
>>> nanosleep({ 0.01000 })
>>> ...
>>>
>>> This is on an arm64 system
>>
>> Analysis of Tom V.'s context for this may be required.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fwd: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]
there is a thread ono this list about a problem in syslogd which made
syslog-clients (like sendmail busy-looping on logging.
That might be related to this. (it is fixed in the source already, so
upgrading again might help)
See the thread with subject like 'Re: r316958: booting a server takes >10
minutes!'
Regards,
Ronald.
On Mon, 17 Apr 2017 16:57:39 +0200, Mark Millard <mar...@dsl-only.net>
wrote:
Just an FYI of a more recent report of runaway sendmail on a
more recent system version ( -r317039 ):
Begin forwarded message:
From: Tom Vijlbrief
Subject: Sendmail eats CPU on r317039
Date: April 17, 2017 at 3:39:37 AM PDT
To: "freebsd-current at freebsd.org" ,
freebsd-arm
On a recent kernel sendmail is constantly consuming CPU.
truss -p PID
shows:
sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
'No
buffer space available'
nanosleep({ 0.01000 }) = 0 (0x0)
sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
'No
buffer space available'
nanosleep({ 0.01000 })
...
This is on an arm64 system
Analysis of Tom V.'s context for this may be required.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fwd: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]
Just an FYI of a more recent report of runaway sendmail on a
more recent system version ( -r317039 ):
Begin forwarded message:
> From: Tom Vijlbrief
> Subject: Sendmail eats CPU on r317039
> Date: April 17, 2017 at 3:39:37 AM PDT
> To: "freebsd-current at freebsd.org" ,
> freebsd-arm
>
> On a recent kernel sendmail is constantly consuming CPU.
>
> truss -p PID
>
> shows:
>
> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
> buffer space available'
> nanosleep({ 0.01000 }) = 0 (0x0)
> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
> buffer space available'
> nanosleep({ 0.01000 })
> ...
>
> This is on an arm64 system
Analysis of Tom V.'s context for this may be required.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Sendmail eats CPU on r317039
On a recent kernel sendmail is constantly consuming CPU.
truss -p PID
shows:
sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
buffer space available'
nanosleep({ 0.01000 }) = 0 (0x0)
sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
buffer space available'
nanosleep({ 0.01000 })
...
This is on an arm64 system
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
