* udev cookie on DM_DEVICE_RELOAD
@ 2015-06-29 13:46 Hannes Reinecke
2015-06-29 14:02 ` Mike Snitzer
2015-06-29 14:45 ` Alasdair G Kergon
0 siblings, 2 replies; 9+ messages in thread
From: Hannes Reinecke @ 2015-06-29 13:46 UTC (permalink / raw)
To: device-mapper development; +Cc: Mike Snitzer
Hi all,
I've been debugging weird failures in multipathing, where 'multipath
-r' would occasionally incide libdevmapper to create
device nodes under /dev/mapper on it's own, instead of relying on
udev for doing so.
Looking in the logs, I've found:
Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
3600508b4000cf1c300008000002b0000 NF [16384] (*1)
Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1689): Cookie
value is not set while trying to call DM_DEVICE_RESUME ioctl.
Please, consider using libdevmapper's udev synchronisation interface
or disable it explicitly by calling dm_udev_set_sync_support(0).
Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1691): Switching
off device-mapper and all subsystem related udev rules. Falling back
to libdevmapper node creation.
Okay, that'll explain it.
Then I've added a cookie to the call of DM_DEVICE_RELOAD, and
encountered a hang:
Jun 29 15:41:55 | 3600508b1001047395656543131580001: addmap [0
143305920 multipath 1 queue_if_no_path 0 1 1 service-time 0 1 1 104:0 1]
Jun 29 15:41:55 | libdevmapper: libdm-common.c(2105): Udev cookie
0xd4d7246 (semid 6062098) created
Jun 29 15:41:55 | libdevmapper: libdm-common.c(2125): Udev cookie
0xd4d7246 (semid 6062098) incremented to 1
Jun 29 15:41:55 | libdevmapper: libdm-common.c(1997): Udev cookie
0xd4d7246 (semid 6062098) incremented to 2
Jun 29 15:41:55 | libdevmapper: libdm-common.c(2238): Udev cookie
0xd4d7246 (semid 6062098) assigned to RELOAD task(1) with flags
DISABLE_LIBRARY_FALLBACK (0x20)
Jun 29 15:41:55 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
3600508b1001047395656543131580001 NNS [16384] (*1)
Jun 29 15:41:55 | libdevmapper: libdm-common.c(2032): Udev cookie
0xd4d7246 (semid 6062098) decremented to 1
Jun 29 15:41:55 | libdevmapper: libdm-common.c(2288): Udev cookie
0xd4d7246 (semid 6062098) waiting for zero
(hangs)
So apparently you can only set the cookie for DM_DEVICE_RESUME,
_not_ DM_DEVICE_RELOAD.
Which is odd, as DM_DEVICE_RELOAD is the only call I'll ever do;
apparently it's being translated internally into a
suspend/reload/resume cycle.
Shouldn't device-mapper take care of setting the cookie correctly?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udev cookie on DM_DEVICE_RELOAD
2015-06-29 13:46 udev cookie on DM_DEVICE_RELOAD Hannes Reinecke
@ 2015-06-29 14:02 ` Mike Snitzer
2015-06-29 14:45 ` Alasdair G Kergon
1 sibling, 0 replies; 9+ messages in thread
From: Mike Snitzer @ 2015-06-29 14:02 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: device-mapper development, Peter Rajnoha, lvm-devel
On Mon, Jun 29 2015 at 9:46am -0400,
Hannes Reinecke <hare@suse.de> wrote:
> Hi all,
>
> I've been debugging weird failures in multipathing, where 'multipath
> -r' would occasionally incide libdevmapper to create
> device nodes under /dev/mapper on it's own, instead of relying on
> udev for doing so.
> Looking in the logs, I've found:
>
> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
> 3600508b4000cf1c300008000002b0000 NF [16384] (*1)
> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1689): Cookie
> value is not set while trying to call DM_DEVICE_RESUME ioctl.
> Please, consider using libdevmapper's udev synchronisation interface
> or disable it explicitly by calling dm_udev_set_sync_support(0).
> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1691): Switching
> off device-mapper and all subsystem related udev rules. Falling back
> to libdevmapper node creation.
>
> Okay, that'll explain it.
> Then I've added a cookie to the call of DM_DEVICE_RELOAD, and
> encountered a hang:
> Jun 29 15:41:55 | 3600508b1001047395656543131580001: addmap [0
> 143305920 multipath 1 queue_if_no_path 0 1 1 service-time 0 1 1 104:0 1]
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2105): Udev cookie
> 0xd4d7246 (semid 6062098) created
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2125): Udev cookie
> 0xd4d7246 (semid 6062098) incremented to 1
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(1997): Udev cookie
> 0xd4d7246 (semid 6062098) incremented to 2
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2238): Udev cookie
> 0xd4d7246 (semid 6062098) assigned to RELOAD task(1) with flags
> DISABLE_LIBRARY_FALLBACK (0x20)
> Jun 29 15:41:55 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
> 3600508b1001047395656543131580001 NNS [16384] (*1)
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2032): Udev cookie
> 0xd4d7246 (semid 6062098) decremented to 1
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2288): Udev cookie
> 0xd4d7246 (semid 6062098) waiting for zero
> (hangs)
>
> So apparently you can only set the cookie for DM_DEVICE_RESUME,
> _not_ DM_DEVICE_RELOAD.
>
> Which is odd, as DM_DEVICE_RELOAD is the only call I'll ever do;
> apparently it's being translated internally into a
> suspend/reload/resume cycle.
>
> Shouldn't device-mapper take care of setting the cookie correctly?
This is really a question for the lvm2 developers (Alasdair and Peter
Rajnoha specifically, cc'd).
--
lvm-devel mailing list
lvm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/lvm-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* udev cookie on DM_DEVICE_RELOAD
@ 2015-06-29 14:02 ` Mike Snitzer
0 siblings, 0 replies; 9+ messages in thread
From: Mike Snitzer @ 2015-06-29 14:02 UTC (permalink / raw)
To: lvm-devel
On Mon, Jun 29 2015 at 9:46am -0400,
Hannes Reinecke <hare@suse.de> wrote:
> Hi all,
>
> I've been debugging weird failures in multipathing, where 'multipath
> -r' would occasionally incide libdevmapper to create
> device nodes under /dev/mapper on it's own, instead of relying on
> udev for doing so.
> Looking in the logs, I've found:
>
> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
> 3600508b4000cf1c300008000002b0000 NF [16384] (*1)
> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1689): Cookie
> value is not set while trying to call DM_DEVICE_RESUME ioctl.
> Please, consider using libdevmapper's udev synchronisation interface
> or disable it explicitly by calling dm_udev_set_sync_support(0).
> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1691): Switching
> off device-mapper and all subsystem related udev rules. Falling back
> to libdevmapper node creation.
>
> Okay, that'll explain it.
> Then I've added a cookie to the call of DM_DEVICE_RELOAD, and
> encountered a hang:
> Jun 29 15:41:55 | 3600508b1001047395656543131580001: addmap [0
> 143305920 multipath 1 queue_if_no_path 0 1 1 service-time 0 1 1 104:0 1]
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2105): Udev cookie
> 0xd4d7246 (semid 6062098) created
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2125): Udev cookie
> 0xd4d7246 (semid 6062098) incremented to 1
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(1997): Udev cookie
> 0xd4d7246 (semid 6062098) incremented to 2
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2238): Udev cookie
> 0xd4d7246 (semid 6062098) assigned to RELOAD task(1) with flags
> DISABLE_LIBRARY_FALLBACK (0x20)
> Jun 29 15:41:55 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
> 3600508b1001047395656543131580001 NNS [16384] (*1)
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2032): Udev cookie
> 0xd4d7246 (semid 6062098) decremented to 1
> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2288): Udev cookie
> 0xd4d7246 (semid 6062098) waiting for zero
> (hangs)
>
> So apparently you can only set the cookie for DM_DEVICE_RESUME,
> _not_ DM_DEVICE_RELOAD.
>
> Which is odd, as DM_DEVICE_RELOAD is the only call I'll ever do;
> apparently it's being translated internally into a
> suspend/reload/resume cycle.
>
> Shouldn't device-mapper take care of setting the cookie correctly?
This is really a question for the lvm2 developers (Alasdair and Peter
Rajnoha specifically, cc'd).
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udev cookie on DM_DEVICE_RELOAD
2015-06-29 14:02 ` Mike Snitzer
@ 2015-06-29 14:49 ` Peter Rajnoha
-1 siblings, 0 replies; 9+ messages in thread
From: Peter Rajnoha @ 2015-06-29 14:49 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: device-mapper development, LVM2 development
On 06/29/2015 04:02 PM, Mike Snitzer wrote:
> On Mon, Jun 29 2015 at 9:46am -0400,
> Hannes Reinecke <hare@suse.de> wrote:
>
>> Hi all,
>>
>> I've been debugging weird failures in multipathing, where 'multipath
>> -r' would occasionally incide libdevmapper to create
>> device nodes under /dev/mapper on it's own, instead of relying on
>> udev for doing so.
>> Looking in the logs, I've found:
>>
>> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
>> 3600508b4000cf1c300008000002b0000 NF [16384] (*1)
>> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1689): Cookie
>> value is not set while trying to call DM_DEVICE_RESUME ioctl.
>> Please, consider using libdevmapper's udev synchronisation interface
>> or disable it explicitly by calling dm_udev_set_sync_support(0).
>> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1691): Switching
>> off device-mapper and all subsystem related udev rules. Falling back
>> to libdevmapper node creation.
>>
>> Okay, that'll explain it.
>> Then I've added a cookie to the call of DM_DEVICE_RELOAD, and
>> encountered a hang:
>> Jun 29 15:41:55 | 3600508b1001047395656543131580001: addmap [0
>> 143305920 multipath 1 queue_if_no_path 0 1 1 service-time 0 1 1 104:0 1]
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2105): Udev cookie
>> 0xd4d7246 (semid 6062098) created
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2125): Udev cookie
>> 0xd4d7246 (semid 6062098) incremented to 1
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(1997): Udev cookie
>> 0xd4d7246 (semid 6062098) incremented to 2
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2238): Udev cookie
>> 0xd4d7246 (semid 6062098) assigned to RELOAD task(1) with flags
>> DISABLE_LIBRARY_FALLBACK (0x20)
>> Jun 29 15:41:55 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
>> 3600508b1001047395656543131580001 NNS [16384] (*1)
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2032): Udev cookie
>> 0xd4d7246 (semid 6062098) decremented to 1
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2288): Udev cookie
>> 0xd4d7246 (semid 6062098) waiting for zero
>> (hangs)
>>
>> So apparently you can only set the cookie for DM_DEVICE_RESUME,
>> _not_ DM_DEVICE_RELOAD.
>>
>> Which is odd, as DM_DEVICE_RELOAD is the only call I'll ever do;
>> apparently it's being translated internally into a
>> suspend/reload/resume cycle.
>>
>> Shouldn't device-mapper take care of setting the cookie correctly?
>
> This is really a question for the lvm2 developers (Alasdair and Peter
> Rajnoha specifically, cc'd).
Actually, we don't check proper combination of dm_task_set_cookie with
dm task type. So currently, if someone sets cookie on a task that does
not produce uevents, it can hang if dm_udev_wait is called for such cookie.
I've noticed we have a FIXME in the code for this already, but clearly
nobody has run into this issue yet. I'll add the check!
As for the DM_DEVICE_RELOAD - yes, it needs DM_DEVICE_RESUME to be called
right after the reload for the new table to be used (and hence the uevent
with the cookie generated as well). If you call RELOAD, the inactive
table is loaded which is then switched to active with the RESUME.
The task that is transparently translated into 3 tasks internally is the
DM_DEVICE_CREATE (with table) which translates into CREATE + LOAD + RESUME.
Anyway, yes, the check whether cookie is not misused is not there yet, so
that's why you hit this.
--
Peter
--
lvm-devel mailing list
lvm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/lvm-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* udev cookie on DM_DEVICE_RELOAD
@ 2015-06-29 14:49 ` Peter Rajnoha
0 siblings, 0 replies; 9+ messages in thread
From: Peter Rajnoha @ 2015-06-29 14:49 UTC (permalink / raw)
To: lvm-devel
On 06/29/2015 04:02 PM, Mike Snitzer wrote:
> On Mon, Jun 29 2015 at 9:46am -0400,
> Hannes Reinecke <hare@suse.de> wrote:
>
>> Hi all,
>>
>> I've been debugging weird failures in multipathing, where 'multipath
>> -r' would occasionally incide libdevmapper to create
>> device nodes under /dev/mapper on it's own, instead of relying on
>> udev for doing so.
>> Looking in the logs, I've found:
>>
>> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
>> 3600508b4000cf1c300008000002b0000 NF [16384] (*1)
>> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1689): Cookie
>> value is not set while trying to call DM_DEVICE_RESUME ioctl.
>> Please, consider using libdevmapper's udev synchronisation interface
>> or disable it explicitly by calling dm_udev_set_sync_support(0).
>> Jun 29 15:15:05 | libdevmapper: ioctl/libdm-iface.c(1691): Switching
>> off device-mapper and all subsystem related udev rules. Falling back
>> to libdevmapper node creation.
>>
>> Okay, that'll explain it.
>> Then I've added a cookie to the call of DM_DEVICE_RELOAD, and
>> encountered a hang:
>> Jun 29 15:41:55 | 3600508b1001047395656543131580001: addmap [0
>> 143305920 multipath 1 queue_if_no_path 0 1 1 service-time 0 1 1 104:0 1]
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2105): Udev cookie
>> 0xd4d7246 (semid 6062098) created
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2125): Udev cookie
>> 0xd4d7246 (semid 6062098) incremented to 1
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(1997): Udev cookie
>> 0xd4d7246 (semid 6062098) incremented to 2
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2238): Udev cookie
>> 0xd4d7246 (semid 6062098) assigned to RELOAD task(1) with flags
>> DISABLE_LIBRARY_FALLBACK (0x20)
>> Jun 29 15:41:55 | libdevmapper: ioctl/libdm-iface.c(1725): dm reload
>> 3600508b1001047395656543131580001 NNS [16384] (*1)
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2032): Udev cookie
>> 0xd4d7246 (semid 6062098) decremented to 1
>> Jun 29 15:41:55 | libdevmapper: libdm-common.c(2288): Udev cookie
>> 0xd4d7246 (semid 6062098) waiting for zero
>> (hangs)
>>
>> So apparently you can only set the cookie for DM_DEVICE_RESUME,
>> _not_ DM_DEVICE_RELOAD.
>>
>> Which is odd, as DM_DEVICE_RELOAD is the only call I'll ever do;
>> apparently it's being translated internally into a
>> suspend/reload/resume cycle.
>>
>> Shouldn't device-mapper take care of setting the cookie correctly?
>
> This is really a question for the lvm2 developers (Alasdair and Peter
> Rajnoha specifically, cc'd).
Actually, we don't check proper combination of dm_task_set_cookie with
dm task type. So currently, if someone sets cookie on a task that does
not produce uevents, it can hang if dm_udev_wait is called for such cookie.
I've noticed we have a FIXME in the code for this already, but clearly
nobody has run into this issue yet. I'll add the check!
As for the DM_DEVICE_RELOAD - yes, it needs DM_DEVICE_RESUME to be called
right after the reload for the new table to be used (and hence the uevent
with the cookie generated as well). If you call RELOAD, the inactive
table is loaded which is then switched to active with the RESUME.
The task that is transparently translated into 3 tasks internally is the
DM_DEVICE_CREATE (with table) which translates into CREATE + LOAD + RESUME.
Anyway, yes, the check whether cookie is not misused is not there yet, so
that's why you hit this.
--
Peter
^ permalink raw reply [flat|nested] 9+ messages in thread
* udev cookie on DM_DEVICE_RELOAD
2015-06-29 14:49 ` Peter Rajnoha
(?)
@ 2015-06-29 14:56 ` Hannes Reinecke
2015-06-29 15:01 ` Peter Rajnoha
-1 siblings, 1 reply; 9+ messages in thread
From: Hannes Reinecke @ 2015-06-29 14:56 UTC (permalink / raw)
To: lvm-devel
On 06/29/2015 04:49 PM, Peter Rajnoha wrote:
[ .. ]
>
> Actually, we don't check proper combination of dm_task_set_cookie with
> dm task type. So currently, if someone sets cookie on a task that does
> not produce uevents, it can hang if dm_udev_wait is called for such cookie.
>
> I've noticed we have a FIXME in the code for this already, but clearly
> nobody has run into this issue yet. I'll add the check!
>
> As for the DM_DEVICE_RELOAD - yes, it needs DM_DEVICE_RESUME to be called
> right after the reload for the new table to be used (and hence the uevent
> with the cookie generated as well). If you call RELOAD, the inactive
> table is loaded which is then switched to active with the RESUME.
>
> The task that is transparently translated into 3 tasks internally is the
> DM_DEVICE_CREATE (with table) which translates into CREATE + LOAD + RESUME.
>
> Anyway, yes, the check whether cookie is not misused is not there yet, so
> that's why you hit this.
>
So how to circumvent this?
Should I do an explicit
SUSPEND/RELOAD/RESUME call sequence and add a cookie on the final
resume?
Or is it sufficient to call RESUME after RELOAD without suspending
first? Or another magic trick?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare at suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: F. Imend?rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply [flat|nested] 9+ messages in thread
* udev cookie on DM_DEVICE_RELOAD
2015-06-29 14:56 ` Hannes Reinecke
@ 2015-06-29 15:01 ` Peter Rajnoha
2015-06-29 15:10 ` Alasdair G Kergon
0 siblings, 1 reply; 9+ messages in thread
From: Peter Rajnoha @ 2015-06-29 15:01 UTC (permalink / raw)
To: lvm-devel
On 06/29/2015 04:56 PM, Hannes Reinecke wrote:
> On 06/29/2015 04:49 PM, Peter Rajnoha wrote:
> [ .. ]
>>
>> Actually, we don't check proper combination of dm_task_set_cookie with
>> dm task type. So currently, if someone sets cookie on a task that does
>> not produce uevents, it can hang if dm_udev_wait is called for such cookie.
>>
>> I've noticed we have a FIXME in the code for this already, but clearly
>> nobody has run into this issue yet. I'll add the check!
>>
>> As for the DM_DEVICE_RELOAD - yes, it needs DM_DEVICE_RESUME to be called
>> right after the reload for the new table to be used (and hence the uevent
>> with the cookie generated as well). If you call RELOAD, the inactive
>> table is loaded which is then switched to active with the RESUME.
>>
>> The task that is transparently translated into 3 tasks internally is the
>> DM_DEVICE_CREATE (with table) which translates into CREATE + LOAD + RESUME.
>>
>> Anyway, yes, the check whether cookie is not misused is not there yet, so
>> that's why you hit this.
>>
> So how to circumvent this?
> Should I do an explicit
> SUSPEND/RELOAD/RESUME call sequence and add a cookie on the final
> resume?
> Or is it sufficient to call RESUME after RELOAD without suspending
> first? Or another magic trick?
suspend -> reload -> dm_task_set_cookie -> resume -> dm_udev_wait
should be the proper sequence.
The reload never translates internally into more tasks...
Can you point me to the exact code you're trying to edit?
--
Peter
^ permalink raw reply [flat|nested] 9+ messages in thread
* udev cookie on DM_DEVICE_RELOAD
2015-06-29 15:01 ` Peter Rajnoha
@ 2015-06-29 15:10 ` Alasdair G Kergon
0 siblings, 0 replies; 9+ messages in thread
From: Alasdair G Kergon @ 2015-06-29 15:10 UTC (permalink / raw)
To: lvm-devel
On Mon, Jun 29, 2015 at 05:01:07PM +0200, Peter Rajnoha wrote:
> suspend -> reload -> dm_task_set_cookie -> resume -> dm_udev_wait
Or rather,
set cookie -> reload -> suspend -> resume -> wait
Reload can fail and allocates kernel resources, and suspend ties up kernel
resources so as little as possible should be done between the suspend
and the resume.
Alasdair
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udev cookie on DM_DEVICE_RELOAD
2015-06-29 13:46 udev cookie on DM_DEVICE_RELOAD Hannes Reinecke
2015-06-29 14:02 ` Mike Snitzer
@ 2015-06-29 14:45 ` Alasdair G Kergon
1 sibling, 0 replies; 9+ messages in thread
From: Alasdair G Kergon @ 2015-06-29 14:45 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: device-mapper development
On Mon, Jun 29, 2015 at 03:46:04PM +0200, Hannes Reinecke wrote:
> So apparently you can only set the cookie for DM_DEVICE_RESUME,
> _not_ DM_DEVICE_RELOAD.
There are various alternative modes of operation to choose between.
It is essential to pick one and use it consistently alongside
the corresponding udev rules. These sorts of problems arise when
switching between different modes, whether deliberately or otherwise.
> Which is odd, as DM_DEVICE_RELOAD is the only call I'll ever do;
> apparently it's being translated internally into a
> suspend/reload/resume cycle.
I didn't think that one got translated internally.
Please point to the actual source code that's causing the problems,
and say which versions of the udev rules (and libdevmapper and kernel
driver) were installed when getting the errors.
Alasdair
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-06-29 15:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-29 13:46 udev cookie on DM_DEVICE_RELOAD Hannes Reinecke
2015-06-29 14:02 ` Mike Snitzer
2015-06-29 14:02 ` Mike Snitzer
2015-06-29 14:49 ` Peter Rajnoha
2015-06-29 14:49 ` Peter Rajnoha
2015-06-29 14:56 ` Hannes Reinecke
2015-06-29 15:01 ` Peter Rajnoha
2015-06-29 15:10 ` Alasdair G Kergon
2015-06-29 14:45 ` Alasdair G Kergon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.