On 02/20/2016 04:16 PM, Bart Van Assche wrote:
On 02/20/16 00:03, Hannes Reinecke wrote:
Also when using your suggestion the 'access_state' attribute will only
be created _after_ the 'ADD' uevent, making it impossible to use it from
udev events.
Can you give an example in which it would be use
https://bugzilla.kernel.org/show_bug.cgi?id=111441
--- Comment #16 from Serguei Bezverkhi ---
Hi Mike,
I just wanted to follow up with you to see if the patch got committed to an
upstream kernel if yes, please let me into which version it went.
Thank you
Serguei
Serguei Bezverkhi,
TECHNICAL
Hi Mike,
I just wanted to follow up with you to see if the patch got committed to an
upstream kernel if yes, please let me into which version it went.
Thank you
Serguei
Serguei Bezverkhi,
TECHNICAL LEADER.SERVICES
Global SP Services
sbezv...@cisco.com
Phone: +1 416 306 7312
Mobile: +1 514 234
Hi Oliver,
sure, we'll fix it at the next patch version. Thank you.
Charles
On 02/04/2016 07:37 PM, Oliver Neukum wrote:
On Thu, 2016-02-04 at 19:22 +0800, Charles Chiou wrote:
+static int stex_choice_sleep_mic(pm_message_t state)
+{
+switch (state.event) {
+case PM_EVENT_SUSPEND:
+
> "Hannes" == Hannes Reinecke writes:
Hannes> Martin, can you please ignore patches 20-22 when pulling the
Hannes> patchset? I'll be resubmitting a new patchset with them once
Hannes> these issues are sorted out. Or do you need a new patch
Hannes> submission?
No, it's OK. I'll merge the fi
On 02/21/16 00:27, Hannes Reinecke wrote:
On 02/20/2016 04:16 PM, Bart Van Assche wrote:
On 02/20/16 00:03, Hannes Reinecke wrote:
Also when using your suggestion the 'access_state' attribute will only
be created _after_ the 'ADD' uevent, making it impossible to use it from
udev events.
Can y
On 02/22/2016 05:45 AM, Bart Van Assche wrote:
> On 02/21/16 00:27, Hannes Reinecke wrote:
>> On 02/20/2016 04:16 PM, Bart Van Assche wrote:
>>> On 02/20/16 00:03, Hannes Reinecke wrote:
Also when using your suggestion the 'access_state' attribute will only
be created _after_ the 'ADD' ue
https://bugzilla.kernel.org/show_bug.cgi?id=111441
--- Comment #17 from Hannes Reinecke ---
On 02/22/2016 01:45 AM, Serguei Bezverkhi (sbezverk) wrote:
> Hi Mike,
>
> I just wanted to follow up with you to see if the patch got committed to an
> upstream kernel if yes, please let me into which v
On 02/22/2016 01:45 AM, Serguei Bezverkhi (sbezverk) wrote:
> Hi Mike,
>
> I just wanted to follow up with you to see if the patch got committed to an
> upstream kernel if yes, please let me into which version it went.
>
> Thank you
>
> Serguei
>
>
> Serguei Bezverkhi,
> TECHNICAL LEADER.SERV
On larger installations it makes sense to disable the target scan
per default on boot, and scan the required LUNs directly via udev
rules.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi_transport_fc.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/dr
Hi all,
having been subjected to the pain of trying to bootstrap a really
large machine with systemd I decided to implement LUN masking in
scsi_transport_fc.
The principle is simple: disallow the automated LUN scanning when
discovering a rport, and create udev rules which selectively
enable indivi
When invoking a scan via the sysfs 'scan' attribute the process
will be blocked until the scan is completed, which can take a
very long time on large installations.
Enabling the 'async_user_scan' parameter moves the actual
LUN scanning to a workqueue, thereby unblocking the process.
Signed-off-by:
12 matches
Mail list logo
