Hello,
on my little X9SBAA mainboard, I'm faced with a strange phenomenon.
I've got two SATA drives at hand, one SSD, the other a regular
mechanical harddisk. As long as I connect the SSD to a PCI card (with
VIA VT6421 chipset), I can nicely boot from it (or use it in any other
way, for that matter).
But as soon as the SSD is connected to any of the on-board SATA ports
(which are wired to the 88SE9230), I'm getting error messages during
bootup of OpenBSD:
"ahci0: failed to stop port, cannot softreset"
The SSD remains inaccessible then, so during the bootup procedure, the
kernel will ask for an alternative root device at some point (see
output "B" below).
Both disks contain basic installations of OpenBSD-current (installed
onto them with a different machine), yesterday's snapshot. (I had seen
the same phenomenon with 5.8-stable, so I thought it was more useful
to try -current in the hope that the problem might have been fixed
already.)
Different attempts at booting OpenBSD on the X9SBAA board were made,
as follows - a few lines of output from each of those are given
(didn't want to spam this list with the entire dmesgs for the
different cases).
Case A: connect only the mechanical harddisk to on-board ports of
X9SBAA, and then boot from it:
OpenBSD 5.9-beta (GENERIC.MP) #1773: Wed Dec 23 01:42:40 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8556261376 (8159MB)
avail mem = 8292818944 (7908MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9510 (23 entries)
bios0: vendor American Megatrends Inc. version "1.1" date 04/29/2014
bios0: Supermicro X9SBAA
[...]
ahci0 at pci1 dev 0 function 0 "Marvell 88SE9230 AHCI" rev 0x10: msi,
AHCI 1.2
ahci0: port 0: 6.0Gb/s
ahci0: port 7: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, ST500LM000-SSHD-, LVD4> SCSI3
0/direct fixed naa.5000c5006c893eda
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
uk0 at scsibus1 targ 7 lun 0: <Marvell, Console, 1.01> ATAPI
3/processor removable
ppb1 at pci0 dev 2 function 0 "Intel Atom S1200 PCIE" rev 0x02
pci2 at ppb1 bus 2
[...]
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (178aae26ff9619d9.a) swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/sd0a (178aae26ff9619d9.a): file system is clean; not checking
/dev/sd0k (178aae26ff9619d9.k): file system is clean; not checking
/dev/sd0d (178aae26ff9619d9.d): file system is clean; not checking
[etc...]
So everything goes through without problems.
Case B: Use the SSD instead of the mechanical harddisk on one of the
internal ports, and try to boot from it:
[Normal bootup messages like above, up to this point:]
ahci0 at pci1 dev 0 function 0 "Marvell 88SE9230 AHCI" rev 0x10: msi,
AHCI 1.2
ahci0: port 0: 6.0Gb/s
ahci0: port 7: 1.5Gb/s
scsibus1 at ahci0: 32 targets
ahci0: failed to stop port, cannot softreset
ahci0: failed to stop port, cannot softreset
ahci0: failed to stop port, cannot softreset
ahci0: failed to stop port, cannot softreset
ppb1 at pci0 dev 2 function 0 "Intel Atom S1200 PCIE" rev 0x02
pci2 at ppb1 bus 2
[bootup seems to continue a little further then - note that neither
sd0 nor uk0 were found in this case]
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root device: ?
use one of: exit em0 em1
root device:
[here we're basically lost]
Case C: Connect the SSD to a VIA SATA card (in the PCI slot) - machine
boots up nicely:
[...]
pci4 at ppb3 bus 4
pciide0 at pci4 dev 0 function 0 "VIA VT6421 SATA" rev 0x50: DMA
pciide0: using apic 2 int 21 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: <ST200FP0021>
wd0: 16-sector PIO, LBA48, 190782MB, 390721968 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
ppb4 at pci0 dev 4 function 0 "Intel Atom S1200 PCIE" rev 0x02
pci5 at ppb4 bus 5
[...]
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (1e7b990af4950623.a) swap on wd0b dump on wd0b
Automatic boot in progress: starting file system checks.
/dev/wd0a (1e7b990af4950623.a): file system is clean; not checking
/dev/wd0k (1e7b990af4950623.k): file system is clean; not checking
/dev/wd0d (1e7b990af4950623.d): file system is clean; not checking
[etc...]
Now, I would really like to figure out why that Marvell thing is
acting up while the SSD is connected to it. I've tried running other
OSes on this board, among them FreeBSD, and they all boot without
problems from the SSD. But then again, why use other OSes when there's
OpenBSD?
It would be really brilliant if it were possible to do away with the
extra PCI board and run the SSD right from the on-board controller.
To be honest, I'm unsure where to even start debugging this, but I'm
open for suggestions. (Maybe make funky #defines when compiling the
kernel to turn on extra debugging, or maybe try to downgrade the
connection to the SSD from 6 Gbit/s to 3 Gbit/s if there's a way to do
this to see whether it helps, or change some timing parameters when
talking to the disk ... whatever you can come up with). SATA isn't
exactly my area of expertise, but I guess I've got some experience in
compiling kernels. ;)
OpenBSD's serial console has come in very handy in all of this, by the
way. Just put "machine comaddr 0xf000" and "set tty com4" in
/etc/boot.conf --> no need to put a VGA card into the board or connect
a keyboard to the USB3 ports. Very neat indeed.
Merry Xmas and sorry for being "a little" lengthy.
Christoph
