Re: IGNORE_OSVERSION=yes -- can't install pkg

2018-05-07 Thread Peter Wemm
On Saturday, May 5, 2018 9:47:36 AM PDT Ian Lepore wrote:
> On Sat, 2018-05-05 at 08:26 -0700, Chris H wrote:
> > On Fri, 04 May 2018 22:57:52 -0700 <bsd-li...@bsdforge.com> said
> > 
> > > I just setup a jail from a 12-CURRENT I built awhile ago. It has no
> > > ports
> > > tree. So I'm attempting
> > > to install svnlite. issuing pkg search svnlite returns
> > > The package management tool is not yet installed on your system.
> > > Do you want to fetch and install it now? [y/N]: y
> > > Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/
> > > latest,
> > > please wait...
> > > Verifying signature with trusted certificate
> > > pkg.freebsd.org.2013102301...
> > > done
> > > [12current.localhost] Installing pkg-1.10.5...
> > > Newer FreeBSD version for package pkg:
> > > To ignore this error set IGNORE_OSVERSION=yes
> > > - package: 1200062
> > > - running kernel: 1200054
> > > Allow missmatch now?[Y/n]:
> > > 
> > > Umm, what? Should I ignore this error? If so, why is there an error
> > > at all?
> > > I answered no. Guess I won't be able to use pkg(8) on this jail(8).
> > > 
> > > :-(
> > > 
> > > --Chris
> > 
> > OK the only reference[1] I can find regarding this, indicates that
> > answering "Y"
> > to Allow missmatch now? resulted in an ABI mismatch that caused
> > pkg(8) to be
> > unusable.
> > This is on an older version of 12, so I don't have anything that
> > might have
> > appeared in UPDATING. I really need this jail to resolve accumulating
> > pr(1)'s
> > on ports(7) I maintain.
> > 
> > Thank you.
> 
> The difference between 1200062 and 1200054 isn't going to affect
> anything except modules which are intimate with kernel internals, such
> as video drivers or virtualbox type stuff.
> 
> IMO, this new version checking done by pkg(8) is just bad Bad BAD. The
> only control you get is a knob that tells you to ignore any version
> mismatch. There appears to be no option to get the historical worked-
> really-well behavior of ignoring mismatches of the minor version for
> people who track -current.

There was an unfortunate Incident caused OSVERSION handling at a certain 
Verizon company that happens to run FreeBSD.

We hit an OSVERSION implementation bug on the freebsd.org cluster today.  
We've disabled it across the entire site as it is unusable for us in this 
form.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5


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


Caveat emptor: Beware of ZFS on HEAD

2017-07-12 Thread Peter Wemm
We mostly run HEAD in the freebsd.org cluster.  Sometime in the last few weeks 
an ugly zfs problem has surfaced. If a redundant volume is degraded, zfs 
panics on boot.  If a drive fails while running, or is manually put offline, 
zfs 
panics the same way.

I do not have a smoking gun, but I am suspicious of the June 28th commits 
(starting at r320156) and their follow-ups. eg: r320452.

https://bugs.freebsd.org/220691

I believe single disk systems will *not* be affected by this - the panic only 
happens when a raidz (and presumably mirror) degrades.  Your laptop etc should 
be fine.

I apologize for being vague - I do not know more. Folks running HEAD should 
take appropritate precautions (eg: keeping a known-good kernel.old and modules 
around).  This is always advisable when running HEAD anyway, particularly so 
now.  For us, a kernel.old from June 18th worked fine.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: commits between r305191 - r305211 broke zfs list

2016-09-04 Thread Peter Wemm
On Saturday, September 03, 2016 10:31:04 PM Steven Hartland wrote:
> Out of sync kernel / world?
> 
> Do you have a crash dump?

This has caused a considerable amount of excitement on the freebsd.org 
cluster.  Having kernel+world out of sync causes zfs(8) to abort rather 
ungracefully.

> On 03/09/2016 21:50, Subbsd wrote:
> > Hi.
> > 
> > Can anybody test of output for:
> > 
> > zfs list
> > 
> > command on FreeBSD current after r305211 ? On my hosts his leads to
> > zfs segfault.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: FreeBSD 11.0-RC1 Now Available

2016-08-13 Thread Peter Wemm
On Saturday, August 13, 2016 08:47:52 PM Glen Barber wrote:
> On Sat, Aug 13, 2016 at 07:35:45PM +0200, Jan Beich wrote:
> > Glen Barber <g...@freebsd.org> writes:
> > > The first RC build of the 11.0-RELEASE release cycle is now available.
> > > 
> > > Installation images are available for:
> > > 
> > > o 11.0-RC1 amd64 GENERIC
> > > o 11.0-RC1 i386 GENERIC
> > > o 11.0-RC1 powerpc GENERIC
> > > o 11.0-RC1 powerpc64 GENERIC64
> > > o 11.0-RC1 sparc64 GENERIC
> > > o 11.0-RC1 armv6 BANANAPI
> > > o 11.0-RC1 armv6 BEAGLEBONE
> > > o 11.0-RC1 armv6 CUBIEBOARD
> > > o 11.0-RC1 armv6 CUBIEBOARD2
> > > o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD
> > > o 11.0-RC1 armv6 GUMSTIX
> > > o 11.0-RC1 armv6 RPI-B
> > > o 11.0-RC1 armv6 RPI2
> > > o 11.0-RC1 armv6 PANDABOARD
> > > o 11.0-RC1 armv6 WANDBOARD
> > > o 11.0-RC1 aarch64 GENERIC
> > 
> > What about granular sets? sparc64 is N/A while amd64 is missing
> > lib32.txz, src.txz, ports.txz, tests.txz. Regressed since 11.0-BETA4.
> > I've waited a day to see if the issue would disappear after mirrors
> > catch up but no joy, even via Tor.
> > 
> > [...]
> 
> Thanks for letting us know.  This isn't an re@ issue, it's an admins@
> issue, and we thought this was fixed.  Give me a bit to investigate.
> 
> Glen

If this isn't fixed now, please yell.

It seems we found a bug in the syncthing-inotify tool.  chmod events were 
being missed.  In theory this is worked around now.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

2016-06-10 Thread Peter Wemm

On 6/9/16 6:49 PM, Matthew Seaman wrote:

On 09/06/2016 18:34, Craig Rodrigues wrote:

There is still value to ypldap as it is now, and getting feedback from
users (especially Active Directory) would be very useful.
If someone could document a configuration which uses IPSEC or OpenSSH
forwarding, that would be nice.

In future, maybe someone in OpenBSD or FreeBSD will implement things like
LDAP over SSL.


What advantages does ypldap offer over nss-pam-ldapd (in ports) ?
nss-pam-ldapd can use both ldap+STARTTLS or ldaps to encrypt data in
transit, and I find it works very well for using OpenLDAP as a central
account database.  I believe it works with AD, but haven't tried that
myself.

Cheers,

Matthew




We used nss-pam-ldapd quite successfully in the freebsd.org cluster during 
our transition away from YP/NIS, for what it's worth.


--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
___
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: buildworld broken

2015-10-14 Thread Peter Wemm
On Wednesday, October 14, 2015 10:20:11 AM Shawn Webb wrote:
> I've now reproduced this same error on two boxes:
> 
> gencat: Unable to create a new zh_CN.GB2312: Permission denied
> --- zh_CN.GB2312 ---
> *** [zh_CN.GB2312] Error code 1
> 
> make[5]: stopped in /usr/src/usr.bin/vi/catalog
> 1 error
> 
> Thanks,

There's recently introduced 'make -jN' races, it seems.

 ... zh_CN.UTF-8
 ... zh_CN.UTF-8
chmod: zh_CN.UTF-8: No such file or directory
--- zh_CN.UTF-8 ---
*** [zh_CN.UTF-8] Error code 1

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Warning: HEAD with zfs is potentially broken

2015-06-15 Thread Peter Wemm
Beware, a recent change has moved zfs tools internal libraries to the wrong 
location and this can cause machines to be unbootable.  /sbin/zfs uses the 
libraries from /lib, which are now going stale and may have undefined symbols.  
installworld is incorrectly installing them in /usr/lib.  This happened some 
time in the last week or so.

Be very careful over the next few days.  This can cause boot failures.
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: PSA: If you run -current, beware!

2015-02-05 Thread Peter Wemm
On Thursday, February 05, 2015 11:00:46 AM Peter Wemm wrote:
 On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote:
  On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote:
   On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
   ...
   
   It is fixed (in the proper meaning of the word, not like worked
   around,
   covered by paper) by the patch at the end of the mail.
   
   We already have a story trying to enable much less ambitious
   option
   -fno-strict-overflow, see r259045 and the revert in r259422.  I
   do
   not
   see other way than try one more time.  Too many places in kernel
   depend on the correctly wrapping 2-complement arithmetic, among
   others
   are callweel and scheduler.
 
 Rather than depending on a compiler option, wouldn't it be
 better/more
 robust to change ticks to unsigned, which has specified wrapping
 behavior?

Yes, but non-trivial.  It's also not limited to ticks.  Since the
compiler
knows when it would apply these optimizations, it would be nice if it
could
warn instead (GCC apparently has a warning, but clang does not). 
Having
people do a manual audit of every signed integer expression in the
tree
will take a long time.
   
   I think I misunderstood the problem as being limited to ticks,
   which is probably only one symptom of a fundamental change in behaviour
   of the compiler.
   Still, it might be worthwhile start looking at ints that ought to be
   implemented as u_int
  
  I actually agree, I just think we are stuck with -fwrapv in the interval,
  but it's probably not a short interval.  I think converting ticks to
  unsigned would be a good first start.
 
 For the record, I agree.  However, I suspect that attempts to do so will
 have a non trivial number of bugs introduced.  We have a track record of
 recurring problems with tcp sequence number space arithmetic and tcp
 timing, partly because the wraparounds happens infrequently.

BTW; anybody working on this will want to run with  kern.hz=10  in 
loader.conf (or higher).  Having the clock tick 100 times faster speeds the 
rollover up from every ~25 days to every ~6 hours.  I don't know what the 
practical limit is but at some point it will cause sufficient pain due to 
contention that it won't be useful.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: PSA: If you run -current, beware!

2015-02-05 Thread Peter Wemm
On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote:
 On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote:
  On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
   On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
  ...
  
  It is fixed (in the proper meaning of the word, not like worked
  around,
  covered by paper) by the patch at the end of the mail.
  
  We already have a story trying to enable much less ambitious
  option
  -fno-strict-overflow, see r259045 and the revert in r259422.  I do
  not
  see other way than try one more time.  Too many places in kernel
  depend on the correctly wrapping 2-complement arithmetic, among
  others
  are callweel and scheduler.

Rather than depending on a compiler option, wouldn't it be better/more
robust to change ticks to unsigned, which has specified wrapping
behavior?
   
   Yes, but non-trivial.  It's also not limited to ticks.  Since the
   compiler
   knows when it would apply these optimizations, it would be nice if it
   could
   warn instead (GCC apparently has a warning, but clang does not).  Having
   people do a manual audit of every signed integer expression in the tree
   will take a long time.
  
  I think I misunderstood the problem as being limited to ticks,
  which is probably only one symptom of a fundamental change in behaviour
  of the compiler.
  Still, it might be worthwhile start looking at ints that ought to be
  implemented as u_int
 
 I actually agree, I just think we are stuck with -fwrapv in the interval,
 but it's probably not a short interval.  I think converting ticks to
 unsigned would be a good first start.

For the record, I agree.  However, I suspect that attempts to do so will have 
a non trivial number of bugs introduced.  We have a track record of recurring 
problems with tcp sequence number space arithmetic and tcp timing, partly 
because the wraparounds happens infrequently.

In the mean time, I feel that telling the compiler that it's OK to let it 
behave the way we expect (vs actively sabotaging it) is a viable stopgap.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: PSA: If you run -current, beware!

2015-02-04 Thread Peter Wemm
On Wednesday, February 04, 2015 04:29:41 PM Konstantin Belousov wrote:
 On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote:
  Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been
  introduced to 11.x/head/-current.With HZ=1000 (the default for bare
  metal, not for a vm); the clocks stop just after 24 days of uptime.  This
  means things like cron, sleep, timeouts etc stop working.  TCP/IP won't
  time out or retransmit, etc etc.  It can get ugly.
  
  The problem is NOT in 10.x/-stable.
  
  We hit this in the freebsd.org cluster, the builds that we used are:
  FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine
  FreeBSD 11.0-CURRENT #0 r276779: Wed Jan  7 18:47:09 UTC 2015 - broken
  
  If you are running -current in a situation where it'll accumulate uptime,
  you may want to take precautions.  A reboot prior to 24 days uptime (as
  horrible a workaround as that is) will avoid it.
  
  Yes, this is being worked on.
 
 So the issue is reproducable in 3 minutes after boot with the following
 change in kern_clock.c:
 volatile int  ticks = INT_MAX - (/*hz*/1000 * 3 * 60);
 
 It is fixed (in the proper meaning of the word, not like worked around,
 covered by paper) by the patch at the end of the mail.
 
 We already have a story trying to enable much less ambitious option
 -fno-strict-overflow, see r259045 and the revert in r259422.  I do not
 see other way than try one more time.  Too many places in kernel
 depend on the correctly wrapping 2-complement arithmetic, among others
 are callweel and scheduler.

Ugh.

I believe I have a smoking gun that suggests that the clock-stop problem is 
caused by the clang-3.5 import on Dec 31st.

Backstory:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://www.airs.com/blog/archives/120

I suspect that what has happened is that clang's optimizer got better at 
seeing the direct or indirect effects of integer overflow and clang (and gcc) 
take advantage of that.

I have used a slightly different change for about 10 years:

--- kern/kern_clock.c   2014-12-01 15:42:21.707911656 -0800
+++ kern/kern_clock.c   2014-12-01 15:42:21.707911656 -0800
@@ -410,6 +415,11 @@
 #ifdef SW_WATCHDOG
EVENTHANDLER_REGISTER(watchdog_list, watchdog_config, NULL, 0);
 #endif
+   /*
+* Arrange for ticks to go negative just 5 minutes after boot
+* to help catch sign problems sooner.
+*/
+   ticks = INT_MAX - (hz * 5 * 60);
 }
 
 /*

This came about from when we had problems with integer overflow arithmetic in 
the tcp stack.

In any case, I'm in the process of adding -fwrapv and the early wraparound to 
the freebsd.org cluster builds to give it some wider exercise.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


PSA: If you run -current, beware!

2015-02-03 Thread Peter Wemm
Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been 
introduced to 11.x/head/-current.With HZ=1000 (the default for bare metal, 
not for a vm); the clocks stop just after 24 days of uptime.  This means 
things like cron, sleep, timeouts etc stop working.  TCP/IP won't time out or 
retransmit, etc etc.  It can get ugly.

The problem is NOT in 10.x/-stable.

We hit this in the freebsd.org cluster, the builds that we used are:
FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine
FreeBSD 11.0-CURRENT #0 r276779: Wed Jan  7 18:47:09 UTC 2015 - broken

If you are running -current in a situation where it'll accumulate uptime, you 
may want to take precautions.  A reboot prior to 24 days uptime (as horrible a 
workaround as that is) will avoid it.

Yes, this is being worked on.
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: RFC: getting rid of oldnfs

2014-10-24 Thread Peter Wemm
On Friday, October 24, 2014 04:43:28 PM Robert Watson wrote:
 On Thu, 23 Oct 2014, Rick Macklem wrote:
  Someone just pinged me on this and I figured I should bring it up.
  
  1 - Is anyone out there still using oldnfs due to unresolved
  
 problems with the new one? (I am not aware of any outstanding
 issues in the new nfs that don't exist in the oldnfs.)
  
  2 - Does anyone see a problem with getting rid of oldnfs for
  
 FreebSD-11?
  
  3 - If I get rid of it in -head, I can do it either in mid-December
  
 or mid-April. (I can't do commits during the winter.)
 Does anyone have a rough idea when the 11.0 release cycle will
 start, so I can choose which of the above would be preferable?
 (I figured I'd wait until after the last 10.n release that happens
 
  before 11.0, since it will be easier to MFC before the removal of
  oldnfs.)
  
  Thanks in advance for any comments, rick
  ps: John, I've cc'd you since I thought you are the guy most likely to
  
 need to do commits/MFCs to oldnfs.
 
 I think removing it is fine, but as early as possible (as John says) to give
 our -CURRENT users time to stop working around bugs and start reporting
 them
 :-).

We still use oldnfs at work, even on 11.x, but I'm very much in favor of 
getting back to one single copy.  It seems like there's too many things that 
are fixed in one stack or the other.,  We need to stop splitting effort.

I've asked Rick before to remove it and get back to just nfs rather than 
newnfs etc.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: Build failed in Jenkins: FreeBSD_HEAD #1594

2014-10-09 Thread Peter Wemm
On Thursday, October 09, 2014 07:38:03 PM jenkins-ad...@freebsd.org wrote:
 See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1594/changes
[...]
 -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc  -I.
 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys
 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq
 
 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libf
 dt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h 
 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel
 -mno-red-zone -mno-mmx -mno-sse -msoft-float 
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2
 -mno-aes -mno-avx -Werror  vers.c ctfconvert -L VERSION -g vers.o
 --- kernel.debug ---
 linking kernel.debug
 ctfmerge -L VERSION -g -o kernel.debug ...
 kernel.debug: not found
 *** [kernel.debug] Error code 127
 
 make[2]: stopped in
 /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERI

This is because of:
=
Author: bapt
Date: Thu Oct  9 15:52:01 2014
New Revision: 272827
URL: https://svnweb.freebsd.org/changeset/base/272827

Log:
  Add size(1) to the cross build toolchain

Modified:
  head/Makefile.inc1
=

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: zpool frag

2014-09-21 Thread Peter Wemm
On Sunday, September 21, 2014 11:06:10 AM Allan Jude wrote:
 On 2014-09-21 04:57, Beeblebrox wrote:
  FRAG means fragmentation, right? Zpool fragmentation? That's news to me.
  If
  this is real how do I fix it?
  
  NAME  SIZE  ALLOC   FREE   FRAG  EXPANDSZCAP  DEDUP  HEALTH 
  ALTROOT pool1  75.5G  53.7G  21.8G60% -71%  1.00x 
  ONLINE  - pool2  48.8G  26.2G  22.6G68% -53%  1.00x 
  ONLINE  - pool3   204G   177G  27.0G53% -86%  1.11x 
  ONLINE  -
  
  Regards.
  
  
  
  -
  FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
  --
  View this message in context:
  http://freebsd.1045724.n5.nabble.com/zpool-frag-tp5950788.html Sent from
  the freebsd-current mailing list archive at Nabble.com.
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 
 It is not something you 'fix', it is just a metric to help you
 understand the performance of your pool. The higher the fragmentation,
 the longer it might take to allocate new space, and obviously you will
 have more random seek time while reading from the pool.
 
 As Steven mentions, there is no defragmentation tool for ZFS. You can
 zfs send/recv or backup/restore the pool if you have a strong enough
 reason to want to get the fragmentation number down.
 
 It is a fairly natural side effect of a copy-on-write file system.
 
 Note: the % is not the % fragmented, IIRC, it is the percentage of the
 free blocks that are less that a specific size. I forget what that size is.

I fear that the information presented in its current form is going to generate 
lots of fear and confusion.

The other thing to consider is that this gets much, much worse as the pool 
fills up.  Even UFS has issues with fragmentation when it fills, but ZFS is far 
more sensative to it.  In the freebsd.org cluster we have a health check alert 
at 80% full, but even that's probably on the high side.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: zpool frag

2014-09-21 Thread Peter Wemm
On Sunday, September 21, 2014 06:12:09 PM Steven Hartland wrote:
 - Original Message -
 
  From: Peter Wemm pe...@wemm.org
  
  On Sunday, September 21, 2014 11:06:10 AM Allan Jude wrote:
   On 2014-09-21 04:57, Beeblebrox wrote:
FRAG means fragmentation, right? Zpool fragmentation? That's news to
me.
If
this is real how do I fix it?

NAME  SIZE  ALLOC   FREE   FRAG  EXPANDSZCAP  DEDUP  HEALTH
ALTROOT pool1  75.5G  53.7G  21.8G60% -71%  1.00x
ONLINE  - pool2  48.8G  26.2G  22.6G68% -53% 
1.00x
ONLINE  - pool3   204G   177G  27.0G53% -86% 
1.11x
ONLINE  -
   
   It is not something you 'fix', it is just a metric to help you
   understand the performance of your pool. The higher the fragmentation,
   the longer it might take to allocate new space, and obviously you will
   have more random seek time while reading from the pool.
   
   As Steven mentions, there is no defragmentation tool for ZFS. You can
   zfs send/recv or backup/restore the pool if you have a strong enough
   reason to want to get the fragmentation number down.
   
   It is a fairly natural side effect of a copy-on-write file system.
   
   Note: the % is not the % fragmented, IIRC, it is the percentage of the
   free blocks that are less that a specific size. I forget what that size
   is.
  
  I fear that the information presented in its current form is going to
  generate lots of fear and confusion.
  
  The other thing to consider is that this gets much, much worse as the pool
  fills up.  Even UFS has issues with fragmentation when it fills, but ZFS
  is far more sensative to it.  In the freebsd.org cluster we have a health
  check alert at 80% full, but even that's probably on the high side.
 
 This should be less of an issue if you have the spacemap_histogram feature
 enabled on the pool, which IIRC if your seeing FRAG details should be the
 case.

Hopefully so.  The catch though is when its been run without it until recently 
it can be a bit of a surprise.


-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

2014-09-17 Thread Peter Wemm
On Tuesday, September 16, 2014 12:42:36 PM Mateusz Guzik wrote:
 On Fri, Sep 12, 2014 at 09:29:56PM -0700, Peter Wemm wrote:
  On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote:
   On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org 
wrote:
On 09.09.2014 21:53, Patrick Kelsey wrote:
 I don't think it is worth the trouble, as given the larger pattern
 of
 libc routines requiring multiple capsicum rights, it seems one will
 in
 general have to have libc implementation knowledge when using it in
 concert with capsicum.  For example, consider the limitfd() routine
 in
 kdump.c, which provides rights for the TIOCGETA ioctl to be used on
 stdout so the eventual call to isatty() via printf() will work as

intended.

 I think the above kdump example is a good one for the subtle issues
 that
 can arise when using capsicum with libc.  That call to isatty() is
 via a
 widely-used internal libc routine __smakebuf().  __smakebuf() also
 calls
 __swhatbuf(), which in turn calls _fstat(), all to make sure that
 output
 to a tty is line buffered by default.  It would appear that programs
 that restrict rights on stdout without allowing CAP_IOCTL and
 CAP_FSTAT
 could be disabling the normally default line buffering when stdout
 is a
 tty.  kdump goes the distance, but dhclient does not (restricting
 stdout
 to CAP_WRITE only).
 
 In any event, the patch attached to my first message is seeming like
 the
 way to go.

Well, then commit it (if capsicum team agrees).
   
   Will do - thanks for the feedback.
   
   -Patrick
  
  Is there any possibility that this is related to the problem we've
  recently
  hit in the freebsd.org cluster with this month's refresh?
  
  After running for a while:
  Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator
  Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator
  Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch
  returned
  error -1, errno is Capabilities insufficient
  
  Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully
  last time (65258)
  Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator
  Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator
  Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch
  returned
  error -1, errno is Capabilities insufficient
  
  Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully
  last time (28213)
  Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator
  Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator
  Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch
  returned
  error -1, errno is Capabilities insufficient
  
  I believe this jail was started from the boot process. If I restart the
  jail by hand from a ssh session the problem goes away.
  
  This is unbound from ports and I don't have any more details than this. 
  This is new this month.
 
 Is this thingy multithreaded?
 
 Currently there is a race in the kernel where fd is visible before
 relevant capabilities are installed. This can result in an error like
 this one for weird processes.
 
 I got a patch for this:
 http://lists.freebsd.org/pipermail/freebsd-arch/2014-August/015788.html
 
 but it got stalled on 'memory barrier' discussion. I'll try to ping
 people to move it forward.
 
 IIRC there was a report of unbound failing this way, apparently fixed
 with aforementioned patch.

Yes, unbound is multi-threaded and your comment is the first potential 
explanation that makes sense so far.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

2014-09-12 Thread Peter Wemm
On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote:
 On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org wrote:
  On 09.09.2014 21:53, Patrick Kelsey wrote:
   I don't think it is worth the trouble, as given the larger pattern of
   libc routines requiring multiple capsicum rights, it seems one will in
   general have to have libc implementation knowledge when using it in
   concert with capsicum.  For example, consider the limitfd() routine in
   kdump.c, which provides rights for the TIOCGETA ioctl to be used on
   stdout so the eventual call to isatty() via printf() will work as
  
  intended.
  
   I think the above kdump example is a good one for the subtle issues that
   can arise when using capsicum with libc.  That call to isatty() is via a
   widely-used internal libc routine __smakebuf().  __smakebuf() also calls
   __swhatbuf(), which in turn calls _fstat(), all to make sure that output
   to a tty is line buffered by default.  It would appear that programs
   that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT
   could be disabling the normally default line buffering when stdout is a
   tty.  kdump goes the distance, but dhclient does not (restricting stdout
   to CAP_WRITE only).
   
   In any event, the patch attached to my first message is seeming like the
   way to go.
  
  Well, then commit it (if capsicum team agrees).
 
 Will do - thanks for the feedback.
 
 -Patrick

Is there any possibility that this is related to the problem we've recently 
hit in the freebsd.org cluster with this month's refresh?

After running for a while:
Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator
Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator
Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned 
error -1, errno is Capabilities insufficient

Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully last 
time (65258)
Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator
Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator
Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch returned 
error -1, errno is Capabilities insufficient

Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully last 
time (28213)
Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator
Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator
Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch returned 
error -1, errno is Capabilities insufficient

I believe this jail was started from the boot process. If I restart the jail 
by hand from a ssh session the problem goes away.

This is unbound from ports and I don't have any more details than this.  This 
is new this month.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: ddb_enable=YES by default?

2014-09-05 Thread Peter Wemm
On Friday 05 September 2014 13:51:24 Craig Rodrigues wrote:
 On Fri, Sep 5, 2014 at 7:54 AM, John Baldwin j...@freebsd.org wrote:
  Probably at least 50% of the time when I work with a user on a bug report,
  I ask them to go into kgdb and run specific commands to extract more
  detailed info (print some struct, etc.).
 
 Sure, I understand, but you are not working with every user who
 encounters a kernel panic in FreeBSD.  For the average or casual
 FreeBSD user, such as desktop
 users of FreeBSD or PC-BSD, wouldn't it be better
 to have ddb_enable=YES be the default in FreeBSD?  The ddb script
 there does a fairly reasonable
 job of gathering some useful info which can be analyzed later, and
 then rebooting the box.
 
 For more expert users, or people developing products, they can set
 ddb_enable=NO
 and do more advanced debugging.  Or hook into /etc/rc.d/ddb and define
 a different
 ddb script which doesn't do textdumps on kernel panic.

I think what John was saying was at that point it's too late.  The loss of the 
crash dump means the one shot at getting more information is gone.

For reproducable crashes, yes, an end user could just flip the bit.  But for a 
one-off, it's too late.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread Peter Wemm
On 8/26/14 11:05 AM, Chris H wrote:
 Greetings,
 I'm currently testing 11. My build / install is from about 2 days ago.
 I generally use xz compression, when creating archives. But when I
 attempt the following:
 
 tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file
 
 it returns the following:
 
 tar: Undefined option: `xz:9'
 
 This has always worked in previous versions. Has the syntax changed,
 and the man(1) pages just haven't caught up?

I use:
tar -cJ --options xz:compression-level=1
.. on head. Are you using the right syntax?

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV



signature.asc
Description: OpenPGP digital signature


Beware, ZFS on head!

2014-08-21 Thread Peter Wemm
Depending on how you build it, you may either get a kernel compile failure (if 
you build zfs into the core kernel with options ZFS), or possibly even an 
invalid zfs.ko with an undefined symbol that can't be used at reboot time.  Be 
exceptionally careful.

I suggest, before rebooting, do a 
# nm /boot/kernel/zfs.ko | grep atomic_dec

If you see:
  U atomic_dec_64_nv
.. you will have a sub-optimal reboot experience and you may want to save your 
kernel.old.

(no output = you're fine = carry on!)

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: nscd not caching

2014-08-17 Thread Peter Wemm
On Sunday 17 August 2014 15:22:02 O. Hartmann wrote:
 Am Sun, 17 Aug 2014 13:09:10 +
 
 Eggert, Lars l...@netapp.com schrieb:
  Nobody using nscd? Really?
 
 I can only speak for myself and I stopped using nscd since the support is
 crap.
 
 A while ago (t  1 1/2 years) I realised within a OpenLDAP environment, that
 when nscd is running, sometimes the system simple forgets about root -
 this is painful while installing/updating ports and getting interrupted
 with a weird error unknown user root.
 
 nscd is supposed to be used in large environments where the cost for a user
 lookup, like in OpenLDAP, is worse. But obviously FreeBSD isn't used in
 that large environments with OpenLDAP and I'm wondering what the purpose of
 nscd is.

The other problem is that net/nss_ldap and security/pam_ldap have kind of been 
left behind for performance and robustness.  People who use this seriousy tend 
to discover net/nss-pam-ldapd fairly quickly which has its own caching proxy 
and eliminates the need for nscd.

With nss_ldap and pam_ldap, the openldap client libraries and startup cost is 
linked into every single binary that uses it.

WIth pam-nss-ldapd, it's a simple unix domain socket (with peercred 
authentication) and no heavy-weight libraries in the consumers. The proxy on 
the other end of the socket keeps a ldap connection open (with an idle 
timeout).  The whole thing was vastly more robust and efficient.

At least that's what we found in the freebsd.org cluster.  nss-pam-ldapd was 
two or three orders of magnitude more usable and got rid of nscd in the 
process.

For us, nscd worked, but it just didn't save much effort because it was a 
per-uid cache.  ie: if jkh had just caused a ldap search, and peter 
repeated it, it had to be done again from scratch.

The downside for nss-pam-ldapd was that it uses a non-extensible wire protocol 
and didn't have room for bsd-style login classes.

  On 2014-8-14, at 13:26, Eggert, Lars l...@netapp.com wrote:
   [Resending to current@, since I can't get it to work on -CURRENT
   either.]
   
   Hi,
   
   anyone have an idea why nscd would not be caching NIS lookups?
   
   My nsswitch.conf looks as follows:
   
   group: cache files nis
   hosts: cache files dns
   networks: cache files
   passwd: cache files nis
   shells: files
   services: cache files nis
   protocols: cache files
   rpc: cache files
   
   nisdomain is set and ypbind is started, and I see lots of NIS traffic
   going in and out.
   
   But nothing is cached; running nscd with -t just prints this and then
   then nothing, ever:
   
   M1 from main: successfully daemonized
   M1 from main: request agents registered successfully
   M2 from cache: cache was successfully initialized
   M2 from runtime environment: using socket /var/run/nscd
   M2 from runtime environment: successfully initialized
   M1 from main: thread #0 was successfully created
   M1 from main: thread #1 was successfully created
   M1 from main: thread #2 was successfully created
   M1 from main: thread #3 was successfully created
   M1 from main: thread #4 was successfully created
   M1 from main: thread #5 was successfully created
   M1 from main: thread #6 was successfully created
   M1 from main: thread #7 was successfully created
   
   Lars

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: loader lszfs command

2014-08-07 Thread Peter Wemm
On Thursday 07 August 2014 16:42:42 dte...@freebsd.org wrote:

 Maybe if I update boot0 to a HEAD copy maybe?
 Have already tried updating /boot/loader with no change.

-r-xr-xr-x  1 root  wheel  262144 Aug  1 12:24 /boot/loader*
-r-xr-xr-x  1 root  wheel  299008 Aug  1 12:24 /boot/zfsloader*

It sounds like something is wrong with your install.

BTW; boot0 isn't involved - if you've got that far, boot0 / gptzfsboot have 
already done their part.
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: local_unbound: since update sporadic hangs in connections

2014-07-28 Thread Peter Wemm
Are you using pf and IPv6 by any chance?  Since you mentioned the FreeBSD.org 
domain, DNSSEC and IPv6 triggers fragments.  Just a thought. 

--
Peter Wemm. pe...@wemm.org


 On 28 Jul 2014, at 6:50 am, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
 
 Since local_unbound update and the suggested update procedure as requested 
 with TAG
 20140719 the connection to the net hangs (DNS resolving). This is very often 
 with the
 freebsd.org domain the case, while domestic domains rarely show this strange 
 behaviour.
 
 The problem occurs on ALL CURRENT systems with updated unbound!
 
 Updates via svn also show those hangs (FBSD SVN server).
 
 This is nasty ...
 
 oh
___
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 ?

2014-07-24 Thread Peter Wemm
On Wednesday 23 July 2014 20:59:19 Bjoern A. Zeeb wrote:
 On 23 Jul 2014, at 20:41 , Allan Jude allanj...@freebsd.org wrote:
  On 2014-07-23 16:38, Bjoern A. Zeeb wrote:
  On 23 Jul 2014, at 15:42 , Cy Schubert cy.schub...@komquats.com wrote:
  Taking this discussion slightly sideways but touching on this thread a
  little, each of our packet filters will need nat66 support too. Pf
  doesn't
  support it for sure. I've been told that ipfw may and I suspect ipfilter
  doesn't as it was on Darren's todo list from 2009.
  
  our pf does support IPv6 prefix rewriting quite nicely and has for years.
  
  Bjoern: What IPv6 stuff does our pf not do well?
 
 I think the most pressing, as Peter said, is fragment handling, though a
 good fraction of major content providers seems to do mss clamping to a min
 IPv6 mtu on IPv6 and drop fragments at the edge (not much different to
 IPv4, which makes you wonder?).Whoever is clever will think of how many
 different queueing and fragment handling implementations we need in the
 kernel, and how often we have to do it on an end node that might also run a
 firewall,  pick one we have, turn it into a library thing, apply it to all
 places, and then add the latest IETF suggestions on top of it.

Correct.

There is code in the openbsd cvs history where they added it while the 
internal APIs looked similar enough to ours.  It's simpler than ipv4 
reassembly - taking advantage of things like overlapping fragments not being 
allowed.

I'm almost desperate enough to take a shot at it myself, but mbufs and I do 
not get along.  Nobody wants code I've touched to be in the tree if mbufs are 
involved.


The initial commits.. first the supporting changes:

(refactor code for reuse)
http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf_norm.c.diff?r1=1.128r2=1.129

(add ipv6 defrag/refrag)
http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf_norm.c.diff?r1=1.129r2=1.130

Then they added the code to defragment/refragment:
(pf_test6 defrag/refrag)
http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.729r2=1.730


The catch is that they fixed a lot of edge cases so one needs to follow the 
history forward a bit to make sure it it's covered.  The other problem is our 
codebase is even older than when this was added so some looking at older 
commits is required.

In the time since the feature was added, they have refactored it a few times 
and merged the two code paths for ipv4 and ipv6.  It bears no resemblance to 
what we have in our tree.


The killer reason why this is a problem that needs to be solved.. IPv6 + 
DNSSEC exercises this code a lot.

Performance isn't a factor - it's basic functionality that's at stake.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: Future of pf / firewall in FreeBSD ? - does it have one ?

2014-07-19 Thread Peter Wemm
On Saturday 19 July 2014 13:06:52 Baptiste Daroussin wrote:
 On Fri, Jul 18, 2014 at 03:22:18PM -0400, Allan Jude wrote:
  On 2014-07-18 15:07, Adrian Chadd wrote:
   On 18 July 2014 07:34, krad kra...@gmail.com wrote:
   that is true and I have not problem using man pages, however thats not
   the
   way most of the world work and search engines arent exactly new either.
   We
   should be trying to engage more people not less, and part of that is
   reaching out.
   
   Then do the port and maintain it.
   
   The problem isn't the desire to keep things up to date, it's a lack of
   people who want that _and_ are willing/able to do it _and_ are funded
   somehow.
   
   So, please step up! We'll all love you for it.
   
   
   
   -a
   ___
   freebsd-current@freebsd.org mailing list
   http://lists.freebsd.org/mailman/listinfo/freebsd-current
   To unsubscribe, send any mail to
   freebsd-current-unsubscr...@freebsd.org
  
  At vBSDCon Bapt@ volunteered to port the newer pf back to FreeBSD, after
  spending some hours driving with Henning.
 
 I tried and broke pf for month and my changes have been reverted, this is
 not as simple as it looks like, our code as diverge a lot in some part and
 we do support things that openbsd does not (vimage). Sync features requires
 us to be very careful, my priorities went elsewhere since that time, so now
 I will probably only focus on bringing features I care about, and not the
 entirely new pf.
 
 So no do not count me as volunteer to maintain pf, I ll probably do some
 work but not a full sync.

If anyone is looking for a really useful chunk to work on, please go back over 
the pf history in openbsd and find where they added ipv6 fragment support.  It 
was fairly well contained and didn't appear to be a big deal to port.  They 
did do something with mbuf tags that I'm suspicious of though.

IPv6 fragments are the biggest pain point we have on the freebsd.org cluster - 
yes, we use pf and IPv6 extensively, but dns with ipv6 involved is really 
painful without fragment support.

We sort-of work around it by using dedicated IPv6 address that has nothing but 
the dns resolver clients and allow  ipv6 fragments to it.  Its not ideal but 
it gets over the worst problems.

The other thing we had to do for usability is stop state tracking for udp dns 
- the sheer update rate was causing collisions and state drops / resets of 
other connections to the point of being really hard to use.

Those two tweaks - stopping heavy dns use from thrashing the state tables, and 
having a safe place to send fragments makes it quite usable for freebsd.org.

But, lack of ipv6 fragment processing still causes ongoing pain.  That's our 
#1 wish list item for the cluster.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: In tree builds broken in lib/ncurses?

2014-06-14 Thread Peter Wemm
On Saturday 14 June 2014 14:44:39 Steve Kargl wrote:
 On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote:
  Long story short.  I have laptop that is normally limited in
  available diskspace, so I do not install profiled libraries.
  I however have the need for running some code under the profiler
  (assuming clang can generate proper profiling).  I do the
  following,
 
 Is it possible to using profiling on FreeBSD-current?  After installing
 libc_p.a, I try to build math/lapack.  It dies with
 
 /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to
 symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from
 command line collect2: error: ld returned 1 exit status
 *** Error code 1

collect2? I think you've got something odd going on there..

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: In tree builds broken in lib/ncurses?

2014-06-14 Thread Peter Wemm
On Saturday 14 June 2014 15:30:02 Steve Kargl wrote:
 On Sat, Jun 14, 2014 at 03:12:36PM -0700, Steve Kargl wrote:
  On Sat, Jun 14, 2014 at 03:01:20PM -0700, Peter Wemm wrote:
   On Saturday 14 June 2014 14:44:39 Steve Kargl wrote:
On Sat, Jun 14, 2014 at 01:19:33PM -0700, Steve Kargl wrote:
 Long story short.  I have laptop that is normally limited in
 available diskspace, so I do not install profiled libraries.
 I however have the need for running some code under the profiler
 (assuming clang can generate proper profiling).  I do the
 following,

Is it possible to using profiling on FreeBSD-current?  After
installing
libc_p.a, I try to build math/lapack.  It dies with

/usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to
symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from
command line collect2: error: ld returned 1 exit status
*** Error code 1
   
   collect2? I think you've got something odd going on there..
  
  Maybe.  math/lapack is built with gfortran, which is from
  lang/gcc47 on my system.  lang/gcc47 is probably picking
  up the installed devel/binutils.  This would explain the
  /usr/local/bin/ld instead of our /usr/bin/ld.   libc_p.a is
  built with clang, so I'm probably running into yet-another
  clang vs gcc problem.
 
 Where is the symbol _end suppose to come from?
 
 Script started on Sat Jun 14 15:26:08 2014
 laptop-kargl:kargl[201] foreach i (/usr/lib/*.a)
 foreach? echo $i
 foreach? nm $i | grep 'U _end'
 foreach? nm $i | grep 'T _end'
 foreach? end
 /usr/lib/libc.a
  U _end

_end is a dynamic symbol that is synthesized by ld or linker scripts.  
Normally that would be /usr/bin/ld

peter@hub[10:35pm]~-110 grep _end /usr/libdata/ldscripts/elf_x86_64_fbsd.x
...
  _end.  Align after .bss to ensure correct alignment even if the
  _end = .; PROVIDE (end = .);

It used to be built into the a.out linker, but it's in the built-in linker 
scripts since the ELF switch.

Your problem isn't clang vs gcc or libc_p, it's /usr/local/bin/ld or a linker 
script the gfortran stuff is using.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.


Re: RES: KQueue vs Select (NetMap)

2014-05-28 Thread Peter Wemm
On Thursday 29 May 2014 01:57:38 Fred Pedrisa wrote:
 Hello,
 
 There are 4 threads, and a total of 32 FDs. What do you think ?

I think it is time for you to try it and find out...

I suspect it wouldn't make much difference at all if you just implement select 
semantics with kqueue.  

 -Mensagem original-
 De: owner-freebsd-curr...@freebsd.org
 [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Adrian Chadd
 Enviada em: quinta-feira, 29 de maio de 2014 01:52
 Para: Fred Pedrisa
 Cc: freebsd-current; Jan Bramkamp
 Assunto: Re: KQueue vs Select (NetMap)
 
 If your netmap thread(s) just have one or two FDs in some low range (say,
 under FD 8 or 10) - no.
 
 If you have a whole bunch of active FDs and your netmap threads get FDs that
 are high - then yes. select() operates on a bitmap of FD numbers. So if
 your netmap FD is like, FD 8 and it's the highest FD that you're interested
 in, select() only has to scan up to that FD. So it scans up to 8 FDs. If
 you have a very active program and it has thousands of FDs open, select()
 has to check all the FDs in the bitmap to see if they're set before getting
 to your netmap FD.
 
 So yes. kqueue() is actually rather nice.
 
 
 
 -a
 
 On 28 May 2014 21:48, Fred Pedrisa fredhp...@hotmail.com wrote:
  Hello,
  
  Ok, but in practice, is there any performance gain by moving from select
 
 to kQueue implementation ? Or is it not significant at all ?
 
  -Mensagem original-
  De: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] Em nome de
  Adrian Chadd Enviada em: quinta-feira, 29 de maio de 2014 01:46
  Para: Fred Pedrisa
  Cc: Jan Bramkamp; freebsd-current
  Assunto: Re: KQueue vs Select (NetMap)
  
  The advantage is being able to include it in the rest of a kqueue IO loop
 
 where it's doing other things.
 
  -a
  
  On 28 May 2014 20:53, Fred Pedrisa fredhp...@hotmail.com wrote:
  Hello,
  
  Yes, but kqueue support was added in recent commits as it says in the
  netmap changelog, is there any advantage ?
  
  -Mensagem original-
  De: owner-freebsd-curr...@freebsd.org
  [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp
  Enviada em: quinta-feira, 29 de maio de 2014 00:30
  Para: freebsd-current@freebsd.org
  Assunto: Re: KQueue vs Select (NetMap)
  
  On 29.05.2014 03:04, Fred Pedrisa wrote:
  Hey Guys,
  
  
  
  How does kQueue performs over select with netmap ?
  
  You are asking for a comparison between apples and oranges. Netmap is
  an API for high performance access to the low-level features of
  modern NICs. It works on batches of frames in hardware queues.
  
  The kqueue() and kevent() system calls are an event notification API.
  It is mostly used by application dealing with a large amount of
  non-blocking sockets (or other file descriptors). It reduces overhead
  inherent in
  select() and poll() by preserving state between calls. It also
  supports multiple types of events (read ready, write ready, timer
  expired, async i/o, etc.).
  
  Afaik the netmap pseudo-device supports only select() and poll().
  This is no performance problem because every thread will only deal
  with a small number of file descriptors to netmap devices.
  
  Netmap is designed to bypass the FreeBSD IP stack (for most frames).
  Kqueue is designed to scale to many sockets per process within the
  FreeBSD IP stack.
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to
 
 freebsd-current-unsubscr...@freebsd.org
 
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to
 
 freebsd-current-unsubscr...@freebsd.org
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 
 ___
 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

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.

signature.asc
Description: This is a digitally signed message part.


Re: What on earth is all this %20 crap at the end of the GUID? (newfs?)

2014-04-29 Thread Peter Wemm
On Tuesday 29 April 2014 20:52:30 Alan Somers wrote:
 On Tue, Apr 29, 2014 at 8:30 PM, Allan Jude free...@allanjude.com wrote:
  On 2014-04-29 19:51, Sean Bruno wrote:
  Created a simple partition:
   root@:~ # gpart create -s gpt da11
  
  da11 created
  root@:~ # gpart add -t freebsd-ufs da11
  da11p1 added
  root@:~ # gpart show da11
  =40  7814037088  da11  GPT  (3.6T)
  
40  7814037088 1  freebsd-ufs  (3.6T)
  
  root@:~ #
  
  Then run a newfs and reboot the system.  Upon reboot this is what I get?
  
  =40  7814037088  da11  GPT  (3.6T)
  
40  7814037088 1  freebsd-ufs  (3.6T)
  
  =40  7814037088  diskid/DISK-Z1Z0DQ73%20%20%20%20%20%20%20%20%
  20%20%20%20  GPT  (3.6T)
  
40  7814037088
  
  1  freebsd-ufs  (3.6T)
  
  
  What is going on here?
  
  sean
  
  That is highly unusual, does your disk have a bunch of blank spaces in
  its serial # or something?
 
 Not that unusual at all.  In ATA and SCSI alike it's common for text
 fields to be defined as fixed length strings.  I've seen many vendors
 pad their entries out with spaces; for some reason they're allergic to
 using NULLs.  geom should probably be modified to strip trailing
 whitespace from the serial number.

In this particular case, it's a modified ciss driver.  If memory serves, ciss 
pads its cam ident strings with spaces and that's showing up here.

FWIW, this is usually why I rm -rf /dev/gptid /dev/diskid before doing an 
import. I don't usually want the synthetic names in there.

-Peter
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.

signature.asc
Description: This is a digitally signed message part.


Re: installworld recreating unwanted dirs

2014-02-03 Thread Peter Wemm
On Mon, Feb 3, 2014 at 8:25 AM, Sean Bruno sean_br...@yahoo.com wrote:
 I don't understand what I'm doing wrong here.  I've added a lot of
 WITHOUT directives to my src.conf, but installworld seems to be
 ignoring them and recreating directories that make delete-old  make
 delete-old-libs removes.  Have I missed something obvious here?

The mtree based directory creation is (for the most part) unaware of
with/without flags.  There was some mtree partitioning for things like
bind and those were only created if bind was enabled.  But for the
most part, delete-old will prune things that aren't used.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
Yes, I know, gmail sucks now. If you see this then I forgot. Habits
are hard to break.
___
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: md2 on current and 10.

2014-01-08 Thread Peter Wemm
On 1/8/14, 7:00 AM, Mikhail T wrote:
 On 08.01.2014 02:54, Peter Wemm wrote:
  Could we, please, have MD2 resurrected before 10.0 is officially out?
  Preferably in both -lmd and -lcrypto, but certainly in the former. Thank
  you! Yours,
 The time to bring this up was before the freeze for 10.0, a good 6+
 months ago. It is way too late now.
 First of all, Peter, are you talking as a core-member, or expressing
 personal opinion? In any case, I'd say it is not entirely fair to blame me
 for reporting a problem late -- without any apologies about causing it in
 the first place...
 
 But is it really too late to add such a small piece back to where it was?
 I'm not talking about resurrecting uucp here... Meanwhile, any existing
 MD2-using application will simply break after upgrade -- does that not
 bother anyone? If the code was removed after 19 years in the tree, is 6
 months really too late to resurrect it?

Personal unless stated otherwise.

By too late I mean the cutoff has already passed for the final RC and
there won't be more unless there's an absolute emergency.

As for timeliness of the request, here's the original commit:

r234746 | obrien | 2012-04-27 19:48:51 -0700 (Fri, 27 Apr 2012) | 10 lines

Remove the RFC 1319 MD2 Message-Digest Algorithm routines from libmd.

1. The licensing terms for the MD2 routines from RFC is not under a BSD-like
   license.  Instead it is only granted for non-commercial Internet
   Privacy-Enhanced Mail.
2. MD2 is quite deprecated as it is no longer considered a cryptographically
   strong algorithm.

Discussed with: so (cperciva), core


The original feature cutoff schedules were:

 head/ slush:   August 24, 2013
 head/ freeze:  September 7, 2013

10.0 is already late.  The original plan would have had 10.0 released in
November.  That's before the first email in this thread - December.

You can always ask the release engineers for an exception, but given that
the release is already overdue I'd bet money you won't get a positive
reception to a request to a delay for md2.

You could ask obrien to revert his commit for head but I'd bet you won't
get a positive response there.

 However.. the code in libmd had had a non-commercial use restriction..
 Even if it wasn't too late, that code won't be back.
 That restriction was not (enough of) a problem for 20 years (since 1994) --
 and still is not in 9.x and 8.x. But, Ok...
 Your best bet is to create a crypto/libmd2 port.  Start with the code
 from openssl.
 Adding such a port increases the number of hoops for any user to jump
 through -- and the maintenance costs. Whereas the cost of simply adjusting
 the base OpenSSL's configuration to include MD2 functionality is virtually
 zero -- a single additional file file will be back (md2.h), and no new
 libraries...

The path of least resistance is to make a libmd2 port.  It's the only way I
can see you getting to use it on 10.0.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
___
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: md2 on current and 10.

2014-01-07 Thread Peter Wemm
On Wed, Dec 25, 2013 at 10:52 AM, Mikhail T mi+apa...@aldan.algebra.com wrote:
 On 20.12.2013 13:38, olli hauer wrote:
 md2 was deprecated in 2009 by the openssl project

  http://cvs.openssl.org/chngview?cn=18381
  CVE-2009-2409

 As fas as I know some Linux based projects have removed md2 from 
 openssl-0.9.x in 2009.
[..]
 Could we, please, have MD2 resurrected before 10.0 is officially out?
 Preferably in both -lmd and -lcrypto, but certainly in the former. Thank
 you! Yours,

The time to bring this up was before the freeze for 10.0, a good 6+
months ago. It is way too late now.

However.. the code in libmd had had a non-commercial use restriction..
Even if it wasn't too late, that code won't be back.

Your best bet is to create a crypto/libmd2 port.  Start with the code
from openssl.
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
___
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: latest openjdk7 triggers kernel panic

2013-12-26 Thread Peter Wemm
On Thu, Dec 26, 2013 at 7:39 AM, Antoine Brodin anto...@freebsd.org wrote:
 On Thu, Dec 26, 2013 at 1:04 PM, Andriy Gapon a...@freebsd.org wrote:
...
 Hello,

 FWIW,  I had a similar panic today on 9.2-RELEASE with a GENERIC kernel:
 panic: Bad entry start/end for new stack entry
 cpuid = 1
 KDB: stack backtrace:
 #0 0x80947986 at kdb_backtrace+0x66
 #1 0x8090d9ae at panic+0x1ce
 #2 0x80b81314 at vm_map_stack+0x274
 #3 0x80b83584 at vm_mmap+0x674
 #4 0x80b83d2f at sys_mmap+0x1cf
 #5 0x80cf187a at amd64_syscall+0x5ea
 #6 0x80cdbff7 at Xfast_syscall+0xf7

 It looks like the box was compiling java related ports (java/jaxen and
 devel/antlr) when it panic'ed.

This is troubling.  I'm wondering what's changed and why we haven't
seen this before.

Just so I'm clear, you're building 9.2 ports on a 9.2-REL kernel,
right?  and not something like building 9.2-REL ports inside a jail on
a 10.x or 11.x host?  10.x / 11.x are not involved and you're seeing
this?

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
___
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: latest openjdk7 triggers kernel panic

2013-12-26 Thread Peter Wemm
On Thu, Dec 26, 2013 at 12:01 PM, Konstantin Belousov
kostik...@gmail.com wrote:
 On Thu, Dec 26, 2013 at 07:51:45PM +0100, Antoine Brodin wrote:
 On Thu, Dec 26, 2013 at 7:33 PM, Peter Wemm pe...@wemm.org wrote:
  On Thu, Dec 26, 2013 at 7:39 AM, Antoine Brodin anto...@freebsd.org 
  wrote:
  On Thu, Dec 26, 2013 at 1:04 PM, Andriy Gapon a...@freebsd.org wrote:
  ...
  Hello,
 
  FWIW,  I had a similar panic today on 9.2-RELEASE with a GENERIC kernel:
  panic: Bad entry start/end for new stack entry
  cpuid = 1
  KDB: stack backtrace:
  #0 0x80947986 at kdb_backtrace+0x66
  #1 0x8090d9ae at panic+0x1ce
  #2 0x80b81314 at vm_map_stack+0x274
  #3 0x80b83584 at vm_mmap+0x674
  #4 0x80b83d2f at sys_mmap+0x1cf
  #5 0x80cf187a at amd64_syscall+0x5ea
  #6 0x80cdbff7 at Xfast_syscall+0xf7
 
  It looks like the box was compiling java related ports (java/jaxen and
  devel/antlr) when it panic'ed.
 
  This is troubling.  I'm wondering what's changed and why we haven't
  seen this before.
 Well, if MAP_STACK was started used only with update, or the condition
 for coalescing only holds due to changes in the update, this is not
 much strange.

openjdk7 doesn't appear to use MAP_STACK itself.  The mmap(..
MAP_STACK..) caller looks like it is libthr.

The only odd thing that stood with a quick browse of the code was that
openjdk tinkers with mprotect() for stack guard pages.  These will
presumably be right on the boundaries of the stacks.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
___
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: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds

2013-11-30 Thread Peter Wemm
On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd adr...@freebsd.org wrote:
[..]
 Are you able to have clang/llvm/gcc tell us where/when code is relying
 on undefined behaviour? So we can, like, fix them?

It wasn't all that long ago that we had this wonderful thing called
-Werror and had a clean kernel build.

The problem is that gcc and clang have different warning sets.  I seem
to recall we had -Werror on for gcc and off for clang.  IMHO it would
be more useful to do it the other way around.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
___
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: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds

2013-11-30 Thread Peter Wemm
On Sat, Nov 30, 2013 at 8:38 PM, Eitan Adler li...@eitanadler.com wrote:
 On Sat, Nov 30, 2013 at 11:26 PM, Peter Wemm pe...@wemm.org wrote:
 On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd adr...@freebsd.org wrote:
 [..]
 Are you able to have clang/llvm/gcc tell us where/when code is relying
 on undefined behaviour? So we can, like, fix them?

 It wasn't all that long ago that we had this wonderful thing called
 -Werror and had a clean kernel build.

 The problem is that gcc and clang have different warning sets.  I seem
 to recall we had -Werror on for gcc and off for clang.  IMHO it would
 be more useful to do it the other way around.

 Not all cases can be caught by static analysis.  They would all be
 caught be the integer sanitizer.  However, these have not yet been
 ported to FreeBSD.


I also missed the  -Wno-error-tautological-compare setting. Oops.

I personally tweak my builds a little so that:

  CC ../../../kern/kern_acct.c
  CC ../../../kern/kern_clock.c
WARNING: kern_clock.c: enum pmc_event has too many values: 1669  1023
  CC ../../../kern/kern_condvar.c
  CC ../../../kern/kern_conf.c
  CC ../../../kern/kern_cons.c
  CC ../../../kern/kern_cpu.c
  CC ../../../kern/kern_cpuset.c
../../../kern/kern_cpuset.c:637:16: warning: comparison of unsigned
expression  0 is always false [-Wtautological-compare]
for (i = 0; i  (_NCPUWORDS - 1); i++) {
~ ^ 
1 warning generated.
  CC ../../../kern/kern_context.c
  CC ../../../kern/kern_descrip.c
  CC ../../../kern/kern_dtrace.c

Warnings stand out nicely that way.

The diff is along these lines:

--- kern.pre.mk(revision 258784)
+++ kern.pre.mk(working copy)
@@ -126,12 +126,12 @@
 # Optional linting. This can be overridden in /etc/make.conf.
 LINTFLAGS=${LINTOBJKERNFLAGS}

-NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC}
-NORMAL_S= ${CC} -c ${ASM_CFLAGS} ${WERROR} ${.IMPSRC}
+NORMAL_C= @echo   CC ${.IMPSRC} ; ${CC} -c ${CFLAGS} ${WERROR}
${PROF} ${.IMPSRC}
+NORMAL_S= @echo   AS ${.IMPSRC} ; ${CC} -c ${ASM_CFLAGS} ${WERROR} ${.IMPSRC}
 PROFILE_C= ${CC} -c ${CFLAGS} ${WERROR} ${.IMPSRC}
-NORMAL_C_NOWERROR= ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC}
+NORMAL_C_NOWERROR= @echo   CC_NOWERROR ${.IMPSRC} ; ${CC} -c
${CFLAGS} ${PROF} ${.IMPSRC}
...

Unfortunately that interferes with my usual use of 'make -s' - silent.
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
___
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


Fwd: FYI: svn commit: r258283 - in head: . include lib lib/libc lib/libc/iconv lib/libc_nonshared

2013-11-17 Thread Peter Wemm
FYI, for folks not following commit messages..

There is a potential new-binaries-on-old-systems gotcha here.

If you compile an iconv-using program on a system *after* this commit and
try to run the binary on an *old* pre-commit system, you will get undefined
symbols.

Going forwards is fine - a buildworld on an established system is safe.
Old binaries run on new systems.

Most folks would never hit this, except perhaps:
* you build a bunch of iconv-using binaries in /usr/local, then revert your
/usr/src to and old rev and buildworld.
* you try and copy/install binary packages build on a new system onto an
old system.

New binaries on old systems generally isn't supported.  Particularly so on
-current.

-- Forwarded message --
From: Peter Wemm pe...@freebsd.org
Date: Sun, Nov 17, 2013 at 2:52 PM
Subject: svn commit: r258283 - in head: . include lib lib/libc
lib/libc/iconv lib/libc_nonshared
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org


Author: peter
Date: Sun Nov 17 22:52:17 2013
New Revision: 258283
URL: http://svnweb.freebsd.org/changeset/base/258283

Log:
  Attempt to move the POSIX iconv* symbols out of runtime linker space.
  FreeBSD systems usually implemented this as a third party module and
  our implementation hasn't played as nicely with the old way as it could
  have.

  To that end:
  * Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix.
  * Provide .symver compatability with existing 10.x+ binaries that
referenced the iconv symbols. All existing binaries should work.
  * Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript
at /usr/lib/libc.so.
  * Move the iconv* wrapper symbols to libc_nonshared.a

  This should solve the runtime ambiguity about which symbols resolve
  to where.  If you compile against the iconv in libc, your runtime
  dependencies will be unambiguous.

  Old 9.x libraries and binaries will always resolve against their
  libiconv.so.3 like they did on 9.x.  They won't resolve against libc.

  Old 10.x binaries will be satisified by the .symver helpers.

  This should allow ports to selectively compile against the libiconv
  port if needed and it should behave without ambiguity now.



-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
___
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: Fun with nvi

2013-08-11 Thread Peter Wemm
On Sun, Aug 11, 2013 at 1:35 AM, Alexey Dokuchaev da...@freebsd.org wrote:
 On Sat, Aug 10, 2013 at 10:33:20AM -0700, Peter Wemm wrote:
 I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2.

 https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1
 https://github.com/lichray/nvi2

 The goal was to update the multibyte handling in nvi-1.79 (the one we
 have in our tree) in such a way we could import it.

 Yes, please do something about our base(1) being unable to talk in anything
 non-ASCII.  I'm using editors/nvi-devel now, which was WIDECHAR option, and
 was wondering why those changes were never imported into the base.

 How is nvi 1.81.6 (per editors/nvi-devel) is different from nvi2, btw?

The original reason was that nvi-devel switched from the db-1.x API to
db-3/db-4 which were sleepycat licensed, and are now Oracle.  It was a
big chunk of code at the time.  eg:
USE_BDB=42+
CONFIGURE_ARGS+=--with-db-prefix=${LOCALBASE}

nvi2 is nvi-1.79 from base with a serious cleanup pass.  The
iconv/multibyte code will look quite familiar if you've looked at the
nvi-devel code, along with a cherry-picking of additions from nvi-m17n
for better CJK/non-utf8 support.

nvi2 does not have the same level of sophisticated encoding detection
that nvi-m17n has.
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
brueffer ZFS must be the bacon of file systems. everything's better with ZFS
___
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


Fun with nvi

2013-08-10 Thread Peter Wemm
I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2.

https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1
https://github.com/lichray/nvi2

The goal was to update the multibyte handling in nvi-1.79 (the one we
have in our tree) in such a way we could import it.

Anyway.. an early WIP:   http://people.freebsd.org/~peter/nvi2.tgz

peter@overcee[ 9:37AM]~/head/contrib/nvi/catalog-1643 echo $LANG
en_US.UTF-8
peter@overcee[ 9:38AM]~/head/contrib/nvi/catalog-1644 vi -c 'set
fileencoding=GB2312' zh_CN.GB2312.base

.. leads to fun things like:
http://people.freebsd.org/~peter/nvi2-transcoding.png
that's editing the file in GB2312 format, but converting to utf-8 on
the fly for my terminal.

This is with the WITH_ICONV=yes in make.conf.  nvi2 will build without
it but obviously won't be able to work with non-default encoding
methods.

In straight up UTF-8 mode: http://people.freebsd.org/~peter/nvi2-utf8-4.png

How to use the tarball..
1) rm -rf contrib/nvi usr.bin/vi
2) extract tarball into src tree
3) patch -p0  nvi.diff  (this adds a built-tool to world)

Note that I haven't actually done a buildworld yet. I've just been
building it directly from src/usr.bin/vi with
make obj  make depend  make all  make install
.. to save time.

But you'll need to have WITH_ICONV=yes in make.conf to do the fancy
stuff.  Note that the ports tree is a long way from being
WITH_ICONV=yes safe, so don't do this on an important machine.  An
example of the tweaks to make ports happier:
http://people.freebsd.org/~peter/iconv.diff - that's not complete.
Most of the ports tree was updated to use Mk/Uses/iconv.mk but there's
still some oddballs scattered around in weird places.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
brueffer ZFS must be the bacon of file systems. everything's better with ZFS
___
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: svn error during 'make buildkernel'?

2013-08-04 Thread Peter Wemm
On Sun, Aug 4, 2013 at 4:23 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
 On Sat, Aug 03, 2013 at 05:43:13PM -0400, Glen Barber wrote:
 On Sat, Aug 03, 2013 at 02:30:23PM -0700, Steve Kargl wrote:
 
  Thanks.
 
  Looks like an entry in /usr/src/UPDATING is missing if
  /usr/bin/svn* is forcing an obsolscence of a functioning
  installed port.
 

 The port was at 1.8.x before I added the additional lookup of
 svnlite to the script.  There really is no need for UPDATING entry,
 since 1.7.9 is deprecated, and the behavior you have seen is not a fatal
 error with the buildkernel process.

 BTW, you should upgrade devel/subversion anyway, since there are
 security vulnerabilities.


 Here's a perfect example why chasing the bleeding edge ports
 is a stupid idea.  After upgrading devel/subversion as you
 suggested, I see

 cd /usr/ports
 % svn upgrade
 % svn update
 Updating '.':
 svn: E17: Unrecognized URL scheme for 'http://svn.freebsd.org/ports/head'
 % svn --version | grep version
 svn, version 1.8.1 (r1503906)
 % which svn
 /usr/local/bin/svn
 %which svnlite
 /usr/bin/svnlite
 % svnlite --version | grep version
 svn, version 1.8.1 (r1503906)
 Subversion is open source software, see http://subversion.apache.org/
 % svnlite
 % svnlite update
 Updating '.':
 Uwww/squid33/distinfo
 Uwww/squid33/files/squid.in
 Uwww/squid33/Makefile
 Ucad/gmsh/Makefile
 Ucad/gmsh/distinfo
 Ucad/gmsh/pkg-plist
 Ulang/gcc47/Makefile
 Ulang/gcc47/distinfo
 Ulang/gdc/Makefile
 Ux11-clocks/xdaliclock/Makefile
 Ux11-clocks/xdaliclock/distinfo
 Unet-mgmt/virt-viewer/Makefile
 Unet-mgmt/virt-viewer/distinfo
 Unet-mgmt/virt-viewer/pkg-plist
 Ux11/xfwp/Makefile
 Ux11/xfwp/distinfo
 Updated to revision 324253.

 So, how do I fix svn, now?

ports/UPDATING:

20130619:
  AFFECTS: users of devel/subversion
  AUTHOR: oha...@freebsd.org

  devel/subversion has been upgraded from 1.7.10 to 1.8.0

  If you want to upgrade, and use http/https access to repositories,
  please check, that SERF option is enabled, as NEON support
  ^
  is gone. Also, mod_dontdothat and svnauthz_validate are
  now eanbled with one option TOOLS, among other new tools
  and SVNMUCC is enabled always.

  subversion-1.7.x is available as devel/subversion17

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: So you can \342\200\231 .. for when a ' just won't do
brueffer ZFS must be the bacon of file systems. everything's better with ZFS
___
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: [HEADSUP] No more pkg_install on HEAD by default

2013-07-13 Thread Peter Wemm
On Sat, Jul 13, 2013 at 11:54 AM, Teske, Devin
devin.te...@fisglobal.com wrote:

 So yes... I'm asking... in a HEAD world, what is the officially supported 
 method of acquisition?

This has been answered elsewhere, but to be absolutely clear:

* 10.0 will ship with pkgng format packages.

* pkgng will be configured to pull via http from project
infrastructure by default.

* The project will not be providing pkg_install format packages via
any method for 10.x.

This doesn't stop third parties building and providing them
unofficially but my understanding is that they won't be on any project
operated freebsd.org sites.

Footnote... *.cc.freebsd.org are generally project operated sites.
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: So you can \342\200\231 .. for when a ' just won't do
brueffer ZFS must be the bacon of file systems. everything's better with ZFS
___
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: [HEADSUP] No more pkg_install on HEAD by default

2013-07-13 Thread Peter Wemm
On Sat, Jul 13, 2013 at 9:24 PM, Peter Wemm pe...@wemm.org wrote:

 Footnote... *.cc.freebsd.org are generally project operated sites.

.. gah.. generally *NOT* project operated sites.  They're third party
/ regional / local.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
___
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: dialog4ports crashing in head recently

2013-06-23 Thread Peter Wemm
On Sun, Jun 23, 2013 at 1:36 PM, Nathan Whitehorn
nwhiteh...@freebsd.org wrote:
 On 06/23/13 14:52, Dan Mack wrote:

 dialog4ports has been crashing on all of my systems for about the last
 week.  I rebuilt it with debug symbols and this is what I got (doesn't
 matter which port is using it).

 Anyone else seeing this?


 libdialog was updated recently. I had to rebuild dialog4ports after that to
 keep it from crashing. Maybe you have the same issue?
 -Nathan

I've had the same problem on the freebsd.org cluster over the last
week or so.  A forced rebuild of dialog4ports solved it for me.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
___
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 kernel panic, known incompatibilities with clang CPUTYPE/COPTFLAGS?

2013-06-12 Thread Peter Wemm
On Wed, Jun 12, 2013 at 1:39 PM, Dimitry Andric d...@freebsd.org wrote:
 On Jun 12, 2013, at 22:30, Alexander Leidinger alexan...@leidinger.net 
 wrote:
 I try to update from a pre-clang world (r242511M) to now (r251618M).
 The resulting kernel boots, but while starting some jails (with ezjail
 from ports, so fairly late in the boot process) I get a kernel panic
 (IIRC zfs trying to access page 0).

 If you are running on i386, it might be a stack overflow?  Try
 increasing the stack a little, it might help in that case.


For i386 I'd be more inclined to suspect KVA exhaustion.

For non-PAE, as a shot in the dark, increase
options KVA_PAGES=384
.. the default is 256 for PAE.  that increases kernel KVA from 1GB to 1.5GB.

For a PAE system, this number is multipled by 2, so a corresponding
change is 512 - 768.

This is just a shot in the dark.  If this is amd64, then never mind,
KVA_PAGES is meaningless there.
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
On IRC, talking about C++:
BigKnife I think that it is a good thing I will never meet Bjarne on a street
BigKnife cause really, I don't want to end up in prison or anything
___
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: in_pcblookup_local (?)

2013-05-03 Thread Peter Wemm
On Thu, May 2, 2013 at 11:32 AM, John Baldwin j...@freebsd.org wrote:
 On Thursday, May 02, 2013 1:53:47 pm Ian FREISLICH wrote:
 John Baldwin wrote:
  On Thursday, May 02, 2013 7:25:08 am Robert N. M. Watson wrote:
  
   On 2 May 2013, at 11:42, Glen Barber wrote:
  
Hmm.  Perhaps it would be worthwhile for me to rebuild the current
kernel with DDB support.  It looks like the machine has panicked a few
times over the last two weeks or so, but based on the timestamps of the
crash dumps and nagios complaints, happened during the middle of the
night when I would not have really noticed, or otherwise would have 
just
blamed my ISP.
   
Two of the panics are ath(4) related.  One looks similar to the one
referenced in this thread, similarly triggered by a CFEngine process.
   
In that case, the backtrace looks like:
   
#4 0x808cdbb3 at calltrap+0x8
#5 0x807371d8 at in_pcb_lport+0x128
#6 0x8073745a at in_pcbbind_setup+0x16a
#7 0x80737d8e at in_pcbconnect_setup+0x71e
#8 0x80737df9 at in_pcbconnect_mbuf+0x59
#9 0x807bf29f at udp_connect+0x11f
#10 0x80680615 at kern_connectat+0x275
   
Regarding DDB though, it would be rather difficult to access the 
machine
if it drops to a DDB debugger session, since the machine acts as my
firewall.
  
   Thanks -- will take a look at the attached.
  
   FWIW, though, I'm worried by the number of panics you are seeing, 
   especiall
 y
  given that they involve multiple subsystems, and in particular, John's
  observation about a potentially corrupted pointer. This makes me wonder
  whether (a) you are experiencing hardware faults -- it would be worth 
  running

  some memory/cpu/etc tests and (b) if we might be seeing a software memory
  corruption bug of some sort.
 
  Other users have reported this (Ian Lepore), and Peter Wemm can now 
  reproduce
  these at will as well, so I think this is a software bug.  What might be
  easiest if we can't figure this out from the crashdump is just to bisect 
  the
  offending revision.

 I've started a binary search.  I'll let you know what that turns up.

 Thanks, and sorry for getting my Ian's mixed up. :-/

 --
 John Baldwin

I forgot to roll back one of the routers at nyi.freebsd.org and it
paniced again, the same way as before:

Fatal trap 9: general protection fault while in kernel mode^M
cpuid = 3; apic id = 03^M
instruction pointer = 0x20:0x8067284c^M
stack pointer   = 0x28:0xff8098688760^M
frame pointer   = 0x28:0xff80986887a0^M
code segment= base 0x0, limit 0xf, type 0x1b^M
= DPL 0, pres 1, long 1, def32 0, gran 1^M
processor eflags= interrupt enabled, resume, IOPL = 0^M
current process = 15041 (svn)^M
[ thread pid 15041 tid 100208 ]^M
Stopped at  in_pcblookup_local+0x5c:cmpw%r12w,0x18(%rax)^M


#8  0x80829dff in calltrap () at ../../../amd64/amd64/exception.S:228
#9  0x8067284c in in_pcblookup_local (pcbinfo=0x80c9e180, laddr=
  {s_addr = 708980576}, lport=607, lookupflags=1, cred=0xfe006956d700)
at ../../../netinet/in_pcb.c:1438
#10 0x80672d38 in in_pcb_lport (inp=0xfe00098aa620,
laddrp=0xff809845d860, lportp=0xff809845d86e,
cred=0xfe006956d700,
lookupflags=1) at ../../../netinet/in_pcb.c:457
#11 0x80672fba in in_pcbbind_setup (inp=0xfe00098aa620, nam=0x0,
laddrp=0xff809845d900, lportp=0xff809845d90e,
cred=0xfe006956d700)
at ../../../netinet/in_pcb.c:615
#12 0x806738ee in in_pcbconnect_setup (inp=0xfe00098aa620,
nam=value optimized out, laddrp=0xff809845d9b8,
lportp=0xff809845d9be,
faddrp=0xff809845d9b4, fportp=0xff809845d9bc, oinpp=0x0,
cred=0xfe006956d700) at ../../../netinet/in_pcb.c:1019
#13 0x80673959 in in_pcbconnect_mbuf (inp=0xfe00098aa620,
nam=value optimized out, cred=value optimized out, m=0x0)
at ../../../netinet/in_pcb.c:645
#14 0x806fafcf in udp_connect (so=0xfe002e150d48,
nam=0xfe00264df3b0,
td=0xfe00091df490) at ../../../netinet/udp_usrreq.c:1530
#15 0x805faea5 in kern_connectat (td=0xfe00091df490, dirfd=-100,
fd=value optimized out, sa=0xfe00264df3b0) at
../../../kern/uipc_syscalls.c:593
#16 0x805fafc1 in sys_connect (td=0xfe00091df490,
uap=0xff809845db70)
at ../../../kern/uipc_syscalls.c:559
#17 0x8083f571 in amd64_syscall (td=0xfe00091df490, traced=0)
at subr_syscall.c:134

There's been two separate machines, at least twice each on this exact
panic / trace.  Always with doing a 'svn update'.

Rolling back to April 5th 249172 solves it.  (There's nothing
particular about that rev, except it was top-of-tree when the last
update was done).

I see a number locking changes in the area.  Note that this is UDP,
most likely a dns

Re: Light humour

2013-04-29 Thread Peter Wemm
On Mon, Apr 29, 2013 at 7:33 PM, Teske, Devin devin.te...@fisglobal.com wrote:

 On Apr 29, 2013, at 2:53 PM, Robison, Dave wrote:

 http://news.netcraft.com/archives/2013/04/01/most-reliable-hosting-company-sites-in-march-2013.html


 (obligatory) netcraft confirms it!

 (smiles)

You don't need netcraft..  the tools are built in!

  http://www.youtube.com/watch?v=SXmv8quf_xM

(Please, don't be drinking anything.. I disclaim all responsibility
for keyboard damage)


-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
___
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: Anyone have scripts for managing interfaces under new CARP setup?

2013-04-05 Thread Peter Wemm
On Tue, Apr 2, 2013 at 3:37 PM, Freddie Cash fjwc...@gmail.com wrote:
 On 2013-04-02 1:52 AM, Gleb Smirnoff gleb...@freebsd.org wrote:

   Freddie,

 On Wed, Mar 27, 2013 at 04:10:03PM -0700, Freddie Cash wrote:
 F Just curious if anyone has any scripts for managing fail-over of
 multiple
 F interfaces using the new CARP setup in 10-CURRENT.
 F
 F Fail-over of all CARP vhids associated with a single interface is
 working
 F correctly.  But, I have 2 separate, physical interfaces running with
 CARP,
 F and want to fail-over everything if one of the links (or boxes) goes
 down.
 F
 F Figured I'd ask around to see if anyone has done something like this
 F already.  I've been playing with devd.conf settings and logging
 events, but
 F don't have anything written up to do the actual switch yet.

   Same as for old CARP, you can achieve behavior when a box with lower
 advskew yields master status to a second one, setting:

 sysctl net.inet.carp.preempt=1

   If an interface on the master has proper link state notification to the
 kernel, then once the interface goes down, the advskew on the box will be
 demoted and backup box will preempt it.

 That's how I have things set and it wasn't switching the 2nd interface.

 However, I think that may be due to the IPFW rules on one interface
 blocking CARP multicast packets on that interface, while they were going
 through correctly on the 2nd interface. I'll see if I can schedule a manual
 test later this week now that IPFW is configured correctly.

 Thanks for the confirmation of things are supposed to work.

We use new-carp on 10.x on the freebsd.org cluster.  There's machines
with 10+ vlans with carp on each and pf.

I find some of the replacement tools a little lacking but one thing
I've done is use a dummy vlan to cause an entire machine to demote
itself based on bgp default-route state.  I wrote a script to do this
before I became aware of ifstated(8).  This is necessary for us more
because of the unusual uplink arrangement we have at one of the
cluster locations.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE
___
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: Any objections/comments on axing out old ATA stack?

2013-03-30 Thread Peter Wemm
On Sat, Mar 30, 2013 at 4:29 PM, Matthias Andree mand...@freebsd.org wrote:
 Am 27.03.2013 22:22, schrieb Alexander Motin:
 Hi.

 Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
 stack, using only some controller drivers of old ata(4) by having
 `options ATA_CAM` enabled in all kernels by default. I have a wish to
 drop non-ATA_CAM ata(4) code, unused since that time from the head
 branch to allow further ATA code cleanup.

 Does any one here still uses legacy ATA stack (kernel explicitly built
 without `options ATA_CAM`) for some reason, for example as workaround
 for some regression? Does anybody have good ideas why we should not drop
 it now?

 Alexander,

 The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397
 where the SATA NCQ slots stall for some Samsung drives in the new stack,
 and consequently hang the computer for prolonged episodes where it is in
 the NCQ error handling, disallows removal of the old driver. (Last
 checked with 9.1-RELEASE at current patchlevel.)

We're talking about 10.x, so if you want it fixed, you need update
with 10.x information.

Please put 10.x diagnostics in the PR.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE
___
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: NewNFS vs. oldNFS for 10.0?

2013-03-15 Thread Peter Wemm
On Fri, Mar 15, 2013 at 2:03 PM, John Baldwin j...@freebsd.org wrote:
 On Friday, March 15, 2013 11:24:32 am Andre Oppermann wrote:
 On 15.03.2013 14:46, John Baldwin wrote:
  On Friday, March 15, 2013 9:40:56 am Andre Oppermann wrote:
  Hi Rick, all,
 
  is there a plan to decide for one NFS implementation for FreeBSD 10.0,
  or to keep both around indefinately?
 
  I'm talking about:
 oldNFS in sys/{nfs, nfsclient, nfsserver} NFSv2+NFSv3
 newNFS in sys/fs/{nfs, nfsclient, nfsserver}  NFSv2+NFSv3+NFSv4
 
  NewNFS supports newer NFS standards and seems to have proven itself in
  some quite heavy traffic environments.
 
  Is there any reason to keep oldNFS around other than nostalgic?
 
  It can probably be removed.  It's kind of handy to keep around as long as 
  8.x
  is around since it uses oldNFS by default as it makes merging bugfixes to 
  the
  NFS client a bit easier (you fix both clients in HEAD and can then just svn
  merge both of those to 8 and 9).  Having several fixes to the NFS client
  recently and being in a position of still using 8.x with oldNFS in 
  production,
  I would prefer to not remove it quite yet.

 Do you have a timeframe on the sunset of oldNFS in HEAD so we can communicate
 a) that oldNFS won't be in 10.0; and b) it will go on date X?

 I thought I implied one above: when 8.x is EOL'd.  However, that has more to 
 do
 with developer convience.  It's actually a PITA to use the old NFS client even
 on 9.0.

Yes to both.  As somebody who uses oldNFS in production in 9.x, I can
vouch for that.

Personally I'd like to see oldnfs go away from head after a
comfortable dust-settling period 8.4-R and then call it a day.

Although, please, as part of this please hunt down and s/newnfs/nfs/g
in the process.  This should be done well before 10.x so loose ends
can be tracked down and fixed.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE
___
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: Response of *.freebsd.org websites are very slow

2013-02-28 Thread Peter Wemm
On Thu, Feb 28, 2013 at 3:44 AM, Fbsd8 fb...@a1poweruser.com wrote:
[..]

 From cleveland ohio and www.freebsd.org is un-reachable again. It comes and
 gos. To me it's acting like someone high up is making dns changes.
 Some freebsd official better contact yahoo and put a stop to what ever there
 fooling around with.

Nope.  It isn't DNS, but there is a routing issue for ipv6 space
between Level-3 and and Yahoo.  I'm working on it.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE
___
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: Response of *.freebsd.org websites are very slow

2013-02-27 Thread Peter Wemm
On Wed, Feb 27, 2013 at 11:25 AM, Mehmet Erol Sanliturk
m.e.sanlit...@gmail.com wrote:
 I have installed snapshot

 FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso

 # traceroute ftp.freebsd.org

 3 failures : traceroute : unknown host ftp.freebsd.org
 2 successes :

 Route is Izmir ( Turkey ) - Frankfurt - New York - San Jose -
 freebsd.isc.org ( 204.152.184.73 )

 and pkg_add is not able to find package site .

 Perhaps for many tries it may find in some of the tries , but this will not
 be a feasible way .

Clearly you are having dns problems.

First, try a dig with the +trace flag, eg:

$ dig +trace www.freebsd.org.

;  DiG 9.8.3-P1  +trace www.freebsd.org.
;; global options: +cmd
.   518400  IN  NS  e.root-servers.net.
.   518400  IN  NS  j.root-servers.net.
.   518400  IN  NS  h.root-servers.net.
.   518400  IN  NS  d.root-servers.net.
.   518400  IN  NS  f.root-servers.net.
.   518400  IN  NS  b.root-servers.net.
.   518400  IN  NS  i.root-servers.net.
.   518400  IN  NS  g.root-servers.net.
.   518400  IN  NS  c.root-servers.net.
.   518400  IN  NS  k.root-servers.net.
.   518400  IN  NS  a.root-servers.net.
.   518400  IN  NS  m.root-servers.net.
.   518400  IN  NS  l.root-servers.net.
;; Received 512 bytes from 10.0.0.1#53(10.0.0.1) in 234 ms

org.172800  IN  NS  a2.org.afilias-nst.info.
org.172800  IN  NS  d0.org.afilias-nst.org.
org.172800  IN  NS  c0.org.afilias-nst.info.
org.172800  IN  NS  b0.org.afilias-nst.org.
org.172800  IN  NS  a0.org.afilias-nst.info.
org.172800  IN  NS  b2.org.afilias-nst.org.
;; Received 435 bytes from 2001:500:2d::d#53(2001:500:2d::d) in 1469 ms

freebsd.org.86400   IN  NS  ns1.isc-sns.net.
freebsd.org.86400   IN  NS  ns2.isc-sns.com.
freebsd.org.86400   IN  NS  ns3.isc-sns.info.
;; Received 132 bytes from 199.19.56.1#53(199.19.56.1) in 1165 ms

www.freebsd.org.120 IN  CNAME   wfe0.ysv.freebsd.org.
wfe0.ysv.freebsd.org.   3600IN  A   8.8.178.110
freebsd.org.3600IN  NS  ns2.isc-sns.com.
freebsd.org.3600IN  NS  ns1.isc-sns.net.
freebsd.org.3600IN  NS  ns3.isc-sns.info.
;; Received 264 bytes from 63.243.194.1#53(63.243.194.1) in 27 ms

Note the isc-sns.com/net/info addresses.  These are our public-facing
DNS servers and are distributed around the world.

You should see something like this:
$ host ns1.isc-sns.net
ns1.isc-sns.net has address 72.52.71.1
...
ns2.isc-sns.com has address 38.103.2.1
ns3.isc-sns.info has address 63.243.194.1

It would be interesting to see traceroutes to these IP addresses.

You had problems above with the nslookup commands.  You might try this:
$ nslookup www.freebsd.org ns1.isc-sns.net
Server: ns1.isc-sns.net
Address:2001:470:1a::1#53

www.freebsd.org canonical name = wfe0.ysv.freebsd.org.
Name:   wfe0.ysv.freebsd.org
Address: 8.8.178.110

or even:
$ nslookup www.freebsd.org 72.52.71.1
Server: 72.52.71.1
Address:72.52.71.1#53

www.freebsd.org canonical name = wfe0.ysv.freebsd.org.
Name:   wfe0.ysv.freebsd.org
Address: 8.8.178.110

What does your /etc/resolv.conf file look like?


What happens if you change it to (as a debugging aid):
$ cat /etc/resolf.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

Does that change anything?
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE
___
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: Response of *.freebsd.org websites are very slow

2013-02-27 Thread Peter Wemm
On Wed, Feb 27, 2013 at 6:46 PM, Kevin Oberman rkober...@gmail.com wrote:
 On Wed, Feb 27, 2013 at 11:55 AM, Niclas Zeising zeis...@daemonic.sewrote:

 On 2013-02-27 20:25, Mehmet Erol Sanliturk wrote:
  I have installed snapshot
 
  FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso
 
  # traceroute ftp.freebsd.org
 
  3 failures : traceroute : unknown host ftp.freebsd.org
  2 successes :
 
  Route is Izmir ( Turkey ) - Frankfurt - New York - San Jose -
  freebsd.isc.org ( 204.152.184.73 )
 
  and pkg_add is not able to find package site .
 
  Perhaps for many tries it may find in some of the tries , but this will
 not
  be a feasible way .

 Does Turkey (or your ISP) have any sort of great firewall or other
 restrictions on network traffic?  Do you have a firewall somewhere?
 I have no trouble reaching www.freebsd.org and ftp.freebsd.org from 3
 different ASes using both IPv4 and IPv6.
 Regards!


 Just in case it is relevant ot someone else, www.freebsd.com  is currently
 unreachable via IPv6 from Level(3). While the address is announced by
 Yahoo!, it is from an address block belonging to Level(3) but is being
 announced by Yahoo!. This works fine as long as you are NOT using Level(3).
 IPv4 is not involved.

 NOTE: This may be a problem caused by n error on the part of Level(3),
 Yahoo!, or FreeBSD. Without knowing details of how FreeBSD got the address
 and what arrangements Yahoo! made for announcing it to peers, there is no
 way to tell for sure. I can only say that ARIN shows no assignment from L3
 to Yahoo or FreeBSD and the same situation is present for another /48 in
 the same L3 /32.

I will ask about this tomorrow.  There is supposed to be
L3-Yahoo-FreeBSD ipv6 connectivity.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE
___
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: [HEADSUP CFT] pkg 1.0rc1 and schedule

2012-07-13 Thread Peter Wemm
On Fri, Jul 13, 2012 at 5:14 AM, Fbsd8 fb...@a1poweruser.com wrote:
 What I want to know is this new pkg system going to remove the requirement
 of having the complete ports tree on my system?

 What I am looking for in an port system, is to install a port and any files
 needed for the parent port and its dependents to automatically be
 downloaded. So in the end my system ports tree only contain the files used
 to install the ports I use and their dependents.

That is precisely what pkgng is for.

At the risk of over-simplifying:
* Generally eliminate the need for having /usr/ports installed for end
user consumers of freebsd if you have no desire to compile ports with
custom options.
* Generally eliminate the need for layers over the top of pkg* like
portupgrade/portmaster/portmanager for those people.
* Play nicely with people who *are* building some (or all) of their
packages from /usr/ports.
* Provide enough look and feel compatibility with the old pkg_* tools
so people will feel enough at home.
* Assimilate an existing pkg_* machine.
* Store complete metadata so that going foward we have much better
support for package sets - eg: package repositories with custom
options that play nicely with official packages.
* Be extensible so that we can add to it as we go forward.

In the new world order, things like portupgrade and portmanager tend
to be used to manage interactions between personally build ports from
/usr/ports and external binary packages.  If you continue to build
from /usr/ports, the only thing that changes is bsd.port.mk uses a
different command to register a package and you still use
portupgrade/portmaster/whatever to orchestrate your personal package
rebuilding.  (Well, portmaster does if you apply the simple patch to
it).

pkg-1.0 is primarily an infrastructure change.   Instead of metadata
being stored in discrete +FOO and +BAR files in a .tgz file, it is
stored in a structured, extensible file.  Instead of an incomplete set
of metadata being stored in /var/db/pkg/* and having to be augmented
by reaching over to /usr/ports/*, a full set of data is stored in a
.sqlite file.  Instead of version numbers being baked into the package
name as an ascii string, the package system uses version numbers as
first class metadata.

In reality, not much will change at the switch throwing, except that
of having good reason to be afraid of pkg_add -r, you'll be able to
reasonably expect it's replacement (pkg install) to work.  And a bunch
of people who have a /usr/ports tree will suddenly wonder why they
even have it there at all.  It becomes incredibly convenient and fast
to use packages.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
All of this is for nothing if we don't go to the stars - JMS/B5
If Java had true garbage collection, most programs would delete
themselves upon execution. -- Robert Sewell
___
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: boot2 overflow when building with clang

2012-03-08 Thread Peter Wemm
On Wed, Mar 7, 2012 at 4:18 PM, Jung-uk Kim j...@freebsd.org wrote:
 On Tuesday 06 March 2012 11:51 pm, Jia-Shiun Li wrote:
 I am not familiar with boot2, but it looks like allocated size for
 boot2 is not enough to hold code generated by clang. Reverting
 r232570 fixes it.

 === sys/boot/i386/boot2 (all)
 objcopy -S -O binary boot1.out boot1
 dd if=/dev/zero of=boot2.ldr bs=512 count=1
 clang -Os  -fno-guess-branch-probability  -fomit-frame-pointer
 -fno-unit-at-a-time  -mno-align-long-strings  -mrtd  -mregparm=3
 -DUSE_XREAD  -DUFS1_AND_UFS2  -DFLAGS=0x80  -DSIOPRT=0x3f8
 -DSIOFMT=0x3  -DSIOSPD=9600
 -I/usr/src/sys/boot/i386/boot2/../../common
 -I/usr/src/sys/boot/i386/boot2/../btx/lib -I.  -Wall
 -Waggregate-return -Wbad-function-cast -Wcast-align
 -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
 -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings
 -Winline --param max-inline-insns-single=100  -mllvm
 -stack-alignment=8 -mllvm -inline-threshold=3  -mllvm
 -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2
 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float
 -std=gnu99    -S -o boot2.s.tmp
 /usr/src/sys/boot/i386/boot2/boot2.c
 sed -e '/align/d' -e '/nop/d'  boot2.s.tmp  boot2.s
 rm -f boot2.s.tmp
 clang  -c boot2.s
 clang -Os  -fno-guess-branch-probability  -fomit-frame-pointer
 -fno-unit-at-a-time  -mno-align-long-strings  -mrtd  -mregparm=3
 -DUSE_XREAD  -DUFS1_AND_UFS2  -DFLAGS=0x80  -DSIOPRT=0x3f8
 -DSIOFMT=0x3  -DSIOSPD=9600
 -I/usr/src/sys/boot/i386/boot2/../../common
 -I/usr/src/sys/boot/i386/boot2/../btx/lib -I.  -Wall
 -Waggregate-return -Wbad-function-cast -Wcast-align
 -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
 -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings
 -Winline --param max-inline-insns-single=100  -mllvm
 -stack-alignment=8 -mllvm -inline-threshold=3  -mllvm
 -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2
 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float
 -std=gnu99     -c
 /usr/src/sys/boot/i386/boot2/sio.S
 ld -static -N --gc-sections -nostdlib -Ttext 0x2000 -o boot2.out
 /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o
 sio.o objcopy -S -O binary boot2.out boot2.bin
 btxld -v -E 0x2000 -f bin -b
 /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr
 -o boot2.ld -P 1 boot2.bin
 kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1
 client: fmt=bin size=15a1 text=0 data=0 bss=0 entry=0
 output: fmt=bin size=1e31 text=200 data=1c31 org=0 entry=0
 -49 bytes available
 *** [boot2] Error code 1

 Stop in /usr/src/sys/boot/i386/boot2.
 *** [all] Error code 1

 Stop in /usr/src/sys/boot/i386.
 *** [all] Error code 1

 Stop in /usr/src/sys/boot.
 *** [all] Error code 1

 Stop in /usr/src/sys.
 *** [sys.all__D] Error code 1

 Stop in /usr/src.
 *** [everything] Error code 1

 Stop in /usr/src.
 *** [buildworld] Error code 1

 Stop in /usr/src.

 Here is a patch to work around the problem:

 http://people.freebsd.org/~jkim/boot2.diff

 Please note this patch creates two separate boot codes, one for UFS1
 and one for UFS2.  To generate previous boot code (i.e., UFS1+UFS2)
 with GCC, clean objects, add the following line to
 your /etc/make.conf, rebuild, and install:

 BOOT2_UFS=UFS1_AND_UFS2

I think this should be committed.

If you're concerned about separating them, you can make this case
default for gcc.
There's glue in src/Makefile.inc1 that gives some hints about how this is done
.if ${MK_CLANG} != no  (${MK_CLANG_IS_CC} != no ||
${CC:T:Mclang} == clang)

eg: if building with clang, default to UFS2, else UFS1_AND_UFS2

But please commit something.  Personally I think we could use the
spare space in boot2 in any case.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
All of this is for nothing if we don't go to the stars - JMS/B5
If Java had true garbage collection, most programs would delete
themselves upon execution. -- Robert Sewell
___
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


fork speed vs /bin/sh

2003-11-27 Thread Peter Wemm
I *know* I'm going to regret posting this, but if people care about
the speed of their shell, then perhaps you want to look at this:

[EMAIL PROTECTED]:46am]/tmp-149 cc -O -o vforkathon.dynamic vforkathon.c
[EMAIL PROTECTED]:46am]/tmp-150 cc -O -static -o vforkathon.static vforkathon.c
[EMAIL PROTECTED]:47am]/tmp-151 cc -O -static -o forkathon.static forkathon.c
[EMAIL PROTECTED]:47am]/tmp-152 cc -O -o forkathon.dynamic forkathon.c
[EMAIL PROTECTED]:47am]/tmp-153 time ./forkathon.dynamic
0.120u 17.192s 0:17.81 97.1%5+169k 0+0io 0pf+0w
[EMAIL PROTECTED]:47am]/tmp-154 time ./forkathon.static
0.051u 5.939s 0:06.38 93.7% 15+177k 0+0io 0pf+0w
[EMAIL PROTECTED]:47am]/tmp-155 time ./vforkathon.dynamic
0.015u 2.006s 0:02.30 87.3% 5+176k 0+0io 0pf+0w
[EMAIL PROTECTED]:48am]/tmp-156 time ./vforkathon.static
0.022u 2.020s 0:02.34 87.1% 16+182k 0+0io 0pf+0w

What this shows is that vfork() is 3 times faster than fork() on static
binaries, and 9 times faster on dynamic binaries.  If people are
worried about a 40% slowdown, then perhaps they'd like to investigate
a speedup that works no matter whether its static or dynamic?  There is
a reason that popen(3) uses vfork().  /bin/sh should too, regardless of
whether its dynamic or static.  csh/tcsh already uses vfork() for the
same reason.

NetBSD have already taken advantage of this speedup and their /bin/sh uses
vfork().  Some enterprising individual who cares about /bin/sh speed should
check out that.  Start looking near #ifdef DO_SHAREDVFORK.

In case anybody was wondering:

[EMAIL PROTECTED]:48am]/tmp-157 cat forkathon.c
#include sys/types.h
#include sys/signal.h
#include stdio.h

int
main(int ac, char *av[])
{
int i;
pid_t pid;

for (i = 0; i  10; i++) {
pid = fork();
switch (pid) {
case 0:
_exit(0);
default:
waitpid(pid, NULL, 0);
}
}
}
[EMAIL PROTECTED]:53am]/tmp-158 diff forkathon.c vforkathon.c
12c12
   pid = fork();
---
   pid = vfork();


Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: 40% slowdown with dynamic /bin/sh

2003-11-24 Thread Peter Wemm
M. Warner Losh wrote:
 In message: [EMAIL PROTECTED]
 Andrew Gallatin [EMAIL PROTECTED] writes:
 : 
 : M. Warner Losh writes:
 :   In message: [EMAIL PROTECTED]
 :   Andrew Gallatin [EMAIL PROTECTED] writes:
 :   : I'll bet a larger percentage of our users build ports than need nss or
 :   : ldap.
 :   
 :   I'll bet a larger percentage of the people are ignoring this thread
 :   than reading it since it has been so devoid of concrete numbers.
 : 
 : Aside from $SUBJECT..
 
 I'm just saying that most of the developers I'm talking to on IRC say
 this tread is insane, has no content and they are blowing it off
 because of that.  A concrete, real benchmark will go a long way
 towards changing that.  Until then, you are as good as kill filed.

Ding!  Oh god, not another one! *plonk*

We need nsswitch type functionality in /bin/sh.  To the people who want to
make it static, lets see some static binary dlopen() support or a nsswitch
proxy system.

If half as much effort had been spent on implementing such a thing as there
has been hand wringing, then we'd have the best of both worlds by now.

I'm sorry to sound harsh, but its the reality of the situation.  Code
speaks louder than words.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-22 Thread Peter Wemm
Mark Linimon wrote:
  Is this where we start swapping stories about when I was a young 
  sysadmin, we didn't need no stinkin vi.  We used ed and liked it!.  :-)
 
 No, this is where we, out of respect for the mbox size of our fellow
 readers of -current, take this thread to -chat.
 
 Please.

You know, its never been done on our mailing lists that I can remember,
but this thread is certainly one that I'm seriously thinking of killing
at the mailing list gateway for the first time.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


HEADS UP: amd64 users! SMP code drop committed.

2003-11-17 Thread Peter Wemm
The subject should be pretty self explanatory.  However, this commit trips
some of the landmines in the nVidia nForce3 Pro-150 chipset and/or reference
bios.  

Boards known to be broken by the commit:
ASUS SK8N: two problems.. 
1) requires 'device atpic' and that you run in 'mixed mode', even though
this is expressly prohibited by the acpi spec.
2) the bios is broken and doesn't return the correct _CRS values for the
interrupts after switching into apic mode.  This causes level triggered pci
interrupts to set up on the edge-triggered PIC which leads to much unhappiness.

Gigabyte K8N-Pro:  two problems
1) same missing 8254 timer - apic connection
2) the bios appears to be outright *wrong* in apic mode.  For example, it
reports that the onboard ethernet is at irq 19, when in fact the interrupts
appear to arrive at irq 21 instead.

I have a couple of workarounds in mind.  I have not tried it yet, but the
quickest thing might be to comment out these lines in sys/conf/files.amd64:

amd64/acpica/madt.c optionalacpi
amd64/amd64/apic_vector.S   standard
amd64/amd64/io_apic.c   standard
amd64/amd64/local_apic.cstandard
amd64/amd64/mptable.c   optionalmptable
amd64/amd64/mptable_pci.c   optionalmptable pci

and add 'device atpic' to your kernel config.

You may also try 'set hint.acpi.0.disabled=1' in your loader.  Be sure to
leave out the mptable options as well, and include the atpic device.

I have an SK8N as my desktop at home and a K8N Pro as my home crashbox, so
rest assured that I'll sort something out real quick. :-)

sledge.freebsd.org is now running in SMP, as is the loaner 4-way Opteron
that I have for testing.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Peter Wemm
walt wrote:
 Terry Lambert wrote:
  Robert M.Zigweid wrote:
  
 I'll admit to being mostly a lurker here, but isn't the point of /sbin
 to be statically linked.  That's what the 's' stands for?
 
 Second question.  This seems to imply that /sbin and /bin both have to
 have the same behavior?  I have no problem with /bin being dynamically
 linked, but what if I want /bin to be dynamic and /sbin static?
  
  
  Since sbin on System V predated shared libraries on System V,
  I think maybe this is a reverse assignment of a meaning to the
  's'.
 
 I was taught by an older fart than Terry that the 's' stands for
 (S)ingle-user, which is reflected even today in the 'boot -s' switch.
 
 Since the single-user is usually the Sysadmin, the association with
 'system' is inevitable.  The association with 'static' is also
 inevitable when I think of Sysadmins-I-Have-Known  ;0)

It is 'system' binaries.  The distinction between bin and sbin (and /usr/
bin and /usr/sbin) is that the binaries in */sbin are only really supposed
to be useful for administrators or other priviliged users.

eg:  ps, netstat, ls, id, etc are in */bin because they dont require privs
and are generally useful.

meanwhile, fsck, dhclient, fdisk, cron, rmuser, usbdevs etc do require
priviliges or are not of general use.

Why seperate them?  Consider your shell and searching $PATH at execve time.
It was more efficient to keep the amount of work that each step in processing
$PATH to a minimum.  Doubling the size of the directories means double the work
searching directories looking for the foo binary.  Remember that we dont
have hashed directory lookups, its a linear search.  For all your shell
scripts etc, this search happens over and over and over again.  So, having
/bin:/usr/bin:/usr/local/bin as your $PATH as a normal user is a win.

Of course, the nami cache which does negative caching does skew things a bit,
but it still helps.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: HEADS UP: amd64 users! SMP code drop committed.

2003-11-17 Thread Peter Wemm
Peter Wemm wrote:
 You may also try 'set hint.acpi.0.disabled=1' in your loader.  Be sure to
 leave out the mptable options as well, and include the atpic device.

The good news is that this solves my problems on the gigabyte board.  I expect
it'll work for the nvidia as well.  But you will need to have the atpic
driver in the kernel.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Peter Wemm
Ken Smith wrote:
 On Mon, Nov 17, 2003 at 12:59:47PM -0800, Peter Wemm wrote:
 
  It is 'system' binaries.  The distinction between bin and sbin (and /usr/
  bin and /usr/sbin) is that the binaries in */sbin are only really supposed
  to be useful for administrators or other priviliged users.
 
 Yup, this distinction was in place long before shared libraries came
 along but not in its current form.  You can only consider yourself a
 true UNIX dinosaur if at some point you changed your path to replace
 /usr/etc /etc with /usr/sbin /sbin.  /etc was where they lived
 at first.

*Everbody* knows that ifconfig belongs in /etc/ifconfig :-)

On my SVR4 system (past life), /bin was a symlink to /usr/bin and /sbin
was a symlink to /usr/sbin.  /usr was on /.  Things were simpler.

I say we ditch this silly /usr thing and put it all in /bin + /lib and be
done with it. :-)

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: HEADSUP: Committing new interrupt code, tree will be broken

2003-11-03 Thread Peter Wemm
John Baldwin wrote:
 
 On 03-Nov-2003 John Baldwin wrote:
  I'm committing the new i386 interrupt and SMP code, so buckle your
  seat belts. :)  I'll be intentionally breaking the kernel build at
  the start and re-enable it with the last commit when I am done.
 
 I've finished committing everything but am waiting for some kernel
 compiles on virgin trees to finish to make sure I didn't miss anything.
 The -current waters should be safe again though.

JFYI:
ref5.freebsd.org updated ok (no MADT or mptable in bios)
builder.freebsd.org updated ok (no MADT or mptable in bios)
the quad xeon-550 at work updated fine.. multiple IO apics and all.  (I had
  to make a PAE fix for i386/acpica/madt.c though)

...
ACPI APIC Table: INTEL  SKA4
CPU: Pentium III/Pentium III Xeon/Celeron (549.44-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x673  Stepping = 3
  
Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE
real memory  = 6442450944 (6144 MB)
avail memory = 5828734976 (5558 MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): APIC ID:  3
 cpu1 (AP): APIC ID:  0
 cpu2 (AP): APIC ID:  1
 cpu3 (AP): APIC ID:  2
ioapic0 Version 17 irqs 0-15 on motherboard
ioapic1 Version 17 irqs 16-31 on motherboard
...

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: __fpclassifyd problem

2003-10-22 Thread Peter Wemm
Daniel Eischen wrote:
 On Mon, 20 Oct 2003, M. Warner Losh wrote:
 
  In message: [EMAIL PROTECTED]
  Scott Long [EMAIL PROTECTED] writes:
  : We need to resolve this before 5.2 in some fashion.  It looks like the
  : easiest thing to do is bump libm.  Is this advisable?
  
  The problem with bumping libm is that we also need, strictly speaking,
  to bump all libarires that depend on libm, and that can be very ugly.
  This moves the bump the major version from the trivial fix class to
  something that we have to think real hard about.  In general one
  cannot bump the major version of 'base' libaries like this w/o careful
  thought and planning.  While we've done that in the past with libc, I
  think we were wrong to do so in some classes of symbol tampering.
  
  Warner ___
  [EMAIL PROTECTED] mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
  send any mail to [EMAIL PROTECTED]
  
 
 If it's just __fpclassifyd(), can you just add a compatability
 hack to libm so it works with both libc 4.0 and 5.x?  You
 can make __fpclassifyd a weak definition to the hack in libm.
 I suppose you could also add __fpclassfyd() to libc 4.0.

We tried this at usenix, but it still didn't work.  Obviously there is more
going on.

Before anybody goes and bumps libraries etc, it would be useful to know if
running a statically linked jvm will work on -current.  If that does, then
the next thing to try is using a complete exclusive set of 4.x libraries
and ld-elf.so.1 somewhere and running in a chroot environment.  The next
step is to use the 5.x ld-elf.so.1, but $LD_LIBRARY_PATH to search for and
find the 4.x libraries in preference to the 5.x ones.  And so on.  If it
still works at this point,  then try switching the unbumped libraries one
at a time until it breaks.

Bumping the library versions is only useful IF it actually solves the
problem.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: panic: pmap_enter: attempted pmap_enter on 4MB page

2003-10-17 Thread Peter Wemm
Jilles Tjoelker wrote:
 Hello,
 
 Yesterday our 5-CURRENT box panicked with panic: pmap_enter: attempted
 pmap_enter on 4MB page.
[..]
 (kgdb) p va
 $1 = 689672192
 (kgdb) p pte
 $2 = (pt_entry_t *) 0xbfca46e4
 (kgdb) p origpte
 $3 = 3503345872
 (kgdb) p (void *)va
 $4 = (void *) 0x291b9000
 (kgdb) p (void *)origpte
 $5 = (void *) 0xd0d0d0d0
 (kgdb) # 

AHA!  origpte being 0xd0d0d0d0 means that something really came unstuck
because that is the fill pattern that userland malloc(3) uses.  The
4MB page thing is a red herring, it just happens that PG_PS (0x80) is
a set bit in the fill pattern.

Now to find the source. :-(  Are you getting this repeatably?  If somebody
is able to (relatively) easily provoke this, there are a few things I'd
like to try (shotgun diagnostics, but its better than nothing).

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


FYI, I've switched my primary desktop to AMD64.

2003-10-17 Thread Peter Wemm
 in fast mode - using normal mode
puc1: Dolphin Peripherals 4036 port 0xdfa0-0xdfa7,0xdfa8-0xdfaf,0xdf40-0xdf5f irq 5 
at device 7.0 on pci1
sio6: Dolphin Peripherals 4036 on puc1
sio6: type 16550A
sio6: unable to activate interrupt in fast mode - using normal mode
sio7: Dolphin Peripherals 4036 on puc1
sio7: type 16550A
sio7: unable to activate interrupt in fast mode - using normal mode
atapci1: Promise PDC20378 SATA150 controller port 
0xdc00-0xdc7f,0xdf60-0xdf6f,0xde80-0xdebf mem 
0xfc9a-0xfc9b,0xfc9fd000-0xfc9fdfff irq 11 at device 8.0 on pci1
atapci1: [MPSAFE]
ata2: at 0xfc9fd000 on atapci1
ata2: [MPSAFE]
ata3: at 0xfc9fd000 on atapci1
ata3: [MPSAFE]
ata4: at 0xfc9fd000 on atapci1
ata4: [MPSAFE]
fwohci0: Texas Instruments TSB43AB22/A mem 
0xfc9f8000-0xfc9fbfff,0xfc9fc800-0xfc9fcfff irq 11 at device 9.0 on pci1
fwohci0: [MPSAFE]
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channel is 4.
fwohci0: EUI64 00:e0:18:00:00:2e:05:8c
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: IEEE1394(FireWire) bus on fwohci0
if_fwe0: Ethernet over FireWire on firewire0
if_fwe0: Fake Ethernet address: 02:e0:18:2e:05:8c
sbp0: SBP-2/SCSI over FireWire on firewire0
fwohci0: Initiate bus reset
fwohci0: BUS reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
pcib2: ACPI PCI-PCI bridge at device 11.0 on pci0
pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P2 - AE_NOT_FOUND
pci2: ACPI PCI bus on pcib2
pci2: display, VGA at device 0.0 (no driver attached)
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0x3f5 
irq 6 drq 2 on acpi0
ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0
ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
ppbus0: Parallel port bus on ppc0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model IntelliMouse Explorer, device ID 4
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
acpi_button0: Power Button on acpi0
  uteval-0226: *** Error: Return object type is incorrect [\\_SB_.LATA._CRS] (Node 
0xffa24730), AE_TYPE
can't fetch resources for \\_SB_.LATA - AE_TYPE
acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0
npx0: math processor on motherboard
npx0: INT 16 interface
orm0: Option ROMs at iomem 0xd8000-0xd87ff,0xcf800-0xd07ff on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounter TSC frequency 2200013004 Hz quality 800
Timecounters tick every 10.000 msec
acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0%
GEOM: create disk ad0 dp=0xffec62c0
ad0: 156334MB Maxtor 6Y160M0 [317632/16/63] at ata2-master UDMA133
GEOM: create disk ad1 dp=0xffec5ac0
ad1: 156334MB Maxtor 6Y160M0 [317632/16/63] at ata3-master UDMA133
GEOM: create disk ar0 dp=0xff003cb42e70
ar0: 156334MB ATA RAID1 array [19929/255/63] status: READY subdisks:
 disk0 READY on ad0 at ata2-master
 disk1 READY on ad1 at ata3-master
Waiting 2 seconds for SCSI devices to settle
GEOM: create disk cd0 dp=0xff003ca69698
cd0 at ahc0 bus 0 target 4 lun 0
cd0: TOSHIBA CD-ROM XM-6401TA 1001 Removable CD-ROM SCSI-2 device 
cd0: 10.000MB/s transfers (10.000MHz, offset 15)
cd0: Attempt to query device size failed: NOT READY, Medium not present
Mounting root from ufs:/dev/ar0s1a

Those disks are serial-ata maxtor drives on the serial-ata ports of the
controller - the ATA code doesn't know how to recognize that and is calling
them UDMA133.

I've got all those sio ports in there because I no longer have an ISA slot
for my Specialix XIO multiport controller to go in. :-(  (Say, does anybody
have a PCI SI/XIO host adapter laying around?)

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: XFree86-4-clients port broken.

2003-10-13 Thread Peter Wemm
David Gilbert wrote:
 I don't really have a clue where to look for this fix as there seems
 to be a serious amount of magic going into the divided XFree86-4 port
 builds, but my XFree86-4-clients port fails saying:
 
 make: don't know how to make /usr/ports/x11/XFree86-4-clients/work/xc/exports
/lib/libfntstubs.a. Stop

I ran into this on my amd64 box too.  Is yours an i386?

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: XFree86-4-clients port broken.

2003-10-13 Thread Peter Wemm
Eric Anholt wrote:
 On Mon, 2003-10-13 at 15:51, Peter Wemm wrote:
  David Gilbert wrote:
   I don't really have a clue where to look for this fix as there seems
   to be a serious amount of magic going into the divided XFree86-4 port
   builds, but my XFree86-4-clients port fails saying:
   
   make: don't know how to make /usr/ports/x11/XFree86-4-clients/work/xc/exp
orts
  /lib/libfntstubs.a. Stop
  
  I ran into this on my amd64 box too.  Is yours an i386?
 
 This is a problem on ref5, too.  I am testing a fix right now.  The
 confusing part is I can't find any change I (or anyone else) has made
 that would have caused this.

Does the port have any exposure to make(1) at all?  Its been futzed with
fairly recently.  I know it's supposed to use gmake, but perhaps there are
still some make references?

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: HEADS UP: APM users on -current!

2003-10-04 Thread Peter Wemm
Kevin Oberman wrote:
  Date: Wed, 01 Oct 2003 22:01:07 -0700
  From: Peter Wemm [EMAIL PROTECTED]
  Sender: [EMAIL PROTECTED]
  
  I've made a commit that has been reported as breaking APM for some people.
  I'll be following this up, so could folks please report here if things
  break?  (and feel free to say so if you find the problem :-).  It would
  also be interesting to know that things are ok for a few people too.
  
  If you're stuck (hang or reset on boot), take out apm for the time being.
  Yes, I know that isn't a solution, but please bear with me.
 
 No hangs or resets on my ThinkPad T30. It just crashes. :-(

I found it.. please try with revision 1.177 of locore.s..

peter   2003/10/03 23:30:56 PDT

  FreeBSD src repository

  Modified files:
sys/i386/i386locore.s 
  Log:
  Emulate bugs in the old PSE code so that apm works again.
  
  I do not yet understand why, but apm *depended* on the fact that the old
  PSE code caused the first 1MB of ram to be mapped read/write because it
  was in the same 4MB page as the kernel text+data+bss blob.
  
  If anybody ever tried DISABLE_PSE before, apm would not work.
  
  If your cpu did not have PSE, apm would not work there either (eg: 486).
  
  This bug has been around for a Very Long Time.
  
  The Pentium-4-fix commits did not emulate this unintended side effect of
  the PSE post-early-boot fixup, and thus apm blew up.  I've added a hack to
  emulate the bug until either apm is fixed or we set fire to our bridges.
  
  This is bad though because it gives kernel mode code the opportunity
  to accidently write to the first few megs of the general page pool
  which is remapped at KERNBASE.  It needs to be fixed properly.
  
  Revision  ChangesPath
  1.177 +5 -0  src/sys/i386/i386/locore.s

@@ -787,7 +788,12 @@
 
 /* Map read-only from zero to the beginning of the kernel text section */
xorl%eax, %eax
+#ifdef BURN_BRIDGES
xorl%edx,%edx
+#else
+/* XXX emulate bugs in the old PSE code so that apm works */
+   movl$PG_RW,%edx
+#endif
movl$R(btext),%ecx
addl$PAGE_MASK,%ecx
shrl$PAGE_SHIFT,%ecx

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: HEADS UP: APM users on -current!

2003-10-02 Thread Peter Wemm
Kevin Oberman wrote:
  Date: Wed, 01 Oct 2003 22:01:07 -0700
  From: Peter Wemm [EMAIL PROTECTED]
  Sender: [EMAIL PROTECTED]
  
  I've made a commit that has been reported as breaking APM for some people.
  I'll be following this up, so could folks please report here if things
  break?  (and feel free to say so if you find the problem :-).  It would
  also be interesting to know that things are ok for a few people too.
  
  If you're stuck (hang or reset on boot), take out apm for the time being.
  Yes, I know that isn't a solution, but please bear with me.
 
 No hangs or resets on my ThinkPad T30. It just crashes. :-(

OK, I have it myself now.  I'm working on it..

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


HEADS UP: APM users on -current!

2003-10-01 Thread Peter Wemm
I've made a commit that has been reported as breaking APM for some people.
I'll be following this up, so could folks please report here if things
break?  (and feel free to say so if you find the problem :-).  It would
also be interesting to know that things are ok for a few people too.

If you're stuck (hang or reset on boot), take out apm for the time being.
Yes, I know that isn't a solution, but please bear with me.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

--- Forwarded Message

Date:Wed, 01 Oct 2003 16:46:08 -0700
From:Peter Wemm [EMAIL PROTECTED]
To:  [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED]
Subject: cvs commit: src/sys/conf ldscript.i386 src/sys/i386/i386 bios.c genass
  ym.c locore.s machdep.c mp_machdep.c mpboot.s pmap.c src/sys/i386/inc
  lude pmap.h vmparam.h

peter   2003/10/01 16:46:08 PDT

  FreeBSD src repository

  Modified files:
sys/conf ldscript.i386 
sys/i386/i386bios.c genassym.c locore.s machdep.c 
 mp_machdep.c mpboot.s pmap.c 
sys/i386/include pmap.h vmparam.h 
  Log:
  Commit Bosko's patch to clean up the PSE/PG_G initialization to and
  avoid problems with some Pentium 4 cpus and some older PPro/Pentium2
  cpus.  There are several problems, some documented in Intel errata.
  This patch:
  1) moves the kernel to the second page in the PSE case.  There is an
  errata that says that you Must Not point a 4MB page at physical
  address zero on older cpus.  We avoided bugs here due to sheer luck.
  2) sets up PSE page tables right from the start in locore, rather than
  trying to switch from 4K to 4M (or 2M) pages part way through the boot
  sequence at the same time that we're messing with PG_G.
  
  For some reason, the pmap work over the last 18 months seems to tickle
  the problems, and the PAE infrastructure changes disturb the cpu
  bugs even more.
  
  A couple of people have reported a problem with APM bios calls during
  boot.  I'll work with people to get this resolved.
  
  Obtained from:  bmilekic
  
  Revision  ChangesPath
  1.8   +1 -1  src/sys/conf/ldscript.i386
  1.63  +12 -12src/sys/i386/i386/bios.c
  1.144 +3 -0  src/sys/i386/i386/genassym.c
  1.175 +62 -9 src/sys/i386/i386/locore.s
  1.573 +1 -1  src/sys/i386/i386/machdep.c
  1.217 +2 -8  src/sys/i386/i386/mp_machdep.c
  1.21  +16 -0 src/sys/i386/i386/mpboot.s
  1.442 +35 -86src/sys/i386/i386/pmap.c
  1.101 +3 -1  src/sys/i386/include/pmap.h
  1.37  +7 -0  src/sys/i386/include/vmparam.h


--- End of Forwarded Message


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


Re: Fixing -pthreads (Re: ports and -current)

2003-09-24 Thread Peter Wemm
Robert Watson wrote:

 Based on the results seen thus far, my preference would really be for:
 
 (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle.

Regarding the switch, the gcc folks have been adding -pthread as the
'standard' way to enable pthreads across the board for all platforms.
On some systems it also implies -D_REENTRANT and other flags as well.

-pthread cannot go away.  We'd just be hurting ourselves for no good reason,
especially when the rest of the world is syncing up with us.

Samples from http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog:


* config/linux.h (LIB_SPEC): If -pthread, add -lpthread even if
-shared.
* config/alpha/linux-elf.h (LIB_SPEC): Likewise.

* config/ia64/hpux.h: Define CPP_SPEC to set appropriate
#defines for -pthread.  Add -lpthread to LIB_SPEC when
-pthread.  In both cases take -mt as a synonym for -pthread
for acc compatibility.
... 
* config/netbsd.h: Update copyright years.
(NETBSD_CPP_SPEC): Define _REENTRANT and _PTHREADS if
-pthread is specified on the command line.
...


Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: ata-lowlevel.c ate my slave disc

2003-09-24 Thread Peter Wemm

 Hi, I want to report a regression in ATAng. It's exactly same problem
 that Richard Nyberg reported on current@ 9 days ago.
 
 After updating to today -current, my system no longer see primary slave
 hard drive. It's one year old Seagate 80 GB hard drive.

FWIW, I have the same problem on my amd64 boxes at home.  It will not see
the drive if its in slave mode.  It too happens to be a seagate.

 If I revert a 1.10 revision of ata-lowlevel.c (#ifdef 0 a section of
 probing code), the disc is back and works absolutely fine.

I'll try the same later on.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: 5.2-RELEASE TODO

2003-09-03 Thread Peter Wemm
Scott Long wrote:
 David O'Brien wrote:
  On Mon, Sep 01, 2003 at 10:00:17AM -0400, Robert Watson wrote:
  
  |-+---+-+|
  | |   | | Productionable |
  | |   | | support for the|
  | |   | | AMD64 platform.|
  | |   | | Currently, AMD64   |
  | |   | | runs fully in  |
  | |   | | 32-bit emulation   |
  | Tier-1 Support for  | In| Peter Wemm, | mode, and boots to |
  | AMD64 Hammer| progress  | David O'Brien   | single-user in |
  | |   | | 64-bit mode. We|
  | |   | | expect full|
  | |   | | production support |
  | |   | | for the AMD64  |
  | |   | | architecture in|
  | |   | | 5.2-RELEASE.   |
  |-+---+-+|
  
  
  
  PLEASE, PLEASE update this.  Not implying that FreeBSD/amd64 doesn't make
  it multiuser and can build its own world would be sufficient.
  
 
 Sorry, I missed this when I did my scrub yesterday.  I'll fix it now.
 Btw, does X work on it?  Can I compile/install it without hassle?

Yes.  It installs Just Fine.  You wont even notice the difference relative
to an i386 machine.  X builds/runs.  I dont think the Xserver port packages
yet though, but it does build.  I think David is working on that.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: cvsup failing with ASSERT failed

2003-08-27 Thread Peter Wemm
[EMAIL PROTECTED] wrote:
 A couple of times, now, on both FBSD-5.1-CURRENT and FBSD-4.8-STABLE whilst 
 running with 2MB of RAM, cvsup has croaked with the following error:
 
 ***
 *** runtime error:
 ***ASSERT failed
 ***file /usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/runtime/
 common/RTHeapMap.m3, line 35
 ***
use option @M3stackdump to get a stack trace
 Abort trap (core dumped)

Oh, that *is* interesting.  I get this 100% of the time when trying to
run the i386 binary on my amd64 boxes.  Hmm.  Maybe I dont have an emulation
bug then?

[EMAIL PROTECTED]:46am]~-99 ./cvsup -gL2 cvs-supfile 
Parsing supfile cvs-supfile
Connecting to malaise

***
*** runtime error:
***ASSERT failed
***file 
/home/ports/lang/ezm3/work/ezm3-1.1/libs/m3core/src/runtime/common/RTHeapMap.m3, 
line 35
***

  use option @M3stackdump to get a stack trace
Abort (core dumped)

[EMAIL PROTECTED]:46am]~-100 file ./cvsup
./cvsup: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 
5.0.1, statically linked, stripped

Interestingly, file(1) wasn't taught about the new encoding scheme for
FreeBSD_version, but thats off on a tangent.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: [-CURRENT tinderbox] failure on i386/i386

2003-07-21 Thread Peter Wemm
Mark Murray wrote:
 Peter Wemm writes:
  Tinderbox wrote:
  
   gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls
/c
  at
  gets.3  catgets.3.gz
   Segmentation fault (core dumped)
   *** Error code 139
  
  These false alarms are wearing a bit thin.  Is there a problem with the
  tinderbox build machine perhaps?
 
 My home box is doing it too. as(1) blowing up randomly. No usable core
 dumps. :-(.

Hmm. I thought it was gzip that was dying. Looks like its make instead, and
is rather consistent.

 grep dump /var/log/messages
Jul 20 14:14:52 cueball kernel: pid 34706 (make), uid 722: exited on signal 11 (core 
dumped)
Jul 20 14:56:35 cueball kernel: pid 16740 (make), uid 722: exited on signal 11 (core 
dumped)
Jul 20 18:32:07 cueball kernel: pid 6784 (make), uid 722: exited on signal 11 (core 
dumped)
Jul 21 00:43:54 cueball kernel: pid 85754 (make), uid 722: exited on signal 11 (core 
dumped)
Jul 21 15:01:12 cueball kernel: pid 51790 (make), uid 722: exited on signal 10 (core 
dumped)

So, who has been messing with make(1) lately?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: [-CURRENT tinderbox] failure on i386/i386

2003-07-21 Thread Peter Wemm
Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= wrote:
 Peter Wemm [EMAIL PROTECTED] writes:
  Hmm. I thought it was gzip that was dying. Looks like its make instead, a=
 nd
  is rather consistent.
 
 told you so
 
  So, who has been messing with make(1) lately?
 
 I believe that the problem is in the kernel, not in make(1); it just
 happens to be triggered by make(1) because it is a big (if not the
 biggest) vfork(2) consumer.

For a minute I had a horrible thought that it might have been a consequence
of the lazy switch stuff.  But the kernel on cueball predates the turn-on
and doesn't have the options enabled.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: [-CURRENT tinderbox] failure on i386/i386

2003-07-20 Thread Peter Wemm
Tinderbox wrote:

 gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/cat
gets.3  catgets.3.gz
 Segmentation fault (core dumped)
 *** Error code 139

These false alarms are wearing a bit thin.  Is there a problem with the
tinderbox build machine perhaps?

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Patches for XFree86 for FreeBSD/amd64

2003-07-15 Thread Peter Wemm
I have the X server up and running on my machine at work, I'm currently
using it in a desktop configuration (although not my primary desktop yet
because I still need to have a place to finish off some kernel
optimizations).

The first patch is against ports/x11/XFree86-4-libraries:
http://people.freebsd.org/~peter/amd64-libraries.diff

The second is against ports/x11-servers/XFree86-4-server:
http://people.freebsd.org/~peter/amd64-server.diff

You need to patch both, because the imake config files come from the
libraries port and is used in the server build.  I've submitted these
to the port maintainer, so hopefully something might get committed soon.

Most of the rest of the diffs are to either add amd64 support to the
FreeBSD configuration, or to fix XFree86 bugs where they assume that all
amd64 systems are implicitly Linux based.  These patches are very minimal
and really need somebody with more knowledge of the XFree86 internals to
go over them.  But it should be enough to get up and running to play around
with it.  I'm using a MGA G450 at work FWIW.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: [-CURRENT tinderbox] failure on amd64/amd64

2003-06-29 Thread Peter Wemm
Tinderbox wrote:
 TB --- 2003-06-29 17:28:12 - starting CURRENT tinderbox run for amd64/amd64
[..]
  stage 3: cross tools
  stage 4: populating /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol
/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include
  stage 4: building libraries
 [...]
 cc -O -pipe  -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libs
mutil/../../contrib/sendmail/src -I/vol/vol0/users/des/tinderbox/CURRENT/am
d64/amd64/src/lib/libsmutil/../../contrib/sendmail/include -I. -DNEWDB -DNI
S -DMAP_REGEX -DNOT_SENDMAIL   -c /vol/vol0/users/des/tinderbox/CURRENT/amd
64/amd64/src/contrib/sendmail/libsmutil/snprintf.c -o snprintf.o
 cc -O -pipe  -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libs
mutil/../../contrib/sendmail/src -I/vol/vol0/users/des/tinderbox/CURRENT/am
d64/amd64/src/lib/libsmutil/../../contrib/sendmail/include -I. -DNEWDB -DNI
S -DMAP_REGEX -DNOT_SENDMAIL   -c /vol/vol0/users/des/tinderbox/CURRENT/amd
64/amd64/src/contrib/sendmail/libsmutil/cf.c -o cf.o
 building static smutil library
 ranlib libsmutil.a
 === lib/libstand
 cc -O -pipe  -ffreestanding -Wformat -I/vol/vol0/users/des/tinderbox/CURRENT/
amd64/amd64/src/lib/libstand -m32 -I. -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE
_MEMCPY -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libstan
d/../libz  -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/lib
stand/__main.c -o __main.o
 ld: unrecognised emulation mode: elf_i386_fbsd
 Supported emulations: elf_x86_64_fbsd
 *** Error code 1

In case anybody else is running into this, I am waiting on a straight
answer from David O'Brien about whether he objects to this patch or not:

Index: gnu/usr.bin/binutils/ld/Makefile.amd64
===
--- gnu/usr.bin/binutils/ld/Makefile.amd64  2003/06/26 17:55:59 #1
+++ gnu/usr.bin/binutils/ld/Makefile.amd64  2003/06/26 17:55:59
@@ -18,3 +18,17 @@
sh ${.CURDIR}/genscripts.sh ${SRCDIR}/ld ${_x86_64_path} \
${HOST} ${TARGET_TUPLE} ${TARGET_TUPLE} \
${NATIVE_EMULATION}  ${NATIVE_EMULATION} ${TARGET_TUPLE}
+
+X86_EMULATION= elf_i386_fbsd
+_i386_path=\${TOOLS_PREFIX}/usr/lib/i386\
+EMS+=  ${X86_EMULATION}
+LDSCRIPTS+=${X86_EMULATION}.x ${X86_EMULATION}.xbn ${X86_EMULATION}.xn 
${X86_EMULATION}.xr \
+   ${X86_EMULATION}.xs ${X86_EMULATION}.xu ${X86_EMULATION}.xc 
${X86_EMULATION}.xsc
+SRCS+= e${X86_EMULATION}.c
+CLEANFILES+=   e${X86_EMULATION}.c
+
+e${X86_EMULATION}.c: emulparams/${X86_EMULATION}.sh emultempl/elf32.em 
scripttempl/elf.sc \
+genscripts.sh stringify.sed
+   sh ${.CURDIR}/genscripts.sh ${SRCDIR}/ld ${_i386_path} \
+   ${HOST} ${TARGET_TUPLE} ${TARGET_TUPLE} \
+   ${X86_EMULATION}  ${X86_EMULATION} ${TARGET_TUPLE}
Index: gnu/usr.bin/binutils/libbfd/Makefile.amd64
===
--- gnu/usr.bin/binutils/libbfd/Makefile.amd64  2003/06/26 17:55:59 #1
+++ gnu/usr.bin/binutils/libbfd/Makefile.amd64  2003/06/26 17:55:59
@@ -1,21 +1,22 @@
 # $FreeBSD: src/gnu/usr.bin/binutils/libbfd/Makefile.amd64,v 1.1 2003/04/26 03:28:21 
obrien Exp $
 
-.include ${.CURDIR}/Makefile.i386
-
-#  Get the i386 DEFAULT_VECTOR and VECS.
-I386_VECS:=${DEFAULT_VECTOR} ${VECS}
-
 DEFAULT_VECTOR=bfd_elf64_x86_64_vec
 
-VECS=  bfd_elf64_x86_64_vec ${I386_VECS}
+VECS=  bfd_elf64_x86_64_vec bfd_elf32_i386_freebsd_vec
 
 SRCS+= elf64-amd64-fbsd.c elf64-target.h elf64-gen.c elf64.c
+SRCS+= cpu-i386.c elf32-i386-fbsd.c elf32-target.h elf32.c elflink.c
 
 CLEANFILES+=   elf64-target.h
 
 elf64-target.h:elfxx-target.h
sed -e s/NN/64/g ${.ALLSRC}  ${.TARGET}
 
+CLEANFILES+=   elf32-target.h
+
+elf32-target.h:elfxx-target.h
+   sed -e s/NN/32/g ${.ALLSRC}  ${.TARGET}
+
 CLEANFILES+=   elf64-amd64-fbsd.c
 
 elf64-amd64-fbsd.c: ${.CURDIR}/elf-fbsd-brand.c ${SRCDIR}/bfd/elf64-x86-64.c

There is a copy here:  http://people.freebsd.org/~peter/binutils.diff

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: Panic on fxp

2003-04-03 Thread Peter Wemm
Daniel C. Sobral wrote:
 It seems recent current doesn't like my fxp. A current from some 10 
 hours ago keeps complaining about device timeout and dma timeout. I 
 don't *know* it's fxp fault (for one thing, because it says unknown), 
 but...
 
 So, two hours ago, I cvsupped and tried a new world. This one panics on 
 boot, while doing something with fxp (attaching, I think), and doesn't 
 even get me a core dump.
 
 I'll try a new world tomorrow. People tweaking fxp, do please try to get 
 it fixed?

Some details would be useful.  Pencil and paper perhaps?  Serial cable
to another machine and boot -h?

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: libthr and 1:1 threading.

2003-04-02 Thread Peter Wemm
Terry Lambert wrote:
 Jun Su wrote:
  
 [ ... 1:1 kernel threads implementation ... ]
  
  A benchmark would be interested.
 
 This request doesn't make sense.
 
 The primary performance reasoning behind a 1:1 kernel threading
 implementation, relative to the user space single kernel entry
 scheduler in the libc_r implementation is SMP scalability for
 threaded applications.

No.  It gives the ability for a thread to block on a syscall without
stalling the entire system.  Just try using mysqld on a system using libc_r
and heavy disk IO.  You can't select() on a read() from disk.  Thats the
ultimate reason to do it.  The SMP parallelism is a bonus.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: libthr and 1:1 threading.

2003-04-02 Thread Peter Wemm
John Baldwin wrote:
 
 On 02-Apr-2003 Terry Lambert wrote:
  The only way I see for disk I/O to be involved in Mozilla is in
  local cache?  You can turn that off.
 
 Umm, the idea here is to actually make threaded programs
 _useful_.  Not to require that you trim their functionality
 down before we handle them in a sane way.  Less FUD more signal
 please.

Just a reminder, we can selectively moderate folks with the new mailing
list software..

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: libthr and 1:1 threading.

2003-04-02 Thread Peter Wemm
Terry Lambert wrote:

 KSE mailing list, starting Monday or so:
 ] We still haven't heard from jeff with regard to the process
 ] signal mask removal.

We can add new mailing lists really easily now - it takes about 20-30 seconds.
Would it be worth adding a freebsd-threads and/or freebsd-kse type list
where it is a bit higher profile?

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: libthr and 1:1 threading.

2003-04-02 Thread Peter Wemm
Terry Lambert wrote:
 Peter Wemm wrote:
  No.  It gives the ability for a thread to block on a syscall without
  stalling the entire system.  Just try using mysqld on a system using libc_r
  and heavy disk IO.  You can't select() on a read() from disk.  Thats the
  ultimate reason to do it.  The SMP parallelism is a bonus.
 
 Bug in FreeBSD's NBIO implementation.  A read() that would result
 in page-in needs to queue the request, but return EAGAIN to user
 space to indicate the request cannot be satisfied.  Making select()
 come true for disk I/O after the fault is satisfied is a seperate
 issue.  Probably need to pass the fd all the way down.

Umm Terry.. we have zero infrastructure to support this.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: libthr and 1:1 threading.

2003-04-02 Thread Peter Wemm
Matthew Dillon wrote:

 A better solution would be to give AIO the capability to
 operate synchronously if the operation would occur in a 
 non-blocking fashion (inclusive of blockages on page faults),
 and asynchronously otherwise.

Without wanting to get too far off into the weeds, squid does something
interesting.  They need to be able to nonblock for everything including
open(), read(), unlink(), readdir() etc.  So what they do is implement a
fairly significant superset of the traditional AIO stuff using pthreads. It
seems to work pretty well for them, even with linuxthreads style threads.
Granted, squid's needs are not exactly typical.  But I did want to point
out that a good part of the delays come not only from data IO but operations
like opening a file (pathname traversal), creating or removing a file,
reading a directory etc.  This is a particular problem when the disk
is really busy.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: failure notice

2003-04-02 Thread Peter Wemm
[EMAIL PROTECTED] wrote:
 Hi. This is the qmail-send program at norton.palomine.net.
 I'm afraid I wasn't able to deliver your message to the following addresses.
 This is a permanent error; I've given up. Sorry it didn't work out.

GRRR. a spammer is sending out a batch of spam right now and using
forged @freebsd.org addresses in the From: line.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: libthr and 1:1 threading.

2003-04-02 Thread Peter Wemm
Julian Elischer wrote:
 Yes I think so..
 I think 'threads is a better name thatn 'kse' though kse
 is good in that it's real quick to type :-)

OK, done.  It seems to me we've needed one for a while now.

Subscribe by either:
http://lists.freebsd.org/mailman/listinfo/freebsd-threads
or
echo subscribe | mail [EMAIL PROTECTED]
or
echo anything at all | mail [EMAIL PROTECTED]

 On Wed, 2 Apr 2003, Peter Wemm wrote:
 
  Terry Lambert wrote:
  
   KSE mailing list, starting Monday or so:
   ] We still haven't heard from jeff with regard to the process
   ] signal mask removal.
  
  We can add new mailing lists really easily now - it takes about 20-30 secon
ds.
  Would it be worth adding a freebsd-threads and/or freebsd-kse type list
  where it is a bit higher profile?
  
  Cheers,
  -Peter
  --
  Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
  All of this is for nothing if we don't go to the stars - JMS/B5
  
  ___
  [EMAIL PROTECTED] mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to [EMAIL PROTECTED]
  
 

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


ATA broken on alpha?

2003-03-30 Thread Peter Wemm
beast.freebsd.org is panicing at bootup with this:

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #81: Sun Mar 30 07:48:29 PST 2003
[EMAIL PROTECTED]:/usr/src/sys/alpha/compile/BEAST
Preloaded elf kernel /boot/kernel/kernel at 0xfc714000.
ST6600
AlphaPC 264DP 833 MHz, 833MHz
8192 byte page size, 2 processors.
CPU: EV6 (21264) major=8 minor=0 extensions=0x1307BWX,FIX,CIX,MVI,PRECISE
OSF PAL rev: 0x200370002013e
real memory  = 2144706560 (2045 MB)
avail memory = 2081095680 (1984 MB)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Allocating major#253 to net
Allocating major#252 to g_ctl
Allocating major#251 to pci
tsunami0: 21271 Core Logic chipset
pcib0: 21271 PCI host bus adapter on tsunami0
pci0: PCI bus on pcib0
isab0: PCI-ISA bridge at device 5.0 on pci0
isa0: ISA bus on isab0
atapci0: Cypress 82C693 ATA controller port 0x1300-0x130f,0x3f4-0x3f7,0x1f0-0x1f7 
irq 238 at device 5.1 on pci0

fatal kernel trap:

trap entry = 0x2 (memory management fault)
cpuid  = 0
faulting va= 0x0
type   = access violation
cause  = load instructon
pc = 0xfc37b0fc
ra = 0xfc37b0d0
sp = 0xfc71ba50
usp= 0x0
curthread  = 0xfc63d3f8
pid = 0, comm = swapper

Stopped at  ata_pcisub_probe+0x11c: ldl t0,0(t0) 0x0  t0=0x0
db trace
ata_pcisub_probe() at ata_pcisub_probe+0x11c
device_probe_child() at device_probe_child+0x114
device_probe_and_attach() at device_probe_and_attach+0x58
bus_generic_attach() at bus_generic_attach+0x28
ata_pci_attach() at ata_pci_attach+0x600
device_probe_and_attach() at device_probe_and_attach+0xc4
bus_generic_attach() at bus_generic_attach+0x28
pci_attach() at pci_attach+0xe0
device_probe_and_attach() at device_probe_and_attach+0xc4
bus_generic_attach() at bus_generic_attach+0x28
device_probe_and_attach() at device_probe_and_attach+0xc4
bus_generic_attach() at bus_generic_attach+0x28
tsunami_attach() at tsunami_attach+0x98
device_probe_and_attach() at device_probe_and_attach+0xc4
root_bus_configure() at root_bus_configure+0x38
configure() at configure+0x40
mi_startup() at mi_startup+0x144
locorestart() at locorestart+0x64
--- root of call graph ---

Do you need more details or is that enough of a clue?

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: sparc64 tinderbox failure

2003-03-29 Thread Peter Wemm
Mike Barcroft wrote:

  stage 4: building everything..
 --
 === share/man/man9
 make: don't know how to make bus_Activate_resource.9. Stop
 *** Error code 2

This looks like a single bit memory error to me.  Turn off bit 5 and a
lowercase a turns into an uppercase A.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: Returned mail--window.open(

2003-03-26 Thread Peter Wemm
postmaster wrote:
 
The following mail can't be sent to [EMAIL PROTECTED]:
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: window.open(
The file is the original mail

OK, thats impressive.. :-]

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

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


Re: February 6, 2003 to March 8, 2003 -CURRENT - Bad System Calls?

2003-03-22 Thread Peter Wemm
Vincent Poy wrote:
   I've recently went from a February 6, 2003 -CURRENT to a March 8,
 2003 -CURRENT and for whatever reason, the stuff that used to work
 installed from ports all broke with Bad System Call (core dump), has
 anyone else experienced this problem since what happened to all the
 backwards compatibility of older binaries?

Old ports?  You probably need to add COMPAT_FREEBSD4 to your kernel config.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: HTT , APIC_IO

2003-03-18 Thread Peter Wemm
Joris Vandalon wrote:
 Hi there,
 
 I'm having a problem compling a current kernel with HTT
 it seemd the option APIC_IO gives me some trouwbels (see output below)
 is there anyone who had similar problems or even how got HTT working on curre
nt?

You are using APIC_IO, HTT *and* SMP, aren't you?  HTT is an addition to the
SMP option.  You must use APIC_IO and SMP together, with an optional addition
of HTT.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: Anyone working on fsck?

2003-03-17 Thread Peter Wemm
Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Greg 'groggy' Lehey
 
 writes:
 
  Optimizing fsck is a valid project, I just wish it would be somebody
  who would also finish the last 30% who would do it.
 
 Poul-Henning, how can you justify the second half of that sentence?  I
 take exception to the implications.  In case anybody is in any doubt,
 I've heard you say this sort of thing about julian before.  Please
 don't do it again.
 
 I'll stop as soon as KSE is finished, fair ?

Poul-Henning.. this is a bit of a cheap shot.  Your point may be valid, but
this isn't the way to express it as it just turns into a 'phk is being
mean again' flamewar and the message gets lost in the noise.

Anyway, the deadline for KSE to be demonstrated as robust in order to avoid
getting disabled for 5.x is getting closer.  I'm glad it was going to be
finished inside 2 months, starting about 18 months ago. (See the 5.x release
milestones for the actual deadline, June 30 if I recall correctly.)

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: Create linker.hints at boot

2003-03-14 Thread Peter Wemm
Crist J. Clark wrote:
 
 --C7zPtVaVf+AK4Oqc
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 Perhaps it would be a good idea to build a linker.hints file with
 kldxref(8) at boot time. At least, I can't think of any really good
 reasons why _not_ to do it.

Yes, we need to do this, but your patch needs a little more work.

Specifically.. There is a linker.hints file in each directory in the module
path, not just /boot/kernel.  You need to look at the kern.module_path
sysctl to find the search path.

[EMAIL PROTECTED]:26pm]~-101 sysctl -n kern.module_path
/boot/kernel;/boot/kernel;/boot/modules;/modules

This also needs to be robust in the case where /boot might be another file
system or readonly or NFSROOT or not even mounted, or something.  

But this has needed attention for quite a while.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: param.h

2003-03-14 Thread Peter Wemm
Rhett Monteg Hollander wrote:
 Hello gentlemen,
 
 the question is, why param.h (v1.65) that comes with 5.0
 doesn't define OBJFORMAT_NAMES and OBJFORMAT_DEFAULT, but
 v1.54 does? These are required by GCC 2.95.4 at compile-time
 (pulled from -STABLE). It may look like someone had decided
 that GCC2 is of no use in -CURRENT...

Are you trying to compile the -stable version of gcc?  We make significant
modifications to integrate it within our environment.  I would not at all
be suprised if the -stable version of gcc doesn't build on -current.
The OBJFORMAT stuff only exists on -stable.  If you're going to try and
use the -stable compiler on -current, you'll have to stub this out.

Or have you found a problem in the FSF releases?

You are aware that there are gcc ports set up to configure the FSF trees
specifically for use on FreeBSD, right?  And that includes gcc-2.95.4.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: [PATCH 5.x] netns

2003-03-05 Thread Peter Wemm
=?iso-8859-1?q?Pedro=20F.=20Giffuni?= wrote:
 Guys;
 
 I have to agree with Terry that the fixes for netns
 should be committed, and furthermore they should be
 MFC (using his first patch perhaps). It's a nightmare
 to try to rescue anything from the Attic, at least it
 would be nice to have it in better shape before
 killing it.

They can be cleaned up and committed to RELENG_4 after the freeze is over.
The original 4.x patch posted wasn't ready for commit though.  (eg: externs
scattered all over the place rather than declaring things properly in the
include files).

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


HEADS UP: cvsup cvs-supfile users!

2003-03-04 Thread Peter Wemm
Anybody who uses the cvs-supfile example to get the repository should add
cvsroot-all to their supfile.  This is in addition to src-all, ports-all,
doc-all etc.

This is *ONLY* for the folks getting the CVS ,v files via cvsup.  If you
use tag=. or tag=RELENG_4, then you are not affected by this.

I have updated cvs-supfile in -current but not RELENG_4 yet.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: HEADS UP: cvsup cvs-supfile users!

2003-03-04 Thread Peter Wemm
Stijn Hoop wrote:

 On Tue, Mar 04, 2003 at 11:10:45AM -0800, Peter Wemm wrote:
  Anybody who uses the cvs-supfile example to get the repository should add
  cvsroot-all to their supfile.  This is in addition to src-all, ports-al=
 l,
  doc-all etc.
 =20
  This is *ONLY* for the folks getting the CVS ,v files via cvsup.  If you
  use tag=3D. or tag=3DRELENG_4, then you are not affected by this.
 =20
  I have updated cvs-supfile in -current but not RELENG_4 yet.
 
 Just to be doubly sure, this goes for cvsup mirrors as well, I assume?
 So I have to edit /usr/local/etc/cvsup/supfile to include it?
 If so, then you might want to update ports/net/cvsup-mirror/files/supfile a=
 lso.

No, people who use cvs-all are already getting this stuff.  If you use
the cvsup-mirror port yourself, you do not need to change anything either.
Mirrors who use cvs-all (official and unofficial) do not need to change
anything.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: Removal of netns - politically correct version

2003-03-04 Thread Peter Wemm
'
../../../netns/spp_usrreq.c:700: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c: In function `spp_output':
../../../netns/spp_usrreq.c:715: warning: nested extern declaration of `idpcksum'
../../../netns/spp_usrreq.c:940: warning: implicit declaration of function 
`spp_setpersist'
../../../netns/spp_usrreq.c:1079: too many arguments to function `ns_cksum'
../../../netns/spp_usrreq.c:1085: warning: redundant redeclaration of `spp_trace' in 
same scope
../../../netns/spp_usrreq.c:1018: warning: previous declaration of `spp_trace'
../../../netns/spp_usrreq.c:1088: warning: implicit declaration of function `ns_output'
../../../netns/spp_usrreq.c: At top level:
../../../netns/spp_usrreq.c:1115: warning: return type defaults to `int'
../../../netns/spp_usrreq.c:1115: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c: In function `spp_setpersist':
../../../netns/spp_usrreq.c:1117: warning: type defaults to `int' in declaration of `t'
../../../netns/spp_usrreq.c:1118: warning: nested extern declaration of `spp_backoff'
../../../netns/spp_usrreq.c:1118: warning: redundant redeclaration of `spp_backoff' in 
same scope
../../../netns/spp_timer.h:125: warning: previous declaration of `spp_backoff'
../../../netns/spp_usrreq.c: At top level:
../../../netns/spp_usrreq.c:1133: warning: return type defaults to `int'
../../../netns/spp_usrreq.c:1133: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c: In function `spp_ctloutput':
../../../netns/spp_usrreq.c:1146: warning: implicit declaration of function 
`idp_ctloutput'
../../../netns/spp_usrreq.c: At top level:
../../../netns/spp_usrreq.c:1258: warning: return type defaults to `int'
../../../netns/spp_usrreq.c:1258: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c: In function `spp_usrreq':
../../../netns/spp_usrreq.c:1270: warning: implicit declaration of function 
`ns_control'
../../../netns/spp_usrreq.c:1289: warning: implicit declaration of function 
`ns_pcballoc'
../../../netns/spp_usrreq.c:1299: `MT_PCB' undeclared (first use in this function)
../../../netns/spp_usrreq.c:1299: (Each undeclared identifier is reported only once
../../../netns/spp_usrreq.c:1299: for each function it appears in.)
../../../netns/spp_usrreq.c:1346: warning: implicit declaration of function 
`ns_pcbbind'
../../../netns/spp_usrreq.c:1477: warning: implicit declaration of function 
`ns_setsockaddr'
../../../netns/spp_usrreq.c:1481: warning: implicit declaration of function 
`ns_setpeeraddr'
../../../netns/spp_usrreq.c: At top level:
../../../netns/spp_usrreq.c:1510: warning: return type defaults to `int'
../../../netns/spp_usrreq.c:1510: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c:1531: warning: return type defaults to `int'
../../../netns/spp_usrreq.c:1531: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c:1559: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c: In function `spp_close':
../../../netns/spp_usrreq.c:1577: warning: implicit declaration of function 
`ns_pcbdetach'
../../../netns/spp_usrreq.c: At top level:
../../../netns/spp_usrreq.c:1588: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c:1594: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c:1604: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c:1625: warning: return type defaults to `int'
../../../netns/spp_usrreq.c:1625: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c:1637: warning: return type defaults to `int'
../../../netns/spp_usrreq.c:1637: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c:1661: warning: return type defaults to `int'
../../../netns/spp_usrreq.c:1661: warning: function declaration isn't a prototype
../../../netns/spp_usrreq.c: In function `spp_slowtimo':
../../../netns/spp_usrreq.c:1673: warning: `return' with no value, in function 
returning non-void
../../../netns/spp_usrreq.c: At top level:
../../../netns/spp_usrreq.c:1704: warning: function declaration isn't a prototype


Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: Removal of netns

2003-03-04 Thread Peter Wemm
Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Vincent Jardin writes:
 
 Why does it need to be removed ? According to me, it would be the same mista
ke 
 as the removal of netiso and netccitt. I did not know FreeBSD at this time, 
 but nowadays, in order to get an OS that supports many stacks, we have to us
e 
 NetBSD.
 
 BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will 
 support only IPv4 and IPv6, won't they ?
 
 We will import and retain any protocol stack which has enough interested 
 users and committers to keep it alive.
 
 netiso and netccitt both fell for both of those criteria: neither users
 nor committers.
 
 netns fails both criteria too.

Yep. It was removed in 1996 as well, because it didn't work.  One company
(Netcon) objected and claimed that they needed it for their commercial
product and that they'd send fixes.  Now, 7 years later, not a single
person has shown the slightest interest in fixing it.  It may as well have
been left in the Attic the whole time.

revision 1.7
date: 1996/10/17 18:42:19;  author: jkh;  state: Exp;  lines: +3 -1
branches:  1.7.2;
Bring back netns so that Netcon can take over support for it, as agreed.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


  1   2   3   4   5   6   7   8   >