from Izumi Tsutsui:
> > ahcisata0 port 1: device present, speed: 3.0Gb/s
> > for the two attached SSDs, seemingly triggered by disk activity. These
> > SSDs are running as a RAIDframe mirror. Unpacking the 9.0_RC1 sets with
> > the new kernel triggered around 50 of these, as well as a few
>> [%] If there is any - man.netbsd.org has been improved to the point
>> where it won't talk to me.
> Just curious, what do you mean by this? Do you mean that your web
> browser does not support HTTPS?
Yes. I neither have nor want HTTPS support. I do nothing on the Web
for which HTTPS is
On 01/13, Mouse wrote:
> [%] If there is any - man.netbsd.org has been improved to the point
> where it won't talk to me.
Just curious, what do you mean by this? Do you mean that your web
browser does not support HTTPS?
Lewis
> If neither of those work, then maybe we should adapt ktrace to
> support many simultaneous ktraces of a single process, but I don't
> want to commit more resources to maintaining that unless we have a
> real need.
Well, it seems to me that the choices are:
(1) Keep meta-make as it is, filemon
> On Jan 13, 2020, at 10:24 AM, Christos Zoulas wrote:
>
> Talking to myself:
>
> The arm PAGE_SIZE_{MIN,MAX} should go away after nick eliminates the
> need for the 8K pages. This leaves us with m68k to deal with...
> Do modules work on m68k? Should modules be shared between kernels with
>
On Mon, Jan 13, 2020 at 08:46:26AM -0500, Mouse wrote:
> >>> replaces make's use of /dev/filemon by ktrace, in meta mode.
> >> How does this interact with someone ktracing a make run?
> > Don't use meta mode in that case. It is not the default.
>
> Well, if I'm trying to use make's meta
> At sjg's request, there's a compile-time option -- setting the make
> variable USE_FILEMON=ktrace vs USE_FILEMON=dev -- to switch between
> filemon back ends, since Juniper still uses /dev/filemon on FreeBSD
> which has seen more maintenance, security, and performance updates.
> (This
> Date: Mon, 13 Jan 2020 06:09:20 -0500 (EST)
> From: Mouse
>
> > - What instead? The attached patch (patch set make-meta-v2.patch;
> > combined diff make-meta-v2.diff) replaces make's use of
> > /dev/filemon by ktrace, in meta mode.
>
> How does this interact with someone ktracing a make
>> Then I think possibly the right answer for the moment is for me to
>> excise rump from my tree entirely. [...]
> But it seems really obvious that you should fix the rump build and
> write some atf test cases for your SCM_MEMORY stuff, and then you
> will be able to test it automatically.
I
On Jan 14, 1:15am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/incl
| christos@ wrote:
|
| > >Now I get the following erro during local tests of
| > >"build.sh -U -m hp300 release" on NetBSD/i386 9.0_RC1 host:
| > >
| >
Mouse writes:
>> The rump build is done with separate reachover makefiles. [...]
>
> Hm. Then I think possibly the right answer for the moment is for me to
> excise rump from my tree entirely. I can't recall ever wanting its
> functionality, and trying to figure out what the dependency graph
jdolecek@ wrote:
> > problem with Samsung EVO 860 disks and AMD SB710/750 chipsets. The
> > problem also occurs on Windows and Linux with these drives and chipsets.
:
> If they are known broken, seems we indeed need to add a quirk entry to
> disable NCQ for these drives, and push it into NetBSD
mueller6725@ wrote:
> Would "sysctl hw.wd2.use_ncq=0" from the command line have the same effect?
> What about "sysctl -w hw.wd2.use_ncq=0" ? What is the effect of "-w" here?
"man 8 sysctl" says
> -wSets the MIB style name given to the value given.
i.e. it just means "write a value".
Maybe
>>> replaces make's use of /dev/filemon by ktrace, in meta mode.
>> How does this interact with someone ktracing a make run?
> Don't use meta mode in that case. It is not the default.
Well, if I'm trying to use make's meta mode and it misbehaves, this
sounds as though ktrace is not available
On Mon, Jan 13, 2020 at 06:09:20AM -0500, Mouse wrote:
> > - What instead? The attached patch (patch set make-meta-v2.patch;
> > combined diff make-meta-v2.diff) replaces make's use of
> > /dev/filemon by ktrace, in meta mode.
>
> How does this interact with someone ktracing a make run? If
On Mon, Jan 13, 2020 at 10:39:19PM +1100, Simon Burge wrote:
> I _think_ the problem is restricted to 860 EVO drives, not 860 PRO drives.
Duh - sorry for not reading properly
Martin
Martin Husemann wrote:
> On Mon, Jan 13, 2020 at 12:07:44PM +0100, Jarom\xedr Dole?ek wrote:
> > If they are known broken, seems we indeed need to add a quirk entry to
> > disable NCQ for these drives, and push it into NetBSD 9.0 branch.
>
> Please restrict to the affected sata controllers too.
On Mon, Jan 13, 2020 at 12:07:44PM +0100, Jaromír Dole?ek wrote:
> If they are known broken, seems we indeed need to add a quirk entry to
> disable NCQ for these drives, and push it into NetBSD 9.0 branch.
Please restrict to the affected sata controllers too.
I have:
ahcisata0 at pci2 dev 0
> - What instead? The attached patch (patch set make-meta-v2.patch;
> combined diff make-meta-v2.diff) replaces make's use of
> /dev/filemon by ktrace, in meta mode.
How does this interact with someone ktracing a make run? If it that
breaks make, I think this is a very bad idea; if it
Le lun. 13 janv. 2020 à 11:56, Simon Burge a écrit :
> A bit more digging shows that this seems to be a (somewhat) known
> problem with Samsung EVO 860 disks and AMD SB710/750 chipsets. The
> problem also occurs on Windows and Linux with these drives and chipsets.
>
> Here's a couple of links:
>
Simon Burge wrote:
> Izumi Tsutsui wrote:
>
> > [ ... ]
> >
> > I have similar problems, as filed in PR/54790.
> > https://gnats.netbsd.org/54790
> >
> > No "ahcisata0 port 1: device present, speed: 3.0Gb/s"
> > but many soft errors. No error on NetBSD 8.1 GENERIC.
> >
> > The problem here
I posted this message a few hours ago but see I forgot the subject line.
from Izumi Tsutsui:
> > ahcisata0 port 1: device present, speed: 3.0Gb/s
> > for the two attached SSDs, seemingly triggered by disk activity. These
> > SSDs are running as a RAIDframe mirror. Unpacking the 9.0_RC1
from Izumi Tsutsui:
> > ahcisata0 port 1: device present, speed: 3.0Gb/s
> > for the two attached SSDs, seemingly triggered by disk activity. These
> > SSDs are running as a RAIDframe mirror. Unpacking the 9.0_RC1 sets with
> > the new kernel triggered around 50 of these, as well as a few
23 matches
Mail list logo
