From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ackJvSbdV6A for ; Wed, 17 Aug 2011 09:31:54 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 17 Aug 2011 09:31:53 +0200 (CEST) Message-ID: <4E4B6E61.4020301@redhat.com> Date: Wed, 17 Aug 2011 09:31:45 +0200 From: Milan Broz MIME-Version: 1.0 References: <4E4AD6F2.8020800@archlinux.org> <4E4AE4DB.30205@redhat.com> <4E4AE740.9020800@archlinux.org> In-Reply-To: <4E4AE740.9020800@archlinux.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] The weird bug again: semid XXXXXX: semop failed for cookie 0xdeadbeef: incorrect semaphore state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Thomas_B=E4chler?= Cc: dm-crypt On 08/16/2011 11:55 PM, Thomas B=E4chler wrote: > Am 16.08.2011 23:44, schrieb Milan Broz: >> On 08/16/2011 10:45 PM, Thomas B=E4chler wrote: >>> I am getting reports of this error again: >>> >>> semid 491524: semop failed for cookie 0xd4dc159: incorrect semaphore st= ate >>> Failed to set a proper state for notification semaphore identified by >>> cookie value 223199577 (0xd4dc159) to initialize waiting for incoming >>> notifications. >>> >>> This issue is so weird that I don't know where to start. Apparently, >>> this problem appears whenever chromium is running, and disappears when >>> you quit chromium. I'm confused about this. Very confused. >> >> I know that this bug is still there. I think that the problem is: >> >> - kernel, in response to devmapper library request, send uevent with coo= kie >> - kernel reports failure (despite uevent was sent), I guess it is >> some memory allocation error later >> - libdevmapper takes error path, destroying semaphore, which was already >> destroyed in udev rules >> >> So my guess is that connection with chromium just it perhaps allocates m= ost >> of system memory and some allocation in kernel perhaps fail then. >=20 > Then this would probably be reproducible with other programs, too. So > far, the connection has been only made with chromium. I would love to > find another test case though. Well, this is the most strange report so far. If more people can reproduce = it, there must be a connection. Isn't chromium using system semaphores intensiv= ely? (I have no idea.) What says "ipcs -s" (with and without chromium running)? Will increasing number of system semaphores help (first number)? sysctl -a |grep sem Can you try to increase it to 1000 for example sysctl -w kernel.sem=3D1000 >=20 >> The final state should be correct, so you can (I hope) ignore that error >> for now. >=20 > Don't the LUKS commands abort after this error? (Don't remember). It should not. Milan