https://bugzilla.kernel.org/show_bug.cgi?id=96631
Bug ID: 96631
Summary: after Updating kernel ,system failed to boot
Product: SCSI Drivers
Version: 2.5
Kernel Version: kernel-ml-3.19.2-1.el7.elrepo.x86_64
Hardware: All
OS
Hi Hannes,
Thank you for reviewing patches. Please find responses inline.
On 13/04/15 7:59 pm, "Hannes Reinecke" wrote:
>On 04/13/2015 07:25 AM, Narsimhulu Musini (nmusini) wrote:
>> Hi Hannes,
>>
>> Thank you for reviewing patches. Please find responses inline.
>>
>>
>>
>> On 09/04/15
Changes from V7:
Fix handling of copy_from_user() result in case of incomplete copy in
ufshcd_query_ioctl().
Fix ufs-debugfs build in case UFS is configured as a loadable kernel module.
Dolev Raviv (1):
scsi: ufs: add ioctl interface for query request
Gilad Broner (1):
scsi: ufs: add trace e
From: Dolev Raviv
This patch exposes the ioctl interface for UFS driver via SCSI device
ioctl interface. As of now UFS driver would provide the ioctl for query
interface to connected UFS device.
Signed-off-by: Dolev Raviv
Signed-off-by: Noa Rubens
Signed-off-by: Raviv Shvili
Signed-off-by: Ya
From: Lee Susman
Adding debugfs capability for ufshcd.
debugfs attributes introduced in this patch:
- View driver/controller runtime data
- Command tag statistics for performance analisis
- Dump device descriptor info
- Track recoverable errors statistics during runtime
- Change UFS power m
Add trace events to driver to allow monitoring and profilig
of activities such as PM suspend/resume, hibernate enter/exit,
clock gating and clock scaling up/down.
In addition, add UFS host controller register dumps to provide
detailed information in case of errors to assist in analysis
of issues.
2015-02-12 12:35 GMT+09:00 Bjorn Andersson :
> The function regulator_set_optimum_mode() is changing name to
> regulator_set_load(), so update the code accordingly. Also cleaned up
> ufshcd_config_vreg_load() while touching the code.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/scsi/ufs/ufs
2015-04-14 2:19 GMT+09:00 Sagi Grimberg :
> Hey All,
>
> This set follows the patchset from Akinobu Mita that addresses
> DIF bounce buffer sgl construction. Instead of trying to fix these
> bugs, this removes it altogether and work with cmd->t_prot_sg
> directly.
>
> The first patch is a simplific
On Tue, 14 Apr 2015 14:51:21 +0300
Gilad Broner wrote:
> +static const char *ufschd_uic_link_state_to_string(
> + enum uic_link_state state)
> +{
> + switch (state) {
> + case UIC_LINK_OFF_STATE:return "OFF";
> + case UIC_LINK_ACTIVE_STATE: return "ACT
I almost accidentally sent this one again. I still think it's correct.
regards,
dan carpenter
On Mon, Jan 19, 2015 at 05:41:12PM +0300, Dan Carpenter wrote:
> If device_add() fails then it should return the error code but instead
> the current code returns success.
>
> Signed-off-by: Dan Carpen
We should return -ENOMEM if kzalloc() fails here instead of returning
success.
Signed-off-by: Dan Carpenter
diff --git a/drivers/scsi/csiostor/csio_hw.c b/drivers/scsi/csiostor/csio_hw.c
index 2e66f34..622bdab 100644
--- a/drivers/scsi/csiostor/csio_hw.c
+++ b/drivers/scsi/csiostor/csio_hw.c
@@
When I set up a DIX enabled device for the first time (say
scsi_debug) it all works, but when I remove it
and set it up again I get the below crash:
Reproducer:
$modprobe scsi_debug dif=1 dix=1
$modprobe -r scsi_debug
$modprobe scsi_debug dif=1 dix=1
It seems that somehow bdi_destroy() is not
in
On Sat, Apr 11, 2015 at 09:04:02AM -0400, Jeff Layton wrote:
> Yuck! How the heck do you clean up the mess if that happens? I guess
> you're just stuck redoing the copy with normal READ/WRITE?
>
> Maybe we need to have the interface return a hard error in that
> case and not try to give back any s
I have a pair of test machines in the new Xen Project test colo which
do not detect their disk with the 3.14.* kernel branch we are using.
The machines are based on a Gigabyte motherboard with an Intel C600
storage controller. Debian's 3.2.0-4 (i386 or amd64) detects the
controller and its disks
On Tue, Apr 14, 2015 at 09:53:44AM -0700, Christoph Hellwig wrote:
> On Sat, Apr 11, 2015 at 09:04:02AM -0400, Jeff Layton wrote:
> > Yuck! How the heck do you clean up the mess if that happens? I guess
> > you're just stuck redoing the copy with normal READ/WRITE?
> >
> > Maybe we need to have th
On 04/10/2015 06:00 PM, Zach Brown wrote:
> This rearranges the existing COPY_RANGE ioctl implementation so that the
> .copy_file_range file operation can call the core loop that copies file
> data extent items.
>
> The extent copying loop is lifted up into its own function. It retains
> the core
On 4/14/2015 3:17 PM, Akinobu Mita wrote:
2015-04-14 2:19 GMT+09:00 Sagi Grimberg :
Hey All,
This set follows the patchset from Akinobu Mita that addresses
DIF bounce buffer sgl construction. Instead of trying to fix these
bugs, this removes it altogether and work with cmd->t_prot_sg
directly.
On 04/14/2015 12:53 PM, Christoph Hellwig wrote:
> On Sat, Apr 11, 2015 at 09:04:02AM -0400, Jeff Layton wrote:
>> Yuck! How the heck do you clean up the mess if that happens? I guess
>> you're just stuck redoing the copy with normal READ/WRITE?
>>
>> Maybe we need to have the interface return a ha
On 15-04-14 06:52 PM, Sagi Grimberg wrote:
When I set up a DIX enabled device for the first time (say
scsi_debug) it all works, but when I remove it
and set it up again I get the below crash:
Reproducer:
$modprobe scsi_debug dif=1 dix=1
$modprobe -r scsi_debug
$modprobe scsi_debug dif=1 dix=1
On Tue, 2015-04-14 at 19:52 +0300, Sagi Grimberg wrote:
> When I set up a DIX enabled device for the first time (say
> scsi_debug) it all works, but when I remove it
> and set it up again I get the below crash:
>
> Reproducer:
> $modprobe scsi_debug dif=1 dix=1
> $modprobe -r scsi_debug
> $modprob
> "Sagi" == Sagi Grimberg writes:
Sagi,
Sagi> scsi_debug $modprobe scsi_debug dif=1 dix=1
Sagi> scsi_debug: host protection DIF1 DIX1
Sagi> sd 9:0:0:0: [sdc] Enabling DIF Type 1 protection
This looks odd. dix specifies the host protection mask. A value of 1 is
"DIF Type 1" so DIX should n
On Tue, Apr 14, 2015 at 01:16:13PM -0400, Anna Schumaker wrote:
> On 04/14/2015 12:53 PM, Christoph Hellwig wrote:
> > On Sat, Apr 11, 2015 at 09:04:02AM -0400, Jeff Layton wrote:
> >> Yuck! How the heck do you clean up the mess if that happens? I
> >> guess you're just stuck redoing the copy with
On Tue, Apr 14, 2015 at 02:19:11PM -0400, J. Bruce Fields wrote:
> On Tue, Apr 14, 2015 at 01:16:13PM -0400, Anna Schumaker wrote:
> > On 04/14/2015 12:53 PM, Christoph Hellwig wrote:
> > > On Sat, Apr 11, 2015 at 09:04:02AM -0400, Jeff Layton wrote:
> > >> Yuck! How the heck do you clean up the me
On Tue, Apr 14, 2015 at 11:22:41AM -0700, Zach Brown wrote:
> On Tue, Apr 14, 2015 at 02:19:11PM -0400, J. Bruce Fields wrote:
> > On Tue, Apr 14, 2015 at 01:16:13PM -0400, Anna Schumaker wrote:
> > > On 04/14/2015 12:53 PM, Christoph Hellwig wrote:
> > > > On Sat, Apr 11, 2015 at 09:04:02AM -0400,
On Tue, Apr 14, 2015 at 02:29:06PM -0400, J. Bruce Fields wrote:
> On Tue, Apr 14, 2015 at 11:22:41AM -0700, Zach Brown wrote:
> > On Tue, Apr 14, 2015 at 02:19:11PM -0400, J. Bruce Fields wrote:
> > > On Tue, Apr 14, 2015 at 01:16:13PM -0400, Anna Schumaker wrote:
> > > > On 04/14/2015 12:53 PM, C
On Tue, Apr 14, 2015 at 11:54:08AM -0700, Zach Brown wrote:
> Is this relying on btrfs range cloning being atomic? It certainly
> doesn't look atomic. It can modify items across an arbitrarily large
> number of leaf blocks. It can make the changes across multiple
> transactions which could intro
On Tue, Apr 14, 2015 at 12:23:25PM -0700, Christoph Hellwig wrote:
> On Tue, Apr 14, 2015 at 11:54:08AM -0700, Zach Brown wrote:
> > Is this relying on btrfs range cloning being atomic? It certainly
> > doesn't look atomic. It can modify items across an arbitrarily large
> > number of leaf blocks
The new integrity code did not correctly unregister the profile for SD
disks. Call blk_integrity_unregister() when we release a disk.
Signed-off-by: Martin K. Petersen
Reported-by: Sagi Grimberg
CC: sta...@vger.kernel.org # v3.17+
---
drivers/scsi/sd.c | 1 +
1 file changed, 1 insertion(+)
dif
To make a very long debugging story short, I think there is an issues/bug
with the mvsas driver. It works, with older kernels, and breaks on
newer kernels.
My Debian Jessie system was running great on a 3.18 kernel. Changed
cases to a newer supermicro case with a SAS expander backplane (SAS933EL)
3aec2f41a8bae introduced a merge error where we would end up check for
sdkp instead of sdkp->ATO. Fix this so we register app tag capability
correctly.
Signed-off-by: Martin K. Petersen
Cc: # v3.17+
---
drivers/scsi/sd_dif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dr
On Tue, 2015-04-14 at 14:03 -0700, Adam Talbot wrote:
> To make a very long debugging story short, I think there is an issues/bug
> with the mvsas driver. It works, with older kernels, and breaks on
> newer kernels.
>
> My Debian Jessie system was running great on a 3.18 kernel. Changed
> cases t
Removing the sas expander and attaching the SATA drives directly works
just fine. I had to limp along with the drives direct attached for a
while, while debugging.
Here is the dump from: Linux version 3.15.1-031501-generic. Just tested it.
[8.455203] scsi4 : mvsas
[8.663885] floppy0: no f
Any chance you can capture a vmcore (kernel only pages), I will
provide an upload location.
Thanks
Laurence
On Tue, Apr 14, 2015 at 5:16 PM, James Bottomley
wrote:
> On Tue, 2015-04-14 at 14:03 -0700, Adam Talbot wrote:
>> To make a very long debugging story short, I think there is an issues/bug
James Smart wrote:
>
> Fix provide host name and OS name in RSNN-NN FC-GS command
>
> Signed-off-by: Dick Kennedy
> Signed-off-by: James Smart
> ---
> drivers/scsi/lpfc/lpfc_ct.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/lpfc/
We recently started to get
[8043768.238110] lpfc :10:00.1: 1:(0):0115 Unknown ELS command x18 received
from NPORT xfffc2b
[8130462.560283] lpfc :10:00.1: 1:(0):0115 Unknown ELS command x18 received
from NPORT xfffc2b
[8216439.442882] lpfc :10:00.1: 1:(0):0115 Unknown ELS command x18
2015-04-15 2:20 GMT+09:00 Sagi Grimberg :
> On 4/14/2015 3:17 PM, Akinobu Mita wrote:
>>
>> 2015-04-14 2:19 GMT+09:00 Sagi Grimberg :
>>>
>>> Hey All,
>>>
>>> This set follows the patchset from Akinobu Mita that addresses
>>> DIF bounce buffer sgl construction. Instead of trying to fix these
>>> bu
On 04/12/2015 07:17 AM, Sebastian Herbszt wrote:
Add target hooks.
Signed-off-by: Sebastian Herbszt
+#ifdef LPFC_TARGET_MODE
+#include "lpfc_target_api.h"
+#include "lpfc_target_api_base.h"
+#endif
Hi, great to see new fabrics posted.
There are a great many ifdefs like this. Are they stri
37 matches
Mail list logo
