When sd_init_command() get's a with a unknown req_op() it crashes the
system via BUG().
This makes debugging the actual reason for the broken request
cmd_flags pretty hard as the system is down before it's able to write
out debugging data on the serial console or the trace buffer.
Change the BUG(
On 9/19/2018 2:26 AM, Evan Green wrote:
On Fri, Sep 14, 2018 at 2:43 AM Sayali Lokhande wrote:
This patch adds configfs support to provision UFS device at
runtime. This feature can be primarily useful in factory or
assembly line as some devices may be required to be configured
multiple times
On 9/21/18 12:01 AM, Johannes Thumshirn wrote:
When sd_init_command() get's a with a unknown req_op() it crashes the
system via BUG().
This makes debugging the actual reason for the broken request
cmd_flags pretty hard as the system is down before it's able to write
out debugging data on the ser
Hi, martin
Can you pick up the patch? Thanks,
Sincerely,
zhong jiang
On 2018/9/18 23:54, zhong jiang wrote:
> vmemdup_user is better than duplicating its implementation, So just
> replace the open code.
>
> The issue is detected with the help of Coccinelle.
>
> Tested-by: Don Brace
> Acked-by
On 09/20/2018 03:10 PM, Nathan Chancellor wrote:
> Clang warns when multiple pairs of parentheses are used for a single
> conditional statement.
>
> In file included from drivers/scsi/BusLogic.c:57:
> drivers/scsi/FlashPoint.c:2947:34: warning: equality comparison with
> extraneous parentheses [-
On Fri, Sep 21, 2018 at 09:19:40AM -0600, Khalid Aziz wrote:
> On 09/20/2018 03:10 PM, Nathan Chancellor wrote:
> > Clang warns when multiple pairs of parentheses are used for a single
> > conditional statement.
> >
> > In file included from drivers/scsi/BusLogic.c:57:
> > drivers/scsi/FlashPoint.
Thanks for your reponse and feedback,
>> If the disk has no write cache the following errors are being logged.
>> * sd 1:0:0:0: [sdb] No Caching mode page found
>> * sd 1:0:0:0: [sdb] Assuming drive cache: write through
>>
>> Lower the severity from error to info.
>> The absence of a write cache s
Here is a proposal to use a bsg endpoint to manage ufs devices.
We will do that by adding a bsg device node to the ufs driver,
and use it to send UPIU transactions to the ufs device.
It will serve as a ufs device management infrastructure,
for device configuration, provisioning, testing and valid
From: Christoph Hellwig
Remove the pointless task_req_upiu and task_rsp_upiu indirections,
which are __le32 arrays always cast to given structures and just add
the members directly. Also clean up variables names in use in the
callers a bit to make the code more readable.
Signed-off-by: Christop
Add a bsg endpoint that supports UPIUs.
For now, just provide an API to allocate and remove
ufs-bsg node. We will use this framework to
manage ufs devices by sending UPIU transactions.
For the time being, implements an empty bsg_request() -
will add some more functionality in coming patches.
Non
From: Christoph Hellwig
Add a helper that takes a utp_task_req_desc and issues it, which will
be useful for UFS bsg support. Rewrite ufshcd_issue_tm_cmd0x to use
this new helper.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/ufs/ufshcd.c | 141 -
Do that for the currently supported UPIUs:
query, nop out, and task management.
We do not support UPIU of type scsi command yet, while
we are using the job's request and reply pointers to hold
the payload. We will look into it in later patches.
We might need to elaborate the raw upiu api for that
The UFS host software uses a combination of a host register set,
and Transfer Request Descriptors in system memory to communicate
with host controller hardware. In its mmio space, a separate places
are assigned to UTP Transfer Request Descriptor ("utrd") list, and
to UTP Task Management Request Des
Use the structure size in pointer arithmetic's instead of
an opaque 32 bytes for the over allocation of descriptors.
Signed-off-by: Avri Altman
---
drivers/scsi/ufs/ufs.h| 2 +-
drivers/scsi/ufs/ufshcd.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs
Make ufshcd_send_uic_cmd() public for that.
Signed-off-by: Avri Altman
---
drivers/scsi/ufs/ufs_bsg.c | 11 ++-
drivers/scsi/ufs/ufshcd.c| 4 ++--
drivers/scsi/ufs/ufshcd.h| 2 ++
include/uapi/scsi/scsi_bsg_ufs.h | 2 ++
4 files changed, 16 insertions(+), 3 delet
The WARN_ON() is pointless as the rport is placed in SDEV_TRANSPORT_OFFLINE
at that time, so no new commands can be submitted via srp_queuecomment()
Signed-off-by: Hannes Reinecke
---
drivers/infiniband/ulp/srp/ib_srp.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/infiniband
On Fri, Sep 21, 2018 at 02:15:05PM +0200, Hannes Reinecke wrote:
> The WARN_ON() is pointless as the rport is placed in SDEV_TRANSPORT_OFFLINE
> at that time, so no new commands can be submitted via srp_queuecomment()
s/srp_queuecomment/srp_queuecommand/
--
Johannes Thumshirn
On 9/21/18 5:15 AM, Hannes Reinecke wrote:
The WARN_ON() is pointless as the rport is placed in SDEV_TRANSPORT_OFFLINE
at that time, so no new commands can be submitted via srp_queuecomment()
Signed-off-by: Hannes Reinecke
---
drivers/infiniband/ulp/srp/ib_srp.c | 7 ---
1 file changed,
On 09/20/2018 07:32 PM, wenxi...@linux.vnet.ibm.com wrote:
> +
> + list_for_each_entry(res, &ioa_cfg->used_res_q, queue) {
> + if (res->add_to_ml) {
> + bus = res->bus;
> + target = res->target;
> + lun = res->lun;
> +
https://bugzilla.kernel.org/show_bug.cgi?id=201199
Bug ID: 201199
Summary: hpsa blocking boot on HP smart Array P410
Product: IO/Storage
Version: 2.5
Kernel Version: 4.18.3
Hardware: Intel
OS: Linux
Tree: Main
https://bugzilla.kernel.org/show_bug.cgi?id=201199
--- Comment #1 from Seb Lu (se...@seblu.net) ---
Created attachment 278699
--> https://bugzilla.kernel.org/attachment.cgi?id=278699&action=edit
boot failure message
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201199
--- Comment #2 from Seb Lu (se...@seblu.net) ---
Created attachment 278701
--> https://bugzilla.kernel.org/attachment.cgi?id=278701&action=edit
boot udevd traceback
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201199
--- Comment #3 from Seb Lu (se...@seblu.net) ---
Created attachment 278703
--> https://bugzilla.kernel.org/attachment.cgi?id=278703&action=edit
config for 4.19-rc4
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201199
--- Comment #4 from Seb Lu (se...@seblu.net) ---
Created attachment 278705
--> https://bugzilla.kernel.org/attachment.cgi?id=278705&action=edit
config for 4.15.0-22 (working ubuntu)
--
You are receiving this mail because:
You are the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=201199
--- Comment #5 from Seb Lu (se...@seblu.net) ---
Created attachment 278707
--> https://bugzilla.kernel.org/attachment.cgi?id=278707&action=edit
bios version
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201199
--- Comment #6 from Seb Lu (se...@seblu.net) ---
Created attachment 278709
--> https://bugzilla.kernel.org/attachment.cgi?id=278709&action=edit
controller version
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201199
--- Comment #7 from Seb Lu (se...@seblu.net) ---
Created attachment 278711
--> https://bugzilla.kernel.org/attachment.cgi?id=278711&action=edit
lspci
--
You are receiving this mail because:
You are the assignee for the bug.
27 matches
Mail list logo