FS#24614 - [device-mapper] [linux] semid 491524: semop failed for cookie 0xd4dc159: incorrect semaphore state

Attached to Project: Arch Linux
Opened by Max Pray (synthead) - Tuesday, 07 June 2011, 13:15 GMT
Last edited by Thomas Bächler (brain0) - Thursday, 08 March 2012, 13:49 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Eric Belanger (Snowman)
Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Using packages:
cryptsetup 1.3.1-1
kernel26 2.6.38.7-1

Dump from console:
[max@killterm3 ~]$ sudo cryptsetup luksFormat /dev/sdf6

WARNING!
========
This will overwrite data on /dev/sdf6 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
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 notifications.
This task depends upon

Closed by  Thomas Bächler (brain0)
Thursday, 08 March 2012, 13:49 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fix has been applied in 3.1-rc4 and in 3.0 stable kernels.
Comment by Thomas Bächler (brain0) - Wednesday, 08 June 2011, 17:48 GMT
I have seen this before, but don't remember where. Does it actually fail to complete the luksFormat command?

Please also provide version numbers for cryptsetup, udev and the kernel.
Comment by Thomas Bächler (brain0) - Wednesday, 08 June 2011, 17:51 GMT
I know where I saw this before:  FS#22351 .

Back then, this went away with an upgrade to device-mapper. Please provide the device-mapper version as well.
Comment by Max Pray (synthead) - Thursday, 09 June 2011, 02:00 GMT
Here's the version numbers:

device-mapper 2.02.85-2
cryptsetup 1.3.1-1
udev 171-2
kernel26 2.6.38.8-1
Comment by Max Pray (synthead) - Thursday, 09 June 2011, 02:06 GMT
Oh, I should also mention that this only happens on x86_64. I am able to run cryptsetup on my i686 machine without any errors.
These are the versions for the i686 machine:

device-mapper 2.02.85-1
cryptsetup 1.3.0-1
udev 171-1
kernel26 2.6.38.7-1
Comment by Thomas Bächler (brain0) - Thursday, 09 June 2011, 08:05 GMT
I see some minor version differences between your machines here. I don't think they matter, but could you test with the same versions anyway?
Comment by Alexander Koch (lynix) - Wednesday, 29 June 2011, 19:37 GMT
Same problem here on x86_64 with:

device-mapper 2.02.85-2
cryptsetup 1.3.1-1
udev 171-2
kernel26 2.6.39.2-1
Comment by Thomas Bächler (brain0) - Thursday, 30 June 2011, 08:59 GMT
Someone needs to report this to the device mapper people. This was a bug in an old version of device-mapper, which magically disappeared and now reappeared. Can someone who is affected please downgrade device-mapper until they find the last version that works?
Comment by Sylvain (Tarjaizaid) - Sunday, 17 July 2011, 16:38 GMT
I've same problem with i686 arch

This error appears when chromium is running.

If i run chromium-12.0.742.124-1 and use cryptsetup i've this error otherwise no.
If i use chromium-browser-bin-92813-1 (aur) I doesn't get this error.

bug on chromium ?
Comment by Armin Eibl (sysrmr) - Sunday, 07 August 2011, 06:59 GMT
Same problem here and appears only if chromium is running.

i am running on x86_64
cryptsetup 1.3.1-2
device-mapper 2.02.86-1
kernel26 2.6.39-1
udev 173-3
chromium 13.0.782.107-1
Comment by Thomas Bächler (brain0) - Sunday, 07 August 2011, 09:08 GMT
The connection to chromium is confusing, I really can't understand it.
Comment by Mark Meyer (ofosos) - Monday, 08 August 2011, 10:33 GMT
same problem on x86_64, stopping chromium fixes it
Comment by Joshua D Miller (joshdmiller) - Saturday, 13 August 2011, 03:04 GMT
Same error on x86_64; stopping chromium does indeed fix it and allows the operation to complete successfully.

I also have this same problem when running luksOpen, but it actually completes this operation despite the error.
Comment by Alexander Koch (lynix) - Saturday, 13 August 2011, 08:50 GMT
Although I cannot imagine how this all comes down to chromium, I have opened a bug report in the chromium bug tracker:
http://code.google.com/p/chromium/issues/detail?id=92762
Comment by Alexander Koch (lynix) - Tuesday, 16 August 2011, 20:10 GMT
I'm receiving confirmations from users of other distributions, so I think this is not Arch-related.
This bug can be closed, I suppose.
Comment by Thomas Bächler (brain0) - Tuesday, 16 August 2011, 20:42 GMT
Amazing, I'll need to talk to Milan, maybe he can help.
Comment by Thomas Bächler (brain0) - Wednesday, 17 August 2011, 08:06 GMT
This bug seems to be reproducible as well with LVM. From Milan:

> 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 intensively?
> (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=1000"
(http://www.saout.de/pipermail/dm-crypt/2011-August/001901.html)
Comment by Thomas Bächler (brain0) - Thursday, 18 August 2011, 11:33 GMT
Bug report: https://lkml.org/lkml/2011/8/18/112
Comment by x (onexused) - Saturday, 20 August 2011, 04:20 GMT
This happens for me too, both with LVM commands on one machine and cryptsetup commands on another. The commands complete correctly, though. I don't use chromium. ipcs -s says:"
------ Semaphore Arrays --------
key semid owner perms nsems
"
Comment by Thomas Bächler (brain0) - Tuesday, 23 August 2011, 16:10 GMT
If you feel like patching your kernel, here is a patch that should fix it: https://lkml.org/lkml/2011/8/22/155
Comment by Mihael Pranjić (tux) - Wednesday, 07 September 2011, 20:59 GMT
when you see it you shit bricks

I confirm this behaviour on my systems too
Comment by Vasili (3point2) - Thursday, 15 September 2011, 11:58 GMT
I can confirm this on my i686 system too. Closing Chromium does indeed make the error go away.
Comment by Thomas Bächler (brain0) - Thursday, 15 September 2011, 18:32 GMT
Did anyone try the kernel patch I posted?
Comment by Jakob Matthes (jakobm) - Thursday, 15 September 2011, 22:35 GMT
Thomas: The patch works. I no longer get any 'semop failed' messages from cryptsetup operations.
Comment by Robert Orzanna (orschiro) - Tuesday, 11 October 2011, 19:53 GMT
Will the patch be added to the default kernel?

I'm experiencing the same issue with 64bit.

Comment by Thomas Bächler (brain0) - Tuesday, 11 October 2011, 20:42 GMT
I hope so, but I haven't checked if it's in 3.1 already.
Comment by Robert Orzanna (orschiro) - Wednesday, 12 October 2011, 19:15 GMT
Recently I updated to linux 3.0.6-2 which solves the bugs.

Regards
Comment by Jakob Matthes (jakobm) - Thursday, 13 October 2011, 17:15 GMT
I cannot confirm that, Robert, 3.0.6-2 has the same issue. The patch is not yet applied to kernel. Could you find the specific change that fixed it?
Comment by Robert Orzanna (orschiro) - Thursday, 13 October 2011, 17:42 GMT
That's interesting. Are you on a 64 Bit system as well?

I cannot think of other changes apart from the kernel update.

cryptsetup 1.3.1-2
device-mapper 2.02.88-1
chromium 14.0.835.202-1
udev 173-3

Regards
Comment by Jakob Matthes (jakobm) - Thursday, 13 October 2011, 20:18 GMT
same versions, x86-64 system
Comment by Robert Orzanna (orschiro) - Monday, 17 October 2011, 03:31 GMT
How do you mount your drive?

I use gvfs and thunar for it which may handle mounting differently.

Regards
Comment by Tobias Powalowski (tpowa) - Thursday, 08 March 2012, 13:33 GMT
status of this issue?
Comment by Vasili (3point2) - Thursday, 08 March 2012, 13:46 GMT
i just used luksFormat with chromium running with the 3.2.8-1-ARCH (32-bit) kernel and the issue seems to be resolved. the only thing is that i formatted a regular file, not a real block device (when i experienced this bug, it was with a real block device).

Loading...