On 05/11/2015 00:06, Brian King wrote:
> On 11/04/2015 07:02 AM, Hannes Reinecke wrote:
>> On 11/04/2015 12:46 PM, Laurent Vivier wrote:
>>>
>>>
>>> On 04/11/2015 12:16, Hannes Reinecke wrote:
On 11/04/2015 11:20 AM, Laurent Vivier wrote:
> QEMU allows until 32 LUNs.
>
> Signed-o
On Thu, Nov 5, 2015 at 6:46 AM, Sinan Kaya wrote:
> The MULDIV macro has been designed for small
> numbers. It emits an overflow warning on 64 bit
> systems. This patch places type casts in the
> parameters to fix the compiler warning.
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/scsi/sg.c | 5
Looks good:
Reviewed-by: Christoph Hellwig
A few things I noticed when looking over this and the previous iterations,
which are more notes for future work than an actual comment on this patch:
- what lock protects ->visible and ->reaped (or previously ->state)?
It seems like the synchroniza
On Wed, Nov 04, 2015 at 02:35:40PM -0800, Bart Van Assche wrote:
> (replying to my own e-mail)
>
> Hello Christoph,
>
> Is it OK for you if I mention you as author of this e-mail ?
I don't care whom this fix is attributed to, but let's get it in:
Reviewed-by: Christoph Hellwig
or
Signed-off-by
On 11/05/2015 12:06 AM, Brian King wrote:
> On 11/04/2015 07:02 AM, Hannes Reinecke wrote:
>> On 11/04/2015 12:46 PM, Laurent Vivier wrote:
>>>
>>>
>>> On 04/11/2015 12:16, Hannes Reinecke wrote:
On 11/04/2015 11:20 AM, Laurent Vivier wrote:
> QEMU allows until 32 LUNs.
>
> Signed-
On 05/11/15 01:38, Wakko Warner wrote:
> I tested on a system with 3 drives. ejecting all drives didn't happen at
> the same time, but I think it's because they are different brands and one
> didn't have a disc in. I did notice the leds coming on about the same time
> though. eject -t on all dri
Hi Jack,
all three patches look fine to me, but it seems like your mailer mangled
the whitespaces.
--
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
commit cff549e4860f ("scsi: proper state checking and module refcount
handling in scsi_device_get")
, the reference count of scsi device was changed, which could lead to when
rmmod with at least on drive attached, SCSI error handle will
run into infinite loop, and lockup the system.
Fix it by remo
commit cff549e4860f ("scsi: proper state checking and module refcount
handling in scsi_device_get")
the reference count of scsi device was changed, which could lead to
when rmmod with at least on drive attached, SCSI error handle will
run into infinite loop, and lockup the system.
Fix it by remove
commit cff549e4860f ("scsi: proper state checking and module refcount
handling in scsi_device_get")
the reference count of scsi device was changed, which could lead to
when rmmod with at least on drive attached, SCSI error handle will
run into infinite loop, and lockup the system.
Fix it by remov
Hi Christoph,
On Thu, Nov 5, 2015 at 11:23 AM, Christoph Hellwig wrote:
> Hi Jack,
>
> all three patches look fine to me, but it seems like your mailer mangled
> the whitespaces.
Thanks, I've resend with git send-email.
Sorry for inconvenient.
--
Mit freundlichen Grüßen,
Best Regards,
Jack Wa
Looks good,
Reviewed-by: Christoph Hellwig
--
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
Looks good,
Reviewed-by: Christoph Hellwig
--
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
Looks good,
Reviewed-by: Christoph Hellwig
--
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 11/5/2015 3:48 AM, Andy Shevchenko wrote:
On Thu, Nov 5, 2015 at 6:46 AM, Sinan Kaya wrote:
The MULDIV macro has been designed for small
numbers. It emits an overflow warning on 64 bit
systems. This patch places type casts in the
parameters to fix the compiler warning.
Signed-off-by: Sina
Sinan Kaya wrote:
>
>
> #define MULDIV(X,MUL,DIV)mult_frac64(X, MUL, DIV)
Why bother with the macro at all? Just change the code to use do_div()
directly. It's possible that the original code was written before
do_div() became standard, or the developer didn't know about, which is
why we h
Don:
Thanks for not redefining HPSA_PERF_ERROR_BITS.
Reviewed-by: Manoj Kumar
---
Manoj Kumar
On 11/4/2015 3:50 PM, Don Brace wrote:
This function is no longer used.
Reviewed-by: Tomas Henzl
Reviewed-by: Hannes Reinecke
Signed-off-by: Don Brace
---
drivers/scsi/hpsa.c | 11 +-
On Thu, 5 Nov 2015, kbuild test robot wrote:
> Hi Alan,
>
> First bad commit (maybe != root cause):
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
> head: a34a7cb8a7905606206559cd8d6605e5a72028e9
> commit: b704f70ce2003c8046d5c0128303aeeb0d93d890 [22/23] SCS
Signed-off-by: Sumit Saxena
---
drivers/scsi/megaraid/megaraid_sas_fusion.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 72c731d..bdc2606 100644
--- a/drivers/scsi/megarai
Sumit Saxena (2):
megaraid_sas: Fix TAPE drive not exposed attached to PERC5 controller
megaraid_sas: Fix sparse warning
drivers/scsi/megaraid/megaraid_sas.h|1 +
drivers/scsi/megaraid/megaraid_sas_base.c | 20 +---
drivers/scsi/megaraid/megaraid_sas_fusion.c |
DELL PERC5 controller's(device ID- 0x0015) firmware does not expose TAPE drives
to driver in response of DCMD- MR_DCMD_PD_LIST_QUERY and it causes TAPE drives
not be
exposed to OS when connected behind PERC5 controller. This patch will unblock
scanning of TAPE drives connected behind PERC5 contr
Reviewed-by: Matthew R. Ochs
--
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 Nov 4, 2015, at 3:51 PM, Don Brace wrote:
>
> From: Scott Teel
>
> External array LUNs must use target and lun numbers assigned by the
> external array. So the driver must treat these differently from
> local LUNs when assigning lun/target.
>
> LUN's 'model' field has been used to detect
On Friday 30 October 2015 01:30:40 Tina Ruchandani wrote:
> Function stex_gettime uses 'struct timeval' whose tv_sec value
> will overflow on 32-bit systems in year 2038 and beyond. This patch
> replaces the use of struct timeval and do_gettimeofday with
> ktime_get_real_seconds, which returns a 64
On Friday 30 October 2015 02:11:10 Tina Ruchandani wrote:
> struct mvumi_hs_page2 stores a "seconds_since1970" field which is of
> type u64. It is however, written to, using 'struct timeval' which has
> a 32-bit seconds field and whose value will overflow in year 2038.
> This patch uses ktime_get_r
On Friday 30 October 2015 02:15:26 Tina Ruchandani wrote:
> struct register_host_info stores a 64-bit UTC system time timestamp.
> This patch removes the use of 'struct timeval' to obtain that timestamp
> as its tv_sec value will overflow on 32-bit systems in year 2038 beyond.
> The patch uses ktim
- Original Message -
> This is just a resend of the patchset from earlier today. There was
> a error in the middle of sending the set, so it looks like 10 - 32 got
> dropped.
>
> There are a couple new block layer commands we are trying to add support
> for in the near term:
>
> compare a
On Wed, Nov 4, 2015 at 2:44 PM, James Bottomley
wrote:
[..]
> The fundamental problem with this is how have the conditions that caused
> us to move away from list restart:
>
> commit bc3f02a795d3b4faa99d37390174be2a75d091bd
> Author: Dan Williams
> Date: Tue Aug 28 22:12:10 2012 -0700
>
> [
On Thu, 2015-11-05 at 08:55 -0800, Dan Williams wrote:
> On Wed, Nov 4, 2015 at 2:44 PM, James Bottomley
> wrote:
> [..]
> > The fundamental problem with this is how have the conditions that caused
> > us to move away from list restart:
> >
> > commit bc3f02a795d3b4faa99d37390174be2a75d091bd
> > A
This patch includes a couple of minor fixes, some core changes to help
issues we're still seeing with the suspend/resume code and updates to
lpfc and cxlflash.
We're (actually Martin Petersen is) trying to wrangle a mpt2/mpt3sas
merger for the merge window which will help enormously with the
maint
On 11/04/2015 04:44 PM, Bart Van Assche wrote:
> On 11/04/2015 02:08 PM, mchri...@redhat.com wrote:
>> From: Mike Christie
>>
>> In later patches the op will no longer be a bitmap, so we will
>> not have REQ_WRITE set for all non reads like discard, flush,
>> and write same. Drivers will still wan
On Thu, Nov 5, 2015 at 5:10 PM, Sinan Kaya wrote:
>
>
> On 11/5/2015 3:48 AM, Andy Shevchenko wrote:
>>
>> On Thu, Nov 5, 2015 at 6:46 AM, Sinan Kaya wrote:
>>>
>>> The MULDIV macro has been designed for small
>>> numbers. It emits an overflow warning on 64 bit
>>> systems. This patch places type
On 11/5/2015 1:07 PM, Andy Shevchenko wrote:
OK, I didn't know that we had such a macro. To make this look like the other
>macro, I can do this.
>
>static inline u64 mult_frac64(u64 x, u32 numer, u32 denom)
>{
> u64 quot;
> u64 rem = x % denom;
> u64 rem2;
>
> q
On 11/05/2015 02:51 AM, Hannes Reinecke wrote:
> On 11/05/2015 12:06 AM, Brian King wrote:
>> On 11/04/2015 07:02 AM, Hannes Reinecke wrote:
>>> On 11/04/2015 12:46 PM, Laurent Vivier wrote:
On 04/11/2015 12:16, Hannes Reinecke wrote:
> On 11/04/2015 11:20 AM, Laurent Vivier wrot
On Thu, Nov 5, 2015 at 8:32 PM, Sinan Kaya wrote:
> On 11/5/2015 1:07 PM, Andy Shevchenko wrote:
> Let's try again.
>
> static inline u64 mult_frac64(u64 x, u32 numer, u32 denom) {
> u64 rem = x % denom;
> u64 quot = do_div(x, denom);
> u64 mul = rem * numer;
>
>
On 11/05/2015 10:23 AM, Matthew R. Ochs wrote:
On Nov 4, 2015, at 3:51 PM, Don Brace wrote:
From: Scott Teel
External array LUNs must use target and lun numbers assigned by the
external array. So the driver must treat these differently from
local LUNs when assigning lun/target.
LUN's 'model'
On Thu, Nov 5, 2015 at 9:31 PM, Andy Shevchenko
wrote:
> On Thu, Nov 5, 2015 at 8:32 PM, Sinan Kaya wrote:
>> On 11/5/2015 1:07 PM, Andy Shevchenko wrote:
>
>> Let's try again.
>>
>> static inline u64 mult_frac64(u64 x, u32 numer, u32 denom) {
>> u64 rem = x % denom;
>> u64 quot
On 11/05/2015 02:26 AM, Laurent Vivier wrote:
>
>
> On 05/11/2015 00:06, Brian King wrote:
>> On 11/04/2015 07:02 AM, Hannes Reinecke wrote:
>>> On 11/04/2015 12:46 PM, Laurent Vivier wrote:
On 04/11/2015 12:16, Hannes Reinecke wrote:
> On 11/04/2015 11:20 AM, Laurent Vivier wr
On 11/5/2015 2:56 PM, Andy Shevchenko wrote:
One more look to the users of MULDIV.
They all seems 32 bit for x.
It means you don't need two do_div()s at all.
Just do something like:
u64 d = x * numer;
do_div(d, denom);
return d;
OK. I assume you want a change only in this file.
--
Sinan K
On 09/02/2015 04:48 AM, Hannes Reinecke wrote:
> On 09/02/2015 08:39 AM, Christoph Hellwig wrote:
>> On Tue, Sep 01, 2015 at 02:57:57PM +0200, Hannes Reinecke wrote:
>>
>> It might be a good idea to prioritize that. Todd has been asking
>> for multipath monitoring APIs and suggested adding D-BUS A
James, could you take a look at this? My patch was really incomplete
and even the bits that I wrote were buggy... :/ This might be easier
for someone who is familiar with the code and can say what the expected
ranges are etc.
regards,
dan carpenter
--
To unsubscribe from this list: send the li
On Fri, 2015-11-06 at 00:52 +0300, Dan Carpenter wrote:
> James, could you take a look at this? My patch was really incomplete
> and even the bits that I wrote were buggy... :/ This might be easier
> for someone who is familiar with the code and can say what the expected
> ranges are etc.
Yes,
Hi All,
I'm glad to announce SCST 3.1 pre-release code freeze in the SCST SVN branch
3.0.x.
You can get it by command:
$ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.1.x
It is going to be released after few weeks of testing, if no significant issues
found.
Highlights for t
43 matches
Mail list logo
