NetBSD Problem Report #52372
From greywolf@starwolf.com Thu Jul 6 09:31:35 2017
Return-Path: <greywolf@starwolf.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 35E867A179
for <gnats-bugs@gnats.NetBSD.org>; Thu, 6 Jul 2017 09:31:35 +0000 (UTC)
Message-Id: <20170706081623.BC4D31A47E@eddie.starwolf.com>
Date: Thu, 6 Jul 2017 01:16:23 -0700 (PDT)
From: greywolf@starwolf.com
Reply-To: relayer@gmail.com
To: gnats-bugs@NetBSD.org
Subject: various SATA controllers throwing 'setting WDCTL_RST failed'
X-Send-Pr-Version: 3.95
>Number: 52372
>Notify-List: Petar Bogdanovic <petar@smokva.net>
>Category: kern
>Synopsis: various SATA controllers throwing 'setting WDCTL_RST failed'
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: jdolecek
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Jul 06 09:35:00 +0000 2017
>Closed-Date: Fri Apr 12 21:25:32 +0000 2019
>Last-Modified: Fri Feb 24 14:20:02 +0000 2023
>Originator: Grey Wolf
>Release: NetBSD 8.99.1
>Organization:
None to speak of
>Environment:
Motherboard: ASUS Z87-PLUS
CPU: Intel i7-4770
RAM: 32GB
ahcisata0: HighPoint Technologies RocketRaid 640
atabus0 thru atabus3 (ahcisata0 channels 0-3)
ahcisata1: Marvell SATA Controller 88SE9230 PCIe 6Gb/s RAID*
atabus4 thru atabus11 (ahcisata1 channels 0-7)
ahcisata2: ASMedia SATA controller [2 ports]
atabus12, atabus13 (ahcisata2 channels 0, 1)
ahcisata3: Marvell SATA Controller 88SE9230 PCIe 6Gb/s RAID*
atabus14 thru atabus21 (ahcisata3 channels 0-7)
ahcisata4: Intel 8C220 6-port SATA controller [AHCI mode]
atabus22 thru atabus25 (ahcisata4 channels 0-3)
DMESG at https://www.starwolf.com/machines/eddie/dmesg
DMI dump at https://www.starwolf.com/eddie/dmi
"EDDIE" is really, at this point, just a renamed GENERIC kernel,
until I can get it stable enough with the hardware to start paring
drivers out.
The two starred controllers (ahcisata1, ahcisata3) give me grief
(see below)
System: NetBSD eddie.starwolf.com 8.99.1 NetBSD 8.99.1 (EDDIE) #10: Thu Jun 15 21:39:22 PDT 2017 greywolf@eddie.starwolf.com:/sys/arch/amd64/compile/EDDIE amd64
Architecture: x86_64
Machine: amd64
>Description:
I have a machine with Bunch-O-Disks (12), mostly raid-mirrored.
If I have more than two disks plugged in to either Marvell SATA
controller, all disks on that controller fail with
"ahcisataN channel X: setting WDCTL_RST failed for drive 0"
If I have the root disk in this arrangement, the machine will boot
but will then fail to find the root device at which point it will
then ask me for the root device (and not accept keyboard input, but
that's for another ticket). This has caused me considerable grief,
especially considering that I don't really want to have 4 controllers
installed for 12 disks -- I should only need 3.
>How-To-Repeat:
Hook more than two drives up to a Marvell-core SATA Controller and
boot the box.
>Fix:
I have no idea even what's gone wrong, here.
>Release-Note:
>Audit-Trail:
From: "Jaromir Dolecek" <jdolecek@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/52372 CVS commit: [jdolecek-ncq] src/sys/dev/ic
Date: Fri, 21 Jul 2017 18:36:47 +0000
Module Name: src
Committed By: jdolecek
Date: Fri Jul 21 18:36:47 UTC 2017
Modified Files:
src/sys/dev/ic [jdolecek-ncq]: ahcisata_core.c
Log Message:
use free slot for drive reset, rather than always using slot zero; if we can't
get the slot, fallback to channel reset as usual
note this increases the odds of not being able to do the reset, when all slots
happen to be active
this is in same area as problem reported by PR kern/52372 but I
don't believe that this change actually make any change for it - during
probe/attach there shouldn't be any paralell request with drive reset
To generate a diff of this commit:
cvs rdiff -u -r1.57.6.18 -r1.57.6.19 src/sys/dev/ic/ahcisata_core.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Wed, 01 Nov 2017 11:40:31 +0000
State-Changed-Why:
Can you try more recent -current please? Behaviour might have changed after
the NCQ branch merge.
From: Petar Bogdanovic <petar@smokva.net>
To: gnats-bugs@NetBSD.org
Cc: jdolecek@NetBSD.org
Subject: Re: kern/52372: various SATA controllers throwing 'setting WDCTL_RST
failed'
Date: Sat, 9 Dec 2017 15:40:10 +0100
Same here with one HighPoint Rocket 640L adapter and four disks:
1 x Samsung SSD
3 x WD Blue 6TB
Fails with netbsd-8 and netbsd-current (8.12.2017),
works with netbsd-6-0.
Full dmesg here:
https://smokva.net/wdctl_rst/dmesg-nb8.txt
https://smokva.net/wdctl_rst/dmesg-nbC.txt
relevant part:
ahcisata0 port 0: device present, speed: 6.0Gb/s
ahcisata0 port 3: device present, speed: 6.0Gb/s
ahcisata0 port 1: device present, speed: 6.0Gb/s
ahcisata0 port 2: device present, speed: 6.0Gb/s
ahcisata0 port 7: device present, speed: 1.5Gb/s
ahcisata0 channel 0: setting WDCTL_RST failed for drive 0
ahcisata0 channel 3: setting WDCTL_RST failed for drive 0
ahcisata0 channel 7: setting WDCTL_RST failed for drive 0
ahcisata0 channel 1: setting WDCTL_RST failed for drive 0
Let me know if I can help; will try netbsd-7 later today.
Petar
P.S. I don't know what device is on port 7, maybe some proprietary
softraid implementation. Appears on nb6, nb8 and current.
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
relayer@gmail.com
Subject: Re: kern/52372: various SATA controllers throwing 'setting WDCTL_RST failed'
Date: Sat, 9 Dec 2017 17:22:06 +0100
--089e0826a108d74e49055feab3c0
Content-Type: multipart/alternative; boundary="089e0826a108d74e45055feab3bd"
--089e0826a108d74e45055feab3bd
Content-Type: text/plain; charset="UTF-8"
Thanks.
Can you try if attached patch makes any difference? It merely changes the
timeout for the command to 1s. It's not likely the problem since the
attached devices are supposed to be fast (SSD and very recent WD disks).
Other thing to check, is the controller set to 'AHCI' mode in BIOS and not
RAID or 'compatible' or some such?
Jaromir
2017-12-09 15:45 GMT+01:00 Petar Bogdanovic <petar@smokva.net>:
>
> The following reply was made to PR kern/52372; it has been noted by GNATS.
>
> From: Petar Bogdanovic <petar@smokva.net>
> To: gnats-bugs@NetBSD.org
> Cc: jdolecek@NetBSD.org
> Subject: Re: kern/52372: various SATA controllers throwing 'setting
WDCTL_RST
> failed'
> Date: Sat, 9 Dec 2017 15:40:10 +0100
>
> Same here with one HighPoint Rocket 640L adapter and four disks:
>
> 1 x Samsung SSD
> 3 x WD Blue 6TB
>
> Fails with netbsd-8 and netbsd-current (8.12.2017),
> works with netbsd-6-0.
>
> Full dmesg here:
>
> https://smokva.net/wdctl_rst/dmesg-nb8.txt
> https://smokva.net/wdctl_rst/dmesg-nbC.txt
>
> relevant part:
>
> ahcisata0 port 0: device present, speed: 6.0Gb/s
> ahcisata0 port 3: device present, speed: 6.0Gb/s
> ahcisata0 port 1: device present, speed: 6.0Gb/s
> ahcisata0 port 2: device present, speed: 6.0Gb/s
> ahcisata0 port 7: device present, speed: 1.5Gb/s
> ahcisata0 channel 0: setting WDCTL_RST failed for drive 0
> ahcisata0 channel 3: setting WDCTL_RST failed for drive 0
> ahcisata0 channel 7: setting WDCTL_RST failed for drive 0
> ahcisata0 channel 1: setting WDCTL_RST failed for drive 0
>
> Let me know if I can help; will try netbsd-7 later today.
>
> Petar
>
>
> P.S. I don't know what device is on port 7, maybe some proprietary
> softraid implementation. Appears on nb6, nb8 and current.
>
--089e0826a108d74e45055feab3bd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks.<div><br></div><div>Can you try if attached patch m=
akes any difference? It merely changes the timeout for the command to 1s. I=
t's not likely the problem since the attached devices are supposed to b=
e fast (SSD and very recent WD disks).<br><br>Other thing to check, is the =
controller set to 'AHCI' mode in BIOS and not RAID or 'compatib=
le' or some such?<div><br>Jaromir<br><br><br><br>2017-12-09 15:45 GMT+0=
1:00 Petar Bogdanovic <<a href=3D"mailto:petar@smokva.net">petar@smokva.=
net</a>>:<br>><br>> The following reply was made to PR kern/52372;=
it has been noted by GNATS.<br>><br>> From: Petar Bogdanovic <<a =
href=3D"mailto:petar@smokva.net">petar@smokva.net</a>><br>> To: gnats=
-bugs@NetBSD.org<br>> Cc: jdolecek@NetBSD.org<br>> Subject: Re: kern/=
52372: various SATA controllers throwing 'setting WDCTL_RST<br>> =C2=
=A0failed'<br>> Date: Sat, 9 Dec 2017 15:40:10 +0100<br>><br>>=
=C2=A0Same here with one HighPoint Rocket 640L adapter and four disks:<br>=
><br>> =C2=A0 =C2=A0 =C2=A01 x Samsung SSD<br>> =C2=A0 =C2=A0 =C2=
=A03 x WD Blue 6TB<br>><br>> =C2=A0Fails with netbsd-8 and netbsd-cur=
rent (8.12.2017),<br>> =C2=A0works with netbsd-6-0.<br>><br>> =C2=
=A0Full dmesg here:<br>><br>> =C2=A0 =C2=A0 =C2=A0<a href=3D"https://=
smokva.net/wdctl_rst/dmesg-nb8.txt">https://smokva.net/wdctl_rst/dmesg-nb8.=
txt</a><br>> =C2=A0 =C2=A0 =C2=A0<a href=3D"https://smokva.net/wdctl_rst=
/dmesg-nbC.txt">https://smokva.net/wdctl_rst/dmesg-nbC.txt</a><br>><br>&=
gt; =C2=A0relevant part:<br>><br>> =C2=A0 =C2=A0 =C2=A0ahcisata0 port=
0: device present, speed: 6.0Gb/s<br>> =C2=A0 =C2=A0 =C2=A0ahcisata0 po=
rt 3: device present, speed: 6.0Gb/s<br>> =C2=A0 =C2=A0 =C2=A0ahcisata0 =
port 1: device present, speed: 6.0Gb/s<br>> =C2=A0 =C2=A0 =C2=A0ahcisata=
0 port 2: device present, speed: 6.0Gb/s<br>> =C2=A0 =C2=A0 =C2=A0ahcisa=
ta0 port 7: device present, speed: 1.5Gb/s<br>> =C2=A0 =C2=A0 =C2=A0ahci=
sata0 channel 0: setting WDCTL_RST failed for drive 0<br>> =C2=A0 =C2=A0=
=C2=A0ahcisata0 channel 3: setting WDCTL_RST failed for drive 0<br>> =
=C2=A0 =C2=A0 =C2=A0ahcisata0 channel 7: setting WDCTL_RST failed for drive=
0<br>> =C2=A0 =C2=A0 =C2=A0ahcisata0 channel 1: setting WDCTL_RST faile=
d for drive 0<br>><br>> =C2=A0Let me know if I can help; will try net=
bsd-7 later today.<br>><br>> =C2=A0Petar<br>><br>><br>> =C2=
=A0P.S. I don't know what device is on port 7, maybe some proprietary<b=
r>> =C2=A0softraid implementation.=C2=A0 Appears on nb6, nb8 and current=
.<br>><br></div></div></div>
--089e0826a108d74e45055feab3bd--
--089e0826a108d74e49055feab3c0
Content-Type: text/plain; charset="US-ASCII"; name="ahcisata_fix_wdctl_rst.diff"
Content-Disposition: attachment; filename="ahcisata_fix_wdctl_rst.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_jazjqrp80
SW5kZXg6IGFoY2lzYXRhX2NvcmUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3Zzcm9vdC9zcmMv
c3lzL2Rldi9pYy9haGNpc2F0YV9jb3JlLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNjAKZGlm
ZiAtdSAtcCAtcjEuNjAgYWhjaXNhdGFfY29yZS5jCi0tLSBhaGNpc2F0YV9jb3JlLmMJMTEgTm92
IDIwMTcgMTY6NDk6MTMgLTAwMDAJMS42MAorKysgYWhjaXNhdGFfY29yZS5jCTkgRGVjIDIwMTcg
MTY6MjA6MDYgLTAwMDAKQEAgLTcxMCwyMSArNzEwLDExIEBAIGFoY2lfZXhlY19maXMoc3RydWN0
IGF0YV9jaGFubmVsICpjaHAsIGkKIAlpbnQgaTsKIAl1aW50MzJfdCBpczsKIAotCS8qCi0JICog
QmFzZSB0aW1lb3V0IGlzIHNwZWNpZmllZCBpbiBtcy4KLQkgKiBJZiB3ZSBhcmUgYWxsb3dlZCB0
byBzbGVlcCwgd2FpdCBhIHRpY2sgZWFjaCByb3VuZC4KLQkgKiBPdGhlcndpc2UgZGVsYXkgZm9y
IDEwbXMgb24gZWFjaCByb3VuZC4KLQkgKi8KLQlpZiAoZmxhZ3MgJiBBVF9XQUlUKQotCQl0aW1l
b3V0ID0gTUFYKDEsIG1zdG9oeih0aW1lb3V0KSk7Ci0JZWxzZQotCQl0aW1lb3V0ID0gdGltZW91
dCAvIDEwOwotCiAJQUhDSV9DTURIX1NZTkMoc2MsIGFjaHAsIHNsb3QsCiAJICAgIEJVU19ETUFT
WU5DX1BSRVJFQUQgfCBCVVNfRE1BU1lOQ19QUkVXUklURSk7CiAJLyogc3RhcnQgY29tbWFuZCAq
LwogCUFIQ0lfV1JJVEUoc2MsIEFIQ0lfUF9DSShjaHAtPmNoX2NoYW5uZWwpLCAxIDw8IHNsb3Qp
OwotCWZvciAoaSA9IDA7IGkgPCB0aW1lb3V0OyBpKyspIHsKKwlmb3IgKGkgPSAwOyBpIDwgKHRp
bWVvdXQgLyAxMCk7IGkrKykgewogCQlpZiAoKEFIQ0lfUkVBRChzYywgQUhDSV9QX0NJKGNocC0+
Y2hfY2hhbm5lbCkpICYgKDEgPDwgc2xvdCkpID09CiAJCSAgICAwKQogCQkJcmV0dXJuIDA7CkBA
IC03OTksNyArNzg5LDcgQEAgYWdhaW46CiAJY21kX3RibC0+Y21kdF9jZmlzW2Zpc190eXBlXSA9
IFJIRF9GSVNUWVBFOwogCWNtZF90YmwtPmNtZHRfY2Zpc1tyaGRfY10gPSBkcml2ZTsKIAljbWRf
dGJsLT5jbWR0X2NmaXNbcmhkX2NvbnRyb2xdID0gV0RDVExfUlNUOwotCXN3aXRjaChhaGNpX2V4
ZWNfZmlzKGNocCwgMTAwLCBmbGFncywgeGZlci0+Y19zbG90KSkgeworCXN3aXRjaChhaGNpX2V4
ZWNfZmlzKGNocCwgMTAwMCwgZmxhZ3MsIHhmZXItPmNfc2xvdCkpIHsKIAljYXNlIEVSUl9ERjoK
IAljYXNlIFRJTUVPVVQ6CiAJCWFwcmludF9lcnJvcigiJXMgY2hhbm5lbCAlZDogc2V0dGluZyBX
RENUTF9SU1QgZmFpbGVkICIK
--089e0826a108d74e49055feab3c0--
From: Petar Bogdanovic <petar@smokva.net>
To: gnats-bugs@NetBSD.org
Cc: jdolecek@NetBSD.org
Subject: Re: kern/52372: various SATA controllers throwing 'setting WDCTL_RST
failed'
Date: Sat, 9 Dec 2017 19:24:22 +0100
jaromir.dolecek@gmail.com wrote:
>
> Can you try if attached patch makes any difference? It merely changes the
> timeout for the command to 1s. It's not likely the problem since the
> attached devices are supposed to be fast (SSD and very recent WD disks).
Patch managed to get 2 out of 4 drives up; or 3 out of 5 if we count the
ghost-device at port 7:
ahcisata0 port 0: device present, speed: 6.0Gb/s
ahcisata0 port 1: device present, speed: 6.0Gb/s
ahcisata0 port 7: device present, speed: 1.5Gb/s
ahcisata0 port 3: device present, speed: 6.0Gb/s
ahcisata0 port 2: device present, speed: 6.0Gb/s
ahcisata0 channel 2: clearing WDCTL_RST failed for drive 0
ahcisata0 channel 3: clearing WDCTL_RST failed for drive 0
wd0 at atabus0 drive 0
wd0: <Samsung SSD 840 EVO 500GB>
wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
wd1 at atabus1 drive 0
wd1: <WDC WD60EZRZ-00GZ5B1>
wd1: 5589 GB, 11628021 cyl, 16 head, 63 sec, 512 bytes/sect x 11721045168 sectors
https://smokva.net/wdctl_rst/dmesg-nbC_1.txt (full dmesg)
So rootfs is up but since wd[23] are missing, rf setup fails.
> Other thing to check, is the controller set to 'AHCI' mode in BIOS and not
> RAID or 'compatible' or some such?
In the adapter-BIOS, I see:
"HBA 0: Marvell 0"
-> "Configure SATA as: AHCI Mode"
(I just checked netbsd-7, same issue)
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
To: Petar Bogdanovic <petar@smokva.net>
Cc: gnats-bugs@netbsd.org, Jaromir Dolecek <jdolecek@netbsd.org>
Subject: Re: kern/52372: various SATA controllers throwing 'setting WDCTL_RST failed'
Date: Sat, 9 Dec 2017 19:58:51 +0100
--089e0826a10867f3ab055fece4ee
Content-Type: text/plain; charset="UTF-8"
Interesting. Can you try to raise the timeout there to say 10000 (i.e. 10
second) instead of the 1000?
Jaromir
2017-12-09 19:24 GMT+01:00 Petar Bogdanovic <petar@smokva.net>:
> jaromir.dolecek@gmail.com wrote:
> >
> > Can you try if attached patch makes any difference? It merely changes the
> > timeout for the command to 1s. It's not likely the problem since the
> > attached devices are supposed to be fast (SSD and very recent WD disks).
>
> Patch managed to get 2 out of 4 drives up; or 3 out of 5 if we count the
> ghost-device at port 7:
>
> ahcisata0 port 0: device present, speed: 6.0Gb/s
> ahcisata0 port 1: device present, speed: 6.0Gb/s
> ahcisata0 port 7: device present, speed: 1.5Gb/s
> ahcisata0 port 3: device present, speed: 6.0Gb/s
> ahcisata0 port 2: device present, speed: 6.0Gb/s
> ahcisata0 channel 2: clearing WDCTL_RST failed for drive 0
> ahcisata0 channel 3: clearing WDCTL_RST failed for drive 0
> wd0 at atabus0 drive 0
> wd0: <Samsung SSD 840 EVO 500GB>
> wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168
> sectors
> wd1 at atabus1 drive 0
> wd1: <WDC WD60EZRZ-00GZ5B1>
> wd1: 5589 GB, 11628021 cyl, 16 head, 63 sec, 512 bytes/sect x
> 11721045168 sectors
>
> https://smokva.net/wdctl_rst/dmesg-nbC_1.txt (full dmesg)
>
> So rootfs is up but since wd[23] are missing, rf setup fails.
>
>
> > Other thing to check, is the controller set to 'AHCI' mode in BIOS and
> not
> > RAID or 'compatible' or some such?
>
> In the adapter-BIOS, I see:
>
> "HBA 0: Marvell 0"
> -> "Configure SATA as: AHCI Mode"
>
>
> (I just checked netbsd-7, same issue)
>
--089e0826a10867f3ab055fece4ee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Interesting. Can you try to raise the timeout there to say=
10000 (i.e. 10 second) instead of the 1000?<div><br></div><div>Jaromir</di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-12-0=
9 19:24 GMT+01:00 Petar Bogdanovic <span dir=3D"ltr"><<a href=3D"mailto:=
petar@smokva.net" target=3D"_blank">petar@smokva.net</a>></span>:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><a href=3D"mailto:jaromir.dolecek@gmail.com">ja=
romir.dolecek@gmail.com</a> wrote:<br>
><br>
> Can you try if attached patch makes any difference? It merely changes =
the<br>
> timeout for the command to 1s. It's not likely the problem since t=
he<br>
> attached devices are supposed to be fast (SSD and very recent WD disks=
).<br>
<br>
Patch managed to get 2 out of 4 drives up; or 3 out of 5 if we count the<br=
>
ghost-device at port 7:<br>
<span class=3D""><br>
=C2=A0 =C2=A0 ahcisata0 port 0: device present, speed: 6.0Gb/s<br>
</span><span class=3D"">=C2=A0 =C2=A0 ahcisata0 port 1: device present, spe=
ed: 6.0Gb/s<br>
</span><span class=3D"">=C2=A0 =C2=A0 ahcisata0 port 7: device present, spe=
ed: 1.5Gb/s<br>
</span><span class=3D"">=C2=A0 =C2=A0 ahcisata0 port 3: device present, spe=
ed: 6.0Gb/s<br>
</span><span class=3D"">=C2=A0 =C2=A0 ahcisata0 port 2: device present, spe=
ed: 6.0Gb/s<br>
</span>=C2=A0 =C2=A0 ahcisata0 channel 2: clearing WDCTL_RST failed for dri=
ve 0<br>
=C2=A0 =C2=A0 ahcisata0 channel 3: clearing WDCTL_RST failed for drive 0<br=
>
=C2=A0 =C2=A0 wd0 at atabus0 drive 0<br>
=C2=A0 =C2=A0 wd0: <Samsung SSD 840 EVO 500GB><br>
=C2=A0 =C2=A0 wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 97=
6773168 sectors<br>
=C2=A0 =C2=A0 wd1 at atabus1 drive 0<br>
=C2=A0 =C2=A0 wd1: <WDC WD60EZRZ-00GZ5B1><br>
=C2=A0 =C2=A0 wd1: 5589 GB, 11628021 cyl, 16 head, 63 sec, 512 bytes/sect x=
11721045168 sectors<br>
<br>
=C2=A0 =C2=A0 <a href=3D"https://smokva.net/wdctl_rst/dmesg-nbC_1.txt" rel=
=3D"noreferrer" target=3D"_blank">https://smokva.net/wdctl_rst/<wbr>dmesg-n=
bC_1.txt</a> (full dmesg)<br>
<br>
So rootfs is up but since wd[23] are missing, rf setup fails.<br>
<br>
<br>
> Other thing to check, is the controller set to 'AHCI' mode in =
BIOS and not<br>
> RAID or 'compatible' or some such?<br>
<br>
In the adapter-BIOS, I see:<br>
<br>
=C2=A0 =C2=A0 "HBA 0: Marvell 0"<br>
=C2=A0 =C2=A0 =C2=A0-> "Configure SATA as: AHCI Mode"<br>
<br>
<br>
(I just checked netbsd-7, same issue)<br>
</blockquote></div><br></div>
--089e0826a10867f3ab055fece4ee--
From: Petar Bogdanovic <petar@smokva.net>
To: =?utf-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
Cc: gnats-bugs@netbsd.org, Jaromir Dolecek <jdolecek@netbsd.org>
Subject: Re: kern/52372: various SATA controllers throwing 'setting WDCTL_RST
failed'
Date: Sat, 9 Dec 2017 21:35:38 +0100
On Sat, Dec 09, 2017 at 07:58:51PM +0100, Jaromír Doleček wrote:
> Interesting. Can you try to raise the timeout there to say 10000 (i.e. 10
> second) instead of the 1000?
Hm, I just noticed that it can time out while setting and clearing
WDCTL_RST.
Unpatched, it failed while setting WDCTL_RST.
After raising the timeout to 1000 (below mdt_cfis[rhd_control] = WDCTL_RST),
it started failing while _clearing_ WDCTL_RST.
After raising the other timeout to 1000 (below mdt_cfis[rhd_control] = 0),
it still failed while clearing WDCTL_RST.
After raising both timeouts to 10000,
it still failed while clearing WDCTL_RST. Just much later:
ahcisata0 port 0: device present, speed: 6.0Gb/s
ahcisata0 port 3: device present, speed: 6.0Gb/s
ahcisata0 port 7: device present, speed: 1.5Gb/s
ahcisata0 port 1: device present, speed: 6.0Gb/s
ahcisata0 port 2: device present, speed: 6.0Gb/s
drm: Enabling RC6 states: RC6 on, RC6p on, RC6pp off
wd0 at atabus0 drive 0
wd0: <Samsung SSD 840 EVO 500GB>
wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
dk0 at wd0: "netbsd-swap", 8388608 blocks at 2048, type: swap
dk1 at wd0: "netbsd-root", 968382479 blocks at 8390656, type: ffs
wd1 at atabus1 drive 0
wd1: <WDC WD60EZRZ-00GZ5B1>
wd1: 5589 GB, 11628021 cyl, 16 head, 63 sec, 512 bytes/sect x 11721045168 sectors
dk2 at wd1: "becdce23-d224-11e7-9dd0-2c44fd388e2b", 11721043087 blocks at 2048, type: raidframe
uhub4 at uhub2 port 1: vendor 8087 (0x8087) product 0024 (0x24), class 9/0, rev 2.00/0.00, addr 2
uhub4: single transaction translator
uhub5 at uhub3 port 1: vendor 8087 (0x8087) product 0024 (0x24), class 9/0, rev 2.00/0.00, addr 2
uhub5: single transaction translator
ahcisata0 channel 2: clearing WDCTL_RST failed for drive 0
ahcisata0 channel 3: clearing WDCTL_RST failed for drive 0
From: Greywolf <relayer@gmail.com>
To: gnats-bugs@gnats.netbsd.org
Cc:
Subject: Re: kern/52372
Date: Mon, 22 Jan 2018 12:09:22 -0800
--089e0827e9fcc603030563630202
Content-Type: text/plain; charset="UTF-8"
[refreshing only to keep from closing until I have a chance to test.
home internet circuit is completely down so cannot test and report at the
moment.]
--
<center>--*greywolf;<br>
/* relayer @t gmail d0t com */
/* ^ spam decoy ^ */
--089e0827e9fcc603030563630202
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>[refreshing only to keep from closing until I have a =
chance to test.<br></div>=C2=A0home internet circuit is completely down so =
cannot test and report at the moment.]<br clear=3D"all"><div><div><div><br>=
-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">&l=
t;center>--*greywolf;<br><br>/* relayer @t gmail d0t com */<br>/* =
^ spam decoy ^ */</div>
</div></div></div></div>
--089e0827e9fcc603030563630202--
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/52372: various SATA controllers throwing 'setting WDCTL_RST failed'
Date: Thu, 20 Jul 2017 01:22:12 +0200
--001a11444716e89cdd0554b3e63e
Content-Type: text/plain; charset="UTF-8"
Hello,
I've had a look on the dmesg, seems it's not consistent with the
description in the PR.
Particularily, there is just one 88SE9230 (not two as indicated in
Environment), and it's attached as ahcisata0, with 3 devices in different
channels already without any problem in dmesg.
Actually, when I look on dmesg, I see this:
ahcisata0 port 0: device present, speed: 6.0Gb/s
ahcisata0 port 1: device present, speed: 6.0Gb/s
ahcisata0 port 7: device present, speed: 1.5Gb/s
ahcisata1 port 0: device present, speed: 6.0Gb/s
ahcisata1 port 1: device present, speed: 6.0Gb/s
ahcisata2 port 0: device present, speed: 6.0Gb/s
ahcisata2 port 1: device present, speed: 6.0Gb/s
ahcisata3 port 0: device present, speed: 6.0Gb/s
ahcisata3 port 1: device present, speed: 6.0Gb/s
ahcisata3 port 2: device present, speed: 6.0Gb/s
ahcisata3 port 3: device present, speed: 3.0Gb/s
ahcisata3 port 4: device present, speed: 6.0Gb/s
ahcisata3 port 5: device present, speed: 6.0Gb/s
As far as I can read this, there is more than one device already on each
controller, and no WDCTL_RST error in dmesg.
Can you elaborate for which controllers you see the problem again? Also,
providing dmesg with PCIVERBOSE would be nice, easier to match.
Jaromir
2017-07-06 11:35 GMT+02:00 <greywolf@starwolf.com>:
>
> >Number: 52372
> >Category: kern
> >Synopsis: various SATA controllers throwing 'setting WDCTL_RST
failed'
> >Confidential: no
> >Severity: serious
> >Priority: high
> >Responsible: kern-bug-people
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Thu Jul 06 09:35:00 +0000 2017
> >Originator: Grey Wolf
> >Release: NetBSD 8.99.1
> >Organization:
> None to speak of
> >Environment:
> Motherboard: ASUS Z87-PLUS
> CPU: Intel i7-4770
> RAM: 32GB
> ahcisata0: HighPoint Technologies RocketRaid 640
> atabus0 thru atabus3 (ahcisata0 channels 0-3)
> ahcisata1: Marvell SATA Controller 88SE9230 PCIe 6Gb/s RAID*
> atabus4 thru atabus11 (ahcisata1 channels 0-7)
> ahcisata2: ASMedia SATA controller [2 ports]
> atabus12, atabus13 (ahcisata2 channels 0, 1)
> ahcisata3: Marvell SATA Controller 88SE9230 PCIe 6Gb/s RAID*
> atabus14 thru atabus21 (ahcisata3 channels 0-7)
> ahcisata4: Intel 8C220 6-port SATA controller [AHCI mode]
> atabus22 thru atabus25 (ahcisata4 channels 0-3)
>
> DMESG at https://www.starwolf.com/machines/eddie/dmesg
> DMI dump at https://www.starwolf.com/eddie/dmi
>
> "EDDIE" is really, at this point, just a renamed GENERIC kernel,
> until I can get it stable enough with the hardware to start paring
> drivers out.
>
> The two starred controllers (ahcisata1, ahcisata3) give me grief
> (see below)
>
> System: NetBSD eddie.starwolf.com 8.99.1 NetBSD 8.99.1 (EDDIE) #10: Thu
Jun 15 21:39:22 PDT 2017
greywolf@eddie.starwolf.com:/sys/arch/amd64/compile/EDDIE
amd64
> Architecture: x86_64
> Machine: amd64
> >Description:
> I have a machine with Bunch-O-Disks (12), mostly raid-mirrored.
>
> If I have more than two disks plugged in to either Marvell SATA
> controller, all disks on that controller fail with
> "ahcisataN channel X: setting WDCTL_RST failed for drive 0"
>
> If I have the root disk in this arrangement, the machine will boot
> but will then fail to find the root device at which point it will
> then ask me for the root device (and not accept keyboard input,
but
> that's for another ticket). This has caused me considerable
grief,
> especially considering that I don't really want to have 4
controllers
> installed for 12 disks -- I should only need 3.
>
> >How-To-Repeat:
> Hook more than two drives up to a Marvell-core SATA Controller and
> boot the box.
> >Fix:
> I have no idea even what's gone wrong, here.
>
--001a11444716e89cdd0554b3e63e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,<br><br>I've had a look on the dmesg, seems it&#=
39;s not consistent with the description in the PR.<br><br>Particularily, t=
here is just one 88SE9230 (not two as indicated in Environment), and it'=
;s attached as ahcisata0, with 3 devices in different channels already with=
out any problem in dmesg.<br><br>Actually, when I look on dmesg, I see this=
:<br><br>ahcisata0 port 0: device present, speed: 6.0Gb/s<br>ahcisata0 port=
1: device present, speed: 6.0Gb/s<br>ahcisata0 port 7: device present, spe=
ed: 1.5Gb/s<br>ahcisata1 port 0: device present, speed: 6.0Gb/s<br>ahcisata=
1 port 1: device present, speed: 6.0Gb/s<br>ahcisata2 port 0: device presen=
t, speed: 6.0Gb/s<br>ahcisata2 port 1: device present, speed: 6.0Gb/s<br>ah=
cisata3 port 0: device present, speed: 6.0Gb/s<br>ahcisata3 port 1: device =
present, speed: 6.0Gb/s<br>ahcisata3 port 2: device present, speed: 6.0Gb/s=
<br>ahcisata3 port 3: device present, speed: 3.0Gb/s<br>ahcisata3 port 4: d=
evice present, speed: 6.0Gb/s<br>ahcisata3 port 5: device present, speed: 6=
.0Gb/s<br><br>As far as I can read this, there is more than one device alre=
ady on each controller, and no WDCTL_RST error in dmesg.<div><br></div><div=
>Can you elaborate for which controllers you see the problem again? Also, p=
roviding dmesg with PCIVERBOSE would be nice, easier to match.</div><div><b=
r></div><div>Jaromir</div><div><br><br>2017-07-06 11:35 GMT+02:00 <<a hr=
ef=3D"mailto:greywolf@starwolf.com">greywolf@starwolf.com</a>>:<br>><=
br>> >Number: =C2=A0 =C2=A0 =C2=A0 =C2=A0 52372<br>> >Category:=
=C2=A0 =C2=A0 =C2=A0 kern<br>> >Synopsis: =C2=A0 =C2=A0 =C2=A0 vario=
us SATA controllers throwing 'setting WDCTL_RST failed'<br>> >=
;Confidential: =C2=A0 no<br>> >Severity: =C2=A0 =C2=A0 =C2=A0 serious=
<br>> >Priority: =C2=A0 =C2=A0 =C2=A0 high<br>> >Responsible: =
=C2=A0 =C2=A0kern-bug-people<br>> >State: =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0open<br>> >Class: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sw-bug<br>=
> >Submitter-Id: =C2=A0 net<br>> >Arrival-Date: =C2=A0 Thu Jul =
06 09:35:00 +0000 2017<br>> >Originator: =C2=A0 =C2=A0 Grey Wolf<br>&=
gt; >Release: =C2=A0 =C2=A0 =C2=A0 =C2=A0NetBSD 8.99.1<br>> >Organ=
ization:<br>> None to speak of<br>> >Environment:<br>> =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Motherboard: ASUS Z87-PLUS<br>> =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 CPU: Intel i7-4770<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 RAM: 32GB=
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ahcisata0: HighPoint Technologies Rock=
etRaid 640<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
atabus0 thru atabus3 (ahcisata0 channels 0-3)<br>> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 ahcisata1: Marvell SATA Controller 88SE9230 PCIe 6Gb/s RAID*<br>>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 atabus4 thru atabu=
s11 (ahcisata1 channels 0-7)<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ahcisata2:=
ASMedia SATA controller [2 ports]<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 atabus12, atabus13 (ahcisata2 channels 0, 1)<br>&g=
t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 ahcisata3: Marvell SATA Controller 88SE9230 =
PCIe 6Gb/s RAID*<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 atabus14 thru atabus21 (ahcisata3 channels 0-7)<br>> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ahcisata4: Intel 8C220 6-port SATA controller [AHCI mode]=
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 atabus22 t=
hru atabus25 (ahcisata4 channels 0-3)<br>><br>> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 DMESG at <a href=3D"https://www.starwolf.com/machines/eddie/dmesg">h=
ttps://www.starwolf.com/machines/eddie/dmesg</a><br>> =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 DMI dump at <a href=3D"https://www.starwolf.com/eddie/dmi">https=
://www.starwolf.com/eddie/dmi</a><br>><br>> =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "EDDIE" is really, at this point, just a renamed GENERIC kern=
el,<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 until I can get it stable enough wi=
th the hardware to start paring<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 drivers=
out.<br>><br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 The two starred controlle=
rs (ahcisata1, ahcisata3) give me grief<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0=
(see below)<br>><br>> System: NetBSD <a href=3D"http://eddie.starwol=
f.com">eddie.starwolf.com</a> 8.99.1 NetBSD 8.99.1 (EDDIE) #10: Thu Jun 15 =
21:39:22 PDT 2017 greywolf@eddie.starwolf.com:/sys/arch/amd64/compile/EDDIE=
amd64<br>> Architecture: x86_64<br>> Machine: amd64<br>> >Desc=
ription:<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I have a machine with Bunch-O-=
Disks (12), mostly raid-mirrored.<br>><br>> =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 If I have more than two disks plugged in to either Marvell SATA<br>>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 controller, all disks on that controller fail =
with<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ahcisataN channel X: setting=
WDCTL_RST failed for drive 0"<br>><br>> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 If I have the root disk in this arrangement, the machine will boot<b=
r>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 but will then fail to find the root devi=
ce at which point it will<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 then ask me f=
or the root device (and not accept keyboard input, but<br>> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 that's for another ticket).=C2=A0 This has caused me =
considerable grief,<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 especially consider=
ing that I don't really want to have 4 controllers<br>> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 installed for 12 disks -- I should only need 3.<br>><b=
r>> >How-To-Repeat:<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hook more tha=
n two drives up to a Marvell-core SATA Controller and<br>> =C2=A0 =C2=A0=
=C2=A0 =C2=A0 boot the box.<br>> >Fix:<br>> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 I have no idea even what's gone wrong, here.<br>><br></div></=
div>
--001a11444716e89cdd0554b3e63e--
Responsible-Changed-From-To: kern-bug-people->jdolecek
Responsible-Changed-By: jdolecek@NetBSD.org
Responsible-Changed-When: Tue, 19 Jun 2018 20:41:46 +0000
Responsible-Changed-Why:
Collecting WDCTL_RST related PRs. Again one controller with PSC,SSC, and
this time SSS.
State-Changed-From-To: feedback->open
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Tue, 19 Jun 2018 20:41:46 +0000
State-Changed-Why:
Feedback provided.
From: "Jaromir Dolecek" <jdolecek@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/52372 CVS commit: src/sys/dev/ata
Date: Thu, 21 Jun 2018 21:52:15 +0000
Module Name: src
Committed By: jdolecek
Date: Thu Jun 21 21:52:15 UTC 2018
Modified Files:
src/sys/dev/ata: sata_subr.c satavar.h
Log Message:
split the port status reporting to new function sata_interpret_det()
so it can be called separately from sata_reset_interface()
do not treat PHY offline as an error, it's pretty normal when there
is no device actually connected
debugging aid for PR kern/52372
To generate a diff of this commit:
cvs rdiff -u -r1.23 -r1.24 src/sys/dev/ata/sata_subr.c
cvs rdiff -u -r1.9 -r1.10 src/sys/dev/ata/satavar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Sat, 23 Jun 2018 14:12:16 +0000
State-Changed-Why:
Can you try a patch? It changes the probe routine to wait until
the device is ACTIVE.
http://www.netbsd.org/~jdolecek/ahci_reset_wait.diff
From: Greywolf <greywolf@starwolf.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/52372
Date: Fri, 12 Apr 2019 12:37:39 -0700
My apologies for the latency of the reply - FINALLY had a chance to test it
out. I no longer seem to have problems as originally reported.
--*greywolf;
State-Changed-From-To: feedback->closed
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Fri, 12 Apr 2019 21:25:32 +0000
State-Changed-Why:
Reported fixed. Thank you.
From: Petar Bogdanovic <petar@smokva.net>
To: gnats-bugs@netbsd.org
Cc: jdolecek@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
relayer@gmail.com
Subject: Re: kern/52372
Date: Sun, 14 Apr 2019 15:47:22 +0200
On Fri, Apr 12, 2019 at 09:00:02PM +0000, Greywolf wrote:
>
> My apologies for the latency of the reply - FINALLY had a chance to test it
> out. I no longer seem to have problems as originally reported.
FWIW, I removed my 88SE9230 based card (HighPoint Rocket 640L).
The device (and the attached disks) completely disappeared on multiple
occasions while doing lots of IO on Linux. Same thing has been reported
by multiple users running Linux and Windows.
https://www.digitec.ch/de/s1/product/ratings/highpoint-rocket-640l-storage-controller-5339442
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/52372 CVS commit: [netbsd-8] src/sys/dev/ata
Date: Fri, 24 Feb 2023 14:19:56 +0000
Module Name: src
Committed By: martin
Date: Fri Feb 24 14:19:56 UTC 2023
Modified Files:
src/sys/dev/ata [netbsd-8]: sata_subr.c satavar.h
Log Message:
Pull up following revision(s) (requested by msaitoh in ticket #1805):
sys/dev/ata/satavar.h: revision 1.10
sys/dev/ata/sata_subr.c: revision 1.24
split the port status reporting to new function sata_interpret_det()
so it can be called separately from sata_reset_interface()
do not treat PHY offline as an error, it's pretty normal when there
is no device actually connected
debugging aid for PR kern/52372
To generate a diff of this commit:
cvs rdiff -u -r1.22 -r1.22.2.1 src/sys/dev/ata/sata_subr.c
cvs rdiff -u -r1.9 -r1.9.28.1 src/sys/dev/ata/satavar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home