Re: CVS commit: src/sys/dev/raidframe
> On 16. Apr 2022, at 18:40, Andrius Varanavicius wrote: > > Module Name: src > Committed By: andvar > Date: Sat Apr 16 16:40:54 UTC 2022 > > Modified Files: > src/sys/dev/raidframe: rf_netbsdkintf.c > > Log Message: > Fix mistake in error branch locking caused by previous changes. > vput(vp) also unlocks vp, thus unlocking happens twice in error flow > causing kernel to panic with failed assertion lktype != LK_NONE > in vfs_vnode.c#778. Thanks riastradh with finding the issue. > > > To generate a diff of this commit: > cvs rdiff -u -r1.406 -r1.407 src/sys/dev/raidframe/rf_netbsdkintf.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. Thanks, replacing vput() with vrele() would have been even better ... -- J. Hannken-Illjes - hann...@mailbox.org signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/sys/dev/raidframe
In article , Paul Goyette wrote: >> Module Name:src >> Committed By: mrg >> Date: Tue Feb 5 09:28:00 UTC 2019 >> >> Modified Files: >> src/sys/dev/raidframe: rf_netbsdkintf.c >> >> Log Message: >> fix the previous: >> >> rf_netbsd32 is only relevant on _LP64 as all the structures are >> the same for arm32 oabi/eabi compat. >> >> only do it for _LP64 *and* COMAPT_NETBSD32. > >This doesn't really do the job... > >Consider a kernel with raid(4) built-in, but _not_ built with >COMPAT_NETBSD32. The raid code will not have any calls to the compat >hooks. So even if you subsequently modload the compat_netbsd32 module >there won't be any way to call the compat code. > >The main raidframe driver code needs to be built _without_ depending on >COMPAT_NETBSD32 being defined at all. There is also the consideration of compat_32 for all the _80 ioctls... christos
Re: CVS commit: src/sys/dev/raidframe
It's still a behaviour change..
On Thu, Jan 12, 2017 at 11:22:16PM -0500, Christos Zoulas wrote:
> +static void
> +rf_handle_hosed(RF_Raid_t *raidPtr, RF_Config_t *cfgPtr, int hosed_column)
> +{
> + if (raidPtr->Disks[hosed_column].status == rf_ds_failed)
> + return;
equivalent to
if (raidPtr->Disks[hosed_column].status != rf_ds_failed) { do stuff }
in the second check, but this is first one:
>
> - printf("Hosed component: %s\n",
> -&cfgPtr->devnames[0][hosed_column][0]);
> - if (!force) {
> - /* we'll fail this component, as if there are
> -other major errors, we arn't forcing things
> -and we'll abort the config anyways */
> - raidPtr->Disks[hosed_column].status
> - = rf_ds_failed;
> - raidPtr->numFailures++;
> - raidPtr->status = rf_rs_degraded;
> - }
> + if (hosed_column != -1)
> + rf_handle_hosed(raidPtr, cfgPtr, hosed_column);
>
It always increments numfailures, even if this column has
failed in the distant past.
Re: CVS commit: src/sys/dev/raidframe
On Thu, Jan 12, 2017 at 11:22:16PM -0500, Christos Zoulas wrote:
> +rf_handle_hosed(RF_Raid_t *raidPtr, RF_Config_t *cfgPtr, int hosed_column)
> +{
:
> + if (raidPtr->Disks[hosed_column].status == rf_ds_failed)
> + return;
equivalent to
if (raidPtr->Disks[hosed_column].status != rf_ds_failed) {
do stuff
This is not in the first part:
> - printf("Hosed component: %s\n",
> -&cfgPtr->devnames[0][hosed_column][0]);
> - if (!force) {
> - /* we'll fail this component, as if there are
> -other major errors, we arn't forcing things
> -and we'll abort the config anyways */
> - raidPtr->Disks[hosed_column].status
> - = rf_ds_failed;
> - raidPtr->numFailures++;
> - raidPtr->status = rf_rs_degraded;
> - }
> + if (hosed_column != -1)
> + rf_handle_hosed(raidPtr, cfgPtr, hosed_column);
It is only in the second part:
> - printf("Hosed component: %s\n",
> -&cfgPtr->devnames[0][hosed_column][0]);
> - if (!force) {
> - /* we'll fail this component, as if there are
> -other major errors, we arn't forcing things
> -and we'll abort the config anyways */
> - if (raidPtr->Disks[hosed_column].status !=
> rf_ds_failed) {
> - raidPtr->Disks[hosed_column].status
> - = rf_ds_failed;
> - raidPtr->numFailures++;
> - raidPtr->status = rf_rs_degraded;
> - }
> - }
> + if (hosed_column != -1)
> + rf_handle_hosed(raidPtr, cfgPtr, hosed_column);
I didn't want to commit it because it introduces a functional
change. Now if the status was failed from long before, we will
not increment numFailures, so numFailures > 1 is probably not
possible.
Re: CVS commit: src/sys/dev/raidframe
err, this does introduce a functional change... oops it's if panicstr != NULL, but that's not the argument.
Re: CVS commit: src/sys/dev/raidframe
In article <112c4aeb-38d8-42d4-be3c-b53e866ea...@eis.cs.tu-bs.de>, J. Hannken-Illjes wrote: > >Where does it call biodone()? > >biodone_vfs(bp); /* biodone() iff vfs present */ Nevertheless, it is best to check for the error and not biowait needlessly. christos
Re: CVS commit: src/sys/dev/raidframe
On 02 Jan 2016, at 17:07, Christos Zoulas wrote:
>
> In article <20160102160001.c978df...@cvs.netbsd.org>,
> Michael van Elst wrote:
>> @@ -2665,11 +2664,7 @@ raidread_component_area(dev_t dev, struc
>> bp->b_flags |= B_READ;
>> bp->b_resid = dsize;
>>
>> -bdev = bdevsw_lookup(bp->b_dev);
>> -if (bdev == NULL)
>> -return (ENXIO);
>> -(*bdev->d_strategy)(bp);
>> -
>> +bdev_strategy(bp);
>> error = biowait(bp);
>
> Don't you want instead?
>
> + bdev_strategy(bp);
> + if (bp->b_error)
> + return bp->b_error;
>
> Since bdev_strategy() calls biodone()
Where does it call biodone()?
From sys/kern/subr_devsw.c:
void
bdev_strategy(struct buf *bp)
{
const struct bdevsw *d;
int mpflag;
if ((d = bdevsw_lookup(bp->b_dev)) == NULL) {
bp->b_error = ENXIO;
bp->b_resid = bp->b_bcount;
biodone_vfs(bp); /* biodone() iff vfs present */
return;
}
DEV_LOCK(d);
(*d->d_strategy)(bp);
DEV_UNLOCK(d);
}
> and I am pretty sure you are not
> supposed to call biowait() on a biodone()'d buffer? And bdev_strategy
> should be made to return an error...
>
> christos
>
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: CVS commit: src/sys/dev/raidframe
In article <20160102160001.c978df...@cvs.netbsd.org>, Michael van Elst wrote: >@@ -2665,11 +2664,7 @@ raidread_component_area(dev_t dev, struc > bp->b_flags |= B_READ; > bp->b_resid = dsize; > >- bdev = bdevsw_lookup(bp->b_dev); >- if (bdev == NULL) >- return (ENXIO); >- (*bdev->d_strategy)(bp); >- >+ bdev_strategy(bp); > error = biowait(bp); Don't you want instead? + bdev_strategy(bp); + if (bp->b_error) + return bp->b_error; Since bdev_strategy() calls biodone() and I am pretty sure you are not supposed to call biowait() on a biodone()'d buffer? And bdev_strategy should be made to return an error... christos
Re: CVS commit: src/sys/dev/raidframe
On Sun, 27 Dec 2015, Robert Elz wrote: Date:Sat, 26 Dec 2015 12:59:01 + From:"Paul Goyette" Message-ID: <20151226125901.230e1f...@cvs.netbsd.org> | if it does, all we really lose is auto-configuration of raid-sets. Auto-config of raid is what makes many of my systems function, if that fails, the system should panic, not just bindly charge ahead. The failure of config_finalize_register() was already only a WARNING. This commit just restores the original semantics. Additionally, the only failure that i can find for ...register() is the return of EEXIST if the finalizer is already registered. This really can't happen any more, since rev 1.238 of kern/subr_autoconf.c +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: CVS commit: src/sys/dev/raidframe
Date:Sat, 26 Dec 2015 12:59:01 + From:"Paul Goyette" Message-ID: <20151226125901.230e1f...@cvs.netbsd.org> | if it does, all we really lose is auto-configuration of raid-sets. Auto-config of raid is what makes many of my systems function, if that fails, the system should panic, not just bindly charge ahead. kre
Re: CVS commit: src/sys/dev/raidframe
Module Name:src Committed By: pgoyette Date: Sat Dec 26 00:58:45 UTC 2015 Modified Files: src/sys/dev/raidframe: rf_driver.c rf_driver.h rf_netbsdkintf.c Log Message: Modularize the raidframe driver, including rework of the unit attach code to permit detaching (and possible module unloading). Also, convert tsleep()/wakeup() locking to use cv_wait_sig()/cv_broadcast(). Tested in non-modular, modular-builtin, and modular-loaded-at-runtime environments. Hmmm, looks like I need to do some more testing, this time in a rump environment. The most recent automated test run shows six new failed tests related to raidframe. I'm looking into it... +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: CVS commit: src/sys/dev/raidframe
On Thu, Apr 03, 2014 at 12:13:09PM -0400, Greg Troxel wrote: > > > Or: > > 1. add the ability to pass the root name through the bootblocks/userconf > > 2. add a raidctl -A forceroot and obey that. > > > > | It seems to me that the behavior 1 (not in case 2) isn't useful, and > > | that we could make behavior 2 the default behavior, with 3 with -A yes. > > > > Yes, I think you are right. There could be an issue with having wd0a being > > the real root and then a raid component on wd0e... In that case do we want > > to make wd0e the root device because it is on the same drive? > > I don't think so. The case that matters for automatically making the > raid root is when one has a RAID1 and the bootblocks boot off of half of > it. So I think the narrow "if the boot device is a component of an > autoconfigured raid, switch the boot device to that raid" really is what > we want to do. Agreed. wd0a might have nothing to do with the raid component wd0e. I keep entirely separate bootable root filesystems for old versions and recovery. One might be i386, the other amd64 ... David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/dev/raidframe
chris...@zoulas.com (Christos Zoulas) writes: > On Apr 3, 7:57am, m...@eterna.com.au (matthew green) wrote: > -- Subject: re: CVS commit: src/sys/dev/raidframe > > | kernel configuration changes are not solutions, so 2 and 3 are out. > | > | if we do 4, we should instead add an option to mark something as a > | 'soft root', and leave the current semantics alone. the machines i > | have that are now not going to reboot properly are both used > | remotely, so changing semantics about how they work seems like a > | bad idea. i'm pretty sure i'm not the only one who does this. > | i think i like this the best. > > Sure, we can add -A softroot. Do we want to rename the current option > to -A hardroot? If that's the consensus, I can go ahead. Why don't you just leave the current one alone, and not change the name? The names only mean what the docs say, and -A root says "and make this root, period" in the docs, which is not unsurprising for "-A root". Having "-A softroot" or "-A condroot" to mean "make this root if the existing root is a component" sounds good. This way the only people that will see new behavior are those that configure -A softroot, and I think that's a good goal. pgpdgzG97Nfh6.pgp Description: PGP signature
re: CVS commit: src/sys/dev/raidframe
On Apr 3, 8:10am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/sys/dev/raidframe | | > > 4. we can add an option to mark the raid as force root. | > | > if we do 4, we should instead add an option to mark something as a | > 'soft root', and leave the current semantics alone. the machines i | > have that are now not going to reboot properly are both used | > remotely, so changing semantics about how they work seems like a | > bad idea. i'm pretty sure i'm not the only one who does this. | > i think i like this the best. | | oh, actually. we already (can) have "soft root". by marking | something as auto-configure, and booting from it. | | what we want to change from what the past has been is to enable | the auto-configured raids to be used as root when booted from, | without them being marked -A root. we should still keep the | current -A root semantics, and then people can stop using -A | root when they don't need to force it, and just use -A yes. This has the problem of having a raid component on the same boot disk with the real root partition. christos
re: CVS commit: src/sys/dev/raidframe
On Apr 3, 7:57am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/sys/dev/raidframe | kernel configuration changes are not solutions, so 2 and 3 are out. | | if we do 4, we should instead add an option to mark something as a | 'soft root', and leave the current semantics alone. the machines i | have that are now not going to reboot properly are both used | remotely, so changing semantics about how they work seems like a | bad idea. i'm pretty sure i'm not the only one who does this. | i think i like this the best. Sure, we can add -A softroot. Do we want to rename the current option to -A hardroot? If that's the consensus, I can go ahead. christos
Re: CVS commit: src/sys/dev/raidframe
I think the most important thing is that people who have a system that boots now (and aren't doing anything super sick) should continue to have that system boot after they just replace the kernel. And we should discuss how to do this before the change is committed :-) > On Apr 2, 10:33am, g...@ir.bbn.com (Greg Troxel) wrote: > -- Subject: Re: CVS commit: src/sys/dev/raidframe > > | It seems there are 3 behaviors for root > | > | 1) don't change the root device (old behavior with -A yes) > > That does autoconfig for raid and does not deal with root at all. Right, but it is a way that some systems might be set up now. > | 2) if root is on a component, change root to the raid, otherwise don't > | change. > > This behavior did not exist before my commit. It is now only turned on with > -A root. > > | 3) force the root device to be the raid (old behavior with -A root) > > This does not exist anymore. You can currently: > > 1. boot -a > 2. make a kernel that has root on raidx so this is the real concern, that the straightforward update will make systems unbootable. > Or: > 1. add the ability to pass the root name through the bootblocks/userconf > 2. add a raidctl -A forceroot and obey that. > > | It seems to me that the behavior 1 (not in case 2) isn't useful, and > | that we could make behavior 2 the default behavior, with 3 with -A yes. > > Yes, I think you are right. There could be an issue with having wd0a being > the real root and then a raid component on wd0e... In that case do we want > to make wd0e the root device because it is on the same drive? I don't think so. The case that matters for automatically making the raid root is when one has a RAID1 and the bootblocks boot off of half of it. So I think the narrow "if the boot device is a component of an autoconfigured raid, switch the boot device to that raid" really is what we want to do. > | Is there any reason why someone would not want to use the raid for root > | when a) the system booted from a component and b) it's marked > | autoconfigurable? If anything, I think there should be a way to disable > | autoconfiguration. > > See above... There is a way to disable autoconfiguration, but there is > currently no easy way to get the old behavior? What do you think we should > do? I guess the idea that you boot from half a raid and then you use root on that half - doesn't make sense. That breaks the raid set. I think people either set things up as (typical examples) one of the following ways: boot a kernel from wd0a, which is nonraid, and have a RAID1 on wd0e/wd1e marked -A root. Here, wd0a is merely as a rescue partition and a way to load the kernel. This is what you used to have to do before RAID1 boot support, which means I think you still do have to do it on some platforms. have wd0a/wd1a be a RAID1. Boot from wd0a (or wd1a) with boot blocks that skip over the raid header, and then -A root is used to make that the root device. So the first way needs -A root to keep its current semantics. The 2nd way works with -A root, but I think it's fine to make it work with merely -A yes. pgpagpzE8AyBe.pgp Description: PGP signature
Re: CVS commit: src/sys/dev/raidframe
On Apr 2, 10:33am, g...@ir.bbn.com (Greg Troxel) wrote: -- Subject: Re: CVS commit: src/sys/dev/raidframe | It seems there are 3 behaviors for root | | 1) don't change the root device (old behavior with -A yes) That does autoconfig for raid and does not deal with root at all. | 2) if root is on a component, change root to the raid, otherwise don't | change. This behavior did not exist before my commit. It is now only turned on with -A root. | 3) force the root device to be the raid (old behavior with -A root) This does not exist anymore. You can currently: 1. boot -a 2. make a kernel that has root on raidx Or: 1. add the ability to pass the root name through the bootblocks/userconf 2. add a raidctl -A forceroot and obey that. | It seems to me that the behavior 1 (not in case 2) isn't useful, and | that we could make behavior 2 the default behavior, with 3 with -A yes. Yes, I think you are right. There could be an issue with having wd0a being the real root and then a raid component on wd0e... In that case do we want to make wd0e the root device because it is on the same drive? | Is there any reason why someone would not want to use the raid for root | when a) the system booted from a component and b) it's marked | autoconfigurable? If anything, I think there should be a way to disable | autoconfiguration. See above... There is a way to disable autoconfiguration, but there is currently no easy way to get the old behavior? What do you think we should do? christos
Re: CVS commit: src/sys/dev/raidframe
On Thu, 03 Apr 2014 08:10:01 +1100 matthew green wrote: > > > > 4. we can add an option to mark the raid as force root. > > > > if we do 4, we should instead add an option to mark something as a > > 'soft root', and leave the current semantics alone. the machines i > > have that are now not going to reboot properly are both used > > remotely, so changing semantics about how they work seems like a > > bad idea. i'm pretty sure i'm not the only one who does this. > > i think i like this the best. > > oh, actually. we already (can) have "soft root". by marking > something as auto-configure, and booting from it. > > what we want to change from what the past has been is to enable > the auto-configured raids to be used as root when booted from, > without them being marked -A root. we should still keep the > current -A root semantics, and then people can stop using -A > root when they don't need to force it, and just use -A yes. FWIW: I like this idea the best. It also doesn't break any existing installations. Later... Greg Oster
re: CVS commit: src/sys/dev/raidframe
> > 4. we can add an option to mark the raid as force root. > > if we do 4, we should instead add an option to mark something as a > 'soft root', and leave the current semantics alone. the machines i > have that are now not going to reboot properly are both used > remotely, so changing semantics about how they work seems like a > bad idea. i'm pretty sure i'm not the only one who does this. > i think i like this the best. oh, actually. we already (can) have "soft root". by marking something as auto-configure, and booting from it. what we want to change from what the past has been is to enable the auto-configured raids to be used as root when booted from, without them being marked -A root. we should still keep the current -A root semantics, and then people can stop using -A root when they don't need to force it, and just use -A yes. .mrg.
re: CVS commit: src/sys/dev/raidframe
> | > Log Message: > | > If we are autoconfiguring root, then only change the booted_device if > | > we booted from one of the components of the root raid set. This allows > | > us to boot from other media, without forcing the found raid to always > | > be root. Allow the old behavior with RAIDFRAME_FORCE_ROOT. > | > XXX: cpu_rootconf() is called twice now, which prints the booted device > | > message twice. Perhaps we can remember that cpu_rootconf has been called > | > and avoid calling it twice to avoid that. > | > | i like this.. i think. > | > | i wonder if this will break my system that boot from a different > | device to the raid root device. > > I think it will. > > | eg, ultra10 whose prom can't talk to my sata disk, and boots from > | a cf/ide fob with just ofwboot and netbsd (and attaches as wd0), > | and mountroots from the raidframe on wd1+wd2. > > Well, there are different options here: > 1. is there a way to pass the root from ofwboot to netbsd? > 2. since netbsd knows it boots normally from raid, you can put a > "root on raidx" statement in your kernel. > 3. you can compile the kernel with RAIDCTL_FORCE_ROOT > 4. we can add an option to mark the raid as force root. kernel configuration changes are not solutions, so 2 and 3 are out. if we do 4, we should instead add an option to mark something as a 'soft root', and leave the current semantics alone. the machines i have that are now not going to reboot properly are both used remotely, so changing semantics about how they work seems like a bad idea. i'm pretty sure i'm not the only one who does this. i think i like this the best. ofwboot doesn't know about the real root -- it can't talk to those disks at all, because it can't talk to the sata controller they're attached to, so i'm not sure how to do 1. .mrg.
Re: CVS commit: src/sys/dev/raidframe
On Wed, Apr 02, 2014 at 06:37:21AM -0400, Christos Zoulas wrote: > On Apr 2, 2:10pm, m...@eterna.com.au (matthew green) wrote: > | i like this.. i think. > | > | i wonder if this will break my system that boot from a different > | device to the raid root device. > > I think it will. > > | eg, ultra10 whose prom can't talk to my sata disk, and boots from > | a cf/ide fob with just ofwboot and netbsd (and attaches as wd0), > | and mountroots from the raidframe on wd1+wd2. > > Well, there are different options here: > 1. is there a way to pass the root from ofwboot to netbsd? There should be - I'd have though that loading the kernel from other than the root parition was needed for some non-raid configurations - eg large disks. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/dev/raidframe
I seemed to have missed the discussion for this change. It seems there are 3 behaviors for root 1) don't change the root device (old behavior with -A yes) 2) if root is on a component, change root to the raid, otherwise don't change. 3) force the root device to be the raid (old behavior with -A root) It seems to me that the behavior 1 (not in case 2) isn't useful, and that we could make behavior 2 the default behavior, with 3 with -A yes. Is there any reason why someone would not want to use the raid for root when a) the system booted from a component and b) it's marked autoconfigurable? If anything, I think there should be a way to disable autoconfiguration. pgpH2Q2GRCSi_.pgp Description: PGP signature
Re: CVS commit: src/sys/dev/raidframe
On Apr 2, 12:51pm, mar...@duskware.de (Martin Husemann) wrote: -- Subject: Re: CVS commit: src/sys/dev/raidframe | On Wed, Apr 02, 2014 at 06:37:21AM -0400, Christos Zoulas wrote: | > Well, there are different options here: | > 1. is there a way to pass the root from ofwboot to netbsd? | > 2. since netbsd knows it boots normally from raid, you can put a | > "root on raidx" statement in your kernel. | > 3. you can compile the kernel with RAIDCTL_FORCE_ROOT | > 4. we can add an option to mark the raid as force root. | | See also PR 44774. | | Another option is to make the new behaviour optional and select it | via boot.cfg (and populate the install media boot.cfg with it defined). I would prefer to have a rootdev= boot.cfg option instead to force things if needed, similar to consdev=. christos
Re: CVS commit: src/sys/dev/raidframe
On Wed, Apr 02, 2014 at 06:37:21AM -0400, Christos Zoulas wrote: > Well, there are different options here: > 1. is there a way to pass the root from ofwboot to netbsd? > 2. since netbsd knows it boots normally from raid, you can put a > "root on raidx" statement in your kernel. > 3. you can compile the kernel with RAIDCTL_FORCE_ROOT > 4. we can add an option to mark the raid as force root. See also PR 44774. Another option is to make the new behaviour optional and select it via boot.cfg (and populate the install media boot.cfg with it defined). Martin
re: CVS commit: src/sys/dev/raidframe
On Apr 2, 2:10pm, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/sys/dev/raidframe | | > Module Name:src | > Committed By: christos | > Date: Wed Apr 2 02:17:01 UTC 2014 | > | > Modified Files: | > src/sys/dev/raidframe: rf_netbsdkintf.c | > | > Log Message: | > If we are autoconfiguring root, then only change the booted_device if | > we booted from one of the components of the root raid set. This allows | > us to boot from other media, without forcing the found raid to always | > be root. Allow the old behavior with RAIDFRAME_FORCE_ROOT. | > XXX: cpu_rootconf() is called twice now, which prints the booted device | > message twice. Perhaps we can remember that cpu_rootconf has been called | > and avoid calling it twice to avoid that. | | i like this.. i think. | | i wonder if this will break my system that boot from a different | device to the raid root device. I think it will. | eg, ultra10 whose prom can't talk to my sata disk, and boots from | a cf/ide fob with just ofwboot and netbsd (and attaches as wd0), | and mountroots from the raidframe on wd1+wd2. Well, there are different options here: 1. is there a way to pass the root from ofwboot to netbsd? 2. since netbsd knows it boots normally from raid, you can put a "root on raidx" statement in your kernel. 3. you can compile the kernel with RAIDCTL_FORCE_ROOT 4. we can add an option to mark the raid as force root. christos
re: CVS commit: src/sys/dev/raidframe
> Module Name: src > Committed By: christos > Date: Wed Apr 2 02:17:01 UTC 2014 > > Modified Files: > src/sys/dev/raidframe: rf_netbsdkintf.c > > Log Message: > If we are autoconfiguring root, then only change the booted_device if > we booted from one of the components of the root raid set. This allows > us to boot from other media, without forcing the found raid to always > be root. Allow the old behavior with RAIDFRAME_FORCE_ROOT. > XXX: cpu_rootconf() is called twice now, which prints the booted device > message twice. Perhaps we can remember that cpu_rootconf has been called > and avoid calling it twice to avoid that. i like this.. i think. i wonder if this will break my system that boot from a different device to the raid root device. eg, ultra10 whose prom can't talk to my sata disk, and boots from a cf/ide fob with just ofwboot and netbsd (and attaches as wd0), and mountroots from the raidframe on wd1+wd2. .mrg.
re: CVS commit: src/sys/dev/raidframe
> Module Name: src > Committed By: yamt > Date: Fri May 27 22:48:25 UTC 2011 > > Modified Files: > src/sys/dev/raidframe: rf_driver.c > > Log Message: > don't forget to destroy mutex. thanks. .mrg.
re: CVS commit: src/sys/dev/raidframe
Module Name: src Committed By:dyoung Date:Thu Nov 5 17:52:32 UTC 2009 Modified Files: src/sys/dev/raidframe: rf_netbsdkintf.c Log Message: Use deviter(9) instead of accessing alldevs directly. Compile-tested, only. this worries me. "compile-tested only" on our raid code base seems like a recipe for data loss. .mrg.
