Re: CVS commit: src/sys/arch

2018-12-11 Thread Tom Ivar Helbekkmo
Tom Ivar Helbekkmo  writes:

> This one goes black:
>
> nouveau0 at pci1 dev 0 function 0: vendor 10de product 06eb (rev. 0xa1)
> drm kern info: nouveau  [  DEVICE][nouveau0] BOOT0  : 0x298580a2
> drm kern info: nouveau  [  DEVICE][nouveau0] Chipset: G98 (NV98)
> drm kern info: nouveau  [  DEVICE][nouveau0] Family : NV50

...but works with maya's "big hammer" - albeit without acceleration, so
I still can't use mplayer to watch videos on it.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay


Re: CVS commit: src/sys/arch

2018-12-11 Thread maya
I got it working well now :-) thanks.
it was MSI.
I should see how to disable it for just nouveau.


Re: CVS commit: src/sys/arch

2018-12-11 Thread Robert Swindells


m...@netbsd.org wrote:
>On Tue, Dec 11, 2018 at 11:34:30AM -0600, Greg Oster wrote:
>> On Tue, 11 Dec 2018 15:23:01 +
>> Robert Swindells  wrote:
>> 
>> > "Maya Rashish"  wrote:
>> > >Module Name:src
>> > >Committed By:   maya
>> > >Date:   Tue Dec 11 11:00:18 UTC 2018
>> > >
>> > >Modified Files:
>> > >src/sys/arch/amd64/conf: GENERIC
>> > >src/sys/arch/i386/conf: GENERIC
>> > >
>> > >Log Message:
>> > >disable nouveau. it hasn't been functional since the import of new
>> > >drmkms code.  
>> > 
>> > Nouveau works fine for me.
>> > 
>> > Can we at least get some more data on which GPUs don't work ?
>> 
>> drm kern info: nouveau  [  DEVICE][nouveau0] Chipset: GF108 (NVC1)
>> drm kern info: nouveau  [  DEVICE][nouveau0] Family : NVC0
>> 
>> Works great with 8.0.  Gets into a funky loop of some sort:

[snip]

>> with -current, and fails to display anything more than a black screen.
>> 
>> Additional details happily provided on request.

>My machine does this too, it does however manage to boot and I've even
>see it startx.  The monitor won't display anything though.

I see similar messages on my working system.

>Monitor is connected with DP and then a VGA adapter.

What do you see in dmesg.boot when it is trying to attach a suitable
output device ?

The equivalent stage for me is this:

...
kern info: nouveau: DRM:0039:0039: init children...
kern info: nouveau: DRM:0039:0039: init completed in 378us
nouveau0: info: DRM: MM: using M2MF for buffer copies
nouveau0: info: DRM: Calling LVDS script 6:
nouveau0: info: DRM: 0xD0D8: Parsing digital output script table
nouveau0: info: DRM: Setting dpms mode 3 on TV encoder (output 2)
nouveaufb0 at nouveau0
nouveaufb0: framebuffer at 0x800045c0d000, size 1280x800, depth 16, stride 
2560
nouveau0: info: DRM: Calling LVDS script 2:
nouveau0: info: DRM: 0xD13A: Parsing digital output script table
nouveau0: info: DRM: Calling LVDS script 5:
nouveau0: info: DRM: 0xD0B4: Parsing digital output script table
wsdisplay0 at nouveaufb0 kbdmux 1: console (default, vt100 emulation), using 
wskbd0


Re: CVS commit: src/sys/arch

2018-12-11 Thread Tom Ivar Helbekkmo
Robert Swindells  writes:

> Can we at least get some more data on which GPUs don't work ?

This one goes black:

nouveau0 at pci1 dev 0 function 0: vendor 10de product 06eb (rev. 0xa1)
drm kern info: nouveau  [  DEVICE][nouveau0] BOOT0  : 0x298580a2
drm kern info: nouveau  [  DEVICE][nouveau0] Chipset: G98 (NV98)
drm kern info: nouveau  [  DEVICE][nouveau0] Family : NV50

...as does this one:

nouveau0 at pci1 dev 0 function 0: vendor 10de product 1200 (rev. 0xa1)
drm kern info: nouveau  [  DEVICE][nouveau0] BOOT0  : 0x0ce000a1
drm kern info: nouveau  [  DEVICE][nouveau0] Chipset: GF114 (NVCE)
drm kern info: nouveau  [  DEVICE][nouveau0] Family : NVC0

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay


Re: CVS commit: src/sys/arch

2018-12-11 Thread maya
This is a pretty big hammer, but it works.

Index: amd64/include/types.h
===
RCS file: /cvsroot/src/sys/arch/amd64/include/types.h,v
retrieving revision 1.58
diff -u -r1.58 types.h
--- amd64/include/types.h   15 Nov 2018 04:59:02 -  1.58
+++ amd64/include/types.h   11 Dec 2018 18:41:02 -
@@ -108,7 +108,6 @@
 #define__HAVE_DIRECT_MAP 1
 #endif
 #if !defined(NO_PCI_MSI_MSIX)
-#define__HAVE_PCI_MSI_MSIX
 #endif
 #endif
 #endif



Re: CVS commit: src/sys/arch

2018-12-11 Thread Robert Swindells


m...@netbsd.org wrote:
>On Tue, Dec 11, 2018 at 03:23:01PM +, Robert Swindells wrote:
>> 
>> "Maya Rashish"  wrote:
>> >Module Name:src
>> >Committed By:   maya
>> >Date:   Tue Dec 11 11:00:18 UTC 2018
>> >
>> >Modified Files:
>> >src/sys/arch/amd64/conf: GENERIC
>> >src/sys/arch/i386/conf: GENERIC
>> >
>> >Log Message:
>> >disable nouveau. it hasn't been functional since the import of new drmkms
>> >code.
>> 
>> Nouveau works fine for me.
>> 
>> Can we at least get some more data on which GPUs don't work ?
>
>You're not even giving the data yourself

I don't own any machines that it doesn't work on.


Re: CVS commit: src/sys/arch

2018-12-11 Thread maya
On Tue, Dec 11, 2018 at 11:34:30AM -0600, Greg Oster wrote:
> On Tue, 11 Dec 2018 15:23:01 +
> Robert Swindells  wrote:
> 
> > "Maya Rashish"  wrote:
> > >Module Name:src
> > >Committed By:   maya
> > >Date:   Tue Dec 11 11:00:18 UTC 2018
> > >
> > >Modified Files:
> > >src/sys/arch/amd64/conf: GENERIC
> > >src/sys/arch/i386/conf: GENERIC
> > >
> > >Log Message:
> > >disable nouveau. it hasn't been functional since the import of new
> > >drmkms code.  
> > 
> > Nouveau works fine for me.
> > 
> > Can we at least get some more data on which GPUs don't work ?
> 
> drm kern info: nouveau  [  DEVICE][nouveau0] Chipset: GF108 (NVC1)
> drm kern info: nouveau  [  DEVICE][nouveau0] Family : NVC0
> 
> Works great with 8.0.  Gets into a funky loop of some sort:
> 
> [  69.9188746] kern info: nouveau: user:001f906e:fff9: fini
> children... 
> [  69.9188746] kern info: nouveau: user:001f906e:fff9:
> fini running... 
> [  69.9188746] kern info: nouveau: user::: fini
> children... 
> [  69.9188746] kern info: nouveau: user::: fini
> running... 
> [  69.9188746] kern info: nouveau: user::: fini
> completed in 31us 
> [  69.9188746] kern info: nouveau: user:001f906e:fff9: fini
> completed in 130us 
> [  69.9188746] kern info: nouveau: user:001f906e:fff9: destroy
> children... 
> [  69.9188746] kern info: nouveau: user:001f906e:fff9: destroy
> running...
> 
> with -current, and fails to display anything more than a black screen.
> 
> Additional details happily provided on request.

My machine does this too, it does however manage to boot and I've even
see it startx.  The monitor won't display anything though.
Monitor is connected with DP and then a VGA adapter.
Martin pointed out his machine runs headless so it's not yet certain
GF104 works.


Re: CVS commit: src/sys/arch

2018-12-11 Thread Greg Oster
On Tue, 11 Dec 2018 15:23:01 +
Robert Swindells  wrote:

> "Maya Rashish"  wrote:
> >Module Name:src
> >Committed By:   maya
> >Date:   Tue Dec 11 11:00:18 UTC 2018
> >
> >Modified Files:
> >src/sys/arch/amd64/conf: GENERIC
> >src/sys/arch/i386/conf: GENERIC
> >
> >Log Message:
> >disable nouveau. it hasn't been functional since the import of new
> >drmkms code.  
> 
> Nouveau works fine for me.
> 
> Can we at least get some more data on which GPUs don't work ?

drm kern info: nouveau  [  DEVICE][nouveau0] Chipset: GF108 (NVC1)
drm kern info: nouveau  [  DEVICE][nouveau0] Family : NVC0

Works great with 8.0.  Gets into a funky loop of some sort:

[  69.9188746] kern info: nouveau: user:001f906e:fff9: fini
children... 
[  69.9188746] kern info: nouveau: user:001f906e:fff9:
fini running... 
[  69.9188746] kern info: nouveau: user::: fini
children... 
[  69.9188746] kern info: nouveau: user::: fini
running... 
[  69.9188746] kern info: nouveau: user::: fini
completed in 31us 
[  69.9188746] kern info: nouveau: user:001f906e:fff9: fini
completed in 130us 
[  69.9188746] kern info: nouveau: user:001f906e:fff9: destroy
children... 
[  69.9188746] kern info: nouveau: user:001f906e:fff9: destroy
running...

with -current, and fails to display anything more than a black screen.

Additional details happily provided on request.

Later...

Greg Oster


Re: CVS commit: src/sys/arch

2018-12-11 Thread Robert Swindells


m...@netbsd.org wrote:
>On Tue, Dec 11, 2018 at 05:36:56PM +0100, Martin Husemann wrote:
>> On Tue, Dec 11, 2018 at 03:23:01PM +, Robert Swindells wrote:
>> > Nouveau works fine for me.
>> 
>> Seems to work fine for me too with -current:
>> 
>> pci1: i/o space, memory space enabled, rd/line, wr/inv ok
>> pci1: info: NVIDIA GF104 (0c4100a1)
>> nouveau0 at pci1 dev 0 function 0: vendor 10de product 0e22 (rev. 0xa1)
>> nouveau0: info: NVIDIA GF104 (0c4100a1)
>
>Are you sure it's not an optimus setup where nvidia failing to function
>would still look fine?

Mine isn't an optimus setup.

It is a fairly old laptop with an AMD CPU, so there isn't another
graphics controller to fall back to.

cpu0 at mainbus0 apid 0
cpu0: AMD Turion(tm) 64 Mobile Technology MT-30, id 0x20f42

pci1: i/o space, memory space enabled, rd/line, wr/inv ok
pci1: info: NVIDIA NV44 (044700a2)
nouveau0 at pci1 dev 0 function 0: vendor 10de product 0167 (rev. 0xa1)
nouveau0: info: NVIDIA NV44 (044700a2)

I did have to make one local change to the nouveau sources to get it to
work, Taylor does know about it. I added calls to printf until I could
see where things were going wrong.


Re: CVS commit: src/sys/arch

2018-12-11 Thread maya
On Tue, Dec 11, 2018 at 05:36:56PM +0100, Martin Husemann wrote:
> On Tue, Dec 11, 2018 at 03:23:01PM +, Robert Swindells wrote:
> > Nouveau works fine for me.
> 
> Seems to work fine for me too with -current:
> 
> pci1: i/o space, memory space enabled, rd/line, wr/inv ok
> pci1: info: NVIDIA GF104 (0c4100a1)
> nouveau0 at pci1 dev 0 function 0: vendor 10de product 0e22 (rev. 0xa1)
> nouveau0: info: NVIDIA GF104 (0c4100a1)

Are you sure it's not an optimus setup where nvidia failing to function
would still look fine?

I have a single GTX 770, no other graphics card.


Re: CVS commit: src/sys/arch

2018-12-11 Thread Martin Husemann
On Tue, Dec 11, 2018 at 03:23:01PM +, Robert Swindells wrote:
> Nouveau works fine for me.

Seems to work fine for me too with -current:

pci1: i/o space, memory space enabled, rd/line, wr/inv ok
pci1: info: NVIDIA GF104 (0c4100a1)
nouveau0 at pci1 dev 0 function 0: vendor 10de product 0e22 (rev. 0xa1)
nouveau0: info: NVIDIA GF104 (0c4100a1)


Martin


Re: CVS commit: src/sys/arch

2018-12-11 Thread Robert Swindells


"Maya Rashish"  wrote:
>Module Name:src
>Committed By:   maya
>Date:   Tue Dec 11 11:00:18 UTC 2018
>
>Modified Files:
>src/sys/arch/amd64/conf: GENERIC
>src/sys/arch/i386/conf: GENERIC
>
>Log Message:
>disable nouveau. it hasn't been functional since the import of new drmkms
>code.

Nouveau works fine for me.

Can we at least get some more data on which GPUs don't work ?


Re: CVS commit: src/sys/arch

2018-12-11 Thread maya
On Tue, Dec 11, 2018 at 03:23:01PM +, Robert Swindells wrote:
> 
> "Maya Rashish"  wrote:
> >Module Name:src
> >Committed By:   maya
> >Date:   Tue Dec 11 11:00:18 UTC 2018
> >
> >Modified Files:
> >src/sys/arch/amd64/conf: GENERIC
> >src/sys/arch/i386/conf: GENERIC
> >
> >Log Message:
> >disable nouveau. it hasn't been functional since the import of new drmkms
> >code.
> 
> Nouveau works fine for me.
> 
> Can we at least get some more data on which GPUs don't work ?

You're not even giving the data yourself


Re: CVS commit: src/sys/arch/x86

2018-12-07 Thread Maxime Villard

Le 07/12/2018 à 17:29, Jaromír Doleček a écrit :

Maybe I missed something earlier - does KASLR being enabled by default
mean that x86 now doesn't any more use the direct map to copy memory
pages?


No. The direct map is still there and still used, the only thing is that
its location is randomized.

You are probably confusing with KASAN, which indeed doesn't have a
direct map, for specific reasons.

In all cases, GENERIC stays with a direct map.


Re: CVS commit: src/sys/arch/x86

2018-12-07 Thread Jaromír Doleček
Maybe I missed something earlier - does KASLR being enabled by default
mean that x86 now doesn't any more use the direct map to copy memory
pages?

Jaromir
Le ven. 7 déc. 2018 à 16:47, Maxime Villard  a écrit :
>
> Module Name:src
> Committed By:   maxv
> Date:   Fri Dec  7 15:47:11 UTC 2018
>
> Modified Files:
> src/sys/arch/x86/conf: files.x86
> src/sys/arch/x86/x86: pmap.c
>
> Log Message:
> Add an option to have a static kernel memory layout. This option is
> disabled by default - that is to say, KASLR remains enabled by default.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.103 -r1.104 src/sys/arch/x86/conf/files.x86
> cvs rdiff -u -r1.312 -r1.313 src/sys/arch/x86/x86/pmap.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>


re: CVS commit: src/sys/arch/x86/x86

2018-12-04 Thread matthew green
Joerg Sonnenberger writes:
> On Tue, Dec 04, 2018 at 07:27:22PM +, Cherry G. Mathew wrote:
> > Module Name:src
> > Committed By:   cherry
> > Date:   Tue Dec  4 19:27:22 UTC 2018
> > 
> > Modified Files:
> > src/sys/arch/x86/x86: cpu.c intr.c
> > 
> > Log Message:
> > Hypothetically speaking, if one were to want to compile a
> > 
> > 'no options MULTIPROCESSOR'
> > 
> > kernel, these files may trip up the build.
> > 
> > Fix them by moving around the #defines as originally intended.
> 
> Well, MULTIPROCESSOR is *not* meant to be optional on x86.

true, but it's always been very simple to keep working.  i've
commited simple fixes like this maybe twice before..


.mrg.


Re: CVS commit: src/sys/arch/x86/x86

2018-12-04 Thread Joerg Sonnenberger
On Tue, Dec 04, 2018 at 07:27:22PM +, Cherry G. Mathew wrote:
> Module Name:  src
> Committed By: cherry
> Date: Tue Dec  4 19:27:22 UTC 2018
> 
> Modified Files:
>   src/sys/arch/x86/x86: cpu.c intr.c
> 
> Log Message:
> Hypothetically speaking, if one were to want to compile a
> 
> 'no options MULTIPROCESSOR'
> 
> kernel, these files may trip up the build.
> 
> Fix them by moving around the #defines as originally intended.

Well, MULTIPROCESSOR is *not* meant to be optional on x86.

Joerg


Re: CVS commit: src/sys/arch/arm/acpi

2018-11-27 Thread Masanobu SAITOH

On 2018/11/28 12:11, Masanobu SAITOH wrote:

Hi.

On 2018/11/28 3:29, Jared D. McNeill wrote:

Module Name:    src
Committed By:    jmcneill
Date:    Tue Nov 27 18:29:17 UTC 2018

Modified Files:
src/sys/arch/arm/acpi: acpi_platform.c

Log Message:
Add support for SPCR 16550 and 16450 interface types


To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/sys/arch/arm/acpi/acpi_platform.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


  SPCR's interface type is the same as DBG's PortType.


s/DBG/DBG2/


src/sys/external/bsd/acpica/dist/include/actbl1.h defines DBG's
port type, so it would be good to use actbl1.h's definitions and
remove duplicated definitions in acpi_platform.c. It also seems
that ACPI_DBG2_ARM_DCC (0x000f) is not treated in acpi_platform.c

See also:
 
https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table
 
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/acpitools/acpidump/acpi.c.diff?r1=1.33=1.34=h




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)


Re: CVS commit: src/sys/arch/arm/acpi

2018-11-27 Thread Masanobu SAITOH

Hi.

On 2018/11/28 3:29, Jared D. McNeill wrote:

Module Name:src
Committed By:   jmcneill
Date:   Tue Nov 27 18:29:17 UTC 2018

Modified Files:
src/sys/arch/arm/acpi: acpi_platform.c

Log Message:
Add support for SPCR 16550 and 16450 interface types


To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/sys/arch/arm/acpi/acpi_platform.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


 SPCR's interface type is the same as DBG's PortType.
src/sys/external/bsd/acpica/dist/include/actbl1.h defines DBG's
port type, so it would be good to use actbl1.h's definitions and
remove duplicated definitions in acpi_platform.c. It also seems
that ACPI_DBG2_ARM_DCC (0x000f) is not treated in acpi_platform.c

See also:

https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table

http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/acpitools/acpidump/acpi.c.diff?r1=1.33=1.34=h

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)


re: CVS commit: src/sys/arch/aarch64/include

2018-11-21 Thread matthew green
"Jaromir Dolecek" writes:
> Module Name:  src
> Committed By: jdolecek
> Date: Tue Nov 20 20:53:50 UTC 2018
> 
> Modified Files:
>   src/sys/arch/aarch64/include: pmap.h
> 
> Log Message:
> Implement PMAP_DIRECT / pmap_direct_process() in support of experimental
> UBC optimizations (compile-tested only for now)
> 
> PR kern/53124

can we please not commit *untested* pmap changes.  espcially
when this port is actively maintained and you could very
easily ask someone to test this specific change.

compile testing kernel changes is really bad.  compile testing
memory management code is pretty much forbidden.


.mrg.


Re: CVS commit: src/sys/arch

2018-11-19 Thread Martin Husemann
On Mon, Nov 19, 2018 at 10:45:32PM +0700, Robert Elz wrote:
>   | This also applies to the original commit which broke the build ;-)
> 
> In fairness, as it was, it did work on amd64, just not on i386.   Asking
> developers to test build every possible port just in case would be a
> bit much I think.

If the list of possibly affected ports is small, I don't think it is asking
too much. Otherwise at least keep an eye on the auto-build results and fix
quickly...

Martin


Re: CVS commit: src/sys/arch

2018-11-19 Thread Robert Elz
Date:Mon, 19 Nov 2018 14:46:53 +0100
From:Martin Husemann 
Message-ID:  <20181119134653.ga23...@mail.duskware.de>

  | > Let us stop committing untested codes in order to just fix build.

Yes, sorry about that, I should have tested that one.

  | This also applies to the original commit which broke the build ;-)

In fairness, as it was, it did work on amd64, just not on i386.   Asking
developers to test build every possible port just in case would be a
bit much I think.

kre



Re: CVS commit: src/sys/arch

2018-11-19 Thread Rin Okuyama

On 2018/11/19 22:46, Martin Husemann wrote:

On Mon, Nov 19, 2018 at 10:40:38PM +0900, Rin Okuyama wrote:

-   ci->ci_xen_clockf_usermode = USERMODE(regs->if_tf.tf_cs);
-   ci->ci_xen_clockf_pc = regs->if_tf.tf_rip;
+   ci->ci_xen_clockf_usermode = USERMODE(regs->_INTRFRAME_CS);
+   ci->ci_xen_clockf_pc = regs->_INTRFRAME_IP;


Let us stop committing untested codes in order to just fix build.


This also applies to the original commit which broke the build ;-)


Exactly. It should be responsibility of the original commiter to
fix the problem. Let's notice s/he before "fixing" it.

Thanks,
rin


Re: CVS commit: src/sys/arch

2018-11-19 Thread Martin Husemann
On Mon, Nov 19, 2018 at 10:40:38PM +0900, Rin Okuyama wrote:
> > -   ci->ci_xen_clockf_usermode = USERMODE(regs->if_tf.tf_cs);
> > -   ci->ci_xen_clockf_pc = regs->if_tf.tf_rip;
> > +   ci->ci_xen_clockf_usermode = USERMODE(regs->_INTRFRAME_CS);
> > +   ci->ci_xen_clockf_pc = regs->_INTRFRAME_IP;
> 
> Let us stop committing untested codes in order to just fix build.

This also applies to the original commit which broke the build ;-)

Martin


Re: CVS commit: src/sys/arch

2018-11-19 Thread Rin Okuyama

On 2018/11/19 19:05, Robert Elz wrote:

Module Name:src
Committed By:   kre
Date:   Mon Nov 19 10:05:09 UTC 2018

Modified Files:
src/sys/arch/amd64/include: frame.h
src/sys/arch/i386/include: frame.h
src/sys/arch/xen/x86: hypervisor_machdep.c

Log Message:
Hide differences between i386 and amd64 interrupt frames so XEN does
not need to know there is one.   Hopefully unbreak i386 build.


_INTRFRAME_IP and _CS are reversed for amd64:


Index: src/sys/arch/amd64/include/frame.h
diff -u src/sys/arch/amd64/include/frame.h:1.18 
src/sys/arch/amd64/include/frame.h:1.19
--- src/sys/arch/amd64/include/frame.h:1.18 Wed Jun 14 00:40:05 2017
+++ src/sys/arch/amd64/include/frame.h  Mon Nov 19 10:05:09 2018

...

+#ifdef XEN
+/*
+ * Need arch independany way to access IP and CS from intrframe
+ */
+#define_INTRFRAME_IP   if_tf.tf_cs
+#define_INTRFRAME_CS   if_tf.tf_rip
+#endif



Index: src/sys/arch/xen/x86/hypervisor_machdep.c
diff -u src/sys/arch/xen/x86/hypervisor_machdep.c:1.32 
src/sys/arch/xen/x86/hypervisor_machdep.c:1.33
--- src/sys/arch/xen/x86/hypervisor_machdep.c:1.32  Sun Nov 18 23:50:48 2018
+++ src/sys/arch/xen/x86/hypervisor_machdep.c   Mon Nov 19 10:05:09 2018

...

-   ci->ci_xen_clockf_usermode = USERMODE(regs->if_tf.tf_cs);
-   ci->ci_xen_clockf_pc = regs->if_tf.tf_rip;
+   ci->ci_xen_clockf_usermode = USERMODE(regs->_INTRFRAME_CS);
+   ci->ci_xen_clockf_pc = regs->_INTRFRAME_IP;


Let us stop committing untested codes in order to just fix build.
Compile-time errors are much better than bugs not detectable by
compilers.

Thanks,
rin


Re: CVS commit: src/sys/arch/macppc/stand/ofwboot

2018-11-16 Thread Izumi Tsutsui
> Module Name:  src
> Committed By: tsutsui
> Date: Fri Nov 16 14:58:54 UTC 2018
> 
> Modified Files:
>   src/sys/arch/macppc/stand/ofwboot: ofdev.c version
> 
> Log Message:
> Fix boot failure from installation floppies.  PR port-macppc/53103

Ugh, this should be PR port-macppc/53727

---
Izumi Tsutsui


Re: CVS commit: src/sys/arch/evbarm/conf

2018-11-14 Thread Greg Troxel
matthew green  writes:

> Nick Hudson writes:
>> On 13/11/2018 08:21, matthew green wrote:
>> >> Modified Files:
>> >>   src/sys/arch/evbarm/conf: std.generic64
>> >>
>> >> Log Message:
>> >> turn on MODULAR by default on aarch64
>> > 
>> > optional things should not be in "std.foo".  that should be
>> > things that are necessary for basic function.  stuff that
>> > a user would never want to remove.
>> 
>> I thought core wanted MODULAR everywhere? If so, it's in the right 
>> place, I think.
>
> it's still "optional", even if we want it default everywhere.
> std.foo is for things that are not optional, that all users
> should have, no matter what choices they have.
>
> i should never have to look in std.foo to decide if an option
> should be removed for my config or not.

Agreed on both points.


re: CVS commit: src/sys/arch/evbarm/conf

2018-11-13 Thread matthew green
Nick Hudson writes:
> On 13/11/2018 08:21, matthew green wrote:
> >> Modified Files:
> >>src/sys/arch/evbarm/conf: std.generic64
> >>
> >> Log Message:
> >> turn on MODULAR by default on aarch64
> > 
> > optional things should not be in "std.foo".  that should be
> > things that are necessary for basic function.  stuff that
> > a user would never want to remove.
> 
> I thought core wanted MODULAR everywhere? If so, it's in the right 
> place, I think.

it's still "optional", even if we want it default everywhere.
std.foo is for things that are not optional, that all users
should have, no matter what choices they have.

i should never have to look in std.foo to decide if an option
should be removed for my config or not.

thanks.


.mrg.


Re: CVS commit: src/sys/arch/evbarm/conf

2018-11-13 Thread Nick Hudson

On 13/11/2018 08:21, matthew green wrote:

Modified Files:
src/sys/arch/evbarm/conf: std.generic64

Log Message:
turn on MODULAR by default on aarch64


optional things should not be in "std.foo".  that should be
things that are necessary for basic function.  stuff that
a user would never want to remove.


I thought core wanted MODULAR everywhere? If so, it's in the right 
place, I think.



this belongs in GENERIC64.  the same problem is there for
the entry in std.generic that already exists, but maybe that
one should stay until the fdtisation is completed on arm32,
(i'm assuming std.generic is included multiple places, i
didn't actually check.)


Nope just by GENERIC.



thanks.


.mrg.



Nick


re: CVS commit: src/sys/arch/evbarm/conf

2018-11-13 Thread matthew green
> Modified Files:
>   src/sys/arch/evbarm/conf: std.generic64
> 
> Log Message:
> turn on MODULAR by default on aarch64

optional things should not be in "std.foo".  that should be
things that are necessary for basic function.  stuff that
a user would never want to remove.

this belongs in GENERIC64.  the same problem is there for
the entry in std.generic that already exists, but maybe that
one should stay until the fdtisation is completed on arm32,
(i'm assuming std.generic is included multiple places, i
didn't actually check.)

thanks.


.mrg.


re: CVS commit: src/sys/arch/aarch64/aarch64

2018-10-31 Thread matthew green
"Ryo Shimizu" writes:
> Module Name:  src
> Committed By: ryo
> Date: Wed Oct 31 06:36:19 UTC 2018
> 
> Modified Files:
>   src/sys/arch/aarch64/aarch64: pmap.c
> 
> Log Message:
> invalidate icache correctly.
> l3pte_executable() should be used for only valid pte.

thanks!  this makes nfsroot work for me.


.mrg.


Re: CVS commit: src/sys/arch/arm/altera

2018-10-28 Thread Aymeric Vincent
Nick Hudson  writes:

> Does it work now?

Yes, it does.

Regards,
 Aymeric


Re: CVS commit: src/sys/arch/arm/altera

2018-10-28 Thread Nick Hudson

On 28/10/2018 14:58, Aymeric Vincent wrote:

Module Name:src
Committed By:   aymeric
Date:   Sun Oct 28 14:58:20 UTC 2018

Modified Files:
src/sys/arch/arm/altera: cycv_platform.c

Log Message:
Use virtual addresses where virtual addresses are expected.


Thanks

Does it work now?

Nick


Re: CVS commit: src/sys/arch/arm/broadcom

2018-10-21 Thread Jared McNeill

On Sun, 21 Oct 2018, Nick Hudson wrote:

Can't see enable-method as property of cpus node in the standard bindings. 
Surely, bcm2837.dtsi is using non-standard bindings


This is valid according to the devicetree spec:

  Properties that have identical values across cpu nodes may be placed in
  the /cpus node instead. A client program must first examine a specific cpu
  node, but if an expected property is not found then it should look at the
  parent /cpus node. This results in a less verbose representation of
  properties which are identical across all CPUs.



Re: CVS commit: src/sys/arch/arm/broadcom

2018-10-21 Thread Nick Hudson

On 20/10/2018 11:24, Jared McNeill wrote:

On Sat, 20 Oct 2018, Ryo Shimizu wrote:


I think the dts should be fixed rather than #ifdef __arm__


I agree that we need to change dts to eliminate 32bit enable method from
the dtb for 64bit. However, it is also strange that enable-method code
for 32bit ARM remains in the 64bit binary as well.


I don't think the dts should be changed. This lets use share a dtb 
between 32- and 64-bit kernels. The brcm,bcm2836-smp enable-method is 
documented as being supported only in 32-bit mode:


https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/cpus.txt



Can't see enable-method as property of cpus node in the standard 
bindings.  Surely, bcm2837.dtsi is using non-standard bindings


http://src.illumos.org/source/xref/netbsd-src/sys/external/gpl2/dts/dist/arch/arm/boot/dts/bcm2837.dtsi#30

30  cpus: cpus {
31  #address-cells = <1>;
32  #size-cells = <0>;
33  enable-method = "brcm,bcm2836-smp"; // for ARM 32-bit

Nick


Re: CVS commit: src/sys/arch/arm/broadcom

2018-10-20 Thread Jared McNeill

On Sat, 20 Oct 2018, Ryo Shimizu wrote:


I think the dts should be fixed rather than #ifdef __arm__


I agree that we need to change dts to eliminate 32bit enable method from
the dtb for 64bit. However, it is also strange that enable-method code
for 32bit ARM remains in the 64bit binary as well.


I don't think the dts should be changed. This lets use share a dtb between 
32- and 64-bit kernels. The brcm,bcm2836-smp enable-method is documented 
as being supported only in 32-bit mode:


https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/cpus.txt


Re: CVS commit: src/sys/arch/arm/broadcom

2018-10-20 Thread Ryo Shimizu


>On 20/10/2018 06:53, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Sat Oct 20 05:53:22 UTC 2018
>> 
>> Modified Files:
>>  src/sys/arch/arm/broadcom: bcm283x_platform.c
>> 
>> Log Message:
>> - fix AP spinup on bcm283x
>> - "brcm,bcm2836-smp" is a enable-method for only 32bit bcm2836.
>
>
>I think the dts should be fixed rather than #ifdef __arm__

I agree that we need to change dts to eliminate 32bit enable method from
the dtb for 64bit. However, it is also strange that enable-method code
for 32bit ARM remains in the 64bit binary as well.

-- 
ryo shimizu


Re: CVS commit: src/sys/arch/arm/broadcom

2018-10-20 Thread Nick Hudson




On 20/10/2018 08:19, Ryo Shimizu wrote:

On 20/10/2018 06:53, Ryo Shimizu wrote:

Module Name:src
Committed By:   ryo
Date:   Sat Oct 20 05:53:22 UTC 2018

Modified Files:
src/sys/arch/arm/broadcom: bcm283x_platform.c

Log Message:
- fix AP spinup on bcm283x
- "brcm,bcm2836-smp" is a enable-method for only 32bit bcm2836.


I think the dts should be fixed rather than #ifdef __arm__

I agree that we need to change dts to eliminate 32bit enable method from
the dtb for 64bit.


Cool


  However, it is also strange that enable-method code
for 32bit ARM remains in the 64bit binary as well.

Lots more code in GENERIC64 than this little snippet that won't ever get 
used, e.g. SOC_{RK*,TEGRA,SUN*,etc} on RPI3


Nick


Re: CVS commit: src/sys/arch/arm/broadcom

2018-10-20 Thread Nick Hudson

On 20/10/2018 06:53, Ryo Shimizu wrote:

Module Name:src
Committed By:   ryo
Date:   Sat Oct 20 05:53:22 UTC 2018

Modified Files:
src/sys/arch/arm/broadcom: bcm283x_platform.c

Log Message:
- fix AP spinup on bcm283x
- "brcm,bcm2836-smp" is a enable-method for only 32bit bcm2836.



I think the dts should be fixed rather than #ifdef __arm__

Thanks,
Nick


Re: CVS commit: src/sys/arch/arm/rockchip

2018-10-20 Thread Nick Hudson

On 20/10/2018 06:38, Ryo Shimizu wrote:

Module Name:src
Committed By:   ryo
Date:   Sat Oct 20 05:38:27 UTC 2018

Modified Files:
src/sys/arch/arm/rockchip: rk_platform.c

Log Message:
add missing .ap_mpstart for rk3399

Thanks,
Nick


Re: CVS commit: src/sys/arch

2018-09-19 Thread Aymeric Vincent


Jared McNeill  writes:

> Any chance that you could use sys/dev/fdt/dwcmmc_fdt.c instead of the
> new cycv_dwcmmc.c? It should be fairly generic.

>From reading the code, and to avoid any modification except
compat_data[], I will first have to add support for changing clock rates
to cycv_clkmgr.c, it seems to be required by dwcmmc_fdt.c. Other than
that, you're right, it should work as is. Thanks, it's now on my todo
list.

Regards,
 Aymeric


Re: CVS commit: src/sys/arch

2018-09-19 Thread Jared McNeill

On Wed, 19 Sep 2018, Aymeric Vincent wrote:


Module Name:src
Committed By:   aymeric
Date:   Wed Sep 19 17:31:39 UTC 2018

Added Files:
src/sys/arch/arm/altera: cycv_clkmgr.c cycv_dwcmmc.c cycv_gmac.c
cycv_intr.h cycv_platform.c cycv_reg.h cycv_rstmgr.c cycv_var.h
files.altera
src/sys/arch/arm/dts: socfpga_cyclone5_de0_sockit.dts
src/sys/arch/evbarm/altera: altera_start.S genassym.cf platform.h
src/sys/arch/evbarm/conf: NANOSOC files.altera mk.altera std.altera

Log Message:
Add support for the DE0 NanoSoC board.


Very cool!

Any chance that you could use sys/dev/fdt/dwcmmc_fdt.c instead of the new 
cycv_dwcmmc.c? It should be fairly generic.


Cheers,
Jared


Re: CVS commit: src/sys/arch/evbarm/fdt

2018-09-17 Thread Christos Zoulas
On Sep 17,  8:25am, scole_m...@gmx.com (scole_mail) wrote:
-- Subject: Re: CVS commit: src/sys/arch/evbarm/fdt

| chris...@astron.com (Christos Zoulas) writes:
| >
| > This is why we have __nothing
| >
| 
| Should this be documented in src/share/man/man3/attribute.3 ?
| 
| Wish I had known about this man page earlier...

It is not an attribute per say, and there are other macros that
are not attributes in cdefs.h that are not documented. We should
either add them to this page or create a new one with a more
appropriate name.

christos


Re: CVS commit: src/sys/arch/evbarm/fdt

2018-09-17 Thread scole_mail
chris...@astron.com (Christos Zoulas) writes:
>
> This is why we have __nothing
>

Should this be documented in src/share/man/man3/attribute.3 ?

Wish I had known about this man page earlier...

Thanks


Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-09-17 Thread Ryo Shimizu



>> Module Name: src
>> Committed By:ryo
>> Date:Mon Sep 17 00:15:55 UTC 2018
>> 
>> Modified Files:
>>  src/sys/arch/aarch64/aarch64: pmap.c
>> 
>> Log Message:
>> delete debug printf and KASSERT.
>
>i'm confused by this (moved) comment:
>
>/* pte is readable and writable, but occured fault? probably copy(9) */
>
>this sounds sound wrong.  under what conditions will it happen?
>copy(9)'s faults is about handling the userspace not being mapped
>at all, not getting faults while r/w.
>
>is there a stack trace related to the case?

kcopy(9) faults even in unplivedged access.

for test:

/* pte is readable and writable, but occured fault? probably copy(9) */
-   if ((pte & LX_BLKPAG_AF) && ((pte & LX_BLKPAG_AP) == LX_BLKPAG_AP_RW))
+   if ((pte & LX_BLKPAG_AF) && ((pte & LX_BLKPAG_AP) == LX_BLKPAG_AP_RW)) {
+   cpu_Debugger();
goto done;
+   }
 

# cat hello.c 
#include 
int main()
{
 sendmsg(0, (const void *)0xffc00420, 0); /* Any kernel address (RW L3 
page) */
}


# cc hello.c 
# ./a.out 
Stopped in pid 412.1 (a.out) at netbsd:cpu_Debugger+0x4:ret
db{5}> bt
trace tf 0xffc0009fa180
 trapframe 0xffc0009fa180 (304 bytes) 
pc=ffc4f840,   spsr=6005
   esr=f200,far=ffc00420
x0=098610a8, x1=0400
x2=0001, x3=0007
x4=000f5eeb, x5=000ec07a
x6=000f5a1d, x7=0002
x8=ffc000a10490, x9=0050
   x10=000c,x11=003f
   x12=03d11bf48f40,x13=03d11bf48f41
   x14=0040,x15=f446fd23c060
   x16=000200110cf8,x17=f446fd130d5c
   x18=f6440848,x19=ffc00420
   x20=ffc0009fa7c0,x21=ffc0009fa7c0
   x22=f5a1c000,x23=0001
   x24=03e0f5a1df03,x25=
   x26=,x27=000f
   x28=0025, fp=x29=ffc0a3e47b50
lr=x30=ffc556d4, sp=ffc0a3e47b50

fp ffc0a3e47b50 cpu_Debugger() at ffc4f83c netbsd:cpu_Debugger
fp ffc0a3e47b90 data_abort_handler() at ffc51e64 
netbsd:data_abort_handler+0xfc
tf ffc0a3e47c00 el1_trap() at ffc4f730 netbsd:el1_trap
 trapframe 0xffc0a3e47c00 (304 bytes) 
pc=ffc4e964,   spsr=8005
   esr=960f,far=ffc00420
x0=ffc00420, x1=ffc0a3e47df0
x2=0030, x3=ffc0003ec250
x4=0001, x5=
x6=ffb36f88, x7=
x8=, x9=1003
   x10=000c,x11=003f
   x12=03d11bf48f40,x13=03d11bf48f41
   x14=0040,x15=f446fd23c060
   x16=000200110cf8,x17=f446fd130d5c
   x18=f6440848,x19=ffc00420
   x20=ffc0a3e47df0,x21=ffc0a3e47e70
   x22=ffc003e85480,x23=561c
   x24=ffc0a3e47ed0,x25=ffc0a3e47e70
   x26=,x27=
   x28=, fp=x29=ffc0a3e47db0
lr=x30=ffc4e8dc, sp=ffc0a3e47d30

fp ffc0a3e47db0 copyin() at ffc4e964 netbsd:copyin+0xac
fp ffc0a3e47dc0 sys_sendmsg() at ffc0003ec278 netbsd:sys_sendmsg+0x28
fp ffc0a3e47e20 syscall() at ffc50ffc netbsd:syscall+0x174
tf ffc0a3e47ed0 el0_trap() at ffc4f794 netbsd:el0_trap
 trapframe 0xffc0a3e47ed0 (304 bytes) 
pc=f446fd130d60,   spsr=8000
   esr=561c,far=f446fd195c20
x0=, x1=ffc00420
x2=, x3=0001
x4=f446fd225000, x5=ffb374e8
x6=ffb36f88, x7=
x8=, x9=1003
   x10=000c,x11=003f
   x12=03d11bf48f40,x13=03d11bf48f41
   x14=0040,x15=f446fd23c060
   x16=000200110cf8,x17=f446fd130d5c
   x18=f6440848,x19=0001
   x20=0001,x21=ffb37fe0
   x22=000200110da8,x23=000200110b28
   x24=ffb37fe0,x25=f642
   x26=,x27=
   x28=, fp=x29=ffb36f30
lr=x30=000200100944, sp=ffb36f30

db{5}>


-- 
ryo shimizu


re: CVS commit: src/sys/arch/aarch64/aarch64

2018-09-16 Thread matthew green
"Ryo Shimizu" writes:
> Module Name:  src
> Committed By: ryo
> Date: Mon Sep 17 00:15:55 UTC 2018
> 
> Modified Files:
>   src/sys/arch/aarch64/aarch64: pmap.c
> 
> Log Message:
> delete debug printf and KASSERT.

i'm confused by this (moved) comment:

/* pte is readable and writable, but occured fault? probably copy(9) */

this sounds sound wrong.  under what conditions will it happen?
copy(9)'s faults is about handling the userspace not being mapped
at all, not getting faults while r/w.

is there a stack trace related to the case?

thanks.


.mrg.


Re: CVS commit: src/sys/arch/evbarm/fdt

2018-09-16 Thread Christos Zoulas
In article <20180916112430.0f...@cvs.netbsd.org>,
Nick Hudson  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  skrll
>Date:  Sun Sep 16 11:24:29 UTC 2018
>
>Modified Files:
>   src/sys/arch/evbarm/fdt: fdt_machdep.c
>
>Log Message:
>Use do { } while (/* CONSTCOND */ 0) for nop VPRINTF

This is why we have __nothing

christos



Re: CVS commit: src/sys/arch/x86/pci

2018-09-10 Thread Joerg Sonnenberger
On Mon, Sep 10, 2018 at 02:49:23AM +, Cherry G. Mathew wrote:
> Module Name:  src
> Committed By: cherry
> Date: Mon Sep 10 02:49:23 UTC 2018
> 
> Modified Files:
>   src/sys/arch/x86/pci: pci_intr_machdep.c
> 
> Log Message:
> In the NIOAPIC case, we do not need to support "legacy" irqs,
> ie; We don't need to simultaneously pass back the irq in the
> range 0 < irq < 16 (which are sometimes described as "legacy"
> in src

It should be kept in mind that the majority of the NIOAPIC code is
completely wrong by nature as it makes a runtime behavior choice based
on a build-time variable. :(

Joerg


Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-09-10 Thread Rin Okuyama

On 2018/09/10 16:49, Nick Hudson wrote:

For the record this should be fixed now with


sys/arch/aarch64/aarch64/locore.S:1.24
sys/arch/evbarm/fdt/fdt_start.S:1.4


The problem is gone. Thank you for quick fix!

rin


Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-09-10 Thread Nick Hudson

On 10/09/18 04:41, Rin Okuyama wrote:

Hi,

Hi,

After this commit, GENERIC64 does not boot anymore on RPI3B and 3B+.
It successfully boots if locore.S is reverted to rev. 1.21.

Strangely enough, after boot with old locore.S, it can reboot with new
locore.S. However, for initial boot after power-on, only kernel with
old locore.S works fine.


For the record this should be fixed now with


sys/arch/aarch64/aarch64/locore.S:1.24
sys/arch/evbarm/fdt/fdt_start.S:1.4

Nick


Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-09-09 Thread Rin Okuyama

Hi,

Hi,

After this commit, GENERIC64 does not boot anymore on RPI3B and 3B+.
It successfully boots if locore.S is reverted to rev. 1.21.

Strangely enough, after boot with old locore.S, it can reboot with new
locore.S. However, for initial boot after power-on, only kernel with
old locore.S works fine.

I found some typos in register number and comments. However, they are
apparently irrelevant with this problem...

Thanks,
rin

On 2018/09/05 0:50, Nick Hudson wrote:

Module Name:src
Committed By:   skrll
Date:   Tue Sep  4 15:50:25 UTC 2018

Modified Files:
src/sys/arch/aarch64/aarch64: locore.S

Log Message:
Adjust register usage a bit and unbreak DEBUG_MMU as a result.

The change moves to using callee-saved registers more so that any call
into C will have them preserved (if they're used or not).  It's safe
to use stack as it's setup very early for BP/APs.

Discussed with ryo@


To generate a diff of this commit:
cvs rdiff -u -r1.21 -r1.22 src/sys/arch/aarch64/aarch64/locore.S

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


Modified files:

Index: src/sys/arch/aarch64/aarch64/locore.S
diff -u src/sys/arch/aarch64/aarch64/locore.S:1.21 
src/sys/arch/aarch64/aarch64/locore.S:1.22
--- src/sys/arch/aarch64/aarch64/locore.S:1.21  Thu Aug 30 10:38:01 2018
+++ src/sys/arch/aarch64/aarch64/locore.S   Tue Sep  4 15:50:25 2018
@@ -1,4 +1,4 @@
-/* $NetBSD: locore.S,v 1.21 2018/08/30 10:38:01 maxv Exp $ */
+/* $NetBSD: locore.S,v 1.22 2018/09/04 15:50:25 skrll Exp $*/
  
  /*

   * Copyright (c) 2017 Ryo Shimizu 
@@ -35,7 +35,7 @@
  #include 
  #include "assym.h"
  
-RCSID("$NetBSD: locore.S,v 1.21 2018/08/30 10:38:01 maxv Exp $")

+RCSID("$NetBSD: locore.S,v 1.22 2018/09/04 15:50:25 skrll Exp $")
  
  /* #define DEBUG_LOCORE */

  /* #define DEBUG_MMU */
@@ -496,22 +496,25 @@ END(aarch64_mpstart)
   *.ascii"Hello\r\n\0" <- wouldn't return here
   *.align2
   *nop <- return to here
+ *
+ * x0 is preserved despite being caller saved.
   */
  ENTRY_NP(xprint)
-   mov x11, lr
-   mov x12, x0
-   ldrbw0, [x11], #1
+   stp x0, x19, [sp, #-16]!
+
+   mov x19, lr
+   ldrbw0, [x19], #1
cbz w0, 2f
  
  1:

bl  uartputc
-   ldrbw0, [x11], #1
+   ldrbw0, [x19], #1
cbnzw0, 1b
  
  2:

-   add x11, x11, #3
-   bic lr, x11, #3
-   mov x0, x12
+   add x19, x19, #3
+   bic lr, x19, #3
+   ldp x0, x19, [sp], #16
ret
  END(xprint)
  
@@ -527,47 +530,52 @@ ENTRY_NP(uartputs)

ret
  END(uartputs)
  
+/* x0 is preserved despite being caller saved. */

  ENTRY_NP(_print_x0)
stp x0, lr, [sp, #-16]!
-   stp x4, x5, [sp, #-16]!
-   stp x6, x7, [sp, #-16]!
+   stp x20, x21, [sp, #-16]!
  
-	mov	x7, x0		/* number to display */

-   mov x4, #60 /* num of shift */
-   mov x5, #0xf/* mask */
+   mov x21, x0 /* number to display */
+   mov x20, #60/* num of shift */
  1:
-   ror x0, x7, x4
-   and x0, x0, x5
+   ror x0, x21, x20
+   and x0, x0, #0xf
cmp x0, #10
blt 2f
add x0, x0, #('a' - 10 - '0')
  2:add x0, x0, #'0'
bl  uartputc
-   subsx4, x4, #4
+   subsx20, x20, #4
bge 1b
  
-	ldp	x6, x7, [sp], #16

-   ldp x4, x5, [sp], #16
+   ldp x20, x21, [sp], #16
ldp x0, lr, [sp], #16
ret
  END(_print_x0)
  
+/* Preserve x{0,1,2} descpite them being caller saved */

  ENTRY_NP(print_x0)
stp x0, lr, [sp, #-16]!
+   stp x1, x2, [sp, #-16]!
bl  _print_x0
PRINT("\r\n")
+   ldp x1, x2, [sp], #16
ldp x0, lr, [sp], #16
ret
  END(print_x0)
  
+/* Preserve x{0,1,2} descpite them being caller saved */

  ENTRY_NP(printn_x1)
stp x0, lr, [sp, #-16]!
+   stp x1, x2, [sp, #-16]!
mov x0, x1
bl  _print_x0
+   ldp x1, x2, [sp], #16
ldp x0, lr, [sp], #16
ret
  END(printn_x1)
  
+/* Preserve x{0,1,2} descpite them being caller saved */

  ENTRY_NP(print_x2)
stp x0, lr, [sp, #-16]!
mov x0, x2
@@ -772,32 +780,42 @@ END(l0_settable)
   */
  ENTRY_NP(l1_setblocks)
stp x0, lr, [sp, #-16]!
+   stp x19, x20, [sp, #-16]!
+   stp x21, x22, [sp, #-16]!
  
-	and	x2, x2, #L1_ADDR_BITS

-   mov x8, #L1_BLOCK
-   orr x2, x2, x8
-   orr x2, x2, x3
-   mov x8, #(LX_BLKPAG_AF|LX_BLKPAG_AP_RW)
-   orr x2, x2, x8
+   mov x19, x0 /* l1table */
+   mov x22, x4 /* N entries */
+
+   and x21, x2, #L1_ADDR_BITS  /* PA[38:30] */
+   mov x9, #L1_BLOCK

Re: CVS commit: src/sys/arch/mips/mips

2018-09-07 Thread maya
On Fri, Sep 07, 2018 at 09:29:27PM +, Christos Zoulas wrote:
> In article <20180907211445.dbf47f...@cvs.netbsd.org>,
> Michael Lorenz  wrote:
> >-=-=-=-=-=-
> >
> >Module Name: src
> >Committed By:macallan
> >Date:Fri Sep  7 21:14:45 UTC 2018
> >
> >Modified Files:
> > src/sys/arch/mips/mips: locore.S
> >
> >Log Message:
> >re-enable 64bit addressing in n32 kernels
> >Now these work again, at least on my Indy.
> 
> Isn't there only one line different?
> 
> christos
> 

yeah, but I find it more readable this way, too.
sorry for the breakage btw.


Re: CVS commit: src/sys/arch/mips/mips

2018-09-07 Thread Christos Zoulas
In article <20180907211445.dbf47f...@cvs.netbsd.org>,
Michael Lorenz  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  macallan
>Date:  Fri Sep  7 21:14:45 UTC 2018
>
>Modified Files:
>   src/sys/arch/mips/mips: locore.S
>
>Log Message:
>re-enable 64bit addressing in n32 kernels
>Now these work again, at least on my Indy.

Isn't there only one line different?

christos



Re: Merge majors.{arm32,aarch64} into single file (Re: CVS commit: src/sys/arch/evbarm/conf)

2018-08-19 Thread Jason Thorpe


> On Aug 18, 2018, at 5:02 PM, Rin Okuyama  wrote:
> 
> (1) rename majors.arm32 to majors.arm
> (2) remove majors.aarch64
> (3) make everyone include majors.arm
> 
> I will commit if there's no objection.


Correct.  Thank you for making this change.

-- thorpej



Re: Merge majors.{arm32,aarch64} into single file (Re: CVS commit: src/sys/arch/evbarm/conf)

2018-08-19 Thread Christos Zoulas
In article <27877.1534674...@splode.eterna.com.au>,
matthew green   wrote:
>> OK. I will leave it as is for now. Please let me know if you
>> remember the problems.
>
>try, and see? :-)
>
>if nothing else, please make them the same now, and add large
>SHOUTING COMMENTS at the top to keep them in sync.

Yes, please make them the same and whatever break we will fix.

christos



re: Merge majors.{arm32,aarch64} into single file (Re: CVS commit: src/sys/arch/evbarm/conf)

2018-08-19 Thread matthew green
> OK. I will leave it as is for now. Please let me know if you
> remember the problems.

try, and see? :-)

if nothing else, please make them the same now, and add large
SHOUTING COMMENTS at the top to keep them in sync.

thanks.


.mrg.


Re: Merge majors.{arm32,aarch64} into single file (Re: CVS commit: src/sys/arch/evbarm/conf)

2018-08-19 Thread Rin Okuyama

On 2018/08/19 14:33, Nick Hudson wrote:
...

On 19/08/2018 01:02, Rin Okuyama wrote:

It seems harmless to add these devices in majors.aarch64. Therefore,
I propose:

(1) rename majors.arm32 to majors.arm
(2) remove majors.aarch64
(3) make everyone include majors.arm

I will commit if there's no objection.

...

I support the goal of a single majors file for both arm and aarch64, but when I 
tried to do this I found problems in MAKEDEV generation or similar.  I forget 
the exact details.


OK. I will leave it as is for now. Please let me know if you
remember the problems.

Thanks,
rin


Re: Merge majors.{arm32,aarch64} into single file (Re: CVS commit: src/sys/arch/evbarm/conf)

2018-08-18 Thread Nick Hudson

On 19/08/2018 01:02, Rin Okuyama wrote:

Oops, I forgot to CC to source-changes-d@.


[snip]


On 2018/08/19 3:48, matthew green wrote:

can't we make arm and arm64 use the identical majors file?

please!


Diff between majors.arm32 and aarch64 reads


[snip]



- ctcom was added by matt@ back in 2014, but no one uses it now
- vchiq is a device of RPI, not still supported in aarch64 mode
- zynquart is a device of Xilinx Zynq boards, whose 64bit models are
   not currently supported

It seems harmless to add these devices in majors.aarch64. Therefore,
I propose:

(1) rename majors.arm32 to majors.arm
(2) remove majors.aarch64
(3) make everyone include majors.arm

I will commit if there's no objection.

rin



I support the goal of a single majors file for both arm and aarch64, but 
when I tried to do this I found problems in MAKEDEV generation or 
similar.  I forget the exact details.


Nick


Merge majors.{arm32,aarch64} into single file (Re: CVS commit: src/sys/arch/evbarm/conf)

2018-08-18 Thread Rin Okuyama

Oops, I forgot to CC to source-changes-d@.

 Forwarded Message 
Subject: Merge majors.{arm32,aarch64} into single file (Re: CVS commit: 
src/sys/arch/evbarm/conf)
To: matthew green 
Cc: Jared McNeill , Nick Hudson , Ryo 
Shimizu 
From: Rin Okuyama 
Date: Sun, 19 Aug 2018 08:57:53 +0900

On 2018/08/19 3:48, matthew green wrote:

can't we make arm and arm64 use the identical majors file?

please!


Diff between majors.arm32 and aarch64 reads


--- arm/conf/majors.arm32   2015-04-24 08:22:51.0 +0900
+++ aarch64/conf/majors.aarch64 2015-04-24 08:22:51.0 +0900
@@ -1,4 +1,4 @@
-#  $NetBSD: majors.arm32,v 1.37 2015/04/23 23:22:51 pgoyette Exp $
+# $NetBSD: majors.aarch64,v 1.2 2015/04/23 23:22:51 pgoyette Exp $
 #
 # Device majors for arm32
 #
@@ -91,7 +91,6 @@
 device-major   irframe char 95 irframedrv
 device-major   cir char 96 cir
 device-major   radio   char 97 radio
-device-major   ctcom   char 98 ctcom
 device-major   kttcp   char 99 kttcp
 device-major   ixpcom  char 100ixpcom
 device-major   sysmon  char 101sysmon
@@ -105,8 +104,7 @@
 device-major   tslcd   char 108tslcd
 device-major   twe char 109twe
 device-major   nsmbchar 110nsmb
-device-major   vchiq   char 111vchiq
-device-major   zynquartchar 112zynquart
+#device-major  vchiq   char 111vchiq

 # Majors up to 143 are reserved for machine-dependent drivers.
 # New machine-independent driver majors are assigned in


- ctcom was added by matt@ back in 2014, but no one uses it now
- vchiq is a device of RPI, not still supported in aarch64 mode
- zynquart is a device of Xilinx Zynq boards, whose 64bit models are
  not currently supported

It seems harmless to add these devices in majors.aarch64. Therefore,
I propose:

(1) rename majors.arm32 to majors.arm
(2) remove majors.aarch64
(3) make everyone include majors.arm

I will commit if there's no objection.

rin


Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Rin Okuyama

On 2018/08/19 1:11, Jason Thorpe wrote:

On Aug 18, 2018, at 8:49 AM, Rin Okuyama  wrote:

...

"ifdef" statements refer "attrtab", whose entries are not normalized to
lower-case. Therefore, "ifdef arm32" becomes false even if we have
"options ARM32", as I wrote in the previous message:

http://mail-index.netbsd.org/source-changes-d/2018/08/18/msg010463.html

Well, this is a very confusing behavior of config(1). We should normalize
everything to lower-case, provided no one depends on this behavior...


Well, interestingly enough, this works (of course):

# files common to arm32 implementations
filearch/arm/arm32/arm32_machdep.c  arm32
filearch/arm/arm32/bus_dma.carm32
.
.
.

I'm a little confused why "ifdef" would reference the attrtab, though...it 
seems like it should be looking at the options / flags table.  (It's been a long time 
since I was deep in the bowels of config(1), though, so entirely possible that something 
drastic has changed while I wasn't paying attention...)

Well, config(1) has too many tables that have similar roles.
This problem was pointed in usr.bin/config/TODO:

https://nxr.netbsd.org/xref/src/usr.bin/config/TODO#344

Overhaul should be made by someone sometime ;-), although it
must be a tough work that affects too wide a range...

rin


re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread matthew green
can't we make arm and arm64 use the identical majors file? 

please!


.mrg.


Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Jason Thorpe



> On Aug 18, 2018, at 8:49 AM, Rin Okuyama  wrote:
> 
> On 2018/08/19 0:06, Jason Thorpe wrote:
>>> On 2018/08/18 20:08, Rin Okuyama wrote:
 Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31.
>>> 
>>> Sorry, not 1.31 but 1.30.
>> That's because all options are normalized to lower-case.
> 
> Oops, not "if" but "ifdef".
> 
> "ifdef" statements refer "attrtab", whose entries are not normalized to
> lower-case. Therefore, "ifdef arm32" becomes false even if we have
> "options ARM32", as I wrote in the previous message:
> 
> http://mail-index.netbsd.org/source-changes-d/2018/08/18/msg010463.html
> 
> Well, this is a very confusing behavior of config(1). We should normalize
> everything to lower-case, provided no one depends on this behavior...

Well, interestingly enough, this works (of course):

# files common to arm32 implementations
filearch/arm/arm32/arm32_machdep.c  arm32
filearch/arm/arm32/bus_dma.carm32
.
.
.

I'm a little confused why "ifdef" would reference the attrtab, though...it 
seems like it should be looking at the options / flags table.  (It's been a 
long time since I was deep in the bowels of config(1), though, so entirely 
possible that something drastic has changed while I wasn't paying attention...)

-- thorpej



Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Jared McNeill

On Sun, 19 Aug 2018, Rin Okuyama wrote:


On 2018/08/18 22:41, Jared McNeill wrote:
Not sure I understand this change. arm32 should be defined on 32-bit evbarm 
platforms via std.evbarm.


If arm32 is not defined, I wouldn't expect a kernel to link as there are 
dependencies on it in arch/arm/conf/files.arm as well.


No "arm32" is not defined.

arch/arm/conf/files.arm is included because of "machine evbarm arm" lines in
std.* files for 32bit machines. On the other hand, for 64bit machines,


Thanks, I understand the issue now.


Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Rin Okuyama

On 2018/08/19 0:06, Jason Thorpe wrote:

On 2018/08/18 20:08, Rin Okuyama wrote:

Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31.


Sorry, not 1.31 but 1.30.


That's because all options are normalized to lower-case.


Oops, not "if" but "ifdef".

"ifdef" statements refer "attrtab", whose entries are not normalized to
lower-case. Therefore, "ifdef arm32" becomes false even if we have
"options ARM32", as I wrote in the previous message:

http://mail-index.netbsd.org/source-changes-d/2018/08/18/msg010463.html

Well, this is a very confusing behavior of config(1). We should normalize
everything to lower-case, provided no one depends on this behavior...

rin


Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Rin Okuyama

On 2018/08/18 22:41, Jared McNeill wrote:

Not sure I understand this change. arm32 should be defined on 32-bit evbarm 
platforms via std.evbarm.

If arm32 is not defined, I wouldn't expect a kernel to link as there are 
dependencies on it in arch/arm/conf/files.arm as well.


No "arm32" is not defined.

arch/arm/conf/files.arm is included because of "machine evbarm arm" lines in
std.* files for 32bit machines. On the other hand, for 64bit machines,
arch/aarch64/conf/files.aarch64 is used because of "machine evbarm aarch64".

Actually, with files.evbarm rev 1.30, we observe

% ktrace config RPI2 && kdump | grep NAMI | grep 'majors\.'
Build directory is ../compile/RPI2
Don't forget to run "make depend"
 21972  1 config   NAMI  
"../../../../arch/aarch64/conf/majors.aarch64"

On the other hand, with files.evbarm rev 1.31, we have

% ktrace config RPI2 && kdump | grep NAMI | grep 'majors\.'
Build directory is ../compile/RPI2
Don't forget to run "make depend"
  6856  1 config   NAMI  "../../../../arch/arm/conf/majors.arm32"


On Sat, 18 Aug 2018, Rin Okuyama wrote:


Module Name:    src
Committed By:    rin
Date:    Sat Aug 18 09:29:45 UTC 2018

Modified Files:
src/sys/arch/evbarm/conf: files.evbarm

Log Message:
Fix a bug introduced in the previous revision;
We don't define arm32 anywhere, and majors.aarch64 is used unconditionally.


To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/sys/arch/evbarm/conf/files.evbarm

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.







Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Jason Thorpe



> On Aug 18, 2018, at 7:59 AM, Rin Okuyama  wrote:
> 
> On 2018/08/18 20:08, Rin Okuyama wrote:
>> Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31.
> 
> Sorry, not 1.31 but 1.30.

That's because all options are normalized to lower-case.

-- thorpej



Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Rin Okuyama

On 2018/08/18 20:08, Rin Okuyama wrote:

Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31.


Sorry, not 1.31 but 1.30.


On 2018/08/18 18:51, Nick Hudson wrote:

On 18/08/2018 10:29, Rin Okuyama wrote:

Module Name:    src
Committed By:    rin
Date:    Sat Aug 18 09:29:45 UTC 2018

Modified Files:
src/sys/arch/evbarm/conf: files.evbarm

Log Message:
Fix a bug introduced in the previous revision;
We don't define arm32 anywhere, and majors.aarch64 is used unconditionally.



sys/arch/evbarm/conf/std.evbarm:options ARM32

?


Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Jared McNeill
Not sure I understand this change. arm32 should be defined on 32-bit 
evbarm platforms via std.evbarm.


If arm32 is not defined, I wouldn't expect a kernel to link as there are 
dependencies on it in arch/arm/conf/files.arm as well.




On Sat, 18 Aug 2018, Rin Okuyama wrote:


Module Name:src
Committed By:   rin
Date:   Sat Aug 18 09:29:45 UTC 2018

Modified Files:
src/sys/arch/evbarm/conf: files.evbarm

Log Message:
Fix a bug introduced in the previous revision;
We don't define arm32 anywhere, and majors.aarch64 is used unconditionally.


To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/sys/arch/evbarm/conf/files.evbarm

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Rin Okuyama

Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31.

On 2018/08/18 18:51, Nick Hudson wrote:

On 18/08/2018 10:29, Rin Okuyama wrote:

Module Name:    src
Committed By:    rin
Date:    Sat Aug 18 09:29:45 UTC 2018

Modified Files:
src/sys/arch/evbarm/conf: files.evbarm

Log Message:
Fix a bug introduced in the previous revision;
We don't define arm32 anywhere, and majors.aarch64 is used unconditionally.



sys/arch/evbarm/conf/std.evbarm:options ARM32

?




Re: CVS commit: src/sys/arch/evbarm/conf

2018-08-18 Thread Nick Hudson

On 18/08/2018 10:29, Rin Okuyama wrote:

Module Name:src
Committed By:   rin
Date:   Sat Aug 18 09:29:45 UTC 2018

Modified Files:
src/sys/arch/evbarm/conf: files.evbarm

Log Message:
Fix a bug introduced in the previous revision;
We don't define arm32 anywhere, and majors.aarch64 is used unconditionally.



sys/arch/evbarm/conf/std.evbarm:options ARM32

?


Re: CVS commit: src/sys/arch

2018-08-11 Thread Christos Zoulas
In article <20180810182215.1494684...@mail.netbsd.org>,
Leonardo Taccari   wrote:
>Hello Sevan,
>
>"Sevan Janiyan" writes:
>> Module Name: src
>> Committed By:sevan
>> Date:Fri Aug 10 17:54:46 UTC 2018
>>
>> Modified Files:
>>  src/sys/arch/amd64/conf: GENERIC
>>  src/sys/arch/i386/conf: GENERIC
>>
>> Log Message:
>> Add snippet for bpfjit(4) as both i386 and amd64 are listed as supported.
>> Ideally BPFJIT should be enabled by default for use with NPF but I haven't
>> raised the question (no access to email at the moment) hence both are
>disabled.
>> [...]
>
>I think that on both i386 and amd64 they are loaded as modules,
>e.g.:
>
> | % modstat | grep jit
> | bpfjit  misc filesys  -0   - sljit
> | sljit   misc filesys  a1   - -

Yes, all of npf is modularized...

christos



Re: CVS commit: src/sys/arch

2018-08-10 Thread Leonardo Taccari
Hello Sevan,

"Sevan Janiyan" writes:
> Module Name:  src
> Committed By: sevan
> Date: Fri Aug 10 17:54:46 UTC 2018
>
> Modified Files:
>   src/sys/arch/amd64/conf: GENERIC
>   src/sys/arch/i386/conf: GENERIC
>
> Log Message:
> Add snippet for bpfjit(4) as both i386 and amd64 are listed as supported.
> Ideally BPFJIT should be enabled by default for use with NPF but I haven't
> raised the question (no access to email at the moment) hence both are 
> disabled.
> [...]

I think that on both i386 and amd64 they are loaded as modules,
e.g.:

 | % modstat | grep jit
 | bpfjit  misc filesys  -0   - sljit
 | sljit   misc filesys  a1   - -


re: CVS commit: src/sys/arch/x86

2018-08-09 Thread matthew green
"Maxime Villard" writes:
> Module Name:  src
> Committed By: maxv
> Date: Tue Aug  7 10:50:12 UTC 2018
> 
> Modified Files:
>   src/sys/arch/x86/include: specialreg.h
>   src/sys/arch/x86/x86: errata.c
> 
> Log Message:
> Add five errata for AMD Family 17h (Ryzen etc), tested by Patrick Welche,
> thanks. Also add two errata for Family 16h, not yet tested, so not yet
> enabled.

i enabled these on my family 16h system and it seems fine:

cpu0: "AMD E2-7110 APU with AMD Radeon R2 Graphics"
cpu0: AMD Family 16h (686-class), 1796.70 MHz
cpu0: family 0x16 model 0x30 stepping 0x1 (id 0x730f01)

so you can probably turn them on now.  thanks!


.mrg.


Re: CVS commit: src/sys/arch/aarch64

2018-08-08 Thread Maxime Villard

Le 08/08/2018 à 20:13, Ryo Shimizu a écrit :

It would be nice to set SCTLR_EL1.WXN, by the way.


Yes, It is easy. But should this be synchronized with
security.pax.mprotect.enabled? If so, we need a md-hook in the sysctl helper
of pax.mprotect.enable.


Ah, I misunderstood the meaning of SCTLR_EL1; in fact it also controls EL0.
So no, we probably can't set SCTLR_EL1.WXN, because it affects userland too
and not just the kernel...


re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread matthew green
m...@netbsd.org writes:
> Can we use aprint_debug instead?

it's not an autoconf message, so, please don't use aprint*().


.mrg.

> On Wed, Aug 08, 2018 at 07:50:13AM +, Simon Burge wrote:
> > Module Name:src
> > Committed By:   simonb
> > Date:   Wed Aug  8 07:50:12 UTC 2018
> > 
> > Modified Files:
> > src/sys/arch/mips/mips: cpu_exec.c
> > 
> > Log Message:
> > Make change of ABI printf()s #ifdef DEBUG_EXEC.


Re: CVS commit: src/sys/arch/aarch64

2018-08-08 Thread Ryo Shimizu


>Also, why don't we tag each userland page with LX_BLKPAG_PXN?

Oh... I overlooked that.
Certainly, no userland page should not be set executable for kernel. I'll fix.


>It would be nice to set SCTLR_EL1.WXN, by the way.

Yes, It is easy. But should this be synchronized with 
security.pax.mprotect.enabled?
If so, we need a md-hook in the sysctl helper of pax.mprotect.enable.

-- 
ryo shimizu


Re: CVS commit: src/sys/arch/aarch64

2018-08-08 Thread Maxime Villard

Le 04/08/2018 à 17:24, Ryo Shimizu a écrit :

Maybe we should just pass the protection bits in l2_setblocks, and map the
kernel text/rodata as RO right away. It would also make it possible to map
rodata/data as non executable, with PXN|UXN. (Looking at the code it seems
to me rodata/data are executable currently.)

We would make three calls, to map

.text as RX
.rodata as R
.data as RW

a bit like in amd64[1]. Regarding the DDB ifndef, probably there must be
a bit in ARM64 saying "disable page protection", so it could be set when
we enter DDB, and we could remove the ifndef.


I get it. I need to write db_write_text(), and when I finish,
set kernel text/rodata READONLY by default.

Ah...I had forgotten deleting execute bit. We need more 2Mbyte alignment
between .text/.rodata. I will fix.


I see you fixed it, thanks.

Also, why don't we tag each userland page with LX_BLKPAG_PXN?

It would be nice to set SCTLR_EL1.WXN, by the way.


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread maya
On Wed, Aug 08, 2018 at 10:22:33PM +1000, Simon Burge wrote:
> Martin Husemann wrote:
> 
> > On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote:
> > > On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:
> > > > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> > > > > Can we use aprint_debug instead?
> > > > 
> > > > It is not even usefull for general debugging IMHO.
> > > > 
> > > > Martin
> > > 
> > > I like the idea of removing the messages entirely. The code was hard to
> > > read when I had to do it, and I didn't find those messages helpful.
> >
> > I meant: I like the way Simon changed it - it will not show up unless
> > you are explicitly debugging exec stuff.
> 
> On top of what Martin said, there's a DEBUG_EXEC already in
> sys/kern/kern_exec.c .  Do these messages still serve a purpose
> now that the compat stuff is working?  I can't answer that!

I can, because I fixed the compat stuff.


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread Paul Goyette

On Wed, 8 Aug 2018, Martin Husemann wrote:


On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote:

On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:

On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:

Can we use aprint_debug instead?


It is not even usefull for general debugging IMHO.

Martin


I like the idea of removing the messages entirely. The code was hard to
read when I had to do it, and I didn't find those messages helpful.


I meant: I like the way Simon changed it - it will not show up unless
you are explicitly debugging exec stuff.


Well, it could remain conditional, and in addition use aprint_debug() 
instead of printf().  So even if you've compiled it in, you don't see 
anything unless you also boot with debug (ie, boot -x).




+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread Simon Burge
Martin Husemann wrote:

> On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote:
> > On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:
> > > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> > > > Can we use aprint_debug instead?
> > > 
> > > It is not even usefull for general debugging IMHO.
> > > 
> > > Martin
> > 
> > I like the idea of removing the messages entirely. The code was hard to
> > read when I had to do it, and I didn't find those messages helpful.
>
> I meant: I like the way Simon changed it - it will not show up unless
> you are explicitly debugging exec stuff.

On top of what Martin said, there's a DEBUG_EXEC already in
sys/kern/kern_exec.c .  Do these messages still serve a purpose
now that the compat stuff is working?  I can't answer that!

Cheers,
Simon.


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread Martin Husemann
On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote:
> On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:
> > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> > > Can we use aprint_debug instead?
> > 
> > It is not even usefull for general debugging IMHO.
> > 
> > Martin
> 
> I like the idea of removing the messages entirely. The code was hard to
> read when I had to do it, and I didn't find those messages helpful.

I meant: I like the way Simon changed it - it will not show up unless
you are explicitly debugging exec stuff.

Martin


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread maya
On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:
> On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> > Can we use aprint_debug instead?
> 
> It is not even usefull for general debugging IMHO.
> 
> Martin

I like the idea of removing the messages entirely. The code was hard to
read when I had to do it, and I didn't find those messages helpful.


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread Martin Husemann
On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> Can we use aprint_debug instead?

It is not even usefull for general debugging IMHO.

Martin


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread maya
Can we use aprint_debug instead?

On Wed, Aug 08, 2018 at 07:50:13AM +, Simon Burge wrote:
> Module Name:  src
> Committed By: simonb
> Date: Wed Aug  8 07:50:12 UTC 2018
> 
> Modified Files:
>   src/sys/arch/mips/mips: cpu_exec.c
> 
> Log Message:
> Make change of ABI printf()s #ifdef DEBUG_EXEC.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.65 -r1.66 src/sys/arch/mips/mips/cpu_exec.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

> Modified files:
> 
> Index: src/sys/arch/mips/mips/cpu_exec.c
> diff -u src/sys/arch/mips/mips/cpu_exec.c:1.65 
> src/sys/arch/mips/mips/cpu_exec.c:1.66
> --- src/sys/arch/mips/mips/cpu_exec.c:1.65Sun Oct 16 10:57:58 2016
> +++ src/sys/arch/mips/mips/cpu_exec.c Wed Aug  8 07:50:12 2018
> @@ -1,4 +1,4 @@
> -/*   $NetBSD: cpu_exec.c,v 1.65 2016/10/16 10:57:58 maxv Exp $   */
> +/*   $NetBSD: cpu_exec.c,v 1.66 2018/08/08 07:50:12 simonb Exp $ */
>  
>  /*
>   * Copyright (c) 1992, 1993
> @@ -35,7 +35,7 @@
>   */
>  
>  #include 
> -__KERNEL_RCSID(0, "$NetBSD: cpu_exec.c,v 1.65 2016/10/16 10:57:58 maxv Exp 
> $");
> +__KERNEL_RCSID(0, "$NetBSD: cpu_exec.c,v 1.66 2018/08/08 07:50:12 simonb Exp 
> $");
>  
>  #include "opt_compat_netbsd.h"
>  #include "opt_compat_ultrix.h"
> @@ -96,7 +96,9 @@ mips_netbsd_elf32_probe(struct lwp *l, s
>  {
>   struct proc * const p = l->l_proc;
>   const Elf32_Ehdr * const eh = eh0;
> +#ifdef DEBUG_EXEC
>   int old_abi = p->p_md.md_abi;
> +#endif /* DEBUG_EXEC */
>   const char *itp_suffix = NULL;
>  
>   /*
> @@ -138,8 +140,10 @@ mips_netbsd_elf32_probe(struct lwp *l, s
>   case EF_MIPS_ABI2:
>   itp_suffix = "n32";
>   p->p_md.md_abi = _MIPS_BSD_API_N32;
> +#ifdef DEBUG_EXEC
>   if (old_abi != p->p_md.md_abi)
>   printf("pid %d(%s): ABI set to N32 (e_flags=%#x)\n", 
> p->p_pid, p->p_comm, eh->e_flags);
> +#endif /* DEBUG_EXEC */
>   break;
>  #endif
>  #ifdef COMPAT_16
> @@ -150,9 +154,11 @@ mips_netbsd_elf32_probe(struct lwp *l, s
>   case EF_MIPS_ABI_O32:
>   itp_suffix = "o32";
>   p->p_md.md_abi = _MIPS_BSD_API_O32;
> +#ifdef DEBUG_EXEC
>   if (old_abi != p->p_md.md_abi)
>   printf("pid %d(%s): ABI set to O32 (e_flags=%#x)\n", 
> p->p_pid, p->p_comm, eh->e_flags);
>   break;
> +#endif /* DEBUG_EXEC */
>   default:
>   return ENOEXEC;
>   }
> @@ -208,7 +214,9 @@ mips_netbsd_elf64_probe(struct lwp *l, s
>  {
>   struct proc * const p = l->l_proc;
>   const Elf64_Ehdr * const eh = eh0;
> +#ifdef DEBUG_EXEC
>   int old_abi = p->p_md.md_abi;
> +#endif /* DEBUG_EXEC */
>   const char *itp_suffix = NULL;
>  
>   switch (eh->e_flags & EF_MIPS_ARCH) {
> @@ -247,14 +255,18 @@ mips_netbsd_elf64_probe(struct lwp *l, s
>   case 0:
>   itp_suffix = "64";
>   p->p_md.md_abi = _MIPS_BSD_API_N64;
> +#ifdef DEBUG_EXEC
>   if (old_abi != p->p_md.md_abi)
>   printf("pid %d(%s): ABI set to N64 (e_flags=%#x)\n", 
> p->p_pid, p->p_comm, eh->e_flags);
> +#endif /* DEBUG_EXEC */
>   break;
>   case EF_MIPS_ABI_O64:
>   itp_suffix = "o64";
>   p->p_md.md_abi = _MIPS_BSD_API_O64;
> +#ifdef DEBUG_EXEC
>   if (old_abi != p->p_md.md_abi)
>   printf("pid %d(%s): ABI set to O64 (e_flags=%#x)\n", 
> p->p_pid, p->p_comm, eh->e_flags);
> +#endif /* DEBUG_EXEC */
>   break;
>   default:
>   return ENOEXEC;
> 



Re: CVS commit: src/sys/arch/aarch64

2018-08-05 Thread Jason Thorpe



> On Aug 5, 2018, at 1:55 AM, Martin Husemann  wrote:
> 
> On Sat, Aug 04, 2018 at 06:33:20AM -0700, Jason Thorpe wrote:
>> It only matters when setting / removing breakpoints, so it seems like
>> you want to defer changing page protection right until then.
> 
> Can't we do the breakpoint changes via the direct map instead?

That would probably work, too, at the expense of some possible additional cache 
fiddling.

-- thorpej



Re: CVS commit: src/sys/arch/aarch64

2018-08-05 Thread Martin Husemann
On Sat, Aug 04, 2018 at 06:33:20AM -0700, Jason Thorpe wrote:
> It only matters when setting / removing breakpoints, so it seems like
> you want to defer changing page protection right until then.

Can't we do the breakpoint changes via the direct map instead?

Martin


Re: CVS commit: src/sys/arch/aarch64

2018-08-05 Thread Jason Thorpe


> On Aug 4, 2018, at 2:09 AM, Maxime Villard  wrote:
> 
> Regarding the DDB ifndef, probably there must be
> a bit in ARM64 saying "disable page protection", so it could be set when
> we enter DDB, and we could remove the ifndef.


It only matters when setting / removing breakpoints, so it seems like you want 
to defer changing page protection right until then.

Even if there's not a single bit that will do it (I honestly don't know), why 
not just fiddle with the L2 descriptor directly?

-- thorpej



Re: CVS commit: src/sys/arch/aarch64

2018-08-04 Thread Ryo Shimizu


>Maybe we should just pass the protection bits in l2_setblocks, and map the
>kernel text/rodata as RO right away. It would also make it possible to map
>rodata/data as non executable, with PXN|UXN. (Looking at the code it seems
>to me rodata/data are executable currently.)
>
>We would make three calls, to map
>
>   .text as RX
>   .rodata as R
>   .data as RW
>
>a bit like in amd64[1]. Regarding the DDB ifndef, probably there must be
>a bit in ARM64 saying "disable page protection", so it could be set when
>we enter DDB, and we could remove the ifndef.

I get it. I need to write db_write_text(), and when I finish,
set kernel text/rodata READONLY by default.

Ah...I had forgotten deleting execute bit. We need more 2Mbyte alignment
between .text/.rodata. I will fix.

thanks,
-- 
ryo shimizu


Re: CVS commit: src/sys/arch/evbarm/bcm53xx

2018-08-04 Thread Robert Elz
Date:Sat, 4 Aug 2018 14:33:13 +0100
From:Nick Hudson 
Message-ID:  

  | I'll take a look

Great, thanks.

http://releng.netbsd.org/builds/HEAD/201808040510Z/

provides links to the error logs of the failing builds (ignore the one
that fails building "file" - that's a build race condition that hits 
occasionally, I think it would have failed "the other way" later).

The build in progress now should be just the same, my change was
after it started (you might have a chance to fix things before my
abomination even gerts noticed, perhaps.)   The previous HEAD build
was the same as well.

http://releng.netbsd.org/cgi-bin/builds.cgi

is the index of builds and results.

kre



Re: CVS commit: src/sys/arch/evbarm/bcm53xx

2018-08-04 Thread Nick Hudson

On 04/08/2018 14:27, Robert Elz wrote:

Module Name:src
Committed By:   kre
Date:   Sat Aug  4 13:27:03 UTC 2018

Modified Files:
src/sys/arch/evbarm/bcm53xx: bcm53xx_machdep.c

Log Message:
Hack workaround to deal with KERN_VTOPHYS and KERN_PHYSTOV now
being defined in arm/arm32/machdep.h ... attempt to fix (some) earm
builds.   Even if builds succeed, resulting kernel might not boot,
and if it boots, could crash.   Someone with a clue, please use it!



Oops.

I'll take a look

Nick


Re: CVS commit: src/sys/arch/aarch64

2018-08-04 Thread Maxime Villard

Module Name:src
Committed By:   ryo
Date:   Fri Aug  3 16:32:55 UTC 2018

Modified Files:
src/sys/arch/aarch64/aarch64: genassym.cf locore.S
src/sys/arch/aarch64/conf: kern.ldscript

Log Message:
set kernel text/rodata readonly when not defined DDB.
set readonly segment on 2Mbytes aligned. (kernel image is mapped with 2Mbytes 
L2 block)


To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/sys/arch/aarch64/aarch64/genassym.cf
cvs rdiff -u -r1.13 -r1.14 src/sys/arch/aarch64/aarch64/locore.S
cvs rdiff -u -r1.5 -r1.6 src/sys/arch/aarch64/conf/kern.ldscript

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


Maybe we should just pass the protection bits in l2_setblocks, and map the
kernel text/rodata as RO right away. It would also make it possible to map
rodata/data as non executable, with PXN|UXN. (Looking at the code it seems
to me rodata/data are executable currently.)

We would make three calls, to map

.text as RX
.rodata as R
.data as RW

a bit like in amd64 [1]. Regarding the DDB ifndef, probably there must be
a bit in ARM64 saying "disable page protection", so it could be set when
we enter DDB, and we could remove the ifndef.

Maxime

[1] https://nxr.netbsd.org/xref/src/sys/arch/amd64/amd64/locore.S?r=1.173#675


Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-07-17 Thread Christos Zoulas
On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64

| kern_vtopdiff has already been fixed. (thanks christos@)
| u_int uboot_args[4] (in various file :-P) has same problem.
| Should I fix it? [Y/y]

I just did.

christos


Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-07-17 Thread Christos Zoulas
On Jul 18, 12:57am, r...@nerv.org (Ryo Shimizu) wrote:
-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64

| 
| >On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
| >-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
| >
| >| kern_vtopdiff has already been fixed. (thanks christos@)
| >| u_int uboot_args[4] (in various file :-P) has same problem.
| >| Should I fix it? [Y/y]
| >
| >Please do! Does the gcc kernel boot after all the changes?
| 
| Yes. Now the kernel (GENERIC64 and RPI64) compiled by aarch64-gcc has been
| booted fine. Thank you for everything!

Thank you!

| >Also I think that the '#define {fp,lr}', should probably go to the asm.h
| >file, instead of putting it on each .S file?
| 
| I see, you're right.
| Apart from that, I wonder why gcc/gas cannot handle the symbols of fp and 
lr...

Perhaps because our binutils is ancient. But moving to 2.30 has other
problems that I need to resolve first... So let's do it for now.

Best,

christos


Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-07-17 Thread Ryo Shimizu


>On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
>-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
>
>| kern_vtopdiff has already been fixed. (thanks christos@)
>| u_int uboot_args[4] (in various file :-P) has same problem.
>| Should I fix it? [Y/y]
>
>Please do! Does the gcc kernel boot after all the changes?

Yes. Now the kernel (GENERIC64 and RPI64) compiled by aarch64-gcc has been 
booted fine.
Thank you for everything!


>Also I think that the '#define {fp,lr}', should probably go to the asm.h file,
>instead of putting it on each .S file?

I see, you're right.
Apart from that, I wonder why gcc/gas cannot handle the symbols of fp and lr...


-- 
ryo shimizu


Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-07-17 Thread Christos Zoulas
On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64

| kern_vtopdiff has already been fixed. (thanks christos@)
| u_int uboot_args[4] (in various file :-P) has same problem.
| Should I fix it? [Y/y]

Please do! Does the gcc kernel boot after all the changes?

Thanks for all your work with this.

Also I think that the '#define {fp,lr}', should probably go to the asm.h file,
instead of putting it on each .S file?

christos


Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-07-17 Thread Ryo Shimizu


>On Tue, Jul 17, 2018 at 11:12:41AM +, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Tue Jul 17 11:12:41 UTC 2018
>> 
>> Modified Files:
>>  src/sys/arch/aarch64/aarch64: aarch64_machdep.c
>> 
>> Log Message:
>> kern_vtopdiff is stored in fdt_start.S. that is before cleaning bss.
>> decl "kern_vtopdiff = 0" for keep in .data section.
>
>That sounds really fragile. Put it explicitly into .data via section
>attribute?

kern_vtopdiff has already been fixed. (thanks christos@)
u_int uboot_args[4] (in various file :-P) has same problem.
Should I fix it? [Y/y]

-- 
ryo shimizu


Re: CVS commit: src/sys/arch/aarch64/include

2018-07-17 Thread Christos Zoulas
In article <2018071711.5b119f...@cvs.netbsd.org>,
Joerg Sonnenberger  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  joerg
>Date:  Tue Jul 17 11:55:55 UTC 2018
>
>Modified Files:
>   src/sys/arch/aarch64/include: types.h
>
>Log Message:
>Be consistent and explicitly size register32_t too.

The reason I did not do that (I don't disagree with the change though)
is that in reg.h they are declared as unsigned int, not __uint32_t.

christos



Re: CVS commit: src/sys/arch/aarch64/aarch64

2018-07-17 Thread Joerg Sonnenberger
On Tue, Jul 17, 2018 at 11:12:41AM +, Ryo Shimizu wrote:
> Module Name:  src
> Committed By: ryo
> Date: Tue Jul 17 11:12:41 UTC 2018
> 
> Modified Files:
>   src/sys/arch/aarch64/aarch64: aarch64_machdep.c
> 
> Log Message:
> kern_vtopdiff is stored in fdt_start.S. that is before cleaning bss.
> decl "kern_vtopdiff = 0" for keep in .data section.

That sounds really fragile. Put it explicitly into .data via section
attribute?

Joerg


Re: CVS commit: src/sys/arch/arm/arm32

2018-07-17 Thread Joerg Sonnenberger
On Tue, Jul 17, 2018 at 05:29:07AM +, Martin Husemann wrote:
> Module Name:  src
> Committed By: martin
> Date: Tue Jul 17 05:29:07 UTC 2018
> 
> Modified Files:
>   src/sys/arch/arm/arm32: bus_dma.c
> 
> Log Message:
> Revert previous and cast to u_quad_t instead (t is for ptrdiff_t and off_t
> does not match that on all arm)

Please do not use *quad_t.

Joerg


Re: CVS commit: src/sys/arch

2018-07-15 Thread Kamil Rytarowski
On 14.07.2018 18:29, m...@netbsd.org wrote:
> On Sat, Jul 14, 2018 at 03:09:41PM +, Maxime Villard wrote:
>> Module Name: src
>> Committed By:maxv
>> Date:Sat Jul 14 15:09:41 UTC 2018
>>
>> Modified Files:
>>  src/sys/arch/bebox/conf: INSTALL
>>  src/sys/arch/evbarm/conf: ARMADAXP ARMADILLO-IOT-G3 BCM5301X BCM56340
>>  CUBOX CUBOX-I DUOVERO EXYNOS GENERIC GENERIC.common GENERIC64
>>  GOLDENGATE IGEPV2 IMX31LITE IMX6UL-STARTER MARVELL_NAS N900
>>  NITROGEN6X OMAP5EVM OVERO PANDABOARD PEPPER SUNXI TEGRA TISDP2420
>>  TISDP2430 VEXPRESS_A15 VIRT VTC100
>>  src/sys/arch/sandpoint/conf: ENCPP1 SANDPOINT
>>
>> Log Message:
>> Remove "options IPKDB", and the other associated options, from the config
>> files.
>>
>> ipkdb is being retired. Its code is really old, and hasn't kept pace with
>> today's expectations: IPv6, SMP, modern NICs. The associated code for x86
>> was already removed because it was too incorrect to stay.
>>
>> There are plans to rewrite a similar feature from scratch.
>>
>> ok kamil christos
> 
> Looks like there are a lot of code references to IPKDB, still.
> Do we want to remove them?
> 


Yes, if we will find it useful and implementable in future, we will
reintroduce it.



signature.asc
Description: OpenPGP digital signature


  1   2   3   4   5   6   7   8   9   10   >