On Tue, Feb 11, 2014 at 03:34:53PM +0100, Hannes Reinecke wrote:
> Instead of modifying attributes after the device has been created
> we should be using the 'is_visible' callback to avoid races.
Can't say I like the fact that the is_visible function needs is
per-group and not per attribute and th
On 02/12/2014 08:45 AM, Christoph Hellwig wrote:
> On Tue, Feb 11, 2014 at 03:29:10PM +0100, Hannes Reinecke wrote:
>> Well, _actually_ the cancel_delayed_work should be pointless; I've
>> just added it as a terminal measure here.
>> (It'd actually be an idea to insert a BUG_ON() here ...)
>>
>> Th
On Tue, Feb 11, 2014 at 03:29:10PM +0100, Hannes Reinecke wrote:
> Well, _actually_ the cancel_delayed_work should be pointless; I've
> just added it as a terminal measure here.
> (It'd actually be an idea to insert a BUG_ON() here ...)
>
> Thing is whenever the eh_timeout thingie kicks in we most
I can report that the Samsung 840 Pro *does* support trim on the LSI
SAS2008. As suspected it supports deterministic read zeros after trim.
One other thing to note, in my testing the P16 LSI firmware has broken
trim support. P14 and P15 report incorrect values for
/sys/block/sdX/queue/discard_gran
https://bugzilla.kernel.org/show_bug.cgi?id=70271
Maurizio Lombardi changed:
What|Removed |Added
CC||mlomb...@redhat.com
--- Comment #1 fr
When copying the st_modedef structures the devs pointers must be preserved
in the same way as with the cdevs pointers.
This fixes bug 70271: https://bugzilla.kernel.org/show_bug.cgi?id=70271
[ 135.037052] BUG: unable to handle kernel NULL pointer dereference at
0098
[ 135.045048] I
We must use a 64-bit for this, otherwise overflowed bits get lost, and
that can result in a lower than intended value set.
Fixes: 8e0cb8a1f6ac ("ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for
bounce_limit calculations")
Fixes: 7d35496dd982 ("ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for
On 2/11/2014 2:32 AM, Hannes Reinecke wrote:
> The problem with page 0x80 is that (per spec) it's vendor-defined. So there
> is no guarantee for it to be unique in any sense. Which makes it rather
> impractical for normal use.
>
> Hence we typically rely on page 0x83 to identify a device, be it fo
The original code always set the upper 32 bits to zero because it was
doing a shift of the wrong variable.
Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other
fixes')
Signed-off-by: Dan Carpenter
---
v3: In v2 I introduced an expensive cast to solve a static checker
war
On Tue, Feb 11 2014, Christoph Hellwig wrote:
> Hi Jens,
>
> seems like with the SCSI work I introduced the first
> BLK_MQ_RQ_QUEUE_ERROR error return in the tree, and immediately ran into
> the first pitfall. The code as-is expects rq->errors set to an error
> value, which otherwise is an inter
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 11, 2014 at 06:42:40AM -0800, James Bottomley wrote:
> > Unfortunately that's not true in SCSI land, where most driver do per-lun
> > tagging, and the the cmd_per_lun values are very low and very often
> > single digits, as a simple grep for cmd_per_lun will tell.
>
> Remember we do sh
On Tue, 2014-02-11 at 01:12 -0800, Christoph Hellwig wrote:
> On Mon, Feb 10, 2014 at 04:06:27PM -0700, Jens Axboe wrote:
> > For the common case, I'd assume that anywhere between 31..256 tags
> > is "normal". That's where the majority of devices will end up being,
> > largely. So single digits wou
Instead of modifying attributes after the device has been created
we should be using the 'is_visible' callback to avoid races.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi_sysfs.c | 195 --
1 file changed, 102 insertions(+), 93 deletions(-)
di
Hi all,
here's now the (hopefully) final version of my patch to display
EVPD pages in sysfs. After some discussion with Kay Sievers I've
found that the whole thing can be made far simpler by using the
'is_visible' callback to the sysfs attribute group.
And we can even simplify existing code here.
EVPD page 0x83 is used to uniquely identify the device.
So instead of having each and every program issue a separate
SG_IO call to retrieve this information it does make far more
sense to display it in sysfs.
The page is displayed in its entirety with the attribute
'vpd_pg83', and the individual de
On 02/11/2014 03:01 PM, Christoph Hellwig wrote:
> Hi Hannes,
>
> I'll need a little reminder how we came to the conclusion that the
> cancel_delayed_work in scsi_put_command was safe and we didn't need
> a cancel_delayed_work_sync or flush_delayed_work. I remember we had
> that discussion, but i
Hi Hannes,
I'll need a little reminder how we came to the conclusion that the
cancel_delayed_work in scsi_put_command was safe and we didn't need
a cancel_delayed_work_sync or flush_delayed_work. I remember we had
that discussion, but it seems that same doesn't apply to the equivalent
call in the
Hi Jim,
On Fri, Feb 07, 2014 at 05:32:44PM +, Jim Malina wrote:
>
>
> > -Original Message-
> > From: Hannes Reinecke [mailto:h...@suse.de]
> > Sent: Friday, February 07, 2014 5:46 AM
> > To: Carlos Maiolino; Albert Chen
> > Cc: lsf...@lists.linux-foundation.org; James Borden; Jim Mal
EVPD page 0x83 is used to uniquely identify the device.
So instead of having each and every program issue a separate
SG_IO call to retrieve this information it does make far more
sense to display it in sysfs.
Cc: Jeremy Linton
Cc: Doug Gilbert
Cc: Kai Makisara
Signed-off-by: Hannes Reinecke
--
EVPD page 0x83 is used to uniquely identify the device.
So instead of having each and every program issue a separate
SG_IO call to retrieve this information it does make far more
sense to display it in sysfs.
The page is displayed in its entirety with the attribute
'vpd_pg83', and the individual de
On 02/10/2014 08:06 PM, Douglas Gilbert wrote:
> On 14-02-10 01:06 PM, Jeremy Linton wrote:
>> On 2/10/2014 5:11 AM, Hannes Reinecke wrote:
>>> EVPD page 0x83 is used to uniquely identify the device. So
>>> instead of
>>> having each and every program issue a separate SG_IO call to
>>> retrieve thi
Hi Jens,
seems like with the SCSI work I introduced the first
BLK_MQ_RQ_QUEUE_ERROR error return in the tree, and immediately ran into
the first pitfall. The code as-is expects rq->errors set to an error
value, which otherwise is an internal field used by the block layer and
some drivers, but no
On Mon, Feb 10, 2014 at 04:06:27PM -0700, Jens Axboe wrote:
> For the common case, I'd assume that anywhere between 31..256 tags
> is "normal". That's where the majority of devices will end up being,
> largely. So single digits would be an anomaly.
Unfortunately that's not true in SCSI land, where
On 02/10/2014 07:06 PM, Jeremy Linton wrote:
> On 2/10/2014 5:11 AM, Hannes Reinecke wrote:
>> EVPD page 0x83 is used to uniquely identify the device. So instead of
>> having each and every program issue a separate SG_IO call to retrieve this
>> information it does make far more sense to display it
25 matches
Mail list logo
