er.kernel.org; James
>> Bottomley; Jeremy Linton; Elliott, Robert (Server Storage); Bart Van Assche;
>> Bud Brown
>> Subject: Re: [PATCH 0/4] scsi: 64-bit LUN support
>>
>> On 04/08/2013 05:37 PM, Tomas Henzl wrote:
>>> On 04/05/2013 05:24 PM, James Smart wrote:
&
Van Assche;
> Bud Brown
> Subject: Re: [PATCH 0/4] scsi: 64-bit LUN support
>
> On 04/08/2013 05:37 PM, Tomas Henzl wrote:
> > On 04/05/2013 05:24 PM, James Smart wrote:
> >>
> >> On 4/4/2013 6:17 AM, Hannes Reinecke wrote:
> >>> On 03/31/2013 07:44 PM,
On 04/08/2013 05:37 PM, Tomas Henzl wrote:
> On 04/05/2013 05:24 PM, James Smart wrote:
>>
>> On 4/4/2013 6:17 AM, Hannes Reinecke wrote:
>>> On 03/31/2013 07:44 PM, Tomas Henzl wrote:
What we can do is to decode the LUN and compare it to max_lun provided by
the driver,
I think that
On 04/05/2013 05:24 PM, James Smart wrote:
>
> On 4/4/2013 6:17 AM, Hannes Reinecke wrote:
>> On 03/31/2013 07:44 PM, Tomas Henzl wrote:
>>> What we can do is to decode the LUN and compare it to max_lun provided by
>>> the driver,
>>> I think that sg_luns is able to do that, so what is needed is j
On 04/05/2013 05:24 PM, James Smart wrote:
>
> On 4/4/2013 6:17 AM, Hannes Reinecke wrote:
>> On 03/31/2013 07:44 PM, Tomas Henzl wrote:
>>> What we can do is to decode the LUN and compare it to max_lun
>>> provided by the driver,
>>> I think that sg_luns is able to do that, so what is needed is
>
On 4/4/2013 6:17 AM, Hannes Reinecke wrote:
On 03/31/2013 07:44 PM, Tomas Henzl wrote:
What we can do is to decode the LUN and compare it to max_lun provided by the
driver,
I think that sg_luns is able to do that, so what is needed is just to follow
the SAM.
I have seen reports of problem on
On 03/31/2013 07:44 PM, Tomas Henzl wrote:
> On 03/30/2013 05:53 PM, Hannes Reinecke wrote:
>> On 03/29/2013 05:32 PM, Tomas Henzl wrote:
[ .. ]
>>>
>>> in scsi_report_lun_scan is max_lun compared with the result of
>>> scsilun_to_int,
>>> but in that value is also stored the address method. This
On 03/30/2013 05:53 PM, Hannes Reinecke wrote:
> On 03/29/2013 05:32 PM, Tomas Henzl wrote:
>> On 03/27/2013 08:37 AM, Hannes Reinecke wrote:
>>> On 03/26/2013 07:00 PM, Chad Dupuis wrote:
On Tue, 19 Feb 2013, Hannes Reinecke wrote:
> This patchset updates the SCSI midlayer to us
On 03/29/2013 05:32 PM, Tomas Henzl wrote:
On 03/27/2013 08:37 AM, Hannes Reinecke wrote:
On 03/26/2013 07:00 PM, Chad Dupuis wrote:
On Tue, 19 Feb 2013, Hannes Reinecke wrote:
This patchset updates the SCSI midlayer to use 64-bit LUNs
internally.
It eliminates the need to limit the number
On 03/27/2013 08:37 AM, Hannes Reinecke wrote:
> On 03/26/2013 07:00 PM, Chad Dupuis wrote:
>>
>>
>> On Tue, 19 Feb 2013, Hannes Reinecke wrote:
>>
>>> This patchset updates the SCSI midlayer to use 64-bit LUNs
>>> internally.
>>> It eliminates the need to limit the number of LUNs artificially to
>
On Wed, 27 Mar 2013, Hannes Reinecke wrote:
On 03/26/2013 07:00 PM, Chad Dupuis wrote:
On Tue, 19 Feb 2013, Hannes Reinecke wrote:
This patchset updates the SCSI midlayer to use 64-bit LUNs
internally.
It eliminates the need to limit the number of LUNs artificially to
avoid aliasing issue
On 03/26/2013 07:00 PM, Chad Dupuis wrote:
On Tue, 19 Feb 2013, Hannes Reinecke wrote:
This patchset updates the SCSI midlayer to use 64-bit LUNs
internally.
It eliminates the need to limit the number of LUNs artificially to
avoid aliasing issues; the SCSI midlayer can now accept any LUN
pres
On 13-03-26 02:00 PM, Chad Dupuis wrote:
On Tue, 19 Feb 2013, Hannes Reinecke wrote:
This patchset updates the SCSI midlayer to use 64-bit LUNs internally.
It eliminates the need to limit the number of LUNs artificially to
avoid aliasing issues; the SCSI midlayer can now accept any LUN presen
On Tue, 19 Feb 2013, Hannes Reinecke wrote:
This patchset updates the SCSI midlayer to use 64-bit LUNs internally.
It eliminates the need to limit the number of LUNs artificially to
avoid aliasing issues; the SCSI midlayer can now accept any LUN presented
to it.
The LLDD specific settings for
On 13-02-21 11:32 AM, James Bottomley wrote:
On Thu, 2013-02-21 at 16:15 +, Elliott, Robert (Server Storage)
wrote:
Regarding changes like this:
- printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] "
+ printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] "
On 02/21/2013 05:15 PM, Elliott, Robert (Server Storage) wrote:
Regarding changes like this:
- printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] "
+ printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] "
"FCP_ResponseInfo=%08xh\n", ioc->name,
On Thu, 2013-02-21 at 16:15 +, Elliott, Robert (Server Storage)
wrote:
> Regarding changes like this:
> - printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] "
> + printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] "
> "FCP_ResponseInfo=%08xh\n", ioc->name
Regarding changes like this:
- printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] "
+ printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] "
"FCP_ResponseInfo=%08xh\n", ioc->name,
sc->device->host->host_no, sc->device->channel,
18 matches
Mail list logo
