NetBSD Problem Report #43986
From woods@once.weird.com Tue Oct 19 19:41:20 2010
Return-Path: <woods@once.weird.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id 0A33C63B11D
for <gnats-bugs@gnats.NetBSD.org>; Tue, 19 Oct 2010 19:41:20 +0000 (UTC)
Message-Id: <m1P8H4t-001ZAkC@once.weird.com>
Date: Tue, 19 Oct 2010 14:38:27 -0400 (EDT)
From: "Greg A. Woods" <woods@planix.com>
Sender: "Greg A. Woods" <woods@once.weird.com>
Reply-To: "Greg A. Woods" <woods@planix.com>
To: gnats-bugs@gnats.NetBSD.org
Subject: ataraid(4) doesn't seem to handle weird array configs very gracefully
X-Send-Pr-Version: 3.95
>Number: 43986
>Category: kern
>Synopsis: ataraid(4) doesn't seem to handle weird array configs very gracefully
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: andvar
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Oct 19 19:45:00 +0000 2010
>Closed-Date: Sun Jul 20 21:34:11 +0000 2025
>Last-Modified: Wed Jul 30 18:30:01 +0000 2025
>Originator: Greg A. Woods
>Release: NetBSD 4.0_STABLE 2010/10/15
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:
System: NetBSD historically 4.0_STABLE NetBSD 4.0_STABLE (GENERIC.MP) #1: Fri Oct 15 13:14:43 EDT 2010 woods@once:/rest/build/woods/once/netbsd-4-i386-i386-ppro-obj/rest/work/woods/m-NetBSD-4/sys/arch/i386/compile/GENERIC.MP i386
Architecture: i386
Machine: i386
>Description:
ataraid(4) doesn't seem to handle weird array configs very gracefully:
wd1 at atabus2 drive 0: <WDC WD2000JD-00HBB0>
wd1: drive supports 16-sector PIO transfers, LBA48 addressing
wd1: 186 GB, 387621 cyl, 16 head, 63 sec, 512 bytes/sect x 390721968 sectors
rnd: wd1 attached as an entropy source (collecting)
wd1: 32-bit data port
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd1(piixide1:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
MAGIC == 0x00
wd2 at atabus3 drive 0: <WDC WD2000JD-00HBB0>
wd2: drive supports 16-sector PIO transfers, LBA48 addressing
wd2: 186 GB, 387621 cyl, 16 head, 63 sec, 512 bytes/sect x 390721968 sectors
rnd: wd2 attached as an entropy source (collecting)
wd2: 32-bit data port
wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd2(piixide1:1:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
ataraid0: found 1 RAID volume
ld0 at ataraid0 vendtype 1 unit 0: Adaptec ATA RAID-1 array
uvm_fault(0xc0ab2c40, 0, 1) -> 0xe
kernel: supervisor trap page fault, code=0
Stopped in pid 0.1 (swapper) at netbsd:strncmp+0x23: movzbl 0(%ebx),%eax
db{0}> trace
strncmp(c095397a,1c,6,282,c0a9564c) at netbsd:strncmp+0x23
devsw_name2blk(1c,0,0,0,0) at netbsd:devsw_name2blk+0x7e
ld_ataraid_attach(c3d9c940,c3dede00,c3da0600,c37d4000,c37f4000) at netbsd:ld_ata
raid_attach+0x1a8
config_attach_loc(c3d9c940,c0a0bb40,c0b96b54,c3da0600,c053c470) at netbsd:config
_attach_loc+0x3b0
ataraid_attach(0,c3d9c940,0,c04547fd,c095304c) at netbsd:ataraid_attach+0x87
config_attach_pseudo(c0a20e28,c0a20e00,c09c4c6c,241,7) at netbsd:config_attach_p
seudo+0x213
ata_raid_finalize(0,c0a1cfe0,0,20,20) at netbsd:ata_raid_finalize+0x4d
config_finalize(c0ab4114,20,c0967934,0,0) at netbsd:config_finalize+0x29
main(fbff,c01002d2,0,0,0) at netbsd:main+0x297
db{0}>
>How-To-Repeat:
1. set up a RAID-1 mirror in the hardware RAID controller config
2. disconnect one drive
3. delete the array
4. connect the drive
5. boot
i.e. I think the problem was the disconnected drive was
identified as being an array member and so the array
re-appeared, but the second drive was in JBOD mode because it
had been the only one connected when the array was initially
deleted.
>Fix:
>Release-Note:
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: "Greg A. Woods" <woods@planix.com>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/43986: ataraid(4) doesn't seem to handle weird array configs very gracefully
Date: Tue, 26 Mar 2024 02:12:00 +0000
> uvm_fault(0xc0ab2c40, 0, 1) -> 0xe
> kernel: supervisor trap page fault, code=3D0
> Stopped in pid 0.1 (swapper) at netbsd:strncmp+0x23: movzbl 0(%ebx),%=
eax
> db{0}> trace
> strncmp(c095397a,1c,6,282,c0a9564c) at netbsd:strncmp+0x23
This is an attempt to access the page zero. Not exactly a null
pointer dererence, but a near-null pointer dereference -- the second
argument is 0x1c.
> devsw_name2blk(1c,0,0,0,0) at netbsd:devsw_name2blk+0x7e
It probably happened here:
535 if (strncmp(conv->d_name, name, len) !=3D 0)
https://nxr.netbsd.org/xref/src/sys/kern/subr_devsw.c?r=3D1.28#535
> ld_ataraid_attach(c3d9c940,c3dede00,c3da0600,c37d4000,c37f4000) at netbsd=
:ld_ataraid_attach+0x1a8
The devsw_name2blk call is probaby this one:
78 bmajor =3D devsw_name2blk(device_xname(adi->adi_dev), NULL, 0);
https://nxr.netbsd.org/xref/src/sys/dev/ata/ata_raid_subr.c?r=3D1.2#78
0x1c is offsetof(struct device, dv_xname) on i386 as of around 2010:
https://nxr.netbsd.org/xref/src/sys/sys/device.h?r=3D1.137#141
So adi->adi_dev is probably null here.
ata_raid_disk_vnode_find assumes that adi->adi_dev is nonnull. This
is probably a bug on its own: the caller handles a null return, so
either if the input is null, the output should be null, or the caller
should avoid calling ata_raid_disk_vnode_find with a null input.
225 adi =3D &aai->aai_disks[i];
226 vp =3D ata_raid_disk_vnode_find(adi);
227 if (vp =3D=3D NULL) {
228 /*
229 * XXX This is bogus. We should just mark the
230 * XXX component as FAILED, and write-back new
231 * XXX config blocks.
232 */
233 break;
234 }
https://nxr.netbsd.org/xref/src/sys/dev/ata/ld_ataraid.c?r=3D1.37#225
How did adi->adi_dev come to be null?
Well, the struct ataraid_disk_info *adi structure is one of the
aai->aai_ndisks entries in a struct ataraid_array_info *aai structure
which is created by ataraid_get_array_info:
270 aai =3D malloc(sizeof(*aai), M_DEVBUF, M_WAITOK | M_ZERO);
...
289 TAILQ_INSERT_TAIL(&ataraid_array_info_list, aai, aai_list);
https://nxr.netbsd.org/xref/src/sys/dev/ata/ata_raid.c?r=3D1.34#258
This is called by the various ata_raid_*.c drivers. From the dmesg
you shared, it looks like this was an Adaptec adapter, so aai_ndisks
is filled in from the first component here:
156 aai->aai_ndisks =3D be16toh(info->configs[0].total_disks);
https://nxr.netbsd.org/xref/src/sys/dev/ata/ata_raid_adaptec.c?r=3D1.9#156
And aai->aai_disks[drive].adi_dev is filled in for each component
found here:
182 adi =3D &aai->aai_disks[drive];
183 adi->adi_dev =3D sc->sc_dev;
https://nxr.netbsd.org/xref/src/sys/dev/ata/ata_raid_adaptec.c?r=3D1.9#182
If any components are missing, there will be some number `drive' for
which aai->aai_disks[drive].adi_dev remains null, and the logic will
crash where you saw this. That seems to be consistent with your
explanation of the state of the disks.
None of this code has changed much since this PR was filed, so I
suspect the bug is still there. I'm inclined to say that
ld_ataraid_attach should just check adi->adi_dev =3D=3D NULL and handle it
like when ata_raid_disk_vnode_find returns null -- in both cases, it
needs to deal with a missing component.
--- ld_ataraid.c
+++ ld_ataraid.c
@@ -226,8 +226,8 @@
*/
for (i =3D 0; i < aai->aai_ndisks; i++) {
adi =3D &aai->aai_disks[i];
- vp =3D ata_raid_disk_vnode_find(adi);
- if (vp =3D=3D NULL) {
+ if (adi =3D=3D NULL ||
+ (vp =3D ata_raid_disk_vnode_find(adi)) =3D=3D NULL) {
/*
* XXX This is bogus. We should just mark the
* XXX component as FAILED, and write-back new
Now, the failure branch logic here may be wrong -- it just gives up
instead of trying to deal with a missing component -- but that's a
separate issue which, with any luck, should lead to a more graceful
failure than crash, even if the more graceful failure isn't ideal.
State-Changed-From-To: open->analyzed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Tue, 26 Mar 2024 02:16:44 +0000
State-Changed-Why:
problem analyzed, band-aid proposed
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
"Greg A. Woods" <woods@planix.com>
Subject: Re: kern/43986: ataraid(4) doesn't seem to handle weird array configs
very gracefully
Date: Tue, 11 Mar 2025 23:58:51 +0200
Hi Greg,
Do you still the hardware available and would be able to test the
patch https://netbsd.org/~andvar/ata_raid_fix2.diff?
It should not crash if drives are missing or RAID is invalid.
On Tue, Mar 26, 2024 at 4:15=E2=80=AFAM Taylor R Campbell <riastradh@netbsd=
.org> wrote:
>
> The following reply was made to PR kern/43986; it has been noted by GNATS=
.
>
> From: Taylor R Campbell <riastradh@NetBSD.org>
> To: "Greg A. Woods" <woods@planix.com>
> Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
> Subject: Re: kern/43986: ataraid(4) doesn't seem to handle weird array co=
nfigs very gracefully
> Date: Tue, 26 Mar 2024 02:12:00 +0000
>
> > uvm_fault(0xc0ab2c40, 0, 1) -> 0xe
> > kernel: supervisor trap page fault, code=3D3D0
> > Stopped in pid 0.1 (swapper) at netbsd:strncmp+0x23: movzbl 0(%ebx=
),%=3D
> eax
> > db{0}> trace
> > strncmp(c095397a,1c,6,282,c0a9564c) at netbsd:strncmp+0x23
>
> This is an attempt to access the page zero. Not exactly a null
> pointer dererence, but a near-null pointer dereference -- the second
> argument is 0x1c.
>
> > devsw_name2blk(1c,0,0,0,0) at netbsd:devsw_name2blk+0x7e
>
> It probably happened here:
>
> 535 if (strncmp(conv->d_name, name, len) !=3D3D 0)
>
> https://nxr.netbsd.org/xref/src/sys/kern/subr_devsw.c?r=3D3D1.28#535
>
> > ld_ataraid_attach(c3d9c940,c3dede00,c3da0600,c37d4000,c37f4000) at net=
bsd=3D
> :ld_ataraid_attach+0x1a8
>
> The devsw_name2blk call is probaby this one:
>
> 78 bmajor =3D3D devsw_name2blk(device_xname(adi->adi_dev), N=
ULL, 0);
>
> https://nxr.netbsd.org/xref/src/sys/dev/ata/ata_raid_subr.c?r=3D3D1.2#78
>
> 0x1c is offsetof(struct device, dv_xname) on i386 as of around 2010:
>
> https://nxr.netbsd.org/xref/src/sys/sys/device.h?r=3D3D1.137#141
>
> So adi->adi_dev is probably null here.
>
> ata_raid_disk_vnode_find assumes that adi->adi_dev is nonnull. This
> is probably a bug on its own: the caller handles a null return, so
> either if the input is null, the output should be null, or the caller
> should avoid calling ata_raid_disk_vnode_find with a null input.
>
> 225 adi =3D3D &aai->aai_disks[i];
> 226 vp =3D3D ata_raid_disk_vnode_find(adi);
> 227 if (vp =3D3D=3D3D NULL) {
> 228 /*
> 229 * XXX This is bogus. We should just mar=
k the
> 230 * XXX component as FAILED, and write-bac=
k new
> 231 * XXX config blocks.
> 232 */
> 233 break;
> 234 }
>
> https://nxr.netbsd.org/xref/src/sys/dev/ata/ld_ataraid.c?r=3D3D1.37#225
>
> How did adi->adi_dev come to be null?
>
> Well, the struct ataraid_disk_info *adi structure is one of the
> aai->aai_ndisks entries in a struct ataraid_array_info *aai structure
> which is created by ataraid_get_array_info:
>
> 270 aai =3D3D malloc(sizeof(*aai), M_DEVBUF, M_WAITOK | M_ZER=
O);
> ...
> 289 TAILQ_INSERT_TAIL(&ataraid_array_info_list, aai, aai_list=
);
>
> https://nxr.netbsd.org/xref/src/sys/dev/ata/ata_raid.c?r=3D3D1.34#258
>
> This is called by the various ata_raid_*.c drivers. From the dmesg
> you shared, it looks like this was an Adaptec adapter, so aai_ndisks
> is filled in from the first component here:
>
> 156 aai->aai_ndisks =3D3D be16toh(info->configs[0].to=
tal_disks);
>
> https://nxr.netbsd.org/xref/src/sys/dev/ata/ata_raid_adaptec.c?r=3D3D1.9=
#156
>
> And aai->aai_disks[drive].adi_dev is filled in for each component
> found here:
>
> 182 adi =3D3D &aai->aai_disks[drive];
> 183 adi->adi_dev =3D3D sc->sc_dev;
>
> https://nxr.netbsd.org/xref/src/sys/dev/ata/ata_raid_adaptec.c?r=3D3D1.9=
#182
>
> If any components are missing, there will be some number `drive' for
> which aai->aai_disks[drive].adi_dev remains null, and the logic will
> crash where you saw this. That seems to be consistent with your
> explanation of the state of the disks.
>
> None of this code has changed much since this PR was filed, so I
> suspect the bug is still there. I'm inclined to say that
> ld_ataraid_attach should just check adi->adi_dev =3D3D=3D3D NULL and han=
dle it
> like when ata_raid_disk_vnode_find returns null -- in both cases, it
> needs to deal with a missing component.
>
> --- ld_ataraid.c
> +++ ld_ataraid.c
> @@ -226,8 +226,8 @@
> */
> for (i =3D3D 0; i < aai->aai_ndisks; i++) {
> adi =3D3D &aai->aai_disks[i];
> - vp =3D3D ata_raid_disk_vnode_find(adi);
> - if (vp =3D3D=3D3D NULL) {
> + if (adi =3D3D=3D3D NULL ||
> + (vp =3D3D ata_raid_disk_vnode_find(adi)) =3D3D=3D3D N=
ULL) {
> /*
> * XXX This is bogus. We should just mark the
> * XXX component as FAILED, and write-back new
>
> Now, the failure branch logic here may be wrong -- it just gives up
> instead of trying to deal with a missing component -- but that's a
> separate issue which, with any luck, should lead to a more graceful
> failure than crash, even if the more graceful failure isn't ideal.
>
From: "Greg A. Woods" <woods@planix.com>
To: Andrius V <vezhlys@gmail.com>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: kern/43986: ataraid(4) doesn't seem to handle weird array configs very gracefully
Date: Tue, 11 Mar 2025 15:21:35 -0700
--pgp-sign-Multipart_Tue_Mar_11_15:21:32_2025-1
Content-Type: text/plain; charset=US-ASCII
At Tue, 11 Mar 2025 23:58:51 +0200, Andrius V <vezhlys@gmail.com> wrote:
Subject: Re: kern/43986: ataraid(4) doesn't seem to handle weird array configs very gracefully
>
> Do you still the hardware available and would be able to test the
> patch https://netbsd.org/~andvar/ata_raid_fix2.diff?
>
> It should not crash if drives are missing or RAID is invalid.
Hmmm.... that's a really good question.
I have a bunch of old computers I used to use out in storage in the
workshop, but I don't actually remember exactly which one this was
from.
I will have a peek and see if I recognize the board or drive. It
I'm not sure I have a spare monitor with VGA input any more though, but
I'll check.
--
Greg A. Woods <gwoods@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
--pgp-sign-Multipart_Tue_Mar_11_15:21:32_2025-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCZ9C3bwAKCRBmfXG3eL/0
fwwlAKDHWGmhJ1fY6j8FK72gBFcJwQT8pgCg69kyut5s7qSKHWNz71UW+Pnc9YY=
=gmIW
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Tue_Mar_11_15:21:32_2025-1--
From: "Greg A. Woods" <woods@planix.com>
To: Andrius V <vezhlys@gmail.com>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: kern/43986: ataraid(4) doesn't seem to handle weird array configs very gracefully
Date: Tue, 11 Mar 2025 18:40:46 -0700
--pgp-sign-Multipart_Tue_Mar_11_18:40:38_2025-1
Content-Type: text/plain; charset=US-ASCII
I think I do have the hardware. The first old system I looked at out in
the shop was an i386 server with a pair of WD "200.0" GB drives. They
should match the "WD20000JD" models shown in the original dmesg.
Now whether it works or not is another question entirely. It may have
serial console bootblocks installed, which would simplify things, but
somehow I think I switched it back to monitor and keyboard because it
moved to a colo in 2010. It had a brand new power supply installed in
2014, and it was running in production up until at least 2017! I got it
shipped back to me from the colo in Toronto in 2020, but haven't touched
it since.
If I can find a spare monitor that'll work on it I'll try to poke at it
this week or next week.
--
Greg A. Woods <gwoods@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
--pgp-sign-Multipart_Tue_Mar_11_18:40:38_2025-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCZ9DmGAAKCRBmfXG3eL/0
f3WtAJ9FXitO3TVA9b1spoGIojNmtAjpzgCdFapqtS+BcBopXeUIZWLwoKH0LOY=
=bSZI
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Tue_Mar_11_18:40:38_2025-1--
From: Andrius V <vezhlys@gmail.com>
To: NetBSD GNATS <gnats-bugs@netbsd.org>
Cc: "Greg A. Woods" <woods@planix.com>
Subject: Re: kern/43986: ataraid(4) doesn't seem to handle weird array configs
very gracefully
Date: Wed, 12 Mar 2025 15:39:29 +0200
Hi,
Good to know you still have hardware and would be great if you will
have a chance to test. No worries about timeline. If I'll commit patch
before your testing I will inform too :).
Also, if you will be testing, would be great to verify that kern/38273
is also not reproducible anymore for you (on my via ataraid(4) I don't
get spin locks anymore with LOCKDEBUG enabled, discussed patch was
committed in 2010).
Thank you.
On Wed, Mar 12, 2025 at 3:40=E2=80=AFAM Greg A. Woods <woods@planix.com> wr=
ote:
>
> I think I do have the hardware. The first old system I looked at out in
> the shop was an i386 server with a pair of WD "200.0" GB drives. They
> should match the "WD20000JD" models shown in the original dmesg.
>
> Now whether it works or not is another question entirely. It may have
> serial console bootblocks installed, which would simplify things, but
> somehow I think I switched it back to monitor and keyboard because it
> moved to a colo in 2010. It had a brand new power supply installed in
> 2014, and it was running in production up until at least 2017! I got it
> shipped back to me from the colo in Toronto in 2020, but haven't touched
> it since.
>
> If I can find a spare monitor that'll work on it I'll try to poke at it
> this week or next week.
>
> --
> Greg A. Woods <gwoods@acm.org>
>
> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
From: "Andrius Varanavicius" <andvar@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/43986 CVS commit: src/sys/dev/ata
Date: Sun, 16 Mar 2025 12:27:51 +0000
Module Name: src
Committed By: andvar
Date: Sun Mar 16 12:27:50 UTC 2025
Modified Files:
src/sys/dev/ata: ata_raid_subr.c ld_ataraid.c
Log Message:
ataraid(4), ld(4): ensure RAID disk status is set before resolving vnode.
Given a RAID array disk is missing (due to removal, failure, or a code bug),
its configuration is skipped. This causes ld(4) attachment at ataraid(4) to
fail because adi->adi_dev is NULL.
The fix will treat disks without known status (ADI_S_ONLINE, ADI_S_SPARE,
ADI_S_ASSIGNED) as if ata_raid_disk_vnode_find() returned NULL, more gracefully
solving above situation and avoiding the crash.
Additionally, replace vnode block device opening logic with vn_bdev_open()
(vn_subr(9)). This function provides identical functionality while also
incrementing vp->v_writecount, preventing a 'vp->v_writecount > 0` assertion
failure on vn_close().
More details are available in the tech-kern mailing list thread:
the https://mail-index.netbsd.org/tech-kern/2025/03/10/msg030179.html thread
and PR thread.
Should fix PR kern/43986
Also observed in PR kern/59130 (due to a different bug).
pullups are needed to netbsd-9, netbsd-10.
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/sys/dev/ata/ata_raid_subr.c
cvs rdiff -u -r1.50 -r1.51 src/sys/dev/ata/ld_ataraid.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Andrius V <vezhlys@gmail.com>
To: NetBSD GNATS <gnats-bugs@netbsd.org>
Cc: "Greg A. Woods" <woods@planix.com>
Subject: Re: kern/43986: ataraid(4) doesn't seem to handle weird array configs
very gracefully
Date: Sun, 16 Mar 2025 14:30:58 +0200
Hi,
I committed the fix today (ld_ataraid.c rev 1.51, ata_raid_subr.c rev
1.5). Thus, next "latest" image should contain the fix and allow
testing directly from from the install image.
On Wed, Mar 12, 2025 at 3:39=E2=80=AFPM Andrius V <vezhlys@gmail.com> wrote=
:
>
> Hi,
>
> Good to know you still have hardware and would be great if you will
> have a chance to test. No worries about timeline. If I'll commit patch
> before your testing I will inform too :).
>
> Also, if you will be testing, would be great to verify that kern/38273
> is also not reproducible anymore for you (on my via ataraid(4) I don't
> get spin locks anymore with LOCKDEBUG enabled, discussed patch was
> committed in 2010).
>
> Thank you.
>
> On Wed, Mar 12, 2025 at 3:40=E2=80=AFAM Greg A. Woods <woods@planix.com> =
wrote:
> >
> > I think I do have the hardware. The first old system I looked at out i=
n
> > the shop was an i386 server with a pair of WD "200.0" GB drives. They
> > should match the "WD20000JD" models shown in the original dmesg.
> >
> > Now whether it works or not is another question entirely. It may have
> > serial console bootblocks installed, which would simplify things, but
> > somehow I think I switched it back to monitor and keyboard because it
> > moved to a colo in 2010. It had a brand new power supply installed in
> > 2014, and it was running in production up until at least 2017! I got i=
t
> > shipped back to me from the colo in Toronto in 2020, but haven't touche=
d
> > it since.
> >
> > If I can find a spare monitor that'll work on it I'll try to poke at it
> > this week or next week.
> >
> > --
> > Greg A. Woods <gwoods@acm.org>
> >
> > Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
> > Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
Responsible-Changed-From-To: kern-bug-people->andvar
Responsible-Changed-By: andvar@NetBSD.org
Responsible-Changed-When: Sun, 16 Mar 2025 12:49:33 +0000
Responsible-Changed-Why:
take
State-Changed-From-To: analyzed->needs-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Sun, 16 Mar 2025 12:50:40 +0000
State-Changed-Why:
fix committed, needs pullups.
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Thu, 24 Apr 2025 16:31:04 +0000
State-Changed-Why:
pullups requested: [pullup-9 #1943] and [pullup-10 #1100]
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/43986 CVS commit: [netbsd-10] src/sys/dev/ata
Date: Wed, 7 May 2025 17:42:31 +0000
Module Name: src
Committed By: martin
Date: Wed May 7 17:42:31 UTC 2025
Modified Files:
src/sys/dev/ata [netbsd-10]: ata_raid_subr.c ld_ataraid.c
Log Message:
Pull up following revision(s) (requested by andvar in ticket #1100):
sys/dev/ata/ld_ataraid.c: revision 1.51
sys/dev/ata/ata_raid_subr.c: revision 1.5
ataraid(4), ld(4): ensure RAID disk status is set before resolving vnode.
Given a RAID array disk is missing (due to removal, failure, or a code bug),
its configuration is skipped. This causes ld(4) attachment at ataraid(4) to
fail because adi->adi_dev is NULL.
The fix will treat disks without known status (ADI_S_ONLINE, ADI_S_SPARE,
ADI_S_ASSIGNED) as if ata_raid_disk_vnode_find() returned NULL, more gracefully
solving above situation and avoiding the crash.
Additionally, replace vnode block device opening logic with vn_bdev_open()
(vn_subr(9)). This function provides identical functionality while also
incrementing vp->v_writecount, preventing a 'vp->v_writecount > 0` assertion
failure on vn_close().
More details are available in the tech-kern mailing list thread:
the https://mail-index.netbsd.org/tech-kern/2025/03/10/msg030179.html thread
and PR thread.
Should fix PR kern/43986
Also observed in PR kern/59130 (due to a different bug).
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.4.4.1 src/sys/dev/ata/ata_raid_subr.c
cvs rdiff -u -r1.50 -r1.50.24.1 src/sys/dev/ata/ld_ataraid.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Sun, 20 Jul 2025 21:34:11 +0000
State-Changed-Why:
closing: fixed and pulled up months ago.
was waiting for the additional confirmation, but I guess there's no time or interest to do it anytime soon.
From: "Greg A. Woods" <Greg.A.Woods@avoncote.ca>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc:
Subject: Re: kern/43986 (ataraid(4) doesn't seem to handle weird array configs very gracefully)
Date: Sun, 27 Jul 2025 13:28:32 -0700
--pgp-sign-Multipart_Sun_Jul_27_13:28:19_2025-1
Content-Type: text/plain; charset=US-ASCII
At Sun, 20 Jul 2025 21:34:12 +0000 (UTC), andvar@NetBSD.org wrote:
> closing: fixed and pulled up months ago.
>
> was waiting for the additional confirmation, but I guess there's no
> time or interest to do it anytime soon.
Sorry, yeah, spring and summer activities have overwhelmed time
available for computer activities.... That and I don't seem to have a
spare working monitor available for it either -- but I'll need to fix
that problem sooner or later for many reasons....
--
Greg A. Woods <gwoods@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
--pgp-sign-Multipart_Sun_Jul_27_13:28:19_2025-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCaIaL5QAKCRBmfXG3eL/0
f9zcAJ9H8d4VYLJ1UagNVQJ5kHP2bxpEagCeNNS4tQryi5GLcqKfJDJoxbJ6BFg=
=ms/+
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Sun_Jul_27_13:28:19_2025-1--
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: "Greg A. Woods" <woods@planix.com>
Subject: Re: kern/43986 (ataraid(4) doesn't seem to handle weird array configs
very gracefully)
Date: Wed, 30 Jul 2025 21:28:29 +0300
On Sun, Jul 27, 2025 at 11:40=E2=80=AFPM Greg A. Woods via gnats
<gnats-admin@netbsd.org> wrote:
>
> The following reply was made to PR kern/43986; it has been noted by GNATS=
.
>
> From: "Greg A. Woods" <Greg.A.Woods@avoncote.ca>
> To: NetBSD GNATS <gnats-bugs@NetBSD.org>
> Cc:
> Subject: Re: kern/43986 (ataraid(4) doesn't seem to handle weird array co=
nfigs very gracefully)
> Date: Sun, 27 Jul 2025 13:28:32 -0700
>
> --pgp-sign-Multipart_Sun_Jul_27_13:28:19_2025-1
> Content-Type: text/plain; charset=3DUS-ASCII
>
> At Sun, 20 Jul 2025 21:34:12 +0000 (UTC), andvar@NetBSD.org wrote:
> > closing: fixed and pulled up months ago.
> >
> > was waiting for the additional confirmation, but I guess there's no
> > time or interest to do it anytime soon.
>
> Sorry, yeah, spring and summer activities have overwhelmed time
> available for computer activities.... That and I don't seem to have a
> spare working monitor available for it either -- but I'll need to fix
> that problem sooner or later for many reasons....
>
> --
> Greg A. Woods <gwoods@acm.org>
>
> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
>
> --pgp-sign-Multipart_Sun_Jul_27_13:28:19_2025-1
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
> Content-Description: OpenPGP Digital Signature
>
> -----BEGIN PGP SIGNATURE-----
>
> iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCaIaL5QAKCRBmfXG3eL/0
> f9zcAJ9H8d4VYLJ1UagNVQJ5kHP2bxpEagCeNNS4tQryi5GLcqKfJDJoxbJ6BFg=3D
> =3Dms/+
> -----END PGP SIGNATURE-----
>
> --pgp-sign-Multipart_Sun_Jul_27_13:28:19_2025-1--
>
No worries, will all busy, it's understandable, and this functionality
is not extremely relevant these days..
If you will have a chance to test, feedback is still welcome. There
were few other PRs which may be fixed by now. Thanks.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home