Re: HST time zone

[David Cornejo]

On Tue, Jul 25, 2023 at 11:01 AM Dimitry Andric  wrote:

> On 25 Jul 2023, at 22:26, David Cornejo  wrote:
> >
> > One thing that has bothered me for a long time is that the
> Pacific/Honolulu timezone is found under the America -- North and
> South/United States of America/Hawaii in tzsetup. Politics of Hawaiian
> Sovereignty aside, every other system I regularly install uses
> Pacific/Honolulu as it is in the official tzdb.
> >
> > Is there any reason why a patch to change to match the standard would be
> refused?
>
> Which version of FreeBSD are you using? On my 14-CURRENT box, Hawaii is
> actually found in *two* locations in tzsetup:
>
> * America -- North and South -> United States of America -> Hawaii
> * Pacific Ocean -> United States of America -> Hawaii
>

It just seems that the "standard" is Pacific/Honolulu and we are different
- in the IANA tz db, there is only mention of Pacific/Honolulu. While I'm
not saying they're correct, every Linux dist I've tried uses it. I have a
mixed shop, and every difference is a potential problem.

I doubt that this affects many people, so consistency would not seem a
hardship.

So that would serve all sides? :)
>
> As far as I can see, the menu is dynamically generated from
> /usr/share/zoneinfo/zone1970.tab, which has:
>
> US  +211825-1575130 Pacific/HonoluluHawaii
>
> and seems to be up-to-date with regards to the IANA tz files.
>
> -Dimitry
>
>

HST time zone

[David Cornejo]

Hi,

One thing that has bothered me for a long time is that the Pacific/Honolulu
timezone is found under the America -- North and South/United States of
America/Hawaii in tzsetup. Politics of Hawaiian Sovereignty aside, every
other system I regularly install uses Pacific/Honolulu as it is in the
official tzdb.

Is there any reason why a patch to change to match the standard would be
refused?

thanks,
dave c

-- 
Honolulu, Oʻahu, Hawaiʻi

Re: openssl 1.1.1 utils mkerr.pl

[David Cornejo]

On Wed, Jan 16, 2019 at 7:54 AM Benjamin Kaduk  wrote:
>
> On Wed, Jan 16, 2019 at 09:52:26AM -0800, Enji Cooper wrote:
> >
> > > On Jan 15, 2019, at 5:55 PM, David Cornejo  wrote:
> > >
> > > Hi,
> > >
> > > I am working on some code that wants to use mkerr.pl from the openssl
> > > distribution - but this appears to have been left out of the import to
> > > base.
> > >
> > > Is there an alternative method to create the include files produced
> > > from this script in FreeBSD?
> >
> >
> > Hi Dave,
> >
> > I would go a different route from what was mentioned by others — I would
> > actually either grab mkerr.pl from upstream from the release package
> > (upstream on GitHub is https://github.com/openssl/openssl/releases )
> > (sidenote: I don’t know why, but our vendor-crypto tree lacks this script
> > as well; jkim@ CCed). Why go this route? You can easily grab the file
>
> The script is used by upstream when preparing a release; we only use the
> finished release objects from upstream and do not expect to be doing this
> sort of "pre-release" step in our own operations.
>
> -Ben

thanks for the responses!

Let's say that this might become a port, so I'd create the output
files from mkerr.pl by pulling that script from upstream and then
include them in the files directory for installation?

thanks,
dave c

-- 
Kailua, Hawaiʻi
US +1 (808) 728-3050
UK +44 (020) 3286 2808
___
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"

openssl 1.1.1 utils mkerr.pl

[David Cornejo]

Hi,

I am working on some code that wants to use mkerr.pl from the openssl
distribution - but this appears to have been left out of the import to
base.

Is there an alternative method to create the include files produced
from this script in FreeBSD?

thanks,
dave c

-- 
Kailua, Hawaiʻi
US +1 (808) 728-3050
UK +44 (020) 3286 2808
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build error on current@r296308: 'yacc.h' file not found

[David Cornejo]

On Wed, Mar 2, 2016 at 11:04 AM, Bryan Drewery  wrote:
> On 3/2/2016 12:52 PM, Bryan Drewery wrote:
>> On 3/2/2016 11:00 AM, Kurt Jaeger wrote:
>>> Hi!
>>>
>>> Today, I upgraded to r296308 and had this failure during buildworld:
>>>
>>> ===> usr.bin/mkesdb_static (obj,build-tools)
>>> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static 
>>> -I/usr/src/usr.bin/mkesdb_static/../mkesdb  
>>> -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -std=gnu99  
>>> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o 
>>> lex.o
>>> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' 
>>> file not found
>>> #include "yacc.h"
>>> 1 error generated.
>>> *** Error code 1
>>>
>>> A 'script' output is available at 
>>> http://people.freebsd.org/~pi/logs/src-up-2
>>>
>>> Is it just me or ... ?
>>>
>>
>> My fault. I am working on a fix.
>>
>
> Fixed in r296324.
>
> --
> Regards,
> Bryan Drewery
>

fix worked, thank you for quick resolution!

dave c
___
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: spurious "Service Unavailable"

[David Cornejo]

Thanks for the replies

dave c



On Fri, Sep 20, 2013 at 2:11 AM, Dimitry Andric  wrote:

> On Sep 20, 2013, at 01:39, Glen Barber  wrote:
>
> > On Thu, Sep 19, 2013 at 01:29:35PM -1000, David Cornejo wrote:
> >> On CURRENT Revsion 255706
> >>
> >> I am trying to rebuild a bunch of ports in screen and I'm getting the
> >> string "Service unavailable" in the output between the package creation
> and
> >> the cleaning phases for each port:
> >>
> >> ===>   Generating temporary packing list
> >> install  -o root -g wheel -m 555   dialog4ports
> /usr/local/bin/dialog4ports
> >> install -o root -g wheel -m 444 dialog4ports.1.gz  /usr/local/man/man1
> >> ===>   Registering installation for dialog4ports-0.1.5_1 as automatic
> >> Installing dialog4ports-0.1.5_1... done
> >> ===>  Building package for dialog4ports-0.1.5_1
> >> Creating package for dialog4ports-0.1.5_1
> >> Service unavailable===>  Cleaning for dialog4ports-0.1.5_1
> >> --->  Cleaning out obsolete shared libraries
> >> --->  Reinstalling 'm4-1.4.16_1,1' (devel/m4)
> >> --->  Building '/usr/ports/devel/m4'
> >> ===>  Cleaning for m4-1.4.16_1,1
> >>
> >> Is this dangerous?  Anyone know what's making that happen?
> >>
> >
> > These are, as far as I can tell, harmless messages.  It is due to
> > libarchive and statically linked binaries (pig-static).
>
> See this recent thread:
> http://lists.freebsd.org/pipermail/freebsd-current/2013-August/043824.html
>
> It is a problem in our iconv implementation in libc, which should really
> be fixed before 10.0-RELEASE.
>
> -Dimitry
>
>
___
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"

spurious "Service Unavailable"

[David Cornejo]

On CURRENT Revsion 255706

I am trying to rebuild a bunch of ports in screen and I'm getting the
string "Service unavailable" in the output between the package creation and
the cleaning phases for each port:

===>   Generating temporary packing list
install  -o root -g wheel -m 555   dialog4ports /usr/local/bin/dialog4ports
install -o root -g wheel -m 444 dialog4ports.1.gz  /usr/local/man/man1
===>   Registering installation for dialog4ports-0.1.5_1 as automatic
Installing dialog4ports-0.1.5_1... done
===>  Building package for dialog4ports-0.1.5_1
Creating package for dialog4ports-0.1.5_1
Service unavailable===>  Cleaning for dialog4ports-0.1.5_1
--->  Cleaning out obsolete shared libraries
--->  Reinstalling 'm4-1.4.16_1,1' (devel/m4)
--->  Building '/usr/ports/devel/m4'
===>  Cleaning for m4-1.4.16_1,1

Is this dangerous?  Anyone know what's making that happen?

thanks,
dave c
___
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: system crashing while shuting down -> files system corruption

[David Cornejo]

On Fri, May 24, 2013 at 3:50 AM, O. Hartmann wrote:

> Since r250670 (last known stable) I face a lot of problems.
>
> On systems with SSD, after a couple of seconds the box is crashing and
> rebooting, showing up a lot of CAM/SCSI stuff on the console.
>
> A system with "traditional" disks I get while shutdown in progress (via
> ACPI power button or shutdown -p now command) corrupt filesystems (UFS
> disk).
>
> Below an error message after such a crahs, /usr/ports is a partition and
> while the shutdown was in effect, there were no activities on that
> partition, but is has been "repaired" while the box then powered up
> again. Now it seems to be corrupted in the way that I can not svn update
> the ports tree anymore.
>
> What happened?
>
>
> root@thor:/usr/ports # make update
> --
> >>> Updating /usr/ports using Subversion
> --
> cd /usr/ports; /usr/local/bin/svn update
> svn: E155036: Please see the 'svn upgrade' command
> svn: E155036: Working copy '/usr/ports' is an old development version
> (format 12); to upgrade it, use a format 18 client, then use
> 'tools/dev/wc-ng/bump-to-19.py', then use the current client
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports
>

Coincidentally, I get that exact same error message today when I exported
an SVN /usr/src tree to a raspberry-pi host from an amd64 system.  I tried
the script and it complains about I/O errors...

dave c
___
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: esxi - high system cpu load

[David Cornejo]

On Mon, Jan 7, 2013 at 12:46 PM, Chrysostomos Kanoulis  wrote:

> Hello,
>
> The following output is from a virtual machine on ESXi 4.1.
> I am experiencing high system cpu loads whenever i try to compile anything,
> making it difficult to even update the system.
>
>
> ---
> root@lab:~ # uname -a
> FreeBSD lab.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sun Dec 30
> 10:45:18 UTC 2012 
> r...@snap.freebsd.org:/usr/obj/i386.i386/usr/src/sys/GENERIC
>  i386
>
> ---
> root@lab:~ # top
> last pid: 45416;  load averages:  1.10,  1.08,  1.08
>
>   up 1+23:24:19  22:06:25
> 36 processes:  2 running, 34 sleeping
> CPU: 12.2% user,  0.0% nice, 87.8% system,  0.0% interrupt,  0.0% idle
> Mem: 273M Active, 62M Inact, 109M Wired, 11M Cache, 59M Buf, 27M Free
> Swap: 819M Total, 8996K Used, 810M Free, 1% Inuse
>
> ---
> root@lab:~ # vmstat 1
>  procs  memory  pagedisks faults
> cpu
>  r b w avmfre   flt  re  pi  pofr  sr da0 cd0   in   sy   cs
> us sy id
>  1 0 0398M37M   325   0   0   0   334   2   0   03   69  149
>  0  4 96
>  1 0 0398M37M  5195   0   2   0  5318   0   2   07 1335  163
> 47 53  0
>  1 1 0373M37M  5374   0   0   0  5337   0   0   07 1395  157
> 45 55  0
>  1 0 0394M39M 10096   0   0   0 10724   0   0   07  965  198
>  4 96  0
>  1 0 0408M30M  7602   0   1   0  5347   0   1   04 1630  150
> 32 68  0
>  1 0 0354M54M  6540   0   0   0 12687   0   0   05 1206  162
> 26 74  0
>  1 0 0409M26M 10452   0   2   0  3373   0   3   09 1592  208
> 10 90  0
>  1 0 0398M34M  4184   0   1   0  6316   0   2   05  929  153
> 52 48  0
>  1 0 0369M41M  3637   0   0   0  5337   0   0   05 1371  152
> 54 46  0
>  2 0 0362M42M 10285   0   0   0 10710   0   0   06  959  185
>  5 95  0
>
> Any suggestions ?
>

A load of 1.10 isn't very high, maybe some output while you're compiling
might help?

It looks like you've got approximately 512M of RAM - I can think of a lot
of code that would really stress that these days, but you don't say what
you're compiling.  You included the top and vmstat output which would
indicate that you're already thinking this way.

Also, ESXi 4.1 is pretty old - I know latest FreeBSD really has problems on
old VMWare workstation, so there might be a problem there too.
___
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: src.conf ignored; phantom named

[David Cornejo]

On Fri, Mar 2, 2012 at 12:41 PM, Rotate 13  wrote:
> I set WITHOUT_BIND="yes" in /etc/src.conf, and built/installed world.
> Not only does /usr/sbin/named exist - named is actually started!
> Several other WITHOUT_* variables also were apparently ignored, as
> evidenced by stuff installed on running system.
>
> My main question is - how do I debug this?  I have been combing over
> makefiles under /usr/src (not to mention, going through /etc/rc.d/
> trying to figure out what actually started named).  As far as I
> ascertain, _WITHOUT_SRCCONF is *not* set anywhere for world building;
> named_enable="no" in relevant rc.conf files; rpcbind and ntpd are not
> running either.  Since named daemonized, it's not easy to tell who
> started it - and grepping everything in sight, I can't figure out how
> it got built in the first place.
>
> uname -a:
> FreeBSD xyz.example.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Feb 29
> 10:28:17 CST 2012    r...@xyz.example.com:/usr/obj/usr/src/sys/CUSTOM
> amd64
>
> I focused substantial attention on /usr/src/share/bsd.own.mk and
> worked outward; but did not find anything obvious.
>
> Advice on where to poke for the right information, much appreciated.
> ___
> 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"

check the timestamp on /usr/sbin/named, I bet it's old as make world
doesn't delete old stuff.

I think "make delete-old" in /usr/src might do that for you.

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

/usr/home vs /home

[David Cornejo]

Hi,

In the old days home was typically a separate partition that was
mounted on /home.  If you didn't have a partition the installer would
create /usr/home and symlink /home to it.  The root was also typically
an independent partition, so it made sense not to clutter it up with
home directories.

Now that the default behavior is to use one big partition, the
installer defaults to /usr/home + symlink.

I've always liked the more succinct /home and was wondering if there
is any reason why not to delete the symlink and move home to / to
mimic the old many partition style?

thanks,
dave c
___
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: Serial Port Configuration does not work

[David Cornejo]

On Sep 11, 2011 6:54 PM, "Boris Samorodov"  wrote:
>
> On Sun, 11 Sep 2011 10:33:18 +0200 Gary Jennejohn wrote:
> > On Sat, 10 Sep 2011 21:10:44 +0400
> > Boris Samorodov  wrote:
> > > On Sat, 10 Sep 2011 16:08:21 +0200 Gary Jennejohn wrote:
> > > > > On Tue, 06 Sep 2011 16:29:51 +0400 Boris Samorodov wrote:
> > > > >
> > > > > > the port does not work as expected (at least as per The
Handbook,
> > > > > > 26.2.5 Serial Port Configuration). Nether "init" nor "lock"
> > > > > > devices can be used:
> > >
> > > > Seems that the handbook is out of date.
> > >
> > > OK, how can I configure a serial port then?
> > >
>
> > Just don't use the init and lock devices.
>
> Well, I've read the Handbook because I can't do it with
> a serial port:
> -
> % uname -a
> FreeBSD host.ipt.ru 9.0-BETA2 FreeBSD 9.0-BETA2 #14 r225395: Mon Sep  5
18:10:43 MSK 2011 b...@host.ipt.ru:/usr/obj/usr/src/sys/HOST  i386
>
> % sudo stty -f /dev/ttyu4 56400
>
> % echo $?
> 0
>
> % sudo stty -f /dev/ttyu4
> speed 9600 baud;
> lflags: echoe echoke echoctl
> oflags: tab0
> cflags: cs8 -parenb
> -
>
> --
> WBR, Boris Samorodov (bsam)
> Research Engineer, http://www.ipt.ru Telephone & Internet SP
> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
> ___
> 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"

It's been a long time, but I seem to recall that you need to have the device
open before you can configure it and that when the device closes it gets
reset to defaults. (or maybe the open resets it).  The way I remember
configuring it from the command line was to tip or cu to port, suspend tip,
reconfigure, and foreground tip.
___
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: Recent HEAD: buildworld is broken with clang

[David Cornejo]

Not sure this is CLANG related - I see this on a system where WITHOUT_CLANG
is set, and someone else reported it in another thread.

dave c

On Sun, Aug 14, 2011 at 8:58 AM, Oleg V. Nauman wrote:

> ===> libexec (all)
> ===> libexec/atrun (all)
> clang -O -pipe -march=i686 -mtune=i686  -DATJOB_DIR=\"/var/at/jobs/\"
>  -DLFILE=\"/var/at/jobs/.**lockfile\"  -DLOADAVG_MX=1.5
> -DATSPOOL_DIR=\"/var/at/spool\**"  -DVERSION=\"2.9\" -DDAEMON_UID=1
> -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
> -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../..**/usr.bin/at
> -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
> -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
> -c /usr/src/libexec/atrun/atrun.c
> clang -O -pipe -march=i686 -mtune=i686  -DATJOB_DIR=\"/var/at/jobs/\"
>  -DLFILE=\"/var/at/jobs/.**lockfile\"  -DLOADAVG_MX=1.5
> -DATSPOOL_DIR=\"/var/at/spool\**"  -DVERSION=\"2.9\" -DDAEMON_UID=1
> -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
> -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../..**/usr.bin/at
> -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
> -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
> -c /usr/src/libexec/atrun/**gloadavg.c
> clang -O -pipe -march=i686 -mtune=i686  -DATJOB_DIR=\"/var/at/jobs/\"
>  -DLFILE=\"/var/at/jobs/.**lockfile\"  -DLOADAVG_MX=1.5
> -DATSPOOL_DIR=\"/var/at/spool\**"  -DVERSION=\"2.9\" -DDAEMON_UID=1
> -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
> -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../..**/usr.bin/at
> -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
> -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
>  -o atrun atrun.o gloadavg.o -lpam -lutil
> clang: warning: argument unused during compilation: '-std=gnu99'
> /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to `_nsyylex'
> /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to `_nsyyin'
> /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to `_nsyytext'
> /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to
> `_nsyyerror'
> /usr/obj/usr/src/tmp/usr/lib/**libc.so: undefined reference to
> `_nsyylineno'
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** Error code 1
>
> Stop in /usr/src/libexec/atrun.
> *** Error code 1
>
> Stop in /usr/src/libexec.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
>
> __**_
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-**current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@**
> freebsd.org "
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Failed Buildworld 9.0 Beta 1

[David Cornejo]

Oh good, I'm not the only one seeing this - I have had it for a few days at
least, but haven't had time to look into it.

dave c

On Sun, Aug 14, 2011 at 9:16 AM, Johan Hendriks  wrote:

> Hello all.
>
> I cvsuped yesterday, and did a buildworld, all was fine.
> cvsuped today again, and now i can not do a buildworld, it errors out on
> atrun
>
> It ends like this (written by hand)
>
> ===>libexec (all)
> ===>libexec/atrun (all)
>
> cc -O2 -pipe ..
> cc -O2 -pipe ..
> cc -O2 -pipe ..
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyylex`
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyyin`
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyytext`
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyyerror`
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undifined reference to `_nsyylineno`
>
> *** error code 1
> Stop in /usr/src/libexec/atrun
>
>
> my make.conf
>
> CPUTYPE?=nocona
> KERNCONF=KRNL
>
> BATCH_DELETE_OLD_FILES= yes
>
> CUPS_OVERWRITE_BASE=yes
>
> # added by use.perl 2011-08-11 12:41:27
> PERL_VERSION=5.10.1
>
>
> my src.conf
> WITHOUT_BLUETOOTH=  yes
> WITHOUT_CALENDAR=   yes
> WITHOUT_DICT=   yes
> WITHOUT_GAMES=  yes
> WITHOUT_HTML=   yes
> WITHOUT_I4B=yes
> WITHOUT_IPFILTER=   yes
> WITHOUT_IPX=yes
> WITHOUT_LPR=yes
> WITHOUT_NIS=yes
> WITHOUT_RCMDS=  yes
> WITHOUT_RCS=yes
> #WITHOUT_PROFILE=   yes
> WITHOUT_SENDMAIL=   yes
> WITHOUT_SHAREDOCS=  yes
> WITHOUT_WIRELESS=  yes
>
> and my KRNL conf file
> include GENERIC
> ident   KRNL
>
> # hast support
> options GEOM_GATE
>
> # Carp support
> device  carp
>
>
> # pf
> options ALTQ
> options ALTQ_CBQ
> options ALTQ_RED
> options ALTQ_RIO
> options ALTQ_HFSC
> options ALTQ_CDNR
> options ALTQ_PRIQ
> device  pf
> device  pflog
> device  pfsync
>
> # Console color options
> options SC_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK)
> options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
> options SC_KERNEL_CONS_ATTR=(FG_BROWN|BG_BLACK)
> options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)
>
> # Console video mode
> options VESA # Vesa Support for Splash
> options SC_PIXEL_MODE # add support for the raster tex
>
> # System console options
> options SC_DISABLE_REBOOT   # disable reboot key sequence
> options SC_HISTORY_SIZE=200 # number of history buffer lines
>
>
> # Disable debugging in -current
> nooptions   KDB # Enable kernel debugger support.
> nooptions   DDB # Support DDB.
> nooptions   GDB # Support remote GDB.
> nooptions   INVARIANTS  # Enable calls of extra sanity
> checking
> nooptions   INVARIANT_SUPPORT   # Extra sanity checks of internal
> structures, required by INVARIANTS
> nooptions   WITNESS # Enable checks to detect deadlocks
> and cycles
> nooptions   WITNESS_SKIPSPIN# Don't run witness on spinlocks
> for speed
>
> regards
> Johan Hendriks
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: tzsetup disregards setting TZ to UTC

[David Cornejo]

On Mon, Mar 28, 2011 at 10:15 AM, Matthew Seaman <
m.sea...@infracaninophile.co.uk> wrote:

> On 28/03/2011 12:08, Matthias Andree wrote:
> > Perhaps the installer should instead:
> >
> > display CMOS and system time, and ask which one of them is correct, and
> > offer a third option to actually correct the timezone or time if neither
> > is correct.
> >
> > That's much easier to grasp.
>
> ... and a 4th option for when both are correct.  Happens quite a lot
> round these parts in the winter.  However, there are very few people for
> whom DST is the same as UTC.
>
>Cheers,
>
>Matthew
>
> --
> Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
>  Flat 3
> PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
> JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW
>
>
To me it seems that the fault is that I can find no way in tzsetup to
specify UTC.  Though it seems the system defaults to UTC if you don't run
tzsetup anyway, so maybe it would suffice to just say not to do that.
 (tzsetup is a no-op anyway if you're using UTC since in either case the
system RTC would be set to UTC)

While I don't follow the lists religiously, this is the first time in many
years that I've seen someone make this complaint and I'd rather not change
it.

dave c
___
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: [TESTING] ssse3 backport from gcc 4.3

[David Cornejo]

On Wed, Mar 9, 2011 at 9:49 AM, George Liaskos wrote:

> > I have prepared a patch that finishes the "core2" support part and
> > backports from gcc-4.3
> > the SSSE3 instruction set (-mssse3, -mno-ssse3).
> > It is enabled for -march=core2 by default.
> >
> > Testing and comments are welcome.
> >
> > Patch:
> > http://people.freebsd.org/~mm/patches/head-gcc-ssse3.patch
> >
> > The backport covers three GPLv2 revisions from gcc 4.3:
> > http://gcc.gnu.org/viewcvs?view=revision&revision=117958 (applies
> cleanly)
> > http://gcc.gnu.org/viewcvs?view=revision&revision=121687 (small
> adjustment)
> > http://gcc.gnu.org/viewcvs?view=revision&revision=121726 (small
> adjustment)
> > http://gcc.gnu.org/viewcvs?view=revision&revision=123639 (small
> adjustment)
>
> Just finished compiling world and kernel with the patch, no issues
> whatsoever but i have some questions :)
>
> I have a Q6600, with -march=native gcc still uses nocona instead of
> core2, clang does the right thing. Is this a bug?
> Is it possible to support sse4.1 for penryn or is there a problem with
> the license?
>
> Regards
> ___
> 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 also had success with this patch - running on a Core 2 Duo E4500.  rebuilt
world & kernel both with and without CPUTYPE=core2, so it at least doesn't
break anything.  Can you recommend a way to test Core2 specific features?

dave c
___
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: Panic booting vmware i386 after SRAT update

[David Cornejo]

On Thu, Jul 29, 2010 at 4:18 AM, John Baldwin  wrote:

> On Wednesday, July 28, 2010 1:37:42 pm m...@freebsd.org wrote:
> > I have a 2 cpu virtual image of FreeBSD current.  It panics during
> > boot after building in the NUMA support.
> >
> > I'll transcribe the SRAT bootverbose messages and panic message as best I
> can.
> >
> > Table 'SRAT' at 0xfef07f6
> > SRAT: Found table at 0xfef07f6
> > SRAT: Found memory domain 0 addr 0 len a: enabled
> > SRAT: Found memory domain 0 addr 10 len ff0: enabled
> >
> > then some MADT: messages about finding cpu 0 and 1
> >
> >  cpu0 (BSP): APIC ID:  0
> >  cpu1 (AP): APIC ID:  1
> > panic: SRAT: CPU with APIC ID 0 is not known
> >
> > I'm playing around now with trying to figure out what went missing,
> > but I thought I'd send this out now.
>
> Hmm, check_domains() in srat.c should reject the SRAT table in this case.
> Oh, I see the problem, try this:
>
> Index: srat.c
> ===
> --- srat.c  (revision 210552)
> +++ srat.c  (working copy)
> @@ -150,7 +150,8 @@
>for (i = 0; i < num_mem; i++) {
>found = 0;
>for (j = 0; j <= MAX_APIC_ID; j++)
> -   if (cpus[j].domain == mem_info[i].domain) {
> +   if (cpus[j].enabled &&
> +   cpus[j].domain == mem_info[i].domain) {
>cpus[j].has_memory = 1;
>found++;
>}
>
> --
> John Baldwin
> ___
> 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"
>

Works on amd64 kernel under VMWare, thanks!

dave c
___
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: Panic booting vmware i386 after SRAT update

[David Cornejo]

On Wed, Jul 28, 2010 at 8:23 AM,  wrote:

> On Wed, Jul 28, 2010 at 10:37 AM,   wrote:
> > I have a 2 cpu virtual image of FreeBSD current.  It panics during
> > boot after building in the NUMA support.
> >
> > I'll transcribe the SRAT bootverbose messages and panic message as best I
> can.
> >
> > Table 'SRAT' at 0xfef07f6
> > SRAT: Found table at 0xfef07f6
> > SRAT: Found memory domain 0 addr 0 len a: enabled
> > SRAT: Found memory domain 0 addr 10 len ff0: enabled
> >
> > then some MADT: messages about finding cpu 0 and 1
> >
> >  cpu0 (BSP): APIC ID:  0
> >  cpu1 (AP): APIC ID:  1
> > panic: SRAT: CPU with APIC ID 0 is not known
> >
> > I'm playing around now with trying to figure out what went missing,
> > but I thought I'd send this out now.
>
> Okay, apparently VMWare is providing two entries of type
> ACPI_SRAT_TYPE_MEMORY_AFFINITY but no entries of type
> ACPI_SRAT_TYPE_CPU_AFFINITY.  This leads to the assert since no CPUs
> are "enabled"; that is there's no affinity information for them.  This
> is probably a VMWare bug.
>
> Setting hint.srat.0.disabled="1" in /boot/device.hints works around the
> issue.
>
> Thanks,
> matthew
> ___
> 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"
>

GENERIC amd64 kernel with the hint dies earlier:

WARNING: WITNESS option enabled, expect reduced performance
panic: witness_init: pending locks list is too small, bump it

cpuid = 0
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at  kdb_enter+0x3d: movq$0,0x6d6fb0(%rip)
db>
___
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: Panic booting vmware i386 after SRAT update

[David Cornejo]

On Wed, Jul 28, 2010 at 7:37 AM,  wrote:

> I have a 2 cpu virtual image of FreeBSD current.  It panics during
> boot after building in the NUMA support.
>
> I'll transcribe the SRAT bootverbose messages and panic message as best I
> can.
>
> Table 'SRAT' at 0xfef07f6
> SRAT: Found table at 0xfef07f6
> SRAT: Found memory domain 0 addr 0 len a: enabled
> SRAT: Found memory domain 0 addr 10 len ff0: enabled
>
> then some MADT: messages about finding cpu 0 and 1
>
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
> panic: SRAT: CPU with APIC ID 0 is not known
>
> I'm playing around now with trying to figure out what went missing,
> but I thought I'd send this out now.
>
> Thanks,
> matthew
> ___
> 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 have been seeing this since yesterday with amd64 custom kernels - just
compiled a GENERIC kernel a few minutes ago and it shows the same symptom.
___
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: Wireless TCP aborts

[David Cornejo]

On Sun, Mar 7, 2010 at 1:08 PM, Chuck Swiger  wrote:

> Hi, Tim--
>
> On Mar 7, 2010, at 2:16 PM, Tim Kientzle wrote:
> [ ... ]
> >  Corrupted MAC on input.
> >  Disconnecting: Packet corrupt
> >  rsync: connection unexpectedly closed ... [receiver]
> >
> > and then the rsync session is dead.
> >
> > It seems odd that a single corrupt packet would terminate the TCP
> connection.
>
> It's not TCP itself which is closing the connection; if a garbage packet as
> far as TCP or IP layer checksums was seen, it would be dropped and normal
> resend mechanisms would compensate.  However, SSH adds it's own layer of
> data integrity checking called HMAC, which uses block-based hashes like MD5
> or SHA, and is much stronger than the 32-bit CRCs used at TCP/IP layers.
>
> See:
>
>   /usr/src/crypto/openssh/packet.c
>   http://en.wikipedia.org/wiki/HMAC
>
> The implication is that the data is being corrupted before it gets munged
> into network packets; failing memory is a likely cause, but bugs in the
> network stack, the NIC driver, or OpenSSL are also lower-order
> possibilities.
>
> Regards,
> --
> -Chuck
>
>
I have seen this same symptom many times with PCEngines ALIX boards but on
the vr interfaces.  It seems to come and go as I update kernels and worse
yet, it seems to vary by board -  have four boards all purchased at the same
time a couple of years ago and some seem more prone to it than others.  All
have worked and failed at one time or another.

I had, at one point, thought it to be related to power problems, because a
high-power mini-PCI WiFi card seemed to exacerbate the problem, but removing
the card made no difference, and the problem cleared up with an update and
recompile of my source tree.

It's a very disconcerting problem because FTP'ed files were being silently
corrupted, so it's not just an SSH problem either.

dave c
___
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: multicast panic

[David Cornejo]

the application is ports/net/mrt

attempting to build it causes a panic.  i'm pretty sure you need options 
MROUTING in the kernel config to cause it.

dave c

At 06:08 AM 10/15/2003, Doug White wrote:
On Tue, 14 Oct 2003, David Cornejo wrote:

> I'm trying to compile a multicast application and the system panics every
> time I run configure:
Might be nice toknow which multicast application, if its publicly
available :)
I suspect this is fallout from the multicast code reorg that bms has been
working on.
> Oct 14 13:46:11 groggy su: dave to root on /dev/ttyp0
>
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x68
> fault code  = supervisor read, page not present
> instruction pointer = 0x8:0xc053ddd2
> stack pointer   = 0x10:0xc9241bd4
> frame pointer   = 0x10:0xc9241be4
> code segment= base 0x0, limit 0xf, type 0x1b
>  = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 1143 (conftest)
> kernel: type 12 trap, code=0
> Stopped at  _mtx_lock_sleep+0x192:  movl0x68(%ecx),%edx
> db> trace
> _mtx_lock_sleep(c075a580,0,0,0) at _mtx_lock_sleep+0x192
> get_sg_cnt(c9241c60) at get_sg_cnt+0x34
> X_mrt_ioctl(c0147210,c9241c60,c9241c34,c056d632,c0147210) at 
X_mrt_ioctl+0x2e
> rtioctl(c0147210,c9241c60,0,c0147210,c9241cec) at rtioctl+0x18
> soo_ioctl(c1cebbf4,c0147210,c9241c60,c1deb380,c1cbfe40) at soo_ioctl+0x152
> ioctl(c1cbfe40,c9241d14,3,0,206) at ioctl+0x4be
> syscall(2f,2f,2f,bfbffa88,bfbffa74) at syscall+0x27b
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280be37f, esp = 0xbfbffa5c,
> ebp = 0xbfbffaac ---
> db>
>
>
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>

--
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

multicast panic

[David Cornejo]

I'm trying to compile a multicast application and the system panics every 
time I run configure:

Oct 14 13:46:11 groggy su: dave to root on /dev/ttyp0

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x68
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc053ddd2
stack pointer   = 0x10:0xc9241bd4
frame pointer   = 0x10:0xc9241be4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1143 (conftest)
kernel: type 12 trap, code=0
Stopped at  _mtx_lock_sleep+0x192:  movl0x68(%ecx),%edx
db> trace
_mtx_lock_sleep(c075a580,0,0,0) at _mtx_lock_sleep+0x192
get_sg_cnt(c9241c60) at get_sg_cnt+0x34
X_mrt_ioctl(c0147210,c9241c60,c9241c34,c056d632,c0147210) at X_mrt_ioctl+0x2e
rtioctl(c0147210,c9241c60,0,c0147210,c9241cec) at rtioctl+0x18
soo_ioctl(c1cebbf4,c0147210,c9241c60,c1deb380,c1cbfe40) at soo_ioctl+0x152
ioctl(c1cbfe40,c9241d14,3,0,206) at ioctl+0x4be
syscall(2f,2f,2f,bfbffa88,bfbffa74) at syscall+0x27b
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280be37f, esp = 0xbfbffa5c, 
ebp = 0xbfbffaac ---
db>



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"