Re: [Qemu-devel] megasas: Unexpected response from lun 1 while scanning, scan aborted

From: Hannes Reinecke
Date: Thu Mar 28 2019 - 10:24:49 EST


On 3/28/19 1:47 AM, Dongli Zhang wrote:


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,

Hmm. Good point.

In _theory_ one could just jbod mode, in which case _all_ LUNs are exposed. But then we could probably adjust it, based on which mode is selected.
I'll check.

Cheers,

Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 NÃrnberg
GF: Felix ImendÃrffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG NÃrnberg)