On Fri, May 13, 2016 at 07:50:20AM +0200, Maxime Villard wrote:
> It's all explained in the commit messages that came afterwards.
Sorry, but it is still completely unclear to me what the overall
benefit is.
An executable read-only .rodata should be ok and only if you happen
to have it cross a lar
Le 12/05/2016 15:31, Joerg Sonnenberger a écrit :
On Thu, May 12, 2016 at 06:45:17AM +, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Thu May 12 06:45:16 UTC 2016
Modified Files:
src/sys/arch/amd64/amd64: locore.S machdep.c
src/sys/arch/amd64
In article <20160512133124.ga29...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Thu, May 12, 2016 at 06:45:17AM +, Maxime Villard wrote:
>> Module Name: src
>> Committed By:maxv
>> Date:Thu May 12 06:45:16 UTC 2016
>>
>> Modified Files:
>> src/sys/arch/amd64
On Thu, May 12, 2016 at 06:45:17AM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Thu May 12 06:45:16 UTC 2016
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S machdep.c
> src/sys/arch/amd64/conf: kern.ldscript
> src/sys/arch/i386/co
Le 07/05/2016 23:13, matthew green a écrit :
Joerg Sonnenberger writes:
On Sat, May 07, 2016 at 11:49:21AM +, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Sat May 7 11:49:21 UTC 2016
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Message:
Joerg Sonnenberger writes:
> On Sat, May 07, 2016 at 11:49:21AM +, Maxime Villard wrote:
> > Module Name:src
> > Committed By: maxv
> > Date: Sat May 7 11:49:21 UTC 2016
> >
> > Modified Files:
> > src/sys/arch/amd64/amd64: locore.S
> >
> > Log Message:
> > cl
On Sat, May 07, 2016 at 11:49:21AM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Sat May 7 11:49:21 UTC 2016
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S
>
> Log Message:
> clarify
WTH. Can you please not mix arbitrary stylistic changes
On Wed, Apr 06, 2016 at 06:02:33AM +1000, matthew green wrote:
> or convert it (back to?) a __cpu_simple_lock.
Yes, whatever is easiest and works.
Martin
Martin Husemann writes:
> On Tue, Apr 05, 2016 at 03:02:25PM +0200, J. Hannken-Illjes wrote:
> > The attached hack works for me -- looks like we cannot use a mutex
> > so early ...
>
> Or just skip the mutex_{enter,exit} while cold?
or convert it (back to?) a __cpu_simple_lock.
.mrg.
> On 05 Apr 2016, at 15:05, Martin Husemann wrote:
>
> On Tue, Apr 05, 2016 at 03:02:25PM +0200, J. Hannken-Illjes wrote:
>> The attached hack works for me -- looks like we cannot use a mutex
>> so early ...
>
> Or just skip the mutex_{enter,exit} while cold?
The first crash is the result of m
On Tue, Apr 05, 2016 at 03:36:13PM +0200, J. Hannken-Illjes wrote:
> The first crash is the result of mutex_init -> lockdebug_alloc().
Yeah, and init it "later" - but I don't know what a good point for that
would be.
Martin
On Tue, Apr 05, 2016 at 03:02:25PM +0200, J. Hannken-Illjes wrote:
> The attached hack works for me -- looks like we cannot use a mutex
> so early ...
Or just skip the mutex_{enter,exit} while cold?
Martin
> On 01 Apr 2016, at 22:21, Palle Lyckegaard wrote:
>
> Module Name: src
> Committed By: palle
> Date: Fri Apr 1 20:21:45 UTC 2016
>
> Modified Files:
> src/sys/arch/sparc/include: openfirm.h
> src/sys/arch/sparc/sparc: openfirm.c promlib.c
>
> Log Message:
> sun4v: Worka
Hi Nick!
On Thu, Mar 03, 2016 at 05:01:31PM +, Nick Hudson wrote:
> Log Message:
> Get the RPI3 working (in aarch32 mode) by recognising Cortex A53 CPUs.
> While I'm here add some A57/A72 info as well.
>
> My RPI3 works with FB console - the uart needs some help with its clocks.
Thanks for y
Hello,
On Wed, 13 Jan 2016 16:35:38 +0100
Manuel Bouyer wrote:
> On Wed, Jan 13, 2016 at 01:29:52PM +, Michael Lorenz wrote:
> > Module Name:src
> > Committed By: macallan
> > Date: Wed Jan 13 13:29:51 UTC 2016
> >
> > Modified Files:
> > src/sys/arch/arm/all
On Wed, Jan 13, 2016 at 01:29:52PM +, Michael Lorenz wrote:
> Module Name: src
> Committed By: macallan
> Date: Wed Jan 13 13:29:51 UTC 2016
>
> Modified Files:
> src/sys/arch/arm/allwinner: awin_tcon.c
>
> Log Message:
> add OUTPUT_VGA in order to shut down the right output(s)
On Mon, Jan 04, 2016 at 06:33:50PM +1100, matthew green wrote:
> "Christos Zoulas" writes:
> > Module Name:src
> > Committed By: christos
> > Date: Sun Jan 3 20:59:47 UTC 2016
> >
> > Modified Files:
> > src/sys/arch/i386/stand/bootxx: pbr.S
> >
> > Log Message:
>
On Jan 10, 2:29pm, ryo...@yk.rim.or.jp (Ryo ONODERA) wrote:
-- Subject: Re: CVS commit: src/sys/arch/amd64/conf
| It is not needed.
I've removed it already!
christos
From: Ryo ONODERA , Date: Sun, 10 Jan 2016 13:04:07 +0900
(JST)
> Hi,
>
> From: chris...@zoulas.com (Christos Zoulas), Date: Sat, 9 Jan 2016 23:01:25
> -0500
>
>> On Jan 10, 12:57pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
>> -- Subject: Re: CVS comm
Hi,
From: chris...@zoulas.com (Christos Zoulas), Date: Sat, 9 Jan 2016 23:01:25
-0500
> On Jan 10, 12:57pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> -- Subject: Re: CVS commit: src/sys/arch/amd64/conf
>
> | christos@ wrote:
> |
> | > Modified Files:
> | >
On Jan 10, 12:57pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/amd64/conf
| christos@ wrote:
|
| > Modified Files:
| > src/sys/arch/amd64/conf: GENERIC
| >
| > Log Message:
| > PR/50636: Ryo ONODERA: Add scsibus to vioscsi
|
| &
christos@ wrote:
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC
>
> Log Message:
> PR/50636: Ryo ONODERA: Add scsibus to vioscsi
>> +#mos* at uhub? port ? # Moschip MCS7730/MCS7830/MCS7832 based
>> adapters
What's this one?
>> +scsibus* at vioscsi?
Why the existing
On Mon, Jan 04, 2016 at 06:33:50PM +1100, matthew green wrote:
> "Christos Zoulas" writes:
> > Module Name:src
> > Committed By: christos
> > Date: Sun Jan 3 20:59:47 UTC 2016
> >
> > Modified Files:
> > src/sys/arch/i386/stand/bootxx: pbr.S
> >
> > Log Message:
>
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Jan 3 20:59:47 UTC 2016
>
> Modified Files:
> src/sys/arch/i386/stand/bootxx: pbr.S
>
> Log Message:
> change 60 to 70 which is the current release. Noticed by Rares Aioanei.
i don't think so we sho
On Mon, 14 Dec 2015, Paul Goyette wrote:
On Mon, 14 Dec 2015, Marty Fouts wrote:
Module Name:src
Committed By: marty
Date: Mon Dec 14 00:00:22 UTC 2015
Modified Files:
src/sys/arch/evbarm/conf: ODROID-XU4
Log Message:
enable the watch dog
This will work only if the p
On Mon, 14 Dec 2015, Marty Fouts wrote:
Module Name:src
Committed By: marty
Date: Mon Dec 14 00:00:22 UTC 2015
Modified Files:
src/sys/arch/evbarm/conf: ODROID-XU4
Log Message:
enable the watch dog
This will work only if the patch to sysmon_wdog.c to convert it to
MODU
thanks for fixing these problems. i was espcially amused by the
code that was if (copyout() || copyout() || suword()).
> Modified Files:
> src/sys/arch/sparc64/sparc64: machdep.c netbsd32_machdep.c
> sunos_machdep.c
>
> Log Message:
> remove all MD uses of suword(), replace by co
In article <20151113235600.68160682715d32da26bd8...@phoenix.owl.de>,
Frank Wille wrote:
>On Fri, 13 Nov 2015 08:45:29 +1100
>matthew green wrote:
>
>> > I didn't manage to make the "wskbd" protocol the default in the X
>> > server, so you have to provide a small xorg.conf with Option "Protocol"
On Fri, 13 Nov 2015 08:45:29 +1100
matthew green wrote:
> > I didn't manage to make the "wskbd" protocol the default in the X
> > server, so you have to provide a small xorg.conf with Option "Protocol"
> > "wskbd". The standard protocol will not work as the Amiga wskbd cannot
> > be switched into
> I didn't manage to make the "wskbd" protocol the default in the X server,
> so you have to provide a small xorg.conf with Option "Protocol" "wskbd".
> The standard protocol will not work as the Amiga wskbd cannot be switched
> into raw mode and has no AT-scancode translation in the kernel.
try h
> Module Name: src
> Committed By: christos
> Date: Mon Nov 9 02:13:41 UTC 2015
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: syscall.c
>
> Log Message:
> fix printf formats.
yuck, can't you just use PRId64 instead of the casts? these are
int64 members. also, using %# vs
Typo in awin_reg.h?
-#define AWIN_DEBE_MODCTL_OUT_SEL_LCD 0
+#define AWIN_DEBE_MODCTL_OUT_SEL_LCD0 0
+#define AWIN_DEBE_MODCTL_OUT_SEL_LCD1 0
On Tue, 3 Nov 2015, Manuel Bouyer wrote:
Module Name:src
Committed By: bouyer
Date: Tue Nov 3 18:38:03 UTC 2015
Modified Files:
On Wed, Oct 21, 2015 at 06:27:10AM -0300, Jared McNeill wrote:
> A31 and A80 use different PMUs. I checked in a fix -- the axp20x specific
> code in awin_machdep.c is now protected by #if NAXP20X > 0.
thanks ! I was testing something similar.
In the long run I wonder if awin_machdep.c should be sp
A31 and A80 use different PMUs. I checked in a fix -- the axp20x specific
code in awin_machdep.c is now protected by #if NAXP20X > 0.
On Tue, 20 Oct 2015, Jeff Rizzo wrote:
On 10/17/15 8:30 AM, Manuel Bouyer wrote:
Module Name:src
Committed By: bouyer
Date: Sat Oct 17 15:30:1
On 10/17/15 8:30 AM, Manuel Bouyer wrote:
Module Name:src
Committed By: bouyer
Date: Sat Oct 17 15:30:14 UTC 2015
Modified Files:
src/sys/arch/arm/allwinner: awin_board.c awin_reg.h awin_var.h
src/sys/arch/evbarm/awin: awin_machdep.c
src/sys/arch/evbarm/co
Le 09/10/2015 06:49, Masanobu SAITOH a écrit :
> On 2015/10/06 6:10, Jean-Yves Migeon wrote:
>>> Log Message:
>>> kmem_free() the address returned by kmem_alloc(). found by Brainy.
>>> use the newly aligned location if we needed it. found by kre.
>>>
>>>
>>> To generate a diff of this commit:
>>>
On Thu, Oct 08, 2015 at 07:19:15PM -0300, Jared McNeill wrote:
> Unless you plan on implementing a better fix, I'm going to commit something
> like this (not compile tested) to restore HDMI audio functionality for A20
> and A31.
By experiments, I found that it's better to turn off the signals in
H
On 2015/10/06 6:10, Jean-Yves Migeon wrote:
Le 04/10/2015 19:52, matthew green a écrit :
Module Name:src
Committed By: mrg
Date: Sun Oct 4 17:52:50 UTC 2015
Modified Files:
src/sys/arch/x86/x86: cpu_ucode_intel.c
Log Message:
kmem_free() the address returned by kmem_al
Unless you plan on implementing a better fix, I'm going to commit
something like this (not compile tested) to restore HDMI audio
functionality for A20 and A31.
Index: awin_debe.c
===
RCS file: /cvsroot/src/sys/arch/arm/allwinner/a
On Tue, 6 Oct 2015, Manuel Bouyer wrote:
On Tue, Oct 06, 2015 at 10:06:31AM +1100, matthew green wrote:
And is this really a problem ? turning off video is configurable in the
X server, so if you want audio without video you can turn off the
screensaver ...
it's a problem if you want the scre
On Tue, Oct 06, 2015 at 10:06:31AM +1100, matthew green wrote:
> > And is this really a problem ? turning off video is configurable in the
> > X server, so if you want audio without video you can turn off the
> > screensaver ...
>
> it's a problem if you want the screensaver to work when you're no
> And is this really a problem ? turning off video is configurable in the
> X server, so if you want audio without video you can turn off the
> screensaver ...
it's a problem if you want the screensaver to work when you're not
using the video or audio. your idea means it is *always* on.
.mrg.
Le 04/10/2015 19:52, matthew green a écrit :
> Module Name: src
> Committed By: mrg
> Date: Sun Oct 4 17:52:50 UTC 2015
>
> Modified Files:
> src/sys/arch/x86/x86: cpu_ucode_intel.c
>
> Log Message:
> kmem_free() the address returned by kmem_alloc(). found by Brainy.
> use the ne
Device tree is definitely the way to go (IMHO) but we don't have that
code today and that's not a small effort. I wrote the fex code at a time
when there was no other option. So it's there if you want to use it.
On Mon, 5 Oct 2015, Manuel Bouyer wrote:
On Mon, Oct 05, 2015 at 01:28:08PM -03
It's really a problem because of how the audio device behaves when you
turn the clock off from under it. I don't think changing X server
configuration is a good solution when we can clearly do better than that
by adding a bit of logic in the display driver to handle it.
On Mon, 5 Oct 2015, Ma
On Mon, Oct 05, 2015 at 01:28:08PM -0300, Jared McNeill wrote:
> On Mon, 5 Oct 2015, Manuel Bouyer wrote:
> >BTW, I'm looking at this because I need to make the LVDS interface to work
> >(and turn the display on/off via GPIOs, to save power). Do you have ideas
> >on how this should work ?
> >We won
On Mon, Oct 05, 2015 at 02:42:00PM -0300, Jared McNeill wrote:
> On Mon, 5 Oct 2015, Manuel Bouyer wrote:
>
> >On Mon, Oct 05, 2015 at 02:13:51PM -0300, Jared McNeill wrote:
> >>Can you see what happens to audio output when the display is turend off in
> >>this way? I have a vague memory of trying
On Mon, 5 Oct 2015, Manuel Bouyer wrote:
On Mon, Oct 05, 2015 at 02:13:51PM -0300, Jared McNeill wrote:
Can you see what happens to audio output when the display is turend off in
this way? I have a vague memory of trying something like this before..
Not easily, my display doens't deal with HD
On Mon, Oct 05, 2015 at 02:13:51PM -0300, Jared McNeill wrote:
> Can you see what happens to audio output when the display is turend off in
> this way? I have a vague memory of trying something like this before..
Not easily, my display doens't deal with HDMI audio.
It's also possible that the disp
FWIW, radeondrmkms has this audio depends on video problem. i noticed
that hdmi audio works mostly fine in netbsd-7, so i tried to switch to
it. unfortunately there are at least three problems i need to look at:
- the display must be unblanked (ie, the "xset dpms" standby
time
Can you see what happens to audio output when the display is turend off in
this way? I have a vague memory of trying something like this before..
On Mon, 5 Oct 2015, Manuel Bouyer wrote:
On Mon, Oct 05, 2015 at 05:28:50PM +0200, Manuel Bouyer wrote:
On Mon, Oct 05, 2015 at 12:20:57PM -0300,
On Mon, Oct 05, 2015 at 05:28:50PM +0200, Manuel Bouyer wrote:
> On Mon, Oct 05, 2015 at 12:20:57PM -0300, Jared McNeill wrote:
> > Not sure I like this. Disabling TCON interferes with HDMI audio (and this is
> > why the code was the way that it was) and I'm not aware of any "blank screen
> > but k
On Mon, 5 Oct 2015, Manuel Bouyer wrote:
BTW, I'm looking at this because I need to make the LVDS interface to work
(and turn the display on/off via GPIOs, to save power). Do you have ideas
on how this should work ?
We won't have EDID source in this case; for the omap controller I did
hardcode a
I don't mind turning off TCON, but I think we need to take HDMI audio into
consideration when doing so. I don't think interrupting audio output is a
good idea. Unfortunately wscons only give us an on/off switch so we need
to be smart about it in the kernel. So I think the blanking solution needs
On Mon, Oct 05, 2015 at 12:20:57PM -0300, Jared McNeill wrote:
> Not sure I like this. Disabling TCON interferes with HDMI audio (and this is
> why the code was the way that it was) and I'm not aware of any "blank screen
> but keep audio active" mechanism for HDMI displays.
So you say we should al
Not sure I like this. Disabling TCON interferes with HDMI audio (and this
is why the code was the way that it was) and I'm not aware of any "blank
screen but keep audio active" mechanism for HDMI displays.
On Mon, 5 Oct 2015, Manuel Bouyer wrote:
Module Name:src
Committed By: bouyer
Da
On Fri, Oct 02, 2015 at 12:44:32PM -0300, Jared McNeill wrote:
> Instead of an extra line of output, can you change this to use your own
> callback instead of gpiobus_print for config_attach_ia? Here's what I do on
> Tegra:
>
> http://nxr.netbsd.org/xref/src/sys/arch/arm/nvidia/tegra_gpio.c#196
Instead of an extra line of output, can you change this to use
your own callback instead of gpiobus_print for config_attach_ia? Here's
what I do on Tegra:
http://nxr.netbsd.org/xref/src/sys/arch/arm/nvidia/tegra_gpio.c#196
The result is a lot cleaner (especially since there are 31 instances
"Frank Wille" writes:
> Module Name: src
> Committed By: phx
> Date: Wed Sep 30 20:36:28 UTC 2015
>
> Modified Files:
> src/sys/arch/amiga/include: vmparam.h
>
> Log Message:
> Reduce MAXDSIZ from 416MB back to 224MB.
> Due to limitations by the current pmap implementation our virt
On Sun, Sep 6, 2015 at 4:17 PM, Masao Uebayashi wrote:
> Module Name:src
> Committed By: uebayasi
> Date: Sun Sep 6 07:17:14 UTC 2015
>
> Modified Files:
> src/sys/arch/amd64/conf: Makefile.amd64 files.amd64
>
> Log Message:
> Define MD start code at the top of files.${MAC
On Mon, Sep 7, 2015 at 7:01 AM, David Laight wrote:
> On Sat, Sep 05, 2015 at 09:39:43AM +0900, Masao Uebayashi wrote:
>> The reason of this is that config(1) have no idea of library at this
>> moment. Makefile.kern.inc has also a convention that all *.o files
>> have to be built under the top of
On Sat, Sep 05, 2015 at 09:39:43AM +0900, Masao Uebayashi wrote:
> The reason of this is that config(1) have no idea of library at this
> moment. Makefile.kern.inc has also a convention that all *.o files
> have to be built under the top of kernel build directory. libkern &
> libcompat have speic
The reason of this is that config(1) have no idea of library at this
moment. Makefile.kern.inc has also a convention that all *.o files
have to be built under the top of kernel build directory. libkern &
libcompat have speicalized make(1) rules, that work but look ugly.
I'd consider to extend con
Although I confirmed that all kernels of evbearmv7hf-el had no binary
changes after this change, I am a bit confused by [1]. According to
[1], at that time, this linker script was used by hpcboot (of
hpcarm?). Now I see that hpcarm doesn't seem to use linker script at
all.
Anyway, load addresses
netwinder is strange in that it wants .data aligned to 0x8000, but it
also specifies physical/virtual load addresses as
0xc000/0xf000c000, that are obviously not aligned to 0x8000! Can
someone check if other load addresses work? For example
0x0001/0xf001?
On 2015/08/13 13:52, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Thu Aug 13 04:52:40 UTC 2015
Modified Files:
src/sys/arch/x86/pci: msipic.c
Log Message:
Add workaround for PCI prefetchable bit in msipic_construct_msix_pic().
Some chips (e.g. Int
On Jul 30, 12:56am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/sun68k/stand/netboot
| I already said:
| http://mail-index.netbsd.org/source-changes-d/2015/04/26/msg007717.html
|
| I also asked for build but no answer.
| http://mail-index.netbsd.org
> A good portmaster would be watching his ports and keep them building
> and running.
I already said:
http://mail-index.netbsd.org/source-changes-d/2015/04/26/msg007717.html
> | > Having the build broken for weeks is not acceptable. I've added the PR.
> |
> | You always forget your own words.
>
On Jul 29, 11:26pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/sun68k/stand/netboot
| christos@ wrote:
|
| > | Please don't put kludge to hide problem. File a PR instead.
A good portmaster would be watching his ports and keep them buil
christos@ wrote:
> | Please don't put kludge to hide problem. File a PR instead.
>
> Having the build broken for weeks is not acceptable. I've added the PR.
You always forget your own words.
http://mail-index.netbsd.org/source-changes-d/2015/04/26/msg007718.html
---
Izumi Tsutsui
On Jul 29, 8:37pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/sun68k/stand/netboot
| Please don't put kludge to hide problem. File a PR instead.
Having the build broken for weeks is not acceptable. I've added the PR.
christos
christos@ wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Jul 29 08:52:22 UTC 2015
>
> Modified Files:
> src/sys/arch/sun68k/stand/netboot: conf.c
>
> Log Message:
> XXX: add missing symbols.
Please don't put kludge to hide problem. File a PR instead.
---
Izumi Ts
> On Jul 25, 2015, at 1:43 AM, Nick Hudson wrote:
>
> Module Name: src
> Committed By: skrll
> Date: Sat Jul 25 08:43:41 UTC 2015
>
> Modified Files:
> src/sys/arch/arm/broadcom: bcm2835_intr.c
>
> Log Message:
> IPIs should be IPL_HIGH according to rmind@
>
> Fix bcm2836mp_pic
I backed it out, will try to fix differently.
Martin
martin@ wrote:
> Module Name: src
> Committed By: martin
> Date: Fri Jul 17 19:32:24 UTC 2015
>
> Modified Files:
> src/sys/arch/zaurus/conf: INSTALL
>
> Log Message:
> Provide a bit more space for the ram disk image
Did you check the following comment in INSTALL?
>> # for reduc
On Wed, Jul 01, 2015 at 02:04:43AM +, Christos Zoulas wrote:
> In article <20150630233112.ga8...@britannica.bec.de>,
> Joerg Sonnenberger wrote:
> >On Tue, Jun 30, 2015 at 05:08:24PM -0400, Christos Zoulas wrote:
> >> Module Name: src
> >> Committed By: christos
> >> Date:
In article <20150630233112.ga8...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tue, Jun 30, 2015 at 05:08:24PM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Jun 30 21:08:24 UTC 2015
>>
>> Modified Files:
>> src/sys/arch/a
On Tue, Jun 30, 2015 at 05:08:24PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Jun 30 21:08:24 UTC 2015
>
> Modified Files:
> src/sys/arch/amd64/amd64: cpu_in_cksum.S
>
> Log Message:
> handle PIC compilation (if we are building a PIE syste
On Wed, 10 Jun 2015 13:07:01 +0200
Radoslaw Kujawa wrote:
> > Modified Files:
> > src/sys/arch/amiga/include: vmparam.h
> >
> > Log Message:
> > Remove unused KUSER_AREA, SYSPTSIZE, USRPTSIZE.
> > Bump MAXTSIZ and MAXDSIZ to the same values atari is using.
> > This makes gcc 4.8 (/usr/libexe
Hi.
> On 1 Jun 2015, at 19:16, Frank Wille wrote:
>
> Module Name: src
> Committed By: phx
> Date: Mon Jun 1 17:16:57 UTC 2015
>
> Modified Files:
> src/sys/arch/amiga/include: vmparam.h
>
> Log Message:
> Remove unused KUSER_AREA, SYSPTSIZE, USRPTSIZE.
> Bump MAXTSIZ and MAXDS
On 06/06/2015 22:44, Matt Thomas wrote:
Module Name:src
Committed By: matt
Date: Sat Jun 6 21:44:17 UTC 2015
Modified Files:
src/sys/arch/mips/cavium: octeon_cpunode.c
src/sys/arch/mips/mips: genassym.cf
Log Message:
Use ci_nmi_stack
To generate a diff of this
On 2015/05/20 2:30, Matt Thomas wrote:
>
>> On May 19, 2015, at 2:20 AM, SUENAGA Hiroki wrote:
>>
>> Module Name: src
>> Committed By:hsuenaga
>> Date:Tue May 19 09:20:19 UTC 2015
>>
>> Modified Files:
>> src/sys/arch/arm/arm: cpufunc_asm_pj4b.S
>> src/sys/arch/a
> On May 19, 2015, at 2:20 AM, SUENAGA Hiroki wrote:
>
> Module Name: src
> Committed By: hsuenaga
> Date: Tue May 19 09:20:19 UTC 2015
>
> Modified Files:
> src/sys/arch/arm/arm: cpufunc_asm_pj4b.S
> src/sys/arch/arm/marvell: armadaxp.c mvsocreg.h
>
> Log Message:
> fix M
On 2015/05/18 22:09, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Mon May 18 13:09:55 UTC 2015
Modified Files:
src/sys/arch/x86/x86: cpu.c
Log Message:
PS. Revert previous.
To generate a diff of this commit:
cvs rdiff -u -r1.114 -r1.115 src/
Yes, if each entry in the path array were treated as a separate test
case, then we could certainly skip the sysmon/power/wdog entries if the
open returns ENODEV.
However, there is one big list of paths, all tested in a single test
case. It would not make sense to report the entire test case a
On Wed, May 06, 2015 at 07:43:02AM +0800, Paul Goyette wrote:
> Arguably, the atf test include/t_paths could have been updated to check
> for the specific error ENODEV and treat that as a PASS.
Minor nit: it should skip, not pass.
Martin
Paul Goyette writes:
> GENERIC kernels already include at least one instance of sensor,
> watch-dog, and power-switch, so all the sysmon sub-component drivers
> are included and "built-in" whether or not the kernel is MODULAR.
> (Confirm by running modstat(8) and observe that all symon modules
> a
GENERIC kernels already include at least one instance of sensor,
watch-dog, and power-switch, so all the sysmon sub-component drivers
are included and "built-in" whether or not the kernel is MODULAR.
(Confirm by running modstat(8) and observe that all symon modules
are "built-in".)
It seems to m
> For i386 and amd64:
>
> non-XEN GENERIC is MODULAR, and the sysmon drivers will be autoloaded as
> necesary. Confirmed by successful running of atf test suite.
it MODULAR, but it is supposed to have all common drivers in it.
autoloading isn't something you can depend on.
.mrg.
For i386 and amd64:
non-XEN GENERIC is MODULAR, and the sysmon drivers will be autoloaded as
necesary. Confirmed by successful running of atf test suite.
For other platforms:
MODULAR kernels are unaffected, as drivers will be autoloaded.
Non-MODULAR kernels will contain sysmon sub-component
"Paul Goyette" writes:
> Module Name: src
> Committed By: pgoyette
> Date: Tue May 5 22:14:24 UTC 2015
>
> Modified Files:
> src/sys/arch/amd64/conf: XEN3_DOMU
> src/sys/arch/i386/conf: XEN3_DOMU
>
> Log Message:
> For non-modular XEN3_DOMU kernels, include sysmon and all o
On May 2, 7:33am, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: CVS commit: src/sys/arch/mips/include
| Not all ABIs run on all CPU architectures. N32/N64 are 64-bit only
| so you can exclude all MIPS32 and MIPS1/MIPS2 cpus.
|
| The ABI for the kernel must be the same as the ABI
> On May 2, 2015, at 4:52 AM, Christos Zoulas wrote:
>
> On May 1, 1:46pm, m...@3am-software.com (Matt Thomas) wrote:
> -- Subject: Re: CVS commit: src/sys/arch/mips/include
>
> |
> | > On May 1, 2015, at 11:37 AM, Christos Zoulas wrote:
> | >
> | > Modu
On May 1, 1:46pm, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: CVS commit: src/sys/arch/mips/include
|
| > On May 1, 2015, at 11:37 AM, Christos Zoulas wrote:
| >
| > Module Name:src
| > Committed By: christos
| > Date: Fri May 1 18
> >> If reasonably possible, use MACHINE=MACHINE_ARCH=whatever config.guess
> >> uses for the platform. A lot of the different MACHINE values are due to
> >> historical reasons annd wouldn't happen again.
> >
> > I think keeping evb* for boards makes sense, though.
>
> I agree. MACHINE=evbavr32
> On May 1, 2015, at 11:37 AM, Christos Zoulas wrote:
>
> Module Name: src
> Committed By: christos
> Date: Fri May 1 18:37:40 UTC 2015
>
> Modified Files:
> src/sys/arch/mips/include: locore.h
>
> Log Message:
> change #error to KASSERT
>
>
> To generate a diff of this commi
Hello
2015-04-30 2:16 GMT+09:00 Michael :
>> USB is working with dwc2 code base on OpenBSD. FYI.
>
> And our dwctwo works on MIPS ( ci20's got one )
I will work for it. Thanks.
Hello,
On Wed, 29 Apr 2015 20:12:40 +0900
Masao Uebayashi wrote:
> On Wed, Apr 29, 2015 at 5:32 PM, Hikaru Abe wrote:
> > Log Message:
> > Initial import of Cavium Octeon and Octeon Plus SoC and
> > specifically Ubiquiti Networks EdgeRouter LITE support.
> > Currently the ethernet and uart of a
On Wed, Apr 29, 2015 at 08:32:01AM +, Hikaru Abe wrote:
> Module Name: src
> Committed By: hikaru
> Date: Wed Apr 29 08:32:01 UTC 2015
>
> Modified Files:
> src/sys/arch/mips/conf: files.mips
> src/sys/arch/mips/include: cpuregs.h locore.h
> src/sys/arch/mips/mips: c
On Wed, Apr 29, 2015 at 5:32 PM, Hikaru Abe wrote:
> Log Message:
> Initial import of Cavium Octeon and Octeon Plus SoC and
> specifically Ubiquiti Networks EdgeRouter LITE support.
> Currently the ethernet and uart of are worked.
> This support was contributed by Internet Initiative Japan Inc.
U
801 - 900 of 1962 matches
Mail list logo
