linux-kernel - RE: [patch 2/4] scsi: expose AN support to user space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 15 Aug 2007 17:37:45 -0600
From:	"Moore, Eric" <Eric.Moore@....com>
To:	"James Bottomley" <James.Bottomley@...elEye.com>,
	"Jeff Garzik" <jeff@...zik.org>
Cc:	"Kristen Carlson Accardi" <kristen.c.accardi@...el.com>,
	<linux-ide@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <akpm@...ux-foundation.org>,
	<venkatr@...mise.com>, <vimal.nakum@...mise.com>
Subject: RE: [patch 2/4] scsi: expose AN support to user space

On Wednesday, August 15, 2007 8:02 AM, James Bottomley wrote: 
> Actually, we just got a second potential consumer ... although I'll
> reprod to have the reporter send it to the list.  It's a device that
> needs notice of report luns data changing.  The proposed 
> mechanism looks
> a bit narrow now (too tied to media change).  I'll see if I 
> can propose
> a more generic update.
> 

I believe James is referring to my Promise issue. That is -  the
customers mutipath enclosure our SAS controller.  They have alternating
luns mapped to each path.  The odd luns mapped to a single path, and the
even luns to the other.  When a cable is pulled, a check condition is
generated (0x6, 0x3F, 0xE),  means report_luns data has changed.  What
the enclosure does it move the luns over to the alternate path.    Our
driver is not reporting the new luns because no event is generated to
mpt fusion driver from controller firmware (firmware only reports when a
target has been added/removed, not lun).     The mpt fusion driver
reports to the sas transport layer, the libata layer is not involved.
Shouldn't someone above sscsi lld be snooping that sence, and then
sending REPORT_LUNS to find out what changed.       

I've added some Promise contacts,  I hope they include the interested
partied to this discussion.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/