From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752529AbdEJJun (ORCPT ); Wed, 10 May 2017 05:50:43 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59430 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752494AbdEJJuk (ORCPT ); Wed, 10 May 2017 05:50:40 -0400 Subject: Re: [linux-next][bock] [bisected c20cfc27a] WARNING: CPU: 22 PID: 0 at block/blk-core.c:2655 .blk_update_request+0x4f8/0x500 From: Abdul Haleem To: Christoph Hellwig Cc: Jens Axboe , sachinp , "Martin K. Petersen" , Stephen Rothwell , linux-kernel , linux-block , linuxppc-dev Date: Wed, 10 May 2017 15:19:40 +0530 In-Reply-To: <20170510075642.GA10943@lst.de> References: <1493965539.7355.44.camel@abdul.in.ibm.com> <15a0a50a-d57d-736b-634c-4d0131ec5af3@kernel.dk> <1494227599.2983.2.camel@abdul.in.ibm.com> <1494343101.11532.4.camel@abdul.in.ibm.com> <20170510075642.GA10943@lst.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17051009-0008-0000-0000-0000012B648C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051009-0009-0000-0000-00000959D36C Message-Id: <1494409780.11532.14.camel@abdul.in.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-10_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705100069 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2017-05-10 at 09:56 +0200, Christoph Hellwig wrote: > On Tue, May 09, 2017 at 08:48:21PM +0530, Abdul Haleem wrote: > > A bisection for the above suspects resulted a bad commit; > > > > c20cfc27a47307e811346f85959cf3cc07ae42f9 is the first bad commit > > commit c20cfc27a47307e811346f85959cf3cc07ae42f9 > > Author: Christoph Hellwig > > Date: Wed Apr 5 19:21:07 2017 +0200 > > > > block: stop using blkdev_issue_write_same for zeroing > > And this effectively switches us to use the write_zeroes for SCSI. > > > > > > > We'll always use the WRITE ZEROES code for zeroing now. > > > > Signed-off-by: Christoph Hellwig > > Reviewed-by: Martin K. Petersen > > Reviewed-by: Hannes Reinecke > > Signed-off-by: Jens Axboe > > > > > > @Christoph FYI, the machine configured with 64K page size > > > > > > WARNING: CPU: 12 PID: 0 at block/blk-core.c:2651 .blk_update_request+0x4cc/0x4e0 > > Can you decode which warning this is? Is it: > > WARN_ON_ONCE(req->rq_flags & RQF_SPECIAL_PAYLOAD); Yes it is the one, the Warning shows up only once and if we look at the below stack trace there is only one WARN_ON_ONCE being called from blk_update_request function. WARNING: CPU: 12 PID: 0 at block/blk-core.c:2651 .blk_update_request +0x4cc/0x4e0 Modules linked in: sg(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) binfmt_misc(E) ip_tables(E) ext4(E) mbcache(E) jbd2(E) sd_mod(E) ibmvscsi(E) scsi_transport_srp(E) ibmveth(E) CPU: 12 PID: 0 Comm: swapper/12 Tainted: G E 4.11.0-autotest #1 task: c0000009f455ee80 task.stack: c0000009fb2e8000 NIP: c00000000050bd1c LR: c00000000050b8ec CTR: c0000000005114b0 REGS: c0000013fff73740 TRAP: 0700 Tainted: G E (4.11.0-autotest) MSR: 8000000000029032 CR: 48042048 XER: 00000001 CFAR: c00000000050bb34 SOFTE: 1 GPR00: c00000000050b8ec c0000013fff739c0 c000000001389c00 c0000009eca9c800 GPR04: 0000000000000000 0000000000000000 0000000000000001 0000000000000060 GPR08: 0000000000067887 0000000000000000 c0000009eca9c800 d00000000e5f7e30 GPR12: 0000000088044044 c00000000e9f6c00 c0000009fb2ebf90 0000000000200042 GPR16: 00000000ffff9367 c0000013fff70000 0000000000000000 c000000000df4100 GPR20: c0000000013c3b00 c000000000df4100 0000000000000000 0000000000000005 GPR24: 0000000000002ee0 c0000000017789f8 0000000000000000 0000000000000000 GPR28: 0000000000000000 c0000000038ba400 0000000000000000 c0000009eca9c800 NIP [c00000000050bd1c] .blk_update_request+0x4cc/0x4e0 LR [c00000000050b8ec] .blk_update_request+0x9c/0x4e0 Call Trace: [c0000013fff739c0] [c00000000050b8ec] .blk_update_request+0x9c/0x4e0 (unreliable) [c0000013fff73a60] [c0000000006b06fc] .scsi_end_request+0x4c/0x240 [c0000013fff73b10] [c0000000006b4564] .scsi_io_completion+0x1d4/0x6c0 [c0000013fff73be0] [c0000000006a8cd0] .scsi_finish_command+0x100/0x1b0 [c0000013fff73c70] [c0000000006b3978] .scsi_softirq_done+0x188/0x1e0 [c0000013fff73d00] [c000000000516b44] .blk_done_softirq+0xc4/0xf0 [c0000013fff73d90] [c0000000000daef8] .__do_softirq+0x158/0x3b0 [c0000013fff73e90] [c0000000000db5b8] .irq_exit+0x1a8/0x1c0 [c0000013fff73f10] [c000000000014f84] .__do_irq+0x94/0x1f0 [c0000013fff73f90] [c000000000026cbc] .call_do_irq+0x14/0x24 [c0000009fb2eb7f0] [c00000000001516c] .do_IRQ+0x8c/0x100 [c0000009fb2eb890] [c000000000008bf4] hardware_interrupt_common +0x114/0x120 --- interrupt: 501 at .plpar_hcall_norets+0x14/0x20 LR = .check_and_cede_processor+0x24/0x40 [c0000009fb2ebb80] [0000000000000002] 0x2 (unreliable) [c0000009fb2ebbf0] [c0000000007c360c] .dedicated_cede_loop+0x4c/0x150 [c0000009fb2ebc70] [c0000000007c1040] .cpuidle_enter_state+0xb0/0x3b0 [c0000009fb2ebd20] [c00000000012d1bc] .call_cpuidle+0x3c/0x70 [c0000009fb2ebd90] [c00000000012d550] .do_idle+0x280/0x2e0 [c0000009fb2ebe50] [c00000000012d768] .cpu_startup_entry+0x28/0x40 [c0000009fb2ebed0] [c0000000000428a4] .start_secondary+0x304/0x350 [c0000009fb2ebf90] [c00000000000aa6c] start_secondary_prolog+0x10/0x14 Instruction dump: 3f82ff90 3b9cc190 4bfffd8c 3f82ff90 3b9cc1a8 4bfffd80 61290040 b13f0018 4bfffbd4 3cc2ff8b 38c63160 4bfffd9c <0fe00000> 4bfffe18 60000000 60000000 ---[ end trace 0f80359f8fb9c5f4 ]--- > > ? In which case your setup did a partial completion of a WRITE SAME > command, which is perfectly legal according to SCSI, but a bit unusual. > -- Regard's Abdul Haleem IBM Linux Technology Centre