Race VT+X11 on -current

[Hans Petter Selasky]

Hi,

Sometimes when logging into X11 the keyboard input is not working. 
Pressing ALT+F9 makes it work. Any idea where the race is?


--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Race VT+X11 on -current

[Kevin Oberman]

On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky  wrote:

> Hi,
>
> Sometimes when logging into X11 the keyboard input is not working.
> Pressing ALT+F9 makes it work. Any idea where the race is?
>
> --HPS
>

Actually, I have found that switching to ANY other terminal (e.g. ALT-F2)
and back to vty1 does the job.

I must admit that this is a pretty minor annoyance, so I never got around
to reporting it. Still, any bug report should show that it impacts multiple
users.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Race VT+X11 on -current

[Garrett Cooper]

> On May 7, 2015, at 09:43, Kevin Oberman  wrote:
> 
>> On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky  wrote:
>> 
>> Hi,
>> 
>> Sometimes when logging into X11 the keyboard input is not working.
>> Pressing ALT+F9 makes it work. Any idea where the race is?
>> 
>> --HPS
> 
> Actually, I have found that switching to ANY other terminal (e.g. ALT-F2)
> and back to vty1 does the job.
> 
> I must admit that this is a pretty minor annoyance, so I never got around
> to reporting it. Still, any bug report should show that it impacts multiple
> users.

Speaking of which, please file a bug for this issue so it doesn't get lost!
Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

What to do about RCS/OpenRCS

[Pedro Giffuni]

Hello;

Some of you might recall that right before 10.0-Release there was
a painful attempt to remove GNU RCS from the base system.

From my point of view, the lessons learned from that were:

-A lot more people than you might think find it useful to have
a small version control system for thing like the files in /etc.
-Just removing features without a discussion is not wise.
-IMHO, people wondering about the bloat in the OS should
focus on other bigger VCS we carry, namely svn.

For all I know, it looks like OpenRCS is the most viable option and can
completely replace the old RCS we have in base.

In order to avoid painful surprises late in the release cycle, I started
the process to consider OpenRCS by bringing it to the vendor area
(OpenBSD/usr.bin/rcs/*). I also have an initial patch[1] so that it builds
on FreeBSD.

Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.

All in all, it looks like whatever is done about RCS it may be controversial
so I am opening the discussion in the hope that someone else will
take the lead and do something about it much ahead of 11-Release.

Regards,

Pedro.

[1] Follow the link in:
https://wiki.freebsd.org/GPLinBase
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: What to do about RCS/OpenRCS

[Lyndon Nerenberg]

On Thu, 7 May 2015, Pedro Giffuni wrote:


Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.


If we can have a build-knob to disable GNU RCS and enable the new one I 
will happily twist up the new version and hammer on it.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Race VT+X11 on -current

[Hans Petter Selasky]

On 05/07/15 20:23, Garrett Cooper wrote:



On May 7, 2015, at 09:43, Kevin Oberman  wrote:


On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky  wrote:

Hi,

Sometimes when logging into X11 the keyboard input is not working.
Pressing ALT+F9 makes it work. Any idea where the race is?

--HPS


Actually, I have found that switching to ANY other terminal (e.g. ALT-F2)
and back to vty1 does the job.

I must admit that this is a pretty minor annoyance, so I never got around
to reporting it. Still, any bug report should show that it impacts multiple
users.


Speaking of which, please file a bug for this issue so it doesn't get lost!
Thanks,
-NGie


Hi,

Here it is:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200032

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: What to do about RCS/OpenRCS

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/07/15 12:09, Pedro Giffuni wrote:
> Hello;
> 
> Some of you might recall that right before 10.0-Release there was a
> painful attempt to remove GNU RCS from the base system.
> 
> From my point of view, the lessons learned from that were:
> 
> -A lot more people than you might think find it useful to have a
> small version control system for thing like the files in /etc. 
> -Just removing features without a discussion is not wise. -IMHO,
> people wondering about the bloat in the OS should focus on other
> bigger VCS we carry, namely svn.
> 
> For all I know, it looks like OpenRCS is the most viable option and
> can completely replace the old RCS we have in base.

I have objected this in 2013 because OpenRCS did not pass GNU RCS's
test suite:

https://lists.freebsd.org/pipermail/freebsd-current/2013-October/045185.
html

More specifically:

+ : -Dhas_conf_h
+ : cc
+ : diff
+ CL='cc -Dhas_conf_h  -o a.out'
+ L=''
+ RCSINIT=-x
+ export RCSINIT
+ SLASH=/
+ RCSfile=RCS/a.c
+ RCS_alt=RCS/a.d
+ lockfile=RCS/a._
+ q=-q
+ test -d RCS
+ rmdir=rmdir
+ mkdir RCS
+ rm -f 'a.*' RCS/a.c RCS/a.d RCS/a._
+ echo 1.1
+ echo 1.1.1.1
+ echo 1.2
+ diff -c a.11 a.3x1
+ diff='diff -c'
+ rcs -i -L -ta.11 -q a.c
+ test -r RCS/a.c
+ rlog a.c
+ rm -f RCS/a.c
+ cp a.11 a.c
+ ci -ta.11 -mm -q a.c
+ test -r RCS/a.c
+ rcs -L -q a.c
+ test ! -f a.c
+ co -q a.c
+ test -f a.c
+ diff -c a.11 a.c
+ co -l -q a.c
+ test -f a.c
+ diff -c a.11 a.c
+ cp a.12 a.c
+ ci -mm -q a.c
+ co -q a.c
+ diff -c a.12 a.c
+ rm -f a.c
+ co -r1.1 -q a.c
+ diff -c a.11 a.c
+ rm -f a.c
+ cp a.3x1 a.c
+ ci -r1.1.1 -mm -q a.c
ci: RCS/a.c: no lock set by delphij
+ echo '#branches failed'
#branches failed
+ exit 1

The checkout as of today ported to FreeBSD still does not pass the
test cases, so I still object the replacement unless the issues have
been taken care of.

Cheers,
- -- 
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.2 (FreeBSD)

iQIcBAEBCgAGBQJVS8j7AAoJEJW2GBstM+nsUR4P/1X9hvotuBLzjgY1S6389HJP
3FXoT0+xjJqW0L6Ke5wGJy01Q3awJBGG6OUgSYufZhg32uIwPbLmKKouUuscPj/p
77e+EdonjkNcKIDYurtL8ifLm6bhPUvuWX4JSPcy8SBZtehqXUF0s4WdLqISGXpM
t8iJ56AoGAffQAHEAeHzJDxf41+7Jdb8aw314aFyAAcrcH2Q3giuo6QH75psGoSy
0X3BLu7Wi0eADcTgvLps6eJ6Uwwt+FbCKFySqkNeiXy9+LRnNg8lGUyzHp1gwSJW
5KQ9l+8vFabnAkwVZWkwnZ0mFZRRu24Ui97nwfLOrv0fDYflZIcmfEQQUHTZNp5Z
zsZEulU9MZDA10LgNvIAr4rsDDa41HOY3KA89rGuWXQpxZUOwzibWNnNfHOJIW9c
b4rGJ+femjr5wllvjG3vURGS6mkPvtLt7e/nO4pAZ+ev06KBLQAp+qd3RCjFPMRw
+cFpFXwSN+O2e6aQbYLduk18UAJFLkZf/1tH1AaO4pnjxyM3liZeE5oeIVoqUVMu
2iNNyb15Vk7dJL2DIam1MSX4UA+mCLgsJ6m+SIbigB6zYusUm2vPbDkx+e82fnhu
QlXml8k+ZQjZm6nZl45l2yaRmhRyIVq2b4GgiC6zG/WUfn4mSju83gI2hEfuGqhj
VgaTuJMDK6pjCpTKfA/B
=di1X
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: What to do about RCS/OpenRCS

[Pedro Giffuni]

Hello;

On 05/07/15 14:56, Lyndon Nerenberg wrote:

On Thu, 7 May 2015, Pedro Giffuni wrote:


Unfortunately I don't use RCS enough (it looks like I should though) so
I am not in a good position to take the next step and deal with any
fallout it may produce.


If we can have a build-knob to disable GNU RCS and enable the new one 
I will happily twist up the new version and hammer on it.




Yes, that's usually the next step in the process. It is a little bit 
messy because

there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
perhaps something else that we don't use).

I really want to check out first if there is some strong opinion against
OpenRCS. Perhaps someone that has used it before and thinks it is a
bad idea.

It looks like there are voices against it, so those have to be addressed 
first.


Pedro.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Race VT+X11 on -current

[Hans Petter Selasky]

On 05/07/15 22:00, Hans Petter Selasky wrote:

On 05/07/15 20:23, Garrett Cooper wrote:



On May 7, 2015, at 09:43, Kevin Oberman  wrote:


On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky
 wrote:

Hi,

Sometimes when logging into X11 the keyboard input is not working.
Pressing ALT+F9 makes it work. Any idea where the race is?

--HPS


Actually, I have found that switching to ANY other terminal (e.g.
ALT-F2)
and back to vty1 does the job.

I must admit that this is a pretty minor annoyance, so I never got
around
to reporting it. Still, any bug report should show that it impacts
multiple
users.


Speaking of which, please file a bug for this issue so it doesn't get
lost!
Thanks,
-NGie


Hi,

Here it is:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200032

--HPS


Hi,

It might look like you can reproduce like this:

1) Boot computer into GDM / slim.
2) Wait more than 15 seconds.
3) Keyboard appears frozen.
4) Press ALT+F9
5) Keyboard works again.

If waiting less than 15 seconds everything is fine. Might be related to 
"vw_proc_dead_timer" in VT. I'll debug more tomorrow. Seems trivial.


--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

hastd fail and panic on MAXPHYS=1m

[Daisuke Aoyama]

Hi all,

I have problem with MAXPHYS=1m. (I don't know MAXPHYS=1m works on HAST.)

I put "options MAXPHYS=(1024*1024)" in kernel config.
Then, update primary node to the kernel and world.
If the role back to primary on the machine, writing to the hast device cause an 
error and panic.

I didn't check carefully, but it seems that geom_gate.ko use MAXPHYS=1m and hastd use 
MAXPHYS=128k.

Of course, secondary is MAXPHYS=128k at this time.

Is it an expected result?

Here is a log while manually mounted test:
[DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b240) Request received from the kernel: 
READ(163840, 28672).

[DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b240) Moving request to the 
send queues.
[DEBUG][2] [hast1] (primary) ggate_recv: Taking free request.
[DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b1f0) 
Gotg_vfs_done():hast/hast1p1[WRITE(offset=174784512, length=393216)]error = 6

/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
/mnt: got error 6 while accessing filesystem
free request.
[DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b1f0) Waiting for request from 
the kernel.
[DEBUG][2] [hast1] (primary) local_send: (0x20c4b240) Got request.
[DEBUG][2] [hast1] (primary) local_send: (0x20c4b240) Moving request to the 
done queue.
[DEBUG][2] [hast1] (primary) [DEBUG][2] [hast1] (primary) ggate_send: 
(0x20c4b240) Got request.
local_send: Taking request.
[DEBUG][2] [hast1] (primary) ggate_send: (0x20c4b240) Moving request to the 
free queue.
[DEBUG][2] [hast1] (primary) ggate_send: Taking request.
[ERROR] [hast1] (primary) G_GATE_CMD_START failed: Cannot allocate memory.
[DEBUG][1] Unable to receive event header: Socket is not connected.
softdep_deallocate_dependencies: got error 6 while accessing filesystem
/dev: got error 6 while accessing filesystem
panic: brelvp: Buffer 0xb33129d0 not on queue.
cpuid = 3
KDB: enter: panic

--
Daisuke Aoyama


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: nmount, mountd drops high order MNT_xx flags during a mount update

[Rick Macklem]

Doug Rabson wrote:
> You could add a single integer-valued vfsopt which holds the
> high-order
> bits of f_flags?
> 
Yes, that sounds better than any of my ideas. I'll code up a patch
and put it up for review unless someone has a better solution.

Thanks Doug, rick

> On 7 May 2015 at 02:10, Rick Macklem  wrote:
> 
> > David Boyd reported a problem to freebsd-current@ w.r.t. the
> > MNT_AUTOMOUNTED
> > flag getting cleared by mountd.
> >   http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel
> > I just took a look at this and it's kinda ugly...
> >
> > mountd acquires a list of mounts via getmntinfo() and then does an
> > nmount() for each of them to get rid of any exports. It uses
> > f_flags from the statfs returned by getmntinfo() as the 3rd
> > argument to nmount().
> > --> Since nmount()s 3rd argument is a "int", it silently drops any
> > MNT_xx flag in the high order 32bits of f_flags. At this time,
> > it happens that MNT_AUTOMOUNTED is the only one, but...
> >
> > I can think of a couple of ways to fix this, but I don't like any
> > of
> > them;-)
> >
> > 1) I suppose mountd could check for each flag set in f_flags and
> > generate
> > a vfsopts string for it, but that means that every time a new flag
> > that
> > can be updated is added to MNT_xx, this mountd.c code would have to
> > updated.
> > --> Ugly!!
> >
> > 2) Require that all flags in MNT_UPDATEMASK be in the low order
> > 32bits.
> >I wouldn`t mind this except in means that the MNT_xx flags must
> >be
> > redefined
> >and I don`t think that could get MFC`d.
> >
> > 3) Add a new newernmount(2) which has a 64bit flags argument
> > instead of
> > int.
> >
> > Hopefully someone can think of a nice way to fix this, rick
> > ___
> > freebsd-current@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org"
> >
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
> 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: What to do about RCS/OpenRCS

[NGie Cooper]

On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni  wrote:
> Hello;
>
> On 05/07/15 14:56, Lyndon Nerenberg wrote:
>>
>> On Thu, 7 May 2015, Pedro Giffuni wrote:
>>
>>> Unfortunately I don't use RCS enough (it looks like I should though) so
>>> I am not in a good position to take the next step and deal with any
>>> fallout it may produce.
>>
>>
>> If we can have a build-knob to disable GNU RCS and enable the new one I
>> will happily twist up the new version and hammer on it.
>>
>
> Yes, that's usually the next step in the process. It is a little bit messy
> because
> there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
> perhaps something else that we don't use).
>
> I really want to check out first if there is some strong opinion against
> OpenRCS. Perhaps someone that has used it before and thinks it is a
> bad idea.
>
> It looks like there are voices against it, so those have to be addressed
> first.

Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs
bits); check with jhb first to make sure that OpenRCS works with
etcupdate.
Cheers!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Race VT+X11 on -current

[Hans Petter Selasky]

Hi,

I have a fix, attached.

I'll just throw this in if nobody objects. Seems like a trivial issue:

Prevent switching to NULL or own window in the "vt_proc_window_switch"
function. This fixes an issue where X11 keyboard input can appear
stuck. The cause of the problem is a duplicate TTY device window
switch IOCTL during boot, which leaves the "vt_switch_timer" running,
because the current window is already selected. While at it factor out
some NULL checks.

PR: 200032
Reported by:multiple people
MFC after:  1 week

--HPS
Index: vt_core.c
===
--- vt_core.c	(revision 282504)
+++ vt_core.c	(working copy)
@@ -451,9 +451,22 @@
 	struct vt_device *vd;
 	int ret;
 
+	/* Prevent switching to NULL */
+	if (vw == NULL) {
+		DPRINTF(30, "%s: Cannot switch to NULL.", __func__);
+		return (EINVAL);
+	}
 	vd = vw->vw_device;
 	curvw = vd->vd_curwindow;
 
+	/*
+	 * Prevent switching to self to avoid starting the
+	 * "vt_switch_timer()" again:
+	 */
+	if (vw == curvw) {
+		DPRINTF(30, "%s: Cannot switch to self.", __func__);
+		return (0);
+	}
 	if (curvw->vw_flags & VWF_VTYLOCK)
 		return (EBUSY);
 
@@ -664,8 +677,7 @@
 	if (console == 0) {
 		if (c >= F_SCR && c <= MIN(L_SCR, F_SCR + VT_MAXWINDOWS - 1)) {
 			vw = vd->vd_windows[c - F_SCR];
-			if (vw != NULL)
-vt_proc_window_switch(vw);
+			vt_proc_window_switch(vw);
 			return;
 		}
 		VT_LOCK(vd);
@@ -750,8 +762,7 @@
 
 		if (c >= F_SCR && c <= MIN(L_SCR, F_SCR + VT_MAXWINDOWS - 1)) {
 			vw = vd->vd_windows[c - F_SCR];
-			if (vw != NULL)
-vt_proc_window_switch(vw);
+			vt_proc_window_switch(vw);
 			return (0);
 		}
 
@@ -760,15 +771,13 @@
 			/* Switch to next VT. */
 			c = (vw->vw_number + 1) % VT_MAXWINDOWS;
 			vw = vd->vd_windows[c];
-			if (vw != NULL)
-vt_proc_window_switch(vw);
+			vt_proc_window_switch(vw);
 			return (0);
 		case PREV:
 			/* Switch to previous VT. */
 			c = (vw->vw_number - 1) % VT_MAXWINDOWS;
 			vw = vd->vd_windows[c];
-			if (vw != NULL)
-vt_proc_window_switch(vw);
+			vt_proc_window_switch(vw);
 			return (0);
 		case SLK: {
 			vt_save_kbd_state(vw, kbd);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Build failed in Jenkins: FreeBSD_HEAD #2742

[jenkins-admin]

See 

Changes:

[adrian] Add initial memory locality cost awareness to the VM, and include
a basic ACPI SLIT table parser.

For now this just exports the map via sysctl; it'll eventually be useful
to userland when there's more useful NUMA support in -HEAD.

* Add an optional mem_locality map;
* add a mapping function taking from/to domain and returning the
  relative cost, or -1 if it's not available;
* Add a very basic SLIT parser to x86 ACPI.

Differential Revision:  https://reviews.freebsd.org/D2460
Reviewed by:rpaulo, stas, jhb
Sponsored by:   Norse Corp, Inc (hardware, coding); Dell (hardware)

[delphij] MFV r282611: netcat from OpenBSD 5.7.

MFC after:  2 weeks

--
[...truncated 277250 lines...]
--- drm_dma.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 

 -I. -I -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I
  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso
 9899:1999 -c 

 -o drm_dma.o
--- all_subdir_i915kms ---
ctfconvert -L VERSION -g i915_gem_context.o
--- all_subdir_drm ---
ctfconvert -L VERSION -g drm_mm.o
--- drm_pci.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 

 -I. -I -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I
  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso
 9899:1999 -c 

 -o drm_pci.o
--- all_subdir_drm2 ---
--- i915_gem_execbuffer.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 

 -I. -I -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I
  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso
 9899:1999 -c 

 -o i915_gem_execbuffer.o
--- all_subdir_drm2 ---
ctfconvert -L VERSION -g drm_dma.o
--- all_subdir_dtrace ---
--- dtmalloc.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
-I 
-I
 -I 
-DHAVE_KERNEL_OPTION_HEADERS -include 

Re: What to do about RCS/OpenRCS

[Doug Brewer]

 On Thu, May 07, 2015 at 04:18:38PM -0700, NGie Cooper wrote:
>
> On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni  wrote:
> > Hello;
> >
> > On 05/07/15 14:56, Lyndon Nerenberg wrote:
> >>
> >> On Thu, 7 May 2015, Pedro Giffuni wrote:
> >>
> >>> Unfortunately I don't use RCS enough (it looks like I should though)
so
> >>> I am not in a good position to take the next step and deal with any
> >>> fallout it may produce.
> >>
> >>
> >> If we can have a build-knob to disable GNU RCS and enable the new one
I
> >> will happily twist up the new version and hammer on it.
> >>
> >
> > Yes, that's usually the next step in the process. It is a little bit
messy
> > because
> > there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
> > perhaps something else that we don't use).
> >
> > I really want to check out first if there is some strong opinion
against
> > OpenRCS. Perhaps someone that has used it before and thinks it is a
> > bad idea.
> >
> > It looks like there are voices against it, so those have to be
addressed
> > first.
>
> Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs
> bits); check with jhb first to make sure that OpenRCS works with
> etcupdate.

Confirmed.  Pedro, are you also willing to fix fallout as Xin Li pointed
out?
If not, please revert, thanks.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: What to do about RCS/OpenRCS

[Pedro Giffuni]

> Il giorno 08/mag/2015, alle ore 00:26, Doug Brewer  ha 
> scritto:
> 
> On Thu, May 07, 2015 at 04:18:38PM -0700, NGie Cooper wrote: 
> > 
> > On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni  > > wrote: 
> > > Hello; 
> > > 
> > > On 05/07/15 14:56, Lyndon Nerenberg wrote: 
> > >> 
> > >> On Thu, 7 May 2015, Pedro Giffuni wrote: 
> > >> 
> > >>> Unfortunately I don't use RCS enough (it looks like I should though) so 
> > >>> I am not in a good position to take the next step and deal with any 
> > >>> fallout it may produce. 
> > >> 
> > >> 
> > >> If we can have a build-knob to disable GNU RCS and enable the new one I 
> > >> will happily twist up the new version and hammer on it. 
> > >> 
> > > 
> > > Yes, that's usually the next step in the process. It is a little bit 
> > > messy 
> > > because 
> > > there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and 
> > > perhaps something else that we don't use). 
> > >
> > > I really want to check out first if there is some strong opinion against 
> > > OpenRCS. Perhaps someone that has used it before and thinks it is a 
> > > bad idea. 
> > > 
> > > It looks like there are voices against it, so those have to be addressed 
> > > first. 
> > 
> > Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs 
> > bits); check with jhb first to make sure that OpenRCS works with 
> > etcupdate. 
> 
> Confirmed.  Pedro, are you also willing to fix fallout as Xin Li pointed out? 
> If not, please revert, thanks.


I haven’t committed anything to base so there’s nothing to revert (?).

Pedro.
> 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Build failed in Jenkins: FreeBSD_HEAD_i386 #98

[jenkins-admin]

See 

Changes:

[adrian] Add initial memory locality cost awareness to the VM, and include
a basic ACPI SLIT table parser.

For now this just exports the map via sysctl; it'll eventually be useful
to userland when there's more useful NUMA support in -HEAD.

* Add an optional mem_locality map;
* add a mapping function taking from/to domain and returning the
  relative cost, or -1 if it's not available;
* Add a very basic SLIT parser to x86 ACPI.

Differential Revision:  https://reviews.freebsd.org/D2460
Reviewed by:rpaulo, stas, jhb
Sponsored by:   Norse Corp, Inc (hardware, coding); Dell (hardware)

--
[...truncated 203904 lines...]
ctfmerge -L VERSION -g -o t4_tom.kld t4_connect.o t4_cpl_io.o t4_ddp.o 
t4_listen.o t4_tom.o t4_tom_l2t.o
--- all_subdir_drm ---
--- drm_lock.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 

 -I. -I -fno-common 
-g 
-I
  -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector 
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso9899:1999 -c 
 -o drm_lock.o
--- all_subdir_cxgbe ---
:> export_syms
awk -f 
 
t4_tom.kld  export_syms | xargs -J% objcopy % t4_tom.kld
--- t4_tom.ko.debug ---
ld -Bshareable -d -warn-common -o t4_tom.ko.debug t4_tom.kld
--- t4_tom.ko.symbols ---
objcopy --only-keep-debug t4_tom.ko.debug t4_tom.ko.symbols
--- t4_tom.ko ---
objcopy --strip-debug --add-gnu-debuglink=t4_tom.ko.symbols t4_tom.ko.debug 
t4_tom.ko
--- all_subdir_drm2 ---
--- all_subdir_i915kms ---
===> drm2/i915kms (all)
--- i915_debug.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 

 -I. -I -fno-common 
-g 
-I
  -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector 
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-unused-function -mno-aes -mno-avx  
-std=iso9899:1999 -c  
-o i915_debug.o
--- all_subdir_drm ---
ctfconvert -L VERSION -g drm_lock.o
--- all_subdir_drm2 ---
--- all_subdir_drm2 ---
ctfconvert -L VERSION -g drm_crtc_helper.o
--- all_subdir_drm ---
--- drm_memory.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 

 -I. -I -fno-common 
-g 
-I
  -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector 
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso9899:1999 -c 
 -o drm_memory.o
--- all_subdir_drm2 ---
--- drm_dma.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D

Re: Build failed in Jenkins: FreeBSD_HEAD_i386 #98

[Adrian Chadd]

[snip]

fixed!


-a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"