On Wed, 02 Sep 2026 09:20:21 -0400 Noah Meyerhans <[email protected]> wrote:
> Source: dovecot
> Version: 1:2.4.5+dfsg1-1
> Severity: serious
> Tags: ftbfs
> Justification: ftbfs
> X-Debbugs-Cc: [email protected]
> User: [email protected]
> Usertags: loong64
> 
> Dovecot 2.4.5-1 ftbfs on loong64.  The build appears to complete
> successfully, but the test suite fails.
> 
> Full buildd log is at
> https://buildd.debian.org/status/fetch.php?pkg=dovecot&arch=loong64&ver=1%3A2.4.5%2Bdfsg1-1&stamp=1788231491&raw=0&pow_referer=
> and the relevant failure is logged as:
> 
> ostream multiplex stream (backpressure): sub-process ended properly .. : 
> FAILED
> Warning: test: Sub-process forcibly terminated with signal 9
> ostream multiplex stream (backpressure) .............................. : 
> FAILED
> 
> The code that is timing out contains the following description:
> 
> /* Once the socket is congested the channel must apply backpressure so
>    o_stream_send_istream() stops and waits (WAIT_OUTPUT), instead of buffering
>    the whole body into the parent without bound and busy-looping a writev() on
>    the full socket. A regression either busy-loops forever (never returns) or
>    swallows the whole body (FINISHED) - the first is caught by the subprocess
>    watchdog killing the hung child, the second by the assertions below failing
>    in the child. Either way the parent test fails cleanly. */
> 
> I've tried bumping the timeout to see if this is simply a matter of an
> overly aggressive watchdog, but it doesn't seem to be the case.  The process
> seems to hang indefinitely, which suggests a regression according to the
> above comment.  It's not clear why this would be architecture specific,
> though.
> 
> The problem is 100% reproducible on porter boxes.
> 
>

Dear maintainer,

I saw the workaround changing the buffer size from 4K to 8K which had solved the
problem. I doubt if this issue is related to page size, since loong64 is the 
only
release architecture that by default is in 16K page size. This speculation can 
be
confirmed if this issue can also be reproduced on arm64 using the 16K page size
kernel.

Cheers,

Miao Wang

Reply via email to