Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp92714img; Wed, 27 Mar 2019 17:44:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqyFulufEmcAVI/aQ7VtB8+1QA9z84Mw3qz3TPxzxKxOuCaZ4Jp7DyNSnnnsJEXGuJsBXKKo X-Received: by 2002:a17:902:526:: with SMTP id 35mr37646392plf.276.1553733861004; Wed, 27 Mar 2019 17:44:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553733860; cv=none; d=google.com; s=arc-20160816; b=vqrLVOsMSjuxDcKdho6pIfe2jP0hm/28gfDqzQXEKaV3LajqRG/rW7plF1ZJbTA3RM sQPrWy2xcNhz9MWTy8fyM8qalCBZLEOqclL06cTf9kzm1vM/1d8v4ZCNsTpHJXutuiB/ 4h2GHDjNJ7XDTydTroUlZSOFsFOeATgTfkV0Z522sfPmrJZfFLwiSKec+uDxLorxRVK7 W9X0OxOYRVUZ00r7bbOqXuVSdfmIX5r0x0DxDPW/zmquxHYR2iIoL/5srQ//8uT2StEm H6u3u2njLvNjLOWfxLwOOnqmwDIAgAT1zTBRpsW5m3vH/a6GN/YoPDAPWkqvLh+FO1l9 rKTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=K4KGrj9DTxQpE3Z97Uz8xJr0r3YGRKAUWzS0FAdlioQ=; b=oh0apPYAXup8tIGicPG5UjLP4mKo1KFwyQX+x6DMw2wPd2QYAxpgD/UoiIvVj1qm3F sIxQag4gkWY7hjH+yFamlkCU1hsTqL2mQilMeRenJja3s9xqt8OWKBvwbN1HVOma9qxu 7oKVDBKkFLBqje/1s5fG3XKamvi/e/nfTHYTduyDTvqxBrSRTqwupFB+Kdxhb97gz3W1 NEQH1H5rfO0PQDicXD5f9t3Zr5F8dOh6iOO+QbK5cos8ufedvgQEQd8CVpQdpZXYpzQV T1D6FyO4Y74SrnQ+Qq5JiBSkOZmGcNb/6T/tFeT5uARf034mJ9AuO42n46XyevaG6/o6 bxiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=ed5nrXFZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z11si20201869pgc.145.2019.03.27.17.44.05; Wed, 27 Mar 2019 17:44:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=ed5nrXFZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727658AbfC1AnV (ORCPT + 99 others); Wed, 27 Mar 2019 20:43:21 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:54042 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726173AbfC1AnV (ORCPT ); Wed, 27 Mar 2019 20:43:21 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2S0cZdD184006; Thu, 28 Mar 2019 00:43:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=K4KGrj9DTxQpE3Z97Uz8xJr0r3YGRKAUWzS0FAdlioQ=; b=ed5nrXFZHxzE1fXagZdyHM+Ke3X9D7+699m9Qme7f1urHtbto12Tn47gtnIR5ZGolnKQ JPlNzKuEgTCRVZzWioahmvjhxBJZHXJ+z3A/hjDRdkGkjmpXNtvxc1mDmMNT7HNF5atq KBqG25Qs5tertcbB69b/GGMa/BjiDQleIJWBAkAAgqA21CvZFgD9455WgYUGijCaADLq cJx8QgBM34M93GYq25CJuAY5dABKR4/1OQwByxP/+z3hAKhM1sR+lc56XloSl3OwdUWi iua3lDfFwgi/UAEZMl38+ffOSPOVcnwb1VNW3We/9mp5M2coVGSTOe6wyryxMlnHMSkm jg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2re6g1bpfh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Mar 2019 00:43:13 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x2S0h8Ht008592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Mar 2019 00:43:08 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2S0h6RH025834; Thu, 28 Mar 2019 00:43:07 GMT Received: from [10.182.69.106] (/10.182.69.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Mar 2019 17:43:06 -0700 Subject: Re: [Qemu-devel] megasas: Unexpected response from lun 1 while scanning, scan aborted To: Hannes Reinecke Cc: qemu-block@nongnu.org, linux-scsi@vger.kernel.org, megaraidlinux.pdl@broadcom.com, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org References: <9c3849cf-86c6-4568-bff5-1050b445322d@default> From: Dongli Zhang Message-ID: <442316ee-8800-275c-85e9-a5d054a28e63@oracle.com> Date: Thu, 28 Mar 2019 08:47:13 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9208 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903280003 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/27/19 7:31 PM, Hannes Reinecke wrote: > On 3/26/19 5:47 PM, Dongli Zhang wrote: >> I am reporting an error that the scsi lun cannot initialize successfully when I >> am emulating megasas scsi controller with qemu. >> >> I am not sure if this is issue in qemu or linux kernel. >> >> When 'lun=1' is specified, there is "Unexpected response from lun 1 while >> scanning, scan aborted". >> >> Everything works well if 'lun=0' is specified. >> >> >> Below is the qemu cmdline involved: >> >> -device megasas,id=scsi0 \ >> -device scsi-hd,drive=drive0,bus=scsi0.0,lun=1 \ >> -drive file=/home/zhang/img/test.img,if=none,id=drive0,format=raw >> >> >> Below is the syslog related to 'scsi|SCSI' >> >> # dmesg | grep SCSI >> [    0.392494] SCSI subsystem initialized >> [    0.460666] Block layer SCSI generic (bsg) driver version 0.4 loaded (major >> 251) >> [    0.706788] sd 1:0:0:0: [sda] Attached SCSI disk >> # dmesg | grep scsi >> [    0.511643] scsi host0: Avago SAS based MegaRAID driver >> [    0.523302] scsi 0:2:0:0: Unexpected response from lun 1 while scanning, >> scan aborted >> [    0.540364] scsi host1: ata_piix >> [    0.540780] scsi host2: ata_piix >> [    0.702396] scsi 1:0:0:0: Direct-Access     ATA      QEMU HARDDISK    2.5+ >> PQ: 0 ANSI: 5 >> >> When 'lun=1' is changed to 'lun=0', there is no issue. >> >> Thank you very much! >> > That's an artifact from the megasas emulation in quemu. > Megasas (internally) can't handle LUN numbers (the RAID part only knows about > 'disks'), so I took the decision to not expose devices with LUN != 0. > Please use a different SCSI target number, not a non-zero LUN number. The guest kernel is able to detect the disk if lun is always 0, while target number is changed: -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -device scsi-hd,drive=drive1,bus=scsi0.0,channel=0,scsi-id=1,lun=0 # dmesg | grep scsi [ 0.935999] scsi host0: ata_piix [ 0.936401] scsi host1: ata_piix [ 1.100945] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 [ 1.102409] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 1.672952] scsi host2: Avago SAS based MegaRAID driver [ 1.683886] scsi 2:2:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 [ 1.684915] scsi 2:2:1:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 [ 1.701529] sd 2:2:0:0: Attached scsi generic sg1 type 0 [ 1.704795] sd 2:2:1:0: Attached scsi generic sg2 type 0 # dmesg | grep SCSI [ 0.111015] SCSI subsystem initialized [ 0.904712] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 246) [ 1.121174] sd 0:0:0:0: [sda] Attached SCSI disk [ 1.703739] sd 2:2:0:0: [sdb] Attached SCSI disk [ 1.706964] sd 2:2:1:0: [sdc] Attached SCSI disk If device with LUN != 0 will not be exposed, why not set max_lun = 0 as what qemu lsi is doing? diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c index a56317e..c966ee0 100644 --- a/hw/scsi/megasas.c +++ b/hw/scsi/megasas.c @@ -2298,7 +2298,7 @@ static void megasas_scsi_uninit(PCIDevice *d) static const struct SCSIBusInfo megasas_scsi_info = { .tcq = true, .max_target = MFI_MAX_LD, - .max_lun = 255, + .max_lun = 0, .transfer_data = megasas_xfer_complete, .get_sg_list = megasas_get_sg_list, Thank you very much! Dongli Zhang