Re: [PATCH] advansys: fix build warning for PCI=n

[Hannes Reinecke]

On 10/24/2016 05:51 PM, Arnd Bergmann wrote:
> The advansys probe function tries to handle both ISA and PCI cases,
> each hidden in an #ifdef when unused. This leads to a warning
> indicating that when PCI is disabled we could be using uninitialized
> data:
> 
> drivers/scsi/advansys.c: In function ‘advansys_board_found’:
> drivers/scsi/advansys.c:11036:5: error: ‘ret’ may be used uninitialized in 
> this function [-Werror=maybe-uninitialized]
> drivers/scsi/advansys.c:10928:28: note: ‘ret’ was declared here
> drivers/scsi/advansys.c:11309:8: error: ‘share_irq’ may be used uninitialized 
> in this function [-Werror=maybe-uninitialized]
> drivers/scsi/advansys.c:10928:6: note: ‘share_irq’ was declared here
> 
> This cannot happen in practice because the hardware in question
> only exists for PCI, but changing the code to just error out
> here is better for consistency and avoids the warning.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/scsi/advansys.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
> index febbd83e2ecd..81dd0927246b 100644
> --- a/drivers/scsi/advansys.c
> +++ b/drivers/scsi/advansys.c
> @@ -11030,6 +11030,9 @@ static int advansys_board_found(struct Scsi_Host 
> *shost, unsigned int iop,
>   ASC_DBG(2, "AdvInitGetConfig()\n");
>  
>   ret = AdvInitGetConfig(pdev, shost) ? -ENODEV : 0;
> +#else
> + share_irq = 0;
> + ret = -ENODEV;
>  #endif /* CONFIG_PCI */
>   }
>  
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckezSeries & Storage
h...@suse.com  +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

[TomK]

On 10/24/2016 2:36 AM, Nicholas A. Bellinger wrote:

Hi TomK,

Thanks for reporting this bug.  Comments inline below.

On Mon, 2016-10-24 at 00:45 -0400, TomK wrote:

On 10/24/2016 12:32 AM, TomK wrote:

On 10/23/2016 10:03 PM, TomK wrote:

Hey,

Has anyone seen this and could have a workaround?  Seems like it is more
Kernel related with various apps not just target apparently not but
wondering if there is an interim solution
(https://access.redhat.com/solutions/408833)

Getting this message after few minutes of usage from the QLA2xxx driver.
 This is after some activity on an ESXi server (15 VM's) that I'm
connecting to this HBA.  I've tried the following tuning parameters but
there was no change in behaviour:

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Details:


Oct 23 21:28:25 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Oct 23 21:28:29 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx
task_tag: 1128612
Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Sending
TMR_FUNCTION_COMPLETE for ref_tag: 1128612
Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx
task_tag: 1129116


You are likely hitting a known v4.1+ regression, not yet merged up to
v4.8.y code:

https://github.com/torvalds/linux/commit/527268df31e57cf2b6d417198717c6d6afdb1e3e


Jan  6 23:52:00 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon
successfully started
Oct 23 21:30:18 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Jan  6 23:54:01 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon
successfully started
Oct 23 21:32:16 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/u16:8:289 blocked for
more than 120 seconds.
Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
Oct 23 21:32:24 mbpc-pc kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 23 21:32:24 mbpc-pc kernel: kworker/u16:8   D 8803ba18 0
  289  2 0x
Oct 23 21:32:24 mbpc-pc kernel: Workqueue: tmr-fileio target_tmr_work
[target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: 8803ba18 0400
880049e926c0 8803b998
Oct 23 21:32:24 mbpc-pc kernel: 88034600 81f99ca0
81f998ef 8801
Oct 23 21:32:24 mbpc-pc kernel: 812f27d9 
e8c9a000 8800
Oct 23 21:32:24 mbpc-pc kernel: Call Trace:
Oct 23 21:32:24 mbpc-pc kernel: [] ? number+0x2e9/0x310
Oct 23 21:32:24 mbpc-pc kernel: [] schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
start_flush_work+0x49/0x180
Oct 23 21:32:24 mbpc-pc kernel: []
schedule_timeout+0x9c/0xe0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
flush_work+0x1a/0x40
Oct 23 21:32:24 mbpc-pc kernel: [] ?
console_unlock+0x35c/0x380
Oct 23 21:32:24 mbpc-pc kernel: []
wait_for_completion+0xc0/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
try_to_wake_up+0x260/0x260
Oct 23 21:32:24 mbpc-pc kernel: []
__transport_wait_for_tasks+0xb4/0x1b0 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: [] ?
vprintk_default+0x1f/0x30
Oct 23 21:32:24 mbpc-pc kernel: [] ? printk+0x46/0x48
Oct 23 21:32:24 mbpc-pc kernel: []
transport_wait_for_tasks+0x44/0x60 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: []
core_tmr_abort_task+0xf2/0x160 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: []
target_tmr_work+0x154/0x160 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: []
process_one_work+0x189/0x4e0
Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: []
worker_thread+0x16d/0x520
Oct 23 21:32:24 mbpc-pc kernel: [] ?
default_wake_function+0x12/0x20
Oct 23 21:32:24 mbpc-pc kernel: [] ?
__wake_up_common+0x56/0x90
Oct 23 21:32:24 mbpc-pc kernel: [] ?
maybe_create_worker+0x110/0x110
Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
maybe_create_worker+0x110/0x110
Oct 23 21:32:24 mbpc-pc kernel: [] kthread+0xcc/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
schedule_tail+0x1e/0xc0
Oct 23 21:32:24 mbpc-pc kernel: []
ret_from_fork+0x1f/0x40
Oct 23 21:32:24 mbpc-pc kernel: [] ?
kthread_freezable_should_stop+0x70/0x70
Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/1:48:6089 blocked for
more than 120 seconds.
Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
Oct 23 21:32:24 mbpc-pc kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 23 21:32:24 mbpc-pc kernel: kworker/1:48D 88004017f968 0
 6089  2 0x0080
Oct 23 21:32:24 mbpc-pc kernel: Workqueue: events qlt_free_session_done
[qla2xxx]
Oct 23 21:32:24 mbpc-pc kernel: 88004017f968 88004017f8f8
88011a83a300 0004
Oct 23 21:32:24 mbpc-pc kernel: 88004017a600 88004017f938
810a0bb6 8801
Oct 23 21:32:24 mbpc-pc kernel: 880110fd0840 8800
81090728 8801
Oct 23 21:32:24 mbpc-pc kernel: Call Trace:
Oct 23 21:32:24 mbpc-pc kernel: [] ?
enqueue_task_fair+0x66/0x410
Oct 23 21:32:24 mbpc-pc kernel: [] ?

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

[Martin K. Petersen]

> "Tomas" == Tomas Henzl  writes:

>> SCSI command checking in queuecommand function of arcmsr can be
>> removed safely.  Now driver can pass all scsi command to controller
>> firmware.

Tomas> Is this (passing the SYNCHRONIZE_CACHE command to firmware) safe
Tomas> for all arcmsr cards, even the oldest?

Ching?

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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

Re: [PATCH v3 0/6] scsi: collection of clean ups

[Martin K. Petersen]

> "Andy" == Andy Shevchenko  writes:

Andy> Just collection of clean ups against SCSI drivers. Some of them
Andy> were Acked quite long ago, but didn't make upstream yet.

Applied to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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

Re: [PATCH v3 0/7] megaraid_sas: Updates for scsi-next

[Martin K. Petersen]

> "Kashyap" == Kashyap Desai  writes:

Kashyap,

Kashyap> Changes in v3
Kashyap>  two logical patches created for "Send SYNCHRONIZE_CACHE
Kashyap>  command to firmware"
Kashyap>- Send SYNCHRONIZE_CACHE for JBOD to firmware
Kashyap>- Send SYNCHRONIZE_CACHE for VD to firmware

I applied patch 4 to 4.9/scsi-fixes and 1-3 to 4.10/scsi-queue.

Once Linus merges patch 4 I'll rebase the 4.10 tree and queue 5-8.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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

Re: [PATCH v3 4/8] megaraid_sas: Send SYNCHRONIZE_CACHE for non-raid to firmware

[Martin K. Petersen]

> "Kashyap" == Kashyap Desai  writes:

Kashyap> Commit- " 02b01e0 [SCSI] megaraid_sas: return sync cache call
Kashyap> with success" added the code in driver to return
Kashyap> SYNCHRONIZE_CACHE without sending it to firmware back in
Kashyap> 2007. Earlier MR was mainly for Virtual Disk, so same code
Kashyap> continue for JBOD as well whenever JBOD support was added and
Kashyap> it introduced bug that SYNCHRONIZE_CACHE is not passed to FW
Kashyap> for JBOD (non Raid disk).

Kashyap> But our recent analysis indicates that, From Day-1 MR Firmware
Kashyap> always expect Driver to forward SYNCHRONIZE_CACHE for JBOD (non
Kashyap> Raid disk) to the Firmware.  We have fixed this as part of this
Kashyap> patch.

Applied to 4.9/scsi-fixes.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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

Re: [PATCH 00/10] mpt3sas driver Enhancements and

[Martin K. Petersen]

> "Suganath" == Suganath Prabu S  
> writes:

Suganath,

Suganath> Here is the change list: Posting 10 patches for mpt3sas driver
Suganath> enhancements and few fixes.
Suganath>   * Added Device ID's for SAS35 devices and updated MPI
Suganath> Header.
Suganath>   * Support "EEDP Escape flag" for SAS35 devices.
Suganath>   * fixed improper printk statement.
Suganath>   * Regardless of whether RDPQ disabled card is enumerated
Suganath> first or RDPQ enabled card is enumerated first, MSIX
Suganath> vectors depends on the cards capability.
Suganath>   * device_remove_in_progress bit check has been added in
Suganath> IOCTL path. If bit is set, then IOCTL will be failed
Suganath> printing failure message.
Suganath>   * Started using the Atomic Request Descriptors for
Suganath> SAS35 devices.
Suganath>   * For SAS35 devices MSIX vectors are inceased to 128 from
Suganath> 96.
Suganath>   * Fixing Endianness issue.
Suganath>   * Updated driver version to 14.100.00.00

Please address the review comments, apply Hannes' review tags and
resubmit.

Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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

Re: [PATCH] lpfc: Revise MAINTAINERS to reflect Broadcom

[Martin K. Petersen]

> "James" == James Smart  writes:

James> Avago is now known as Broadcom.  Revise the emails and website
James> for lpfc accordingly

Applied to 4.10/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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

Re: [PATCH v2 00/10] ufs-qcom: phy/hcd: Clean up qcom-ufs phy and ufs-qcom hcd

[Martin K. Petersen]

> "Vivek" == Vivek Gautam  writes:

Vivek,

Vivek> These patches cleanup the ufs phy driver to an extent.
Vivek> Subsequent patches will target to clean the phy_init() of these
Vivek> qcom-ufs phy drivers in order to get rid of a number of exported
Vivek> APIs that phy drivers expose for ufs-qcom hcd driver to use.

Please submit a v3 which addresses the review comments and adds the
relevant Reviewed-by: tags.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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

Re: [PATCH 00/20] libfc callback cleanup

[Martin K. Petersen]

> "Hannes" == Hannes Reinecke  writes:

Hannes> Hi all, it has been bugging me for a while that libfc has tons
Hannes> of callbacks in an attempt to abstract things away. But as it
Hannes> turned out no-one ever used those, rendering them quite
Hannes> pointless.  As I got some time to kill on the train back from
Hannes> Vienna I've decided to finally kill them and call the functions
Hannes> directly.

Applied to 4.10/scsi-queue.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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

[Bug 176951] boot fails unless acpi=off Acer Travelmate X-349

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=176951

Len Brown  changed:

   What|Removed |Added

  Component|Config-Tables   |Other
   Assignee|acpi_config-tables@kernel-b |scsi_drivers-other@kernel-b
   |ugs.osdl.org|ugs.osdl.org
Product|ACPI|SCSI Drivers

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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

RE: Device or HBA level QD throttling creates randomness in sequetial workload

[Kashyap Desai]

> -Original Message-
> From: Omar Sandoval [mailto:osan...@osandov.com]
> Sent: Monday, October 24, 2016 9:11 PM
> To: Kashyap Desai
> Cc: linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
> bl...@vger.kernel.org; ax...@kernel.dk; Christoph Hellwig;
> paolo.vale...@linaro.org
> Subject: Re: Device or HBA level QD throttling creates randomness in
sequetial
> workload
>
> On Mon, Oct 24, 2016 at 06:35:01PM +0530, Kashyap Desai wrote:
> > >
> > > On Fri, Oct 21, 2016 at 05:43:35PM +0530, Kashyap Desai wrote:
> > > > Hi -
> > > >
> > > > I found below conversation and it is on the same line as I wanted
> > > > some input from mailing list.
> > > >
> > > > http://marc.info/?l=linux-kernel=147569860526197=2
> > > >
> > > > I can do testing on any WIP item as Omar mentioned in above
> > discussion.
> > > > https://github.com/osandov/linux/tree/blk-mq-iosched
> >
> > I tried build kernel using this repo, but looks like it is not allowed
> > to reboot due to some changes in  layer.
>
> Did you build the most up-to-date version of that branch? I've been
force
> pushing to it, so the commit id that you built would be useful.
> What boot failure are you seeing?

Below  is latest commit on repo.
commit b077a9a5149f17ccdaa86bc6346fa256e3c1feda
Author: Omar Sandoval 
Date:   Tue Sep 20 11:20:03 2016 -0700

[WIP] blk-mq: limit bio queue depth

I have latest repo from 4.9/scsi-next maintained by Martin which boots
fine.  Only Delta is  " CONFIG_SBITMAP" is enabled in WIP blk-mq-iosched
branch. I could not see any meaningful data on boot hang, so going to try
one more time tomorrow.


>
> > >
> > > Are you using blk-mq for this disk? If not, then the work there
> > > won't
> > affect you.
> >
> > YES. I am using blk-mq for my test. I also confirm if use_blk_mq is
> > disable, Sequential work load issue is not seen and  scheduling
> > works well.
>
> Ah, okay, perfect. Can you send the fio job file you're using? Hard to
tell exactly
> what's going on without the details. A sequential workload with just one
> submitter is about as easy as it gets, so this _should_ be behaving
nicely.



; setup numa policy for each thread
; 'numactl --show' to determine the maximum numa nodes
[global]
ioengine=libaio
buffered=0
rw=write
bssplit=4K/100
iodepth=256
numjobs=1
direct=1
runtime=60s
allow_mounted_write=0

[job1]
filename=/dev/sdd
..
[job24]
filename=/dev/sdaa

When I tune /sys/module/scsi_mod/parameters/use_blk_mq = 1, below is a
ioscheduler detail. (It is in blk-mq mode. )
/sys/devices/pci:00/:00:02.0/:02:00.0/host10/target10:2:13/10:
2:13:0/block/sdq/queue/scheduler:none

When I have set /sys/module/scsi_mod/parameters/use_blk_mq = 0,
ioscheduler picked by SML is .
/sys/devices/pci:00/:00:02.0/:02:00.0/host10/target10:2:13/10:
2:13:0/block/sdq/queue/scheduler:noop deadline [cfq]

I see in blk-mq performance is very low for Sequential Write work load and
I confirm that blk-mq convert Sequential work load into random stream due
to  io-scheduler change in blk-mq vs legacy block layer.

>
> > >
> > > > Is there any workaround/alternative in latest upstream kernel, if
> > > > user wants to see limited penalty  for Sequential Work load on HDD
?
> > > >
> > > > ` Kashyap
> > > >
>
> P.S., your emails are being marked as spam by Gmail. Actually, Gmail
seems to
> mark just about everything I get from Broadcom as spam due to failed
DMARC.
>
> --
> Omar
--
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

Re: [PATCH v3 5/8] megaraid_sas: Send SYNCHRONIZE_CACHE for VD to firmware

[Ewan D. Milne]

On Fri, 2016-10-21 at 06:33 -0700, Kashyap Desai wrote:
> From previous patch we have below changes in v2 (only for Virtual Disk)-
> 1.  Updated change log.  Provided more detail in change log.
> 2.  Agreed to remove module parameter. If we remove module parameter, we
> can ask customer to disable WCE on drive to get similar impact.
> 3.  Always Send SYNCHRONIZE_CACHE  for JBOD (non Raid) Device to Firmware.
> 
> Current megaraid_sas driver returns SYNCHRONIZE_CACHE(related to Drive
> Cache)  command  back to SCSI layer without sending it down to firmware as
> firmware supposed to take care of flushing disk cache for all drives
> belongs to Virtual Disk at the time of system reboot/shutdown.
> 
> We evaluate and understood that for Raid Volume, why driver should not
> send SYNC_CACHE command to the Firmware.
> There may be a some reason in past, but now it looks to be not required and
> we have fixed this issue as part of this patch.
> 
>  - Additional background -
> There are some instance of MegaRaid FW (E.a Gen2 and Gen2.5 FW) set WCE bit
> for Virtual Disk but firmware does not reply correct status for SYNCH_CACHE.
> It is very difficult to find out which Device ID and firmware has capability
> to manage SYNC_CACHE, so we managed to figure out which are the new firmware
> (canHandleSyncCache is set in scratch pad register at 0xB4) and use that
> interface for correct behavior as explained above.
> 
> E.g Liberator/Thunderbolt MegaRaid FW returns SYNC_CACHE as Unsupported
> command (this is a firmware bug) and eventually command will be failed to SML.
> This will cause File system to go Read-only.
> 
>  - New behavior described -
> 
> IF application requests SYNCH_CACHE
>IF 'JBOD'
>   Driver sends SYNCH_CACHE command to the FW
>FW sends SYNCH_CACHE to drive
>FW obtains status from drive and returns same status back to 
> driver
>ELSEIF 'VirtualDisk'
>IF any FW which supports new API bit called canHandleSyncCache
>   Driver sends SYNCH_CACHE command to the FW
>   FW does not send SYNCH_CACHE to drives
>   FW returns SUCCESS
>ELSE
>   Driver does not send SYNCH_CACHE command to the 
> FW.
>   Driver return SUCCESS for that command.
>ENDIF
> ENDIF
> ENDIF
> 
> Signed-off-by: Kashyap Desai 
> Signed-off-by: Sumit Saxena 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h| 3 +++
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 7 ++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 5 +
>  3 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index ca86c88..43fd14f 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>  #define MR_MAX_MSIX_REG_ARRAY   16
>  #define MR_RDPQ_MODE_OFFSET  0X0080
> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET  0X0100
> +
>  /*
>  * register set for both 1068 and 1078 controllers
>  * structure extended for 1078 registers
> @@ -2140,6 +2142,7 @@ struct megasas_instance {
>   u8 is_imr;
>   u8 is_rdpq;
>   bool dev_handle;
> + bool fw_sync_cache_support;
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index c98d4f9..236b8ed 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1700,11 +1700,8 @@ megasas_queue_command(struct Scsi_Host *shost, struct 
> scsi_cmnd *scmd)
>   goto out_done;
>   }
>  
> - /*
> -  * FW takes care of flush cache on its own for Virtual Disk.
> -  * No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to 
> FW.
> -  */
> - if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
> + if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd) &&
> + (!instance->fw_sync_cache_support)) {
>   scmd->result = DID_OK << 16;
>   goto out_done;
>   }
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index ec626fc..0edeeb1 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -748,6 +748,11 @@ megasas_ioc_init_fusion(struct megasas_instance 
> *instance)
>   goto fail_fw_init;
>   }
>  
> + instance->fw_sync_cache_support = (scratch_pad_2 &
> + MR_CAN_HANDLE_SYNC_CACHE_OFFSET) ? 1 : 0;
> + dev_info(>pdev->dev, "FW supports sync 

[PATCH] lpfc: Revise MAINTAINERS to reflect Broadcom

[James Smart]

Avago is now known as Broadcom.
Revise the emails and website for lpfc accordingly

Signed-off-by: James Smart 
---
 MAINTAINERS | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 072fe36..96e0ec6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4681,11 +4681,11 @@ M:  David Woodhouse 
 L: linux-embed...@vger.kernel.org
 S: Maintained
 
-EMULEX/AVAGO LPFC FC/FCOE SCSI DRIVER
-M: James Smart 
-M: Dick Kennedy 
+EMULEX/BROADCOM LPFC FC/FCOE SCSI DRIVER
+M: James Smart 
+M: Dick Kennedy 
 L: linux-scsi@vger.kernel.org
-W: http://www.avagotech.com
+W: http://www.broadcom.com
 S: Supported
 F: drivers/scsi/lpfc/
 
-- 
2.5.0


--
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

Re: [PATCH v3 4/8] megaraid_sas: Send SYNCHRONIZE_CACHE for non-raid to firmware

[Ewan D. Milne]

On Fri, 2016-10-21 at 06:33 -0700, Kashyap Desai wrote:
> Commit- " 02b01e0 [SCSI] megaraid_sas: return sync cache call with success"
> added the code in driver to return SYNCHRONIZE_CACHE without sending it to
> firmware back in 2007. Earlier MR was mainly for Virtual Disk,
> so same code continue for JBOD as well whenever JBOD support was added and it 
> introduced bug that
> SYNCHRONIZE_CACHE is not passed to FW for JBOD (non Raid disk).
> 
> But our recent analysis indicates that, From Day-1 MR Firmware always
> expect Driver to forward SYNCHRONIZE_CACHE for JBOD (non Raid disk) to the
> Firmware.
> We have fixed this as part of this patch.
> 
> CC: sta...@vger.kernel.org
> Signed-off-by: Kashyap Desai 
> Signed-off-by: Sumit Saxena 
> ---
>  drivers/scsi/megaraid/megaraid_sas_base.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index ba57be6..c98d4f9 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1700,16 +1700,13 @@ megasas_queue_command(struct Scsi_Host *shost, struct 
> scsi_cmnd *scmd)
>   goto out_done;
>   }
>  
> - switch (scmd->cmnd[0]) {
> - case SYNCHRONIZE_CACHE:
> - /*
> -  * FW takes care of flush cache on its own
> -  * No need to send it down
> -  */
> + /*
> +  * FW takes care of flush cache on its own for Virtual Disk.
> +  * No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to 
> FW.
> +  */
> + if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
>   scmd->result = DID_OK << 16;
>   goto out_done;
> - default:
> - break;
>   }
>  
>   return instance->instancet->build_and_issue_cmd(instance, scmd);

Along with 4/8 in this v3 series...

Reviewed-by: Ewan D. Milne 


--
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

[PATCH] advansys: fix build warning for PCI=n

[Arnd Bergmann]

The advansys probe function tries to handle both ISA and PCI cases,
each hidden in an #ifdef when unused. This leads to a warning
indicating that when PCI is disabled we could be using uninitialized
data:

drivers/scsi/advansys.c: In function ‘advansys_board_found’:
drivers/scsi/advansys.c:11036:5: error: ‘ret’ may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:10928:28: note: ‘ret’ was declared here
drivers/scsi/advansys.c:11309:8: error: ‘share_irq’ may be used uninitialized 
in this function [-Werror=maybe-uninitialized]
drivers/scsi/advansys.c:10928:6: note: ‘share_irq’ was declared here

This cannot happen in practice because the hardware in question
only exists for PCI, but changing the code to just error out
here is better for consistency and avoids the warning.

Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/advansys.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index febbd83e2ecd..81dd0927246b 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -11030,6 +11030,9 @@ static int advansys_board_found(struct Scsi_Host 
*shost, unsigned int iop,
ASC_DBG(2, "AdvInitGetConfig()\n");
 
ret = AdvInitGetConfig(pdev, shost) ? -ENODEV : 0;
+#else
+   share_irq = 0;
+   ret = -ENODEV;
 #endif /* CONFIG_PCI */
}
 
-- 
2.9.0

--
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

Re: Device or HBA level QD throttling creates randomness in sequetial workload

[Omar Sandoval]

On Mon, Oct 24, 2016 at 06:35:01PM +0530, Kashyap Desai wrote:
> >
> > On Fri, Oct 21, 2016 at 05:43:35PM +0530, Kashyap Desai wrote:
> > > Hi -
> > >
> > > I found below conversation and it is on the same line as I wanted some
> > > input from mailing list.
> > >
> > > http://marc.info/?l=linux-kernel=147569860526197=2
> > >
> > > I can do testing on any WIP item as Omar mentioned in above
> discussion.
> > > https://github.com/osandov/linux/tree/blk-mq-iosched
> 
> I tried build kernel using this repo, but looks like it is not allowed to
> reboot due to some changes in  layer.

Did you build the most up-to-date version of that branch? I've been
force pushing to it, so the commit id that you built would be useful.
What boot failure are you seeing?

> >
> > Are you using blk-mq for this disk? If not, then the work there won't
> affect you.
> 
> YES. I am using blk-mq for my test. I also confirm if use_blk_mq is
> disable, Sequential work load issue is not seen and  scheduling works
> well.

Ah, okay, perfect. Can you send the fio job file you're using? Hard to
tell exactly what's going on without the details. A sequential workload
with just one submitter is about as easy as it gets, so this _should_ be
behaving nicely.

> >
> > > Is there any workaround/alternative in latest upstream kernel, if user
> > > wants to see limited penalty  for Sequential Work load on HDD ?
> > >
> > > ` Kashyap
> > >

P.S., your emails are being marked as spam by Gmail. Actually, Gmail
seems to mark just about everything I get from Broadcom as spam due to
failed DMARC.

-- 
Omar
--
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

Re: [PATCH 10/10] mpt3sas: Fix for Endianness issue.

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

Use le16_to_cpu only for accessing two byte data provided by controller.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 6d17f66..981be7b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -5384,10 +5384,10 @@ _scsih_check_device(struct MPT3SAS_ADAPTER *ioc,
sas_device->handle, handle);
sas_target_priv_data->handle = handle;
sas_device->handle = handle;
-   if (sas_device_pg0.Flags &
+   if (le16_to_cpu(sas_device_pg0.Flags) &
 MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
-   le16_to_cpu(sas_device_pg0.EnclosureLevel);
+   sas_device_pg0.EnclosureLevel;
memcpy(sas_device->connector_name,
sas_device_pg0.ConnectorName, 4);
sas_device->connector_name[4] = '\0';
@@ -5516,9 +5516,10 @@ _scsih_add_device(struct MPT3SAS_ADAPTER *ioc, u16 
handle, u8 phy_num,
sas_device->fast_path = (le16_to_cpu(sas_device_pg0.Flags) &
MPI25_SAS_DEVICE0_FLAGS_FAST_PATH_CAPABLE) ? 1 : 0;

-   if (sas_device_pg0.Flags & MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
+   if (le16_to_cpu(sas_device_pg0.Flags)
+   & MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
-   le16_to_cpu(sas_device_pg0.EnclosureLevel);
+   sas_device_pg0.EnclosureLevel;
memcpy(sas_device->connector_name,
sas_device_pg0.ConnectorName, 4);
sas_device->connector_name[4] = '\0';
@@ -7056,7 +7057,7 @@ Mpi2SasDevicePage0_t *sas_device_pg0)
if (sas_device_pg0->Flags &
  MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
-  le16_to_cpu(sas_device_pg0->EnclosureLevel);
+  sas_device_pg0->EnclosureLevel;
memcpy(_device->connector_name[0],
_device_pg0->ConnectorName[0], 4);
} else {
@@ -7118,6 +7119,7 @@ _scsih_search_responding_sas_devices(struct 
MPT3SAS_ADAPTER *ioc)
sas_device_pg0.SASAddress =
le64_to_cpu(sas_device_pg0.SASAddress);
sas_device_pg0.Slot = le16_to_cpu(sas_device_pg0.Slot);
+   sas_device_pg0.Flags = le16_to_cpu(sas_device_pg0.Flags);
_scsih_mark_responding_sas_device(ioc, _device_pg0);
}



Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH 08/10] mpt3sas: set EEDP-escape-flags for SAS35 devices.

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

An UNMAP command on a PI formatted device will leave the Logical Block
Application Tag and Logical Block Reference Tag as all F's (for those LBAs
that are unmapped). To avoid IO errors if those LBAs are subsequently read
before they are written with valid tag fields, the MPI SCSI IO requests
need to set the EEDPFlags element EEDP Escape Mode field, Bits [7:6]
appropriately. A value of 2 should be set to disable all PI checks if the
Logical Block Application Tag is 0x for PI types 1 and 2.  A value
of 3 should be set to disable all PI checks if the Logical Block
Application Tag is 0x and the Logical Block Reference Tag is
0x for PI type 3.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index a1c541d..c58f326 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3989,6 +3989,9 @@ _scsih_setup_eedp(struct MPT3SAS_ADAPTER *ioc, struct 
scsi_cmnd *scmd,

mpi_request_3v->EEDPBlockSize =
cpu_to_le16(scmd->device->sector_size);
+
+   if (ioc->is_gen35_ioc)
+   eedp_flags |= MPI25_SCSIIO_EEDPFLAGS_APPTAG_DISABLE_MODE;
mpi_request->EEDPFlags = cpu_to_le16(eedp_flags);
 }



Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH 07/10] mpt3sas: Increased/Additional MSIX support for SAS35 devices.

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

For SAS35 devices MSIX vectors are inceased to 128 from 96. To support this
Reply post host index register count is increased to 16. Also variable
msix96_vector is replaced with combined_reply_queue and variable
combined_reply_index_count is added to set different values for SAS3 and
SAS35 devices.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 14 +++---
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  8 +---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 11 +--
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 9ad7f7c..43cdc02 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1078,7 +1078,7 @@ _base_interrupt(int irq, void *bus_id)
 * new reply host index value in ReplyPostIndex Field and msix_index
 * value in MSIxIndex field.
 */
-   if (ioc->msix96_vector)
+   if (ioc->combined_reply_queue)
writel(reply_q->reply_post_host_index | ((msix_index  & 7) <<
MPI2_RPHI_MSIX_INDEX_SHIFT),
ioc->replyPostRegisterIndex[msix_index/8]);
@@ -2052,7 +2052,7 @@ mpt3sas_base_unmap_resources(struct MPT3SAS_ADAPTER *ioc)
_base_free_irq(ioc);
_base_disable_msix(ioc);

-   if (ioc->msix96_vector) {
+   if (ioc->combined_reply_queue) {
kfree(ioc->replyPostRegisterIndex);
ioc->replyPostRegisterIndex = NULL;
}
@@ -2162,7 +2162,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
/* Use the Combined reply queue feature only for SAS3 C0 & higher
 * revision HBAs and also only when reply queue count is greater than 8
 */
-   if (ioc->msix96_vector && ioc->reply_queue_count > 8) {
+   if (ioc->combined_reply_queue && ioc->reply_queue_count > 8) {
/* Determine the Supplemental Reply Post Host Index Registers
 * Addresse. Supplemental Reply Post Host Index Registers
 * starts at offset MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET and
@@ -2170,7 +2170,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
 * MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET from previous one.
 */
ioc->replyPostRegisterIndex = kcalloc(
-MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT,
+ioc->combined_reply_index_count,
 sizeof(resource_size_t *), GFP_KERNEL);
if (!ioc->replyPostRegisterIndex) {
dfailprintk(ioc, printk(MPT3SAS_FMT
@@ -2180,14 +2180,14 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
goto out_fail;
}

-   for (i = 0; i < MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT; i++) {
+   for (i = 0; i < ioc->combined_reply_index_count; i++) {
ioc->replyPostRegisterIndex[i] = (resource_size_t *)
 ((u8 *)>chip->Doorbell +
 MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET +
 (i * MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET));
}
} else
-   ioc->msix96_vector = 0;
+   ioc->combined_reply_queue = 0;

if (ioc->is_warpdrive) {
ioc->reply_post_host_index[0] = (resource_size_t __iomem *)
@@ -5140,7 +5140,7 @@ _base_make_ioc_operational(struct MPT3SAS_ADAPTER *ioc)

/* initialize reply post host index */
list_for_each_entry(reply_q, >reply_queue_list, list) {
-   if (ioc->msix96_vector)
+   if (ioc->combined_reply_queue)
writel((reply_q->msix_index & 7)<<
   MPI2_RPHI_MSIX_INDEX_SHIFT,
   ioc->replyPostRegisterIndex[reply_q->msix_index/8]);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 3d75c57..acb4106 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -300,8 +300,9 @@
  * There are twelve Supplemental Reply Post Host Index Registers
  * and each register is at offset 0x10 bytes from the previous one.
  */
-#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT 12
-#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET (0x10)
+#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT_G312
+#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT_G35   16
+#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET  (0x10)

 /* OEM Identifiers */
 #define MFG10_OEM_ID_INVALID   (0x)
@@ -1158,7 +1159,8 @@ struct MPT3SAS_ADAPTER {
u8  reply_queue_count;

Re: [PATCH 09/10] mpt3sas: Use the new MPI 2.6 32-bit Atomic Request Descriptors for SAS35 devices.

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

Support Atomic Request Descriptors for Ventura/SAS35 devices.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 141 +++
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  18 ++--
 drivers/scsi/mpt3sas/mpt3sas_config.c|   2 +-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  22 ++---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |  24 +++---
 drivers/scsi/mpt3sas/mpt3sas_transport.c |   8 +-
 6 files changed, 161 insertions(+), 54 deletions(-)


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH 06/10] mpt3sas: Added Device ID's for SAS35 devices and updated MPI header.

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

Added Device ID's for SAS35 devices (Ventura, Crusader, Harpoon &
Tomcat) and updated mpi header file for the same. Also added
"is_gen35_ioc" to MPT3SAS_ADAPTER structure for identifying SAS35 adapters.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h |  7 +++
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  1 +
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  5 -
 drivers/scsi/mpt3sas/mpt3sas_ctl.h   |  1 +
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 31 +++
 5 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h 
b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
index 95356a8..fa61baf 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
@@ -478,6 +478,13 @@ typedef struct _MPI2_CONFIG_REPLY {
 #define MPI26_MFGPAGE_DEVID_SAS3324_3   (0x00C2)
 #define MPI26_MFGPAGE_DEVID_SAS3324_4   (0x00C3)

+#define MPI26_MFGPAGE_DEVID_SAS3516 (0x00AA)
+#define MPI26_MFGPAGE_DEVID_SAS3516_1   (0x00AB)
+#define MPI26_MFGPAGE_DEVID_SAS3416 (0x00AC)
+#define MPI26_MFGPAGE_DEVID_SAS3508 (0x00AD)
+#define MPI26_MFGPAGE_DEVID_SAS3508_1   (0x00AE)
+#define MPI26_MFGPAGE_DEVID_SAS3408 (0x00AF)
+
 /*Manufacturing Page 0 */

 typedef struct _MPI2_CONFIG_PAGE_MAN_0 {
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 6f03a86..3d75c57 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -1191,6 +1191,7 @@ struct MPT3SAS_ADAPTER {
struct SL_WH_MPI_TRIGGERS_T diag_trigger_mpi;
void*device_remove_in_progress;
u16 device_remove_in_progress_sz;
+   u8  is_gen35_ioc;
 };

 typedef u8 (*MPT_CALLBACK)(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index,
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c 
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index f204ce1..62be7d4 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -1096,7 +1096,10 @@ _ctl_getiocinfo(struct MPT3SAS_ADAPTER *ioc, void __user 
*arg)
break;
case MPI25_VERSION:
case MPI26_VERSION:
-   karg.adapter_type = MPT3_IOCTL_INTERFACE_SAS3;
+   if (ioc->is_gen35_ioc)
+   karg.adapter_type = MPT3_IOCTL_INTERFACE_SAS35;
+   else
+   karg.adapter_type = MPT3_IOCTL_INTERFACE_SAS3;
strcat(karg.driver_version, MPT3SAS_DRIVER_VERSION);
break;
}
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.h 
b/drivers/scsi/mpt3sas/mpt3sas_ctl.h
index 8940835..f3e17a8 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.h
@@ -143,6 +143,7 @@ struct mpt3_ioctl_pci_info {
 #define MPT2_IOCTL_INTERFACE_SAS2  (0x04)
 #define MPT2_IOCTL_INTERFACE_SAS2_SSS6200  (0x05)
 #define MPT3_IOCTL_INTERFACE_SAS3  (0x06)
+#define MPT3_IOCTL_INTERFACE_SAS35 (0x07)
 #define MPT2_IOCTL_VERSION_LENGTH  (32)

 /**
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 9584d6b..521849d 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -8660,6 +8660,12 @@ _scsih_determine_hba_mpi_version(struct pci_dev *pdev)
case MPI26_MFGPAGE_DEVID_SAS3324_2:
case MPI26_MFGPAGE_DEVID_SAS3324_3:
case MPI26_MFGPAGE_DEVID_SAS3324_4:
+   case MPI26_MFGPAGE_DEVID_SAS3508:
+   case MPI26_MFGPAGE_DEVID_SAS3508_1:
+   case MPI26_MFGPAGE_DEVID_SAS3408:
+   case MPI26_MFGPAGE_DEVID_SAS3516:
+   case MPI26_MFGPAGE_DEVID_SAS3516_1:
+   case MPI26_MFGPAGE_DEVID_SAS3416:
return MPI26_VERSION;
}
return 0;
@@ -8728,6 +8734,18 @@ _scsih_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
ioc->hba_mpi_version_belonged = hba_mpi_version;
ioc->id = mpt3_ids++;
sprintf(ioc->driver_name, "%s", MPT3SAS_DRIVER_NAME);
+   switch (pdev->device) {
+   case MPI26_MFGPAGE_DEVID_SAS3508:
+   case MPI26_MFGPAGE_DEVID_SAS3508_1:
+   case MPI26_MFGPAGE_DEVID_SAS3408:
+   case MPI26_MFGPAGE_DEVID_SAS3516:
+   case MPI26_MFGPAGE_DEVID_SAS3516_1:
+   case MPI26_MFGPAGE_DEVID_SAS3416:
+   ioc->is_gen35_ioc = 1;
+   break;
+   default:
+   ioc->is_gen35_ioc = 0;
+   }
if ((ioc->hba_mpi_version_belonged == MPI25_VERSION &&
pdev->revision >= 

Re: [PATCH 05/10] mpt3sas: Bump driver version as "14.100.00.00"

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index e923c91..6f03a86 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -73,8 +73,8 @@
 #define MPT3SAS_DRIVER_NAME"mpt3sas"
 #define MPT3SAS_AUTHOR "Avago Technologies "
 #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver"
-#define MPT3SAS_DRIVER_VERSION "13.100.00.00"
-#define MPT3SAS_MAJOR_VERSION  13
+#define MPT3SAS_DRIVER_VERSION "14.100.00.00"
+#define MPT3SAS_MAJOR_VERSION  14
 #define MPT3SAS_MINOR_VERSION  100
 #define MPT3SAS_BUILD_VERSION  0
 #define MPT3SAS_RELEASE_VERSION00


Please move this to the end of the patch series.

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH 04/10] mpt3sas: Removing unused macro "MPT_DEVICE_TLR_ON"

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

Removing macro "MPT_DEVICE_TLR_ON" defined in header file as its unused

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 4221a4d..e923c91 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -375,7 +375,6 @@ struct MPT3SAS_TARGET {
  * per device private data
  */
 #define MPT_DEVICE_FLAGS_INIT  0x01
-#define MPT_DEVICE_TLR_ON  0x02

 #define MFG_PAGE10_HIDE_SSDS_MASK  (0x0003)
 #define MFG_PAGE10_HIDE_ALL_DISKS  (0x00)


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH 03/10] mpt3sas: Implement device_remove_in_progress check in IOCTL path

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

When device missing event arrives, device_remove_in_progress bit will be
set and hence driver has to stop sending IOCTL commands.Now the check has
been added in IOCTL path to test device_remove_in_progress bit is set, if
so then IOCTL will be failed printing failure message.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 19 +++
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  5 
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   | 46 ++--
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 24 ++-
 4 files changed, 86 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 4ea81e1..9ad7f7c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -5334,6 +5334,21 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
goto out_free_resources;
}

+   /* allocate memory for pending OS device add list */
+   ioc->pend_os_device_add_sz = (ioc->facts.MaxDevHandle / 8);
+   if (ioc->facts.MaxDevHandle % 8)
+   ioc->pend_os_device_add_sz++;
+   ioc->pend_os_device_add = kzalloc(ioc->pend_os_device_add_sz,
+   GFP_KERNEL);
+   if (!ioc->pend_os_device_add)
+   goto out_free_resources;
+
+   ioc->device_remove_in_progress_sz = ioc->pend_os_device_add_sz;
+   ioc->device_remove_in_progress =
+   kzalloc(ioc->device_remove_in_progress_sz, GFP_KERNEL);
+   if (!ioc->device_remove_in_progress)
+   goto out_free_resources;
+
ioc->fwfault_debug = mpt3sas_fwfault_debug;

/* base internal command bits */
@@ -5416,6 +5431,8 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
kfree(ioc->reply_post_host_index);
kfree(ioc->pd_handles);
kfree(ioc->blocking_handles);
+   kfree(ioc->device_remove_in_progress);
+   kfree(ioc->pend_os_device_add);
kfree(ioc->tm_cmds.reply);
kfree(ioc->transport_cmds.reply);
kfree(ioc->scsih_cmds.reply);
@@ -5457,6 +5474,8 @@ mpt3sas_base_detach(struct MPT3SAS_ADAPTER *ioc)
kfree(ioc->reply_post_host_index);
kfree(ioc->pd_handles);
kfree(ioc->blocking_handles);
+   kfree(ioc->device_remove_in_progress);
+   kfree(ioc->pend_os_device_add);
kfree(ioc->pfacts);
kfree(ioc->ctl_cmds.reply);
kfree(ioc->ctl_cmds.sense);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 3e71bc1..4221a4d 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -1079,6 +1079,9 @@ struct MPT3SAS_ADAPTER {
void*pd_handles;
u16 pd_handles_sz;

+   void*pend_os_device_add;
+   u16 pend_os_device_add_sz;
+
/* config page */
u16 config_page_sz;
void*config_page;
@@ -1187,6 +1190,8 @@ struct MPT3SAS_ADAPTER {
struct SL_WH_EVENT_TRIGGERS_T diag_trigger_event;
struct SL_WH_SCSI_TRIGGERS_T diag_trigger_scsi;
struct SL_WH_MPI_TRIGGERS_T diag_trigger_mpi;
+   void*device_remove_in_progress;
+   u16 device_remove_in_progress_sz;
 };

 typedef u8 (*MPT_CALLBACK)(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index,
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c 
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index 26cdc12..f204ce1 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -654,6 +654,7 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc, struct 
mpt3_ioctl_command karg,
size_t data_in_sz = 0;
long ret;
u16 wait_state_count;
+   u16 device_handle = MPT3SAS_INVALID_DEVICE_HANDLE;

issue_reset = 0;

@@ -738,10 +739,13 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc, struct 
mpt3_ioctl_command karg,
data_in_sz = karg.data_in_size;

if (mpi_request->Function == MPI2_FUNCTION_SCSI_IO_REQUEST ||
-   mpi_request->Function == MPI2_FUNCTION_RAID_SCSI_IO_PASSTHROUGH) {
-   if (!le16_to_cpu(mpi_request->FunctionDependent1) ||
-   le16_to_cpu(mpi_request->FunctionDependent1) >
-   ioc->facts.MaxDevHandle) {
+   mpi_request->Function == MPI2_FUNCTION_RAID_SCSI_IO_PASSTHROUGH ||
+   mpi_request->Function == MPI2_FUNCTION_SCSI_TASK_MGMT ||
+   mpi_request->Function == MPI2_FUNCTION_SATA_PASSTHROUGH) {
+
+   device_handle = le16_to_cpu(mpi_request->FunctionDependent1);
+   if (!device_handle || (device_handle >
+   ioc->facts.MaxDevHandle)) {
ret = -EINVAL;
  

Re: [PATCH 02/10] mpt3sas: Fix for incorrect numbers for MSIX vectors enabled when non RDPQ card is enumerated first.

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

No. of MSIX vectors supported = min (Total no. of CPU cores,
MSIX vectors supported by card)

when RDPQ is disabled "max_msix_vectors" module parameter which was
declared as global was set to '8' and hence if there are more than one card
in system among which if RDPQ disabled card is enumerated first then only 8
MSIX vectors was getting enabled for all the cards(including RDPQ enabled
card,which can support more than 8 MSIX vectors).

Used local variable instead of global variable ,if RDPQ is disabled this
local variable is set to '8' else it is set to "max_msix_vectors" (by
default this is set to -1, whose value can be set by user during driver
load time).So now regardless of whether RDPQ disabled card is enumerated
first or RDPQ enabled card is enumerated first , MSIX vectors enabled
depends on the cards capability.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index a1a5ceb..4ea81e1 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1959,7 +1959,7 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
 {
struct msix_entry *entries, *a;
int r;
-   int i;
+   int i, local_max_msix_vectors;
u8 try_msix = 0;

if (msix_disable == -1 || msix_disable == 0)
@@ -1979,13 +1979,15 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
  ioc->cpu_count, max_msix_vectors);

if (!ioc->rdpq_array_enable && max_msix_vectors == -1)
-   max_msix_vectors = 8;
+   local_max_msix_vectors = 8;
+   else
+   local_max_msix_vectors = max_msix_vectors;

-   if (max_msix_vectors > 0) {
-   ioc->reply_queue_count = min_t(int, max_msix_vectors,
+   if (local_max_msix_vectors > 0) {
+   ioc->reply_queue_count = min_t(int, local_max_msix_vectors,
ioc->reply_queue_count);
ioc->msix_vector_count = ioc->reply_queue_count;
-   } else if (max_msix_vectors == 0)
+   } else if (local_max_msix_vectors == 0)
goto try_ioapic;

if (ioc->msix_vector_count < ioc->cpu_count)


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH 01/10] mpt3sas: Fix for improper info displayed in var log, while blocking or unblocking the device.

[Hannes Reinecke]

On 10/20/2016 02:20 PM, Suganath Prabu S wrote:

Return value and Device_handle Arguments passed in correct order
 to match with its format string.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 209a969..282ca40 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2837,7 +2837,7 @@ _scsih_internal_device_block(struct scsi_device *sdev,
if (r == -EINVAL)
sdev_printk(KERN_WARNING, sdev,
"device_block failed with return(%d) for handle(0x%04x)\n",
-   sas_device_priv_data->sas_target->handle, r);
+   r, sas_device_priv_data->sas_target->handle);
 }

 /**
@@ -2867,20 +2867,20 @@ _scsih_internal_device_unblock(struct scsi_device *sdev,
sdev_printk(KERN_WARNING, sdev,
"device_unblock failed with return(%d) for handle(0x%04x) "
"performing a block followed by an unblock\n",
-   sas_device_priv_data->sas_target->handle, r);
+   r, sas_device_priv_data->sas_target->handle);
sas_device_priv_data->block = 1;
r = scsi_internal_device_block(sdev);
if (r)
sdev_printk(KERN_WARNING, sdev, "retried device_block "
"failed with return(%d) for handle(0x%04x)\n",
-   sas_device_priv_data->sas_target->handle, r);
+   r, sas_device_priv_data->sas_target->handle);

sas_device_priv_data->block = 0;
r = scsi_internal_device_unblock(sdev, SDEV_RUNNING);
if (r)
sdev_printk(KERN_WARNING, sdev, "retried device_unblock"
" failed with return(%d) for handle(0x%04x)\n",
-   sas_device_priv_data->sas_target->handle, r);
+   r, sas_device_priv_data->sas_target->handle);
}
 }



Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH 1/1] libfc: don't have fc_exch_find log errors on a new exchange

[Hannes Reinecke]

On 10/21/2016 11:10 PM, Chris Leech wrote:

With the error message I added in "libfc: sanity check cpu number
extracted from xid" I didn't account for the fact that fc_exch_find is
called with FC_XID_UNKNOWN at the start of a new exchange if we are the
responder.

It doesn't come up with the initiator much, but that's basically every
exchange for a target.  By checking the xid for FC_XID_UNKNOWN first, we
not only prevent the erroneous error message, but skip the unnecessary
lookup attempt as well.

Signed-off-by: Chris Leech 
---
 drivers/scsi/libfc/fc_exch.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c
index 16ca31a..42cc403 100644
--- a/drivers/scsi/libfc/fc_exch.c
+++ b/drivers/scsi/libfc/fc_exch.c
@@ -910,6 +910,9 @@ static struct fc_exch *fc_exch_find(struct fc_exch_mgr *mp, 
u16 xid)
struct fc_exch *ep = NULL;
u16 cpu = xid & fc_cpu_mask;

+   if (xid == FC_XID_UNKNOWN)
+   return NULL;
+
if (cpu >= nr_cpu_ids || !cpu_possible(cpu)) {
printk_ratelimited(KERN_ERR
"libfc: lookup request for XID = %d, "


Does that still apply with my libfc patchset?
I was under the impression I've fixed it already ...

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH] sd: fix uninitialized variable access in error handling

[Hannes Reinecke]

On 10/21/2016 05:32 PM, Arnd Bergmann wrote:

If sd_zbc_report_zones fails, the check for 'zone_blocks == 0'
later in the function accesses uninitialized data:

drivers/scsi/sd_zbc.c: In function ‘sd_zbc_read_zones’:
drivers/scsi/sd_zbc.c:520:7: error: ‘zone_blocks’ may be used uninitialized in 
this function [-Werror=maybe-uninitialized]

This sets it to zero, which has the desired effect of leaving
the sd_zbc_read_zones successfully with sdkp->zone_blocks = 0.

Fixes: 89d947561077 ("sd: Implement support for ZBC devices")
Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/sd_zbc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c
index 16d3fa62d8ac..d5b3bd915d9e 100644
--- a/drivers/scsi/sd_zbc.c
+++ b/drivers/scsi/sd_zbc.c
@@ -455,8 +455,10 @@ static int sd_zbc_check_zone_size(struct scsi_disk *sdkp)

/* Do a report zone to get the same field */
ret = sd_zbc_report_zones(sdkp, buf, SD_ZBC_BUF_SIZE, 0);
-   if (ret)
+   if (ret) {
+   zone_blocks = 0;
goto out;
+   }

same = buf[4] & 0x0f;
if (same > 0) {


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH v3 5/8] megaraid_sas: Send SYNCHRONIZE_CACHE for VD to firmware

[Hannes Reinecke]

On 10/21/2016 03:33 PM, Kashyap Desai wrote:

From previous patch we have below changes in v2 (only for Virtual Disk)-
1.  Updated change log.  Provided more detail in change log.
2.  Agreed to remove module parameter. If we remove module parameter, we
can ask customer to disable WCE on drive to get similar impact.
3.  Always Send SYNCHRONIZE_CACHE  for JBOD (non Raid) Device to Firmware.

Current megaraid_sas driver returns SYNCHRONIZE_CACHE(related to Drive
Cache)  command  back to SCSI layer without sending it down to firmware as
firmware supposed to take care of flushing disk cache for all drives
belongs to Virtual Disk at the time of system reboot/shutdown.

We evaluate and understood that for Raid Volume, why driver should not
send SYNC_CACHE command to the Firmware.
There may be a some reason in past, but now it looks to be not required and
we have fixed this issue as part of this patch.

 - Additional background -
There are some instance of MegaRaid FW (E.a Gen2 and Gen2.5 FW) set WCE bit
for Virtual Disk but firmware does not reply correct status for SYNCH_CACHE.
It is very difficult to find out which Device ID and firmware has capability
to manage SYNC_CACHE, so we managed to figure out which are the new firmware
(canHandleSyncCache is set in scratch pad register at 0xB4) and use that
interface for correct behavior as explained above.

E.g Liberator/Thunderbolt MegaRaid FW returns SYNC_CACHE as Unsupported
command (this is a firmware bug) and eventually command will be failed to SML.
This will cause File system to go Read-only.

 - New behavior described -

IF application requests SYNCH_CACHE
   IF 'JBOD'
  Driver sends SYNCH_CACHE command to the FW
   FW sends SYNCH_CACHE to drive
   FW obtains status from drive and returns same status back to 
driver
   ELSEIF 'VirtualDisk'
   IF any FW which supports new API bit called canHandleSyncCache
  Driver sends SYNCH_CACHE command to the FW
  FW does not send SYNCH_CACHE to drives
  FW returns SUCCESS
   ELSE
  Driver does not send SYNCH_CACHE command to the 
FW.
  Driver return SUCCESS for that command.
   ENDIF
ENDIF
ENDIF

Signed-off-by: Kashyap Desai 
Signed-off-by: Sumit Saxena 
---
 drivers/scsi/megaraid/megaraid_sas.h| 3 +++
 drivers/scsi/megaraid/megaraid_sas_base.c   | 7 ++-
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 5 +
 3 files changed, 10 insertions(+), 5 deletions(-)


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH v3 8/8] megaraid_sas: driver version upgrade

[Hannes Reinecke]

On 10/21/2016 03:33 PM, Kashyap Desai wrote:

Signed-off-by: Sumit Saxena 
---
 drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 43fd14f..74c7b44 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -35,8 +35,8 @@
 /*
  * MegaRAID SAS Driver meta data
  */
-#define MEGASAS_VERSION"06.811.02.00-rc1"
-#define MEGASAS_RELDATE"April 12, 2016"
+#define MEGASAS_VERSION"06.812.07.00-rc1"
+#define MEGASAS_RELDATE"August 22, 2016"

 /*
  * Device IDs


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH v3 3/8] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach

[Hannes Reinecke]

On 10/21/2016 03:33 PM, Kashyap Desai wrote:

This patch addresses the issue of driver firing DCMDs in PCI
shutdown/detach path irrespective of firmware state.
Driver will check for whether firmware is operational state or not
before firing DCMDs. If firmware is in unrecoverbale
state or does not become operational within specfied time, driver will
skip firing DCMDs.

Signed-off-by: Sumit Saxena 
Signed-off-by: Shivasharan Srikanteshwara 

---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 39 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  9 ---
 2 files changed, 45 insertions(+), 3 deletions(-)


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

Re: [PATCH v3 4/8] megaraid_sas: Send SYNCHRONIZE_CACHE for non-raid to firmware

[Hannes Reinecke]

On 10/21/2016 03:33 PM, Kashyap Desai wrote:

Commit- " 02b01e0 [SCSI] megaraid_sas: return sync cache call with success"
added the code in driver to return SYNCHRONIZE_CACHE without sending it to
firmware back in 2007. Earlier MR was mainly for Virtual Disk,
so same code continue for JBOD as well whenever JBOD support was added and it 
introduced bug that
SYNCHRONIZE_CACHE is not passed to FW for JBOD (non Raid disk).

But our recent analysis indicates that, From Day-1 MR Firmware always
expect Driver to forward SYNCHRONIZE_CACHE for JBOD (non Raid disk) to the
Firmware.
We have fixed this as part of this patch.

CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai 
Signed-off-by: Sumit Saxena 
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index ba57be6..c98d4f9 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1700,16 +1700,13 @@ megasas_queue_command(struct Scsi_Host *shost, struct 
scsi_cmnd *scmd)
goto out_done;
}

-   switch (scmd->cmnd[0]) {
-   case SYNCHRONIZE_CACHE:
-   /*
-* FW takes care of flush cache on its own
-* No need to send it down
-*/
+   /*
+* FW takes care of flush cache on its own for Virtual Disk.
+* No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to 
FW.
+*/
+   if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
scmd->result = DID_OK << 16;
goto out_done;
-   default:
-   break;
}

return instance->instancet->build_and_issue_cmd(instance, scmd);


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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

[PATCH] block: Fix kernel panic occurs while creating second raid disk

[Sreekanth Reddy]

Observing below kernel panic while creating second raid disk
on LSI SAS3008 HBA card.

[  +0.55] [ cut here ]
[  +0.07] WARNING: CPU: 2 PID: 281 at fs/sysfs/dir.c:31 
sysfs_warn_dup+0x62/0x80
[  +0.02] sysfs: cannot create duplicate filename 
'/devices/virtual/bdi/8:32'
[  +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac 
edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif 
mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema 
acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc 
sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core 
scsi_transport_sas dca
[  +0.67] CPU: 2 PID: 281 Comm: kworker/u49:5 Not tainted 4.9.0-rc2 #1
[  +0.02] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 
07/22/2015
[  +0.05] Workqueue: events_unbound async_run_entry_fn
[  +0.04] Call Trace:
[  +0.09]  [] dump_stack+0x63/0x85
[  +0.05]  [] __warn+0xcb/0xf0
[  +0.04]  [] warn_slowpath_fmt+0x5f/0x80
[  +0.06]  [] ? kernfs_path_from_node+0x4f/0x60
[  +0.02]  [] sysfs_warn_dup+0x62/0x80
[  +0.02]  [] sysfs_create_dir_ns+0x77/0x90
[  +0.04]  [] kobject_add_internal+0x99/0x330
[  +0.03]  [] ? vsnprintf+0x35b/0x4c0
[  +0.03]  [] kobject_add+0x75/0xd0
[  +0.06]  [] ? device_private_init+0x23/0x70
[  +0.07]  [] ? mutex_lock+0x12/0x30
[  +0.03]  [] device_add+0x119/0x670
[  +0.04]  [] device_create_groups_vargs+0xe0/0xf0
[  +0.03]  [] device_create_vargs+0x1c/0x20
[  +0.06]  [] bdi_register+0x8c/0x180
[  +0.03]  [] bdi_register_owner+0x36/0x60
[  +0.06]  [] device_add_disk+0x168/0x480
[  +0.05]  [] ? update_autosuspend+0x51/0x60
[  +0.05]  [] sd_probe_async+0x110/0x1c0
[  +0.02]  [] async_run_entry_fn+0x39/0x140
[  +0.03]  [] process_one_work+0x15f/0x430
[  +0.02]  [] worker_thread+0x4e/0x490
[  +0.02]  [] ? process_one_work+0x430/0x430
[  +0.03]  [] kthread+0xd9/0xf0
[  +0.03]  [] ? kthread_park+0x60/0x60
[  +0.03]  [] ret_from_fork+0x25/0x30
[  +0.02] [ cut here ]
[  +0.04] WARNING: CPU: 2 PID: 281 at lib/kobject.c:240 
kobject_add_internal+0x2bd/0x330
[  +0.01] kobject_add_internal failed for 8:32 with -EEXIST, don't try to 
register things with the same name in the same
[  +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac 
edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif 
mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema 
acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc 
sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core 
scsi_transport_sas dca
[  +0.43] CPU: 2 PID: 281 Comm: kworker/u49:5 Tainted: GW   
4.9.0-rc2 #1
[  +0.01] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 
07/22/2015
[  +0.02] Workqueue: events_unbound async_run_entry_fn
[  +0.03] Call Trace:
[  +0.03]  [] dump_stack+0x63/0x85
[  +0.03]  [] __warn+0xcb/0xf0
[  +0.04]  [] warn_slowpath_fmt+0x5f/0x80
[  +0.02]  [] ? sysfs_warn_dup+0x6a/0x80
[  +0.03]  [] kobject_add_internal+0x2bd/0x330
[  +0.03]  [] ? vsnprintf+0x35b/0x4c0
[  +0.03]  [] kobject_add+0x75/0xd0
[  +0.03]  [] ? device_private_init+0x23/0x70
[  +0.04]  [] ? mutex_lock+0x12/0x30
[  +0.02]  [] device_add+0x119/0x670
[  +0.04]  [] device_create_groups_vargs+0xe0/0xf0
[  +0.03]  [] device_create_vargs+0x1c/0x20
[  +0.03]  [] bdi_register+0x8c/0x180
[  +0.03]  [] bdi_register_owner+0x36/0x60
[  +0.04]  [] device_add_disk+0x168/0x480
[  +0.03]  [] ? update_autosuspend+0x51/0x60
[  +0.02]  [] sd_probe_async+0x110/0x1c0
[  +0.02]  [] async_run_entry_fn+0x39/0x140
[  +0.02]  [] process_one_work+0x15f/0x430
[  +0.02]  [] worker_thread+0x4e/0x490
[  +0.02]  [] ? process_one_work+0x430/0x430
[  +0.03]  [] kthread+0xd9/0xf0
[  +0.03]  [] ? kthread_park+0x60/0x60
[  +0.03]  [] ret_from_fork+0x25/0x30
[  +0.000949] BUG: unable to handle kernel
[  +0.005263] NULL pointer dereference
[  +0.002853] IP: [] sysfs_do_create_link_sd.isra.2+0x34/0xb0
[  +0.008584] PGD 0

[  +0.006115] Oops:  [#1] SMP
[  +0.004531] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac 
edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif 
mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 

Re: [PATCH 1/1] libfc: don't have fc_exch_find log errors on a new exchange

[Ewan D. Milne]

On Fri, 2016-10-21 at 14:10 -0700, Chris Leech wrote:
> With the error message I added in "libfc: sanity check cpu number
> extracted from xid" I didn't account for the fact that fc_exch_find is
> called with FC_XID_UNKNOWN at the start of a new exchange if we are the
> responder.
> 
> It doesn't come up with the initiator much, but that's basically every
> exchange for a target.  By checking the xid for FC_XID_UNKNOWN first, we
> not only prevent the erroneous error message, but skip the unnecessary
> lookup attempt as well.
> 
> Signed-off-by: Chris Leech 
> ---
>  drivers/scsi/libfc/fc_exch.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c
> index 16ca31a..42cc403 100644
> --- a/drivers/scsi/libfc/fc_exch.c
> +++ b/drivers/scsi/libfc/fc_exch.c
> @@ -910,6 +910,9 @@ static struct fc_exch *fc_exch_find(struct fc_exch_mgr 
> *mp, u16 xid)
>   struct fc_exch *ep = NULL;
>   u16 cpu = xid & fc_cpu_mask;
>  
> + if (xid == FC_XID_UNKNOWN)
> + return NULL;
> +
>   if (cpu >= nr_cpu_ids || !cpu_possible(cpu)) {
>   printk_ratelimited(KERN_ERR
>   "libfc: lookup request for XID = %d, "

Reviewed-by: Ewan D. Milne 


--
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

RE: Device or HBA level QD throttling creates randomness in sequetial workload

[Kashyap Desai]

>
> On Fri, Oct 21, 2016 at 05:43:35PM +0530, Kashyap Desai wrote:
> > Hi -
> >
> > I found below conversation and it is on the same line as I wanted some
> > input from mailing list.
> >
> > http://marc.info/?l=linux-kernel=147569860526197=2
> >
> > I can do testing on any WIP item as Omar mentioned in above
discussion.
> > https://github.com/osandov/linux/tree/blk-mq-iosched

I tried build kernel using this repo, but looks like it is not allowed to
reboot due to some changes in  layer.

>
> Are you using blk-mq for this disk? If not, then the work there won't
affect you.

YES. I am using blk-mq for my test. I also confirm if use_blk_mq is
disable, Sequential work load issue is not seen and  scheduling works
well.

>
> > Is there any workaround/alternative in latest upstream kernel, if user
> > wants to see limited penalty  for Sequential Work load on HDD ?
> >
> > ` Kashyap
> >
--
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

Re: [PATCH v3 5/6] scsi: replace custom approach to hexdump small buffers

[Ewan D. Milne]

On Sat, 2016-10-22 at 20:32 +0300, Andy Shevchenko wrote:
> In kernel we have defined specifier (%*ph[C]) to dump small buffers in a hex
> format. Replace custom approach by a generic one.
> 
> Cc: Jon Mason 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/scsi/scsi_transport_srp.c | 11 +--
>  drivers/scsi/sd.c |  4 +---
>  2 files changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/scsi/scsi_transport_srp.c 
> b/drivers/scsi/scsi_transport_srp.c
> index e3cd3ec..02cfc6b 100644
> --- a/drivers/scsi/scsi_transport_srp.c
> +++ b/drivers/scsi/scsi_transport_srp.c
> @@ -115,21 +115,12 @@ static DECLARE_TRANSPORT_CLASS(srp_host_class, 
> "srp_host", srp_host_setup,
>  static DECLARE_TRANSPORT_CLASS(srp_rport_class, "srp_remote_ports",
>  NULL, NULL, NULL);
>  
> -#define SRP_PID(p) \
> - (p)->port_id[0], (p)->port_id[1], (p)->port_id[2], (p)->port_id[3], \
> - (p)->port_id[4], (p)->port_id[5], (p)->port_id[6], (p)->port_id[7], \
> - (p)->port_id[8], (p)->port_id[9], (p)->port_id[10], (p)->port_id[11], \
> - (p)->port_id[12], (p)->port_id[13], (p)->port_id[14], (p)->port_id[15]
> -
> -#define SRP_PID_FMT "%02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x:" \
> - "%02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x"
> -
>  static ssize_t
>  show_srp_rport_id(struct device *dev, struct device_attribute *attr,
> char *buf)
>  {
>   struct srp_rport *rport = transport_class_to_srp_rport(dev);
> - return sprintf(buf, SRP_PID_FMT "\n", SRP_PID(rport));
> + return sprintf(buf, "%16phC\n", rport->port_id);
>  }
>  
>  static DEVICE_ATTR(port_id, S_IRUGO, show_srp_rport_id, NULL);
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index b9618ff..5634b54 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2472,9 +2472,7 @@ sd_read_write_protect_flag(struct scsi_disk *sdkp, 
> unsigned char *buffer)
>   if (sdkp->first_scan || old_wp != sdkp->write_prot) {
>   sd_printk(KERN_NOTICE, sdkp, "Write Protect is %s\n",
> sdkp->write_prot ? "on" : "off");
> - sd_printk(KERN_DEBUG, sdkp,
> -   "Mode Sense: %02x %02x %02x %02x\n",
> -   buffer[0], buffer[1], buffer[2], buffer[3]);
> + sd_printk(KERN_DEBUG, sdkp, "Mode Sense: %4ph\n", 
> buffer);
>   }
>   }
>  }

Reviewed-by: Ewan D. Milne 



--
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

Re: [PATCH v3 4/6] [SCSI] ips: don't use custom hex_asc_upper[] table

[Ewan D. Milne]

On Sat, 2016-10-22 at 20:32 +0300, Andy Shevchenko wrote:
> From: Andy Shevchenko 
> 
> We have table of the HEX characters in the kernel. Replace custom by a generic
> one.
> 
> Cc: Adaptec OEM Raid Solutions 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/scsi/ips.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
> index 02cb76f..3419e1b 100644
> --- a/drivers/scsi/ips.c
> +++ b/drivers/scsi/ips.c
> @@ -2241,9 +2241,6 @@ ips_get_bios_version(ips_ha_t * ha, int intr)
>   uint8_t minor;
>   uint8_t subminor;
>   uint8_t *buffer;
> - char hexDigits[] =
> - { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C',
> - 'D', 'E', 'F' };
>  
>   METHOD_TRACE("ips_get_bios_version", 1);
>  
> @@ -2374,13 +2371,13 @@ ips_get_bios_version(ips_ha_t * ha, int intr)
>   }
>   }
>  
> - ha->bios_version[0] = hexDigits[(major & 0xF0) >> 4];
> + ha->bios_version[0] = hex_asc_upper_hi(major);
>   ha->bios_version[1] = '.';
> - ha->bios_version[2] = hexDigits[major & 0x0F];
> - ha->bios_version[3] = hexDigits[subminor];
> + ha->bios_version[2] = hex_asc_upper_lo(major);
> + ha->bios_version[3] = hex_asc_upper_lo(subminor);
>   ha->bios_version[4] = '.';
> - ha->bios_version[5] = hexDigits[(minor & 0xF0) >> 4];
> - ha->bios_version[6] = hexDigits[minor & 0x0F];
> + ha->bios_version[5] = hex_asc_upper_hi(minor);
> + ha->bios_version[6] = hex_asc_upper_lo(minor);
>   ha->bios_version[7] = 0;
>  }
>  

Reviewed-by: Ewan D. Milne 


--
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

Re: [PATCH v3 3/6] scsi: qla4xxx: print MAC and SID via %p[mM][R]

[Ewan D. Milne]

On Sat, 2016-10-22 at 20:32 +0300, Andy Shevchenko wrote:
> From: Oleksandr Khoshaba 
> 
> In the kernel we have nice specifier to print MAC by given pointer to the
> address in a binary form.
> 
> Signed-off-by: Oleksandr Khoshaba 
> Acked-by: Vikas Chaudhary 
> Cc: qlogic-storage-upstr...@qlogic.com
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/scsi/qla4xxx/ql4_mbx.c |  5 +
>  drivers/scsi/qla4xxx/ql4_nx.c  |  8 ++--
>  drivers/scsi/qla4xxx/ql4_os.c  | 15 ---
>  3 files changed, 7 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c b/drivers/scsi/qla4xxx/ql4_mbx.c
> index c291fdf..1da04f3 100644
> --- a/drivers/scsi/qla4xxx/ql4_mbx.c
> +++ b/drivers/scsi/qla4xxx/ql4_mbx.c
> @@ -2032,10 +2032,7 @@ int qla4xxx_set_param_ddbentry(struct scsi_qla_host 
> *ha,
>   ptid = (uint16_t *)_ddb_entry->isid[1];
>   *ptid = cpu_to_le16((uint16_t)ddb_entry->sess->target_id);
>  
> - DEBUG2(ql4_printk(KERN_INFO, ha, "ISID [%02x%02x%02x%02x%02x%02x]\n",
> -   fw_ddb_entry->isid[5], fw_ddb_entry->isid[4],
> -   fw_ddb_entry->isid[3], fw_ddb_entry->isid[2],
> -   fw_ddb_entry->isid[1], fw_ddb_entry->isid[0]));
> + DEBUG2(ql4_printk(KERN_INFO, ha, "ISID [%pmR]\n", fw_ddb_entry->isid));
>  
>   iscsi_opts = le16_to_cpu(fw_ddb_entry->iscsi_options);
>   memset(fw_ddb_entry->iscsi_alias, 0, sizeof(fw_ddb_entry->iscsi_alias));
> diff --git a/drivers/scsi/qla4xxx/ql4_nx.c b/drivers/scsi/qla4xxx/ql4_nx.c
> index 06ddd13..bccd8b6 100644
> --- a/drivers/scsi/qla4xxx/ql4_nx.c
> +++ b/drivers/scsi/qla4xxx/ql4_nx.c
> @@ -4094,12 +4094,8 @@ int qla4_8xxx_get_sys_info(struct scsi_qla_host *ha)
>   ha->phy_port_num = sys_info->port_num;
>   ha->iscsi_pci_func_cnt = sys_info->iscsi_pci_func_cnt;
>  
> - DEBUG2(printk("scsi%ld: %s: "
> - "mac %02x:%02x:%02x:%02x:%02x:%02x "
> - "serial %s\n", ha->host_no, __func__,
> - ha->my_mac[0], ha->my_mac[1], ha->my_mac[2],
> - ha->my_mac[3], ha->my_mac[4], ha->my_mac[5],
> - ha->serial_number));
> + DEBUG2(printk("scsi%ld: %s: mac %pM serial %s\n",
> + ha->host_no, __func__, ha->my_mac, ha->serial_number));
>  
>   status = QLA_SUCCESS;
>  
> diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
> index 01c3610..9fbb33f 100644
> --- a/drivers/scsi/qla4xxx/ql4_os.c
> +++ b/drivers/scsi/qla4xxx/ql4_os.c
> @@ -6304,13 +6304,9 @@ static int qla4xxx_compare_tuple_ddb(struct 
> scsi_qla_host *ha,
>* ISID would not match firmware generated ISID.
>*/
>   if (is_isid_compare) {
> - DEBUG2(ql4_printk(KERN_INFO, ha, "%s: old ISID [%02x%02x%02x"
> - "%02x%02x%02x] New ISID [%02x%02x%02x%02x%02x%02x]\n",
> - __func__, old_tddb->isid[5], old_tddb->isid[4],
> - old_tddb->isid[3], old_tddb->isid[2], old_tddb->isid[1],
> - old_tddb->isid[0], new_tddb->isid[5], new_tddb->isid[4],
> - new_tddb->isid[3], new_tddb->isid[2], new_tddb->isid[1],
> - new_tddb->isid[0]));
> + DEBUG2(ql4_printk(KERN_INFO, ha,
> + "%s: old ISID [%pmR] New ISID [%pmR]\n",
> + __func__, old_tddb->isid, new_tddb->isid));
>  
>   if (memcmp(_tddb->isid[0], _tddb->isid[0],
>  sizeof(old_tddb->isid)))
> @@ -7925,10 +7921,7 @@ qla4xxx_sysfs_ddb_get_param(struct 
> iscsi_bus_flash_session *fnode_sess,
>   rc = sprintf(buf, "%u\n", fnode_conn->keepalive_timeout);
>   break;
>   case ISCSI_FLASHNODE_ISID:
> - rc = sprintf(buf, "%02x%02x%02x%02x%02x%02x\n",
> -  fnode_sess->isid[0], fnode_sess->isid[1],
> -  fnode_sess->isid[2], fnode_sess->isid[3],
> -  fnode_sess->isid[4], fnode_sess->isid[5]);
> + rc = sprintf(buf, "%pm\n", fnode_sess->isid);
>   break;
>   case ISCSI_FLASHNODE_TSID:
>   rc = sprintf(buf, "%u\n", fnode_sess->tsid);

Reviewed-by: Ewan D. Milne 


--
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

Re: [PATCH v3 2/6] fusion: print lan address via %pMR

[Ewan D. Milne]

On Sat, 2016-10-22 at 20:32 +0300, Andy Shevchenko wrote:
> LAN MAC addresses can be printed directly using %pMR specifier.
> 
> Cc: Sathya Prakash 
> Cc: Chaitra P B 
> Cc: Suganath Prabu Subramani 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/message/fusion/mptbase.c | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/message/fusion/mptbase.c 
> b/drivers/message/fusion/mptbase.c
> index 89c7ed1..f82745c 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -2585,10 +2585,7 @@ mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int 
> sleepFlag)
>   (void) GetLanConfigPages(ioc);
>   a = 
> (u8*)>lan_cnfg_page1.HardwareAddressLow;
>   dprintk(ioc, printk(MYIOC_s_DEBUG_FMT
> - "LanAddr = %02X:%02X:%02X"
> - ":%02X:%02X:%02X\n",
> - ioc->name, a[5], a[4],
> - a[3], a[2], a[1], a[0]));
> + "LanAddr = %pMR\n", ioc->name, a));
>   }
>   break;
>  
> @@ -6783,8 +6780,7 @@ static int mpt_iocinfo_proc_show(struct seq_file *m, 
> void *v)
>   if (ioc->bus_type == FC) {
>   if (ioc->pfacts[p].ProtocolFlags & 
> MPI_PORTFACTS_PROTOCOL_LAN) {
>   u8 *a = 
> (u8*)>lan_cnfg_page1.HardwareAddressLow;
> - seq_printf(m, "LanAddr = 
> %02X:%02X:%02X:%02X:%02X:%02X\n",
> - a[5], a[4], a[3], a[2], a[1], 
> a[0]);
> + seq_printf(m, "LanAddr = %pMR\n", a);
>   }
>   seq_printf(m, "WWN = %08X%08X:%08X%08X\n",
>   ioc->fc_port_page0[p].WWNN.High,
> @@ -6861,8 +6857,7 @@ mpt_print_ioc_summary(MPT_ADAPTER *ioc, char *buffer, 
> int *size, int len, int sh
>  
>   if (showlan && (ioc->pfacts[0].ProtocolFlags & 
> MPI_PORTFACTS_PROTOCOL_LAN)) {
>   u8 *a = (u8*)>lan_cnfg_page1.HardwareAddressLow;
> - y += sprintf(buffer+len+y, ", 
> LanAddr=%02X:%02X:%02X:%02X:%02X:%02X",
> - a[5], a[4], a[3], a[2], a[1], a[0]);
> + y += sprintf(buffer+len+y, ", LanAddr=%pMR", a);
>   }
>  
>   y += sprintf(buffer+len+y, ", IRQ=%d", ioc->pci_irq);
> @@ -6896,8 +6891,7 @@ static void seq_mpt_print_ioc_summary(MPT_ADAPTER *ioc, 
> struct seq_file *m, int
>  
>   if (showlan && (ioc->pfacts[0].ProtocolFlags & 
> MPI_PORTFACTS_PROTOCOL_LAN)) {
>   u8 *a = (u8*)>lan_cnfg_page1.HardwareAddressLow;
> - seq_printf(m, ", LanAddr=%02X:%02X:%02X:%02X:%02X:%02X",
> - a[5], a[4], a[3], a[2], a[1], a[0]);
> + seq_printf(m, ", LanAddr=%pMR", a);
>   }
>  
>   seq_printf(m, ", IRQ=%d", ioc->pci_irq);

Reviewed-by: Ewan D. Milne 


--
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

Re: [PATCH v3 1/6] scsi: fnic: use kernel's '%pM' format option to print MAC

[Ewan D. Milne]

On Sat, 2016-10-22 at 20:32 +0300, Andy Shevchenko wrote:
> Instead of supplying each byte through stack let's use %pM specifier.
> 
> Cc: Hiral Patel 
> Cc: Suma Ramars 
> Acked-by: Tom Tucker 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/scsi/fnic/vnic_dev.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/scsi/fnic/vnic_dev.c b/drivers/scsi/fnic/vnic_dev.c
> index 9795d6f..ba69d61 100644
> --- a/drivers/scsi/fnic/vnic_dev.c
> +++ b/drivers/scsi/fnic/vnic_dev.c
> @@ -499,10 +499,7 @@ void vnic_dev_add_addr(struct vnic_dev *vdev, u8 *addr)
>  
>   err = vnic_dev_cmd(vdev, CMD_ADDR_ADD, , , wait);
>   if (err)
> - printk(KERN_ERR
> - "Can't add addr [%02x:%02x:%02x:%02x:%02x:%02x], %d\n",
> - addr[0], addr[1], addr[2], addr[3], addr[4], addr[5],
> - err);
> + pr_err("Can't add addr [%pM], %d\n", addr, err);
>  }
>  
>  void vnic_dev_del_addr(struct vnic_dev *vdev, u8 *addr)
> @@ -517,10 +514,7 @@ void vnic_dev_del_addr(struct vnic_dev *vdev, u8 *addr)
>  
>   err = vnic_dev_cmd(vdev, CMD_ADDR_DEL, , , wait);
>   if (err)
> - printk(KERN_ERR
> - "Can't del addr [%02x:%02x:%02x:%02x:%02x:%02x], %d\n",
> - addr[0], addr[1], addr[2], addr[3], addr[4], addr[5],
> - err);
> + pr_err("Can't del addr [%pM], %d\n", addr, err);
>  }
>  
>  int vnic_dev_notify_set(struct vnic_dev *vdev, u16 intr)

Reviewed-by: Ewan D. Milne 


--
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

Re: [PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

[Arnd Bergmann]

On Monday, October 24, 2016 3:34:27 PM CEST Binoy Jayan wrote:
> Hi Arnd
> 
> On 20 October 2016 at 14:36, Arnd Bergmann  wrote:
> > On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
> >> Semaphores are going away in the future, so replace the semaphore
> >> sync_request_sem with the a mutex lock. timeout_msecs is not used
> >> for the lock sync_request_sem, so remove the timed locking too.
> >>
> >> Signed-off-by: Binoy Jayan 
> >
> > The patch looks correct to me, but I think if you remove the support
> > for handling timeouts, you should update the prototype of
> > pqi_submit_raid_request_synchronous to no longer pass the timeout
> > argument in the first place.
> 
> But we still need "timeout_msecs" in a call to
> pqi_submit_raid_request_synchronous_with_io_request()
> 
> drivers/scsi/smartpqi/smartpqi_init.c +3484

Why? If it's always zero, we can remove that too.

Arnd
--
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

Re: [PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

[Binoy Jayan]

On 20 October 2016 at 14:40, Arnd Bergmann  wrote:
> On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
>> -   sema_init(_info->sync_request_sem,
>> -   PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS);
>> +   mutex_init(_info->sync_request_mutex);
>>
>
> Looking at this again, I see that PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS
> is '3', so this is in fact a counting semaphore rather than a mutex,
> and the conversion is changing the behavior.
>
> The patch can't go in unless you either show that it should be
> a normal mutex rather than a counting semaphore, or you find a way
> to keep the behavior the same.

This still holds true, will try changing this accordingly.

-Binoy
--
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

Re: [PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

[Binoy Jayan]

Hi Arnd

On 20 October 2016 at 14:36, Arnd Bergmann  wrote:
> On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
>> Semaphores are going away in the future, so replace the semaphore
>> sync_request_sem with the a mutex lock. timeout_msecs is not used
>> for the lock sync_request_sem, so remove the timed locking too.
>>
>> Signed-off-by: Binoy Jayan 
>
> The patch looks correct to me, but I think if you remove the support
> for handling timeouts, you should update the prototype of
> pqi_submit_raid_request_synchronous to no longer pass the timeout
> argument in the first place.

But we still need "timeout_msecs" in a call to
pqi_submit_raid_request_synchronous_with_io_request()

drivers/scsi/smartpqi/smartpqi_init.c +3484

-Binoy
--
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

RE: Crash in TCM-LIO

[Gurumurthy, Anil]

-Original Message-
From: Nicholas A. Bellinger [mailto:n...@linux-iscsi.org] 
Sent: 24 October 2016 12:30
To: Anil Gurumurthy 
Cc: linux-scsi ; Malavali, Giridhar 
; Tran, Quinn ; TomK 

Subject: Re: Crash in TCM-LIO

Hello Anil & Co,

On Mon, 2016-10-24 at 06:36 +, Anil Gurumurthy wrote:
> Hello Nicholas,
> 
>   I was trying to get DIF working on TCM-LIO with a QLogic FC adapter 
> on kernel version 4.7. I noticed a crash when there was an abort 
> received by the target with the following stack trace:
> 
>  

Thanks for reporting.

> 
> [71884.588748] BUG: unable to handle kernel NULL pointer dereference 
> at 00e0
> 
> [71884.51] IP: [] kmem_cache_free+0x11a/0x200
> 
> [71884.588981] PGD 0
> 
> [71884.589017] Oops:  [#1] SMP
> 
> [71884.589041] [ cut here ]
> 
> [71884.589048] WARNING: CPU: 2 PID: 20783 at lib/list_debug.c:62
> __list_del_entry+0x86/0xd0
> 
> [71884.589049] list_del corruption. next->prev should be 
> 8806f8daeb68, but was 8806f8db79e8
> 
> [71884.589075] Modules linked in: target_core_pscsi tcm_qla2xxx(OE)
> qla2xxx(OE) iscsi_target_mod target_core_file target_core_iblock 
> target_core_mod netconsole ebtable_nat ebtables ipt_MASQUERADE
> nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM 
> iptable_mangle bridge 8021q mrp garp stp llc ipt_REJECT nf_reject_ipv4
> nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT
> nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack 
> ip6table_filter ip6_tables binfmt_misc vhost_net macvtap macvlan vhost 
> tun uinput sg serio_raw iTCO_wdt iTCO_vendor_support ipmi_ssif ipmi_si 
> ipmi_msghandler hpilo hpwdt bnx2 intel_powerclamp coretemp kvm_intel 
> kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel 
> ghash_clmulni_intel pcspkr acpi_power_meter lpc_ich mfd_core 
> i7core_edac edac_core shpchp ext4(E) mbcache(E) jbd2(E) sd_mod(E)
> sr_mod(E) cdrom(E) scsi_transport_fc(E) hpsa(E) scsi_transport_sas(E)
> aesni_intel(E) ablk_helper(E) cryptd(E) lrw(E) gf128mul(E)
> glue_helper(E) pata_acpi(E) ata_generic(E) ata_piix(E) libata(E)
> radeon(E) ttm(E) drm_kms_helper(E) drm(E) fb_sys_fops(E) sysimgblt(E)
> sysfillrect(E) syscopyarea(E) i2c_algo_bit(E) i2c_core(E) dm_mirror(E)
> dm_region_hash(E) dm_log(E) dm_mod(E) [last unloaded: qla2xxx]
> 
> [71884.589091] CPU: 2 PID: 20783 Comm: kworker/2:0 Tainted: GW
> IOE   4.7.0-rc1+ #2
> 
> [71884.589092] Hardware name: HP ProLiant DL380 G7, BIOS P67
> 05/05/2011
> 
> [71884.589107] Workqueue: target_completion target_complete_ok_work 
> [target_core_mod]
> 
> [71884.589109]   880408d1fae8 81352197
> 81370ef6
> 
> [71884.589110]  880408d1fb48 880408d1fb48 
> 880408d1fb38
> 
> [71884.589111]  8108a12d 07c3 003e0246
> 0246
> 
> [71884.589112] Call Trace:
> 
> [71884.589115]  [] dump_stack+0x67/0x90
> 
> [71884.589117]  [] ? __list_del_entry+0x86/0xd0
> 
> [71884.589119]  [] __warn+0xfd/0x120
> 
> [71884.589120]  [] warn_slowpath_fmt+0x49/0x50
> 
> [71884.589122]  [] __list_del_entry+0x86/0xd0
> 
> [71884.589123]  [] list_del+0x11/0x40
> 
> [71884.589132]  [] target_remove_from_state_list
> +0x6e/0x80 [target_core_mod]
> 
> [71884.589140]  [] transport_cmd_check_stop
> +0xe4/0x120 [target_core_mod]
> 
> [71884.589151]  []
> transport_cmd_check_stop_to_fabric+0x15/0x20 [target_core_mod]
> 
> [71884.589160]  [] target_complete_ok_work
> +0x14e/0x280 [target_core_mod]
> 
> [71884.589162]  [] ? pwq_dec_nr_in_flight+0x50/0xa0
> 
> [71884.589164]  [] process_one_work+0x183/0x4d0
> 
> [71884.589166]  [] ? __schedule+0x1ff/0x5c0
> 
> [71884.589167]  [] ? schedule+0x40/0xb0
> 
> [71884.589169]  [] worker_thread+0x16d/0x530
> 
> [71884.589171]  [] ? __switch_to+0x1cd/0x5e0
> 
> [71884.589173]  [] ? __schedule+0x1ff/0x5c0
> 
> [71884.589175]  [] ? __wake_up_common+0x56/0x90
> 
> [71884.589177]  [] ? maybe_create_worker+0x120/0x120
> 
> [71884.589178]  [] ? schedule+0x40/0xb0
> 
> [71884.589179]  [] ? maybe_create_worker+0x120/0x120
> 
> [71884.589180]  [] kthread+0xcc/0xf0
> 
> [71884.589183]  [] ? do_syscall_64+0x78/0x1d0
> 
> [71884.589185]  [] ? schedule_tail+0x1e/0xc0
> 
> [71884.589188]  [] ret_from_fork+0x1f/0x40
> 
> [71884.589189]  [] ? kthread_freezable_should_stop
> +0x70/0x70
> 
> [71884.589190] ---[ end trace 7f24d6c863b6e35b ]---
> 
> [71884.589204] [ cut here ]
> 
> [71884.589206] WARNING: CPU: 2 PID: 20783 at lib/list_debug.c:59
> __list_del_entry+0xa5/0xd0
> 
>  

Was list corruption preceded by hung kernel task warnings..?

No. The only messages prior to them were similar to this:
[ 3345.864359] ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 1219168 
[ 3345.864378] qla2xxx [:0b:00.1]-e900:4: RESET-TMR 

RE: Crash in TCM-LIO

[Gurumurthy, Anil]

-Original Message-
From: Nicholas A. Bellinger [mailto:n...@linux-iscsi.org] 
Sent: 24 October 2016 12:30
To: Anil Gurumurthy 
Cc: linux-scsi ; Malavali, Giridhar 
; Tran, Quinn ; TomK 

Subject: Re: Crash in TCM-LIO

Hello Anil & Co,

On Mon, 2016-10-24 at 06:36 +, Anil Gurumurthy wrote:
> Hello Nicholas,
> 
>   I was trying to get DIF working on TCM-LIO with a QLogic FC adapter 
> on kernel version 4.7. I noticed a crash when there was an abort 
> received by the target with the following stack trace:
> 
>  

Thanks for reporting.

> 
> [71884.588748] BUG: unable to handle kernel NULL pointer dereference 
> at 00e0
> 
> [71884.51] IP: [] kmem_cache_free+0x11a/0x200
> 
> [71884.588981] PGD 0
> 
> [71884.589017] Oops:  [#1] SMP
> 
> [71884.589041] [ cut here ]
> 
> [71884.589048] WARNING: CPU: 2 PID: 20783 at lib/list_debug.c:62
> __list_del_entry+0x86/0xd0
> 
> [71884.589049] list_del corruption. next->prev should be 
> 8806f8daeb68, but was 8806f8db79e8
> 
> [71884.589075] Modules linked in: target_core_pscsi tcm_qla2xxx(OE)
> qla2xxx(OE) iscsi_target_mod target_core_file target_core_iblock 
> target_core_mod netconsole ebtable_nat ebtables ipt_MASQUERADE
> nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM 
> iptable_mangle bridge 8021q mrp garp stp llc ipt_REJECT nf_reject_ipv4
> nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT
> nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack 
> ip6table_filter ip6_tables binfmt_misc vhost_net macvtap macvlan vhost 
> tun uinput sg serio_raw iTCO_wdt iTCO_vendor_support ipmi_ssif ipmi_si 
> ipmi_msghandler hpilo hpwdt bnx2 intel_powerclamp coretemp kvm_intel 
> kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel 
> ghash_clmulni_intel pcspkr acpi_power_meter lpc_ich mfd_core 
> i7core_edac edac_core shpchp ext4(E) mbcache(E) jbd2(E) sd_mod(E)
> sr_mod(E) cdrom(E) scsi_transport_fc(E) hpsa(E) scsi_transport_sas(E)
> aesni_intel(E) ablk_helper(E) cryptd(E) lrw(E) gf128mul(E)
> glue_helper(E) pata_acpi(E) ata_generic(E) ata_piix(E) libata(E)
> radeon(E) ttm(E) drm_kms_helper(E) drm(E) fb_sys_fops(E) sysimgblt(E)
> sysfillrect(E) syscopyarea(E) i2c_algo_bit(E) i2c_core(E) dm_mirror(E)
> dm_region_hash(E) dm_log(E) dm_mod(E) [last unloaded: qla2xxx]
> 
> [71884.589091] CPU: 2 PID: 20783 Comm: kworker/2:0 Tainted: GW
> IOE   4.7.0-rc1+ #2
> 
> [71884.589092] Hardware name: HP ProLiant DL380 G7, BIOS P67
> 05/05/2011
> 
> [71884.589107] Workqueue: target_completion target_complete_ok_work 
> [target_core_mod]
> 
> [71884.589109]   880408d1fae8 81352197
> 81370ef6
> 
> [71884.589110]  880408d1fb48 880408d1fb48 
> 880408d1fb38
> 
> [71884.589111]  8108a12d 07c3 003e0246
> 0246
> 
> [71884.589112] Call Trace:
> 
> [71884.589115]  [] dump_stack+0x67/0x90
> 
> [71884.589117]  [] ? __list_del_entry+0x86/0xd0
> 
> [71884.589119]  [] __warn+0xfd/0x120
> 
> [71884.589120]  [] warn_slowpath_fmt+0x49/0x50
> 
> [71884.589122]  [] __list_del_entry+0x86/0xd0
> 
> [71884.589123]  [] list_del+0x11/0x40
> 
> [71884.589132]  [] target_remove_from_state_list
> +0x6e/0x80 [target_core_mod]
> 
> [71884.589140]  [] transport_cmd_check_stop
> +0xe4/0x120 [target_core_mod]
> 
> [71884.589151]  []
> transport_cmd_check_stop_to_fabric+0x15/0x20 [target_core_mod]
> 
> [71884.589160]  [] target_complete_ok_work
> +0x14e/0x280 [target_core_mod]
> 
> [71884.589162]  [] ? pwq_dec_nr_in_flight+0x50/0xa0
> 
> [71884.589164]  [] process_one_work+0x183/0x4d0
> 
> [71884.589166]  [] ? __schedule+0x1ff/0x5c0
> 
> [71884.589167]  [] ? schedule+0x40/0xb0
> 
> [71884.589169]  [] worker_thread+0x16d/0x530
> 
> [71884.589171]  [] ? __switch_to+0x1cd/0x5e0
> 
> [71884.589173]  [] ? __schedule+0x1ff/0x5c0
> 
> [71884.589175]  [] ? __wake_up_common+0x56/0x90
> 
> [71884.589177]  [] ? maybe_create_worker+0x120/0x120
> 
> [71884.589178]  [] ? schedule+0x40/0xb0
> 
> [71884.589179]  [] ? maybe_create_worker+0x120/0x120
> 
> [71884.589180]  [] kthread+0xcc/0xf0
> 
> [71884.589183]  [] ? do_syscall_64+0x78/0x1d0
> 
> [71884.589185]  [] ? schedule_tail+0x1e/0xc0
> 
> [71884.589188]  [] ret_from_fork+0x1f/0x40
> 
> [71884.589189]  [] ? kthread_freezable_should_stop
> +0x70/0x70
> 
> [71884.589190] ---[ end trace 7f24d6c863b6e35b ]---
> 
> [71884.589204] [ cut here ]
> 
> [71884.589206] WARNING: CPU: 2 PID: 20783 at lib/list_debug.c:59
> __list_del_entry+0xa5/0xd0
> 
>  

Was list corruption preceded by hung kernel task warnings..?

No. The only messages prior to them were similar to this:
[ 3345.864359] ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 1219168
[ 3345.864378] qla2xxx [:0b:00.1]-e900:4: RESET-TMR 

Re: [patch] zfcp: spin_lock_irqsave() is not nestable

[Christian Borntraeger]

On 10/14/2016 10:21 PM, Martin K. Petersen wrote:
>> "Steffen" == Steffen Maier  writes:
> 
> Steffen> could you please queue this as fix for one of my patches that
> Steffen> went into the 4.9 merge window, so for 4.9-rc I guess?
> 
> Applied to 4.9/scsi-fixes.
> 

FWIW, I do see rcu stall errors with 4.9-rc1 from time to time, so I assume
that this fix is not only theoretical but fixes a real life issue.

--
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

Re: Crash in TCM-LIO

[Nicholas A. Bellinger]

Hello Anil & Co,

On Mon, 2016-10-24 at 06:36 +, Anil Gurumurthy wrote:
> Hello Nicholas,
> 
>   I was trying to get DIF working on TCM-LIO with a QLogic FC adapter
> on kernel version 4.7. I noticed a crash when there was an abort
> received by the target with the following stack trace:
> 
>  

Thanks for reporting.

> 
> [71884.588748] BUG: unable to handle kernel NULL pointer dereference
> at 00e0
> 
> [71884.51] IP: [] kmem_cache_free+0x11a/0x200
> 
> [71884.588981] PGD 0
> 
> [71884.589017] Oops:  [#1] SMP
> 
> [71884.589041] [ cut here ]
> 
> [71884.589048] WARNING: CPU: 2 PID: 20783 at lib/list_debug.c:62
> __list_del_entry+0x86/0xd0
> 
> [71884.589049] list_del corruption. next->prev should be
> 8806f8daeb68, but was 8806f8db79e8
> 
> [71884.589075] Modules linked in: target_core_pscsi tcm_qla2xxx(OE)
> qla2xxx(OE) iscsi_target_mod target_core_file target_core_iblock
> target_core_mod netconsole ebtable_nat ebtables ipt_MASQUERADE
> nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM
> iptable_mangle bridge 8021q mrp garp stp llc ipt_REJECT nf_reject_ipv4
> nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT
> nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack
> ip6table_filter ip6_tables binfmt_misc vhost_net macvtap macvlan vhost
> tun uinput sg serio_raw iTCO_wdt iTCO_vendor_support ipmi_ssif ipmi_si
> ipmi_msghandler hpilo hpwdt bnx2 intel_powerclamp coretemp kvm_intel
> kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel
> ghash_clmulni_intel pcspkr acpi_power_meter lpc_ich mfd_core
> i7core_edac edac_core shpchp ext4(E) mbcache(E) jbd2(E) sd_mod(E)
> sr_mod(E) cdrom(E) scsi_transport_fc(E) hpsa(E) scsi_transport_sas(E)
> aesni_intel(E) ablk_helper(E) cryptd(E) lrw(E) gf128mul(E)
> glue_helper(E) pata_acpi(E) ata_generic(E) ata_piix(E) libata(E)
> radeon(E) ttm(E) drm_kms_helper(E) drm(E) fb_sys_fops(E) sysimgblt(E)
> sysfillrect(E) syscopyarea(E) i2c_algo_bit(E) i2c_core(E) dm_mirror(E)
> dm_region_hash(E) dm_log(E) dm_mod(E) [last unloaded: qla2xxx]
> 
> [71884.589091] CPU: 2 PID: 20783 Comm: kworker/2:0 Tainted: GW
> IOE   4.7.0-rc1+ #2
> 
> [71884.589092] Hardware name: HP ProLiant DL380 G7, BIOS P67
> 05/05/2011
> 
> [71884.589107] Workqueue: target_completion target_complete_ok_work
> [target_core_mod]
> 
> [71884.589109]   880408d1fae8 81352197
> 81370ef6
> 
> [71884.589110]  880408d1fb48 880408d1fb48 
> 880408d1fb38
> 
> [71884.589111]  8108a12d 07c3 003e0246
> 0246
> 
> [71884.589112] Call Trace:
> 
> [71884.589115]  [] dump_stack+0x67/0x90
> 
> [71884.589117]  [] ? __list_del_entry+0x86/0xd0
> 
> [71884.589119]  [] __warn+0xfd/0x120
> 
> [71884.589120]  [] warn_slowpath_fmt+0x49/0x50
> 
> [71884.589122]  [] __list_del_entry+0x86/0xd0
> 
> [71884.589123]  [] list_del+0x11/0x40
> 
> [71884.589132]  [] target_remove_from_state_list
> +0x6e/0x80 [target_core_mod]
> 
> [71884.589140]  [] transport_cmd_check_stop
> +0xe4/0x120 [target_core_mod]
> 
> [71884.589151]  []
> transport_cmd_check_stop_to_fabric+0x15/0x20 [target_core_mod]
> 
> [71884.589160]  [] target_complete_ok_work
> +0x14e/0x280 [target_core_mod]
> 
> [71884.589162]  [] ? pwq_dec_nr_in_flight+0x50/0xa0
> 
> [71884.589164]  [] process_one_work+0x183/0x4d0
> 
> [71884.589166]  [] ? __schedule+0x1ff/0x5c0
> 
> [71884.589167]  [] ? schedule+0x40/0xb0
> 
> [71884.589169]  [] worker_thread+0x16d/0x530
> 
> [71884.589171]  [] ? __switch_to+0x1cd/0x5e0
> 
> [71884.589173]  [] ? __schedule+0x1ff/0x5c0
> 
> [71884.589175]  [] ? __wake_up_common+0x56/0x90
> 
> [71884.589177]  [] ? maybe_create_worker+0x120/0x120
> 
> [71884.589178]  [] ? schedule+0x40/0xb0
> 
> [71884.589179]  [] ? maybe_create_worker+0x120/0x120
> 
> [71884.589180]  [] kthread+0xcc/0xf0
> 
> [71884.589183]  [] ? do_syscall_64+0x78/0x1d0
> 
> [71884.589185]  [] ? schedule_tail+0x1e/0xc0
> 
> [71884.589188]  [] ret_from_fork+0x1f/0x40
> 
> [71884.589189]  [] ? kthread_freezable_should_stop
> +0x70/0x70
> 
> [71884.589190] ---[ end trace 7f24d6c863b6e35b ]---
> 
> [71884.589204] [ cut here ]
> 
> [71884.589206] WARNING: CPU: 2 PID: 20783 at lib/list_debug.c:59
> __list_del_entry+0xa5/0xd0
> 
>  

Was list corruption preceded by hung kernel task warnings..?

> 
> On this particular kernel version (4.7), I am unable to get a crash
> dump, so cannot really fathom whats going on. 
> 

Note there is a v4.1+ reference leak regression for ABORT_TASK + session
shutdown here:

https://github.com/torvalds/linux/commit/527268df31e57cf2b6d417198717c6d6afdb1e3e

> Have you seen or have been notified of this behaviour?

TomK (CC') reported something similar using v4.8.4 with ESX hosts
ABORT_TASK + tcm/qla2xxx ports.

>   Any ideas/thoughts on how to proceed?
> 
>  

Currently unsure if this list corruption is related to the above

Re: Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

[Nicholas A. Bellinger]

Hi TomK,

Thanks for reporting this bug.  Comments inline below.

On Mon, 2016-10-24 at 00:45 -0400, TomK wrote:
> On 10/24/2016 12:32 AM, TomK wrote:
> > On 10/23/2016 10:03 PM, TomK wrote:
> >> Hey,
> >>
> >> Has anyone seen this and could have a workaround?  Seems like it is more
> >> Kernel related with various apps not just target apparently not but
> >> wondering if there is an interim solution
> >> (https://access.redhat.com/solutions/408833)
> >>
> >> Getting this message after few minutes of usage from the QLA2xxx driver.
> >>  This is after some activity on an ESXi server (15 VM's) that I'm
> >> connecting to this HBA.  I've tried the following tuning parameters but
> >> there was no change in behaviour:
> >>
> >> vm.dirty_background_ratio = 5
> >> vm.dirty_ratio = 10
> >>
> >> Details:
> >>
> >>
> >> Oct 23 21:28:25 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
> >> Oct 23 21:28:29 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx
> >> task_tag: 1128612
> >> Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Sending
> >> TMR_FUNCTION_COMPLETE for ref_tag: 1128612
> >> Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx
> >> task_tag: 1129116

You are likely hitting a known v4.1+ regression, not yet merged up to
v4.8.y code:

https://github.com/torvalds/linux/commit/527268df31e57cf2b6d417198717c6d6afdb1e3e

> >> Jan  6 23:52:00 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon
> >> successfully started
> >> Oct 23 21:30:18 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
> >> Jan  6 23:54:01 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon
> >> successfully started
> >> Oct 23 21:32:16 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
> >> Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/u16:8:289 blocked for
> >> more than 120 seconds.
> >> Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
> >> Oct 23 21:32:24 mbpc-pc kernel: "echo 0 >
> >> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> >> Oct 23 21:32:24 mbpc-pc kernel: kworker/u16:8   D 8803ba18 0
> >>   289  2 0x
> >> Oct 23 21:32:24 mbpc-pc kernel: Workqueue: tmr-fileio target_tmr_work
> >> [target_core_mod]
> >> Oct 23 21:32:24 mbpc-pc kernel: 8803ba18 0400
> >> 880049e926c0 8803b998
> >> Oct 23 21:32:24 mbpc-pc kernel: 88034600 81f99ca0
> >> 81f998ef 8801
> >> Oct 23 21:32:24 mbpc-pc kernel: 812f27d9 
> >> e8c9a000 8800
> >> Oct 23 21:32:24 mbpc-pc kernel: Call Trace:
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ? number+0x2e9/0x310
> >> Oct 23 21:32:24 mbpc-pc kernel: [] schedule+0x40/0xb0
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> start_flush_work+0x49/0x180
> >> Oct 23 21:32:24 mbpc-pc kernel: []
> >> schedule_timeout+0x9c/0xe0
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> flush_work+0x1a/0x40
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> console_unlock+0x35c/0x380
> >> Oct 23 21:32:24 mbpc-pc kernel: []
> >> wait_for_completion+0xc0/0xf0
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> try_to_wake_up+0x260/0x260
> >> Oct 23 21:32:24 mbpc-pc kernel: []
> >> __transport_wait_for_tasks+0xb4/0x1b0 [target_core_mod]
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> vprintk_default+0x1f/0x30
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ? printk+0x46/0x48
> >> Oct 23 21:32:24 mbpc-pc kernel: []
> >> transport_wait_for_tasks+0x44/0x60 [target_core_mod]
> >> Oct 23 21:32:24 mbpc-pc kernel: []
> >> core_tmr_abort_task+0xf2/0x160 [target_core_mod]
> >> Oct 23 21:32:24 mbpc-pc kernel: []
> >> target_tmr_work+0x154/0x160 [target_core_mod]
> >> Oct 23 21:32:24 mbpc-pc kernel: []
> >> process_one_work+0x189/0x4e0
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
> >> Oct 23 21:32:24 mbpc-pc kernel: []
> >> worker_thread+0x16d/0x520
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> default_wake_function+0x12/0x20
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> __wake_up_common+0x56/0x90
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> maybe_create_worker+0x110/0x110
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> maybe_create_worker+0x110/0x110
> >> Oct 23 21:32:24 mbpc-pc kernel: [] kthread+0xcc/0xf0
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> schedule_tail+0x1e/0xc0
> >> Oct 23 21:32:24 mbpc-pc kernel: []
> >> ret_from_fork+0x1f/0x40
> >> Oct 23 21:32:24 mbpc-pc kernel: [] ?
> >> kthread_freezable_should_stop+0x70/0x70
> >> Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/1:48:6089 blocked for
> >> more than 120 seconds.
> >> Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
> >> Oct 23 21:32:24 mbpc-pc kernel: "echo 0 >
> >> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> >> Oct 23 21:32:24 mbpc-pc kernel: kworker/1:48D 88004017f968 0
> >>  6089  2 0x0080
> >> Oct 23 21:32:24 mbpc-pc kernel: Workqueue: events qlt_free_session_done
> >> [qla2xxx]
> >> Oct 23 

Maxtor USB disk – "UNKNOWN(0x2003) Result" messages logged

[Mantas Mikulėnas]

Apologies if I'm posting to the wrong place; this is where I was
pointed to the last time I had USB storage questions.

I have a Maxtor (Seagate) "D3 Station" USB 3.0 SATA disk (0bc2:6125).
While it appears to work completely fine, every now and then the
following are logged in dmesg:

[Oct20 01:00] sd 3:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result:
hostbyte=0x07 driverbyte=0x08
[  +0.04] sd 3:0:0:0: [sdb] tag#0 Sense Key : 0x4 [current] [descriptor]
[  +0.03] sd 3:0:0:0: [sdb] tag#0 ASC=0x0 ASCQ=0x0
[  +0.03] sd 3:0:0:0: [sdb] tag#0 CDB: opcode=0x85 85 06 20 00 00
00 00 00 00 00 00 00 00 00 e5 00

[  +0.137088] sd 3:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result:
hostbyte=0x07 driverbyte=0x08
[  +0.03] sd 3:0:0:0: [sdb] tag#0 Sense Key : 0x4 [current] [descriptor]
[  +0.02] sd 3:0:0:0: [sdb] tag#0 ASC=0x0 ASCQ=0x0
[  +0.02] sd 3:0:0:0: [sdb] tag#0 CDB: opcode=0xa1 a1 06 20 da 00
00 4f c2 00 b0 00 00

When using smartctl (--health --device=sat), a similar message is also logged:

[Oct20 01:09] sd 3:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result:
hostbyte=0x07 driverbyte=0x08
[  +0.04] sd 3:0:0:0: [sdb] tag#0 Sense Key : 0x4 [current] [descriptor]
[  +0.01] sd 3:0:0:0: [sdb] tag#0 ASC=0x0 ASCQ=0x0
[  +0.03] sd 3:0:0:0: [sdb] tag#0 CDB: opcode=0x85 85 06 2c 00 da
00 00 00 00 00 4f 00 c2 00 b0 00

Are those the sign of a hardware problem or a kernel bug? (I'm running
4.8.2 at the moment.)

-- 
Mantas Mikulėnas 
--
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