"Christos Zoulas" wrote:
> Log Message:
>
> Don't crash if we are on a hippie trail, head full of zombie
+1 for any Australian references in a commit message :)
Cheers,
Simon.
Andrew Doran writes:
> I also recommend disabling ACPI idle, at least until it can be made less
> aggressive by default. It causes a significant slowdown. It can be done
> with detaching all acpicpu devices using "drvctl -d" on each.
this disables cpufreq support, doesn't it? that seems like
On Fri, Jan 10, 2020 at 10:21:25PM +, Andrew Doran wrote:
> Hi Frank,
>
> On Fri, Jan 10, 2020 at 01:10:02PM +0100, Frank Kardel wrote:
>
> > Hi !
> >
> > With this state of January 2nd we ran some tests for robustness and timing
> > with our database setup:
> >
> > Machine:
> >
> >
On 2020/01/21 20:20, Patrick Welche wrote:
> On Tue, Jan 21, 2020 at 03:48:27PM +0900, Masanobu SAITOH wrote:
>> I suspect the location of your panic is after the following message
>> (because of ixgbe_allocate_msix()'s failure):
>>
>>> aprint_normal(" ETrackID %08x\n", ((uint32_t)high <<
On Tue, Jan 21, 2020 at 03:48:27PM +0900, Masanobu SAITOH wrote:
> I suspect the location of your panic is after the following message
> (because of ixgbe_allocate_msix()'s failure):
>
> > aprint_normal(" ETrackID %08x\n", ((uint32_t)high << 16) | low);
Exactly right:
ixg0 at pci8 dev 0
Hi.
On 2020/01/21 2:06, Patrick Welche wrote:
> On Mon, Jan 20, 2020 at 04:12:45PM +, Patrick Welche wrote:
>> On Mon, Jan 20, 2020 at 12:51:00PM +, Andrew Doran wrote:
>>> This also happened the last time I touched rw_downgrade(), and I backed out
>>> the change then, but both times I
> On Jan 20, 2020, at 3:44 PM, Christos Zoulas wrote:
>
> In article <20200120185023.gd28...@homeworld.netbsd.org>,
> Andrew Doran wrote:
>> Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
>> problem as I am running with LOCKDEBUG.
>>
>> Apologies for the disruption.
>
In article <20200120185023.gd28...@homeworld.netbsd.org>,
Andrew Doran wrote:
>Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
>problem as I am running with LOCKDEBUG.
>
>Apologies for the disruption.
FYI: powerpc/arm do not build anymore...
На 2020-01-20 в 18:50, Andrew Doran написа:
> Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
> problem as I am running with LOCKDEBUG.
>
> Apologies for the disruption.
All good now, thanks.
> Andrew
Hi,
Thanks for your quick fix.
It works fine for my laptop now.
On January 21, 2020 3:50:23 AM GMT+09:00, Andrew Doran wrote:
>Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
>problem as I am running with LOCKDEBUG.
>
>Apologies for the disruption.
>
>Andrew
--
Ryo
On Mon, Jan 20, 2020 at 04:12:45PM +, Patrick Welche wrote:
> On Mon, Jan 20, 2020 at 12:51:00PM +, Andrew Doran wrote:
> > This also happened the last time I touched rw_downgrade(), and I backed out
> > the change then, but both times I don't see the bug. I have some questions:
> >
> >
Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
problem as I am running with LOCKDEBUG.
Apologies for the disruption.
Andrew
On Mon, Jan 20, 2020 at 09:28:32AM -0800, Paul Goyette wrote:
> On Mon, 20 Jan 2020, Patrick Welche wrote:
>
> > On Mon, Jan 20, 2020 at 12:51:00PM +, Andrew Doran wrote:
> > > This also happened the last time I touched rw_downgrade(), and I backed
> > > out
> > > the change then, but both
On Mon, Jan 20, 2020 at 12:51:00PM +, Andrew Doran wrote:
> This also happened the last time I touched rw_downgrade(), and I backed out
> the change then, but both times I don't see the bug. I have some questions:
>
> - Are you running DIAGNOSTIC and/or LOCKDEBUG? I would be very interested
On Mon, 20 Jan 2020, Patrick Welche wrote:
On Mon, Jan 20, 2020 at 12:51:00PM +, Andrew Doran wrote:
This also happened the last time I touched rw_downgrade(), and I backed out
the change then, but both times I don't see the bug. I have some questions:
- Are you running DIAGNOSTIC and/or
Thanks. I can reproduce a hang on boot in qemu. It's hanging starting
init, waiting on "needbuf". Investigating now.
Andrew
On Mon, Jan 20, 2020 at 04:12:45PM +, Patrick Welche wrote:
> On Mon, Jan 20, 2020 at 12:51:00PM +, Andrew Doran wrote:
> > This also happened the last time I
On Mon, Jan 20, 2020 at 12:51:00PM +, Andrew Doran wrote:
> This also happened the last time I touched rw_downgrade(), and I backed out
> the change then, but both times I don't see the bug. I have some questions:
>
> - Are you running DIAGNOSTIC and/or LOCKDEBUG? I would be very interested
On Mon, Jan 20, 2020 at 12:51:00PM +, Andrew Doran wrote:
> This also happened the last time I touched rw_downgrade(), and I backed out
> the change then, but both times I don't see the bug. I have some questions:
2 amd64 boxes, let's call them a) and b)
> - Are you running DIAGNOSTIC
Hi,
Jason Thorpe writes:
>> On Jan 20, 2020, at 6:48 AM, Ryo ONODERA wrote:
>>
>> The black screen and ims(4) panic are not related to your change.
>> Older src tree with LOCKDEBUG reproduces these problem.
>
> I'll look at the ims(4) issuer.
Thank you very much.
I can test any patch.
> --
> On Jan 20, 2020, at 6:48 AM, Ryo ONODERA wrote:
>
> The black screen and ims(4) panic are not related to your change.
> Older src tree with LOCKDEBUG reproduces these problem.
I'll look at the ims(4) issuer.
-- thorpej
Ryo ONODERA writes:
> Ryo ONODERA writes:
>
>> Hi,
>>
>> Andrew Doran writes:
>>
>>> Hi,
>>>
>>> This also happened the last time I touched rw_downgrade(), and I backed out
>>> the change then, but both times I don't see the bug. I have some questions:
>>>
>>> - Are you running DIAGNOSTIC
Ryo ONODERA writes:
> Hi,
>
> Andrew Doran writes:
>
>> Hi,
>>
>> This also happened the last time I touched rw_downgrade(), and I backed out
>> the change then, but both times I don't see the bug. I have some questions:
>>
>> - Are you running DIAGNOSTIC and/or LOCKDEBUG? I would be very
On Mon, 20 Jan 2020, Andrew Doran wrote:
Hi,
This also happened the last time I touched rw_downgrade(), and I backed out
the change then, but both times I don't see the bug. I have some questions:
- Are you running DIAGNOSTIC and/or LOCKDEBUG? I would be very interested
to see what happens
On Mon, 20 Jan 2020 at 13:06, Ryo ONODERA wrote:
>
> Hi,
>
> Andrew Doran writes:
>
> > Hi,
> >
> > This also happened the last time I touched rw_downgrade(), and I backed out
> > the change then, but both times I don't see the bug. I have some questions:
> >
> > - Are you running DIAGNOSTIC
Hi,
Andrew Doran writes:
> Hi,
>
> This also happened the last time I touched rw_downgrade(), and I backed out
> the change then, but both times I don't see the bug. I have some questions:
>
> - Are you running DIAGNOSTIC and/or LOCKDEBUG? I would be very interested
> to see what happens
Hi,
This also happened the last time I touched rw_downgrade(), and I backed out
the change then, but both times I don't see the bug. I have some questions:
- Are you running DIAGNOSTIC and/or LOCKDEBUG? I would be very interested
to see what happens with a LOCKDEBUG kernel here.
- Do you
On Mon, 20 Jan 2020, Ryo ONODERA wrote:
Hi,
After this commit, the kernel stalls just before root file system
will be found on my NetBSD/amd64 laptop.
Reverting
src/sys/kern/kern_rwlock.c to r1.60
and
src/sys/sys/rwlock.h to r1.12
in latest -current tree and I can get the kernel that works
Sorry I have note sent this e-mail to you.
Ryo ONODERA writes:
> Hi,
>
> After this commit, the kernel stalls just before root file system
> will be found on my NetBSD/amd64 laptop.
>
> Reverting
> src/sys/kern/kern_rwlock.c to r1.60
> and
> src/sys/sys/rwlock.h to r1.12
> in latest -current
Hi,
After this commit, the kernel stalls just before root file system
will be found on my NetBSD/amd64 laptop.
Reverting
src/sys/kern/kern_rwlock.c to r1.60
and
src/sys/sys/rwlock.h to r1.12
in latest -current tree and I can get the kernel that works like
before.
And on another laptop, the
On 10.01.2020 23:21, Andrew Doran wrote:
> The second is pulling in efficient tracking of page clean/dirty status from
> the yamt-pagecache branch. This reduces the amount of work fsync() needs to
> do, which should be of benefit to the DBMS.
>
We probably should adapt DBMS to use
On 2020/01/10 15:59, Jason Thorpe wrote:
>
>
>> On Jan 9, 2020, at 9:02 PM, Masanobu SAITOH wrote:
>>
>> The reason why I moved stge_softc to if_stgereg.h was that ipgphy.c
>> required to check stge's chip revision. So, if there is no any objection,
>> I'll make new if_stgevar.h and share it
In article <20200113163830.e7a6317f...@rebar.astron.com>,
Christos Zoulas wrote:
>|
>| Probably this is the same reason of recent arm build failures:
>| https://releng.netbsd.org/builds/HEAD/202001130720Z/
>| https://releng.netbsd.org/builds/HEAD/202001130720Z/evbarm-earm.build.failed
>| ---
> On Jan 13, 2020, at 8:15 AM, Izumi Tsutsui wrote:
>
> 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:
>>>
>>> ---
>>> #create compat_util/compat_exec.d
> :
>>> In file included from
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 Ne
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:
> >
> >---
> >#create compat_util/compat_exec.d
:
> >In file included from /s/cvs/src/sys/sys/param.h:149:0,
> > from
In article <200114002918.m0108...@mirage.ceres.dti.ne.jp>,
Izumi Tsutsui wrote:
>christos@ wrote:
>
>> LGTM too.
>
>> >> thorpej@ wrote:
> :
>> >> How about the attached diff? (untested, just for review)
>> >
>> > This looks good to me.
>
>Now I get the following erro during local tests of
christos@ wrote:
> LGTM too.
> >> thorpej@ wrote:
:
> >> How about the attached diff? (untested, just for review)
> >
> > This looks good to me.
Now I get the following erro during local tests of
"build.sh -U -m hp300 release" on NetBSD/i386 9.0_RC1 host:
---
#create
On Mon, Jan 13, 2020 at 06:54:33AM -0800, Jason Thorpe wrote:
> > On Jan 12, 2020, at 10:20 PM, Kamil Rytarowski wrote:
> >
> > While there, could we garbage collect unused defines from sys/param.h?
> >
> > I'm thinking in particular about:
>
> As long as we still have tsleep(9) and friends,
> On Jan 12, 2020, at 10:20 PM, Kamil Rytarowski wrote:
>
> While there, could we garbage collect unused defines from sys/param.h?
>
> I'm thinking in particular about:
As long as we still have tsleep(9) and friends, we can't rid ourselves of these
historical defines.
Perhaps we should
On 12.01.2020 23:03, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun Jan 12 22:03:23 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_exec.c kern_runq.c
> src/sys/sys: lwp.h sched.h
>
> Log Message:
> A final set of scheduler tweaks:
>
Great work!
We should absolutely verify this under DEBUG.
-- thorpej
Sent from my iPhone.
> On Jan 12, 2020, at 11:25 AM, Joerg Sonnenberger wrote:
>
> On Sun, Jan 12, 2020 at 01:01:12PM +, Andrew Doran wrote:
>> Module Name:src
>> Committed By:ad
>> Date:Sun Jan 12 13:01:12 UTC 2020
On Sun, Jan 12, 2020 at 08:25:27PM +0100, Joerg Sonnenberger wrote:
> On Sun, Jan 12, 2020 at 01:01:12PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sun Jan 12 13:01:12 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/x86/include:
On Sun, Jan 12, 2020 at 01:01:12PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun Jan 12 13:01:12 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/include: pmap.h pmap_pv.h
> src/sys/arch/x86/x86: pmap.c vm_machdep.c x86_tlb.c
>
> Log Message:
>
LGTM too.
christos
> On Jan 12, 2020, at 10:09 AM, Jason Thorpe wrote:
>
>
>
>> On Jan 11, 2020, at 10:47 PM, Izumi Tsutsui wrote:
>>
>> thorpej@ wrote:
>>
PGSHIFT is defined in and
PAGE_SHIFT and PAGE_SIZE is in ,
but there is no common .
>>>
>>> Make a common that all
> On Jan 11, 2020, at 10:47 PM, Izumi Tsutsui wrote:
>
> thorpej@ wrote:
>
>>> PGSHIFT is defined in and
>>> PAGE_SHIFT and PAGE_SIZE is in ,
>>> but there is no common .
>>
>> Make a common that all of the platforms can #include, and
>> just put these common definitions in it (for now)?
On Sun, Jan 12, 2020 at 01:30:57PM +, Nick Hudson wrote:
> On 12/01/2020 13:19, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sun Jan 12 13:19:32 UTC 2020
> >
> > Modified Files:
> > src/sys/sys: param.h
> >
> > Log Message:
> > Bump
On 12/01/2020 13:19, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Sun Jan 12 13:19:32 UTC 2020
Modified Files:
src/sys/sys: param.h
Log Message:
Bump MIN_LWP_ALIGNMENT to 64.
Should aarch64/mips define MIN_LWP_ALIGNMENT as 128 as they have CPUs
that have
thorpej@ wrote:
> > PGSHIFT is defined in and
> > PAGE_SHIFT and PAGE_SIZE is in ,
> > but there is no common .
>
> Make a common that all of the platforms can #include, and
> just put these common definitions in it (for now)?
How about the attached diff? (untested, just for review)
- Only
> On Jan 11, 2020, at 8:32 PM, Izumi Tsutsui wrote:
>
> PGSHIFT is defined in and
> PAGE_SHIFT and PAGE_SIZE is in ,
> but there is no common .
Make a common that all of the platforms can #include, and just
put these common definitions in it (for now)?
-- thorpej
> >m68k also needs this? (currently no common though)
>
> Good catch. Yup, looks like it:
:
>
> #define MIN_PAGE_SHIFT 11 /* sun2 */
> #define MAX_PAGE_SHIFT 13 /* amiga,atari,sun3 */
> #define MIN_PAGE_SIZE (1 << MIN_PAGE_SHIFT)
In article <200112121414.m0101...@mirage.ceres.dti.ne.jp>,
Izumi Tsutsui wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Jan 11 19:06:35 UTC 2020
>>
>> Modified Files:
>> src/sys/arch/arm/include/arm32: vmparam.h
>>
>> Log Message:
>> Define the min
> Module Name: src
> Committed By: christos
> Date: Sat Jan 11 19:06:35 UTC 2020
>
> Modified Files:
> src/sys/arch/arm/include/arm32: vmparam.h
>
> Log Message:
> Define the min and max page size supported for the benefit of jemalloc
>
>
> To generate a diff of this commit:
>
Hi Frank,
On Fri, Jan 10, 2020 at 01:10:02PM +0100, Frank Kardel wrote:
> Hi !
>
> With this state of January 2nd we ran some tests for robustness and timing
> with our database setup:
>
> Machine:
>
> Mainboard: S2600WFT
>
> CPU: 2 x Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz
>
>
Hi !
With this state of January 2nd we ran some tests for robustness and
timing with our database setup:
Machine:
Mainboard: S2600WFT
CPU: 2 x Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz
machdep.spectre_v1.mitigated = 0
machdep.spectre_v2.hwmitigated = 1
machdep.spectre_v2.swmitigated = 1
> On Jan 9, 2020, at 9:02 PM, Masanobu SAITOH wrote:
>
> The reason why I moved stge_softc to if_stgereg.h was that ipgphy.c
> required to check stge's chip revision. So, if there is no any objection,
> I'll make new if_stgevar.h and share it with if_stge.c and ipgphy.c.
That seems fine.
On 2020/01/10 13:13, Jason Thorpe wrote:
>
>
>> On Jan 9, 2020, at 6:11 PM, Masanobu SAITOH wrote:
>>
>>
>> Before my change, struct stge_softc is already in if_stgereg.h,
>> so I had thought it would be OK to move to it.
>
> Ah, I don't think I would have put it there when I wrote the driver
> On Jan 9, 2020, at 6:11 PM, Masanobu SAITOH wrote:
>
>
> Before my change, struct stge_softc is already in if_stgereg.h,
> so I had thought it would be OK to move to it.
Ah, I don't think I would have put it there when I wrote the driver originally,
so it must have been moved there at
> Two options:
>
> a) Move some structs (including struct stge_softc) and defines
> to if_stge.c
>
> b) Move them to new if_stgevar.h
i've always preferred:
- fooreg.h and foovar.h exist only when more than 1
file use them
- fooreg.h ONLY has hardware constructs
- foovar.h
On 2020/01/09 23:08, Jason Thorpe wrote:
>
>
>> On Jan 9, 2020, at 2:54 AM, SAITOH Masanobu wrote:
>>
>> Module Name: src
>> Committed By:msaitoh
>> Date:Thu Jan 9 10:54:16 UTC 2020
>>
>> Modified Files:
>> src/sys/dev/pci: if_stge.c if_stgereg.h
>>
>> Log Message:
> On Jan 9, 2020, at 2:54 AM, SAITOH Masanobu wrote:
>
> Module Name: src
> Committed By: msaitoh
> Date: Thu Jan 9 10:54:16 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: if_stge.c if_stgereg.h
>
> Log Message:
> Reduce diff against OpenBSD. No functional change.
>
> -
Ryo ONODERA wrote:
> However I need multiboot support for amd64.
> I am waiting well-tested implementation.
At this point the problems are more about code style and cleaning, as we
have a fix for the boot bugs that has been reported.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
Hi,
However I need multiboot support for amd64.
I am waiting well-tested implementation.
"Emmanuel Dreyfus" writes:
> Module Name: src
> Committed By: manu
> Date: Thu Jan 9 00:42:24 UTC 2020
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S machdep.c
>
On 05/01/2020 13:47, Izumi Tsutsui wrote:
[snip]
My patch allows COPTS to be overridden as
http://src.illumos.org/source/xref/netbsd-src/sys/conf/Makefile.kern.inc#69
has
69 DEFCOPTS?= -O2
70 COPTS?= ${DEFCOPTS}
which I believe allows COPTS to be overridden by
makeoptions
On Sun, Jan 05, 2020 at 02:43:43PM +0100, Maxime Villard wrote:
> I have now requested to core@ that multiboot in amd64 be reverted entirely.
So far I privilegied working on a fix to the boot problem that was
reported, rather than spending time on a revert. This was not a futile
effort, since at
> >> I don't see how as sys/arch/zaurus/conf/INSTALL doesn't define DDB.
> >
> > On zaurus GENERIC also has a size restriction (due to bootloader).
>
> Yes, I understand that. What I don't understand is how my
> sys/arch/arm/conf/Makefile.arm change affects the zaurus INSTALL kernel
> size
Le 05/01/2020 à 13:56, Maxime Villard a écrit :
> Le 05/01/2020 à 02:03, Emmanuel Dreyfus a écrit :
>> On Sat, Jan 04, 2020 at 08:43:16AM +0100, Maxime Villard wrote:
>>> +.section multiboot,"",@note
>>> Why @note? It will be in the .text anyway. Also why no dot in the section
>>> name? That's
On 05/01/2020 13:31, Martin Husemann wrote:
On Sun, Jan 05, 2020 at 01:21:46PM +, Nick Hudson wrote:
Yes, I understand that. What I don't understand is how my
sys/arch/arm/conf/Makefile.arm change affects the zaurus INSTALL kernel
size because INSTALL specifically disables DDB and my patch
On Sun, Jan 05, 2020 at 01:21:46PM +, Nick Hudson wrote:
> Yes, I understand that. What I don't understand is how my
> sys/arch/arm/conf/Makefile.arm change affects the zaurus INSTALL kernel
> size because INSTALL specifically disables DDB and my patch is
> conditional on DDB
It did only
On 04/01/2020 16:32, Izumi Tsutsui wrote:
The problem is caused by sys/arch/arm/conf/Makefile.arm.
It defines "COPTS+= -mapcs-frame" in recent rev 1.52
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/conf/Makefile.arm#rev1.52
but MI sys/conf/Makefile.kern.inc defines COPTS+=-O2
only
Le 05/01/2020 à 02:03, Emmanuel Dreyfus a écrit :
> On Sat, Jan 04, 2020 at 08:43:16AM +0100, Maxime Villard wrote:
>> +.section multiboot,"",@note
>> Why @note? It will be in the .text anyway. Also why no dot in the section
>> name? That's supposed to be the naming convention.
>
> The idea is
On Sat, Jan 04, 2020 at 08:43:16AM +0100, Maxime Villard wrote:
> +.section multiboot,"",@note
> Why @note? It will be in the .text anyway. Also why no dot in the section
> name? That's supposed to be the naming convention.
The idea is that one day if ld gets more reasonable, it could go in
On Sat, Jan 04, 2020 at 08:43:16AM +0100, Maxime Villard wrote:
> As said repeatedly, the option should be enabled only _after_ the garbage
> has been cleaned up.
This is not easy if you just call it that. To me it looks like Emanuel
is trying very hard to address all technical issues brought up
> > The problem is caused by sys/arch/arm/conf/Makefile.arm.
> > It defines "COPTS+= -mapcs-frame" in recent rev 1.52
> >
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/conf/Makefile.arm#rev1.52
> > but MI sys/conf/Makefile.kern.inc defines COPTS+=-O2
> > only if COPTS is empty.
>
>
On 03/01/2020 18:42, Izumi Tsutsui wrote:
I wrote:
The missing COPTS was an accident or fallout from some other changes?
Isn't it specified in -current?
The problem is caused by sys/arch/arm/conf/Makefile.arm.
It defines "COPTS+= -mapcs-frame" in recent rev 1.52
Le 04/01/2020 à 03:33, Emmanuel Dreyfus a écrit :
On Tue, Dec 31, 2019 at 09:32:05AM +0100, Maxime Villard wrote:
I think max-page-size=0x1000 is the right thing to do, but someone needs to
verify that the resulting binary is correct and that the resulting in-memory
layout is correct too.
Hey Jason,
Jason Thorpe wrote:
> > On Jan 3, 2020, at 10:11 AM, Frank Kardel wrote:
> >
> > Hi Jason !
> >
> > Could you please check that kmem using tools can cope with the missing
> > _boottime symbol.
>
> Hey Frank... this should fix it:
>
> $NetBSD: vmstat.c,v 1.231 2020/01/03
Jason Thorpe wrote:
> > Is it worth keeping the boottime symbol about so that a netbsd-9 vmstat
> > binary will still work with a -current kernel? We could possibly wrap
> > boottime with a COMPAT_90 check too?.
>
> Define "work". A dummy symbol would have no valid contents. I guess
> if you
On Tue, Dec 31, 2019 at 09:32:05AM +0100, Maxime Villard wrote:
> I think max-page-size=0x1000 is the right thing to do, but someone needs to
> verify that the resulting binary is correct and that the resulting in-memory
> layout is correct too.
Attached is an updated patch with this approach. I
> On Jan 3, 2020, at 5:08 PM, Simon Burge wrote:
>
> Hey Jason,
>
> Jason Thorpe wrote:
>
>>> On Jan 3, 2020, at 10:11 AM, Frank Kardel wrote:
>>>
>>> Hi Jason !
>>>
>>> Could you please check that kmem using tools can cope with the missing
>>> _boottime symbol.
>>
>> Hey Frank... this
Great. works again.
Frank
On 01/03/20 20:14, Jason Thorpe wrote:
On Jan 3, 2020, at 10:11 AM, Frank Kardel wrote:
Hi Jason !
Could you please check that kmem using tools can cope with the missing
_boottime symbol.
Hey Frank... this should fix it:
$NetBSD: vmstat.c,v 1.231
On Sat, Jan 04, 2020 at 03:42:20AM +0900, Izumi Tsutsui wrote:
> The problem is caused by sys/arch/arm/conf/Makefile.arm.
> It defines "COPTS+= -mapcs-frame" in recent rev 1.52
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/conf/Makefile.arm#rev1.52
> but MI sys/conf/Makefile.kern.inc
Frank Kardel writes:
> Hi Jason !
>
> Could you please check that kmem using tools can cope with the missing
> _boottime symbol.
>
> E.g.:
>
> # vmstat -s
> vmstat: undefined symbols: _boottime
> #
>
> This renders vmstat currently broken.
>
> Best regards
ah, i wondered if this would
> On Jan 3, 2020, at 10:11 AM, Frank Kardel wrote:
>
> Hi Jason !
>
> Could you please check that kmem using tools can cope with the missing
> _boottime symbol.
Hey Frank... this should fix it:
$NetBSD: vmstat.c,v 1.231 2020/01/03 19:13:54 thorpej Exp $
-- thorpej
I wrote:
> > The missing COPTS was an accident or fallout from some other changes?
>
> Isn't it specified in -current?
The problem is caused by sys/arch/arm/conf/Makefile.arm.
It defines "COPTS+= -mapcs-frame" in recent rev 1.52
Hi Jason !
Could you please check that kmem using tools can cope with the missing
_boottime symbol.
E.g.:
# vmstat -s
vmstat: undefined symbols: _boottime
#
This renders vmstat currently broken.
Best regards
Frank
On 01/02/20 16:42, Jason R Thorpe wrote:
Module Name:src
Committed
> > - zbsdmod.o has 5MB buffers to store a copied kernel binary
> > - zbsdmod.o reads a kernel from the 5MB buffer and loads sections
> > into the target addresses
> >
> > https://nxr.netbsd.org/xref/src/sys/arch/zaurus/stand/zbsdmod/zbsdmod.c?r=1.12#94
>
> Ah ok - thanks for explanation. So
On Fri, Jan 03, 2020 at 07:36:34PM +0900, Izumi Tsutsui wrote:
> - zbsdmod.o has 5MB buffers to store a copied kernel binary
> - zbsdmod.o reads a kernel from the 5MB buffer and loads sections
> into the target addresses
>
>
martin@ wrote:
> Module Name: src
> Committed By: martin
> Date: Fri Jan 3 10:01:07 UTC 2020
>
> Modified Files:
> src/sys/arch/zaurus/conf: Makefile.zaurus.inc ldscript.zaurus
>
> Log Message:
> Drop CTF sections from this size restricted kernel (especially as the
> size check
Masanobu SAITOH wrote:
> I have a UEFI boot machine and it also doesn't boot well.
>
> - It hangs after attaching ioapic0, cpu0 or acpi0 (or something else).
>The possibility is about 65%
> - It sometimes panic in acpi_attach(), acpimcfg_probe or something else.
>The possibility is
"Andrew Doran" writes:
> Module Name: src
> Committed By: ad
> Date: Fri Dec 27 13:19:25 UTC 2019
>
> Modified Files:
> src/sys/uvm: uvm.h uvm_page.c
>
> Log Message:
> Nothing uses uvm.cpus any more, and we can do the same with cpu_lookup(),
> so get rid of it.
this has been
> > So I guess we won't be switching pg->phys_addr from paddr to pfn?
> > Speaking of which, any plans for expanding to >32-bit (or >31-bit, if
> > signed) pfns in the rest of uvm?
>
> That's not part of my current plans for UVM, which right now extend only as
> far as breaking the back of the
Le 30/12/2019 à 16:15, Emmanuel Dreyfus a écrit :
> On Sat, Dec 28, 2019 at 02:22:21AM +, Emmanuel Dreyfus wrote:
>>> Regardless of whether it is needed in this specific case, cutting the 2MBs
>>> of zero in the binary is wanted. Unfortunately last I looked at this (two
>>> years ago) there
On Sat, Dec 28, 2019 at 02:22:21AM +, Emmanuel Dreyfus wrote:
> > Regardless of whether it is needed in this specific case, cutting the 2MBs
> > of zero in the binary is wanted. Unfortunately last I looked at this (two
> > years ago) there were some non-obvious consequences, and it needs to be
On Fri, Dec 27, 2019 at 06:24:07PM +0100, Maxime Villard wrote:
> Now that I'm looking at i386 I see you've indeed made the same nonsensical
> changes there, with all the unnecessary garbage in the code.
Here I assume you refer to the starting at efi_multiboot2_loader, since
most of the other
On Fri, Dec 27, 2019 at 06:24:07PM +0100, Maxime Villard wrote:
> .text : AT (ADDR(.text) & 0x0fff)
> {
> + *(.multiboot)
> +
> . = ALIGN(__PAGE_SIZE);
> __text_user_start = . ;
> ...
>
> This guarantees that the structure is
Le 27/12/2019 à 17:45, Emmanuel Dreyfus a écrit :
> On Fri, Dec 27, 2019 at 09:02:17AM +0100, Maxime Villard wrote:
>> Please stop with the nonsense... In this patch you are making the multiboot
>> header executable, and putting it in a section shared with userland under
>> SVS. Neither should be
On Fri, Dec 27, 2019 at 09:02:17AM +0100, Maxime Villard wrote:
> Please stop with the nonsense... In this patch you are making the multiboot
> header executable, and putting it in a section shared with userland under
> SVS. Neither should be required; more than that, both are absolutely _not_
>
Hi,
Your patch works fine for my laptop too.
Thank you.
Masanobu SAITOH writes:
> On 2019/12/27 1:55, Emmanuel Dreyfus wrote:
>> On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
> After this change, amd64 kernel does not boot on my HP Spectre x360
> 13-inch ae019TU
Le 26/12/2019 à 17:55, Emmanuel Dreyfus a écrit :
> On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
After this change, amd64 kernel does not boot on my HP Spectre x360
13-inch ae019TU laptop with pure UEFI boot mode.
>> I have a UEFI boot machine and it also doesn't
On 2019/12/27 1:55, Emmanuel Dreyfus wrote:
> On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
After this change, amd64 kernel does not boot on my HP Spectre x360
13-inch ae019TU laptop with pure UEFI boot mode.
>> I have a UEFI boot machine and it also doesn't boot
801 - 900 of 5581 matches
Mail list logo
