Re: New Xorg - different key-codes

[Mark Martinec]

I just updated my laptop from source, and somewhere along the way
the key-codes Xorg sees changed.


Indeed.  This doesn't just affect -CURRENT: it happened to me on
-STABLE last week, so I'm copying that list too.


And a "Down" key now opens and closes a KDE "Application Launcher",
alternatively with its original function (which makes editing a 
frustration).


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


Mark
___
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: lame reverse DNS?

[Mark Martinec]

The problem has been resolved but I still sometimes see "connect from
unknown[2610:1c1:1:606c::19:2]" in the maillog (today: 6 of 131
connections). Local unbound issue?

That IPv6 has a valid reverse DNS record, so please try to investigate.


Looks like an intermittent problem. Tried the following, with different
resolvers (local and public):

  dig -t ptr 
2.0.0.0.9.1.0.0.0.0.0.0.0.0.0.0.c.6.0.6.1.0.0.0.1.c.1.0.0.1.6.2.ip6.arpa 
@9.9.9.9


For example the quad-9 public resolver returned SERVFAIL several times,
but eventually started returning the positive reply (NOERROR).

There seems to be some mess with NS records and delegations of the
domain 1.0.0.0.1.c.1.0.0.1.6.2.ip6.arpa . DNS checkers are complaining
about a mismatch between NS records of this domain between a parent
NS and domain's NS, e.g. auth1.ns.ny1.nyi.net vs. auth1.sea.ns.nyi.net .

Try the domain 1.c.1.0.0.1.6.2.ip6.arpa at the checkers:
  https://network-tools.webwiz.net/dns-report.htm
  https://intodns.com/1.c.1.0.0.1.6.2.ip6.arpa
  https://zonemaster.iis.se/en/?resultid=5e30b31d6f0061c5


Mark
___
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: Lockdown adaX numbers to allow booting ?

[Mark Martinec]

Kurt Jaeger writes:


The problem is that if all 10 disks are connected, the system
looses track from where it should boot and fails to boot (serial boot 
log):


Consoles: internal video/keyboard  serial port
BTX loader 1.00  BTX version is 1.02
Consoles: internal video/keyboard  serial port
BIOS drive C: is disk0
BIOS drive D: is disk1
BIOS drive E: is disk2
BIOS drive F: is disk3
BIOS drive G: is disk4
BIOS drive H: is disk5
BIOS drive I: is disk6
BIOS drive J: is disk7
BIOS drive K: is disk8
BIOS drive L: is disk9
//
[...]
The solution right now is this to unplug all disks of the 'bck' pool,
reboot, and re-insert the data disks after the boot is finished.
[...]
No gpart on the bck pool, raw drives.



This sounds very much like my experience:

  2018-11-29, Boot loader stuck after first stage upgrading 11.2 to 
12.0-RC2

https://lists.freebsd.org/pipermail/freebsd-stable/2018-November/090129.html

https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090159.html


I now have three SuperMicro machines which are unable to boot after
upgrading 11.2 to 12.0. After unsuccessfully fiddling with boot loaders,
I have reverted two back to 11.2 (which boots and works fine again),
and the third one is now at 12.0 but needs the boot hack as described
by Kurt, i.e. pull out half the disks (of the 'data' pool), boot the
system, plug the disks back in and zfs mount the remaining pool.

Considering that the 11.2 boots and works fine on these machines,
I consider it a btx loader failure and not a BIOS issue.

What is common with these three machines is that they have one pool
on raw devices for historical reasons (not on gpt partitions).
My guess is that the new loader gets confused by these raw disks.

  Mark
___
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: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Mark Martinec]

2018-11-29 18:43, Toomas Soome wrote:

I just did push biosdisk updates to stable/12, I wonder if you could
test those bits…


Myself wrote:

Thank you!  I haven't tried it yet, but I wonder whether this fix was
already incorporated into 12.0-RC3, which would make my rescue easier.
Otherwise I can build a stable/12 on another host and transplant
the problematic file(s) to the affected host - if I knew which files
to copy.


2018-12-02 18:59, Toomas wrote:

The files are /boot/loader* binaries - to be exact, check which one is
linked to /boot/loader. I can provide binaries if needed.
[...]
rgds,
toomas


I got a maintenance window today so I tried with the new loader,
and it did not help.

More specifically:

As it comes with 12-RC2, the /boot/loader was hard linked with 
loader_lua.

Its size is 421888 bytes. So I concentrated on this loader.

I build a fresh stable/12 on another host, and copied the newly
built loader_lua (425984 bytes) to the /boot directory of the affected
host, deleted the file 'loader', and hard-linked loader_lua to loader.

The situation has not changed: the BTX loader lists all BIOS drives
C..J (disk0..disk7), then a spinner starts and gets stuck forever.
It never reaches the 'BIOS 635kB/3537856kB available memory' line.

While trying to restore the old /boot from 11.2, I tried booting
a live image from a 12.0-RC3 memory stick - and the loader got
stuck again, same as when booting from a disk.

So I had to boot from an 11.2 memstick to be able to regain control.

  Mark



On 29 Nov 2018, at 17:01, Mark Martinec 
 wrote:
After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 
(amd64,
zfs, bios), I tried my luck with one of our production hosts, and 
ended up
with a stuck loader after rebooting with a new kernel (after the 
first

stage of upgrade).
These were the steps, and all went smoothly and normally until a 
reboot:

freebsd-update upgrade -r 12.0-RC2
freebsd-update install
shutdown -r now
While booting, the 'BTX loader' comes up, lists the BIOS drives,
then the spinner below the list comes up and begins turning,
stuttering, and after a couple of seconds it grinds to a standstill
and nothing happens afterwards.
At this point the ZFS and the bootstrap loader is supposed to
come up, but it doesn't.
This host has too zfs pools, the system pool consists of two SSDs
in a zfs mirror (also holding a freebsd-boot partition each), the
other pool is a raidz2 with six JBOD disks on an LSI controller.
The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
both zpool versions are up-to-date with 11.2. The 'zpool status -v'
is happy with both pools.
After rebooting from an USB drive and reverting the /boot directory
to a previous version, the machine comes up normally again
with the 11.2-RELEASE-p4.
I found a file init.core in the / directory, slightly predating the
last reboot with a salvaged system - although it was probably not
a cause of the problem, but a consequence of the rescue operation.
It is unfortunate that this is a production host, so I can't play
much with it. One or two more quick experiments I can probably
afford, but not much more. Should I just first wait for the
official 12.0 release? Should I try booting with a 12.0 on USB
and try to import pools? Suggestions welcome.
Now that the /boot has been manually restored to the 11.2 state,
A SECOND QUESTION is about freebsd-update, which still thinks we are
in the middle of an upgrade procedure. Trying now to just update
the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:
# uname -a
FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
#
# freebsd-version
11.2-RELEASE-p4
#
# freebsd-update fetch
src component not installed, skipped
You have a partially completed upgrade pending
Run '/usr/sbin/freebsd-update install' first.
Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.
So what is the right way to get rid of all traces of the
unsuccessful upgrade, and let freebsd-update believe we are cleanly
at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.
Mark

___
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: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Mark Martinec]

2018-11-29 18:43, Toomas Soome wrote:

I just did push biosdisk updates to stable/12, I wonder if you could
test those bits…


Thank you!  I haven't tried it yet, but I wonder whether this fix was
already incorporated into 12.0-RC3, which would make my rescue easier.

Otherwise I can build a stable/12 on another host and transplant
the problematic file(s) to the affected host - if I knew which files
to copy.

I wonder also, if the today's posting by cksalexan...@q.com on the
freebsd-stable ML titled "FreeBSD-12.0-RC3-i386-disc1.iso does not boot"
could be describing the same problem?

  Mark


On 29 Nov 2018, at 17:01, Mark Martinec  
wrote:


After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 
(amd64,
zfs, bios), I tried my luck with one of our production hosts, and 
ended up

with a stuck loader after rebooting with a new kernel (after the first
stage of upgrade).

These were the steps, and all went smoothly and normally until a 
reboot:


 freebsd-update upgrade -r 12.0-RC2
 freebsd-update install
 shutdown -r now

While booting, the 'BTX loader' comes up, lists the BIOS drives,
then the spinner below the list comes up and begins turning,
stuttering, and after a couple of seconds it grinds to a standstill
and nothing happens afterwards.

At this point the ZFS and the bootstrap loader is supposed to
come up, but it doesn't.

This host has too zfs pools, the system pool consists of two SSDs
in a zfs mirror (also holding a freebsd-boot partition each), the
other pool is a raidz2 with six JBOD disks on an LSI controller.
The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
both zpool versions are up-to-date with 11.2. The 'zpool status -v'
is happy with both pools.

After rebooting from an USB drive and reverting the /boot directory
to a previous version, the machine comes up normally again
with the 11.2-RELEASE-p4.

I found a file init.core in the / directory, slightly predating the
last reboot with a salvaged system - although it was probably not
a cause of the problem, but a consequence of the rescue operation.

It is unfortunate that this is a production host, so I can't play
much with it. One or two more quick experiments I can probably
afford, but not much more. Should I just first wait for the
official 12.0 release? Should I try booting with a 12.0 on USB
and try to import pools? Suggestions welcome.



Now that the /boot has been manually restored to the 11.2 state,
A SECOND QUESTION is about freebsd-update, which still thinks we are
in the middle of an upgrade procedure. Trying now to just update
the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:

 # uname -a
 FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
 #
 # freebsd-version
 11.2-RELEASE-p4
 #
 # freebsd-update fetch
 src component not installed, skipped
 You have a partially completed upgrade pending
 Run '/usr/sbin/freebsd-update install' first.
 Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.

So what is the right way to get rid of all traces of the
unsuccessful upgrade, and let freebsd-update believe we are cleanly
at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.

 Mark

___
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"

Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Mark Martinec]

After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64,
zfs, bios), I tried my luck with one of our production hosts, and ended 
up

with a stuck loader after rebooting with a new kernel (after the first
stage of upgrade).

These were the steps, and all went smoothly and normally until a reboot:

  freebsd-update upgrade -r 12.0-RC2
  freebsd-update install
  shutdown -r now

While booting, the 'BTX loader' comes up, lists the BIOS drives,
then the spinner below the list comes up and begins turning,
stuttering, and after a couple of seconds it grinds to a standstill
and nothing happens afterwards.

At this point the ZFS and the bootstrap loader is supposed to
come up, but it doesn't.

This host has too zfs pools, the system pool consists of two SSDs
in a zfs mirror (also holding a freebsd-boot partition each), the
other pool is a raidz2 with six JBOD disks on an LSI controller.
The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
both zpool versions are up-to-date with 11.2. The 'zpool status -v'
is happy with both pools.

After rebooting from an USB drive and reverting the /boot directory
to a previous version, the machine comes up normally again
with the 11.2-RELEASE-p4.

I found a file init.core in the / directory, slightly predating the
last reboot with a salvaged system - although it was probably not
a cause of the problem, but a consequence of the rescue operation.

It is unfortunate that this is a production host, so I can't play
much with it. One or two more quick experiments I can probably
afford, but not much more. Should I just first wait for the
official 12.0 release? Should I try booting with a 12.0 on USB
and try to import pools? Suggestions welcome.



Now that the /boot has been manually restored to the 11.2 state,
A SECOND QUESTION is about freebsd-update, which still thinks we are
in the middle of an upgrade procedure. Trying now to just update
the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:

  # uname -a
  FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
  #
  # freebsd-version
  11.2-RELEASE-p4
  #
  # freebsd-update fetch
  src component not installed, skipped
  You have a partially completed upgrade pending
  Run '/usr/sbin/freebsd-update install' first.
  Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.

So what is the right way to get rid of all traces of the
unsuccessful upgrade, and let freebsd-update believe we are cleanly
at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.

  Mark
___
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"

Reminder - [Bug 213276] port 502 is officially mbap (Modbus Application Protocol), /etc/services claims outdated asa-appl-proto

[Mark Martinec]

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

Any chance of getting this simple fix of /etc/services into CURRENT
before it's too late for 12.0 ...

___
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: r313494 make perl File::Temp broken

[Mark Martinec]

2017-02-10 14:09, Iblis Lin wrote:

as not a perl programmer myself. I have no idea what is going on.
I found this issue while compiling math/openblas.

[iblis@ns]% uname -a
FreeBSD ns 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r313500: Fri Feb 10 
16:39:21

CST 2017 root@ns:/usr/obj/usr/src/sys/GENERIC  amd64

[iblis@ns]% cat test.pl
use File::Temp qw(tempfile);
$tmpf = new File::Temp( UNLINK => 1 );

[iblis@ns]% perl test.pl
Error in tempfile() using template /tmp/XX: Could not create 
temp file

/tmp/dI5uhUsijR: Bad file descriptor at test.pl line 2.


[...]

stat("/tmp/",{ mode=drwxrwxrwt 
,inode=24317568,size=1024,blksize=32768}) = 0 (0x0)
stat("/tmp/",{ mode=drwxrwxrwt 
,inode=24317568,size=1024,blksize=32768}) = 0 (0x0)
openat(AT_FDCWD,"/tmp/Nn0Epra5ff",O_RDWR|O_EXLOCK|O_NOFOLLOW|O_CREAT|O_EXCL,0600) 
ERR#9 'Bad file descriptor'



Perhaps your /tmp is a logical link, and O_NOFOLLOW does not allow that.

  Mark
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Mark Martinec]

2017-01-27 01:09, Allan Jude wrote:

Yeah, most of the size is from the GELI support, not Skein, so that is
your best starting place.


On a tangential ... does the gptzfsboot really support skein checksums
in 11.0?  If so, then why does zfs not allow setting skein on a root 
pool?


  # zfs set checksum=skein xxx
  cannot set property for 'xxx': property setting is not allowed on root 
pools



Mark
___
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: date(1) default format changed between 10.3 and 11.0-BETA3

[Mark Martinec]

On 2016-08-06 21:08, Julian Elischer wrote:

On 6/08/2016 11:09 PM, Benjamin Kaduk wrote:

On Sat, 6 Aug 2016, Baptiste Daroussin wrote:

On Sat, Aug 06, 2016 at 02:15:36PM +1000, Greg 'groggy' Lehey wrote:
On Friday,  5 August 2016 at 18:56:33 +0300, Andrey A. Chernov 
wrote:

On 05.08.2016 18:44, Mark Martinec wrote:

On 2016-08-05 17:23, Andrey Chernov wrote:

POSIX does say that the default format should be the same
as with "+%a %b %e %H:%M:%S %Z %Y".
It also says that %a and %b are locale's abbreviated names.
It is true for _POSIX_ locale only, as I already say. en_US.* is 
not

POSIX or C locale.

It still violates POLA.

I really do not think that it violates POLA fiven that the behaviour 
you are
expecting is still available in the default configurtion that is 
still POSIX.
Regardless, at a new major release is precisely when it is permissible 
to

break POLA.

switching from short form to long form is more than a POLA..  short
form has a specific fixed layout
and feeding a long form string into it will break things.


Set LC_TIME to C and then you are back on your behaviour (and this is 
the

default when you install FreeBSD).

locales should be seen as tzdata for exemple, they are a moving 
target
complicated to handle for every locale we do support: 78 for 
11.0-RELEASE and
193 if we do count the encoding variants. locales are updated very 
often (for
exemple cldr unicode make a new release of the data every 8 month or 
so)

As I understand it, your change will improve the maintainability of
locales in FreeBSD in the future, which justifies a POLA break at the
release boundary.
-Ben



$ LC_ALL=en_US.UTF-8 date

FreeBSD 11.0-BETA3 :
  Friday, August  5, 2016 at 03:20:25 PM CEST

FreeBSD 10.3-RELEASE-p6 :
  Fri Aug  5 15:15:11 CEST 2016

OSX version 10.9.5 :
  Fri Aug  5 14:57:14 CEST 2016

Fedora Linux 4.6.4-301.fc24.x86_64 :
  Fri Aug  5 15:10:40 CEST 2016

Debian 8.0 / Linux 4.4.16-v7+ :
  Fri Aug  5 15:25:49 CEST 2016

It's not just long vs. short forms of a name, it is also the order of 
fields,
their separators, and a 12/24h time form that is different from everyone 
else
and from what we used to have in 10.3.  Is it really worth being 
different?

I wonder how many ad-hoc scripts will break.

Although as Andrey Chernov correctly noted that the date(1) specs in
The Open Group Base Specifications Issue 7 IEEE Std 1003.1, 2013 Edition
( http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html )
says that the default format applies to POSIX locale only:

  STDOUT
  When no formatting operand is specified, the output in the
  POSIX locale shall be equivalent to specifying:
date "+%a %b %e %H:%M:%S %Z %Y"

imo, unless there is a very good reason not to, the above default format
should be applicable to most locales, but at least to English spoken
locales. The explicit locale-dependency of %a, %b, and %Z conversion
specifications already takes care of most locale-specific 
idiosyncrasies.


  Mark


___
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: date(1) default format changed between 10.3 and 11.0-BETA3

[Mark Martinec]

On 2016-08-05 17:23, Andrey Chernov wrote:

On 05.08.2016 17:47, Mark Martinec wrote:

[Bug 211598]
  date(1) default format in en_EN locale breaks compatibility with 
10.3

and violates POSIX

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


It breaks compatibility but not violates POSIX. POSIX care of only its
own POSIX (or C) locale.


POSIX does say that the default format should be the same
as with "+%a %b %e %H:%M:%S %Z %Y".
It also says that %a and %b are locale's abbreviated names.

It may not say what an abbreviated name really looks like
in a particular locale, but it does distinguish between
full and abbreviated names.

  Mark
___
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: date(1) default format changed between 10.3 and 11.0-BETA3

[Mark Martinec]

On 2016-08-05 07:00, Julian Elischer wrote:

On 5/08/2016 5:44 AM, Mark Martinec wrote:

Should I open a bug report, or has the problem been noted?

it's not clear without reading the standard whether the bug is in the
old or new version.
have you tried other systems? In particular I'd check OSX



Did some research, opened a PR against 11.0-BETA3:

[Bug 211598]
  date(1) default format in en_EN locale breaks compatibility with 10.3 
and violates POSIX


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


  Mark




On 2016-08-05 07:00, Julian Elischer wrote:
[...]

sh-3.2$ export LC_CTYPE="en_US.UTF-8"
sh-3.2$ export LC_TIME="en_US.UTF-8"
sh-3.2$ export LC_ALL="en_US.UTF-8"
sh-3.2$ export LC_NUMERIC="en_US.UTF-8"
sh-3.2$ date
Fri Aug  5 12:57:47 AWST 2016

if it IS a bug then yes, file a report with full reproduction steps.




On 2016-08-04 04:32, Julian Elischer wrote:

On 4/08/2016 7:24 AM, Mark Martinec wrote:

Is it normal/expected/documented that the date(1) command in 11.0
now produces a timestamp in substantially different format
in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour 
time):


  Thursday, August  4, 2016 at 12:50:43 AM CEST
vs:
  Thu Aug  4 00:52:29 CEST 2016


one of those is a bug.  the formats are defined in posix I believe.



Setting LC_TIME does not help:

  $LC_TIME="C" date
  Thursday, August  4, 2016 at 01:13:37 AM CEST

although LC_ALL="C" _does_ help.


This is funny too, especially regarding commas:
  $ LC_ALL="en_GB.UTF-8" date
  Thursday  4 August 2016 at 01:16:45 CEST
  $ LC_ALL="en_US.UTF-8" date
  Thursday, August  4, 2016 at 01:16:54 AM CEST


The date(1) man page states:
  The date utility is expected to be compatible with IEEE Std 1003.2
  (“POSIX.2”).
What does POSIX.2 say about date(1) following a locale?



==
11.0-BETA3:

$ date
Thursday, August  4, 2016 at 12:50:43 AM CEST

$ uname -a
FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul 
29 02:27:28 UTC 2016 
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64


$ locale
LANG=
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=en_US.UTF-8

==
10.3-RELEASE-p6 :

$ date
Thu Aug  4 00:52:29 CEST 2016

$ freebsd-version
10.3-RELEASE-p6

$ uname -a
FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat 
May 28 12:23:44 UTC 2016 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC 
amd64


$ locale
LANG=
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=en_US.UTF-8



  Mark

___
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: date(1) default format changed between 10.3 and 11.0-BETA3

[Mark Martinec]

Should I open a bug report, or has the problem been noted?

  Mark


On 2016-08-04 04:32, Julian Elischer wrote:

On 4/08/2016 7:24 AM, Mark Martinec wrote:

Is it normal/expected/documented that the date(1) command in 11.0
now produces a timestamp in substantially different format
in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour time):

  Thursday, August  4, 2016 at 12:50:43 AM CEST
vs:
  Thu Aug  4 00:52:29 CEST 2016


one of those is a bug.  the formats are defined in posix I believe.



Setting LC_TIME does not help:

  $ LC_TIME="C" date
  Thursday, August  4, 2016 at 01:13:37 AM CEST

although LC_ALL="C" _does_ help.


This is funny too, especially regarding commas:
  $ LC_ALL="en_GB.UTF-8" date
  Thursday  4 August 2016 at 01:16:45 CEST
  $ LC_ALL="en_US.UTF-8" date
  Thursday, August  4, 2016 at 01:16:54 AM CEST


The date(1) man page states:
  The date utility is expected to be compatible with IEEE Std 1003.2
  (“POSIX.2”).
What does POSIX.2 say about date(1) following a locale?



==
11.0-BETA3:

$ date
Thursday, August  4, 2016 at 12:50:43 AM CEST

$ uname -a
FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul 
29 02:27:28 UTC 2016 
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64


$ locale
LANG=
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=en_US.UTF-8

==
10.3-RELEASE-p6 :

$ date
Thu Aug  4 00:52:29 CEST 2016

$ freebsd-version
10.3-RELEASE-p6

$ uname -a
FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat May 
28 12:23:44 UTC 2016 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64


$ locale
LANG=
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=en_US.UTF-8



  Mark

___
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"

date(1) default format changed between 10.3 and 11.0-BETA3

[Mark Martinec]

Is it normal/expected/documented that the date(1) command in 11.0
now produces a timestamp in substantially different format
in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour time):

  Thursday, August  4, 2016 at 12:50:43 AM CEST
vs:
  Thu Aug  4 00:52:29 CEST 2016


Setting LC_TIME does not help:

  $ LC_TIME="C" date
  Thursday, August  4, 2016 at 01:13:37 AM CEST

although LC_ALL="C" _does_ help.


This is funny too, especially regarding commas:
  $ LC_ALL="en_GB.UTF-8" date
  Thursday  4 August 2016 at 01:16:45 CEST
  $ LC_ALL="en_US.UTF-8" date
  Thursday, August  4, 2016 at 01:16:54 AM CEST


The date(1) man page states:
  The date utility is expected to be compatible with IEEE Std 1003.2
  (“POSIX.2”).
What does POSIX.2 say about date(1) following a locale?



==
11.0-BETA3:

$ date
Thursday, August  4, 2016 at 12:50:43 AM CEST

$ uname -a
FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul 29 
02:27:28 UTC 2016 
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64


$ locale
LANG=
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=en_US.UTF-8

==
10.3-RELEASE-p6 :

$ date
Thu Aug  4 00:52:29 CEST 2016

$ freebsd-version
10.3-RELEASE-p6

$ uname -a
FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat May 
28 12:23:44 UTC 2016 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64


$ locale
LANG=
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=en_US.UTF-8



  Mark
___
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: OpenSSH HPN

[Mark Martinec]

For a fast transfer of large files see sysutils/bbcp.

It uses ssh to establish authorized connection, then does
a transfer over multiple parallel TCP sessions by itself.

If data encryption is needed, combine it with security/hpenc

  Mark
___
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: Segmentation fault running ntpd

[Mark Martinec]

Upgrading 10.2-RELEASE-p6 to 10.2-RELEASE-p7 now solved ntpd crashes
(apparently fixed by: FreeBSD Errata Notice FreeBSD-EN-15:20.vm).

Thanks!!!

  Mark


On 2015-11-01 10:31, Andre Albsmeier wrote:

On Fri, 30-Oct-2015 at 19:47:59 +0100, Mark Martinec wrote:

Not sure if it's the same issue, but it sure looks like it is.

I have upgraded a couple of hosts (amd64) from 10.2-RELEASE-p5
to 10.2-RELEASE-p6, i.e. the freebsd-upgrade essentially just
replaced the /usr/sbin/ntpd with a new one; then I restarted
the ntpd.

On all host but one this was successful: the new ntpd starts
fine and works normally. But on one of these machines the
ntpd process immediately crashes with SIGSEGV. That machine
has an Intel Xeon cpu. It is not apparent to me in what way
this machine differs from others,


I'll add my observations here:

I am using an ntp.conf with a single server entry:

server ntp.some.domain.org

ntp.some.domain.org is a CNAME pointing to gate.some.domain.org
and the latter contains an A record pointing to 192.168.128.1.

After updating 9.3-STABLE to the latest version (one which includes ntp
4.2.8p4), ntpd crashes:

Nov 1 09:38:38 voyager kernel: pid 4443 (ntpd), uid 0: exited on signal 
11


This happens in line 871 of ntpd.c where mlockall() is called:

&& 0 != mlockall(MCL_CURRENT|MCL_FUTURE))

It does NOT crash with MCL_FUTURE only.
It does crash with MCL_CURRENT only.

When adding

rlimit memlock -1

to ntpd.conf it does NOT crash (as mlockall() won't be called anymore).

When specifying the IP address (192.168.128.1) as the server it
does NOT crash.

When specifying gate.some.domain.org as the server it also does
NOT crash. tcpdump shows in this case:

09:49:59.542310 IP 192.168.128.2.21102 > 192.168.128.1.53: 7639+ A?
gate.some.domain.org. (41)
09:49:59.542578 IP 192.168.128.1.53 > 192.168.128.2.21102: 7639* 1/1/0
A 192.168.128.1 (71)
09:49:59.542612 IP 192.168.128.2.52455 > 192.168.128.1.53: 42047+
? gate.some.domain.org. (41)
09:49:59.542792 IP 192.168.128.1.53 > 192.168.128.2.52455: 42047* 0/1/0 
(88)


When reverting the server entry back to ntp.some.domain.org
it crashes and tcpdump shows:

09:36:05.172552 IP 192.168.128.2.17836 > 192.168.128.1.53: 49768+ A?
ntp.some.domain.org. (40)
09:36:05.173320 IP 192.168.128.1.53 > 192.168.128.2.17836: 49768*
2/1/0 CNAME gate.some.domain.org., A 192.168.128.1 (89)
09:36:05.173361 IP 192.168.128.2.22611 > 192.168.128.1.53: 63808+
? ntp.some.domain.org. (40)
09:36:05.173595 IP 192.168.128.1.53 > 192.168.128.2.22611: 63808*
1/1/0 CNAME gate.some.domain.org. (106)

The probability for crashing increases with the speed and the
number of cores of the machine: On my old single-core Pentiums
it never crashes, on my quad-cores i7-3770K it always crashes.

The (asynchronous) resolving of the names start in line 3876 of
ntp_config.c:

getaddrinfo_sometime(curr_peer->addr->address,

If we put the mlockall() call directly before this line, the
crash is gone.

Maybe you want to play around with rlimit, CNAMES, IPs and
so on...

-Andre

Anyone else seeing this?

2015-10-30 12:34, je David Wolfskill napisal
> On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote:
>> David Wolfskill  writes:
>> > ...
>> > bound to 172.17.1.245 -- renewal in 43200 seconds.
>> > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
>> > Starting Network: lo0 em0 iwn0 lagg0.
>> > ...
>>
>> Did you find a solution?  I'm wondering if the ntpd problems people
>> are
>> reporting on freebsd-security@ are related.  I vaguely recall hearing
>> that this had been traced to a pthread bug, but can't find anything
>> about it in commit logs or mailing list archives.
>> 
>
> I don't recall finding "a solution" per se; that said, I also don't
> recall seeing an occurrence of the above for enough time that I'm not
> sure when I sent that message. :-}
>
> As a reality check:
>
> g1-252(11.0-C)[1] ls -lT /*.core
> -rw-r--r--  1 root  wheel  13783040 Aug 18 04:19:03 2015 /ntpd.core
> g1-252(11.0-C)[2]
>
> So -- among other points -- my last sighting of whatever was causing
> that was the day I built:
>
> FreeBSD 11.0-CURRENT #157  r286880M/286880:1100079: Tue Aug 18
> 04:45:25 PDT 2015
> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>
> Note that the machines where I run head get updated daily (unless
> there's enough of a problem with head that I can't build it or can't
> boot it (and I'm unable to circumvent the issue within a reasonable
> time)) -- and while I do attempt to run ntpd on the machines, the above
> failure is more "annoying" than "crippling" in my particular case.
>
> And I'm presently running:
>

Re: 11.0-CURRENT r290273: installer fails with "out of swap space" error

[Mark Martinec]

On 2015-11-03 21:50, Maxim Pugachev wrote:

I tried to install r29273 into Parallels VM, but got an error on
"distextract" stage. Here is the last messages from bsdinstall_log:

DEBUG: f_debug_init: ARGV=[distextract] GETOPTS_STDARGS=[dD:]
DEBUG: f_debug_init: debug=[1] debugFile=[/tmp/bsdinstall_log]
DEBUG: Running installation step: distextract
Killed

Last message from /var/log/messages:

Nov  3 20:02:9  kernel: pid 967 (distextract), uid 0, was killed: out
of swap space

My VM has 2 gigs of memory, vmstat tells that I have ~537M free
(swapinfo tells nothing). I dunno is it a bug or I'm doing something
wrong.


Looks like the same issue as reported a year and a half ago:

https://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076732.html


  Mark
___
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: Tunnelling IPv4 over IPv6 for GitHub access?

[Mark Martinec]

Craig Rodrigues wrote:


I have some machines which are on an IPv6 only network.
It works great and I can access most things on the IPv6 Internet
that I need like Google ( [2607:f8b0:4004:808::1014]) , Facebook
([2a03:2880:1010:df05:face:b00c:0:2]), CNN ( [2620:100:e000::8001]), 
etc.


However, the one thing I cannot access is GitHub, which does not
support IPv6 ().

Is there a way that I can tunnel IPv4 over an IPv6 network?

I read this blog post:
http://www.aisecure.net/2013/02/03/tunneling-ipv4-over-ipv6-vpn/
and wasn't sure if this was an approach that I could use.


I don't see how a tunnel encapsulation would help here - you need to
translate between protocol families, as your client side is IPv6-only.

If all the traffic is HTTP then a web proxy like squid running
on a dual-stacked host would suffice. Otherwise a NAT64 (with DNS64)
is needed, like implemented in OpenBSD's pf (but not available
in FreeBSD's pf).

  Mark
___
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: Segmentation fault running ntpd

[Mark Martinec]

Not sure if it's the same issue, but it sure looks like it is.

I have upgraded a couple of hosts (amd64) from 10.2-RELEASE-p5
to 10.2-RELEASE-p6, i.e. the freebsd-upgrade essentially just
replaced the /usr/sbin/ntpd with a new one; then I restarted
the ntpd.

On all host but one this was successful: the new ntpd starts
fine and works normally. But on one of these machines the
ntpd process immediately crashes with SIGSEGV. That machine
has an Intel Xeon cpu. It is not apparent to me in what way
this machine differs from others,

Played with some variations of ntpd on that host, here are
some findings:

- the new ntpd (that came with 10.2-RELEASE-p6) runs fine
  if it does *not* daemonize, i.e. ntpd with an option -n or -d
  stays attached to a terminal and works fine; the same
  happens when run under ktrace -d -i ntpd  ... it works fine,
  even when it daemonizes;

- the ntpd built from fresh net/ntp-devel behaves exactly
  the same: crashes on that machine when it daemonizes

- a previous ntpd (from 10.2-RELEASE-p5) works fine,
  so I ended up downgrading ntpd to that previous version
  on that machine. Also a ntpd from a recent 10-STABLE
  when copied to that host runs fine there!

I haven't tried yet to build it with debugging, or capture
a core dump.

Puzzling...

   Mark



2015-10-30 12:34, je David Wolfskill napisal

On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote:

David Wolfskill  writes:
> ...
> bound to 172.17.1.245 -- renewal in 43200 seconds.
> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
> Starting Network: lo0 em0 iwn0 lagg0.
> ...

Did you find a solution?  I'm wondering if the ntpd problems people 
are

reporting on freebsd-security@ are related.  I vaguely recall hearing
that this had been traced to a pthread bug, but can't find anything
about it in commit logs or mailing list archives.



I don't recall finding "a solution" per se; that said, I also don't
recall seeing an occurrence of the above for enough time that I'm not
sure when I sent that message. :-}

As a reality check:

g1-252(11.0-C)[1] ls -lT /*.core
-rw-r--r--  1 root  wheel  13783040 Aug 18 04:19:03 2015 /ntpd.core
g1-252(11.0-C)[2]

So -- among other points -- my last sighting of whatever was causing
that was the day I built:

FreeBSD 11.0-CURRENT #157  r286880M/286880:1100079: Tue Aug 18
04:45:25 PDT 2015
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Note that the machines where I run head get updated daily (unless
there's enough of a problem with head that I can't build it or can't
boot it (and I'm unable to circumvent the issue within a reasonable
time)) -- and while I do attempt to run ntpd on the machines, the above
failure is more "annoying" than "crippling" in my particular case.

And I'm presently running:

FreeBSD 11.0-CURRENT #227  r290138M/290138:1100084: Thu Oct 29
05:12:58 PDT 2015
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

and building head @r290190 as I type.

And FWIW, I *suspect* that one of the issues involved (in my case)
was a ... lack of determinism ... in events involving getting the
(wireless) network connectivity into a usable state as part of the
initial transition to multi-user mode.  (I only have evidence at
the moment of the issue on my laptop; my build machine, which only
uses a wired NIC, has no /ntpd.core file.  It and my laptop are updated
pretty much in lock-step; it runs a completely GENERIC kernel, while
the laptop runs a modestly customized one based on GENERIC.)

Peace,
david

___
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: Some unresolved but important X.org problems

[Mark Martinec]

2015-02-11 Beeblebrox wrote:

I have been having problems described below since March of 2014, but
did not have much of an option other than to wait for gradual
improvements. Considering that 11 is nearing official RELEASE, I would
think these problems would be worth consideration. I'm posting in
current rather than xorg, because if there were many others with these
problems, it would have been brought up a long time ago.

PROBLEMS:
1. PDF viewers fail to display pdf/ps files correctly. Many files get
displayed as blank pages, and I can only get the pdf to display after
closing/re-opening the file several times, or by repeatedly scrolling
up/down past the seemingly blank page. Pages with an image have more
problems than pages with text-only.

2. With the exception of Opera (which is out-dated), all remaining
Browsers fail to display most web pages in a sane manner (Firefox,
Seamonkey, Epiphany, Midori). Chrome is the worst because even with
just a blank page it flickers, goes completely white, comes back as a
partial image and sometimes locks X for 1/2 second or so.
Problems with the other browsers usually have something to do with
sites using php (rather than static content) and I have many problems
with images being correctly displayed. Among the symptoms:
* Page phases out. Mouse-over or scroll up/down resets the display

[...]

Some of the symptoms that you describe sound familiar.
I was using FreeBSD 10-STABLE with GeForce 7600 GS and the 'nv' driver.
After upgrading x11/xorg in December 2014:

  /usr/ports/UPDATING:
  20141219:
AFFECTS: users of x11/xorg and all xorg ports
AUTHOR: dumbb...@freebsd.org
The X.Org server (x11-servers/xorg-server) is updated to 1.14.

the effect was that while editing a text with emacs, large parts
of the editing window would disappear / fail to refresh (like after
scrolling) and would remain of the background color. Stepping with
a cursor through 'hidden' lines would get them redrawn one after
another. I guess this matches your statement "Page phases out.
Mouse-over or scroll up/down resets the display". And yes, Opera
kept working fine. Don't remember how other browsers and okular
behaved - if necessary, I can try switching back to 'nv' for a test.

I 'solved' my problem by switching from 'nv' to nvidia-304 driver,
which works fine with GeForce 7600 GS (but not with GeForce 7300 GT).

  Mark




(midori-on-linuxquestions.png:
https://drive.google.com/file/d/0Bxs_eepbMt6qNTdaQm1pTFZTMWM/view?usp=sharing)
* PHP sites either loose track of last scroll point and jump appx one
page up (example Facebook goes up 4-5 posts to what I just read and
repeats action as I try to scroll down), OR they are only partially
displayed and need to be either refreshed (F5) or up/down scrolling to
get some kind of display (epiphany-on-forums.freebsd.png:
https://drive.google.com/file/d/0Bxs_eepbMt6qbFJWMW1RZzJsYVU/view?usp=sharing)
* I get the same problem when trying to view an image, or a site with
many images. The tab with the image displays one of: a black screen, a
single color with vertical interference lines, or a mixture
(seamonkey-google-image-search.png:
https://drive.google.com/file/d/0Bxs_eepbMt6qUUJvem11U3c3MVk/view?usp=sharing)
* As a result of all the above, logging in to sites, doing any
transactions which require clicking buttons and check-boxes or filling
text fields becomes extremely difficult.

3. In Gnome3, menu text is garbled (gnome3-text.png:
https://drive.google.com/file/d/0Bxs_eepbMt6qWklaSUZLd0luUFk/view?usp=sharing)

4. Chromium causes other programs to mis-behave and display gets
corrupted in the old Win-XP style (chrome-corruption.png:
https://drive.google.com/file/d/0Bxs_eepbMt6qMktnOWo3bV93SGM/view?usp=sharing)

5. An update about a month ago is causing problems with /dev/ums0 on
Desktop (not vt). When I move the mouse it sometimes gets stuck on a
menu item of a program or an item on the Browser (for example a result
in google search). I have to move the mouse and repeat the previous
action in order to get it unstuck. Sticky lasts about 1/5 of a second.

6. Last week I was getting jpeg file corruption when doing simple
processing (crop, rotate) in graphics/gthumb. Resulting file would
have vertical interference lines. After updating the ports/packages
yesterday I don't get that now. Probably unrelated, but worth
mentioning.

MY_SYSTEM:
+ Desktop is usually Fluxbox. Free Memory was 5 GB when screen shots
were taken (not a low-mem issue).
+ GPU is RS880 [Radeon HD 4250], with loaded modules: drm2.ko, agp.ko,
radeonkms.ko, radeonkmsfw_RS780_pfp.ko, radeonkmsfw_RS780_me.ko,
radeonkmsfw_R600_rlc.ko
+ These already in /etc/sysctl.conf:
#_Enhance shared memory X11 interface
kern.ipc.shmmax=67108864
kern.ipc.shmall=32768
#_Enhance desktop responsiveness under high CPU use (200/224)
kern.sched.preempt_thresh=224
#_chromium_browser_issue
kern.ipc.shm_allow_removed=1


___
freebsd-current@freebsd.org mailing list
h

Memory corruption in a master perl process after child exits - only under FreeBSD 10.0 amd64 (not in 10.1 or 9.*)

[Mark Martinec]

There is a problem report since July 2014 in a Perl bug tracker,
which seems to affect only FreeBSD 10.0 amd64 (regardless of a
version of Perl or usage of clang vs. gcc compiler):

  https://rt.perl.org/Ticket/Display.html?id=122199

I wonder if someone intimately familiar with handling of virtual
memory, fork, swap, and process exit / wait(2) under FreeBSD
would be able to recognize what has changed in these areas between
9.2 -> 10.0 and 10.0 -> 10.1, so that only 10.0 is misbehaving,
but 10.1 apparently fixed the problem again.

Below is my short summary of the issue (it is the last comment
in the referenced problem report). Further details are in that PR.

It's been a real mystery, difficult to reproduce, but definitely there.
It might be a Perl bug, but it looks ever more likely that it is
a FreeBSD issue.

  Mark



After upgrading to FreeBSD 10.1 (from 10.0) and running the same 
application
with the same version of Perl for two months now, with child process 
periodic
retiring and re-spawning new child process by a master process as 
previously

under FreeBSD 9.x, I can now confirm that the problem no longer occurs.

I can also confirm that the problem under 10.0 can be avoided by
not letting child processes to voluntarily exit, so the master process
never sees a child termination in wait() and never needs to spawn (fork)
another child process.

A brief summary of the problem:

Setup: an application consisting of a master perl process spawning 
worker

child processes, which periodically voluntarily self-terminate, to be
replaced by a fresh child process forked from the master process.

Environent:
- occurs only on FreeBSD 10.0 amd64, any recent version of perl, gcc or 
clang.
- does not occur on FreeBSD 9.x or 10.1, and not on i383, not 
reproducible

  on Linux

What seems to be happening:
- a child process after doing some work (possibly touching swap)
  does a normal exit;
- a parent process gets a SIGCHLD signal, handles a wait() and
  for some obscure reason some of its memory gets corrupted;
- a parent process forks creating a new worker child process,
  which inherits corrupted sections of parent's memory,
  consequently later leading to its (child) crash if it happens
  to use that part of the memory (opcodes or data structures)
  during its normal work. Any newly born child process inherits
  the same memory corruption and crashes alike.

So it seems the problem is somehow connected with how FreeBSD 10.0
on amd64 manages virtual memory (fork, exit, wait, possibly
involving swap). The problem is apparently fixed in 10.1, and
not present in 9.x. Does anybody have a sound explanation?
___
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: DigitalOcean offers VMs with FreeBSD!

[Mark Martinec]

But here are some thread about FreeBSD is way slower than Linux
in these virtual installations



https://news.ycombinator.com/item?id=487


May be IOPS quotation? Can you test with dd and custom kernel with
MAXPHYS=1048576 ?


Don't know about DO, but networking over virtio is also slower
under VirtualBox (FreeBSD guest and host), compared to the
emulated em0.

  Mark
___
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: ssh None cipher

[Mark Martinec]

If the purpose of having a none cipher is to have a fast
file transfer, then one should be using  sysutils/bbcp
for that purposes. Uses ssd for authentication, and
opens unencrypted channel(s) for the actual data transfer.
It's also very fast, can use multiple TCP streams.

  Mark


On 10/18/14 06:10, Allan Jude wrote:

On 2014-10-17 22:43, Benjamin Kaduk wrote:

On Fri, 17 Oct 2014, Ben Woods wrote:


Whilst trying to replicate data from my FreeNAS to my FreeBSD home theater
PC on my local LAN, I came across this bug preventing use of the None
cipher:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163127

I think I could enable the None cipher by recompiling base with a flag in
/etc/src.conf.


I agree.


Is there any harm in enabling this by default, but having the None cipher
remain disabled in /etc/ssh/sshd_config? That way people wouldn't have it
on my default, but wouldn't have to recompile to enable it.


I do not see any immediate and concrete harm that doing so would cause,
yet that is insufficient for me to think that doing so would be a good
idea.

-Ben
___
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"



I've been using openssh-portable from ports with the none cipher patch
to get around this.

IIRC, upstream openssh refuses to merge the none cipher patches "because
you shouldn't do that". But I'd vote for having it compiled in and just
disabled by default.

It will refuse to let you have a shell without encryption, and prints a
big fat hairy warning when encryption is disabled.



___
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: [CFT] SSP Package Repository available

[Mark Martinec]

2014-08-22 18:07, Dimitry Andric wrote:

On 21 Aug 2014, at 18:07, Bryan Drewery  wrote:

On 8/21/2014 10:53 AM, Bryan Drewery wrote:

On 8/21/2014 5:34 AM, Mark Martinec wrote:

Does clang (in 10-STABLE or CURRENT) support also the
option -fstack-protector-strong ?


Not sure if clang 3.4 has it, but I found a patch for it here:


I'm told that clang 3.5 has support for it. We do not (yet) have 3.5 
in

CURRENT.


Indeed, support for -fstack-protector-strong was added after clang 3.4.
Upstream is in the process of releasing clang 3.5; they're currently at
-rc3, and unless something weird happens, the actual release should be
soonish.

That said, it might take a while to get this version into the base
system, because there are some problems to overcome.  The major one
being, after 3.4 llvm and clang require a C++11-compatible compiler and
standard library to build. :-)

If there is a great demand for -fstack-protector-strong support, I can
see if it can be backported to our 3.4 version.


Don't know how much demand there is. Just these days I was investigating
what looks like a memory corruption in perl under FreeBSD 10, and 
realized

the -fstack-protector-strong would be just the right thing to try first.
(I ended up recompiling perl with gcc48).

Just some random references I came across:

https://en.wikipedia.org/wiki/Buffer_overflow_protection
  All Fedora packages are compiled with -fstack-protector since Fedora
  Core 5, and -fstack-protector-strong since Fedora 20. [...] All Arch
  Linux packages built since 4 May 2014 use -fstack-protector-strong.

https://fedorahosted.org/fesco/ticket/1128
  Benefit over the current default "-fstack-protector" => 
"-fstack-protector"

  is regarded as "not secure enough" (only "protects" < 2% functions in
  Chromium project). "-fstack-protector-strong" hits the balance between 
the
  over-simplified "-fstack-protector" and over-killing 
"-fstack-protector-all".

  [...]
  The stack-protector option is over-simplified, which ignores pointer 
cast,

  address computation, while the stack-protector-all is over-killing,
  using this option results in too much performance overhead.

http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/
  A normal x86_64 “defconfig” build, without stack protector had
  a kernel text size of 11430641 bytes with 36110 function bodies.
  Adding CONFIG_CC_STACKPROTECTOR_REGULAR increased the kernel text
  size to 11468490 (a +0.33% change), with 1015 of 36110 functions
  stack-protected (2.81%). Using CONFIG_CC_STACKPROTECTOR_STRONG
  increased the kernel text size to 11692790 (+2.24%), with 7401
  of 36110 functions stack-protected (20.5%). And 20% is a far-cry
  from 100% if support for -fstack-protector-all was added back
  to the kernel.



If there is a great demand for -fstack-protector-strong support,
I can see if it can be backported to our 3.4 version.


I guess the answer to that question is whether the goal/wish of
a default WITH_SSP_PORTS / SSP_CFLAGS would be to switch to
the -fstack-protector-strong before clang 3.5 comes into base.

  Mark
___
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: [CFT] SSP Package Repository available

[Mark Martinec]

Bryan Drewery wrote:

Ports now support enabling Stack Protector [1] support on FreeBSD 10
i386 and amd64, and older releases on amd64 only currently.

Support may be added for earlier i386 releases once all ports properly
respect LDFLAGS.

To enable, just add WITH_SSP=yes to your make.conf and rebuild all 
ports.


The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
may optionally be set instead.


That's probably SSP_CFLAGS, not SSP_CLFAGS.


Does clang (in 10-STABLE or CURRENT) support also the
option -fstack-protector-strong ?

Is 'world' by default compiled with -fstack-protector
(and if not, why not).

  Mark
___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Mark Martinec]

me wrote:
we are talking about NAT64 (IPv6-only datacenter's path to a legacy 
world),
and NPT66 (prefix transalation). I doubt anyone had a traditional NAT 
in mind.


Kevin Oberman wrote:
No, all of the messages in the thread are specific about NAT66, not 
NPT66.

NPT66 may have real value. I hate it, but it may well be better than
alternatives. [...]


Cy Schubert wrote:
That I don't disagree with, IPv6 NAT makes no logical sense. Having 
said

that I've received emails asking about NAT66 specifically. It is on
people's minds.


My impression is that often the term NAT66 is used indiscriminately,
even when NPT66 (static prefix translation) is meant.

  Mark
___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Mark Martinec]

On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed  
wrote:

[...]
IPFilter 5 does IPv6 NAT.

With the import of 5.1.2, map, rdr and rewrite rules will all work 
with

IPv6 addresses.

NAT66 is a specific implementation of IPv6 NAT behaviour.


2014-07-29 00:07 Kevin Oberman wrote:
And all IPv6 NAT is evil and should be cast into (demonic residence of 
your

choosing) on sight!

NAT on IPv6 serves no useful purpose at all. It only serves to 
complicate
things and make clueless security officers happy. It adds zero 
security. It
is a great example of people who assume that NAT is a security feature 
in

IPv4 (it's not) so it should also be in IPv6.

The problem is that this meme is so pervasive that even when people
understand that it is bad, they still insist on it because there will 
be an
unchecked box on the security checklist for "All systems not pubic 
servers
are in RFC1918 space? -- YES   NO". The checklist item should be 
(usually)
"All systems behind a stateful firewall with an appropriate rule set? 
--

YES  NO" as it is a stateful firewall (which is mandatory for NAT that
provides all of the security.

I say "usually" because the major research lab where I worked ran 
without a
firewall (and probably still does) and little, if any, NAT. It was 
tested

regularly by red teams hired by the feds and they never were able to
penetrate anything due to a very aggressive IDS/IPS system, but most 
people
and companies should NOT go this route. I have IPv6 at home (Comcast) 
and
my router runs a stateful firewall with a rule set functionally the 
same as

that used for IPv4 and that provides the protection needed.

So putting support for NAT66 or any IPv6 NAT into a firewall is just 
making

things worse. Please don't do it!
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com


You are missing the point, we are talking about NAT64 (IPv6-only 
datacenter's
path to a legacy world), and NPT66 (prefix transalation). I doubt anyone 
had

a traditional NAT in mind.

Consider a small site with uplinks to two service providers: it can use 
ULA

internally and translate prefix on each uplink.

Please see these short blogs:

- To ULA or not to ULA, That’s the Question
  
http://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question.html


- I Say ULA, You Hear NAT
  http://blog.ipspace.net/2014/01/i-say-ula-you-hear-nat.html

- PA, PI or ULA IPv6 Address Space? It depends
  
http://blog.ipspace.net/2014/01/pa-pi-or-ula-ipv6-address-space-it.html


- Source IPv6 Address Selection Saves the Day
  
http://blog.ipspace.net/2014/01/source-ipv6-address-selection-saves-day.html



Mark
___
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: zfs send/recv: STILL invalid Backup Stream

[Mark Martinec]

2014-07-25 15:41, Larry Rosenman wrote:

On Fri, Jul 25, 2014 at 11:58:48AM +0200, Mark Martinec wrote:

Don't know, I'd guess some network-related memory limit is being hit
on the sending site.

Why not try to decouple the 'zfs send' from a network copy and ssh:
Login to a remote side, do a 'zfs send' to some local temporary file
there, then feed that file to ssh and send it over to a home host,
where it can be piped into some simple program like md5 or 'wc -c'
instead of a zfs recv.


I think I've done that, but it sort of defeats the purpose,


Does it? If you are lucky it would fail again, but this time
you'd know if it was a zfs or a network problem.


as the stream becomes a big file on disk.


If it's an incremental stream and you have sufficient free space
available, than it's all fine and you should try that. If storage
is a problem you may try piping /dev/zero or /dev/random through
ssh to feed a remote consumer, simulating a huge stream, and hope
that it will eventually fail.


I'd like to get some help chasing what parameter(s) need to be fixed 
here.

[...]

Can I get some ideas on:
1) what MIGHT need tweaking
2) would (k|d)trace help?
3) what else could we find out what's being told no memory?


Sorry, not deep enough into fs or network to be able to tell.

My guess it that it's a networking issue (not zfs), and not
directly related to virtual memory or swap or ARC management.


To: freebsd-current@freebsd.org, Freebsd fs 


If you'd be able to demonstrate that this is unrelated to zfs,
then the freebsd-...@freebsd.org mailing list would perhaps be
a suitable place to continue this thread.

  Mark
___
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: zfs send/recv: STILL invalid Backup Stream

[Mark Martinec]

On 2014-07-24 19:56, Allan Jude wrote:

or better yet:
  ssh r...@tbh.lerctr.org "zfs send ..." | mbuffer -m 16M | zfs recv 
...

(The misc/mbuffer compensates for bursty zfs reads and writes.
 A note to myself: I should suggest to Allan to add mbuffer
 in a pipe as used in sysutils/zxfer, instead of patching zxfer
 for our local use :)


zxfer can already do this, with the -D option
I actually use misc/clpbar and get a progress bar as well

-D 'bar -s %%size%% -bl 1m -bs 128m'

or in your case: -D 'mbuffer -m 16M'


Thank you Allan! It shows it's been a while since the last time
I inspected the guts of zxfer.



2014-07-25 06:43 Larry Rosenman wrote:
Ok, I did the mbuffer trick, and the SEND side is where the memory 
issue is:

borg.lerctr.org /home/ler/bin $ tail zfs-send.log
23:28:12   15.7G   zroot/home@2014-07-24_22:56
23:28:13   15.7G   zroot/home@2014-07-24_22:56
23:28:14   15.7G   zroot/home@2014-07-24_22:56
23:28:15   15.7G   zroot/home@2014-07-24_22:56
23:28:16   15.7G   zroot/home@2014-07-24_22:56
23:28:17   15.7G   zroot/home@2014-07-24_22:56
23:28:18   15.7G   zroot/home@2014-07-24_22:56
23:28:19   15.7G   zroot/home@2014-07-24_22:56
23:28:20   15.8G   zroot/home@2014-07-24_22:56
Write failed: Cannot allocate memory
borg.lerctr.org /home/ler/bin $


Good information. So the "Write failed: Cannot allocate memory"
on the send side is what is causing the "invalid backup stream"
on the receiving side.



borg.lerctr.org /home/ler/bin $ tail zfs-recv.log
cannot receive new filesystem stream: invalid backup stream
borg.lerctr.org /home/ler/bin $

borg.lerctr.org /home/ler/bin $  cat backup-TBH-ZFS-initial.sh
#!/bin/sh
DATE=`date "+%Y-%m-%d_%H:%M"`
#DATE2=2013-03-24
#DATE2=`date -v "-1d" "+%Y-%m-%d"`
# snap the source
ssh r...@tbh.lerctr.org zfs snapshot -r zroot@${DATE}
# zfs copy the source to here.
ssh r...@tbh.lerctr.org 2>zfs-send.log "zfs send  -v -R zroot@${DATE} " 
| \

 mbuffer -m 16M 2>mbuffer.log | \
 zfs recv -F -u -v -d zroot/backups/TBH3 2>zfs-recv.log
# make sure we NEVER allow the backup stuff to automount.
/sbin/zfs list -H -t filesystem -r zroot/backups/TBH3| \
awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh
borg.lerctr.org /home/ler/bin $

borg.lerctr.org /home/ler/bin $ ssh tbh vmstat -z
ITEM   SIZE  LIMIT USED FREE  REQ FAIL 
SLEEP

[...]

Where to now?


Don't know, I'd guess some network-related memory limit is being hit
on the sending site.

Why not try to decouple the 'zfs send' from a network copy and ssh:
Login to a remote side, do a 'zfs send' to some local temporary file
there, then feed that file to ssh and send it over to a home host,
where it can be piped into some simple program like md5 or 'wc -c'
instead of a zfs recv.

  Mark
___
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: zfs send/recv: STILL invalid Backup Stream

[Mark Martinec]

2014-07-25 01:36 Larry Rosenman wrote:


#!/bin/sh
DATE=`date "+%Y-%m-%d"`
#DATE2=2013-03-24
#DATE2=`date -v "-1d" "+%Y-%m-%d"`
# snap the source
ssh r...@tbh.lerctr.org zfs snapshot -r zroot@${DATE}
# zfs copy the source to here.
ssh r...@tbh.lerctr.org "zfs send  -v -R zroot@${DATE} | \
 ssh home.lerctr.org \"zfs recv -F -u -v -d zroot/backups/TBH2\""


Btw, this double-ssh looks awkward, why not just:

  ssh r...@tbh.lerctr.org "zfs send ..." | zfs recv ...

or better yet:

  ssh r...@tbh.lerctr.org "zfs send ..." | mbuffer -m 16M | zfs recv ...

(The misc/mbuffer compensates for bursty zfs reads and writes.
 A note to myself: I should suggest to Allan to add mbuffer
 in a pipe as used in sysutils/zxfer, instead of patching zxfer
 for our local use :)

Mark
___
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: zfs send/recv: STILL invalid Backup Stream

[Mark Martinec]

2014-07-24 21:57, Larry Rosenman wrote:

Sending zroot/home@zxfer_26699_20140724135840 to 
zroot/backups/TBH/zroot/home.

Write failed: Cannot allocate memory

  

cannot receive new filesystem stream: invalid backup stream
Error when zfs send/receiving.
borg.lerctr.org /home/ler #

well that's different...


Sounds familiar, check my posting of today and links therein:
  http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html



I'm not using netgraph to the best of my knowledge


Check to make sure:
  vmstat -z | fgrep NetGraph


and the only fails on the SENDING host are:
8 Bucket:64,  0,  41,3555,  257774,  11,   
0
12 Bucket:   96,  0,  96,2569,  123653,   0,   
0
16 Bucket:  128,  0,   17195, 506,  215573,   0,   
0
32 Bucket:  256,  0, 340,4670,  900638,  50,   
0

64 Bucket:  512,  0,   10691, 365,  546888,185232,
0
128 Bucket:1024,  0,3563, 905,  348419,   0,   
0

256 Bucket:2048,  0,2872, 162,  249995,59834,
0
vmem btag:   56,  0,  192811,   51500,  502264,1723,   
0



Adam Vande More gave other suggestions on that thread from 2011:

  
http://lists.freebsd.org/pipermail/freebsd-emulation/2011-July/008971.html



Mark
___
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: zfs send/recv: STILL invalid Backup Stream

[Mark Martinec]

2014-07-24 21:31, Larry Rosenman wrote:

borg.lerctr.org /home/ler # zxfer -dFkPvs -g 376 -O
r...@tbh.lerctr.org -R zroot  zroot/backups/TBH
Creating recursive snapshot zroot@zxfer_26699_20140724135840.
Checking grandfather status of all snapshots marked for deletion...
Grandfather check passed.
Sending zroot@zxfer_26699_20140724135840 to zroot/backups/TBH/zroot.
Sending zroot/ROOT@zxfer_26699_20140724135840 to 
zroot/backups/TBH/zroot/ROOT.

Sending zroot/ROOT/default@zxfer_23699_20140724134435 to
zroot/backups/TBH/zroot/ROOT/default.
Sending zroot/ROOT/default@zxfer_26699_20140724135840 to
zroot/backups/TBH/zroot/ROOT/default.
  (incremental to zroot/ROOT/default@zxfer_23699_20140724134435.)
Sending zroot/home@zxfer_26699_20140724135840 to 
zroot/backups/TBH/zroot/home.



Write failed: Cannot allocate memory

  


cannot receive new filesystem stream: invalid backup stream
Error when zfs send/receiving.
borg.lerctr.org /home/ler #

well that's different...


Sounds familiar, check my posting of today and links therein:

  http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html

Mark
___
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: CURRENT: why is CURRENT swapping so fast?

[Mark Martinec]

me wrote:

Is this also fixed in the 10.0-STABLE by now?

The situation does not improve by itself, ARC has it all, less
active jobs scramble and fight for whatever free memory is left for
them and most of them remain swapped out. The best curse of action
to recover is to reboot. Quite a pain.


On 2014-06-14 17:29, Matthew D. Fuller wrote:

You may want to check out
 which I
believe is related.  Make sure you get the latest patch rather than
the older one, ref's in comment 10 at
.


Great, thank you, will apply it in the coming days.

One would hope that such a serious pathological behaviour
(in 10-STABLE and 11) would get the patch applied by now
(patch available for two months now, problem described in March),
or the former logic reverted.


I have this patch on a fresh 10.0-STABLE running now for five days,
and things have improved significantly. Inactive processes are still
swapped out, but ARC no longer monopolizes all it can grab, and newly
activated processes get a chance to run quickly. Running a busy
poudriere build no longer leaves the system in unusable state
after it finishes.

I hope this gets rolled into 10.0-STABLE soon.

  Mark
___
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: CURRENT: why is CURRENT swapping so fast?

[Mark Martinec]

me wrote:
>> Is this also fixed in the 10.0-STABLE by now?
>>

The situation does not improve by itself, ARC has it all, less
active jobs scramble and fight for whatever free memory is left for
them and most of them remain swapped out. The best curse of action
to recover is to reboot. Quite a pain.


On 2014-06-14 17:29, Matthew D. Fuller wrote:

You may want to check out
 which I
believe is related.  Make sure you get the latest patch rather than
the older one, ref's in comment 10 at
.


Great, thank you, will apply it in the coming days.

One would hope that such a serious pathological behaviour
(in 10-STABLE and 11) would get the patch applied by now
(patch available for two months now, problem described in March),
or the former logic reverted.

  Mark



___
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: CURRENT: why is CURRENT swapping so fast?

[Mark Martinec]

On 2014-06-12 2:26, Steven Hartland wrote:

Also how recent a current there where some vm changes which apparently
helped with this
specifically r260567 and r265944.


Is this also fixed in the 10.0-STABLE by now?

I'm running "10.0-STABLE #0 r266449 May 19" (with ZFS and
16 MB of memory) and I'm noticing pretty much what O. Hartmann
describes (since a couple of weeks or maybe a month ago).

When some bulky operation (like a poudriere build) runs, some
inactive processes are swapped out. This is just fine, but when
the bulky task is finished, the ARC extends to the new released
memory, but the swapped out jobs then struggle for memory
when they become active again. It can take a minute for a
sshd (login from remote) to respond with a prompt, and it can
take long minutes for a swapped out SQL database (not large)
or a web browser to become responsive again. The situation
does not improve by itself, ARC has it all, less active jobs
scramble and fight for whatever free memory is left for them
and most of them remain swapped out. The best curse of action
to recover is to reboot. Quite a pain.

  Mark
___
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: 10-RC unable to build kernel without INET (i.e. IPv6-only)

[Mark Martinec]

Gleb,

> On Tue, Dec 17, 2013 at 08:13:20PM +0100, Mark Martinec wrote:
> M> Under 9.2 the following could be used to build an IPv6-only kernel:
> M>   include GENERIC
> M>   makeoptions   MKMODULESENV+="WITHOUT_INET_SUPPORT="
> M>   nooptions   INET
> M> Now with stable/10 ... fails while building xen support:
> 
> Just fixed that in stable/10.
> I expect we will merge the patch to release branch as well.

Perfect, builds and works very well now!
Thank you for a very quick response!

  Mark
___
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"

10-RC unable to build kernel without INET (i.e. IPv6-only)

[Mark Martinec]

Under 9.2 the following could be used to build an IPv6-only kernel:

/sys/amd64/conf/TEST :

include GENERIC
makeoptions   MKMODULESENV+="WITHOUT_INET_SUPPORT="
nooptions   INET


Now with stable/10 the:

  make buildkernel KERNCONF=TEST

fails while building xen support:

[...]
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99 -g -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -
Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-error-tautological-compare 
-Wno-error-empty-body  -Wno-error-
parentheses-equality  -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx 
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
-fno-asynchronous-unwind-
tables -ffreestanding -fstack-protector -Werror  
/usr/src/sys/dev/xen/control/control.c
ctfconvert -L VERSION -g control.o
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99 -g -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -
Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-error-tautological-compare 
-Wno-error-empty-body  -Wno-error-
parentheses-equality  -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx 
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
-fno-asynchronous-unwind-
tables -ffreestanding -fstack-protector -Werror  
/usr/src/sys/dev/xen/netback/netback.c
/usr/src/sys/dev/xen/netback/netback.c:2244:8: error: use of undeclared 
identifier 'ifr'
if (ifr->ifr_reqcap & IFCAP_TXCSUM) {
^
/usr/src/sys/dev/xen/netback/netback.c:2251:9: error: use of undeclared 
identifier 'ifr'
if ((ifr->ifr_reqcap & IFCAP_RXCSUM)) {
 ^
/usr/src/sys/dev/xen/netback/netback.c:2284:18: error: use of undeclared 
identifier 'ifr'
ifp->if_mtu = ifr->ifr_mtu;
  ^
/usr/src/sys/dev/xen/netback/netback.c:2292:31: error: use of undeclared 
identifier 'ifr'
error = ifmedia_ioctl(ifp, ifr, &xnb->sc_media, cmd);
   ^
4 errors generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/sys/TEST
*** Error code 1



  Mark
___
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: ipfilter(4) needs maintainer

[Mark Martinec]

On Monday April 15 2013 12:32:37 Lev Serebryakov wrote:
> And, yes, NAT64 will be useful for sure, but it is another story,
> not IPv6<->IPv6 translation.

Fear not, NPT66 prefix translation is stateless,
this is nothing like NAT44 / NAPT.

On Monday April 15 2013 12:51:00 sth...@nethelp.no wrote:
> We are *way* too late in the game to completely avoid IPv6 NAT.
> Various flavors already exist in the form of RFCs, e.g. NPTv6:
>   http://tools.ietf.org/html/rfc6296

Prefix translation is useful for SOHO or branch offices with
more than one uplink, unless one wants to invest into AS and BGP
or start building tunnels:

  http://blog.ioshints.info/2011/12/we-just-might-need-nat66.html


Mark
___
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: ipfilter(4) needs maintainer

[Mark Martinec]

On Sunday April 14 2013 19:30:22 wishmaster wrote:
> > Do we honestly need three packet filters?
> Yes! This is the most clever thought in this thread. Why we need 3
> firewalls? Two packet filters it's excess too. We have two packet filters:
> one with excellent syntax and functionality but with outdated bandwidth
> control mechanism (aka ALTQ); another - with nice traffic
> shaper/prioritization (dummynet)/classification (diffused) but with
> complicated implementation  in not trivial tasks. May be the next step
> will be discussion about one packet filter in the system?..

... and as far as I can tell none of them is currently usable
on an IPv6-only FreeBSD (like protecting a host with sshguard),
none of them supports stateful NAT64, nor IPv6 prefix translation :(

  Mark
___
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: FreeBSD services startup problems

[Mark Martinec]

On Thursday December 27 2012 00:33:25 Derrick Dantavious Edwards wrote:
> Hi,
> I am having problems with startup services in FreeBSD current. I am at a
> loss on where the problem lies. Even though I have services explicitly
> defined in rc.conf for startup they do not start. Startup scripts both
> in /etc/rc.d (powerd/moused) and /usr/local/etc/rc.d (dbus,hald, and gdm
> ) are experiencing this. Initially, I checked out my rc.conf file as
> well as the /etc/defaults/rc.conf because I continue to get this
> message.
> 
> /etc/rc: WARNING: $auditdistd_enable is not set properly - see
> rc.conf(5).
> [...]

Forgot to run mergemaster -p  ?


/usr/src/UPDATING

20121218:
  With the addition of auditdistd(8), a new auditdistd user is now
  depended on during installworld.  "mergemaster -p" can be used to
  add the user prior to installworld, as documented in the handbook.


Mark
___
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: Upgrading FreeBSD to use the NEW pf syntax.

[Mark Martinec]

Paul Webster wrote:
> I am aware this is a much discussed subject since the upgrade of PF,
> I believe the final decision was that too many users are used to the old
> style pf and an upgrade to the new syntax would cause too much confusion.

I don't buy that. Think of a confusion in a year of two when
OpenBSD PF rules and the PF documentation won't match the
legacy syntax in FreeBSD's PF.


Maxim Khitrov wrote:
> > 1) To move to the newer pf and just add to releases notes what had
> > happened,
> My vote is for option 1, but I'll also be happy with option 2 if it
> costs little to maintain both versions. I'm pretty much for anything
> that brings pf in sync (or close to it) with OpenBSD.

My sentiments exactly.


Olivier Smedts wrote:
> But a change like this is expected in a new major branch, ie.
> 10-CURRENT. Not so in -STABLE branches of course. I don't see the
> problem here.

Indeed.


Gary Palmer wrote:
> So you don't expect people to upgrade boxes in place?
> I also guess you've never been 5,000 miles away from a box and typo'd
> something in the firewall and locked yourself out.  The think how tons
> of FreeBSD users would feel if the default pf syntax was changed to be
> incompatible and they find themselves in a similar situation after an
> upgrade.

The risk of locking oneself out even on minor fiddling with fw rules
on a remote machine, let alone upgrading its OS, is something that
every administrator is already aware if. Working without a safety net
is unwise for a hobbyist, and unacceptable for a professional.
I don't think the above argument holds water.

 
Olivier Smedts wrote:
> Another question : how did OpenBSD managed this change ?

This is from  http://www.openbsd.org/faq/upgrade46.html
|
| If you reboot your system without a usable pf.conf file in place, your pf
| rules will not be loaded, and you will end up using the default rule set,
| which will block all traffic EXCEPT for ssh over the standard port 22.
| This means that if you do not fix your pf.conf rules before rebooting,
| you may be greeted by a box that does not even respond to pings.
| Do not panic, as you can still ssh to the box, assuming you have sshd(8)
| listening on the usual port.


Gary Palmer wrote:
> The other question that I haven't seen answered (or maybe even asked), but
> is relevant: what do we gain by going to a later version of pf?  I.e. as an
> administrator, what benefit do I get by having to expend effort converting
> my filter rules?

For one thing, I'm desperately awaiting NAT64 support (the 'af-to'
translation rule in newer pf (5.1?), committed on 2011-10).

Other: packet normalization (scrub) has been reworked and simplified,
and is now a rulset option. Considering that scrub is currently broken
(9.1, see list of PF bugs in FreeBSD), along with several other
bugs that need fixing, it seems the (scarce) manpower would better
be spent in moving on, than keeping the already leaky (buggy) pf
afloat.

I think the compatibility issue should not be used as an excuse
for not moving on. You can't make an omelette without breaking eggs.

  Mark
___
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: (was: Announcing the end of port CVS) no IPv6 mirrors for portsnap.FreeBSD.org

[Mark Martinec]

> For those reasons by February 28th 2013 the FreeBSD ports tree will
> no longer be exported to CVS. Therefore ports tree updates via CVS
> or CVSup will no longer available after that date. All users who use
> CVS or CVSup to update the ports tree are encouraged to switch to
> portsnap(8) [1] or for users which need more control over their ports
> collection checkout use Subversion directly:

On an IPv6-only host (9.1-RC1) :

  # portsnap fetch
  Looking up portsnap.FreeBSD.org mirrors... none found.
  Fetching snapshot tag from portsnap.FreeBSD.org... failed.
  No mirrors remaining, giving up.


csup works fine:

  # csup /etc/cvsup/ports
  Connected to 2001:15c0::f::9
  Updating collection ports-all/cvs
  Edit ports/MOVED
  Cleaning up ...


If portsnap wants to become a mainstream ports update channel,
it should be accessible over IPv6 too.

  Mark
___
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: Bug in Perl script

[Mark Martinec]

Alexander,

> I have a script that runs command tail with open descriptor.
> After 30 seconds, I close descriptor.  But descriptor not closed.
> When script is closed tail is present in ps aux.
> 
> $log_file = path_to_log;
> eval {
> local $SIG{ALRM} = sub { die; };
> alarm (30);
> open (LOG, "tail -F $log_file|") || die "Сan`t open logfile
> \"$log_file\"";
> while () {
> ***
> }
> alarm (0);
> };
> close (LOG);
> print ("Ok\n");
> exit(0);
> 
> This code is good working in FreeBSD 8.2, but in FreeBSD 9.0 not working.

I don't see any difference in this respect between 8.2 and 9.0.

Even in 8.2 the spawned tail process stays alive until the moment
when it tries to write its next line to a pipe - only then it aborts
with 'Broken pipe'. On a busy log file this happens soon, on an
idling log file this may take forever.

You should abort the forked process when you no longer need it:

my $log_file = '/var/log/mail.log';
my $pid;
eval {
  local $SIG{ALRM} = sub { die "Time is up" };
  alarm(10);
  $pid = open(LOG, "tail -F $log_file|");
  $pid or die "Can't open logfile \"$log_file\": $!";
  while () {
print "HERE: $_";
  }
  alarm (0);
  1;
} or do {
  alarm (0);
  print "Bail out: $@";
};
if ($pid) {
  print "Terminating process [$pid]\n";
  kill('TERM',$pid);
}
close(LOG);
print "Ok\n";


  Mark
___
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: iSCSI initiator: iscontrol cannot be stopped or killed

[Mark Martinec]

Xin LI wrote:
> Try procstat -kk  to find the calling stack, as a start?
> This could be very useful when tracking down problems.
> Also the 'D' flag from ps(1) output in most times are not quite useful
> and ps -o wchan would tell you what exactly it was waiting for, just FYI.

Posted both a few days ago, you must have missed it.

Ivan Voras wrote:
> You should probably ask at the freebsd-scsi@ mailing list. From looking 
> at the code it looks like "ffp" is used for LUN scan timeout.

Done, posted to freebsd-scsi@ mailing list.
Thanks for the suggestion.

  Mark
___
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: bsdinstall guided partitioning should 4k-align swap and ufs partitions

[Mark Martinec]

> Seems to me the min(4KB,stripesize) would be a safe bet.

s/min/max/

  Mark
___
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: bsdinstall guided partitioning should 4k-align swap and ufs partitions

[Mark Martinec]

Nathan wrote:
> The installer will align all partitions to the GEOM stripesize/offset.
> We could make it do min(4KB, stripesize), but in general I think this is
> better done at the GEOM level.

I doubt any SSD device on the market will want to admit its
internal structure, they all claim 512 sectors AFAICT.
Seems to me the min(4KB,stripesize) would be a safe bet.

  Mark
___
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: bsdinstall guided partitioning should 4k-align swap and ufs partitions

[Mark Martinec]

> Btw (unrelated), tried the same with a 2 TB (virtual) disk, the
> guided partitioning suggested 64k boot, 2TB ufs, and 4GB swap,
> but then fails with "No free space left on device".
> Didn't investigate, looks like a bug.

Sorry, my mistake, please disregard this claim.
I chose "create" instead of "finish".

The rest of my posting (4k alignment) stands.

  Mark
___
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"

bsdinstall guided partitioning should 4k-align swap and ufs partitions

[Mark Martinec]

Using a guided partitioning install of 9.0-RC2 on a 64GB (virtual) disk
(from a 9.0-RC2 ISO image) results in the following GPT partitioning:

# gpart show /dev/ada0
=>   34  134217661  ada0  GPT  (64G)
 34128 1  freebsd-boot  (64k)
162  125828992 2  freebsd-ufs  (60G)
  1258291546709248 3  freebsd-swap  (3.2G)
  1325384021679293- free -  (820M)

This is most unfortunate for installations using 4kB sectored disks
or SSD disks, especially as the guided partitioning tool is
"recommended for beginners" - who may not be aware of performance
issues of using unaligned partitions on 4k sectored disk, or may
not be aware they are using such disks, or may not dare to venture
into manual partitioning.

Neither the freebsd-ufs partition, nor the freebsd-swap partition
are aligned on a 4k boundary - quite unnecessarily so.

At the expense of making the boot partition larger by 2 kB
or shrinking it by 2 kB, the rest would align just fine.
I see no ill effect for 512 B disks, but obvious benefit
for 4k disks.


Btw (unrelated), tried the same with a 2 TB (virtual) disk, the
guided partitioning suggested 64k boot, 2TB ufs, and 4GB swap,
but then fails with "No free space left on device".
Didn't investigate, looks like a bug.

  Mark
___
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: iSCSI initiator: iscontrol cannot be stopped or killed

[Mark Martinec]

> > If you can get it back into this state,
> 
> Sure, *every* time.
> 
> > a procstat -k -k  would be very helpful.
> > (the second -k is not a typo).
> 
> # procstat -k -k 5896
>   PIDTID COMM TDNAME   KSTACK
>  5896 102364 iscontrol-mi_switch+0x174
> sleepq_timedwait+0x42 _sleep+0x301 ic_init+0x2f1 iscsi_ioctl+0x525
> devfs_ioctl_f+0x7b kern_ioctl+0x115 sys_ioctl+0xfd amd64_syscall+0x450
> Xfast_syscall+0xf7

Additional info: the process is blocking on 'ffp', unresponsive to signals:

  UID   PID  PPID CPU PRI NIVSZRSS MWCHAN STAT  TT TIME COMMAND
0  5896 1   0  20  0  16424   1264 ffpDs??  0:00.04 
iscontrol -c /etc/iscsi.conf -n xxx


Mark
___
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: iSCSI initiator: iscontrol cannot be stopped or killed

[Mark Martinec]

On Thursday November 24 2011 01:35:28 Ryan Stone wrote:
> If you can get it back into this state,

Sure, *every* time.

> a procstat -k -k  would be very helpful.
> (the second -k is not a typo).

# procstat -k -k 5896
  PIDTID COMM TDNAME   KSTACK   
 5896 102364 iscontrol-mi_switch+0x174 
sleepq_timedwait+0x42 _sleep+0x301 ic_init+0x2f1 
iscsi_ioctl+0x525 devfs_ioctl_f+0x7b kern_ioctl+0x115 sys_ioctl+0xfd 
amd64_syscall+0x450 Xfast_syscall+0xf7


Thanks
  Mark
___
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"

iSCSI initiator: iscontrol cannot be stopped or killed

[Mark Martinec]

Problem: the iscontrol process starts normally and establishes
a session and brings up a device, but it cannot be stopped.
It does not react to a HUP signal, and neither to KILL.

The /dev/da0 device is operational and the remote disk remains
normally accessible, regardless of how I try to (unsuccessfully)
shutdown the iscontrol process. The ps reports the state of the
process as "Ds", not doing anything. A ktrace does not show any
reaction to a received signal. A restart seems to be necessary
to break the iSCSI session.

Using FreeBSD 9.0-rc2, amd64, also tried with 9.0-PRERELEASE
(csup tag=RELENG_9 as of today).  This used to work normally
as documented on the same host with the same iscsi.conf
config file before upgrading from 8.2 to 9.0.

Anybody else experiencing this problem? Suggestions welcome.

  Mark
___
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"

Upgrading 8.2 to 9.0-rc2: missing directories at 'make installkernel'

[Mark Martinec]

When upgrading a FreeBSD 8.2 (amd64) to today's csup (tag=RELENG_9,
i.e. 9.0-RC2), the standard procedure got itself into trouble:

  rm -rf /usr/obj
  make buildworld
  make buildkernel KERNCONF=xxx
  make installkernel KERNCONF=xxx

(the xxx is mostly a plain vanilla 'include GENERIC'
with pf altq and GEOM_ELI added).

The 'make installkernel' phase was failing on missing directories.
Creating these manually and repeating the make installkernel
eventually lead to a successful installation.

The missing directories that needed to be created manually were:

  /usr/include/clang  (and possibly /usr/include/clang/3.0 )
  /usr/include/gcc(and possibly /usr/include/gcc/4.2 )
  /libexec/resolvconf
  /usr/share/doc/llvm
  /usr/share/locale/la_LN.ISO8859-13/LC_COLLATE [...]

Actually the /usr/share/locale was a mess, missing several
files, so I ended up replacing this directory by what has been
built in the 'make buildworld' phase under /usr/obj.

Just wanted to point out a possible problem others may encounter.

  Mark
___
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: Support for newer Ethernet chips in RE(4) driver?

[Mark Martinec]

On Friday October 8 2010 19:00:45 Pyun YongHyeon wrote:
> Actually re(4) supports much more controllers than that.
> Man page needs updating to reflect this.

False alarm.  Indeed it does work with RTL8111E.
I was distracted by the lack of its mention on the man page, and
by the presence of a FreeBSD 8.0 re(4) driver on the Realtek's
web page, whose source code is much larger than the base driver
from the FreeBSD 8.1 distribution.

Updating the docs could help others deciding what hw to purchase
or what OS to run on it.

> Does stock re(4) fail to recognize your controller? If yes, please
> send me dmesg output (pciconf output is useless for RealTek
> controllers).

The same report in dmesg comes from using either the base
or the vendor's driver, so no problems there. Here it is anyway
(the second of the two ethernet controllers):

pcib8:  irq 17 at device 28.5 on pci0
pci8:  on pcib8
re1:  port 
0xbe00-0xbeff
 mem 0xfbaff000-0xfbaf,0xfbaf8000-0xfbafbfff irq 17 at device 0.0 on pci8
re1: Using 1 MSI messages
re1: Chip rev. 0x2c00
re1: MAC rev. 0x
miibus1:  on re1
rgephy1:  PHY 1 on miibus1
rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
re1: Ethernet address: 6c:f0:49:ef:99:e7
re1: [FILTER]

and ifconfig tells:

re1: flags=8843 metric 0 mtu 1500
  
options=389b
  ether 6c:f0:49:ef:99:e7
  inet6 fe80::6ef0:49ff:feef:99e7%re1 prefixlen 64 scopeid 0x2 
  inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255
  nd6 options=3
  media: Ethernet autoselect (1000baseT )
  status: active


Thanks for a prompt response!

  Mark
___
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"

Support for newer Ethernet chips in RE(4) driver?

[Mark Martinec]

The current re(4) Realtek Ethernet adapter driver supports the
8139C+/8169/816xS/811xS/8101E chips, but lacks support for newer
Realtek network interface controllers such as RTL8111 C/E/D,
the RTL8168 series and some other.

This is unfortunate as the RTL8111E and RTL8111D controllers
found their way (in singles or in pairs) into the current families
of GigaByte motherboards (such as GA-X58A-UD9/7/5/3R, GA-H55M*, ...),
and RTL8111C found its way into Asus motherboards (such as P6T),
and quite likely into other newer products.

An updated re driver source for FreeBSD 8.0 is available from
the Realtek's web site ( http://www.realtek.com.tw/downloads/ )
and claims to add support for chips and chipsets:

  RTL8111/RTL8111B/RTL8111C/RTL8111CP/RTL8111D(L)/RTL8111DP/RTL8111E
  RTL8168/RTL8168B/RTL8168C/RTL8168CP/RTL8168D/RTL8168E
  RTL8169S/RTL8169SB/RTL8169SC
  RTL8101E/RTL8102E/RTL8103E/RTL8401E/RTL8105E

I tested the new Realtek driver with RTL8111E on FreeBSD 8.1-RELEASE,
works well.

Any chance of importing the updated driver (or adding support
for newer chips in some other way) into CURRENT so that it
could find its way to the 9.0 ?

  Mark
___
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"