date:20170118


On 19/01/2017 11:18 AM, Julian Elischer wrote:

On 19/01/2017 1:37 AM, Adam Weinberger wrote:
On 18 Jan, 2017, at 10:35, Julian Elischer  
wrote:


On 17/01/2017 1:23 AM, Adam Weinberger wrote:
On 16 Jan, 2017, at 9:25, Baptiste Daroussin  
wrote:


On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
I noticed that suddenly vim is grabbing mouse movements, which 
makes life

really hard.

Was there a specific revision that brought in this change, and 
can it be

removed?
This change appeared in one of the last patchset of vim 7.4 and 
was one of the

"features" of the vim 8.0 release.

I do agree this is just totally painful :(

Best regards,
Bapt
One of the things that I inherited with the Vim port was the 
DEFAULT_VIMRC option (which installs 
/usr/ports/editors/vim/files/vimrc), and I haven't touched it.


I have moused disabled in all my boxes so I have no idea about 
bad mouse behaviour in Vim. If there is a bad default that is 
causing grief, let's just fix it in that default vimrc.


I'm not really understanding what the unexpected behaviour is so 
I can't make an intelligent recommendation myself, but I'll go 
with whatever you folks suggest.


# Adam

I'm in iterm on my mac.
I ssh to a freebsd machine
I use vim on a file.
I used to be able to use the mouse on my mac to copy a few lines 
into the cut buffer.. slide-shift-click etc..
now suddenly if I try highlight some code in vim to copy it vim 
drags stuff around, scrolls up and down, deletes stuff and 
generally makes a mess.

if click, instead of starting a copy zone it grabs some of the text.

basically it makes hte mouse useless.
I can;t copy and paste from a file I'm ediitng. I end up having to 
exit vim and do it in vi.
There have been a number of recommendations in this thread for you, 
Julian, including "set mouse=a" and "set mouse=v". Test some of 
them out and let me know what works for you.


actually I never saw one about mouse=a however I did see and try 
mouse=v which didn't work for me.


I have now tried mouse=a and am happy to say that that does what I 
need.

thanks!


actually no, 'set mouse='
seems to be what I want.. not sure why I thought =a worked:




# Adam




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




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

Re: recent change to vim defaults?

On 19/01/2017 1:37 AM, Adam Weinberger wrote:

On 18 Jan, 2017, at 10:35, Julian Elischer wrote:

On 17/01/2017 1:23 AM, Adam Weinberger wrote:

On 16 Jan, 2017, at 9:25, Baptiste Daroussin wrote:

On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:

I noticed that suddenly vim is grabbing mouse movements, which makes life
really hard.

Was there a specific revision that brought in this change, and can it be
removed?

This change appeared in one of the last patchset of vim 7.4 and was one of the
"features" of the vim 8.0 release.

I do agree this is just totally painful :(

Best regards,
Bapt

One of the things that I inherited with the Vim port was the DEFAULT_VIMRC
option (which installs /usr/ports/editors/vim/files/vimrc), and I haven't
touched it.

I have moused disabled in all my boxes so I have no idea about bad mouse
behaviour in Vim. If there is a bad default that is causing grief, let's just
fix it in that default vimrc.

I'm not really understanding what the unexpected behaviour is so I can't make
an intelligent recommendation myself, but I'll go with whatever you folks
suggest.

# Adam

I'm in iterm on my mac.
I ssh to a freebsd machine
I use vim on a file.
I used to be able to use the mouse on my mac to copy a few lines into the cut
buffer.. slide-shift-click etc..
now suddenly if I try highlight some code in vim to copy it vim drags stuff
around, scrolls up and down, deletes stuff and generally makes a mess.
if click, instead of starting a copy zone it grabs some of the text.

basically it makes hte mouse useless.
I can;t copy and paste from a file I'm ediitng. I end up having to exit vim and
do it in vi.

There have been a number of recommendations in this thread for you, Julian, including "set
mouse=a" and "set mouse=v". Test some of them out and let me know what works for you.

actually I never saw one about mouse=a however I did see and try
mouse=v which didn't work for me.

I have now tried mouse=a and am happy to say that that does what I need.
thanks!

# Adam

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

Re: ISO image: where is the CLANG compiler?

2017-01-18 Thread Allan Jude

On 2017-01-18 14:37, O. Hartmann wrote:
> Am Wed, 18 Jan 2017 16:38:32 +0100
> Matthias Apitz  schrieb:
> 
>> Why you do not just boot from USB some mem stick image, mount some disk
>> space to /mnt, svn checkout CURRENT to /mnt and build a booteable system
>> (world and kernel) and install to DESTDIR=/mnt ?
>>
>> I do not understand all this hassle?
>>
>>  matthias
>>
> 
> Wow!
> 
> As I initially stated, that is EXACTLY what I was inclined to do except the 
> fact that I
> had already an intact /usr/obj and usr/src with a complete compiled system.
> 
> I booted from mem stick and I was lost due to no cc!
> 
> Even for "make installworld" it seems I have to rely on the compiler. And the 
> images
> (ISO, memstick et cetera) provided these days do not contain any clang.
> 
> So, I tried /usr/src/release ... for the first time. The image does also not 
> contain the
> necessary tools for a full "make installworld installkernel" - not to speak of
> "compiling" world. I dodn't work (at least for me). 
> 
> I try to figure out how to avoid this crazy and useless shrinking of the ISO 
> images -
> somehow when building NanoBSD, there are knobs with which we can prevent the 
> build and/or
> installation of subsets like compiler, toolchain et cetera. The way such 
> thing is
> provided via src.conf and make.conf is fine and sophisticated. But "RELEASE" 
> seems to
> handle things different, and the standard is useless for a rescue mission.
> 
> So far.
> 
> It might be that I have overlooked something ...
> 
> Regards,
> 
> oh
> 

The DVD should still contain clang. Only the smaller images (bootonly,
disc1) should have clang removed.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: ISO image: where is the CLANG compiler?

2017-01-18 Thread Polytropon

On Wed, 18 Jan 2017 20:37:26 +0100, O. Hartmann wrote:
> Am Wed, 18 Jan 2017 16:38:32 +0100
> Matthias Apitz  schrieb:
> 
> > Why you do not just boot from USB some mem stick image, mount some disk
> > space to /mnt, svn checkout CURRENT to /mnt and build a booteable system
> > (world and kernel) and install to DESTDIR=/mnt ?
> > 
> > I do not understand all this hassle?
> > 
> > matthias
> > 
> 
> Wow!
> 
> As I initially stated, that is EXACTLY what I was inclined to do except
> the fact that I
> had already an intact /usr/obj and usr/src with a complete compiled system.
> 
> I booted from mem stick and I was lost due to no cc!

That is the core problem here: cc is not contained in the USB
(memstick) image. It _might_ be contained on the live system
media, but I'm not sure about this...

> Even for "make installworld" it seems I have to rely on the compiler.
> And the images
> (ISO, memstick et cetera) provided these days do not contain any clang.

Then there would be at least the following option:

>From the installation media, you can manually extract the
distribution files for the base system and use their content
to overwrite your non-functional (zero size) files on disk.
The task here is to perform archive extraction, and the
extractor should be there (simply because the installer uses
it as well). With those tools established, you can recompile
your system, or "make installworld" from the already populated
/usr/obj subtree. Of course, you need to pay attention to
have the _correct_ version.

> I try to figure out how to avoid this crazy and useless shrinking
> of the ISO images -
> somehow when building NanoBSD, there are knobs with which we can
> prevent the build and/or
> installation of subsets like compiler, toolchain et cetera. The way
> such thing is
> provided via src.conf and make.conf is fine and sophisticated. But
> "RELEASE" seems to
> handle things different, and the standard is useless for a rescue
> mission.

So having a more or less complete (!) live system image (for CD
or DVD, depending on result size) would probably be a good idea
and a versatile tool in case of emergencies.

The size limitations, in my opinion, are okay for CD media (650 MB)
and DVD media (4,7 GB), but for USB media, I don't see a significant
problem making the image 4 or even 8 GB in size. It's actually quite
complicated to buy smaller USB sticks or SD cards (sizes < 4 GB)
for the few devices they are still required...

FreeBSD has always been a "self-contained" system that could
"reproduce itself", given that all the sources and the compilation
tools were included with the OS. This should be an important goal
to achieve with a USB-based _live_ system, and even if you run
it from slow USB (instead of fast HDD or SSD), there are still
situations where those systems can prevent you from a complete
system re-installation. Additionally, USB provides permanent
storage (which CDs and DVDs obviously do not).

Of course you can more or less manually create such a live media
and prepare an image for it, but it would be really nice if such
an image would be provided for download. I imagine the initial
tasks to be mostly a buildworld/installword into a custom root
directory and then creating an image from it, prepending it with
the typical boot loader so it becomes a "disk image" (USB image,
of course).

> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).

"Das interessiert uns nicht!" - gez. die Werbewirtschaft. :-)

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build failure 'wmmintrin.h' file not found

2017-01-18 Thread Warner Losh

On Wed, Jan 18, 2017 at 1:21 PM, Dimitry Andric  wrote:
> On 18 Jan 2017, at 14:42, Magnus Ringman  wrote:
>>
>> On Wed, Jan 18, 2017 at 2:16 PM, Hans Petter Selasky 
>> wrote:
> ...
>>> And the error popped out. I'm not observing this error when building a
>>> 12-current kernel from an 11-stable install.
>>
>>
>> Isn't it all bets are off if going to -current from anything but most
>> recent -stable?

Nope. There's a range of supported major branches. This has been the
case for at least 15 years. Typically, we've supported 2-4 old
branches building current due to the needs of the FreeBSD community
and that community making sure it works often enough that we don't
just shut the door to it entirely. Each individual developer only
needs to test the latest branch, but that's not the same as what's
supported. From time to time we bump the minimum system, but it isn't
in lock step with the major branches.

>> Recommended practice[citation needed] would be
>> 10-stable->11-stable->12-current.
>
> That is the safest way, indeed.  But it should not be totally impossible
> to build recent versions of -current on 10.x.

We support building world on 10.3 and newer for -current today. There
were compiler changes to fix bad code generation between 10.2 and
10.3, however, so the usual "any stable-10' is no longer the case. In
fact, it's still supported building from the tip of stable/9 for
current. However, the same compiler bug is not fixed in the last 9.x
release, so there the upgrade is needed.

> Normally, buildworld takes care of the heavy lifting by building all the
> needed tools first.  But if you build only parts of the tree, you might
> encounter "interesting" situations. :)

Anything less than buildworld is defintely not supported when the host
system isn't completely up to date. Well, make kernel-toolchain is
sufficient for make buildkernel.

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

Re: ASLR

2017-01-18 Thread Piotr Kubaj

It should also be stated properly that this patch doesn't implement ASLR, but 
ASR.


signature.asc
Description: PGP signature

Re: ISO image: where is the CLANG compiler?

2017-01-18 Thread Matthias Apitz


(I adjuested To/cc)

El día Wednesday, January 18, 2017 a las 08:37:26PM +0100, O. Hartmann escribió:

> Wow!
> 
> As I initially stated, that is EXACTLY what I was inclined to do except the 
> fact that I
> had already an intact /usr/obj and usr/src with a complete compiled system.
> 
> I booted from mem stick and I was lost due to no cc!
> 
> Even for "make installworld" it seems I have to rely on the compiler. And the 
> images
> (ISO, memstick et cetera) provided these days do not contain any clang.
> 
> So, I tried /usr/src/release ... for the first time. The image does also not 
> contain the
> necessary tools for a full "make installworld installkernel" - not to speak of
> "compiling" world. I dodn't work (at least for me). 

What gives:

# rm -r /usr/obj
# cd /usr/src
# make buildworld
# make buildkernel

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
"Wo ist der antiimperialistische Schutzwall, wenn man ihn braucht? 
US-Panzertransport durch ex-DDR"
"Where is the anti-imperialistic  wall, if it's needed? Transport of US-tanks 
through the ex-GDR"
https://deutsch.rt.com/kurzclips/45282-us-panzertransporte-durch-ex-ddr/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build failure 'wmmintrin.h' file not found

2017-01-18 Thread Dimitry Andric

On 18 Jan 2017, at 14:42, Magnus Ringman  wrote:
> 
> On Wed, Jan 18, 2017 at 2:16 PM, Hans Petter Selasky 
> wrote:
...
>> And the error popped out. I'm not observing this error when building a
>> 12-current kernel from an 11-stable install.
> 
> 
> Isn't it all bets are off if going to -current from anything but most
> recent -stable?
> Recommended practice[citation needed] would be
> 10-stable->11-stable->12-current.

That is the safest way, indeed.  But it should not be totally impossible
to build recent versions of -current on 10.x.

Normally, buildworld takes care of the heavy lifting by building all the
needed tools first.  But if you build only parts of the tree, you might
encounter "interesting" situations. :)

-Dimitry

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Build failure 'wmmintrin.h' file not found

2017-01-18 Thread Dimitry Andric

On 18 Jan 2017, at 14:16, Hans Petter Selasky  wrote:
> 
> On 01/18/17 14:13, Dimitry Andric wrote:
>> On 18 Jan 2017, at 13:36, Hans Petter Selasky  wrote:
>>> 
>>> I'm seeing the following build-error trying to build 12-current from 
>>> 10-stable:
>>> 
>>> xxx/freebsd/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 
>>> 'wmmintrin.h' file not found
>>> #include 
>>> 
>>> Missing header exists:
>>> 
>>> xxx/freebsd/contrib/llvm/tools/clang/lib/Headers/wmmintrin.h
>>> 
>>> Missing include directory or compiler magic?
>> 
>> What are you building, and how?  Did you do a buildworld before buildkernel?
>> 
>> -Dimitry
>> 
> 
> I did:
> 
> make toolchain -jXX
> 
> And then:
> 
> make buildkernel -jXX
> 
> And the error popped out.

As far as I can see, the toolchain target does not install headers and
libraries.  Can you try the kernel-toolchain target instead?


> I'm not observing this error when building a 12-current kernel from an 
> 11-stable install.

Probably not, because you will be using /usr/bin/cc, and the wmmintrin.h
header in the base system.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: crash in iflib_fast_intr

2017-01-18 Thread Shawn Webb

On Wed, Jan 18, 2017 at 07:31:12AM -0700, Sean Bruno wrote:
> 
> 
> On 01/18/17 03:37, peter.b...@bsd4all.org wrote:
> > Hi,
> > 
> > A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since 
> > GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is 
> > reproducible.
> > 
> > KDB: stack backtrace:
> > #0 0x805cec97 at kdb_backtrace+0x67
> > #1 0x80584816 at vpanic+0x186
> > #2 0x80584683 at panic+0x43
> > #3 0x8090f222 at trap_fatal+0x322
> > #4 0x8090f3ec at trap_pfault+0x1bc
> > #5 0x8090eaa0 at trap+0x280
> > #6 0x808f35e1 at calltrap+0x8
> > #7 0x806a202d at iflib_fast_intr+0x3d
> > #8 0x8054963b at intr_event_handle+0x9b
> > #9 0x80965f38 at intr_execute_handlers+0x48
> > #10 0x8096b1cf at lapic_handle_intr+0x3f
> > #11 0x808f3cc7 at Xapic_isr1+0xb7
> > #12 0x805b994a at sched_idletd+0x37a
> > #13 0x805460f5 at fork_exit+0x85
> > #14 0x808f3b1e at fork_trampoline+0xe
> > 
> > Peter
> 
> Thanks for the report.  We're looking at this.
> 
> This is with an igb(4) interface or em(4)?
> 
> sean
> 

I'm getting something similar with em(4):

https://goo.gl/photos/MXiFXtatBYcWagJTA

I'm at this commit in HardenedBSD:

https://github.com/HardenedBSD/hardenedBSD/commit/2108b0d56984115eb52e72bd16539071064b348e

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: ISO image: where is the CLANG compiler?

Am Wed, 18 Jan 2017 16:38:32 +0100
Matthias Apitz  schrieb:

> Why you do not just boot from USB some mem stick image, mount some disk
> space to /mnt, svn checkout CURRENT to /mnt and build a booteable system
> (world and kernel) and install to DESTDIR=/mnt ?
> 
> I do not understand all this hassle?
> 
>   matthias
> 

Wow!

As I initially stated, that is EXACTLY what I was inclined to do except the 
fact that I
had already an intact /usr/obj and usr/src with a complete compiled system.

I booted from mem stick and I was lost due to no cc!

Even for "make installworld" it seems I have to rely on the compiler. And the 
images
(ISO, memstick et cetera) provided these days do not contain any clang.

So, I tried /usr/src/release ... for the first time. The image does also not 
contain the
necessary tools for a full "make installworld installkernel" - not to speak of
"compiling" world. I dodn't work (at least for me). 

I try to figure out how to avoid this crazy and useless shrinking of the ISO 
images -
somehow when building NanoBSD, there are knobs with which we can prevent the 
build and/or
installation of subsets like compiler, toolchain et cetera. The way such thing 
is
provided via src.conf and make.conf is fine and sophisticated. But "RELEASE" 
seems to
handle things different, and the standard is useless for a rescue mission.

So far.

It might be that I have overlooked something ...

Regards,

oh

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpJx4WNYWLWr.pgp
Description: OpenPGP digital signature

Re: r311568 makes freerdp very slow

2017-01-18 Thread Ultima

I have been affected by this issue as well, just updated to r312388 and it
is fixed. Thanks

On Wed, Jan 18, 2017 at 1:29 PM, John Baldwin  wrote:

> On Tuesday, January 17, 2017 01:46:31 PM Jakob Alvermark wrote:
> > On Fri, January 13, 2017 22:46, Jakob Alvermark wrote:
> > > On Fri, January 13, 2017 19:44, John Baldwin wrote:
> > >
> > >> On Friday, January 13, 2017 09:58:01 AM Jakob Alvermark wrote:
> > >>
> > >>
> > >>> On Thu, January 12, 2017 19:26, John Baldwin wrote:
> > >>>
> > >>>
> >  On Thursday, January 12, 2017 12:42:11 PM Shawn Webb wrote:
> > 
> > 
> > 
> > > On Thu, Jan 12, 2017 at 06:05:08PM +0100, Jakob Alvermark wrote:
> > >
> > >
> > >
> > >> Hi,
> > >>
> > >>
> > >>
> > >>
> > >> r311568 Set MORETOCOME for AIO write requests on a socket.
> > >>
> > >> After this commit freerdp is very slow.
> > >>
> > >>
> > >>
> > >>
> > >> Before the password prompt would appear immediately when
> > >> connecting to a server. Now it takes 5-10 seconds. After
> > >> entering the password, another 5-10 seconds until I am
> > >> connected. Once connected, there is a considerable lag.
> > >>
> > >>
> > >> What could be the problem?
> > >>
> > >>
> > >>
> > >
> > > I don't know what the problem is, but I am seeing the same
> > > symptom.
> > >
> > >
> > 
> >  Can you get a ktrace of the freerdp process during this?  The
> >  commit should only be setting MORETOCOME if multiple aio_write
> >  requests are queued to the same socket (so that TCP can batch them
> >  into a single packet). However, it should not affect an application
> >  just calling aio_write() on a socket once.
> > 
> >  --
> >  John Baldwin
> > 
> > 
> > >>>
> > >>> Hi John,
> > >>>
> > >>>
> > >>>
> > >>> I got the ktrace, what do I do with it?
> > >>>
> > >>>
> > >>
> > >> kdump will generate a text representation, perhaps using 'kdump -s' to
> > >> not include dumps of raw I/O data.  If you can put the output of kdump
> > >> at a URL I can fetch from then I can look at it.
> > >>
> > >
> > > OK, here it is: http://filebin.ca/38mkuLau9Yqu/ktrace.out.xfreerdp.txt
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Jakob
> >
> > Hi,
> >
> > Did you get any chance to look at this?
>
> I have not yet, but can you please try the fix in r312387?
>
> --
> John Baldwin
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: recent change to vim defaults?

2017-01-18 Thread Pete Wright




On 1/18/17 10:24 AM, Alexander Kabaev wrote:

On Wed, 18 Jan 2017 10:06:55 -0800
Pete Wright  wrote:


On 1/18/17 10:01 AM, Julian Elischer wrote:

On 18/01/2017 5:03 PM, Raimund Sacherer wrote:

I have to put mouse=v to get the behavior I am used to.

Best


doesn't really work for me.

vim is still taking mouse events



kinda feel like it we need a "classic" vim port that is from the v7.x
codebase since i suspect the changes to mouse behaviour in v8.x is
only the beginning of lots of suspect changes to the vim codebase :/

i went through the code for vim the other day and couldn't figure out
a way to disable entering visual-mode via mouseclick as a compile
time option.  perhaps we should preserve the expected behaviour by
updating /usr/local/etc/vim/vimrc?




I just applied this diff against my global vimrc file and it now 
disables the visual mode by default function:


$ diff -u vimrc.sample vimrc
--- vimrc.sample2017-01-13 22:39:36.0 -0800
+++ vimrc   2017-01-18 10:51:48.020039000 -0800
@@ -3,10 +3,10 @@
 endif

 let g:is_posix = 1
-set nocompatible
 set bs=indent,eol,start
 set history=50
 set ruler
+set mouse-=a

 if _Co > 2 || has("gui_running")
syntax on



I'm not %100 clear why it was setting "nocompatible" - but once I 
removed it it disabled visual-mode-on-mouse-click.  I'll be managing 
this on my systems via our cfg mgmt systems but it'd be super if this, 
or something similar, was the default.


-pete

--
Pete Wright
p...@nomadlogic.org
nomadlogicLA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ASLR

2017-01-18 Thread Conrad Meyer

On Wed, Jan 18, 2017 at 9:53 AM, Johannes Lundberg  wrote:
> Hi
>
> What is the status of ASLR?
>
> https://reviews.freebsd.org/D5603
>
> The thread has been silent for a couple of months. I'm happy to test if
> needed.

Hi Johannes,

I think we were waiting on some review, but if that has stalled out,
let's go ahead and commit it.  Default off is fine for now.  It can be
improved as needed and then we at least have an ASLR story for the
checkbox users.

> I'm also interested in KASLR. Is that also on the roadmap? If someone
> involved could share some info I'd be grateful.

KASLR is less useful (grsecurity folks might say useless) — see
https://forums.grsecurity.net/viewtopic.php?f=7=3367 for some
discussion on it.

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

Re: r311568 makes freerdp very slow

2017-01-18 Thread John Baldwin

On Tuesday, January 17, 2017 01:46:31 PM Jakob Alvermark wrote:
> On Fri, January 13, 2017 22:46, Jakob Alvermark wrote:
> > On Fri, January 13, 2017 19:44, John Baldwin wrote:
> >
> >> On Friday, January 13, 2017 09:58:01 AM Jakob Alvermark wrote:
> >>
> >>
> >>> On Thu, January 12, 2017 19:26, John Baldwin wrote:
> >>>
> >>>
>  On Thursday, January 12, 2017 12:42:11 PM Shawn Webb wrote:
> 
> 
> 
> > On Thu, Jan 12, 2017 at 06:05:08PM +0100, Jakob Alvermark wrote:
> >
> >
> >
> >> Hi,
> >>
> >>
> >>
> >>
> >> r311568 Set MORETOCOME for AIO write requests on a socket.
> >>
> >> After this commit freerdp is very slow.
> >>
> >>
> >>
> >>
> >> Before the password prompt would appear immediately when
> >> connecting to a server. Now it takes 5-10 seconds. After
> >> entering the password, another 5-10 seconds until I am
> >> connected. Once connected, there is a considerable lag.
> >>
> >>
> >> What could be the problem?
> >>
> >>
> >>
> >
> > I don't know what the problem is, but I am seeing the same
> > symptom.
> >
> >
> 
>  Can you get a ktrace of the freerdp process during this?  The
>  commit should only be setting MORETOCOME if multiple aio_write
>  requests are queued to the same socket (so that TCP can batch them
>  into a single packet). However, it should not affect an application
>  just calling aio_write() on a socket once.
> 
>  --
>  John Baldwin
> 
> 
> >>>
> >>> Hi John,
> >>>
> >>>
> >>>
> >>> I got the ktrace, what do I do with it?
> >>>
> >>>
> >>
> >> kdump will generate a text representation, perhaps using 'kdump -s' to
> >> not include dumps of raw I/O data.  If you can put the output of kdump
> >> at a URL I can fetch from then I can look at it.
> >>
> >
> > OK, here it is: http://filebin.ca/38mkuLau9Yqu/ktrace.out.xfreerdp.txt
> >
> >
> > Thanks,
> >
> >
> > Jakob
> 
> Hi,
> 
> Did you get any chance to look at this?

I have not yet, but can you please try the fix in r312387?

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

Re: recent change to vim defaults?

2017-01-18 Thread Alexander Kabaev

On Wed, 18 Jan 2017 10:06:55 -0800
Pete Wright  wrote:

> On 1/18/17 10:01 AM, Julian Elischer wrote:
> > On 18/01/2017 5:03 PM, Raimund Sacherer wrote:  
> >> I have to put mouse=v to get the behavior I am used to.
> >>
> >> Best  
> >
> > doesn't really work for me.
> >
> > vim is still taking mouse events
> >  
> 
> kinda feel like it we need a "classic" vim port that is from the v7.x 
> codebase since i suspect the changes to mouse behaviour in v8.x is
> only the beginning of lots of suspect changes to the vim codebase :/
> 
> i went through the code for vim the other day and couldn't figure out
> a way to disable entering visual-mode via mouseclick as a compile
> time option.  perhaps we should preserve the expected behaviour by
> updating /usr/local/etc/vim/vimrc?
> 
> -p
> 
> 
> -- 
> Pete Wright
> p...@nomadlogic.org
> nomadlogicLA

What we need, IMHO, of course, is to stop jamming _example_ config file
down everyone's throat. Not even Linux does install that file unchanged.

-- 
Alexander Kabaev


pgpHx_puTsrm7.pgp
Description: Цифровая подпись OpenPGP

Re: recent change to vim defaults?

2017-01-18 Thread Pete Wright




On 1/18/17 10:01 AM, Julian Elischer wrote:

On 18/01/2017 5:03 PM, Raimund Sacherer wrote:

I have to put mouse=v to get the behavior I am used to.

Best


doesn't really work for me.

vim is still taking mouse events



kinda feel like it we need a "classic" vim port that is from the v7.x 
codebase since i suspect the changes to mouse behaviour in v8.x is only 
the beginning of lots of suspect changes to the vim codebase :/


i went through the code for vim the other day and couldn't figure out a 
way to disable entering visual-mode via mouseclick as a compile time 
option.  perhaps we should preserve the expected behaviour by updating 
/usr/local/etc/vim/vimrc?


-p


--
Pete Wright
p...@nomadlogic.org
nomadlogicLA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: recent change to vim defaults?

2017-01-18 Thread Adam Weinberger

> On 18 Jan, 2017, at 10:35, Julian Elischer  wrote:
> 
> On 17/01/2017 1:23 AM, Adam Weinberger wrote:
>>> On 16 Jan, 2017, at 9:25, Baptiste Daroussin  wrote:
>>> 
>>> On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
 I noticed that suddenly vim is grabbing mouse movements, which makes life
 really hard.
 
 Was there a specific revision that brought in this change, and can it be
 removed?
>>> This change appeared in one of the last patchset of vim 7.4 and was one of 
>>> the
>>> "features" of the vim 8.0 release.
>>> 
>>> I do agree this is just totally painful :(
>>> 
>>> Best regards,
>>> Bapt
>> One of the things that I inherited with the Vim port was the DEFAULT_VIMRC 
>> option (which installs /usr/ports/editors/vim/files/vimrc), and I haven't 
>> touched it.
>> 
>> I have moused disabled in all my boxes so I have no idea about bad mouse 
>> behaviour in Vim. If there is a bad default that is causing grief, let's 
>> just fix it in that default vimrc.
>> 
>> I'm not really understanding what the unexpected behaviour is so I can't 
>> make an intelligent recommendation myself, but I'll go with whatever you 
>> folks suggest.
>> 
>> # Adam
> I'm in iterm on my mac.
> I ssh to a freebsd machine
> I use vim on a file.
> I used to be able to use the mouse on my mac to copy a few lines into the cut 
> buffer.. slide-shift-click etc..
> now suddenly if I try highlight some code in vim to copy it vim drags stuff 
> around, scrolls up and down, deletes stuff and generally makes a mess.
> if click, instead of starting a copy zone it grabs some of the text.
> 
> basically it makes hte mouse useless.
> I can;t copy and paste from a file I'm ediitng. I end up having to exit vim 
> and do it in vi.

There have been a number of recommendations in this thread for you, Julian, 
including "set mouse=a" and "set mouse=v". Test some of them out and let me 
know what works for you.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org


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

Re: recent change to vim defaults?


On 18/01/2017 5:03 PM, Raimund Sacherer wrote:

I have to put mouse=v to get the behavior I am used to.

Best


doesn't really work for me.

vim is still taking mouse events


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

ASLR

2017-01-18 Thread Johannes Lundberg

Hi

What is the status of ASLR?

https://reviews.freebsd.org/D5603

The thread has been silent for a couple of months. I'm happy to test if
needed.


I'm also interested in KASLR. Is that also on the roadmap? If someone
involved could share some info I'd be grateful.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: recent change to vim defaults?

2017-01-18 Thread Baptiste Daroussin

On Wed, Jan 18, 2017 at 10:37:32AM -0700, Adam Weinberger wrote:
> > On 18 Jan, 2017, at 10:35, Julian Elischer  wrote:
> > 
> > On 17/01/2017 1:23 AM, Adam Weinberger wrote:
> >>> On 16 Jan, 2017, at 9:25, Baptiste Daroussin  wrote:
> >>> 
> >>> On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
>  I noticed that suddenly vim is grabbing mouse movements, which makes life
>  really hard.
>  
>  Was there a specific revision that brought in this change, and can it be
>  removed?
> >>> This change appeared in one of the last patchset of vim 7.4 and was one 
> >>> of the
> >>> "features" of the vim 8.0 release.
> >>> 
> >>> I do agree this is just totally painful :(
> >>> 
> >>> Best regards,
> >>> Bapt
> >> One of the things that I inherited with the Vim port was the DEFAULT_VIMRC 
> >> option (which installs /usr/ports/editors/vim/files/vimrc), and I haven't 
> >> touched it.
> >> 
> >> I have moused disabled in all my boxes so I have no idea about bad mouse 
> >> behaviour in Vim. If there is a bad default that is causing grief, let's 
> >> just fix it in that default vimrc.
> >> 
> >> I'm not really understanding what the unexpected behaviour is so I can't 
> >> make an intelligent recommendation myself, but I'll go with whatever you 
> >> folks suggest.
> >> 
> >> # Adam
> > I'm in iterm on my mac.
> > I ssh to a freebsd machine
> > I use vim on a file.
> > I used to be able to use the mouse on my mac to copy a few lines into the 
> > cut buffer.. slide-shift-click etc..
> > now suddenly if I try highlight some code in vim to copy it vim drags stuff 
> > around, scrolls up and down, deletes stuff and generally makes a mess.
> > if click, instead of starting a copy zone it grabs some of the text.
> > 
> > basically it makes hte mouse useless.
> > I can;t copy and paste from a file I'm ediitng. I end up having to exit vim 
> > and do it in vi.
> 
> There have been a number of recommendations in this thread for you, Julian, 
> including "set mouse=a" and "set mouse=v". Test some of them out and let me 
> know what works for you.

set mouse=
(with nothing) brings back the original behaviour

Bapt


signature.asc
Description: PGP signature

Re: recent change to vim defaults?


On 17/01/2017 1:23 AM, Adam Weinberger wrote:

On 16 Jan, 2017, at 9:25, Baptiste Daroussin  wrote:

On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:

I noticed that suddenly vim is grabbing mouse movements, which makes life
really hard.

Was there a specific revision that brought in this change, and can it be
removed?

This change appeared in one of the last patchset of vim 7.4 and was one of the
"features" of the vim 8.0 release.

I do agree this is just totally painful :(

Best regards,
Bapt

One of the things that I inherited with the Vim port was the DEFAULT_VIMRC 
option (which installs /usr/ports/editors/vim/files/vimrc), and I haven't 
touched it.

I have moused disabled in all my boxes so I have no idea about bad mouse 
behaviour in Vim. If there is a bad default that is causing grief, let's just 
fix it in that default vimrc.

I'm not really understanding what the unexpected behaviour is so I can't make 
an intelligent recommendation myself, but I'll go with whatever you folks 
suggest.

# Adam

I'm in iterm on my mac.
I ssh to a freebsd machine
I use vim on a file.
I used to be able to use the mouse on my mac to copy a few lines into 
the cut buffer..  slide-shift-click etc..
now suddenly if I try highlight some code in vim to copy it vim drags 
stuff around, scrolls up and down, deletes stuff and generally makes a 
mess.

if click, instead of starting a copy zone it grabs some of the text.

basically it makes hte mouse useless.
I can;t copy and paste from a file I'm ediitng. I end up having to 
exit vim and do it in vi.







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

Re: Strange issue after early AP startup

2017-01-18 Thread John Baldwin

On Wednesday, January 18, 2017 09:00:52 AM Hans Petter Selasky wrote:
> On 01/18/17 02:18, John Baldwin wrote:
> > You might still want to adjust 'nextevent' to schedule the next interrupt
> > to be sooner than 'timerperiod' though.  You could just set 'nextevent' to
> > 'now' in that case instead of 'next'.
> 
> Right, I'll give that a spin. Would have to be "now + 1" instead of 
> "now", due to check before et_start() ?

Ugh, ok.  + 1 with sbintime_t is kind of odd which is why I would have liked
to avoid it, but it seems it is required.

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

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On Wed, 18 Jan 2017 07:59:17 -0700
Sean Bruno  wrote:

> On 01/18/17 07:41, Sean Bruno wrote:
> > 
> > 
> > On 01/18/17 00:34, O. Hartmann wrote:  
> >> On Thu, 5 Jan 2017 20:17:56 -0700
> >> Sean Bruno  wrote:  
> >>>  
> >> On a Fujitsu Celsius M740, the "em0" device gets stuck on heavy I/O. I can
> >> still trigger this behaviour on recent CURRENT (12.0-CURRENT #17 r312369:
> >> Wed Jan 18 06:18:45 CET 2017 amd64) by rsync'ing a large poudriere ports
> >> repository onto a remote NFSv4 fileserver. The freeze always occur on large
> >> tarballs.
> >>
> >> Again, here is the pciconf output of the device: 
> >>
> >> em0@pci0:0:25:0:class=0x02 card=0x11ed1734 chip=0x153a8086
> >> rev=0x05 hdr=0x00 vendor = 'Intel Corporation'
> >> device = 'Ethernet Connection I217-LM'
> >> class  = network
> >> subclass   = ethernet
> >> bar   [10] = type Memory, range 32, base 0xfb30, size 131072,
> >> enabled bar   [14] = type Memory, range 32, base 0xfb339000, size 4096,
> >> enabled bar   [18] = type I/O Port, range 32, base 0xf020, size 32, enabled
> >>
> >> On another box. equipted with a dual-port Intel i350 NIC, the igb0 and
> >> igb1 do have negotiation problems with several types of switches (in my
> >> SoHo environment, I use a Netgear GS110TP, at work there are several types
> >> of Cisco Catalyst 3XXX types). The igbX very often fall back to 100MBit/s.
> >>
> >> Since yesterday, the igbX on that specific i350 basesd NIC (we have plentz
> >> of them and they show similar phenomena with FreeBSD), although the switch
> >> reports an uplink with 1 GBit, FreeBSD CURRENT shows this weird crap
> >> message: 
> >>> igb0: flags=8843 metric 0 mtu
> >>> 1500
> >>> options=653dbb
> >>> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xff00 broadcast
> >>> 192.168.0.255 nd6 options=29
> >>>media: Ethernet autoselect (100baseTX )
> >>>status: active  
> >>  
> 
> I just checked my test machines (which are auto/auto on the Juniper
> EX4200 switches in use) and I see them come up with 1000baseTX.  Do you
> set any options in /etc/rc.conf?
> 
> sean
> 

No, I don't.

The line is:
ifconfig_igb0="inet 192.168.0.10 netmask 0xff00"

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

Re: ISO image: where is the CLANG compiler?

2017-01-18 Thread Matthias Apitz

Why you do not just boot from USB some mem stick image, mount some disk
space to /mnt, svn checkout CURRENT to /mnt and build a booteable system
(world and kernel) and install to DESTDIR=/mnt ?

I do not understand all this hassle?

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
"Wo ist der antiimperialistische Schutzwall, wenn man ihn braucht? 
US-Panzertransport durch ex-DDR"
"Where is the anti-imperialistic  wall, if it's needed? Transport of US-tanks 
through the ex-GDR"
https://deutsch.rt.com/kurzclips/45282-us-panzertransporte-durch-ex-ddr/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: crash in iflib_fast_intr

2017-01-18 Thread peter . blok

This is with an igb interface.

Peter
> On 18 Jan 2017, at 15:31, Sean Bruno  wrote:
> 
> 
> 
> On 01/18/17 03:37, peter.b...@bsd4all.org  
> wrote:
>> Hi,
>> 
>> A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since 
>> GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is 
>> reproducible.
>> 
>> KDB: stack backtrace:
>> #0 0x805cec97 at kdb_backtrace+0x67
>> #1 0x80584816 at vpanic+0x186
>> #2 0x80584683 at panic+0x43
>> #3 0x8090f222 at trap_fatal+0x322
>> #4 0x8090f3ec at trap_pfault+0x1bc
>> #5 0x8090eaa0 at trap+0x280
>> #6 0x808f35e1 at calltrap+0x8
>> #7 0x806a202d at iflib_fast_intr+0x3d
>> #8 0x8054963b at intr_event_handle+0x9b
>> #9 0x80965f38 at intr_execute_handlers+0x48
>> #10 0x8096b1cf at lapic_handle_intr+0x3f
>> #11 0x808f3cc7 at Xapic_isr1+0xb7
>> #12 0x805b994a at sched_idletd+0x37a
>> #13 0x805460f5 at fork_exit+0x85
>> #14 0x808f3b1e at fork_trampoline+0xe
>> 
>> Peter
> 
> Thanks for the report.  We're looking at this.
> 
> This is with an igb(4) interface or em(4)?
> 
> sean

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

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending



On 01/18/17 08:20, O. Hartmann wrote:
> On Wed, 18 Jan 2017 07:59:17 -0700
> Sean Bruno  wrote:
> 
>> On 01/18/17 07:41, Sean Bruno wrote:
>>>
>>>
>>> On 01/18/17 00:34, O. Hartmann wrote:  
 On Thu, 5 Jan 2017 20:17:56 -0700
 Sean Bruno  wrote:  
>  
 On a Fujitsu Celsius M740, the "em0" device gets stuck on heavy I/O. I can
 still trigger this behaviour on recent CURRENT (12.0-CURRENT #17 r312369:
 Wed Jan 18 06:18:45 CET 2017 amd64) by rsync'ing a large poudriere ports
 repository onto a remote NFSv4 fileserver. The freeze always occur on large
 tarballs.

 Again, here is the pciconf output of the device: 

 em0@pci0:0:25:0:class=0x02 card=0x11ed1734 chip=0x153a8086
 rev=0x05 hdr=0x00 vendor = 'Intel Corporation'
 device = 'Ethernet Connection I217-LM'
 class  = network
 subclass   = ethernet
 bar   [10] = type Memory, range 32, base 0xfb30, size 131072,
 enabled bar   [14] = type Memory, range 32, base 0xfb339000, size 4096,
 enabled bar   [18] = type I/O Port, range 32, base 0xf020, size 32, enabled

 On another box. equipted with a dual-port Intel i350 NIC, the igb0 and
 igb1 do have negotiation problems with several types of switches (in my
 SoHo environment, I use a Netgear GS110TP, at work there are several types
 of Cisco Catalyst 3XXX types). The igbX very often fall back to 100MBit/s.

 Since yesterday, the igbX on that specific i350 basesd NIC (we have plentz
 of them and they show similar phenomena with FreeBSD), although the switch
 reports an uplink with 1 GBit, FreeBSD CURRENT shows this weird crap
 message: 
> igb0: flags=8843 metric 0 mtu
> 1500
> options=653dbb
> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xff00 broadcast
> 192.168.0.255 nd6 options=29
>media: Ethernet autoselect (100baseTX )
>status: active  
  
>>
>> I just checked my test machines (which are auto/auto on the Juniper
>> EX4200 switches in use) and I see them come up with 1000baseTX.  Do you
>> set any options in /etc/rc.conf?
>>
>> sean
>>
> 
> No, I don't.
> 
> The line is:
> ifconfig_igb0="inet 192.168.0.10 netmask 0xff00"
> 
> Nothing else.
> 

Ok, good.  Definitely a regression.

sean



signature.asc
Description: OpenPGP digital signature

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending



On 01/18/17 07:41, Sean Bruno wrote:
> 
> 
> On 01/18/17 00:34, O. Hartmann wrote:
>> On Thu, 5 Jan 2017 20:17:56 -0700
>> Sean Bruno  wrote:
>>>
>> On a Fujitsu Celsius M740, the "em0" device gets stuck on heavy I/O. I can
>> still trigger this behaviour on recent CURRENT (12.0-CURRENT #17 r312369: Wed
>> Jan 18 06:18:45 CET 2017 amd64) by rsync'ing a large poudriere ports
>> repository onto a remote NFSv4 fileserver. The freeze always occur on large
>> tarballs.
>>
>> Again, here is the pciconf output of the device: 
>>
>> em0@pci0:0:25:0:class=0x02 card=0x11ed1734 chip=0x153a8086
>> rev=0x05 hdr=0x00 vendor = 'Intel Corporation'
>> device = 'Ethernet Connection I217-LM'
>> class  = network
>> subclass   = ethernet
>> bar   [10] = type Memory, range 32, base 0xfb30, size 131072, enabled
>> bar   [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled
>> bar   [18] = type I/O Port, range 32, base 0xf020, size 32, enabled
>>
>> On another box. equipted with a dual-port Intel i350 NIC, the igb0 and igb1 
>> do
>> have negotiation problems with several types of switches (in my SoHo
>> environment, I use a Netgear GS110TP, at work there are several types of 
>> Cisco
>> Catalyst 3XXX types). The igbX very often fall back to 100MBit/s.
>>
>> Since yesterday, the igbX on that specific i350 basesd NIC (we have plentz of
>> them and they show similar phenomena with FreeBSD), although the switch 
>> reports
>> an uplink with 1 GBit, FreeBSD CURRENT shows this weird crap message:
>>
>>> igb0: flags=8843 metric 0 mtu
>>> 1500
>>> options=653dbb
>>> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xff00 broadcast
>>> 192.168.0.255 nd6 options=29
>>>media: Ethernet autoselect (100baseTX )
>>>status: active
>>

I just checked my test machines (which are auto/auto on the Juniper
EX4200 switches in use) and I see them come up with 1000baseTX.  Do you
set any options in /etc/rc.conf?

sean



signature.asc
Description: OpenPGP digital signature

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending



On 01/18/17 00:34, O. Hartmann wrote:
> On Thu, 5 Jan 2017 20:17:56 -0700
> Sean Bruno  wrote:
> 
>> tl;dr --> igbX devices will become emX devices
>>
>> We're about to commit an update to sys/dev/e1000 that will implement and
>> activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks
>> who can test and poke at the drivers to do so this week.  This will have
>> some really great changes for performance and standardization that have
>> been bouncing around inside of various FreeBSD shops that have been
>> collaborating with Matt Macy over the last year.
>>
>> This will implement multiple queues for certain em(4) devices that are
>> capable of such things and add some new sysctl's for you to poke at in
>> your monitoring tools.
>>
>> Due to limitations of device registration, igbX devices will become emX
>> devices.  So, you'll need to make a minor update to your rc.conf and
>> scripts that manipulate the network devices.
>>
>> UPDATING will be bumped to reflect these changes.
>>
>> MFC to stable/11 will have a legacy implementation that doesn't use
>> IFLIB for compatibility reasons.
>>
>> A documentation and man page update will follow in the next few days
>> explaining how to work with the changed driver.
>>
>> sean
>>
>> bcc net@ current@ re@
>>
>>
>>
> On a Fujitsu Celsius M740, the "em0" device gets stuck on heavy I/O. I can
> still trigger this behaviour on recent CURRENT (12.0-CURRENT #17 r312369: Wed
> Jan 18 06:18:45 CET 2017 amd64) by rsync'ing a large poudriere ports
> repository onto a remote NFSv4 fileserver. The freeze always occur on large
> tarballs.
> 
> Again, here is the pciconf output of the device: 
> 
> em0@pci0:0:25:0:class=0x02 card=0x11ed1734 chip=0x153a8086
> rev=0x05 hdr=0x00 vendor = 'Intel Corporation'
> device = 'Ethernet Connection I217-LM'
> class  = network
> subclass   = ethernet
> bar   [10] = type Memory, range 32, base 0xfb30, size 131072, enabled
> bar   [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled
> bar   [18] = type I/O Port, range 32, base 0xf020, size 32, enabled
> 
> On another box. equipted with a dual-port Intel i350 NIC, the igb0 and igb1 do
> have negotiation problems with several types of switches (in my SoHo
> environment, I use a Netgear GS110TP, at work there are several types of Cisco
> Catalyst 3XXX types). The igbX very often fall back to 100MBit/s.
> 
> Since yesterday, the igbX on that specific i350 basesd NIC (we have plentz of
> them and they show similar phenomena with FreeBSD), although the switch 
> reports
> an uplink with 1 GBit, FreeBSD CURRENT shows this weird crap message:
> 
>> igb0: flags=8843 metric 0 mtu
>> 1500
>> options=653dbb
>> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xff00 broadcast
>> 192.168.0.255 nd6 options=29
>>media: Ethernet autoselect (100baseTX )
>>status: active
> 
> I haven't checked whether FreeBSD lies or the switch lies about the linkspeed,
> but will do next time I have access to the box.
> 
> 
> regards,
> Oliver
> 


Ugh.  Ok.  Investigating the link issue, that's gross.

sean



signature.asc
Description: OpenPGP digital signature

Re: crash in iflib_fast_intr



On 01/18/17 03:37, peter.b...@bsd4all.org wrote:
> Hi,
> 
> A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since 
> GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is 
> reproducible.
> 
> KDB: stack backtrace:
> #0 0x805cec97 at kdb_backtrace+0x67
> #1 0x80584816 at vpanic+0x186
> #2 0x80584683 at panic+0x43
> #3 0x8090f222 at trap_fatal+0x322
> #4 0x8090f3ec at trap_pfault+0x1bc
> #5 0x8090eaa0 at trap+0x280
> #6 0x808f35e1 at calltrap+0x8
> #7 0x806a202d at iflib_fast_intr+0x3d
> #8 0x8054963b at intr_event_handle+0x9b
> #9 0x80965f38 at intr_execute_handlers+0x48
> #10 0x8096b1cf at lapic_handle_intr+0x3f
> #11 0x808f3cc7 at Xapic_isr1+0xb7
> #12 0x805b994a at sched_idletd+0x37a
> #13 0x805460f5 at fork_exit+0x85
> #14 0x808f3b1e at fork_trampoline+0xe
> 
> Peter

Thanks for the report.  We're looking at this.

This is with an igb(4) interface or em(4)?

sean



signature.asc
Description: OpenPGP digital signature

Re: Build failure 'wmmintrin.h' file not found

2017-01-18 Thread Magnus Ringman

On Wed, Jan 18, 2017 at 2:16 PM, Hans Petter Selasky 
wrote:

> On 01/18/17 14:13, Dimitry Andric wrote:
>
>> On 18 Jan 2017, at 13:36, Hans Petter Selasky  wrote:
>>
>>>
>>> I'm seeing the following build-error trying to build 12-current from
>>> 10-stable:
>>>
>>> xxx/freebsd/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error:
>>> 'wmmintrin.h' file not found
>>> #include 
>>>
>>> Missing header exists:
>>>
>>> xxx/freebsd/contrib/llvm/tools/clang/lib/Headers/wmmintrin.h
>>>
>>> Missing include directory or compiler magic?
>>>
>>
>> What are you building, and how?  Did you do a buildworld before
>> buildkernel?
>>
>> -Dimitry
>>
>>
> I did:
>
> make toolchain -jXX
>
> And then:
>
> make buildkernel -jXX
>
>

> And the error popped out. I'm not observing this error when building a
> 12-current kernel from an 11-stable install.

Isn't it all bets are off if going to -current from anything but most
recent -stable?
Recommended practice[citation needed] would be
10-stable->11-stable->12-current.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build failure 'wmmintrin.h' file not found


On 01/18/17 14:13, Dimitry Andric wrote:

On 18 Jan 2017, at 13:36, Hans Petter Selasky  wrote:


I'm seeing the following build-error trying to build 12-current from 10-stable:

xxx/freebsd/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h' 
file not found
#include 

Missing header exists:

xxx/freebsd/contrib/llvm/tools/clang/lib/Headers/wmmintrin.h

Missing include directory or compiler magic?


What are you building, and how?  Did you do a buildworld before buildkernel?

-Dimitry



I did:

make toolchain -jXX

And then:

make buildkernel -jXX

And the error popped out. I'm not observing this error when building a 
12-current kernel from an 11-stable install.


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

Re: Build failure 'wmmintrin.h' file not found

2017-01-18 Thread Dimitry Andric

On 18 Jan 2017, at 13:36, Hans Petter Selasky  wrote:
> 
> I'm seeing the following build-error trying to build 12-current from 
> 10-stable:
> 
> xxx/freebsd/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h' 
> file not found
> #include 
> 
> Missing header exists:
> 
> xxx/freebsd/contrib/llvm/tools/clang/lib/Headers/wmmintrin.h
> 
> Missing include directory or compiler magic?

What are you building, and how?  Did you do a buildworld before buildkernel?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Build failure 'wmmintrin.h' file not found


Hi,

I'm seeing the following build-error trying to build 12-current from 
10-stable:


xxx/freebsd/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 
'wmmintrin.h' file not found

#include 

Missing header exists:

xxx/freebsd/contrib/llvm/tools/clang/lib/Headers/wmmintrin.h

Missing include directory or compiler magic?

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

Re: ISO image: where is the CLANG compiler?

2017-01-18 Thread Slawa Olhovchenkov

On Wed, Jan 18, 2017 at 10:19:15AM +0100, O. Hartmann wrote:

> Hello Daniel,
> 
> thank you very much for responding!
> 
> I just looked into "makeing release". I have a lot of NanoBSD images and build
> environments for our purpose at work, but I always strip off the compiler,
> too :-(
> 
> I was realy badly surprised that on the ISOs the compiler is not present - for
> the sake of space? If so, then best practice would be to melt everything down
> to 1,66 MB size - as an ancient floppy would contain. Or better, Null.
> Sorry ... It is hard these days to purchase 1GB USB flash drives, most of them
> do have 2 GB at least.

ISO images limited by size, for fit to real CD-R blank disks.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ISO image: where is the CLANG compiler?

On Wed, 18 Jan 2017 10:43:58 +0200
Daniel Kalchev  wrote:

> I never use the pre-built ISO images for tasks like this. Here is a script I
> use to build my own USB boot drive. The drive contains the full OS to boot
> and also a copy used to create a new system. I make these boot drives from
> time to time, to stay current. Please note the script is few years old (for
> 9-stable) and you might want to twiddle with boot partition size if they
> grew. You need to have done bouildworld/buildkernel on the host before using
> this script.
> 
> $ cat createuboot
> #!/bin/sh
> # target USB drive to write to
> disk=da1
> # use the current date for labels
> today=`date "+%Y%m%d"`
> # wipe out partition data form drive
> # do it twice to wipe more stuff (might not be needed anymore)
> gpart destroy -F $disk   
> gpart create -s GPT $disk
> gpart destroy -F $disk
> # GPT label the drive
> gpart create -s GPT $disk  
> # bootstrap partition 
> gpart add -b 34 -s 128 -t freebsd-boot $disk   
> # partition for the OS
> gpart add -a 4k -t freebsd-ufs -l boot$today $disk 
> # write bootstrap code
> gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 $disk
> 
> # format file system
> newfs  /dev/gpt/boot$today
> 
> # mount file system
> mount -o async /dev/gpt/boot$today /mnt
> 
> # install FreeBSD
> cd /usr/src
> make installworld DESTDIR=/mnt
> make distribution DESTDIR=/mnt
> make installkernel DESTDIR=/mnt
> # Create new “clean” copy of FreeBSD for later use
> mkdir -p /mnt/root/FreeBSD
> make installworld DESTDIR=/mnt/root/FreeBSD
> make distribution DESTDIR=/mnt/root/FreeBSD
> make installkernel DESTDIR=/mnt/root/FreeBSD
> 
> # copy scripts
> cp -r ~/scripts /mnt/root
> 
> echo /dev/gpt/boot$today / ufs rw,noatime 0 1 > /mnt/etc/fstab
> umount /mnt
> 
> 
> You might add more customizations, such as dhclient and starting sshd
> in /etc/rc.conf of the boot drive.
> 
> Hope this helps…
> 
> Daniel
> 
> 
> > On 18.01.2017 г., at 9:45, O. Hartmann  wrote:
> > 
> > I ran into a very nasty situation where I need to save/restore/reinstall a
> > in-installworld-crashed recent current.
> > 
> > While the /usr/obj and /usr/src as well as /etc folders are intact
> > (residing on a Samsung 850 pro SSD with UFS and journaling), /boot/kernel
> > vanished and most binaries in /bin and /sbin are of Null size.
> > 
> > I treid to rescue the system by intending to use the most recent CURRENT ISO
> > image found on the snapshot server for USB drives, booted this successfully
> > and then mounted the failes filesystems into the proper place (/usr/obj
> > and /usr/src onto USB devices /usr/obj and /usr/src respectively, the rest
> > goes into /mnt).
> > 
> > I tried then to perform a make installworld with DESTDIR=/mnt set. But I
> > fail: the minimalistic USB image does not have any CLANG/LLVM stuff
> > required for the rescue!
> > 
> > Where the hell did this stuff go? Has it been ripped off due to the 1 GB
> > ancient flash size? 
> > 
> > Help is needed. I've already posted to CURRENT a message, but I guess I
> > always hit the wrong subject line. It seems that the key to my saviour is
> > to have a flash drive with a recent CURRENT containing a cc compiler -
> > otherwise /usr/obj is useless.
> > 
> > Kind reards,
> > 
> > Oliver
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"  
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Hello Daniel,

thank you very much for responding!

I just looked into "makeing release". I have a lot of NanoBSD images and build
environments for our purpose at work, but I always strip off the compiler,
too :-(

I was realy badly surprised that on the ISOs the compiler is not present - for
the sake of space? If so, then best practice would be to melt everything down
to 1,66 MB size - as an ancient floppy would contain. Or better, Null.
Sorry ... It is hard these days to purchase 1GB USB flash drives, most of them
do have 2 GB at least.

As your own approach indicates, the ISOs are useless in such cases and I
consider them as a toying thingi, nothing more. it is probably the best to have
a complete emergency ISO at hand - as your script provides.

Again, thanks for the script. I need to adjust the kernel and will create then
my own USB drive.

Kind regards,

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

Re: recent change to vim defaults?

2017-01-18 Thread Raimund Sacherer

I have to put mouse=v to get the behavior I am used to.

Best⁣

Sent from TypeApp 

On Jan 18, 2017, 08:46, at 08:46, Julian Elischer  wrote:
>On 17/01/2017 12:07 AM, ohauer wrote:
>> I suspect you mean the /usr/local/etc/vim/vimrc and gvimrc files.
>> That was the first place I've tried to overwrite it, but without 
>> luck (even with set mouse=) but it works in ~/.vimrc
>
>what to put IN the file?
>>
>> -- 
>> olli
>> -- 
>> send with broken GMX mailer client, sorry for tofu and html scrap
>> On 15/01/2017, 22:48 Benjamin Kaduk  wrote:
>>
>> On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
>> > I noticed that suddenly vim is grabbing mouse movements, which
>> makes
>> > life really hard.
>> >
>> > Was there a specific revision that brought in this change, and
>> can it
>> > be removed?
>>
>> I remember seeing something go by during an upgrade somewhat
>> recently
>> about there now being a defaults file that gets used when a user
>> does
>> not specify a .vimrc. Unfortunately, I don't remember whether I
>saw
>> that notice on a FreeBSD machine or a Debian one, and haven't
>> been able
>> to find the notice I remember through searching some likely
>places.
>>
>> Just to check: do you have a .vimrc file in place already?
>>
>not yet.
>when I work out what to put into it I will make it.
>
>>
>> -Ben
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscr...@freebsd.org"
>>
>
>___
>freebsd-po...@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>To unsubscribe, send any mail to
>"freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On Thu, 5 Jan 2017 20:17:56 -0700
Sean Bruno  wrote:

> tl;dr --> igbX devices will become emX devices
> 
> We're about to commit an update to sys/dev/e1000 that will implement and
> activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks
> who can test and poke at the drivers to do so this week.  This will have
> some really great changes for performance and standardization that have
> been bouncing around inside of various FreeBSD shops that have been
> collaborating with Matt Macy over the last year.
> 
> This will implement multiple queues for certain em(4) devices that are
> capable of such things and add some new sysctl's for you to poke at in
> your monitoring tools.
> 
> Due to limitations of device registration, igbX devices will become emX
> devices.  So, you'll need to make a minor update to your rc.conf and
> scripts that manipulate the network devices.
> 
> UPDATING will be bumped to reflect these changes.
> 
> MFC to stable/11 will have a legacy implementation that doesn't use
> IFLIB for compatibility reasons.
> 
> A documentation and man page update will follow in the next few days
> explaining how to work with the changed driver.
> 
> sean
> 
> bcc net@ current@ re@
> 
> 
> 
On a Fujitsu Celsius M740, the "em0" device gets stuck on heavy I/O. I can
still trigger this behaviour on recent CURRENT (12.0-CURRENT #17 r312369: Wed
Jan 18 06:18:45 CET 2017 amd64) by rsync'ing a large poudriere ports
repository onto a remote NFSv4 fileserver. The freeze always occur on large
tarballs.

Again, here is the pciconf output of the device: 

em0@pci0:0:25:0:class=0x02 card=0x11ed1734 chip=0x153a8086
rev=0x05 hdr=0x00 vendor = 'Intel Corporation'
device = 'Ethernet Connection I217-LM'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 32, base 0xfb30, size 131072, enabled
bar   [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled
bar   [18] = type I/O Port, range 32, base 0xf020, size 32, enabled

On another box. equipted with a dual-port Intel i350 NIC, the igb0 and igb1 do
have negotiation problems with several types of switches (in my SoHo
environment, I use a Netgear GS110TP, at work there are several types of Cisco
Catalyst 3XXX types). The igbX very often fall back to 100MBit/s.

Since yesterday, the igbX on that specific i350 basesd NIC (we have plentz of
them and they show similar phenomena with FreeBSD), although the switch reports
an uplink with 1 GBit, FreeBSD CURRENT shows this weird crap message:

> igb0: flags=8843 metric 0 mtu
> 1500
> options=653dbb
> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xff00 broadcast
> 192.168.0.255 nd6 options=29
>media: Ethernet autoselect (100baseTX )
>status: active

I haven't checked whether FreeBSD lies or the switch lies about the linkspeed,
but will do next time I have access to the box.


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

crash in iflib_fast_intr

2017-01-18 Thread peter . blok

Hi,

A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since 
GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is 
reproducible.

KDB: stack backtrace:
#0 0x805cec97 at kdb_backtrace+0x67
#1 0x80584816 at vpanic+0x186
#2 0x80584683 at panic+0x43
#3 0x8090f222 at trap_fatal+0x322
#4 0x8090f3ec at trap_pfault+0x1bc
#5 0x8090eaa0 at trap+0x280
#6 0x808f35e1 at calltrap+0x8
#7 0x806a202d at iflib_fast_intr+0x3d
#8 0x8054963b at intr_event_handle+0x9b
#9 0x80965f38 at intr_execute_handlers+0x48
#10 0x8096b1cf at lapic_handle_intr+0x3f
#11 0x808f3cc7 at Xapic_isr1+0xb7
#12 0x805b994a at sched_idletd+0x37a
#13 0x805460f5 at fork_exit+0x85
#14 0x808f3b1e at fork_trampoline+0xe

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

Re: ISO image: where is the CLANG compiler?

2017-01-18 Thread Daniel Kalchev

I never use the pre-built ISO images for tasks like this. Here is a script I 
use to build my own USB boot drive. The drive contains the full OS to boot and 
also a copy used to create a new system. I make these boot drives from time to 
time, to stay current. Please note the script is few years old (for 9-stable) 
and you might want to twiddle with boot partition size if they grew. You need 
to have done bouildworld/buildkernel on the host before using this script.

$ cat createuboot
#!/bin/sh
# target USB drive to write to
disk=da1
# use the current date for labels
today=`date "+%Y%m%d"`
# wipe out partition data form drive
# do it twice to wipe more stuff (might not be needed anymore)
gpart destroy -F $disk   
gpart create -s GPT $disk
gpart destroy -F $disk
# GPT label the drive
gpart create -s GPT $disk  
# bootstrap partition 
gpart add -b 34 -s 128 -t freebsd-boot $disk   
# partition for the OS
gpart add -a 4k -t freebsd-ufs -l boot$today $disk 
# write bootstrap code
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 $disk

# format file system
newfs  /dev/gpt/boot$today

# mount file system
mount -o async /dev/gpt/boot$today /mnt

# install FreeBSD
cd /usr/src
make installworld DESTDIR=/mnt
make distribution DESTDIR=/mnt
make installkernel DESTDIR=/mnt
# Create new “clean” copy of FreeBSD for later use
mkdir -p /mnt/root/FreeBSD
make installworld DESTDIR=/mnt/root/FreeBSD
make distribution DESTDIR=/mnt/root/FreeBSD
make installkernel DESTDIR=/mnt/root/FreeBSD

# copy scripts
cp -r ~/scripts /mnt/root

echo /dev/gpt/boot$today / ufs rw,noatime 0 1 > /mnt/etc/fstab
umount /mnt


You might add more customizations, such as dhclient and starting sshd in 
/etc/rc.conf of the boot drive.

Hope this helps…

Daniel


> On 18.01.2017 г., at 9:45, O. Hartmann  wrote:
> 
> I ran into a very nasty situation where I need to save/restore/reinstall a
> in-installworld-crashed recent current.
> 
> While the /usr/obj and /usr/src as well as /etc folders are intact (residing 
> on
> a Samsung 850 pro SSD with UFS and journaling), /boot/kernel vanished and
> most binaries in /bin and /sbin are of Null size.
> 
> I treid to rescue the system by intending to use the most recent CURRENT ISO
> image found on the snapshot server for USB drives, booted this successfully 
> and
> then mounted the failes filesystems into the proper place (/usr/obj
> and /usr/src onto USB devices /usr/obj and /usr/src respectively, the rest 
> goes
> into /mnt).
> 
> I tried then to perform a make installworld with DESTDIR=/mnt set. But I fail:
> the minimalistic USB image does not have any CLANG/LLVM stuff required for the
> rescue!
> 
> Where the hell did this stuff go? Has it been ripped off due to the 1 GB
> ancient flash size? 
> 
> Help is needed. I've already posted to CURRENT a message, but I guess I always
> hit the wrong subject line. It seems that the key to my saviour is to have a
> flash drive with a recent CURRENT containing a cc compiler - otherwise 
> /usr/obj
> is useless.
> 
> Kind reards,
> 
> Oliver
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: Strange issue after early AP startup


On 01/18/17 02:18, John Baldwin wrote:

You might still want to adjust 'nextevent' to schedule the next interrupt
to be sooner than 'timerperiod' though.  You could just set 'nextevent' to
'now' in that case instead of 'next'.


Right, I'll give that a spin. Would have to be "now + 1" instead of 
"now", due to check before et_start() ?


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

Re: Strange issue after early AP startup