On Mon, Aug 08, 2022 at 07:18:05AM -0700, Paul Goyette wrote:
> (personal note)
> It really seems to me that the current module sub-systems is at
> best a second-class capability. I often get the feeling that
> others don't really care about modules, until it's the only way
> to provide
On 8/08/22 21:37, Edgar Fuß wrote:
Does anyone use a Dell PERC H730P or similar RAID controller in RAID mode?
I have several NetBSD systems with PERC H730P's
mfii(4) says all configuration is done via the controller's BIOS.
Does that mean I need to shut down in case a drive fails an I
Thomas Klausner wrote:
To reply to this point - I'm very interested in modules, but it
doesn't meet a basic requirement for me - easily going back to a
previous kernel when the new one is broken for some reason - if they
share the same kernel version, they share the same
On Sun, Aug 07, 2022 at 23:08:47 +, Taylor R Campbell wrote:
> Currently there are many types of modules that are autoloaded from
> open-ended patterns:
Our current auto-load policy is a bit too enthusiastic, IMHO. E.g. an
"unknown" ioctl used to (probably still does) trigger autoload of
Paul Goyette writes:
> (personal note)
> It really seems to me that the current module sub-systems is at
> best a second-class capability. I often get the feeling that
> others don't really care about modules, until it's the only way
> to provide something else (dtrace). This proposal feels
On Mon, Aug 08, 2022 at 07:18:05AM -0700, Paul Goyette wrote:
> It really seems to me that the current module sub-systems is at
> best a second-class capability. I often get the feeling that
> others don't really care about modules, until it's the only way
> to provide something else (dtrace).
On Mon, 8 Aug 2022, Martin Husemann wrote:
On Mon, Aug 08, 2022 at 09:24:28AM -0400, Greg Troxel wrote:
Given where we are, do you really mean
we should withdraw every module from autoload that does not have a
documented test result, right now?
It seems far better to have them stay
On Mon, Aug 08, 2022 at 09:24:28AM -0400, Greg Troxel wrote:
> Given where we are, do you really mean
>
> we should withdraw every module from autoload that does not have a
> documented test result, right now?
>
> It seems far better to have them stay loaded than be unavailable.
I'm not
Martin Husemann writes:
> I think that all modules that we deliver and declare safe for *autoload*
> should require to be actually tested, and a basic test (for me) includes
> testing auto-unload. That does not cover races that slip through "casual"
> testing, but should have caught the worst
Hi.
On 2022/08/08 19:41, Edgar Fuß wrote:
> Thanks for your answers.
>
>> Some people reported that kern/56669 (and perhaps kern/55192) still exist
>> on some systems :-(
> Hm.
>
>> bioctl mfi(i)X show
> Ah, thanks.
> What do I do in case a drive fails? Will adding a hot spare automagically
>
I reviewed the bus_dmamap_sync calls in sys/dev/pci/virtio.c and found
several likely bugs by code inspection, including misuse of membar_*.
The attached patch fixes all the issues I saw, and removes the
membar_* calls in favour of bus_dmamap_sync. Details in attached
commit message.
qemu
Thanks for your answers.
> Some people reported that kern/56669 (and perhaps kern/55192) still exist
> on some systems :-(
Hm.
> bioctl mfi(i)X show
Ah, thanks.
What do I do in case a drive fails? Will adding a hot spare automagically start
a reconstruction?
> If your system has other number,
On 2022/08/08 18:37, Edgar Fuß wrote:
> I'm unsure whether this is the right list, is port-amd64 more appropriate?
>
> Does anyone use a Dell PERC H730P or similar RAID controller in RAID mode?
It seems PERC H730P's device ID is 0x005d.
https://pci-ids.ucw.cz/read/PC/1000/005d
It's
I'm unsure whether this is the right list, is port-amd64 more appropriate?
Does anyone use a Dell PERC H730P or similar RAID controller in RAID mode?
mfii(4) says all configuration is done via the controller's BIOS.
Does that mean I need to shut down in case a drive fails an I need to rebuild?
> Date: Mon, 8 Aug 2022 09:09:11 +0200
> From: Martin Husemann
>
> On Sun, Aug 07, 2022 at 11:08:47PM +, Taylor R Campbell wrote:
> > Some modules might still be unsafe to unload, which is a bug -- but at
> > least this way accidentally creating the wrong network interface or
> > opening the
On Sun, Aug 07, 2022 at 11:08:47PM +, Taylor R Campbell wrote:
> Some modules might still be unsafe to unload, which is a bug -- but at
> least this way accidentally creating the wrong network interface or
> opening the wrong device won't set a ten-second time-bomb for the
> system like I
Le lun. 8 août 2022 à 07:23, Taylor R Campbell
a écrit :
> I propose we remove the assumption that ENOTTY means no objection, and
> switch from opt-out to opt-in: if a module _has_ been audited to
> verify MODULE_CMD_AUTOUNLOAD is safe, it can return 0; otherwise it
> will never be autounloaded,
17 matches
Mail list logo
