From nobody Wed Feb 15 19:26:33 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PH7P034NFz3rDqR for ; Wed, 15 Feb 2023 19:26:44 +0000 (UTC) (envelope-from SRS0=oYLu=6L=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PH7Nz0YGsz4Fg1; Wed, 15 Feb 2023 19:26:42 +0000 (UTC) (envelope-from SRS0=oYLu=6L=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of "SRS0=oYLu=6L=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=oYLu=6L=quip.cz=000.fbsd@elsa.codelab.cz"; dmarc=none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id EBF6DD7886; Wed, 15 Feb 2023 20:26:34 +0100 (CET) Received: from [192.168.145.50] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 90893D7885; Wed, 15 Feb 2023 20:26:33 +0100 (CET) Message-ID: Date: Wed, 15 Feb 2023 20:26:33 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: sym vs ncr driver for emulated LSI 53C895A Content-Language: cs-Cestina To: Stefan Esser Cc: freebsd-stable References: <4caf465e-4514-6dbb-1a65-8a27b9b1537e@quip.cz> From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.80 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=oYLu=6L=quip.cz=000.fbsd@elsa.codelab.cz]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=oYLu=6L=quip.cz=000.fbsd@elsa.codelab.cz]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[quip.cz]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PH7Nz0YGsz4Fg1 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On 10/02/2023 22:22, Stefan Esser wrote: > Am 09.02.23 um 20:04 schrieb Miroslav Lachman: >> I have FreeBSD 12.4 virtual machine installed inside KVM. This machine >> has 2 disks. One is 30GB connected as VirtIO vtbd0. There is installed >> system. The second is 20TB iSCSI connected to KVM and should be >> available inside VM as SCSI disk da0 but it is not. > > This is an emulated SCSI controller in KVM instead of a physical > controller on a PCI bus? As far as I know it is emulated by KVM. I search the net and found this for example: https://pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines#qm_hard_disk_bus "the SCSI controller, designed in 1985, is commonly found on server grade hardware, and can connect up to 14 storage devices. Proxmox VE emulates by default a LSI 53C895A controller. A SCSI controller of type VirtIO SCSI is the recommended setting if you aim for performance and is automatically selected for newly created Linux VMs since Proxmox VE 4.3. Linux distributions have support for this controller since 2012, and FreeBSD since 2014." > The device emulation may be incomplete and may therefore violate > assumptions made in the driver. The 53c8xx devices were complex > and the driver contains a "firmware" blob that has to be executed > using main CPU instructions by the emulated Symbios device. This > is extremely inefficient compared to other emulstions (it takes > hundreds of emulated controller instructions to execute trivial > SCSI transfers). > > Why can't you use the iSCSI driver to connect to an iscsi device? Because my VM does not have access to network where the iSCSI target is (for security reason) > Regarding the history of the ncr and sym drivers: > > I'm the co-author of the ncr driver, which originally supported only > the NCR53c810 chip. Later additions of this device family added WIDE > SCSI support and support for faster synchronous transfers, and their > support was added to the ncr driver. [..] > The ncr driver has been removed from later FreeBSD releases, since sym > covers all devices (since it is an extension of the ncr driver). Oh, thank you for the clarification, I thought ncr is newer than sym. So building ncr into kernel does not have any sense. [...] > The sym driver attached correctly, it should work. It has been more than > 10 years since I last used the driver and had a machine with SCSI drives. > > In the meantime Marius Strobl made a few changes to the driver, but I do > not know, whether he still has access to a system with that controller. > > The error messages: > >> (probe1:sym0:0:1:0): INQUIRY. CDB: 12 00 00 00 24 00 >> (probe1:sym0:0:1:0): CAM status: Command timeout >> (probe1:sym0:0:1:0): Retrying command, 3 more tries remain >> sym0:1: message c sent on bad reselection. >> sym0:1:control msgout: 80 6. > > The device should execute the INQUIRY command, but not reply was received > (the device did not reselect the controlled). Several attempts are made, > but the retries are exausted and the device is ignored. > > It seems that the selection/reselection and sending of SCSI messages is > not perfectly emulated. > > You may want to contact the author of the 53c895a emulation, since you'll > need debug output from that emulation in order to understand what's wrong. The administrator of KVM hypervisor changed some settings on the translation layer iSCSI / LSI emul. / VirtIO. Even if he told me I do not understand it well but now I see the disk correctly: # diskinfo -v da0 da0 512 # sectorsize 23747947921408 # mediasize in bytes (22T) 46382710784 # mediasize in sectors 0 # stripesize 0 # stripeoffset 2887190 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. QNAP iSCSI Storage # Disk descr. 194d2dd6-683a-42e1-9985-acd5580b119d # Disk ident. vtscsi0 # Attachment No # TRIM/UNMAP support Unknown # Rotation rate in RPM Not_Zoned # Zone Mode # pciconf -l -v sym0@pci0:0:7:0: class=0x010000 rev=0x00 hdr=0x00 vendor=0x1000 device=0x0012 subvendor=0x0000 subdevice=0x1000 vendor = 'Broadcom / LSI' device = '53c895a' class = mass storage subclass = SCSI virtio_pci2@pci0:0:8:0: class=0x010000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1004 subvendor=0x1af4 subdevice=0x0008 vendor = 'Red Hat, Inc.' device = 'Virtio SCSI' class = mass storage subclass = SCSI virtio_pci3@pci0:0:9:0: class=0x010000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1001 subvendor=0x1af4 subdevice=0x0002 vendor = 'Red Hat, Inc.' device = 'Virtio block device' class = mass storage subclass = SCSI virtio_pci0: port 0xc100-0xc17f mem 0xfc0b5000-0xfc0b5fff, 0xfebf0000-0xfebf3fff irq 10 at device 5.0 on pci0 vtblk0: on virtio_pci0 vtblk0: 30720MB (62914560 512 byte sectors) virtio_pci1: port 0xc240-0xc27f mem 0xfebf4000-0xfebf7ff f irq 10 at device 6.0 on pci0 vtballoon0: on virtio_pci1 sym0: <895a> port 0xc000-0xc0ff mem 0xfc0b6000-0xfc0b63ff,0xfc0b2000-0xfc0b3fff irq 11 at devi ce 7.0 on pci0 sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking virtio_pci2: port 0xc280-0xc2bf mem 0xfc0b7000-0xfc0b7fff,0 xfebf8000-0xfebfbfff irq 11 at device 8.0 on pci0 vtscsi0: on virtio_pci2 virtio_pci3: port 0xc180-0xc1ff mem 0xfc0b8000-0xfc0b8fff, 0xfebfc000-0xfebfffff irq 10 at device 9.0 on pci0 vtblk1: on virtio_pci3 vtblk1: 102400MB (209715200 512 byte sectors) da0 at vtscsi0 bus 0 scbus3 target 0 lun 0 da0: Fixed Direct Access SPC-3 SCSI device da0: Serial Number 194d2dd6-683a-42e1-9985-acd5580b119d da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 22647808MB (46382710784 512 byte sectors) So I assume the iSCSI device is now connected as VirtIO SCSI device on vtscsi0 / virtio_pci2. The important thing is that it works! I greatly appreciated your insightful reply and of course your work on ncr / sym. Thank you! Kind regards Miroslav Lachman