similar to: Issue with a bug with imap-login

On 7 Sep 2018, at 19.43, Timo Sirainen <tss at iki.fi> wrote: > > On 7 Sep 2018, at 16.50, Simone Lazzaris <s.lazzaris at interactive.eu <mailto:s.lazzaris at interactive.eu>> wrote: >> >> Some more information: the issue has just occurred, again on an instance without the "service_count = 0" configuration directive on pop3-login. >> >>

Some more information: the issue has just occurred, again on an instance without the "service_count = 0" configuration directive on pop3-login. I've observed that while the issue is occurring, the director process goes 100% CPU. I've straced the process. It is seemingly looping: ... ... epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, {u32=149035320,

In data venerd? 7 settembre 2018 10:06:00 CEST, Sami Ketola ha scritto: > > On 7 Sep 2018, at 11.00, Simone Lazzaris <s.lazzaris at interactive.eu> > > wrote: > > > > > > The only suspect thing is this: > > > > Sep 6 14:45:41 imap-front13 dovecot: director: doveadm: Host > > 192.168.1.142 > > vhost count changed from 100 to 0 >

On 7 Sep 2018, at 16.50, Simone Lazzaris <s.lazzaris at interactive.eu> wrote: > > Some more information: the issue has just occurred, again on an instance without the "service_count = 0" configuration directive on pop3-login. > > I've observed that while the issue is occurring, the director process goes 100% CPU. I've straced the process. It is seemingly

In data venerd? 7 settembre 2018 11:20:49 CEST, Sami Ketola ha scritto: > > On 7 Sep 2018, at 11.25, Simone Lazzaris <simone.lazzaris at qcom.it> wrote: > > Actually, I have a poolmon script running that should drop vhost count for > > unresponsive backends; the strage thing is, the backends are NOT > > unresponsive, they are working as ususal. > If it's this

Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/drivers/char/mem.c =================================================================== --- head-2007-02-27.orig/drivers/char/mem.c 2007-03-05 10:00:18.000000000 +0100 +++ head-2007-02-27/drivers/char/mem.c 2007-02-27 16:27:37.000000000 +0100 @@ -787,7 +787,7 @@ static const struct file_operations mem_ .open =

Hello, I've been working with the quota plugin(s) the past few days and have been having some real trouble. Only a few entries are appearing in the database, a couple more when I restarted dovecot. None of the current entries were being updated either. I think I've tracked it down to somewhere in the dict backend. I put in a few i_info() statements and recompiled. A few queries get

Everyone, I have a mail server running CentOS release 6.3 (Final) with 2.6.32-279.22.1.el6.i686 kernel that is reporting errors to me pertaining dovecot. I have appended the error message to this note. There is only one user that appears to generate this message, and it is generated to me by way of e-mail without a perceptible problem to the user which is not me. This particular user had an

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 See the end of the message for a possible delete of a closed fd from epoll() problem. Every now and then I get a Panic after a successfull LMTP delivery: 2014-11-12 13:25:31 lmtp(20890): Info: Connect from local 2014-11-12 13:25:32 lmtp(20890): Info: Disconnect from local: Connection closed (in reset) 2014-11-12 13:25:34 lmtp(20890): Info: Connect

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma manager. When passing NULL the embedded _vma_manager is used. All callers are updated to pass NULL, so the behavior doesn't change. Signed-off-by:

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma manager. When passing NULL the embedded _vma_manager is used. All callers are updated to pass NULL, so the behavior doesn't change. Signed-off-by:

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma manager. When passing NULL the embedded _vma_manager is used. All callers are updated to pass NULL, so the behavior doesn't change. Signed-off-by:

On Wed, 2024-10-02 at 14:54 +0200, Thomas Hellstr?m wrote: > On Wed, 2024-10-02 at 14:45 +0200, Christian K?nig wrote: > > Am 02.10.24 um 14:24 schrieb Thomas Hellstr?m: > > > The ttm_device_init funcition uses multiple bool arguments. That > > > means > > > readability in the caller becomes poor, and all callers need to > > > change if > > >

On Fri, Oct 04, 2024 at 04:28:29PM +0200, Thomas Hellstr?m wrote: > On Wed, 2024-10-02 at 14:54 +0200, Thomas Hellstr?m wrote: > > On Wed, 2024-10-02 at 14:45 +0200, Christian K?nig wrote: > > > Am 02.10.24 um 14:24 schrieb Thomas Hellstr?m: > > > > The ttm_device_init funcition uses multiple bool arguments. That > > > > means > > > >

This includes two kernel patches, scsi-target and IO_CMD_EPOLL_WAIT. The former is a modified version of the scsi target infrastructure in mainline. The latter enables applications to handle AIO and non-AIO fds in the same loop. blktap uses the different patch, AIO event queue patch for the same aim. The IO_CMD_EPOLL_WAIT patch will be merged into mainline (and the AIO event queue will not) so

Hi: I have been using Dovecot for well over a year now and it has always worked with few problems. The mail setup is not simple... Postfix+MailScanner+ClamAV+Docvecot+MySql+postfix.admin... just to mention the major things. The system is CentOS 5.3 on VMware. The maildir is on an NFS share, index and control is local. About a month ago I thought I upgraded from 1.1.x to 1.2.x. by doing an

On 7.3.2019 23.37, A. Schulze via dovecot wrote: > > Am 07.03.19 um 17:33 schrieb Aki Tuomi via dovecot: > >>> test-http-client-errors.c:2989: Assert failed: FALSE >>> connection timed out ................................................. : FAILED > Hello Aki, > >> Are you running with valgrind or on really slow system? > I'm not aware my buildsystem

Every few days I find that dovecot auth is using all my CPU. This is from dovecot 2.2.13, I've just upgraded to 2.2.18 strace -r -p 17956 output: Process 17956 attached 0.000000 lseek(19, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) 0.000057 getsockname(19, {sa_family=AF_LOCAL, NULL}, [2]) = 0 0.000043 epoll_ctl(15, EPOLL_CTL_ADD, 19, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP,

Hi. I have Centos 7 (updated) running as my host, and I?m using Qemu and KVM, version 2.0.0 and 2.6.0. I have a Trendnet TU-S9 USB serial dongle attached to the host, which uses the Prolific 2303 chipset. I blacklisted the pl2303 driver so the host doesn?t grab the device, and want to expose it to the guest. On the client, I see 2 USB hubs (3.0 and 2.0), and I see 2 USB endpoints (even though

Drivers have no business looking into dma-mapping internals and check what backend is used. Unfortunstely the DRM core is still broken and tries to do plain page allocations instead of using DMA API allocators by default and uses various bandaids on when to use dma_alloc_coherent. Switch nouveau to use the same (broken) scheme as amdgpu and radeon to remove the last driver user of