[dm-crypt] The weird bug again: semid XXXXXX: semop failed for cookie 0xdeadbeef: incorrect semaphore state
thomas at archlinux.org
Tue Aug 16 23:55:12 CEST 2011
Am 16.08.2011 23:44, schrieb Milan Broz:
> On 08/16/2011 10:45 PM, Thomas Bächler wrote:
>> I am getting reports of this error again:
>> semid 491524: semop failed for cookie 0xd4dc159: incorrect semaphore state
>> Failed to set a proper state for notification semaphore identified by
>> cookie value 223199577 (0xd4dc159) to initialize waiting for incoming
>> 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 cookie
> - 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 most
> of system memory and some allocation in kernel perhaps fail then.
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.
> The final state should be correct, so you can (I hope) ignore that error
> for now.
Don't the LUKS commands abort after this error? (Don't remember).
> It is not a cryptsetup bug but I would like to fix it anyway,
> the problem is the bug appears and disappears quite randomly.
> Does anyone see this bug in some other libdevmapper user?
> (lvm, multipath, kpartx, ... ?)
I have only seen this with cryptsetup so far.
> (Another possibility is that you have broken udev rules and
> "dmsetup udevcomplete" is called twice there, but I do not think it
> the issue.)
Udev rules are all taken directly from upstream udev and device-mapper.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the dm-crypt