NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/54389: NetBSD fails to interoperate with qemu virtual SATA CDROM



>Number:         54389
>Category:       kern
>Synopsis:       NetBSD fails to interoperate with qemu virtual SATA CDROM
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 20 13:40:00 +0000 2019
>Originator:     Andreas Gustafsson
>Release:        NetBSD 8.1; also -current, source date 2019.07.20.03.54.50
>Organization:
>Environment:
System: NetBSD
Architecture: i386
Machine: i386
>Description:

By default, qemu-system-i386 emulates a 1996 vintage PC ("pc-i440fx-4.0"),
with an IDE CDROM.  NetBSD works fine on this, including the CDROM.

Qemu can also emulate newer PCs.  For example, by specifying "-machine
q35" on the qemu command line, it will emulate a 2009 vintage PC with
AHCI and a SATA CDROM.  However, if you try to install NetBSD on this,
the installation fails with errors from the cd0 device, such as:

  cd0(ahcisata0:1:0): Sense Error Code 0x50

>How-To-Repeat:

Run:

  anita install --vmm-args="-machine q35" http://ftp.netbsd.org/pub/NetBSD/NetBSD-8.1/i386/ | tee log

This will fail with a "loop detected" error as opening the CDROM
repeatedly fails and sysinst prompts for it the device name again.
Inspect the log for the "cd0(ahcisata0:5:0): Sense Error Code 0x50"
errors.

>Fix:

I believe I have found the cause of the errors: Qemu is insisting that
for ATAPI commands that return data, such as the "GET CONFIGURATION"
command (0x46), the ATAPI "BYTE COUNT LIMIT" field must contain a
nonzero value, but NetBSD is setting this field to zero when sending
the command over SATA.

The failing check in qemu happens in the function validate_bcl(), called
from ide_atapi_cmd().

The following patch to NetBSD makes installation work, by effectively
doing for SATA what the line

            xfer->c_bcount <= 0xffff ? xfer->c_bcount : 0xffff,

in sys/dev/scsipi/atapi_wdc.c does for ATA.  But since I'm not an
expert in this area, I'm not sure if this is the correct fix.
Could someone familiar with ATAPI and SATA please review?

Index: src/sys/dev/ata/satafis_subr.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ata/satafis_subr.c,v
retrieving revision 1.7
diff -u -r1.7 satafis_subr.c
--- src/sys/dev/ata/satafis_subr.c	22 Jul 2012 17:57:57 -0000	1.7
+++ src/sys/dev/ata/satafis_subr.c	20 Jul 2019 10:12:28 -0000
@@ -140,12 +140,16 @@
 void
 satafis_rhd_construct_atapi(struct ata_xfer *xfer, uint8_t *fis)
 {
+	int bcount16;
 
 	memset(fis, 0, RHD_FISLEN);
 
 	fis[fis_type] = RHD_FISTYPE;
 	fis[rhd_c] = RHD_C;
 	fis[rhd_command] = ATAPI_PKT_CMD;
+	bcount16 = xfer->c_bcount <= 0xffff ? xfer->c_bcount : 0xffff;
+	fis[rhd_lba1] = (bcount16 >> 0) & 0xff;
+	fis[rhd_lba2] = (bcount16 >> 8) & 0xff;
 	fis[rhd_features0] = (xfer->c_flags & C_DMA) ?
 	    ATAPI_PKT_CMD_FTRE_DMA : 0;
 }



Home | Main Index | Thread Index | Old Index