Re: ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

[Sergey Kandaurov]

On Mon, Oct 07, 2019 at 09:48:16AM -0700, John Baldwin wrote:
> On 9/25/19 10:33 AM, Sergey Kandaurov wrote:
> > 
> > Index: lib/libsysdecode/mktables
> > ===
> > --- lib/libsysdecode/mktables   (revision 352685)
> > +++ lib/libsysdecode/mktables   (working copy)
> > @@ -157,7 +157,7 @@
> >  gen_table "sigcode" "SI_[A-Z]+[[:space:]]+0(x[0-9abcdef]+)?"   
> > "sys/signal.h"
> >  gen_table "umtxcvwaitflags" "CVWAIT_[A-Z_]+[[:space:]]+0x[0-9]+"   
> > "sys/umtx.h"
> >  gen_table "umtxrwlockflags" "URWLOCK_PREFER_READER[[:space:]]+0x[0-9]+"
> > "sys/umtx.h"
> > -gen_table "caprights"   
> > "CAP_[A-Z_]+[[:space:]]+CAPRIGHT\([0-9],[[:space:]]+0x[0-9]{16}ULL\)"   
> > "sys/capsicum.h"
> > +gen_table "caprights"   
> > "CAP_[A-Z_]+[[:space:]]+(CAPRIGHT|[()A-Z_|[:space:]]+CAP_LOOKUP)"   
> > "sys/capsicum.h"
> >  gen_table "sctpprpolicy""SCTP_PR_SCTP_[A-Z_]+[[:space:]]+0x[0-9]+" 
> > "netinet/sctp_uio.h" "SCTP_PR_SCTP_ALL"
> >  gen_table "cmsgtypesocket"  "SCM_[A-Z_]+[[:space:]]+0x[0-9]+"  
> > "sys/socket.h"
> >  if [ -e "${include_dir}/x86/sysarch.h" ]; then
> 
> CAP_SEEK and CAP_MMAP_X might also be subject to this.  However, I'm not quite
> understanding the regex, or at least why the modified portion of the regex 
> isn't
> something like this:
> 
> (CAPRIGHT\(|\(CAP_LOOKUP)

This won't match against CAP_LOOKUP on the right side, as in CAP_FSTATAT,
but since it is built from CAP_FSTAT and CAP_LOOKUP, it should be fine still.

> That is, you currently have [()A-Z_|[:space:]]+ for an expression that I think
> will only ever match a single '(' character.

All this sad magic is for preceding characters before CAP_LOOKUP,
such as in "(CAP_FSTAT | CAP_LOOKUP".  But seems it isn't needed.

> A more general form that might work for CAP_SEEK and CAP_MMAP_X might be
> to match on 'CAP_ | 0x 
> (CAPRIGHT\(|\([^)]*CAP_[A-Z_]+ \| 0x[0-9]+)

Given the above, it looks fine.
___
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: ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

[Sergey Kandaurov]

On Sat, Sep 21, 2019 at 08:43:58PM -0400, Ryan Stone wrote:
> I have written a short test program that runs unlinkat(2) in
> capability mode and fails due to not having the write capabilities:
> 
> https://people.freebsd.org/~rstone/src/unlink.c
> 
> If I run the binary under ktrace and look at the kdump output, it
> gives the following incorrect output:
> 
> 43775 unlink   CALL  unlinkat(0x3,0x7fffe995,0)
> 43775 unlink   NAMI  "from.QAUlAA0"
> 43775 unlink   CAP   operation requires CAP_LOOKUP, descriptor holds 
> CAP_LOOKUP
> 43775 unlink   RET   unlinkat -1 errno 93 Capabilities insufficient
> 
> The message should instead say that the operation requires
> CAP_UNLINKAT.  Looking at sys/capsicum.h, I suspect that the problem
> is related to the strange definition of CAP_UNLINKAT:
> 
> #define CAP_UNLINKAT (CAP_LOOKUP | 0x1000ULL)

FYI, with this grep it was able to decode capabilities.

Index: lib/libsysdecode/mktables
===
--- lib/libsysdecode/mktables   (revision 352685)
+++ lib/libsysdecode/mktables   (working copy)
@@ -157,7 +157,7 @@
 gen_table "sigcode" "SI_[A-Z]+[[:space:]]+0(x[0-9abcdef]+)?"   
"sys/signal.h"
 gen_table "umtxcvwaitflags" "CVWAIT_[A-Z_]+[[:space:]]+0x[0-9]+"   
"sys/umtx.h"
 gen_table "umtxrwlockflags" "URWLOCK_PREFER_READER[[:space:]]+0x[0-9]+"
"sys/umtx.h"
-gen_table "caprights"   
"CAP_[A-Z_]+[[:space:]]+CAPRIGHT\([0-9],[[:space:]]+0x[0-9]{16}ULL\)"   
"sys/capsicum.h"
+gen_table "caprights"   
"CAP_[A-Z_]+[[:space:]]+(CAPRIGHT|[()A-Z_|[:space:]]+CAP_LOOKUP)"   
"sys/capsicum.h"
 gen_table "sctpprpolicy""SCTP_PR_SCTP_[A-Z_]+[[:space:]]+0x[0-9]+" 
"netinet/sctp_uio.h" "SCTP_PR_SCTP_ALL"
 gen_table "cmsgtypesocket"  "SCM_[A-Z_]+[[:space:]]+0x[0-9]+"  
"sys/socket.h"
 if [ -e "${include_dir}/x86/sysarch.h" ]; then

On unlink.c, it gives:
 45494 unlink   CALL  cap_rights_limit(0x3,0x7fffead0)
 45494 unlink   STRU  cap_rights_t CAP_LOOKUP
 45494 unlink   RET   cap_rights_limit 0
 45494 unlink   CALL  openat(AT_FDCWD,0x200323,0)
 45494 unlink   NAMI  "/tmp"
 45494 unlink   RET   openat 4
 45494 unlink   CALL  cap_rights_limit(0x4,0x7fffead0)
 45494 unlink   STRU  cap_rights_t CAP_LOOKUP,CAP_UNLINKAT
 45494 unlink   RET   cap_rights_limit 0
 45494 unlink   CALL  cap_enter
 45494 unlink   RET   cap_enter 0
 45494 unlink   CALL  unlinkat(0x3,0x7fffeaa5,0)
 45494 unlink   NAMI  "from.YG6jQx2"
 45494 unlink   CAP   operation requires CAP_LOOKUP,CAP_UNLINKAT, descriptor 
holds CAP_LOOKUP

> I have observed the same problem with renameat(2) and
> CAP_RENAMEAT_SOURCE and CAP_RENAMEAT_TARGET:
> 
> https://people.freebsd.org/~rstone/src/rename.c

 49410 rename   CAP   operation requires CAP_LOOKUP,CAP_RENAMEAT_SOURCE, 
descriptor holds CAP_LOOKUP
___
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: Installworld fails with TMPDIR pointing to NFS mounted directory

[Sergey Kandaurov]

On 12 January 2016 at 19:42, Tom Vijlbrief  wrote:
> [..]
> export TMPDIR=/media/swan/tmp
>
> The NFS server exports /media/swan which has a src/ obj/ and tmp/
> subdirectory.
> src/ has the sources, obj/ is filled correctly by makeworld.
> The tmp dir has the correct permissions. The installworld runs till the
> end, except for the last cleanup action which fails:
>
> ===> etc/sendmail (install)
> cd /media/swan/src/etc/../share/man; make makedb
> makewhatis /d/root11/usr/share/man
> makewhatis /d/root11/usr/share/openssl/man
> rm: /media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8: Directory not empty
> rm: /media/swan/tmp/install.xrgbPMy8/locale: Directory not empty
> rm: /media/swan/tmp/install.xrgbPMy8: Directory not empty
> *** Error code 1

Search for NFS "sillyrename".

-- 
wbr,
pluknet
___
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: Make installworld fails on file not found (Error code 71)

[Sergey Kandaurov]

On 20 October 2015 at 11:07, Thomas Mueller  wrote:
> I was trying to test the new i915 graphics driver but got stuck in building 
> and installing the userland:
>
> /usr/share/man/man2/mknodat.2 -> /usr/share/man/man2/mknod.2
> /usr/share/man/man2/munlock.2 -> /usr/share/man/man2/mlock.2
> /usr/share/man/man2/munlockall.2 -> /usr/share/man/man2/mlockall.2
> /usr/share/man/man2/modfnext.2 -> /usr/share/man/man2/modnext.2
> /usr/share/man/man2/nmount.2 -> /usr/share/man/man2/mount.2
> /usr/share/man/man2/unmount.2 -> /usr/share/man/man2/mount.2
> /usr/share/man/man2/mq_timedreceive.2 -> /usr/share/man/man2/mq_receive.2
> /usr/share/man/man2/mq_timedsend.2 -> /usr/share/man/man2/mq_send.2
> /usr/share/man/man2/ntp_gettime.2 -> /usr/share/man/man2/ntp_adjtime.2
> /usr/share/man/man2/numa_setaffinity.2 -> 
> /usr/share/man/man2/numa_getaffinity.2
> install: link /usr/share/man/man2/numa_getaffinity.2 -> 
> /usr/share/man/man2/numa_setaffinity.2: No such file or directory
> *** Error code 71
>

This looks like if you would try to installworld on newer sources and older
objs without doing buildworld first to get in sync.

-- 
wbr,
pluknet
___
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: Upgrading to r297291 LAGG(4) stops working.

[Sergey Kandaurov]

On 4 September 2015 at 17:06, Gleb Smirnoff <gleb...@freebsd.org> wrote:
> On Fri, Sep 04, 2015 at 04:39:22PM +0300, Sergey Kandaurov wrote:
> S> On 1 September 2015 at 04:47, John Baldwin <j...@freebsd.org> wrote:
> S> > On Monday, August 31, 2015 09:58:45 AM Adrian Chadd wrote:
> S> >> Hi,
> S> >>
> S> >> +glebius, as he recently messed around with the wifi stack and his
> S> >> changes may have broken how mac addresses are assigned to the
> S> >> hardware.
> S> >
> S> > Glebius did break this, though not because of what you say.  It's broken
> S> > because the 'ifconfig_ath0' line that sets the mac address no longer
> S> > does anything because 'ath0' is no longer an interface (and so that
> S> > line is now ignored, plus it wouldn't work if it were passed to ifconfig
> S> > now anyway).
> S> >
> S> > At the very least the Handbook section on this needs to be updated to 
> give
> S> > working instructions for both HEAD and stable branches.
> S>
> S> What about this change?
> S> It should work in both current and stable (not tested, though).
>
> AFAIU, Adrian suggests to better change MAC of Ethernet device, rather
> than WiFi one. Not all WiFi drivers support change of MAC.

Of course, you're correct.
Unfortunately this required more changes, mostly words permutation.

Index: en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
===
--- en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
(revision 47311)
+++ en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
(working copy)
@@ -3671,43 +3671,53 @@
   security reasons, while maintaining the ability to transfer
   data over the wireless connection.

-This is achieved by overriding the physical wireless
+This is achieved by overriding the physical Ethernet
   interface's MAC address with that of the
-  Ethernet interface.
+  wireless interface.

 In this example, the Ethernet interface,
   bge0, is the master and the
-  wireless interface, wlan0, is
-  the failover.  The wlan0 device
+  wireless interface, wlan0, which
   was created from iwn0 wireless
-  interface, which will be configured with the
-  MAC address of the Ethernet interface.
-  First, determine the MAC address of the
-  Ethernet interface:
+  interface is the failover.  The bge0
+  interface will be configured with the
+  MAC address of the WLAN interface.
+  Replace the names of the network interfaces to match
+  the local configuration.

- ifconfig
bge0
-bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric
0 mtu 1500
-options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4
+First, bring the wireless interface up, but do not set
+  an IP address:
+
+ ifconfig
wlan0 create wlandev
iwn0 ssid
my_router up
+
+Determine the MAC address of the
+  WLAN interface.
+
+ ifconfig
wlan0
+wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST
metric 0 mtu 1500
 ether 00:21:70:da:ae:37
-inet6 fe80::221:70ff:feda:ae37%bge0 prefixlen 64 scopeid 0x2
-nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
-media: Ethernet autoselect (1000baseT full-duplex)
-status: active
+media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g
+status: associated
+ssid my_router channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac
+country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF
+AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan
+bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
+wme burst roaming MANUAL

-Replace bge0 to match the
-  system's Ethernet interface name.  The
-  ether line will contain the
-  MAC address of the specified interface.
-  Now, change the MAC address of the
-  underlying wireless interface:
+The ether line will contain the
+  MAC address of the specified
+  interface.

- ifconfig
iwn0 ether
00:21:70:da:ae:37
-
-Bring the wireless interface up, but do not set an
+Bring the Ethernet interface up, but do not set an
   IP address:

- ifconfig
wlan0 create wlandev
iwn0 ssid
my_router up
+ ifconfig
bge0 up

+Now, change the MAC address of the
+  Ethernet interface:
+
+ ifconfig
bge0 ether
00:21:70:da:ae:37
+
 Make sure the bge0 interface
   is up, then create the  interface with
   bge0 as master with failover to
@@ -3739,8 +3749,7 @@
   following entries to
   /etc/rc.conf:

-ifconfig_bge0="up"
-ifconfig_iwn0="ether
00:21:70:da:ae:37"
+ifconfig_bge0="ether
00:21:70:da:ae:37 up"
 wlans_iwn0="wlan0"
 ifconfig_wlan0="WPA"
 cloned_interfaces="lagg0"

-- 
wbr,
pluknet
___
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: Upgrading to r297291 LAGG(4) stops working.

[Sergey Kandaurov]

On 1 September 2015 at 04:47, John Baldwin  wrote:
> On Monday, August 31, 2015 09:58:45 AM Adrian Chadd wrote:
>> Hi,
>>
>> +glebius, as he recently messed around with the wifi stack and his
>> changes may have broken how mac addresses are assigned to the
>> hardware.
>
> Glebius did break this, though not because of what you say.  It's broken
> because the 'ifconfig_ath0' line that sets the mac address no longer
> does anything because 'ath0' is no longer an interface (and so that
> line is now ignored, plus it wouldn't work if it were passed to ifconfig
> now anyway).
>
> At the very least the Handbook section on this needs to be updated to give
> working instructions for both HEAD and stable branches.

What about this change?
It should work in both current and stable (not tested, though).

Index: en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
===
--- en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
(revision 47311)
+++ en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
(working copy)
@@ -3697,17 +3697,19 @@
 Replace bge0 to match the
   system's Ethernet interface name.  The
   ether line will contain the
-  MAC address of the specified interface.
-  Now, change the MAC address of the
-  underlying wireless interface:
+  MAC address of the specified
+  interface.

- ifconfig
iwn0 ether
00:21:70:da:ae:37
-
 Bring the wireless interface up, but do not set an
   IP address:

  ifconfig
wlan0 create wlandev
iwn0 ssid
my_router up

+Now, change the MAC address of the
+  underlying wireless interface:
+
+ ifconfig
wlan0 ether
00:21:70:da:ae:37
+
 Make sure the bge0 interface
   is up, then create the  interface with
   bge0 as master with failover to
@@ -3740,9 +3742,9 @@
   /etc/rc.conf:

 ifconfig_bge0="up"
-ifconfig_iwn0="ether
00:21:70:da:ae:37"
 wlans_iwn0="wlan0"
 ifconfig_wlan0="WPA"
+ifconfig_wlan0_alias0="ether 00:21:70:da:ae:3"
 cloned_interfaces="lagg0"
 ifconfig_lagg0="laggproto
failover laggport bge0 laggport wlan0 DHCP"
   

-- 
wbr,
pluknet
___
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: Notice: wifi infrastructure upgraded; time to mergemaster!

[Sergey Kandaurov]

On 29 August 2015 at 03:46, Rui Paulo rpa...@me.com wrote:
 I just upgraded and there were zero rc.conf changes.  Were you talking
 about custom rc.d scripts?

You probably want to re-read subject.

-- 
wbr,
pluknet
___
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: FreeBSD_HEAD-tests - Build #1226 - Unstable

[Sergey Kandaurov]

On 28 July 2015 at 00:23,  jenkins-ad...@freebsd.org wrote:
 FreeBSD_HEAD-tests - Build #1226 - Unstable:

[..]
 [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send  -  failed: 2 
 checks failed; see output for more details  [0.371s]
 [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send_sigpipe  -  
 failed: 2 checks failed; see output for more details  [0.553s]

I'd fix this if the testing infrastructure was something easily
setup'able locally with e.g. a freshly downloaded VM image.
Currently it is not so, coz trying to build tests/sys/kern emits
some linking errors due missing atf symbols.

-- 
wbr,
pluknet
___
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: null pointer dereference panic in cap_rights_contains() on 11.0-CURRENT r285785 amd64

[Sergey Kandaurov]

On 24 July 2015 at 01:24, Don Lewis truck...@freebsd.org wrote:
 I just got this panic while using poudriere to build packages for
 FreeBSD 8.4 i386.
[..]
 db bt
 Tracing pid 78211 tid 101405 td 0xf80139td29a0
 cap_rights_contains() at cap_rights_contains+0x24/frame
 0xfe005acc772d0
 cap_check() at cap_check+0x15/frame 0xfe005acc7800
 fget_unlocked() at fget_unlocked+0xca/frame 0xfe005acc7870
 fget() at fget+0x2b/frame 0xfe005acc78a0
 ksem_get at ksem_get+0x1e/frame 0xfe05acc78e0
 sys_ksem_close() at sys_ksem_close+0x23/frame 0xfe005acc7920
 ia32_syscall() at ia32_syscall+0x2a5/frame 0xfe005acc7a30
 Xint0x00_syscall() at Xint0x00_syscall+0x95/frame 0xfe00acc7a30
 --- syscall (400, FreeBSD ELF32, sys_ksem_close), rip = 0x2828676b, rsp
 = 0xc60c, rbp = 0xc628 ---



Looks like this was missed after r284442.

Index: kern/uipc_sem.c
===
--- kern/uipc_sem.c(revision 285723)
+++ kern/uipc_sem.c(working copy)
@@ -651,12 +651,13 @@
 int
 sys_ksem_close(struct thread *td, struct ksem_close_args *uap)
 {
+cap_rights_t rights;
 struct ksem *ks;
 struct file *fp;
 int error;

 /* No capability rights required to close a semaphore. */
-error = ksem_get(td, uap-id, 0, fp);
+error = ksem_get(td, uap-id, cap_rights_init(rights), fp);
 if (error)
 return (error);
 ks = fp-f_data;
@@ -872,12 +873,13 @@
 int
 sys_ksem_destroy(struct thread *td, struct ksem_destroy_args *uap)
 {
+cap_rights_t rights;
 struct file *fp;
 struct ksem *ks;
 int error;

 /* No capability rights required to close a semaphore. */
-error = ksem_get(td, uap-id, 0, fp);
+error = ksem_get(td, uap-id, cap_rights_init(rights), fp);
 if (error)
 return (error);
 ks = fp-f_data;


-- 
wbr,
pluknet
___
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: COMPAT_FREEBD8 doesn't exists.

[Sergey Kandaurov]

On 17 June 2015 at 15:00, Arseny Nasokin eir...@gmail.com wrote:
 There was some talks back on 2011/2012 about this option, that kernel
 should include it, but there is no such option (you can see at least
 PR#163630 about this).

 Also I've not found any commit which adds this option and no code in kernel
 which depends on it.

 Is note about this option should be nonexistent somewhere? Should it be
 added to options as dummy?


Because there were no (or at least no noticed) such ABI changes in kernel.
Probably it's worth mentioning this in NOTES to not confuse newcomers.
But I'd personally leave it alone.

Index: sys/conf/NOTES
===
--- sys/conf/NOTES(revision 284433)
+++ sys/conf/NOTES(working copy)
@@ -353,6 +353,8 @@
 # Enable FreeBSD7 compatibility syscalls
 options COMPAT_FREEBSD7

+# No changes that required COMPAT_FREEBSD8
+
 # Enable FreeBSD9 compatibility syscalls
 options COMPAT_FREEBSD9


-- 
wbr,
pluknet
___
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

[patch] chmod: change directory permissions in pre-order

[Sergey Kandaurov]

Change directory permissions in pre-order.
In this order, it won't try to recurse into a directory for which
it doesn't have permission, before changing that permission.
This follows the existing behavior in other BSDs, linux, OS X.

Obtained from:  NetBSD
Found by:   while digging in buildbot sources
Index: chmod.c
===
--- chmod.c (revision 283969)
+++ chmod.c (working copy)
@@ -162,14 +162,16 @@
atflag = AT_SYMLINK_NOFOLLOW;
 
switch (p-fts_info) {
-   case FTS_D: /* Change it at FTS_DP. */
+   case FTS_D:
if (!Rflag)
fts_set(ftsp, p, FTS_SKIP);
-   continue;
+   break;
case FTS_DNR:   /* Warn, chmod. */
warnx(%s: %s, p-fts_path, strerror(p-fts_errno));
rval = 1;
break;
+   case FTS_DP:/* Already changed at FTS_D. */
+   continue;
case FTS_ERR:   /* Warn, continue. */
case FTS_NS:
warnx(%s: %s, p-fts_path, strerror(p-fts_errno));


pgptCFc3Bf3nt.pgp
Description: PGP signature

Re: Panic using QLogic NetXtreme II BCM57810 with latest CURRENT snapshot

[Sergey Kandaurov]

On 13 May 2015 at 00:21, Niclas Zeising zeis...@freebsd.org wrote:
 Hi!
 I got the following panic with a QLogic NetXtreme II BCM57810 when
 trying to assign an IP address using dhclient.  The network card uses
 the bxe driver.  The machine in question is a HP DL380 Gen9.

 Kernel page fault with the following non-sleepable locks held:
 shared rw if_addr_lock (if_addr_lock) locked @ /usr/src/sys/net/if.c:1539
 exclusive sleep mutex bxe0_mcast_lock lockeed @
 /usr/src/sys/dev/bxe/bxe.c:12548

 See screenshots at the links below for details and a stack trace.
 I can provoke this panic at will, let me know if you need more details.
  Unfortunately I don't have access to a console where I can copy things
 out currently, so screenshots have to do.

 Screenshot 1: https://people.freebsd.org/~zeising/panic1.png
 Screenshot 2: https://people.freebsd.org/~zeising/panic2.png


I'm not in any way a network/bxe expert, and this is probably unrelated,
but I see there at least a missing unlock at the error path.

Index: sys/dev/bxe/bxe.c
===
--- sys/dev/bxe/bxe.c   (revision 282468)
+++ sys/dev/bxe/bxe.c   (working copy)
@@ -12551,6 +12551,7 @@
 rc = ecore_config_mcast(sc, rparam, ECORE_MCAST_CMD_DEL);
 if (rc  0) {
 BLOGE(sc, Failed to clear multicast configuration: %d\n, rc);
+BXE_MCAST_UNLOCK(sc);
 return (rc);
 }

BXE_MCAST_LOCK acquires two locks: sc mutex, and if_maddr_rlock(ifp)

OTOH, in bxe_init_mcast_macs_list(), down the path, if_maddr_rlock is acquired
(and released) one more time: in if_multiaddr_array / if_multiaddr_count
functions. Is it recursive?

Another one is bcopy under lock. It is probably inlined
under bxe_handle_rx_mode_tq() in ddb, so the actual place
where it's called is not visible.
My guess is bcopy in bxe_init_mcast_macs_list():

 bcopy((mta + (i * ETHER_ADDR_LEN)), mc_mac-mac, ETHER_ADDR_LEN);

Previously, there was a pointer assignment, see stable/10:

mc_mac-mac = (uint8_t *)LLADDR((struct sockaddr_dl *)ifma-ifma_addr);

mc_mac itself is malloc(M_ZERO)'ed, so that mc_mac-mac is NULL.

Probably bcopy should be restored to assignment (not even compile tested):

Index: sys/dev/bxe/bxe.c
===
--- sys/dev/bxe/bxe.c   (revision 282468)
+++ sys/dev/bxe/bxe.c   (working copy)
@@ -12506,7 +12506,7 @@
   to be  different */
 for(i=0; i mcnt; i++) {

-bcopy((mta + (i * ETHER_ADDR_LEN)), mc_mac-mac, ETHER_ADDR_LEN);
+mc_mac-mac = (uint8_t *)(mta + (i * ETHER_ADDR_LEN));
 ECORE_LIST_PUSH_TAIL(mc_mac-link, p-mcast_list);

 BLOGD(sc, DBG_LOAD,

-- 
wbr,
pluknet
___
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: libthr and main thread stack size

[Sergey Kandaurov]

On 23 September 2014 13:24, Konstantin Belousov kostik...@gmail.com wrote:
 In the patch, default behaviour is to provide RLIMIT_STACK sized stack
 for the main thread.  The knobs are there to restore the old AS layout
 if my fears of the binary compatibility become real one day, and to
 keep the interface compat with the stable/10, which already got a knob
 merged.

 That said, below the patch with libthr.7 man page merged to libthr.3,
 and with the editing applied.

 diff --git a/lib/libthr/libthr.3 b/lib/libthr/libthr.3
 index bfbebec..aa4572c 100644
 --- a/lib/libthr/libthr.3
 +++ b/lib/libthr/libthr.3
 @@ -1,6 +1,11 @@
  .\ Copyright (c) 2005 Robert N. M. Watson
 +.\ Copyright (c) 2014 The FreeBSD Foundation, Inc.
  .\ All rights reserved.
  .\
 +.\ Part of this documentation was written by
 +.\ Konstantin Belousov k...@freebsd.org under sponsorship
 +.\ from the FreeBSD Foundation.
 +.\
  .\ Redistribution and use in source and binary forms, with or without
  .\ modification, are permitted provided that the following conditions
  .\ are met:
 @@ -24,7 +29,7 @@
  .\
  .\ $FreeBSD$
  .\
 -.Dd October 19, 2007
 +.Dd September 20, 2014
  .Dt LIBTHR 3
  .Os
  .Sh NAME
 @@ -45,8 +50,216 @@ has been optimized for use by applications expecting 
 system scope thread
  semantics, and can provide significant performance improvements
  compared to
  .Lb libkse .
 +.Pp
 +The library is tightly integrated with the run-time link editor
 +.Xr ld-elf.so.1 1
 +and
 +.Lb libc ;
 +all three components must be built from the same source tree.
 +Mixing
 +.Li libc
 +and
 +.Nm
 +libraries from different versions of
 +.Fx
 +is not supported.
 +The run-time linker
 +.Xr ld-elf.so.1 1
 +has some code to ensure backward-compatibility with older versions of
 +.Nm .
 +.Pp
 +The man page documents the quirks and tunables of the
 +.Nm .
 +When linking with
 +.Li -lpthread ,
 +the run-time dependency
 +.Li libthr.so.3
 +is recorded in the produced object.
 +.Sh MUTEX ACQUISITION
 +A locked mutex (see
 +.Xr pthread_mutex_lock 3 )
 +is represented by a volatile variable of type
 +.Dv lwpid_t ,
 +which records the global system identifier of the thread
 +owning the lock.
 +.Nm
 +performs a contested mutex acquisition in three stages, each of which
 +is more resource-consuming than the previous.
 +.Pp
 +First, a spin loop
 +is performed, where the library attempts to acquire the lock by
 +.Xr atomic 9
 +operations.
 +The loop count is controlled by the
 +.Ev LIBPTHREAD_SPINLOOPS
 +environment variable, with a default value of 2000.
 +.Pp
 +If the spin loop
 +was unable to acquire the mutex, a yeild loop
typo: yield

[...]
  .Sh SEE ALSO
 -.Xr pthread 3
 +.Xr ktrace 1 ,
 +.Xr ld-elf.so.1 1 ,
 +.Xr getrlimit 2 ,
 +.Xr umtx 2 ,
 +.Xr dlclose 3 ,
 +.Xr dlopen 3 ,
 +.Xr errno 3 ,
 +.Xr getenv 3 ,
 +.Xr libc 3 ,
 +.Xr pthread_attr 3 ,
 +.Xr pthread_attr_setstacksize 3 ,
 +.Xr pthread_create 3 ,
 +.Xr signal 3 ,
 +.Xr atomic 9 .
no pediod there per mdoc

  .Sh AUTHORS
  .An -nosplit
  The
 diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c
 index 9bf0e29..72a067a 100644
 --- a/lib/libthr/thread/thr_init.c
 +++ b/lib/libthr/thread/thr_init.c
 @@ -445,7 +445,7 @@ init_private(void)
 struct rlimit rlim;
 size_t len;
 int mib[2];
 -   char *env;
 +   char *env, *env_bigstack, *env_splitstack;

 _thr_umutex_init(_mutex_static_lock);
 _thr_umutex_init(_cond_static_lock);
 @@ -473,8 +473,9 @@ init_private(void)
 len = sizeof (_usrstack);
 if (sysctl(mib, 2, _usrstack, len, NULL, 0) == -1)
 PANIC(Cannot get kern.usrstack from sysctl);
 -   env = getenv(LIBPTHREAD_BIGSTACK_MAIN);
 -   if (env != NULL) {
 +   env_bigstack = getenv(LIBPTHREAD_BIGSTACK_MAIN);
 +   env_splitstack = getenv(LIBPTHREAD_SPLITSTACK_MAIN);
 +   if (bigstack != NULL || env_splitstack == NULL) {
looks like a typo: s/bigstack/env_bigstack/

 if (getrlimit(RLIMIT_STACK, rlim) == -1)
 PANIC(Cannot get stack rlimit);
 _thr_stack_initial = rlim.rlim_cur;

-- 
wbr,
pluknet
___
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: [heads up] axing AppleTalk and IPX/SPX

[Sergey Kandaurov]

On 13 March 2014 20:43, Gleb Smirnoff gleb...@freebsd.org wrote:
   Hi!

   Since initial mail

   http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045911.html

 did not raise a lot of objection, I'm going to proceed with this.

Would you like to clean up from DECnet as well? :)

sys/net/if_fddisubr.c
73: #ifdef DECNET
74: #include netdnet/dn.h
75: #endif

-- 
wbr,
pluknet
___
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: option PROCDESC is gone?

[Sergey Kandaurov]

On Fri, Feb 07, 2014 at 05:33:56AM -0800, Anton Shterenlikht wrote:
 /usr/src/UPDATING:
 
 20130905:
 The PROCDESC kernel option is now part of the GENERIC kernel
 configuration and is required for the rwhod(8) to work.
 If you are using custom kernel configuration, you should include
 'options PROCDESC'.
 
 There is no later entry advising not to use it,
 yet it seems to have gone from all generic kernels.

This options was removed in HEAD. This probably should be noted.

Index: UPDATING
===
--- UPDATING(revision 261596)
+++ UPDATING(working copy)
@@ -57,6 +57,10 @@
big-endian integer in accordance with RFC 4402.
__FreeBSD_version is bumped to 114.
 
+20131130:
+   The PROCDESC kernel option has been removed. Its
+   functionality now turned on by default.
+
 20131108:
The WITHOUT_ATF build knob has been removed and its functionality
has been subsumed into the more generic WITHOUT_TESTS.  If you were



pgpOfhYt5KXSF.pgp
Description: PGP signature

Re: [head tinderbox] failure on amd64/amd64

[Sergey Kandaurov]

On 27 November 2013 17:59, Shawn Webb latt...@gmail.com wrote:
 On Wed, Nov 27, 2013 at 8:07 AM, FreeBSD Tinderbox 
 tinder...@freebsd.orgwrote:

  stage 3.2: building everything
 [...]
 ^
 /src/sys/sys/sdt.h:153:19: note: expanded from macro 'SDT_PROBE_DEFINE'
 struct sdt_probe sdt_##prov##_##mod##_##func##_##name[1] = {
  \
  ^
 scratch space:51:1: note: expanded from here
 sdt_vnet_functions_vnet_destroy_entry
 ^
 4 errors generated.
 *** Error code 1

 Stop.
 bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT-VIMAGE
 *** Error code 1

 Stop.
 bmake: stopped in /src
 *** Error code 1

 Stop in /src.
 TB --- 2013-11-27 13:07:05 - WARNING: /usr/bin/make returned exit code  1
 TB --- 2013-11-27 13:07:05 - ERROR: failed to build LINT-VIMAGE kernel
 TB --- 2013-11-27 13:07:05 - 15909.88 user 3061.45 system 20807.46 real


 http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full


 Seems like this was a typo or copy/paste error. This patch fixes it:


This should be fixed in r258675. Tinderbox is lagging behind.

-- 
wbr,
pluknet
___
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

panic: sbdrop in sbcut_internal

[Sergey Kandaurov]

Seen this on head while doing two `/etc/rc.d/netif restart wlan0' in parallel.
Thanks our shiny new compiler I can not examine local vars.

 $FreeBSD: head/sys/kern/uipc_sockbuf.c 256185 2013-10-09
11:57:53Z glebius $

Unread portion of the kernel message buffer:
118Nov 24 20:35:52 omg wpa_supplicant[55133]: ioctl[SIOCS80211,
op=26, val=0, arg_len=0]: Operation not supported
panic: sbdrop
cpuid = 0

#2  0x805904b4 in panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:754
#3  0x805fe2eb in sbcut_internal (sb=value optimized out,
len=value optimized out) at /usr/src/sys/kern/uipc_sockbuf.c:859
#4  0x805fd368 in sbflush_internal (sb=0xf8000b4b0348)
at /usr/src/sys/kern/uipc_sockbuf.c:821
#5  0x805fd4a2 in sbdestroy (sb=0xf8000b4b0348,
so=0xf8000b4b02b8) at /usr/src/sys/kern/uipc_sockbuf.c:339
#6  0x805ff300 in sofree (so=0xf8000b4b02b8)
at /usr/src/sys/kern/uipc_socket.c:752
#7  0x805ff7d2 in soclose (so=value optimized out)
at /usr/src/sys/kern/uipc_socket.c:837
#8  0x805502f9 in _fdrop (fp=0xf8000b4d5370, td=0x0) at file.h:342
#9  0x80552b97 in closef (fp=value optimized out,
td=value optimized out) at /usr/src/sys/kern/kern_descrip.c:2315
#10 0x805505f5 in closefp (fdp=0xf8000b3bb800,
fd=value optimized out, fp=0xf8000b4d5370, td=0xf8000b036490,
holdleaders=value optimized out) at /usr/src/sys/kern/kern_descrip.c:1159
#11 0x807c23c7 in amd64_syscall (td=0xf8000b036490, traced=0)
at subr_syscall.c:134

(kgdb) f 3
#3  0x805fe2eb in sbcut_internal (sb=value optimized out,
len=value optimized out) at /usr/src/sys/kern/uipc_sockbuf.c:859
859panic(sbdrop);
(kgdb) list
854mfree = NULL;
855
856while (len  0) {
857if (m == 0) {
858if (next == 0)
859panic(sbdrop);
860m = next;
861next = m-m_nextpkt;
862continue;
863}

-- 
wbr,
pluknet
___
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: make_dev_credv: bad si_name (error=17, si_name=iscsi)

[Sergey Kandaurov]

On 24 September 2013 11:46, Sergey V. Dyatko sergey.dya...@gmail.com wrote:
 Hi,

 today I tried to play a bit with new iscsi

 r255812 isn't fully complete fix?

[...]
 run  `kldload iscsi_initiator` and got a panic:

Something like this quick'n'dirty should work.
Compile tested only.

Index: sys/dev/iscsi_initiator/iscsi.c
===
--- sys/dev/iscsi_initiator/iscsi.c(revision 255841)
+++ sys/dev/iscsi_initiator/iscsi.c(working copy)
@@ -715,7 +715,8 @@
  TUNABLE_INT_FETCH(net.iscsi_initiator.max_pdus, max_pdus);

  isc =  malloc(sizeof(struct isc_softc), M_ISCSI, M_ZERO|M_WAITOK);
- isc-dev = make_dev(iscsi_cdevsw, max_sessions, UID_ROOT,
GID_WHEEL, 0600, iscsi);
+ isc-dev = make_dev_credf(MAKEDEV_CHECKNAME, iscsi_cdevsw, max_sessions,
+   NULL, UID_ROOT, GID_WHEEL, 0600, iscsi);
  isc-dev-si_drv1 = isc;
  mtx_init(isc-isc_mtx, iscsi-isc, NULL, MTX_DEF);


-- 
wbr,
pluknet
___
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: make_dev_credv: bad si_name (error=17, si_name=iscsi)

[Sergey Kandaurov]

On 24 September 2013 14:40, Sergey Kandaurov pluk...@gmail.com wrote:
 On 24 September 2013 11:46, Sergey V. Dyatko sergey.dya...@gmail.com wrote:
 Hi,

 today I tried to play a bit with new iscsi

 r255812 isn't fully complete fix?

 [...]
 run  `kldload iscsi_initiator` and got a panic:

 Something like this quick'n'dirty should work.
 Compile tested only.

 Index: sys/dev/iscsi_initiator/iscsi.c
 ===
 --- sys/dev/iscsi_initiator/iscsi.c(revision 255841)
 +++ sys/dev/iscsi_initiator/iscsi.c(working copy)
 @@ -715,7 +715,8 @@
   TUNABLE_INT_FETCH(net.iscsi_initiator.max_pdus, max_pdus);

   isc =  malloc(sizeof(struct isc_softc), M_ISCSI, M_ZERO|M_WAITOK);
 - isc-dev = make_dev(iscsi_cdevsw, max_sessions, UID_ROOT,
 GID_WHEEL, 0600, iscsi);
 + isc-dev = make_dev_credf(MAKEDEV_CHECKNAME, iscsi_cdevsw, 
 max_sessions,
 +   NULL, UID_ROOT, GID_WHEEL, 0600, iscsi);
   isc-dev-si_drv1 = isc;
   mtx_init(isc-isc_mtx, iscsi-isc, NULL, MTX_DEF);

Erm, of course it shall be checked against failure.

-- 
wbr,
pluknet
___
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: make_dev_credv: bad si_name (error=17, si_name=iscsi)

[Sergey Kandaurov]

On 24 September 2013 15:44, Edward Tomasz Napierała tr...@freebsd.org wrote:
 Wiadomość napisana przez Sergey Kandaurov pluk...@gmail.com w dniu 24 wrz 
 2013, o godz. 13:00:
 On 24 September 2013 14:40, Sergey Kandaurov pluk...@gmail.com wrote:
 On 24 September 2013 11:46, Sergey V. Dyatko sergey.dya...@gmail.com 
 wrote:
 Hi,

 today I tried to play a bit with new iscsi

 r255812 isn't fully complete fix?

 [...]
 run  `kldload iscsi_initiator` and got a panic:

 Something like this quick'n'dirty should work.
 Compile tested only.

 Index: sys/dev/iscsi_initiator/iscsi.c
 ===
 --- sys/dev/iscsi_initiator/iscsi.c(revision 255841)
 +++ sys/dev/iscsi_initiator/iscsi.c(working copy)
 @@ -715,7 +715,8 @@
  TUNABLE_INT_FETCH(net.iscsi_initiator.max_pdus, max_pdus);

  isc =  malloc(sizeof(struct isc_softc), M_ISCSI, M_ZERO|M_WAITOK);
 - isc-dev = make_dev(iscsi_cdevsw, max_sessions, UID_ROOT,
 GID_WHEEL, 0600, iscsi);
 + isc-dev = make_dev_credf(MAKEDEV_CHECKNAME, iscsi_cdevsw, 
 max_sessions,
 +   NULL, UID_ROOT, GID_WHEEL, 0600, iscsi);
  isc-dev-si_drv1 = isc;
  mtx_init(isc-isc_mtx, iscsi-isc, NULL, MTX_DEF);

 Erm, of course it shall be checked against failure.

 Sure.  What do you think about this:

 Index: sys/dev/iscsi_initiator/iscsi.c
 ===
 --- sys/dev/iscsi_initiator/iscsi.c (revision 255834)
 +++ sys/dev/iscsi_initiator/iscsi.c (working copy)
 @@ -715,8 +715,14 @@ iscsi_start(void)
   TUNABLE_INT_FETCH(net.iscsi_initiator.max_pdus, max_pdus);

   isc =  malloc(sizeof(struct isc_softc), M_ISCSI, M_ZERO|M_WAITOK);
 - isc-dev = make_dev(iscsi_cdevsw, max_sessions, UID_ROOT, GID_WHEEL, 
 0600, iscsi);
 - isc-dev-si_drv1 = isc;
 + isc-dev = make_dev_credf(MAKEDEV_CHECKNAME, iscsi_cdevsw, 
 max_sessions,
 + NULL, UID_ROOT, GID_WHEEL, 0600, iscsi);
 + if (isc-dev == NULL) {
 + xdebug(iscsi_initiator: make_dev_credf failed);
 + // XXX: don't return; otherwise it would panic on unload
 + } else {
 +isc-dev-si_drv1 = isc;
 + }
   mtx_init(isc-isc_mtx, iscsi-isc, NULL, MTX_DEF);

   TAILQ_INIT(isc-isc_sess);


LGTM, except there is different indentation where for function calls
each new line aligned with the first function argument.

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

Re: CURRENT r253794: make installkernel fails: install: runfw.ko: No such file or directory

[Sergey Kandaurov]

On 30 July 2013 11:44, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 On Tue, 30 Jul 2013 09:29:56 +0200
 O. Hartmann ohart...@zedat.fu-berlin.de wrote:



 make installkernel  fails in r253794 with the following error:

 === usb/runfw (install)
 install -o root -g wheel -m 555   runfw.ko /boot/kernel
 install: runfw.ko: No such file or directory
 *** Error code 71

 regards,

 oliver

 This is fun:

 The make buildworld buildkernel command worked once, world and
 kernel/modules got built.

 While make installkernel fails with the above shown error, a make
 kernel issued again failed then at

 === usb/runfw (all)
 make: don't know how to
 make /usr/src/sys/modules/usb/runfw/../../contrib/dev/run/rt2870.fw.uu.
 Stop

 make: stopped in /usr/src/sys/modules/usb/runfw
 *** Error code 2


Please try this patch.

Index: sys/modules/usb/runfw/Makefile
===
--- sys/modules/usb/runfw/Makefile  (revision 253794)
+++ sys/modules/usb/runfw/Makefile  (working copy)
@@ -5,7 +5,7 @@

 CLEANFILES=run.fw

-run.fw: ${.CURDIR}/../../contrib/dev/run/rt2870.fw.uu
-   uudecode -p ${.CURDIR}/../../contrib/dev/run/rt2870.fw.uu  ${.TARGET}
+run.fw: ${.CURDIR}/../../../contrib/dev/run/rt2870.fw.uu
+   uudecode -p ${.CURDIR}/../../../contrib/dev/run/rt2870.fw.uu  
${.TARGET}

 .include bsd.kmod.mk


-- 
wbr,
pluknet
___
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

[patch] expand_number(3): check strtoumax(3) for ERANGE

[Sergey Kandaurov]

Hi,

As of now expand_number(3) does not properly check too large data.
It currently handles errors only for prefixed values.

(an argument is intentionally signed to be closer to the real buggish world,
e.g. as it's currently done in truncate(1). This should not compile, though
see bsd.sys.mk@169723).

int64_t sz;

if (expand_number(argv[1], sz)  0)
err(1, expand_number);

printf(%ld\n, sz);


[pluknet@omg] ./expand_number 8000p
9007199254740992000
[pluknet@omg] ./expand_number 9000p
-8313644912125935616
[pluknet@omg] ./expand_number 19000p
expand_number: expand_number: Result too large

[pluknet@omg] ./expand_number 0x7fff (INT64_MAX)
9223372036854775807
[pluknet@omg] ./expand_number 0x (UINT64_MAX)
-1

But

[pluknet@omg] ./expand_number 0xf ( UINT64_MAX)
-1 (actually UINTMAX_MAX expressed as signed)

This is how it should work:

[pluknet@omg] ./expand_number 0xf ( UINT64_MAX)
expand_number: expand_number: Result too large

Index: lib/libutil/expand_number.c
===
--- lib/libutil/expand_number.c (revision 253546)
+++ lib/libutil/expand_number.c (working copy)
@@ -55,6 +55,10 @@

number = strtoumax(buf, endptr, 0);

+   if (number == UINTMAX_MAX  errno == ERANGE) {
+   return (-1);
+   }
+
if (endptr == buf) {
/* No valid digits. */
errno = EINVAL;

-- 
wbr,
pluknet
___
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: r253351 implicit definition of 'critical_exit'.

[Sergey Kandaurov]

On 15 July 2013 18:01, Ian FREISLICH i...@clue.co.za wrote:
 Hi

 Recent change:
 -
 # svn log ./sys/sys/sf_buf.h |less
 
 r253351 | ae | 2013-07-15 08:16:57 +0200 (Mon, 15 Jul 2013) | 6 lines

 Introduce new structure sfstat for collecting sendfile's statistics
 and remove corresponding fields from struct mbstat. Use PCPU counters
 and SFSTAT_INC() macro for update these statistics.
 -

 Includes sys/counter.h in sys/sf_buf.h.  sys/counter.h uses macros
 defined in sys/systm.h resulting in implicit definitions of
 critical_exit and others and then errors in conflicting types for
 critical_exit later when sys/system.h is includd _after_ sys/sf_buf.h
 in sys/i386/i386/uio_machdep.c.

 I haven't checked amd64 yet, but this patch fixes the build:

 Index: /usr/src/sys/i386/i386/uio_machdep.c
 ===
 --- /usr/src/sys/i386/i386/uio_machdep.c(revision 253361)
 +++ /usr/src/sys/i386/i386/uio_machdep.c(working copy)
 @@ -44,8 +44,8 @@
  #include sys/mutex.h
  #include sys/proc.h
  #include sys/sched.h
 +#include sys/systm.h
  #include sys/sf_buf.h
 -#include sys/systm.h
  #include sys/uio.h

  #include vm/vm.h

 However, sys/system.h coul equally be included in sys/sf_buf.h
 before sys/counter.h.  I don't know which is the correct fix.

AFAIK, this is because systm.h isn't properly sorted here
(also in amd64 and probably others).
It should go right after sys/param.h.

-- 
wbr,
pluknet
___
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: too many warnigns for variable 'cons_next_next'

[Sergey Kandaurov]

On 1 July 2013 17:11, Svatopluk Kraus onw...@gmail.com wrote:
 Hi,

   could somebody help me, please, with too many following warnings:
 sys/buf_ring.h:189:33: warning: variable 'cons_next_next' set but not used

 As the warning is produced by header which is included a lot, the important
 warnings are visible poorly among them. I think that buf_ring_dequeue_sc()
 in sys/buf_ring.h could be change to suppress the warning this way:
 static __inline void *
 buf_ring_dequeue_sc(struct buf_ring *br)
 {
 -   uint32_t cons_head, cons_next, cons_next_next;
 +   uint32_t cons_head, cons_next, cons_next_next __unused;
 uint32_t prod_tail;
 void *buf;

 cons_head = br-br_cons_head;
 prod_tail = br-br_prod_tail;

 +   if (cons_head == prod_tail)
 +   return (NULL);

 cons_next = (cons_head + 1)  br-br_cons_mask;
 -   cons_next_next = (cons_head + 2)  br-br_cons_mask;

 -   if (cons_head == prod_tail)
 -   return (NULL);
 #ifdef PREFETCH_DEFINED
 +   cons_next_next = (cons_head + 2)  br-br_cons_mask;
 if (cons_next != prod_tail) {
 prefetch(br-br_ring[cons_next]);
 if (cons_next_next != prod_tail)
 prefetch(br-br_ring[cons_next_next]);
 }
 #endif


Why not put its declaration under #ifdef as well? YMMV.

-- 
wbr,
pluknet
___
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: [head tinderbox] failure on ia64/ia64

[Sergey Kandaurov]

On 28 June 2013 18:22, FreeBSD Tinderbox tinder...@freebsd.org wrote:
 [...]
 (cd /src/rescue/rescue/../../sbin/swapon   /obj/src/make.amd64/make 
 -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/swapon/ depend  
 /obj/src/make.amd64/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE 
 DIRPRFX=rescue/rescue/swapon/ swapon.o)
 rm -f .depend
 CC='cc ' mkdep -f .depend -a-DRESCUE -std=gnu99   
 /src/sbin/swapon/swapon.c
 echo swapon: /obj/ia64.ia64/src/tmp/usr/lib/libc.a 
 /obj/ia64.ia64/src/tmp/usr/lib/libutil.a  .depend
 cc  -O2 -pipe  -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall 
 -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
 -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
 -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
 -Wold-style-definition -Wno-pointer-sign -c /src/sbin/swapon/swapon.c
 cc1: warnings being treated as errors
 /src/sbin/swapon/swapon.c: In function 'swap_on_off_geli':
 /src/sbin/swapon/swapon.c:394: warning: cast discards qualifiers from pointer 
 target type
 *** Error code 1

To my belief, it's wrong to use a const variable for strdup/free.

-- 
wbr,
pluknet
___
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: r251744: amd64/vmm/io/vlapic.c:468:15: error: implicit declaration of function 'cpusetobj_ffs' is invalid in C99

[Sergey Kandaurov]

On 14 June 2013 13:55, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 Kernel build fails on recent r251744 CURRENT:

 [...]
 --- vlapic.o ---
 /usr/src/sys/modules/vmm/../../amd64/vmm/io/vlapic.c:468:15: error:
 implicit declaration of function 'cpusetobj_ffs' is invalid in C99
 [-Werror,-Wimplicit-function-declaration] while ((i =
 cpusetobj_ffs(dmask)) != 0) { ^ 1 error generated.
 *** [vlapic.o] Error code 1

It should be fixed in r251745.

-- 
wbr,
pluknet
___
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

Typo in PCI-E Bus Speed measure unit

[Sergey Kandaurov]

Hi.

I'd like to commit this patch.
PCI-E Bus Speed is measured in GT/s (transfers per sec).

Index: sys/dev/ixgbe/ixgbe.c
===
--- sys/dev/ixgbe/ixgbe.c   (revision 250717)
+++ sys/dev/ixgbe/ixgbe.c   (working copy)
@@ -579,8 +579,8 @@
 /* Print PCIE bus type/speed/width info */
ixgbe_get_bus_info(hw);
device_printf(dev,PCI Express Bus: Speed %s %s\n,
-   ((hw-bus.speed == ixgbe_bus_speed_5000) ? 5.0Gb/s:
-   (hw-bus.speed == ixgbe_bus_speed_2500) ? 2.5Gb/s:Unknown),
+   ((hw-bus.speed == ixgbe_bus_speed_5000) ? 5.0GT/s:
+   (hw-bus.speed == ixgbe_bus_speed_2500) ? 2.5GT/s:Unknown),
(hw-bus.width == ixgbe_bus_width_pcie_x8) ? Width x8 :
(hw-bus.width == ixgbe_bus_width_pcie_x4) ? Width x4 :
(hw-bus.width == ixgbe_bus_width_pcie_x1) ? Width x1 :

-- 
wbr,
pluknet
___
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] flex/lex updated to 2.5.37 (from flex.sourceforge.net)

[Sergey Kandaurov]

On 22 May 2013 00:03, Jung-uk Kim j...@freebsd.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Please note flex/lex was updated to 2.5.37 from flex.sourceforge.net and
 __FreeBSD_version was bumped to 133.

 FYI, I added couple of compatibility shims (just enough to build the
 previous source trees) but it is not 100% compatible with the old
 version.  OTOH, this version is far more popular and third-party
 sources often require this version.  Most importantly, NetBSD,
 DragonFly BSD, and Mac OS X already adopted it for the same reason.

It looks like it broke tinderbox. Note that it runs 8.3-PRERELEASE.
The list of broken targets matches those with gcc set as the default compiler.
Cut off from mips64 build:

=== sbin/hastctl (all)
[...]
cc  -O -pipe -G0  -I/src/sbin/hastctl/../hastd -DHAVE_CAPSICUM -DINET
-DINET6 -DYY_NO_UNPUT -DYY_NO_INPUT -DHAVE_CRYPTO -std=gnu99
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
-Wshadow -Wunused-parameter -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition
-Wno-pointer-sign -Wno-format -c token.c
cc1: warnings being treated as errors
stdout:753: warning: redundant redeclaration of 'yylex'
/src/sbin/hastctl/../hastd/hast.h:263: warning: previous declaration
of 'yylex' was here
*** Error code 1

http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full

-- 
wbr,
pluknet
___
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: problem building -current

[Sergey Kandaurov]

On 7 May 2013 17:21, Michael W. Lucas mwlu...@michaelwlucas.com wrote:

 Hi,

 I'm running an older -current:

 bewilderbeast/usr/src;uname -a
 FreeBSD bewilderbeast.blackhelicopters.org 10.0-CURRENT FreeBSD 10.0-CURRENT 
 #15: Thu Nov  8 14:02:45 EST 2012 
 mwlu...@bewilderbeast.blackhelicopters.org:/usr/obj/usr/src/sys/G

 Trying to build new, and get:

 ...
 c++  -O2 -pipe 
 -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include 
 -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include 
 -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. 
 -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
  -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
 -D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
 -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd10.0\ 
 -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ 
 -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c 
 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Process.cpp
  -o Process.o
 In file included from 
 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Process.cpp:85:
 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Unix/Process.inc:
  In member function 'virtual llvm::sys::TimeValue 
 llvm::sys::self_process::get_user_time() const':
 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Unix/Process.inc:75:
  error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in this scope
 *** [Process.o] Error code 1

You can try to install this change into your /usr/include/time.h and try again.
http://svnweb.freebsd.org/base?view=revisionrevision=245428

--- head/include/time.h 2013/01/14 17:41:04 245427
+++ head/include/time.h 2013/01/14 18:01:19 245428
@@ -112,6 +112,7 @@
 #define CLOCK_MONOTONIC_FAST   12  /* FreeBSD-specific. */
 #define CLOCK_SECOND   13  /* FreeBSD-specific. */
 #define CLOCK_THREAD_CPUTIME_ID14
+#defineCLOCK_PROCESS_CPUTIME_ID15
 #endif /* !defined(CLOCK_REALTIME)  __POSIX_VISIBLE = 200112 */

 #if !defined(TIMER_ABSTIME)  __POSIX_VISIBLE = 200112

-- 
wbr,
pluknet
___
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: mdoc warning: .Fx: Unknown FreeBSD version `10' (#181)

[Sergey Kandaurov]

On 17 March 2013 02:05, Andrey Fesenko f0and...@gmail.com wrote:
 On Sat, Mar 16, 2013 at 8:59 PM, deeptech71 deeptec...@gmail.com wrote:
 When running ``man script'' (world r248258), I get:

   mdoc warning: .Fx: Unknown FreeBSD version `10' (#181)

 (and the whole man page, which quickly hides the warning).

 reproduce

 # whereis man
 man: /usr/bin/man /usr/share/man/man1/man.1.gz /usr/src/usr.bin/man
 # uname -a
 FreeBSD x220.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248378: Sun
 Mar 17 00:11:12 MSK 2013
 andrey@x220.local:/usr/obj/usr/src/sys/W_BOOK  amd64

  % man script | head -1
 mdoc warning: .Fx: Unknown FreeBSD version `10' (#181)
 SCRIPT(1)   FreeBSD General Commands Manual  SCRIPT(1)

 not correct macros .Fx may be fix
  % diff script.1 script.1.orig
 181c181
  .Fx 10.0 .
 ---
 .Fx 10 .

Fix committed in r248388, thanks.

-- 
wbr,
pluknet
___
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: [patch] Proposal: move getmntopts(3) into libutil

[Sergey Kandaurov]

On 26 February 2013 16:20, Konstantin Belousov kostik...@gmail.com wrote:
 On Tue, Feb 26, 2013 at 02:39:26PM +0300, Sergey Kandaurov wrote:
 Hi.

 The functions from sbin/mount/getmntopts.c are used in a bunch of other
 stuff like mount_* utilities which have to suck them in as their own
 functions in quite a hackish way. getmntopts.c copies are compiled in to
 an every utility-consumer instead of being present in one place.  Looks
 like getmntopts.c was brought together with mount_ufs.c in 4.4BSD-Lite.
 After that other mount_* were converted to use getmntopts().
 Yes, this is ugly. On the other hand, compiling the functions into
 mount binaries makes them not to depend on the yet another library.
 It cannot be an argument for rejecting your patch, only a point to
 consider.

I'm afraid this is the price for the change. No better thoughts.

 The attached patch moves them to the IMHO architecturally more correct
 place: a separate library -lutil.
 sbin/mount/mntopts.h- include/mntopts.h
 I think the mntopts.h should be moved to lib/libutil then, and installed
 by libutil Makefile.

That's reasonable, thanks. Patch is updated with your correction.
I have put it on freefall for convenience.
http://people.freebsd.org/~pluknet/patches/getmntopts.2.patch


 sbin/mount/getmntopts.[3c]  - lib/libutil/getmntopts.[3c]
 I assume that the move is done by 'svn mv' to preserve the history.

Yes. Unfortunately svn stat cannot nicely represent 'svn mv' ops.

-- 
wbr,
pluknet
___
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: [patch] Proposal: move getmntopts(3) into libutil

[Sergey Kandaurov]

On 26 February 2013 23:11, Craig Rodrigues rodr...@crodrigues.org wrote:
 On Tue, Feb 26, 2013 at 3:39 AM, Sergey Kandaurov pluk...@gmail.com wrote:

 Hi.



 External mount-like utilities may also have difficulties with building
 to get getmntopts.c source as this requires /usr/src presence which is
 in sync with installed world. Look how mount_fusefs from ports compiles:
 # mount_fusefs needs mntopts.h and getmntopts.c from src/sbin/mount/


 I have no object in moving getmntopts.c to libutil.

 I'll give some history to some of this stuff, to the best of my ability.
 A few years ago, phk@ made a big change by introducing the nmount() system
 call to replace mount().
 Look at all mount-related commits around this time:
 http://lists.freebsd.org/pipermail/cvs-src/2004-December/author.html#36373

 This required changing every file system, and for old file systems which
 supported the classic mount cmount(),
 in each file system, the cmount() call had to internally call the nmount()
 code.

 In addition, phk made a pass to clean up all the userland mount programs to
 use nmount().  There was a lot
 of duplicated (copy and pasted) code in various mount programs.  I helped
 in the effort to clean up some of the userland mount() programs.

 pjd@ proposed to make the main /sbin/mount load a shared library for each
 specific file system,
 and each shared library would have file-system specific mount logic.  For
 example:

 mount -t newfoofs  /dev/blah /mnt

 would internally do something like:

 dlopen(libmount_newfoofs,.);


 phk@ opposed this approach, saying that it could lead to ABI/API problems,
 library mismatches, etc.
 So we kept the existing approach.  I modified /sbin/mount to by default use
 nmount() and only
 for certain file systems, exec an external mount program.

 phk's ideas for getmntopts.c was always to keep it as a place where
 library-like functions for mounting
 file systems would be kept.  To avoid library mismatch problems, it was kept
 has a C file directly compiled
 into the mount programs.

Sure, keeping it directly compiled has its own benefits.
Reading your mail is very educational, thank you.


 I have no problems keeping getmntopts.c in a separate library.  libutil is
 fine, or even a separate libmntutil (or whatever).
 Just keep in mind the issues that could possibly come up if there is a
 mismatch between
 the userland mount programs, and the library which contains getmntopts.c

 Other than that, you proposal is quite reasonable, and I have no issue with
 it.

Although libutil is already used with such binaries like mount and mountd,
library mismatch is a real concern. I will need to think somewhat more.
Thanks for looking at this.

-- 
wbr,
pluknet
___
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

[patch] Proposal: move getmntopts(3) into libutil

[Sergey Kandaurov]

Hi.

The functions from sbin/mount/getmntopts.c are used in a bunch of other
stuff like mount_* utilities which have to suck them in as their own
functions in quite a hackish way. getmntopts.c copies are compiled in to
an every utility-consumer instead of being present in one place.  Looks
like getmntopts.c was brought together with mount_ufs.c in 4.4BSD-Lite.
After that other mount_* were converted to use getmntopts().

The utilities consuming getmntopts.c as currently present in HEAD:
mount_smbfs
fsck_ffs
growfs
mksnap_ffs
mount
mount_cd9660
mount_ext2fs
mount_fusefs
mount_hpfs
mount_msdosfs
mount_nfs
mount_nullfs
mount_reiserfs
mount_std
mount_udf
mount_unionfs
mount_nwfs
mount_portalfs
mount_smbfs
mountd

External mount-like utilities may also have difficulties with building
to get getmntopts.c source as this requires /usr/src presence which is
in sync with installed world. Look how mount_fusefs from ports compiles:
# mount_fusefs needs mntopts.h and getmntopts.c from src/sbin/mount/

The attached patch moves them to the IMHO architecturally more correct
place: a separate library -lutil.
sbin/mount/mntopts.h- include/mntopts.h
sbin/mount/getmntopts.[3c]  - lib/libutil/getmntopts.[3c]

The full list of functions in getmntopts.c:
getmntopts()
rmslashes()
checkpath()
build_iovec()
build_iovec_argf()

This will eventually give them public and documented status. It will
also bring back to live its semi-dead man page getmntopts(3) currently
disconnected from build, that will force us to update (and use) it which
is also a goody. getmntopts.3 was never installed.

As a bonus, it will bring us in sync with others BSDs.

The attached patch was buildworld-tested and contains only minimal changes;
getmntopts(3) updates and other improvements could be made separately.
- rearrange files from sbin/mount/ to the new place
- update Makefiles's of mount_* to use getmntopts(3) from libutil
- #include mntopts.h - #include mntopts.h

Well, the include changes should be safe to commit as is.

Below is a changelist from svn stat, for convenience 'sake.
M   contrib/smbfs/mount_smbfs/mount_smbfs.c
M   include/Makefile
A  +include/mntopts.h
M   lib/libutil/Makefile
A  +lib/libutil/getmntopts.3
A  +lib/libutil/getmntopts.c
M   sbin/fsck_ffs/Makefile
M   sbin/growfs/Makefile
M   sbin/mksnap_ffs/Makefile
M   sbin/mount/Makefile
D   sbin/mount/getmntopts.3
D   sbin/mount/getmntopts.c
D   sbin/mount/mntopts.h
M   sbin/mount/mount.c
M   sbin/mount/mount_fs.c
M   sbin/mount_cd9660/Makefile
M   sbin/mount_cd9660/mount_cd9660.c
M   sbin/mount_ext2fs/Makefile
M   sbin/mount_ext2fs/mount_ext2fs.c
M   sbin/mount_fusefs/Makefile
M   sbin/mount_fusefs/mount_fusefs.c
M   sbin/mount_hpfs/Makefile
M   sbin/mount_hpfs/mount_hpfs.c
M   sbin/mount_msdosfs/Makefile
M   sbin/mount_msdosfs/mount_msdosfs.c
M   sbin/mount_nfs/Makefile
M   sbin/mount_nfs/mount_nfs.c
M   sbin/mount_ntfs/Makefile
M   sbin/mount_ntfs/mount_ntfs.c
M   sbin/mount_nullfs/Makefile
M   sbin/mount_nullfs/mount_nullfs.c
M   sbin/mount_reiserfs/Makefile
M   sbin/mount_reiserfs/mount_reiserfs.c
M   sbin/mount_std/Makefile
M   sbin/mount_std/mount_std.c
M   sbin/mount_udf/Makefile
M   sbin/mount_udf/mount_udf.c
M   sbin/mount_unionfs/Makefile
M   sbin/mount_unionfs/mount_unionfs.c
M   usr.sbin/mount_nwfs/Makefile
M   usr.sbin/mount_nwfs/mount_nwfs.c
M   usr.sbin/mount_portalfs/Makefile
M   usr.sbin/mount_portalfs/mount_portalfs.c
M   usr.sbin/mount_smbfs/Makefile
M   usr.sbin/mountd/Makefile
M   usr.sbin/mountd/mountd.c

-- 
wbr,
pluknet


getmntopts.patch
Description: Binary data
___
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: [PATCH] Fix sbin/fsdb/fsdbutil.c for r247212

[Sergey Kandaurov]

On 24 February 2013 19:25, David Wolfskill da...@catwhisker.org wrote:
 On Sun, Feb 24, 2013 at 07:05:34AM -0800, David Wolfskill wrote:
 ...hine was:
 Simple patch attached; world is still building, but at least it got
 through the make dependencies phase this time.
 ...

 That was incomplete, as it didn't (also) address the change to
 getdatablk().

 The attached patch actually made it through buildworld.

 Note that it is entirely possible that I erred in specifying
 BT_UNKNOWN for the additional type argument.

Hi David.

Thank you for the proposed fix. I committed it with r247234.
I'm not sure regarding BT_UNKNOWN value either. Well..  at least
it should be not worse that it is now, and it should fix the build.
I have not found any (regressive) changes in fsdb -d `blocks' output.

-- 
wbr,
pluknet
___
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: r247095 Boot Failure

[Sergey Kandaurov]

On 21 February 2013 19:38, matt sendtom...@gmail.com wrote:
 On Thu, Feb 21, 2013 at 3:34 PM, Navdeep Parhar npar...@gmail.com wrote:


 Take a look at the -CURRENT userland regression thread.  You may be
 able to boot if you choose safe mode in the boot loader menu.

 Regards,
 Navdeep


 What is safe mode as far as boot flags?


Currently that corresponds to:
set kern.smp.disabled=1
set hw.ata.ata_dma=0
set hw.ata.atapi_dma=0
set hw.ata.wc=0
set hw.eisa_slots=0
set kern.eventtimer.periodic=1
set kern.geom.part.check_integrity=0

See /boot/menu-commands.4th

-- 
wbr,
pluknet
___
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

[patch] remove negative socklen_t checks

[Sergey Kandaurov]

Hi.

These checks are useless after the address length argument is converted
to socklen_t (up to SUSv2). Any objections?

Index: lib/libc/sys/accept.2
===
--- lib/libc/sys/accept.2   (revision 245745)
+++ lib/libc/sys/accept.2   (working copy)
@@ -28,7 +28,7 @@
 .\ @(#)accept.2   8.2 (Berkeley) 12/11/93
 .\ $FreeBSD$
 .\
-.Dd December 11, 1993
+.Dd February 20, 2013
 .Dt ACCEPT 2
 .Os
 .Sh NAME
@@ -154,10 +154,6 @@ The descriptor references a file, not a socket.
 .It Bq Er EINVAL
 .Xr listen 2
 has not been called on the socket descriptor.
-.It Bq Er EINVAL
-The
-.Fa addrlen
-argument is negative.
 .It Bq Er EFAULT
 The
 .Fa addr
Index: sys/kern/uipc_syscalls.c
===
--- sys/kern/uipc_syscalls.c(revision 246354)
+++ sys/kern/uipc_syscalls.c(working copy)
@@ -353,8 +353,6 @@ kern_accept(struct thread *td, int s, struct socka

if (name) {
*name = NULL;
-   if (*namelen  0)
-   return (EINVAL);
}

AUDIT_ARG_FD(s);
@@ -1327,8 +1325,6 @@ kern_setsockopt(td, s, level, name, val, valseg, v

if (val == NULL  valsize != 0)
return (EFAULT);
-   if ((int)valsize  0)
-   return (EINVAL);

sopt.sopt_dir = SOPT_SET;
sopt.sopt_level = level;
@@ -1406,8 +1402,6 @@ kern_getsockopt(td, s, level, name, val, valseg, v

if (val == NULL)
*valsize = 0;
-   if ((int)*valsize  0)
-   return (EINVAL);

sopt.sopt_dir = SOPT_GET;
sopt.sopt_level = level;
@@ -1484,9 +1478,6 @@ kern_getsockname(struct thread *td, int fd, struct
socklen_t len;
int error;

-   if (*alen  0)
-   return (EINVAL);
-
AUDIT_ARG_FD(fd);
error = getsock_cap(td-td_proc-p_fd, fd, CAP_GETSOCKNAME, fp, NULL);
if (error)
@@ -1584,9 +1575,6 @@ kern_getpeername(struct thread *td, int fd, struct
socklen_t len;
int error;

-   if (*alen  0)
-   return (EINVAL);
-
AUDIT_ARG_FD(fd);
error = getsock_cap(td-td_proc-p_fd, fd, CAP_GETPEERNAME, fp, NULL);
if (error)

-- 
wbr,
pluknet
___
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: [patch] remove negative socklen_t checks

[Sergey Kandaurov]

On 20 February 2013 22:42, Xin Li delp...@delphij.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 02/20/13 09:19, Sergey Kandaurov wrote:
 Hi.

 These checks are useless after the address length argument is
 converted to socklen_t (up to SUSv2). Any objections?

 No objection in general but there is a minor style issue, see below.

 [...]
 Index: sys/kern/uipc_syscalls.c
 ===


 - --- sys/kern/uipc_syscalls.c(revision 246354)
 +++ sys/kern/uipc_syscalls.c(working copy) @@ -353,8 +353,6 @@
 kern_accept(struct thread *td, int s, struct socka

 if (name) { *name = NULL; -   if (*namelen  0) -
 return (EINVAL); }

 The { } for if () is no longer needed now per style(9).

Indeed, thanks.


 By the way I wonder why there is no compiler warning for this -- or do
 we compile kernel without signedness warnings?  Just curious...

No, they are (at least with clang). That's how I came there.

cc -c -O2 -pipe -fno-strict-aliasing  -std=c99 -g -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
-fdiagnostics-show-option  -Wno-error-tautological-compare
-Wno-error-empty-body  -Wno-error-parentheses-equality -nostdinc  -I.
-I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-Werror  /usr/src/sys/kern/uipc_syscalls.c
/usr/src/sys/kern/uipc_syscalls.c:356:16: warning: comparison of
unsigned expression  0 is always false [-Wtautological-compare]
if (*namelen  0)
 ^ ~
/usr/src/sys/kern/uipc_syscalls.c:1487:12: warning: comparison of
unsigned expression  0 is always false [-Wtautological-compare]
if (*alen  0)
~ ^ ~
/usr/src/sys/kern/uipc_syscalls.c:1587:12: warning: comparison of
unsigned expression  0 is always false [-Wtautological-compare]
if (*alen  0)
~ ^ ~

Other two warnings are obviously not triggered because of explicit
cast to int (eek!).
Thanks for review.

-- 
wbr,
pluknet
___
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: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

On 7 February 2013 17:43, Andriy Gapon a...@freebsd.org wrote:
 on 07/02/2013 04:13 Rick Macklem said the following:
 Andriy Gapon wrote:
 on 06/02/2013 17:15 Rick Macklem said the following:
 Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
 knows to
 switch over to using VOP_LOOKUP(). If the .zfs/snapshot and
 .zfs/share
 do the same thing, that should be fine, at least for the NFS server,
 I think.

 Ah, right, but again this is done only for .zfs and .zfs/snapshot.
 .zfs/shares is not special-cased and thus is problematic here too in
 the same
 fashion as zfs_fhtovp.

 Well, I have no way to test this, but maybe the attached patch is a
 start in the right direction.

 Maybe you can take a look at it and/or Sergey could test it?

 Thanks for all your help with this, rick

 Rick,
 the patch looks 99% percent good to me :-)
 I am not sure if I am overly paranoid here, but I would add a check for
 zfsvfs-z_shares_dir being non-zero before comparing anything with it.
 I am also not sure if doing actual zfs_zget only to check zp_gen != fid_gen or
 z_unlinked is required.  Probably not.

 Sergey,
 could you please test Rick's patch?

Hi Rick, Andriy.

I tested the patch without the (*vpp != dvp) change.
It works well.

It's something unrelated but when doing ls -l
on server (patched) and client (unpatched) sides,
I found some inconsistency in returned stats.
Or more precisely:

NFS server
# stat -s /pool1/user1000/.zfs/shares/..
st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 st_gid=0
st_rdev=0 st_size=4 st_atime=1360251211 st_mtime=1359551493
st_ctime=1359551493 st_birthtime=1359551493 st_blksize=4096
st_blocks=0 st_flags=0

NFS client
# stat -s /home/user1000/.zfs/shares/..
st_dev=2050684725 st_ino=7 st_mode=040555 st_nlink=2 st_uid=0 st_gid=0
st_rdev=1377468712 st_size=2 st_atime=1360251104 st_mtime=1359551493
st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=3
st_flags=0

JFYI.

-- 
wbr,
pluknet
___
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: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

On 7 February 2013 19:42, Andriy Gapon a...@freebsd.org wrote:
 on 07/02/2013 17:36 Sergey Kandaurov said the following:
 I tested the patch without the (*vpp != dvp) change.
 It works well.

 It's something unrelated but when doing ls -l
 on server (patched) and client (unpatched) sides,
 I found some inconsistency in returned stats.
 Or more precisely:

 NFS server
 # stat -s /pool1/user1000/.zfs/shares/..
 st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 st_gid=0
 st_rdev=0 st_size=4 st_atime=1360251211 st_mtime=1359551493
 st_ctime=1359551493 st_birthtime=1359551493 st_blksize=4096
 st_blocks=0 st_flags=0

 NFS client
 # stat -s /home/user1000/.zfs/shares/..
 st_dev=2050684725 st_ino=7 st_mode=040555 st_nlink=2 st_uid=0 st_gid=0
 st_rdev=1377468712 st_size=2 st_atime=1360251104 st_mtime=1359551493
 st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=3
 st_flags=0

 Hmm, this looks more consistent with the earlier patch.
 Are you sure that you really tested the new kernel (on the server)?

Sorry, I indeed booted a wrong kernel.
Now tested the really new kernel :) And it works as well.
stat -s looks consistent, thanks.

# stat -s /home/user1000/.zfs/shares/..
st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 st_gid=0
st_rdev=0 st_size=4 st_atime=1360252962 st_mtime=1359551493
st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=0
st_flags=0

-- 
wbr,
pluknet
___
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: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

On 4 February 2013 05:07, Rick Macklem rmack...@uoguelph.ca wrote:
 Andriy Gapon wrote:
 on 03/02/2013 18:36 Rick Macklem said the following:
  I can think of two possibilities:
  1 - ZFS isn't setting VV_ROOT on the root vnode under some
  condition.
  or
  2 - The vnode was left locked from some previous operation that
  happened
  to be done by this thread. Doesn't seem likely, but???
 
  Maybe Sergey could try the change to line#1451 and see if the panic
  still happens. If not, that would suggest possibility #1, I think.

 If the kernel is configured with witness, then it should be easy to
 check where
 the exclusive lock was taken (file and line number).

 Yep. If Sergey can reproduce this using a kernel with witness,
 doing show witness to see where the lock on the directory vnode
 was acquired, could be helpful.

Hi, Rick! Here is the requested info regarding witness, and a bit more.
The triggered KASSERT is now different though.

Full witness is at http://people.freebsd.org/~pluknet/witness-zfs-20130204.txt

shared lock of (lockmgr) zfs @
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452
while exclusively locked from
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747
panic: share-excl
cpuid = 2
KDB: enter: panic
[ thread pid 812 tid 100884 ]
Stopped at  kdb_enter+0x3e: movq$0,kdb_why

The 1st line is at zfs_lookup():
if (error == 0  (nm[0] != '.' || nm[1] != '\0')) {
int ltype = 0;

if (cnp-cn_flags  ISDOTDOT) {
ltype = VOP_ISLOCKED(dvp);
VOP_UNLOCK(dvp, 0);
}
ZFS_EXIT(zfsvfs);
error = zfs_vnode_lock(*vpp, cnp-cn_lkflags);
if (cnp-cn_flags  ISDOTDOT)
== vn_lock(dvp, ltype | LK_RETRY);
if (error != 0) {
VN_RELE(*vpp);
*vpp = NULL;
return (error);
}
} else {
ZFS_EXIT(zfsvfs);
}

The 2nd line is at zfs_vnode_lock():
int
zfs_vnode_lock(vnode_t *vp, int flags)
{
int error;

ASSERT(vp != NULL);

error = vn_lock(vp, flags);
return (error);
}

db show locks
exclusive lockmgr zfs (zfs) r = 0 (0xfe00a1b44240) locked @
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747
db show alllocks
Process 812 (nfsd) thread 0xfe00a1198000 (100884)
exclusive lockmgr zfs (zfs) r = 0 (0xfe00a1b44240) locked @
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747
Process 750 (syslogd) thread 0xfe0015a4c480 (100706)
exclusive lockmgr ufs (ufs) r = 0 (0xfe00a1962d50) locked @
/usr/src/sys/kern/vfs_syscalls.c:3433
Process 12 (intr) thread 0xfe0006813000 (100033)
exclusive sleep mutex AAC I/O lock (AAC I/O lock) r = 0
(0xff8001bfb210) locked @ /usr/src/sys/dev/aac/aac.c:827

db show lock 0xfe00a1b44240
 class: lockmgr
 name: zfs
 state: XLOCK: 0xfe00a1198000 (tid 100884, pid 812, nfsd)
 waiters: none
 spinners: none

As KASSERT is different:

db bt
Tracing pid 812 tid 100884 td 0xfe00a1198000
kdb_enter() at kdb_enter+0x3e/frame 0xff848e6bfd60
vpanic() at vpanic+0x147/frame 0xff848e6bfda0
kassert_panic() at kassert_panic+0x136/frame 0xff848e6bfe10
witness_checkorder() at witness_checkorder+0x289/frame 0xff848e6bfe90
__lockmgr_args() at __lockmgr_args+0x43e/frame 0xff848e6bffc0
vop_stdlock() at vop_stdlock+0x3c/frame 0xff848e6bffe0
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xff848e6c
_vn_lock() at _vn_lock+0xab/frame 0xff848e6c0070
zfs_lookup() at zfs_lookup+0x392/frame 0xff848e6c0100
zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame 0xff848e6c0240
VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame 0xff848e6c0260
vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xff848e6c02b0
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xff848e6c02d0
lookup() at lookup+0x548/frame 0xff848e6c0350
nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xff848e6c0400
nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xff848e6c06b0
nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xff848e6c08a0
nfssvc_program() at nfssvc_program+0x482/frame 0xff848e6c0a00
svc_run_internal() at svc_run_internal+0x1e9/frame 0xff848e6c0ba0
svc_thread_start() at svc_thread_start+0xb/frame 0xff848e6c0bb0
fork_exit() at fork_exit+0x84/frame 0xff848e6c0bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xff848e6c0bf0
--- trap 0xc, rip = 0x800883b7a, rsp = 0x7fffd6c8, rbp = 0x7fffd970 ---

-- 
wbr,
pluknet
___
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: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

On 4 February 2013 05:50, Rick Macklem rmack...@uoguelph.ca wrote:
 Konstantin Belousov wrote:
 On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote:
  Andriy Gapon wrote:
   on 31/01/2013 15:29 Sergey Kandaurov said the following:
Hi.
   
Got this assertion on idle NFS server while `ls -la
/.zfs/shares/'
issued on NFS client.
kern/vfs_vnops.c:_vn_lock()
KASSERT((flags  LK_RETRY) == 0 || error == 0,
(LK_RETRY set with incompatible flags
(0x%x) or
an error occured (%d),
   
panic: LK_RETRY set with incompatible flags (0x200400) or an
error
occured (11)
   
What does that mean and how is it possible? As you can see, both
parts
of assertion failed.
11 is EDEADLK
0x200400: LK_RETRY  LK_UPGRADE
  
   LK_SHARED, not LK_UPGRADE.
   Apparently the thread already holds an exlusive lock on the vnode,
   which you
   confirm below.
  
  
Tracing pid 2943 tid 101532 td 0xfe004f5b7000
kdb_enter() at kdb_enter+0x3e/frame 0xff848e45ef50
vpanic() at vpanic+0x147/frame 0xff848e45ef90
kassert_panic() at kassert_panic+0x136/frame 0xff848e45f000
_vn_lock() at _vn_lock+0x70/frame 0xff848e45f070
zfs_lookup() at zfs_lookup+0x392/frame 0xff848e45f100
zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame
0xff848e45f240
VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame
0xff848e45f260
vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame
0xff848e45f2b0
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xff848e45f2d0
lookup() at lookup+0x548/frame 0xff848e45f350
nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xff848e45f400
nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xff848e45f6b0
nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xff848e45f8a0
nfssvc_program() at nfssvc_program+0x482/frame
0xff848e45fa00
svc_run_internal() at svc_run_internal+0x1e9/frame
0xff848e45fba0
svc_thread_start() at svc_thread_start+0xb/frame
0xff848e45fbb0
fork_exit() at fork_exit+0x84/frame 0xff848e45fbf0
fork_trampoline() at fork_trampoline+0xe/frame
0xff848e45fbf0
--- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffd488, rbp =
0x7fffd730 ---
   
db show lockedvnods
Locked vnodes
   
0xfe02e21b11d8: tag zfs, type VDIR
usecount 4, writecount 0, refcount 4 mountedhere 0
flags (VI_ACTIVE)
v_object 0xfe02d9f2eb40 ref 0 pages 0
lock type zfs: EXCL by thread 0xfe004f5b7000 (pid 2943,
nfsd,
tid 101532)
   
   
   
  I just took a look at zfs_vnops.c and I am probably missing
  something,
  but I can't see how this ever worked for a lookup of .. when at
  the
  root (unless ZFS doesn't do the .. is the current directory when
  at
  the root).
 
  Here's the code snippet:
  1442 if (error == 0  (nm[0] != '.' || nm[1] != '\0')) {
  1443 int ltype = 0;
  1444
  1445 if (cnp-cn_flags  ISDOTDOT) {
  1446   ltype = VOP_ISLOCKED(dvp);
  1447   VOP_UNLOCK(dvp, 0);
  1448 }
  1449 ZFS_EXIT(zfsvfs);
  1450 error = zfs_vnode_lock(*vpp, cnp-cn_lkflags);
  1451 if (cnp-cn_flags  ISDOTDOT)
  1452   vn_lock(dvp, ltype | LK_RETRY);
  1453 if (error != 0) {
  1454   VN_RELE(*vpp);
  1455   *vpp = NULL;
  1456   return (error);
  1457 }
 
  Maybe line# 1451 should be changed to:
  if ((cnp-cn_flags  ISDOTDOT)  *vpp != dvp)
 
  I'm not at all familiar with ZFS, so I've probably way
  off the mark on this, rick
  ps: I hope kib and jhb don't mind being added as cc's, since
  they are familiar with this stuff, although maybe not ZFS
  specifics.

 VFS (should) never call VOP_LOOKUP for the dotdot and root vnode.
 The logic in the lookup() prevents it.

 Correcting my previous posts, like usual. If you look at the above snippet of
 code, it seems that zfs_lock_vnode() must lock the same vnode as
 *dvp. Notice that vn_lock() is only called when ISDOTDOT is set and the
 code does a VOP_UNLOCK(dvp, 0); for this case, just before the
 zfs_vnode_lock().

 This assumes that the vn_lock() call at #1452 causes the panic.
 This is the only vn_lock() call in zfs_lookup(), so unless the compiler
 has done something weird, it seems the case.

 Sergey, do you have this kernel handy? If so, maybe you could check the
 line# for zfs_lookup+0x392. (If you haven't done this before, just email
 and I'll give you the steps. You just need the kernel.symbols file for
 the kernel that panic'd.)

Yep, kgdb returned zfs_vnops.c:1453.


-- 
wbr,
pluknet
___
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: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

On 4 February 2013 16:06, Andriy Gapon a...@freebsd.org wrote:
 on 04/02/2013 13:49 Sergey Kandaurov said the following:
 Hi, Rick! Here is the requested info regarding witness, and a bit more.
 The triggered KASSERT is now different though.

 It's exactly the same problem though :-)
 Do you have a crashdump?
 If yes, please print **vpp.

Yep, but it's in a bad form :(
It has many bits optimized out (compiled with clang).
I'll rebuild the kernel with -O or so and will try again.

#8  0x808bc4ce in kdb_enter (why=0x80e7ed99 panic,
msg=value optimized out) at cpufunc.h:63
#9  0x80888fb7 in vpanic (fmt=value optimized out,
ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746
#10 0x80888e66 in kassert_panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:641
#11 0x808d2259 in witness_checkorder (lock=0xfe00a1b44240,
---Type return to continue, or q return to quit---
flags=1,
file=0x81b2bb36
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
line=1452,
interlock=value optimized out) at /usr/src/sys/kern/subr_witness.c:1122
#12 0x8086c11e in __lockmgr_args (lk=0xfe00a1b44240,
flags=value optimized out, ilk=0xfe00a1b44270,
wmesg=0x81b2808d zfs, pri=96, timo=51,
file=0x80e8e407 /usr/src/sys/kern/vfs_default.c, line=0)
at /usr/src/sys/kern/kern_lock.c:511
#13 0x8091439c in vop_stdlock (ap=value optimized out)
at lockmgr.h:97
#14 0x80cb70c0 in VOP_LOCK1_APV (vop=value optimized out,
a=value optimized out) at vnode_if.c:2022
#15 0x80932fbb in _vn_lock (vp=0xfe00a1b441d8,
flags=value optimized out,
file=0x81b2bb36
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
line=1452) at vnode_if.h:859
#16 0x81abd902 in zfs_lookup ()
at 
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452
#17 0x81abdc1d in zfs_freebsd_lookup (ap=0xff848e6c0270)
at 
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864
---Type return to continue, or q return to quit---
#18 0x80cb51b2 in VOP_CACHEDLOOKUP_APV (vop=value optimized out,
a=value optimized out) at vnode_if.c:191
#19 0x8091177f in vfs_cache_lookup (ap=value optimized out)
at vnode_if.h:80
#20 0x80cb50a2 in VOP_LOOKUP_APV (vop=value optimized out,
a=value optimized out) at vnode_if.c:125
#21 0x80919658 in lookup (ndp=0xff848e6c05d8) at vnode_if.h:54
#22 0x807dffe5 in nfsvno_namei (nd=0xff848e6c08c8,
ndp=0xff848e6c05d8, dp=value optimized out,
islocked=value optimized out, exp=value optimized out,
p=value optimized out, retdirp=value optimized out)
at /usr/src/sys/fs/nfsserver/nfs_nfsdport.c:413
#23 0x807d8ffa in nfsrvd_lookup (nd=0xff848e6c08c8,
isdgram=value optimized out, dp=0xfe00a1b441d8,
vpp=0xff848e6c0810, fhp=0xff848e6c07f4, p=0xfe00a1198000,
exp=0xff848e6c07a0) at /usr/src/sys/fs/nfsserver/nfs_nfsdserv.c:517
#24 0x807cb845 in nfsrvd_dorpc (nd=0xff848e6c08c8, isdgram=0,
p=0xfe00a1198000) at /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:823
#25 0x807d7af2 in nfssvc_program (rqst=0xfe00a17bb000,
xprt=0xfe00a124b200) at /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:347
#26 0x80a70659 in svc_run_internal (pool=0xfe00067db600,
ismaster=0) at /usr/src/sys/rpc/svc.c:895
#27 0x80a7155b in svc_thread_start (arg=0xff848e6bfc50)
---Type return to continue, or q return to quit---
at /usr/src/sys/rpc/svc.c:1200
#28 0x80858944 in fork_exit (
callout=0x80a71550 svc_thread_start, arg=0xfe00067db600,
frame=0xff848e6c0c00) at /usr/src/sys/kern/kern_fork.c:991
#29 0x80bfa86e in fork_trampoline () at exception.S:602
#30 0x0080 in ?? ()
#31 0x7fffd820 in ?? ()
#32 0x0001 in ?? ()
#33 0x in ?? ()
Current language:  auto; currently minimal

(kgdb) p vpp
Cannot access memory at address 0x0
(kgdb) p dvp
Cannot access memory at address 0x0



 Full witness is at 
 http://people.freebsd.org/~pluknet/witness-zfs-20130204.txt

 shared lock of (lockmgr) zfs @
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452
 while exclusively locked from
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1747
 panic: share-excl
 cpuid = 2
 KDB: enter: panic
 [ thread pid 812 tid 100884 ]
 Stopped at  kdb_enter+0x3e: movq$0,kdb_why

 The 1st line is at zfs_lookup():
 if (error == 0  (nm[0] != '.' || nm[1] != '\0')) {
 int ltype = 0;

 if (cnp-cn_flags  ISDOTDOT) {
 ltype = VOP_ISLOCKED(dvp);
 VOP_UNLOCK(dvp, 0

Re: panic: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

On 4 February 2013 16:13, Sergey Kandaurov pluk...@gmail.com wrote:
 On 4 February 2013 16:06, Andriy Gapon a...@freebsd.org wrote:
 on 04/02/2013 13:49 Sergey Kandaurov said the following:
 Hi, Rick! Here is the requested info regarding witness, and a bit more.
 The triggered KASSERT is now different though.

 It's exactly the same problem though :-)
 Do you have a crashdump?
 If yes, please print **vpp.

 Yep, but it's in a bad form :(
 It has many bits optimized out (compiled with clang).
 I'll rebuild the kernel with -O or so and will try again.

 #8  0x808bc4ce in kdb_enter (why=0x80e7ed99 panic,
 msg=value optimized out) at cpufunc.h:63
 #9  0x80888fb7 in vpanic (fmt=value optimized out,
 ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746
 #10 0x80888e66 in kassert_panic (fmt=value optimized out)
 at /usr/src/sys/kern/kern_shutdown.c:641
 #11 0x808d2259 in witness_checkorder (lock=0xfe00a1b44240,
 ---Type return to continue, or q return to quit---
 flags=1,
 file=0x81b2bb36
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
 line=1452,
 interlock=value optimized out) at /usr/src/sys/kern/subr_witness.c:1122
 #12 0x8086c11e in __lockmgr_args (lk=0xfe00a1b44240,
 flags=value optimized out, ilk=0xfe00a1b44270,
 wmesg=0x81b2808d zfs, pri=96, timo=51,
 file=0x80e8e407 /usr/src/sys/kern/vfs_default.c, line=0)
 at /usr/src/sys/kern/kern_lock.c:511
 #13 0x8091439c in vop_stdlock (ap=value optimized out)
 at lockmgr.h:97
 #14 0x80cb70c0 in VOP_LOCK1_APV (vop=value optimized out,
 a=value optimized out) at vnode_if.c:2022
 #15 0x80932fbb in _vn_lock (vp=0xfe00a1b441d8,
 flags=value optimized out,
 file=0x81b2bb36
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
 line=1452) at vnode_if.h:859
 #16 0x81abd902 in zfs_lookup ()
 at 
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452
 #17 0x81abdc1d in zfs_freebsd_lookup (ap=0xff848e6c0270)
 at 
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864
 ---Type return to continue, or q return to quit---
 #18 0x80cb51b2 in VOP_CACHEDLOOKUP_APV (vop=value optimized out,
 a=value optimized out) at vnode_if.c:191
 #19 0x8091177f in vfs_cache_lookup (ap=value optimized out)
 at vnode_if.h:80
 #20 0x80cb50a2 in VOP_LOOKUP_APV (vop=value optimized out,
 a=value optimized out) at vnode_if.c:125
 #21 0x80919658 in lookup (ndp=0xff848e6c05d8) at vnode_if.h:54
 #22 0x807dffe5 in nfsvno_namei (nd=0xff848e6c08c8,
 ndp=0xff848e6c05d8, dp=value optimized out,
 islocked=value optimized out, exp=value optimized out,
 p=value optimized out, retdirp=value optimized out)
 at /usr/src/sys/fs/nfsserver/nfs_nfsdport.c:413
 #23 0x807d8ffa in nfsrvd_lookup (nd=0xff848e6c08c8,
 isdgram=value optimized out, dp=0xfe00a1b441d8,
 vpp=0xff848e6c0810, fhp=0xff848e6c07f4, p=0xfe00a1198000,
 exp=0xff848e6c07a0) at /usr/src/sys/fs/nfsserver/nfs_nfsdserv.c:517
 #24 0x807cb845 in nfsrvd_dorpc (nd=0xff848e6c08c8, isdgram=0,
 p=0xfe00a1198000) at /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:823
 #25 0x807d7af2 in nfssvc_program (rqst=0xfe00a17bb000,
 xprt=0xfe00a124b200) at /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:347
 #26 0x80a70659 in svc_run_internal (pool=0xfe00067db600,
 ismaster=0) at /usr/src/sys/rpc/svc.c:895
 #27 0x80a7155b in svc_thread_start (arg=0xff848e6bfc50)
 ---Type return to continue, or q return to quit---
 at /usr/src/sys/rpc/svc.c:1200
 #28 0x80858944 in fork_exit (
 callout=0x80a71550 svc_thread_start, arg=0xfe00067db600,
 frame=0xff848e6c0c00) at /usr/src/sys/kern/kern_fork.c:991
 #29 0x80bfa86e in fork_trampoline () at exception.S:602
 #30 0x0080 in ?? ()
 #31 0x7fffd820 in ?? ()
 #32 0x0001 in ?? ()
 #33 0x in ?? ()
 Current language:  auto; currently minimal

 (kgdb) p vpp
 Cannot access memory at address 0x0
 (kgdb) p dvp
 Cannot access memory at address 0x0


That was from f 16. And as Andriy suggested in private (thanks Andriy!)
those pointers could be reached from ap in f 17.
On the other hand, zfs_lookup() is large, and *vpp might be
rewritten several times there. Here it is:

(kgdb) f 17
#17 0x81abdc1d in zfs_freebsd_lookup (ap=0xff848e6c0270)
at 
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864
5864return (zfs_lookup(ap-a_dvp, nm, ap-a_vpp, cnp,
cnp-cn_nameiop,
(kgdb) p ap-a_vpp
$4 = (struct vnode **) 0xff848e6c0618
(kgdb) p *ap-a_vpp
$5 = (struct vnode

Re: panic: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

On 4 February 2013 16:30, Sergey Kandaurov pluk...@gmail.com wrote:
 On 4 February 2013 16:13, Sergey Kandaurov pluk...@gmail.com wrote:
 On 4 February 2013 16:06, Andriy Gapon a...@freebsd.org wrote:
 on 04/02/2013 13:49 Sergey Kandaurov said the following:
 Hi, Rick! Here is the requested info regarding witness, and a bit more.
 The triggered KASSERT is now different though.

 It's exactly the same problem though :-)
 Do you have a crashdump?
 If yes, please print **vpp.

 Yep, but it's in a bad form :(
 It has many bits optimized out (compiled with clang).
 I'll rebuild the kernel with -O or so and will try again.

 #8  0x808bc4ce in kdb_enter (why=0x80e7ed99 panic,
 msg=value optimized out) at cpufunc.h:63
 #9  0x80888fb7 in vpanic (fmt=value optimized out,
 ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746
 #10 0x80888e66 in kassert_panic (fmt=value optimized out)
 at /usr/src/sys/kern/kern_shutdown.c:641
 #11 0x808d2259 in witness_checkorder (lock=0xfe00a1b44240,
 ---Type return to continue, or q return to quit---
 flags=1,
 file=0x81b2bb36
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
 line=1452,
 interlock=value optimized out) at /usr/src/sys/kern/subr_witness.c:1122
 #12 0x8086c11e in __lockmgr_args (lk=0xfe00a1b44240,
 flags=value optimized out, ilk=0xfe00a1b44270,
 wmesg=0x81b2808d zfs, pri=96, timo=51,
 file=0x80e8e407 /usr/src/sys/kern/vfs_default.c, line=0)
 at /usr/src/sys/kern/kern_lock.c:511
 #13 0x8091439c in vop_stdlock (ap=value optimized out)
 at lockmgr.h:97
 #14 0x80cb70c0 in VOP_LOCK1_APV (vop=value optimized out,
 a=value optimized out) at vnode_if.c:2022
 #15 0x80932fbb in _vn_lock (vp=0xfe00a1b441d8,
 flags=value optimized out,
 file=0x81b2bb36
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
 line=1452) at vnode_if.h:859
 #16 0x81abd902 in zfs_lookup ()
 at 
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1452
 #17 0x81abdc1d in zfs_freebsd_lookup (ap=0xff848e6c0270)
 at 
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864
 ---Type return to continue, or q return to quit---
 #18 0x80cb51b2 in VOP_CACHEDLOOKUP_APV (vop=value optimized out,
 a=value optimized out) at vnode_if.c:191
 #19 0x8091177f in vfs_cache_lookup (ap=value optimized out)
 at vnode_if.h:80
 #20 0x80cb50a2 in VOP_LOOKUP_APV (vop=value optimized out,
 a=value optimized out) at vnode_if.c:125
 #21 0x80919658 in lookup (ndp=0xff848e6c05d8) at vnode_if.h:54
 #22 0x807dffe5 in nfsvno_namei (nd=0xff848e6c08c8,
 ndp=0xff848e6c05d8, dp=value optimized out,
 islocked=value optimized out, exp=value optimized out,
 p=value optimized out, retdirp=value optimized out)
 at /usr/src/sys/fs/nfsserver/nfs_nfsdport.c:413
 #23 0x807d8ffa in nfsrvd_lookup (nd=0xff848e6c08c8,
 isdgram=value optimized out, dp=0xfe00a1b441d8,
 vpp=0xff848e6c0810, fhp=0xff848e6c07f4, p=0xfe00a1198000,
 exp=0xff848e6c07a0) at /usr/src/sys/fs/nfsserver/nfs_nfsdserv.c:517
 #24 0x807cb845 in nfsrvd_dorpc (nd=0xff848e6c08c8, isdgram=0,
 p=0xfe00a1198000) at /usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:823
 #25 0x807d7af2 in nfssvc_program (rqst=0xfe00a17bb000,
 xprt=0xfe00a124b200) at /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:347
 #26 0x80a70659 in svc_run_internal (pool=0xfe00067db600,
 ismaster=0) at /usr/src/sys/rpc/svc.c:895
 #27 0x80a7155b in svc_thread_start (arg=0xff848e6bfc50)
 ---Type return to continue, or q return to quit---
 at /usr/src/sys/rpc/svc.c:1200
 #28 0x80858944 in fork_exit (
 callout=0x80a71550 svc_thread_start, arg=0xfe00067db600,
 frame=0xff848e6c0c00) at /usr/src/sys/kern/kern_fork.c:991
 #29 0x80bfa86e in fork_trampoline () at exception.S:602
 #30 0x0080 in ?? ()
 #31 0x7fffd820 in ?? ()
 #32 0x0001 in ?? ()
 #33 0x in ?? ()
 Current language:  auto; currently minimal

 (kgdb) p vpp
 Cannot access memory at address 0x0
 (kgdb) p dvp
 Cannot access memory at address 0x0


 That was from f 16. And as Andriy suggested in private (thanks Andriy!)
 those pointers could be reached from ap in f 17.
 On the other hand, zfs_lookup() is large, and *vpp might be
 rewritten several times there. Here it is:

 (kgdb) f 17
 #17 0x81abdc1d in zfs_freebsd_lookup (ap=0xff848e6c0270)
 at 
 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5864
 5864return (zfs_lookup(ap-a_dvp, nm, ap-a_vpp, cnp,
 cnp-cn_nameiop,
 (kgdb) p ap-a_vpp
 $4

Re: panic: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

On 4 February 2013 06:32, Rick Macklem rmack...@uoguelph.ca wrote:
 Konstantin Belousov wrote:
 On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote:
  Andriy Gapon wrote:
   on 31/01/2013 15:29 Sergey Kandaurov said the following:
Hi.
   
Got this assertion on idle NFS server while `ls -la
/.zfs/shares/'
issued on NFS client.
 Ok, here's a snippet of zfs_dirlook() from zfs_dir.c:
 388 } else if (name[0] == '.'  name[1] == '.'  name[2] == 0) {
 389   zfsvfs_t *zfsvfs = dzp-z_zfsvfs;
 390
 391   /*
 392* If we are a snapshot mounted under .zfs, return
 393* the vp for the snapshot directory.
 394*/
 395 if ((error = sa_lookup(dzp-z_sa_hdl,
 396SA_ZPL_PARENT(zfsvfs), parent, sizeof (parent))) != 0)
 397   return (error);
 398 if (parent == dzp-z_id  zfsvfs-z_parent != zfsvfs) {
 399   error = zfsctl_root_lookup(zfsvfs-z_parent-z_ctldir,
 400   snapshot, vpp, NULL, 0, NULL, kcred,
 401   NULL, NULL, NULL);
 402   return (error);
 403 }

 Just reading the comment, I don't know what it is referring to by
 snapshot directory. Would that be shares for Sergey's case?

 It seems too obvious, but maybe the lookup of .. is returning the
 vnode for /.zfs/shares for this case?

 I don't know why this wouldn't have shown up before, but maybe it usually
 replies from its cache (I think zfs_lookup() calls it a fast path).

 It might still be interesting to replace zfs_vnops.c line# 1451 with:
   if ((cnp-cn_flags  ISDOTDOT)  *vpp != dvp)
 and see what happens?


With this change `ls /home/user1001/.zfs/shares/' lists empty directory
(although the relevant dataset has snapshot, but that's a different story :)).
Great!
Nothing panics/asserts/etc, just seemingly unrelated LOR

 1st 0xfe00b9569d50 zfs (zfs) @
/usr/src/sys/fs/nfsserver/nfs_nfsdsocket.c:884
 2nd 0xfe001dfd89a0 ufs (ufs) @ /usr/src/sys/kern/vfs_vnops.c:461
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff848e709d00
kdb_backtrace() at kdb_backtrace+0x39/frame 0xff848e709db0
witness_checkorder() at witness_checkorder+0xc47/frame 0xff848e709e30
__lockmgr_args() at __lockmgr_args+0x6c9/frame 0xff848e709f60
ffs_lock() at ffs_lock+0x84/frame 0xff848e709fb0
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xff848e709fd0
_vn_lock() at _vn_lock+0xab/frame 0xff848e70a040
vn_rdwr() at vn_rdwr+0x1f1/frame 0xff848e70a100
nfsrv_writestable() at nfsrv_writestable+0xbe/frame 0xff848e70a170
nfsrv_openupdate() at nfsrv_openupdate+0x489/frame 0xff848e70a5d0
nfsrvd_openconfirm() at nfsrvd_openconfirm+0x123/frame 0xff848e70a6b0
nfsrvd_dorpc() at nfsrvd_dorpc+0xf9a/frame 0xff848e70a8a0
nfssvc_program() at nfssvc_program+0x482/frame 0xff848e70aa00
svc_run_internal() at svc_run_internal+0x1e9/frame 0xff848e70aba0
svc_thread_start() at svc_thread_start+0xb/frame 0xff848e70abb0
fork_exit() at fork_exit+0x84/frame 0xff848e70abf0
fork_trampoline() at fork_trampoline+0xe/frame 0xff848e70abf0
--- trap 0xc, rip = 0x800883b7a, rsp = 0x7fffd6c8, rbp = 0x7fffd970 ---


-- 
wbr,
pluknet
___
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: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

On 5 February 2013 04:13, Rick Macklem rmack...@uoguelph.ca wrote:
 Sergey Kandaurov wrote:
 On 4 February 2013 06:32, Rick Macklem rmack...@uoguelph.ca wrote:
  Konstantin Belousov wrote:
  On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote:
   Andriy Gapon wrote:
on 31/01/2013 15:29 Sergey Kandaurov said the following:
 Hi.

 Got this assertion on idle NFS server while `ls -la
 /.zfs/shares/'
 issued on NFS client.
  Ok, here's a snippet of zfs_dirlook() from zfs_dir.c:
  388 } else if (name[0] == '.'  name[1] == '.'  name[2] == 0) {
  389 zfsvfs_t *zfsvfs = dzp-z_zfsvfs;
  390
  391 /*
  392 * If we are a snapshot mounted under .zfs, return
  393 * the vp for the snapshot directory.
  394 */
  395 if ((error = sa_lookup(dzp-z_sa_hdl,
  396 SA_ZPL_PARENT(zfsvfs), parent, sizeof (parent))) != 0)
  397 return (error);
  398 if (parent == dzp-z_id  zfsvfs-z_parent != zfsvfs) {
  399 error = zfsctl_root_lookup(zfsvfs-z_parent-z_ctldir,
  400 snapshot, vpp, NULL, 0, NULL, kcred,
  401 NULL, NULL, NULL);
  402 return (error);
  403 }
 
  Just reading the comment, I don't know what it is referring to by
  snapshot directory. Would that be shares for Sergey's case?
 
  It seems too obvious, but maybe the lookup of .. is returning the
  vnode for /.zfs/shares for this case?
 
  I don't know why this wouldn't have shown up before, but maybe it
  usually
  replies from its cache (I think zfs_lookup() calls it a fast
  path).
 
  It might still be interesting to replace zfs_vnops.c line# 1451
  with:
if ((cnp-cn_flags  ISDOTDOT)  *vpp != dvp)
  and see what happens?
 

 With this change `ls /home/user1001/.zfs/shares/' lists empty
 directory
 (although the relevant dataset has snapshot, but that's a different
 story :)).
 Great!
 Nothing panics/asserts/etc, just seemingly unrelated LOR

 Yes, I think the patch is relatively safe, since lookup() checks for
 same vnode and does a vrele() instead of a vput() when they are the same,
 at least for a plain lookup without wantparent.

 So, since I've never used ZFS, what does a ls -la 
 /home/user1001/.zfs/shares/
 give you when done locally one the server?

On server (with unmodified kernel):
# ls -la /pool1/user1001/.zfs/share
total 2
dr-xr-xr-x  2 root  wheel  2 Feb  2 20:06 .
dr-xr-xr-x  4 root  wheel  4 Feb  2 20:06 ..

It crashes only when .zfs/share is accessed via NFS
(with and without snapshots), and not when accessed locally.

-- 
wbr,
pluknet
___
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

panic: LK_RETRY set with incompatible flags

[Sergey Kandaurov]

Hi.

Got this assertion on idle NFS server while `ls -la /.zfs/shares/'
issued on NFS client.
kern/vfs_vnops.c:_vn_lock()
KASSERT((flags  LK_RETRY) == 0 || error == 0,
(LK_RETRY set with incompatible flags (0x%x) or
an error occured (%d),

panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)

What does that mean and how is it possible? As you can see, both parts
of assertion failed.
11 is EDEADLK
0x200400: LK_RETRY  LK_UPGRADE

Tracing pid 2943 tid 101532 td 0xfe004f5b7000
kdb_enter() at kdb_enter+0x3e/frame 0xff848e45ef50
vpanic() at vpanic+0x147/frame 0xff848e45ef90
kassert_panic() at kassert_panic+0x136/frame 0xff848e45f000
_vn_lock() at _vn_lock+0x70/frame 0xff848e45f070
zfs_lookup() at zfs_lookup+0x392/frame 0xff848e45f100
zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame 0xff848e45f240
VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame 0xff848e45f260
vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xff848e45f2b0
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xff848e45f2d0
lookup() at lookup+0x548/frame 0xff848e45f350
nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xff848e45f400
nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xff848e45f6b0
nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xff848e45f8a0
nfssvc_program() at nfssvc_program+0x482/frame 0xff848e45fa00
svc_run_internal() at svc_run_internal+0x1e9/frame 0xff848e45fba0
svc_thread_start() at svc_thread_start+0xb/frame 0xff848e45fbb0
fork_exit() at fork_exit+0x84/frame 0xff848e45fbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xff848e45fbf0
--- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffd488, rbp = 0x7fffd730 ---

db show lockedvnods
Locked vnodes

0xfe02e21b11d8: tag zfs, type VDIR
usecount 4, writecount 0, refcount 4 mountedhere 0
flags (VI_ACTIVE)
v_object 0xfe02d9f2eb40 ref 0 pages 0
lock type zfs: EXCL by thread 0xfe004f5b7000 (pid 2943, nfsd,
tid 101532)



-- 
wbr,
pluknet
___
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: [head tinderbox] failure on ia64/ia64

[Sergey Kandaurov]

On 21 January 2013 14:23, FreeBSD Tinderbox tinder...@freebsd.org wrote:
 TB --- 2013-01-21 08:24:09 - tinderbox 2.10 running on 
 freebsd-current.sentex.ca
 TB --- 2013-01-21 08:24:09 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
 FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
 TB --- 2013-01-21 08:24:09 - starting HEAD tinderbox run for ia64/ia64
 TB --- 2013-01-21 08:24:09 - cleaning the object tree
 TB --- 2013-01-21 08:25:27 - /usr/local/bin/svn stat /src
 TB --- 2013-01-21 08:25:37 - At svn revision 245708
 TB --- 2013-01-21 08:25:38 - building world
 TB --- 2013-01-21 08:25:38 - CROSS_BUILD_TESTING=YES
 TB --- 2013-01-21 08:25:38 - MAKEOBJDIRPREFIX=/obj
 TB --- 2013-01-21 08:25:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2013-01-21 08:25:38 - SRCCONF=/dev/null
 TB --- 2013-01-21 08:25:38 - TARGET=ia64
 TB --- 2013-01-21 08:25:38 - TARGET_ARCH=ia64
 TB --- 2013-01-21 08:25:38 - TZ=UTC
 TB --- 2013-01-21 08:25:38 - __MAKE_CONF=/dev/null
 TB --- 2013-01-21 08:25:38 - cd /src
 TB --- 2013-01-21 08:25:38 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Mon Jan 21 08:25:43 UTC 2013
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 World build completed on Mon Jan 21 10:02:31 UTC 2013
 TB --- 2013-01-21 10:02:31 - generating LINT kernel config
 TB --- 2013-01-21 10:02:31 - cd /src/sys/ia64/conf
 TB --- 2013-01-21 10:02:31 - /usr/bin/make -B LINT
 TB --- 2013-01-21 10:02:31 - cd /src/sys/ia64/conf
 TB --- 2013-01-21 10:02:31 - /usr/sbin/config -m LINT
 TB --- 2013-01-21 10:02:31 - building LINT kernel
 TB --- 2013-01-21 10:02:31 - CROSS_BUILD_TESTING=YES
 TB --- 2013-01-21 10:02:31 - MAKEOBJDIRPREFIX=/obj
 TB --- 2013-01-21 10:02:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2013-01-21 10:02:31 - SRCCONF=/dev/null
 TB --- 2013-01-21 10:02:31 - TARGET=ia64
 TB --- 2013-01-21 10:02:31 - TARGET_ARCH=ia64
 TB --- 2013-01-21 10:02:31 - TZ=UTC
 TB --- 2013-01-21 10:02:31 - __MAKE_CONF=/dev/null
 TB --- 2013-01-21 10:02:31 - cd /src
 TB --- 2013-01-21 10:02:31 - /usr/bin/make -B buildkernel KERNCONF=LINT
 Kernel build for LINT started on Mon Jan 21 10:02:31 UTC 2013
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 [...]
 acpi_powerres.o:(.sbss+0x0): multiple definition of 
 `AcpiGbl_IgnoreNoopOperator'
 dbcmds.o:(.sbss+0x0): first defined here
 acpi_resource.o:(.sbss+0x0): multiple definition of 
 `AcpiGbl_IgnoreNoopOperator'
 dbcmds.o:(.sbss+0x0): first defined here
 acpi_thermal.o:(.sbss+0x20): multiple definition of 
 `AcpiGbl_IgnoreNoopOperator'
 dbcmds.o:(.sbss+0x0): first defined here
 acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator'
 dbcmds.o:(.sbss+0x0): first defined here
 *** [kernel] Error code 1

 Stop in /obj/ia64.ia64/src/sys/LINT.
 *** [buildkernel] Error code 1


The (first) patch should fix the build.
So that it is only declared when included in utglobal.c (and extern
elsewhere). DEFINE_ACPI_GLOBALS defined there expects ACPI_EXTERN
to properly handle global objects defined with ACPI_INIT_GLOBAL.

###
Index: contrib/dev/acpica/include/acglobal.h
===
--- contrib/dev/acpica/include/acglobal.h   (revision 245745)
+++ contrib/dev/acpica/include/acglobal.h   (working copy)
@@ -420,7 +420,7 @@

 #ifdef ACPI_DISASSEMBLER

-BOOLEAN ACPI_INIT_GLOBAL (AcpiGbl_IgnoreNoopOperator, FALSE);
+ACPI_EXTERN BOOLEAN ACPI_INIT_GLOBAL (AcpiGbl_IgnoreNoopOperator, FALSE);

 ACPI_EXTERN BOOLEAN AcpiGbl_DbOpt_disasm;
 ACPI_EXTERN BOOLEAN AcpiGbl_DbOpt_verbose;
###


The other way is to declare AcpiGbl_IgnoreNoopOperator as extern below.
This seems to be used for other ACPI_INIT_GLOBAL's as well, see acglobal.h
But this doesn't work because it is not defined under DEFINE_ACPI_GLOBALS.

###
Index: contrib/dev/acpica/include/acpixf.h
===
--- contrib/dev/acpica/include/acpixf.h (revision 245745)
+++ contrib/dev/acpica/include/acpixf.h (working copy)
@@ -79,6 +79,7 @@
 extern UINT8AcpiGbl_CopyDsdtLocally;
 extern UINT8AcpiGbl_TruncateIoAddresses;
 extern UINT8AcpiGbl_DisableAutoRepair;
+extern BOOLEAN  AcpiGbl_IgnoreNoopOperator;


 /*
###

 Stop in /src.
 *** Error code 1

 Stop in /src.
 TB --- 2013-01-21 10:23:07 - WARNING: /usr/bin/make returned exit code  1
 TB --- 

Re: base system: remnant old files not covered by make delete-old-files

[Sergey Kandaurov]

On 26 December 2012 15:49, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 I figured out that my system is somekind of polluted by remnant old files.

 I do installworld on a regular basis and I do it like suggested in the
 handbook. I also regularyly do make delete-old-XXX in /usr/src.

 Well, now I figured out that there are some remnants in several system
 folders, for instance

 /usr/bin/ncplogout
 /usr/bin/ncplist (and some more, but last updated Oct, 17th)

 or

 /usr/bin/smbutil

 or

 /usr/sbin/mount_nwfs
 /usr/sbin/mount_portalfs
 /usr/sbin/mount_smbfs (last update around the 16. Oktober)

 or


 /sbin/mount_ntfs

 Is this by intention or ist this an accident?

 I guess the binaries will by out of sync with the kernel if they remain
 unchanged.


This is an intentional leftover from
http://svn.freebsd.org/changeset/base/241629

On 17.10.12 20:50, Attilio Rao wrote:
For the moment we should not move the files yet into
ObsoleteFiles.inc. This is done because all the FS removed code will
make it into ObsoleteFiles.inc into a separate pass, in 3-4 months,
giving people time to possibly fix and re-link a filesystem.

-- 
wbr,
pluknet
___
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: r244114 ia64: make check-old-libs says /lib/libz.so.5 can be removed, but it is still needed by /usr/sbin/dtrace and /usr/sbin/lockstat

[Sergey Kandaurov]

On 12 December 2012 14:07, Anton Shterenlikht me...@bristol.ac.uk wrote:
 I updated to r244114 on ia64 following the
 standard procedure. I then get:

 # make check-old-libs
 Checking for old libraries
 /lib/libz.so.5
 #

 while sysutils/libchk shows:

 Binaries that are linked with: /lib/libz.so.5
 /usr/sbin/dtrace
 /usr/sbin/lockstat

 and indeed these two executables depend
 on this library:

 # ldd /usr/sbin/dtrace
 /usr/sbin/dtrace:
 libdtrace.so.2 = /lib/libdtrace.so.2 (0x200020094000)
 libproc.so.2 = /usr/lib/libproc.so.2 (0x200020194000)
 libctf.so.2 = /lib/libctf.so.2 (0x2000201a8000)
 libelf.so.1 = /usr/lib/libelf.so.1 (0x2000201d)
 libz.so.5 = /lib/libz.so.5 (0x20002021)
 libthr.so.3 = /lib/libthr.so.3 (0x200020246000)
 libc.so.7 = /lib/libc.so.7 (0x200020294000)
 # ldd /usr/sbin/lockstat
 /usr/sbin/lockstat:
 libdtrace.so.2 = /lib/libdtrace.so.2 (0x200020094000)
 libproc.so.2 = /usr/lib/libproc.so.2 (0x200020194000)
 libctf.so.2 = /lib/libctf.so.2 (0x2000201a8000)
 libelf.so.1 = /usr/lib/libelf.so.1 (0x2000201d)
 libz.so.5 = /lib/libz.so.5 (0x20002021)
 librt.so.1 = /usr/lib/librt.so.1 (0x200020246000)
 libthr.so.3 = /lib/libthr.so.3 (0x20002025e000)
 libc.so.7 = /lib/libc.so.7 (0x2000202ac000)
 #

 I see that these two executables are old:

 # ls -al /usr/sbin/dtrace /usr/sbin/lockstat
 -r-xr-xr-x  1 root  wheel  58976 Jul 18  2010 /usr/sbin/dtrace
 -r-xr-xr-x  1 root  wheel  72832 Jul 18  2010 /usr/sbin/lockstat
 #

 Does this mean that both dtrace and lockstat
 are obsolete and can be removed?


Both binaries stopped building for ia64 since r210693 (Jul 31 2010).

-- 
wbr,
pluknet
___
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: syscall cost freebsd vs linux ?

[Sergey Kandaurov]

On 26 November 2012 15:39, Lukasz Wojcik lukasz.woj...@zoho.com wrote:
 On 11/19/12 20:32, Luigi Rizzo wrote:

 today i was comparing the performance of some netmap-related code
 on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that
 our system calls are significantly slower.
 On comparable hardware (i7-2600k vs E5-1650) the syscall
 getppid() takes about 95ns on FreeBSD and 38ns on linux.

 (i make sure not to use gettimeofday(), which in linux is through vdso,
 and getpid(), which is cached by glibc).

 Any idea on why there is this difference and whether/how
 we can reduce it ?


 I'm curious about how did you measure that ? Could you write some more about
 your methodology ?

There is a nice tool at /usr/src/tools/tools/syscall_timing

-- 
wbr,
pluknet
___
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: strange buildworld failure

[Sergey Kandaurov]

On 23 November 2012 12:34, Nikos Vassiliadis nv...@gmx.com wrote:
 Hi,

 I am trying to buildworld but it fails here:

 === usr.bin/ypwhich (all)
 cc -O2 -pipe  -std=gnu99 -Qunused-arguments -fstack-protector
 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -
 Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
 -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
 unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -c
 /usr/src/usr.bin/ypwhich/ypwhich.c
 gzip -cn /usr/src/usr.bin/ypwhich/ypwhich.1  ypwhich.1.gz
 cc -O2 -pipe  -std=gnu99 -Qunused-arguments -fstack-protector
 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -
 Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
 -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
 unused-function -Wno-conversion -Wno-switch -Wno-switch-enum  -o ypwhich
 ypwhich.o
 1 error
 *** [everything] Error code 2
 1 error
 *** [buildworld] Error code 2
 1 error


 My make.conf has these:
 WITHOUT_X11=1
 MALLOC_PRODUCTION=1
 NO_CLEAN=1

 Also, my src.conf had WITHOUT_CLANG but I deleted it and then I
 also deleted /usr/obj when it failed for the first time. But that
 didn't work. I am building with -j3.

Does it always fail there at usr.bin/ypwhich?
It's likely that -j3 is the culprit of why you do not see the actual build
error because it might be lost off the screen. Try to restart without -jN.

-- 
wbr,
pluknet
___
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: CSRG history now available as an SVN repository

[Sergey Kandaurov]

On 20 October 2012 00:34, Andrew Milton a...@theinternet.com.au wrote:
 +---[ John Baldwin ]--
 | I recently converted CSRG's SCCS repository holding the original BSD history
 | to a Subversion repository.  As a derivative work of CSRG's code base, this
 | repository is available under the terms of the original UC Berkeley license.
 |
 | You can browse the history at http://svnweb.freebsd.org/csrg/
 |
 | The repository is also available via FTP or HTTP:
 |
 |  - ftp://ftp.freebsd.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz
 |  - http://freebsd.isc.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz
 |
 | Thanks to Simon Neilsen for putting the repository up on FreeBSD.org and to
 | Kirk McKusick for preserving this history.

 This is fantastic... although I think I just lost my weekend.

Yeah.. Digging deep into the archaeological survey is so catchy.
Many thanks to all of you who made this happen. Brilliant work.

-- 
wbr,
pluknet
___
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: memory warnings r240891 | dmesgg

[Sergey Kandaurov]

On 4 October 2012 20:18, Darrel levi...@iglou.com wrote:
 Hello,

 Swap was created twice on this 9.0 release candidate install- once as
 part of zfs and also as encrypted hard drive space.

 (30) @ 12:01:50 swapinfo
 Device  1K-blocks UsedAvail Capacity
 /dev/zvol/bigD/swap   41943040  4194304 0%
 /dev/gpt/swap0.eli   31457280  3145728 0%
 /dev/gpt/swap1.eli   31457280  3145728 0%
 Total104857600 10485760 0%
[...]
 *
 FreeBSD 10.0-CURRENT #1 r240891: Tue Sep 25 00:51:03 EDT 2012

[...]
 real memory  = 1073741824 (1024 MB)
 avail memory = 937144320 (893 MB
[...]

 warning: total configured swap (2621440 pages) exceeds maximum
 recommended amount (1852656 pages).

 warning: increase kern.maxswzone or reduce amount of swap.

 *

 Apparently kern.maxswzone is currently equal to 0.  How might I tweak it
 just enough to fix this?

So, reduce amount of swap :)

This is because kernel needs some memory to manage swap too.
Currently for amd64 this roughly reduces to the following rule
(My apologies in advance for the extra simplification):

100MB RAM per 800MB swap space.

So, with your current amount of RAM (893MB) it is recommended to setup
no more than 7144 MB of swap. [1]

[1] Let's look at  vm/swap_pager.c:swapon_check_swzone(npages).
Here npages is the total swap pages you want to setup. The warning will
trigger if (npages  maxpages / 2) becomes true. maxpages is the maximum
pages the system can use for swap management. It is calculated as:
  maxpages = uma_zone_get_max(swap_zone) * SWAP_META_PAGES;
By default SWAP_META_PAGES is 32 on amd64, and swap_zone limit calculates
as available memory pages in system divided by two (assuming that maxswzone
is zero (by default on amd64) and cannot further affect the limit).
So that with X total pages in system, the maximum Y swap pages you are
advised to have is: Y = X * SWAP_META_PAGES / 2 / 2, or X * 8 (on amd64).

-- 
wbr,
pluknet
___
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: /usr/src/lib/libc/gen/aux.c:106: error: 'AT_TIMEKEEP' undeclared

[Sergey Kandaurov]

On 19 September 2012 00:27, Anton Shterenlikht me...@bristol.ac.uk wrote:

 I'm trying to rebuild libc with debugging symbols.
 I did:

 # cd /usr/src/lib/libc
 # make all install DEBUG_FLAGS='-g'

 and got:

 cc  -O2 -pipe  -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include 
 -I/
 usr/src/lib/libc/ia64 -DNLS  -D__DBINTERFACE_PRIVATE 
 -I/usr/src/lib/libc/../../c
 ontrib/gdtoa -DINET6 -I/usr/src/lib/libc -I/usr/src/lib/libc/resolv 
 -D_ACL_PRIVA
 TE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/jemalloc/include 
 -I/usr/src
 /lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
 -I/usr/src/li
 b/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc 
 -DYP
 -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall 
 -Wno-
 format-y2k -Wno-uninitialized -Wno-pointer-sign -c 
 /usr/src/lib/libc/gen/aux.c -
 o aux.o
 /usr/src/lib/libc/gen/aux.c: In function 'init_aux':
 /usr/src/lib/libc/gen/aux.c:106: error: 'AT_TIMEKEEP' undeclared (first use 
 in t
 his function)
 /usr/src/lib/libc/gen/aux.c:106: error: (Each undeclared identifier is 
 reported
 only once
 /usr/src/lib/libc/gen/aux.c:106: error: for each function it appears in.)
 /usr/src/lib/libc/gen/aux.c: In function '_elf_aux_info':
 /usr/src/lib/libc/gen/aux.c:171: error: 'AT_TIMEKEEP' undeclared (first use 
 in t
 his function)
 *** [aux.o] Error code 1


This means you have no actual elf.h with AT_TIMEKEEP installed in your
system required to build the recent libc. When you build libc, make
searches for AT_TIMEKEEP in the installed headers, and not in /usr/src.
Canonically you would need to rebuild all the world to properly build the
libc part. To not do this you could try instead (AFAIK) 'make toolchain'.

-- 
wbr,
pluknet
___
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: swp_pager_meta_build DoS printf

[Sergey Kandaurov]

On 15 August 2012 19:21, John Baldwin j...@freebsd.org wrote:
 On Monday, August 13, 2012 1:49:38 am Sergey Kandaurov wrote:
 On 2 July 2012 20:31, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote:
 
  On 2. Jul 2012, at 14:36 , John Baldwin wrote:
 
  On Sunday, July 01, 2012 8:23:31 am Bjoern A. Zeeb wrote:
  Hey,
 
  hitting this printf in swp_pager_meta_build()
 
 if (uma_zone_exhausted(swap_zone)) {
 printf(swap zone exhausted, increase
 kern.maxswzone\n);
 vm_pageout_oom(VM_OOM_SWAPZ);
 pause(swzonex, 10);
 } else
 
  seems to be an effective way to put the machine into a state of no
 recovery
  unless the memory situation would be able to clear itself.  Not that it
 wouldn't
  otherwise be any better but in addition having a couple of tenthousands
 of these
  going to console as well is really not helpful to try to do anything
 either.  Can
  we make it a log() call or something?
 
  /bz
 
  PS: I am not sure as I have seen it on someone else's machines and it's
  probably been ZFS that caused it.  I unfortunately neither had a way to
  get back in or break to a kernel debugger, so information is sparse.
 
  This used to be a silent deadlock before I added the printf() and the
 call to
  OOM. :-P  Do you just want to ratelimit the printf?  We have an API to
 ratelimit
  printf's already.
 
  Ratelimit would be fine;  I was writing that on the wrong time of the
 wrong day to
  just get it out;  could you do that?

 Hi, looks like the discussion was abandoned.
 What about this patch? It enables to ratelimit the printf.
 Also, are the new variables put in the right places from the style pov?

 I think DES has a newer variant of this now?

Yes, and for my taste it's better as it is closer to fix the cause
of the problem, not the consequences (unrated printf).  Not sure if
both should be combined, I believe the DES change is enough here.

-- 
wbr,
pluknet
___
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: swp_pager_meta_build DoS printf

[Sergey Kandaurov]

On 2 July 2012 20:31, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote:

 On 2. Jul 2012, at 14:36 , John Baldwin wrote:

 On Sunday, July 01, 2012 8:23:31 am Bjoern A. Zeeb wrote:
 Hey,

 hitting this printf in swp_pager_meta_build()

if (uma_zone_exhausted(swap_zone)) {
printf(swap zone exhausted, increase 
 kern.maxswzone\n);
vm_pageout_oom(VM_OOM_SWAPZ);
pause(swzonex, 10);
} else

 seems to be an effective way to put the machine into a state of no recovery
 unless the memory situation would be able to clear itself.  Not that it 
 wouldn't
 otherwise be any better but in addition having a couple of tenthousands of 
 these
 going to console as well is really not helpful to try to do anything 
 either.  Can
 we make it a log() call or something?

 /bz

 PS: I am not sure as I have seen it on someone else's machines and it's
 probably been ZFS that caused it.  I unfortunately neither had a way to
 get back in or break to a kernel debugger, so information is sparse.

 This used to be a silent deadlock before I added the printf() and the call to
 OOM. :-P  Do you just want to ratelimit the printf?  We have an API to 
 ratelimit
 printf's already.

 Ratelimit would be fine;  I was writing that on the wrong time of the wrong 
 day to
 just get it out;  could you do that?

Hi, looks like the discussion was abandoned.
What about this patch? It enables to ratelimit the printf.
Also, are the new variables put in the right places from the style pov?

Index: /usr/src/sys/vm/swap_pager.c
===
--- /usr/src/sys/vm/swap_pager.c(revision 239171)
+++ /usr/src/sys/vm/swap_pager.c(working copy)
@@ -1804,8 +1804,10 @@ restart:
 static void
 swp_pager_meta_build(vm_object_t object, vm_pindex_t pindex, daddr_t swapblk)
 {
+   static struct timeval lastfail;
struct swblock *swap;
struct swblock **pswap;
+   static int curfail;
int idx;

VM_OBJECT_LOCK_ASSERT(object, MA_OWNED);
@@ -1847,7 +1849,9 @@ retry:
mtx_unlock(swhash_mtx);
VM_OBJECT_UNLOCK(object);
if (uma_zone_exhausted(swap_zone)) {
-   printf(swap zone exhausted, increase
kern.maxswzone\n);
+   if (ppsratecheck(lastfail, curfail, 1))
+   printf(swap zone exhausted, 
+   increase kern.maxswzone\n);
vm_pageout_oom(VM_OOM_SWAPZ);
pause(swzonex, 10);
} else

-- 
wbr,
pluknet
___
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: VIA VE-900 nano X2 boot failure

[Sergey Kandaurov]

On 17 July 2012 20:56, Felix Kohtz felix.ko...@gmail.com wrote:
 I recently purchased a VIA EPIA-VE-900 Nano X2 1,4 GHz Dual Core MiniITX
 Board
 http://www.via.com.tw/en/products/viamainboards/ve900/index.jsp

 and wanted to install FreeBSD (amd64) from an iso-file on it.

 I tried to install:

 FreeBSD 8.3-RELEASE :
 works fine.
 dmesg here: http://pastebay.net/1068207

 FreeBSD 9.0-RELEASE :
 stops during boot-process.
 (part of - where it stops) dmesg here: http://pastebay.net/1068208

 FreeBSD 9.1-RELENG_9-20120716-JPSNAP from
 https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/
 stops during boot-process at same point like 9.0-RELEASE.

 FreeBSD 10.0-HEAD-20120717-JPSNAP from
 https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/
 stops during boot-process at same point like 9.0-RELEASE.

 I can provide more information on this problem if you say me what is needed
 and i offer to test changes.

To get better diagnostics:
1) try to put hint.hdac.0.disabled=1 into your /boot/device.hints,
to disabled hdac device, then reboot and see if that helps
hdac is under a cloud, since it is included in GENERIC starting from 9.0.
2) boot kernel in verbose mode
(boot_verbose=YES in /boot/loader.conf or simply boot -v)

-- 
wbr,
pluknet
___
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: mbstowcs(3) may not return -1

[Sergey Kandaurov]

On 21 June 2012 16:38, David Demelier demelier.da...@gmail.com wrote:
 Hello,

 While reading the manpage of mbstowcs I noticed an error in the RETURN
 VALUES :

     The mbstowcs() function returns the number of wide characters converted,
     not counting any terminating null wide character, or -1 if an invalid
     multibyte character was encountered.

 Since size_t is unsigned, it can't returns -1.

It returns (size_t)(-1).
I don't know how is it correct, but this conforms to C spec.

-- 
wbr,
pluknet
___
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: mbstowcs(3) may not return -1

[Sergey Kandaurov]

On 21 June 2012 19:42, David Demelier demelier.da...@gmail.com wrote:
 On 21/06/2012 14:55, Sergey Kandaurov wrote:

 On 21 June 2012 16:38, David Demelierdemelier.da...@gmail.com  wrote:

 Hello,

 While reading the manpage of mbstowcs I noticed an error in the RETURN
 VALUES :

     The mbstowcs() function returns the number of wide characters
 converted,
     not counting any terminating null wide character, or -1 if an invalid
     multibyte character was encountered.

 Since size_t is unsigned, it can't returns -1.


 It returns (size_t)(-1).
 I don't know how is it correct, but this conforms to C spec.


 Mm, if I understand well, since it is cast to size_t, I think the return
 value will be SIZE_MAX - 1 then, right?

No, just SIZE_MAX.
There is also remarkable SIZE_T_MAX. It came with 4.4BSD Lite sources
under !defined(_POSIX_SOURCE). Later it was converted to be under
__POSIX_VISIBLE = 200112 || __XSI_VISIBLE. I hasn't found anything
relative in any POSIX editions. I think this was a typo/misunderstanding.
Other BSD has put this macro under its corresponding if XBSD_VISIBLE.
Therefore I think SIZE_T_MAX should be avoided.

-- 
wbr,
pluknet
___
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: Daily, weekly, security scripts....

[Sergey Kandaurov]

On 24 May 2012 11:49, Willem Jan Withagen w...@digiware.nl wrote:
 [I looked for a better list to drop this on, but other that freebsd-rc
 nothing seems close.]

 Hi,

 I nagged about the verbosity of the periodic scripts.
 But did not give any example.

 Well I just ran into a perfect example:
 --
 Checking setuid files and devices:

 Checking for uids of 0:
 root 0

 Checking for passwordless accounts:

 Checking login.conf permissions:

 Checking for ports with mismatched checksums:

 xx.xx.nl kernel log messages:
 +++ /tmp/security.X5WEmRe8      2012-05-24 03:38:58.028927236 +0200

 xx.xx.nl login failures:

 xx.xx.nl refused connections:

 Checking for a current audit database:

 Database created: Wed May 23 03:45:00 CEST 2012

 Checking for packages with security vulnerabilities:

 0 problem(s) in your installed packages found.

 -- End of security output --

 Which does not really report anything other than the system is healthy.

 Now because of the sheer volume (with about 20+ servers to maintain)
 this goes into a seperate bin, which I only check on less busy times.

 Whereas it would go into my active mailbox when I only get allerts on
 which I really need to handle.

 This would call for something like $periodic_quiet??
 and then generating the headers only if there was something to report.

 I'd do it myself if only the day had 36 hours...

Hi,
you could try to start with:

security_show_success=NO
daily_show_success=NO

-- 
wbr,
pluknet
___
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: SOLVED: Re: KLD zfs.ko: depends on acl_nfs4 - not available or version mismatch

[Sergey Kandaurov]

On 10 May 2012 14:23, Anton Shterenlikht me...@bristol.ac.uk wrote:
 On Thu, May 10, 2012 at 11:01:21AM +0100, Anton Shterenlikht wrote:
 On ia64 r235163 I get this error
 when trying to load zfs module:

 # ls -al /boot/kernel/zfs.ko*
 -r-xr-xr-x  1 root  wheel  2496877 May 10 09:15 /boot/kernel/zfs.ko
 -r-xr-xr-x  1 root  wheel  6578175 May 10 09:15 /boot/kernel/zfs.ko.symbols
 # kldload zfs
 KLD zfs.ko: depends on acl_nfs4 - not available or version mismatch
 kldload: can't load zfs: No such file or directory

 Figured I now need to add module acl_nfs4:

 makeoptions     MODULES_OVERRIDE=geom/geom_part geom/geom_label opensolaris 
 zfs acl_nfs4

 The acl_nfs4 module wasn't required before for zfs.

 Where is this change documented?

Looks like you stepped on rev 232938 where dependency on acl_nfs4 was added.
http://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c?r1=232937r2=234795

-- 
wbr,
pluknet
___
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: r235163: root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does not exist.

[Sergey Kandaurov]

On 10 May 2012 14:30, Anton Shterenlikht me...@bristol.ac.uk wrote:

 On ia64 r235163:

 root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does not 
 exist.

 What is this about?
 After updating to this revision,
 I run mergemaster, as usual,
 with the setting to auto update
 all /etc files which I didn't touch.

I'd check your kernel config for 'options NFSCLIENT', so there is
sysctl vfs.oldnfs.access_cache_timeout instead, and you try to set
non-existing vfs.nfs.access_cache_timeout from /etc/sysctl.conf.
If it is so then all your sysctl vfs.nfs.xxx are named as vfs.oldnfs.xxx,
because the NFS implementation enabled with 'options NFSCLIENT'
considered old, and the NFS impl. enabled with 'options NFSCL' is the default.
My inner voice tells me that you have upgraded from quite old CURRENT
from the point when 'options NFSCLIENT' (old nfs) was default to the point
when 'options NFSCL' (new nfs implementation) became the default,
and you still have 'options NFSCLIENT' in your kernel config.
See /usr/src/UPDATING entry dated 20110427.

-- 
wbr,
pluknet
___
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, seems related to r234386

[Sergey Kandaurov]

On 8 May 2012 00:11, Mateusz Guzik mjgu...@gmail.com wrote:
 On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote:
 On 05/06/2012 15:19, Sergey Kandaurov wrote:
  On 7 May 2012 01:54, Doug Barton do...@freebsd.org wrote:
  I got this with today's current, previous (working) kernel is r232719.
 
  panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx
  @ /frontier/svn/head/sys/kern/vfs_subr.c:4595

 ...

  Please try this patch.
 
  Index: fs/ext2fs/ext2_vfsops.c
  ===
  --- fs/ext2fs/ext2_vfsops.c     (revision 235108)
  +++ fs/ext2fs/ext2_vfsops.c     (working copy)
  @@ -830,7 +830,6 @@
          /*
           * Write back each (modified) inode.
           */
  -       MNT_ILOCK(mp);
   loop:
          MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
                  if (vp-v_type == VNON) {
 

 Didn't help, sorry. I put 234385 through some pretty heavy load
 yesterday, and everything was fine. As soon as I move up to 234386, the
 panic triggered again. So I cleaned everything up, applied your patch,
 built a kernel from scratch, and rebooted. It was Ok for a few seconds
 after boot, then panic'ed again, I think in a different place, but I'm
 not sure because subsequent attempts to fsck the file systems caused new
 panics which overwrote the old ones before they could be saved.


 Another MNT_ILOCK was hiding few lines below, try this patch:

 http://student.agh.edu.pl/~mjguzik/patches/ext2fs-ilock.patch

 I've tested this a bit and I believe this fixes your problem.

I just committed your fix in r235241 since it seems to have no
relation to the problem reported by Peter Holm.

-- 
wbr,
pluknet
___
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, seems related to r234386

[Sergey Kandaurov]

On 8 May 2012 05:14, Doug Barton do...@freebsd.org wrote:
 On 05/07/2012 13:11, Mateusz Guzik wrote:
 On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote:
 On 05/06/2012 15:19, Sergey Kandaurov wrote:
 On 7 May 2012 01:54, Doug Barton do...@freebsd.org wrote:
 I got this with today's current, previous (working) kernel is r232719.

 panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx
 @ /frontier/svn/head/sys/kern/vfs_subr.c:4595

 ...

 Please try this patch.

 Ok, so far so good. Again, thanks for the quick response. I'm
 stress-testing my ext2fs partitions a bit atm, and everything seems Ok.
 I'll let you know if I run into any problems.

 So my next question is, does removing those locks present any risks?
 Should they be replaced by different locks, or were they just safety
 belts to start with?

Unlike in the previously used macro MNT_VNODE_FOREACH_ABORT_ILOCKED(),
the currently used macro MNT_VNODE_FOREACH_ALL_ABORT() manages
mount mutexes itself so you don't need to mess with them. The locking is there,
it's just hidden behind macros.


 Finally, should my next step be to advance to the latest current + your
 patch and see how I go from there?

Yep, so that patches will be tested before they go to head.

-- 
wbr,
pluknet
___
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, seems related to r234386

[Sergey Kandaurov]

On 7 May 2012 01:54, Doug Barton do...@freebsd.org wrote:
 I got this with today's current, previous (working) kernel is r232719.

 panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx
 @ /frontier/svn/head/sys/kern/vfs_subr.c:4595

 FWIW I'm using ufs2, ext2fs, and msdosfs on this system. The panic
 occurred right after loading the linux kernel module, but I'm not 100%
 sure that's related. Full core.txt.0 is in my home directory on freefall.

 #0  doadump (textdump=1) at /frontier/svn/head/sys/kern/kern_shutdown.c:268
 268             if (textdump  textdump_pending) {
 (kgdb) #0  doadump (textdump=1) at
 /frontier/svn/head/sys/kern/kern_shutdown.c:268
 #1  0x80482999 in kern_reboot (howto=260)
    at /frontier/svn/head/sys/kern/kern_shutdown.c:454
 #2  0x804823ca in panic (fmt=0x0)
    at /frontier/svn/head/sys/kern/kern_shutdown.c:642
 #3  0x80471c25 in _mtx_lock_sleep (m=Variable m is not available.
 )
    at /frontier/svn/head/sys/kern/kern_mutex.c:363
 #4  0x80471cb0 in _mtx_lock_flags (m=Variable m is not available.
 )
    at /frontier/svn/head/sys/kern/kern_mutex.c:212
 #5  0x80517353 in __mnt_vnode_first_all (mvp=0xff819e9f0a58,
    mp=0xfe00051dc310) at /frontier/svn/head/sys/kern/vfs_subr.c:4595
 #6  0x8042bdd5 in ext2_sync (mp=0xfe00051dc310, waitfor=2)
    at /frontier/svn/head/sys/fs/ext2fs/ext2_vfsops.c:835
 #7  0x80521446 in sys_sync (td=Variable td is not available.
 )
    at /frontier/svn/head/sys/kern/vfs_syscalls.c:150
 #8  0x806b1d52 in amd64_syscall (td=0xfe0005149480, traced=0)
    at subr_syscall.c:135
 #9  0x8069d697 in Xfast_syscall ()
    at /frontier/svn/head/sys/amd64/amd64/exception.S:387
 #10 0x0008008b061c in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 (kgdb)


Please try this patch.

Index: fs/ext2fs/ext2_vfsops.c
===
--- fs/ext2fs/ext2_vfsops.c (revision 235108)
+++ fs/ext2fs/ext2_vfsops.c (working copy)
@@ -830,7 +830,6 @@
/*
 * Write back each (modified) inode.
 */
-   MNT_ILOCK(mp);
 loop:
MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
if (vp-v_type == VNON) {

-- 
wbr,
pluknet
___
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: kernel build failure

[Sergey Kandaurov]

On 13 April 2012 02:21, AN a...@neu.net wrote:
 At Thu Apr 12 17:52:05 EDT 2012:

 [root@FBSD10 /usr/src]# svn up
 Updating '.':
 At revision 234196.
[...]
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall
 -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
 -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
 -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option
 -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL
 -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
 -finline-limit=8000 --param inline-unit-growth=100 --param
 large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel
 -mno-red-zone -mno-mmx -mno-sse -msoft-float
  -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
  /usr/src/sys/kern/subr_turnstile.c
 cc1: warnings being treated as errors
 /usr/src/sys/kern/subr_turnstile.c: In function 'propagate_priority':
 /usr/src/sys/kern/subr_turnstile.c:220: warning: implicit declaration of
 function 'kdb_backtrace_thread'
 /usr/src/sys/kern/subr_turnstile.c:220: warning: nested extern declaration
 of 'kdb_backtrace_thread' [-Wnested-externs]
 *** [subr_turnstile.o] Error code 1

 Stop in /usr/obj/usr/src/sys/MYKERNEL.
 *** [buildkernel] Error code 1

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

 Stop in /usr/src.

This is a transient failure, it will be fixed soon.

-- 
wbr,
pluknet
___
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: compiling glib20 failed

[Sergey Kandaurov]

On 4 April 2012 07:02, gahn ipfr...@yahoo.com wrote:
 hi gurus:

 i got problem with compiling glib20:

 ===   glib-2.28.8_4 depends on file: /usr/local/bin/perl5.10.1 - found
 /libexec/ld-elf.so.1: /usr/local/lib/liblzma.so.5: version XZ_5.0 required by 
 /usr/bin/xz not defined
 ===  Missing license file for LGPL20 in 
 /usr/ports/devel/glib20/work/glib-2.28.8/COPYING
 *** Error code 1

 Stop in /usr/ports/devel/glib20.
 *** Error code 1


 basically i was trying to install tshark on freebsd 8.1 but it told me i need 
 to upgrade glib but i got into this mess.


Looks like the source of your problem may lie in that your base /usr/bin/xz
tries to dlopen /usr/local/lib/liblzma.so.5 installed from ports and not
the one from base (i.e. there should be /usr/lib/liblzma.so.5 instead).
The one from ports doesn't have the symbol versioning
(or at least doesn't have specific symbols the base xz wants)
and, for aught I know, shall not be used by the base xz in any way.

I wonder how did you manage to install xz from ports on 8.1
as this port is specifically IGNORE'd to install on 8.1 system
with the reason is already in the base system.

First I would try to pkgrm xz and see how it helps.

-- 
wbr,
pluknet
___
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: About kern.ipc.semmap on FreeBSD 9

[Sergey Kandaurov]

On 23 March 2012 09:20, Alexander Pyhalov a...@rsu.ru wrote:
 On 03/23/2012 01:52, Herbert J. Skuhra wrote:

 On Thu, 22 Mar 2012 10:02:15 -0600
 Efraín Déctorefraindec...@motumweb.com  wrote:

 Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS
 for a PostgreSQL Server. However, it is recommended to modified some
 paramerts such as semaphores
 (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ):

 kern.ipc.semmap=256

 But when I tried to change the value on FreeBSD this pops up:

 sysctl: unknown oid 'kern.ipc.semmap'

 What Can I do to resolve this issue?.


 This has been removed in r224016:


 http://svnweb.freebsd.org/base/head/sys/kern/sysv_sem.c?r1=223825r2=224016


 Hello.
 Could someone briefly explain, why this tunable was removed? I couldn't find
 anything relevant in  9.0 release notes.


Hey,
as it was explained in the comment to the commit that removed semmap,
this tune didn't do nothing since its appearance. If that really hurts you,
and you think that this will make you feel better, then you can always
revert that revision and continue to tune its option up :)

-- 
wbr,
pluknet
___
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: CARP on -CURRENT

[Sergey Kandaurov]

On 2 February 2012 04:26, Andrew Hobbs andrew.ho...@ai.net wrote:
 I much appreciate the responses and I was able to get CARP functioning using 
 the new ifconfig syntax under -CURRENT. Having done that, CARP is now acting 
 as it should, though now I have a new challenge with devd and automatic 
 firing of scripts during CARP failover. It appears that the documented method 
 of doing this at http://www.freebsd.org/doc/handbook/disks-hast.html no 
 longer works with the suggested devd.conf setup;
 notify 30 {
        match system IFNET;
        match subsystem carp0;
        match type LINK_UP;
        action /usr/local/sbin/carp-hast-switch master;
 };

 notify 30 {
        match system IFNET;
        match subsystem carp0;
        match type LINK_DOWN;
        action /usr/local/sbin/carp-hast-switch slave;

 Is it likely that the triggers associated with CARP for devd have changed due 
 to the recent new CARP overhaul? Does anyone know what the new triggers may 
 be?


You will need to change this to something like (as taken from man carp):
 match system  CARP;
 match subsystem   [0-9]+@;
 match type(MASTER|BACKUP);

The subsystem now is generated as
snprintf(subsys, IFNAMSIZ+5, %u@%s, sc-sc_vhid, sc-sc_carpdev-if_xname);

-- 
wbr,
pluknet
___
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

[patch] fstat: print the owner process for UNIX domain sockets

[Sergey Kandaurov]

Hi.
This patch adds support for fstat(1) to identify which process opened the
specified socket file, to bring in line with regular files. E.g.:

# fstat /var/run/devd.pipe
USER CMD  PID   FD MOUNT  INUM MODE SZ|DV R/W NAME
root devd12594* local stream fe0002a1a870
/var/run/devd.pipe
# fstat /var/run/logpriv
USER CMD  PID   FD MOUNT  INUM MODE SZ|DV R/W NAME
root syslogd 14955* local dgram fe0002a1a3c0  /var/run/logpriv

Comments are welcome.

Index: usr.bin/fstat/fstat.c
===
--- usr.bin/fstat/fstat.c   (revision 230505)
+++ usr.bin/fstat/fstat.c   (working copy)
@@ -38,6 +38,7 @@ __FBSDID($FreeBSD$);
 #include sys/socketvar.h
 #include sys/sysctl.h
 #include sys/queue.h
+#include sys/un.h

 #include netinet/in.h

@@ -224,28 +225,53 @@ static void
 print_file_info(struct procstat *procstat, struct filestat *fst,
 const char *uname, const char *cmd, int pid)
 {
+   struct sockstat sock;
struct vnstat vn;
DEVS *d;
const char *filename;
int error, fsmatch = 0;
char errbuf[_POSIX2_LINE_MAX];

+   error = 0;
filename = NULL;
if (checkfile != 0) {
-   if (fst-fs_type != PS_FST_TYPE_VNODE 
-   fst-fs_type != PS_FST_TYPE_FIFO)
+   switch (fst-fs_type) {
+   case PS_FST_TYPE_VNODE:
+   case PS_FST_TYPE_FIFO:
+   error = procstat_get_vnode_info(procstat, fst,
vn, errbuf);
+   break;
+   case PS_FST_TYPE_SOCKET:
+   error = procstat_get_socket_info(procstat,
fst, sock, errbuf);
+   break;
+   default:
return;
-   error = procstat_get_vnode_info(procstat, fst, vn, errbuf);
+   }
if (error != 0)
return;

for (d = devs; d != NULL; d = d-next)
-   if (d-fsid == vn.vn_fsid) {
-   fsmatch = 1;
-   if ((unsigned)d-ino == vn.vn_fileid) {
-   filename = d-name;
-   break;
+   switch (fst-fs_type) {
+   case PS_FST_TYPE_VNODE:
+   case PS_FST_TYPE_FIFO:
+   if (d-fsid == vn.vn_fsid) {
+   fsmatch = 1;
+   if ((unsigned)d-ino == vn.vn_fileid) {
+   filename = d-name;
+   break;
+   }
}
+   break;
+   case PS_FST_TYPE_SOCKET:
+   if (sock.dom_family == AF_UNIX) {
+   fsmatch = 1;
+   if (strcmp(((struct sockaddr_un *)
+   (sock.sa_local))-sun_path,
+   d-name) == 0) {
+   filename = d-name;
+   break;
+   }
+   }
+   break;
}
if (fsmatch == 0 || (filename == NULL  fsflg == 0))
return;

-- 
wbr,
pluknet


fstat_un.diff
Description: Binary data
___
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: Improving the FreeBSD-9 boot menu

[Sergey Kandaurov]

On 21 September 2011 05:46, Warren Block wbl...@wonkity.com wrote:
 The patch in PR 160818 makes some clarifications and improvements to the new
 boot menu.  Obviously this is not for 9.0-RELEASE, just wanting to get it
 out there so people can look at it.

 http://www.freebsd.org/cgi/query-pr.cgi?pr=160818


I just committed it to head and will merge it to stable/9 in 1 week.
Thanks!

-- 
wbr,
pluknet
___
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: CARP on -CURRENT

[Sergey Kandaurov]

On 19 January 2012 00:54, Andrew Hobbs andrew.ho...@ai.net wrote:
 Is CARP implemented on -CURRENT (FreeBSD 10)?

 I'm playing around with some test boxes in the office running -CURRENT;
 testbox# uname -a
 FreeBSD testbox.ai.net 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Wed Jan 18 
 19:21:12 EST 2012     r...@testbox.ai.net:/usr/obj/usr/src/sys/CARP  amd64

 I can't seem to create a carp interface despite having compiled a kernel with 
 device      carp in it. Attempts to create a carp interface fail;
 # ifconfig carp create
 ifconfig: SIOCIFCREATE2: Invalid argument

 From what I've read in the handbook entry on CARP 
 (http://www.freebsd.org/doc/handbook/carp.html), I should be able to either 
 compile in the carp device, as above, or load the if_carp.ko kern module. 
 There doesn't appear to be a if_carp.ko module in the -CURRENT source tree, 
 however. Only the carp module itself;
 # ls -ald /usr/src/sys/modules/*carp*
 drwxr-xr-x  2 root  wheel  512 Dec 27 15:12 /usr/src/sys/modules/carp

 Am I missing something completely obvious? Was the functionality of 
 if_carp.ko rolled into another module?

You should definitely read this changeset:
http://svn.freebsd.org/changeset/base/228571

and the updated carp ifconfig syntax in man carp. As for if_carp.ko,
it was renamed into carp.ko as part of the CARP implementation overhaul.

This only affects CURRENT.

-- 
wbr,
pluknet
___
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] fix git detection code in newvers.sh when svn installed

[Sergey Kandaurov]

On 6 January 2012 21:50, Oliver Pinter pin...@tresorium.hu wrote:
 Hi All!

 When svn installed and the source stored in git, then now the version
 detection failed. The attached patch fixed this situation.


FWIW, a different version proposed by Maciej Milewski on -current
some time ago. I don't have/use git, so I cannot test these changes.
It is good in the sense that it doesn't duplicate a search path.
The patch is below for reference:

--- sys/conf/newvers.sh 2011-11-19 00:56:50.795815738 +0100
+++ sys/conf/newvers-patched.sh 2011-11-19 00:58:21.187818982 +0100
@@ -88,14 +88,14 @@
 i=`${MAKE:-make} -V KERN_IDENT`

 for dir in /bin /usr/bin /usr/local/bin; do
-   if [ -x ${dir}/svnversion ] ; then
-   svnversion=${dir}/svnversion
-   break
-   fi
if [ -d ${SYSDIR}/../.git -a -x ${dir}/git ] ; then
git_cmd=${dir}/git --git-dir=${SYSDIR}/../.git
break
fi
+   if [ -x ${dir}/svnversion ] ; then
+   svnversion=${dir}/svnversion
+   break
+   fi
 done

 if [ -n $svnversion ] ; then


-- 
wbr,
pluknet
___
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: [head tinderbox] failure on amd64/amd64

[Sergey Kandaurov]

On 24 December 2011 03:39, FreeBSD Tinderbox tinder...@freebsd.org wrote:
 TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on 
 freebsd-current.sentex.ca
 TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for amd64/amd64
 TB --- 2011-12-23 19:00:00 - cleaning the object tree
 TB --- 2011-12-23 19:00:50 - cvsupping the source tree
 TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
 /tinderbox/HEAD/amd64/amd64/supfile
 TB --- 2011-12-23 19:01:13 - building world
 TB --- 2011-12-23 19:01:13 - CROSS_BUILD_TESTING=YES
 TB --- 2011-12-23 19:01:13 - MAKEOBJDIRPREFIX=/obj
 TB --- 2011-12-23 19:01:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2011-12-23 19:01:13 - SRCCONF=/dev/null
 TB --- 2011-12-23 19:01:13 - TARGET=amd64
 TB --- 2011-12-23 19:01:13 - TARGET_ARCH=amd64
 TB --- 2011-12-23 19:01:13 - TZ=UTC
 TB --- 2011-12-23 19:01:13 - __MAKE_CONF=/dev/null
 TB --- 2011-12-23 19:01:13 - cd /src
 TB --- 2011-12-23 19:01:13 - /usr/bin/make -B buildworld
 World build started on Fri Dec 23 19:01:14 UTC 2011
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 stage 5.1: building 32 bit shim libraries
 World build completed on Fri Dec 23 21:40:55 UTC 2011
 TB --- 2011-12-23 21:40:55 - generating LINT kernel config
 TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 21:40:55 - /usr/bin/make -B LINT
 TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 21:40:55 - /usr/sbin/config -m LINT
 TB --- 2011-12-23 21:40:55 - building LINT kernel
 TB --- 2011-12-23 21:40:55 - CROSS_BUILD_TESTING=YES
 TB --- 2011-12-23 21:40:55 - MAKEOBJDIRPREFIX=/obj
 TB --- 2011-12-23 21:40:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2011-12-23 21:40:55 - SRCCONF=/dev/null
 TB --- 2011-12-23 21:40:55 - TARGET=amd64
 TB --- 2011-12-23 21:40:55 - TARGET_ARCH=amd64
 TB --- 2011-12-23 21:40:55 - TZ=UTC
 TB --- 2011-12-23 21:40:55 - __MAKE_CONF=/dev/null
 TB --- 2011-12-23 21:40:55 - cd /src
 TB --- 2011-12-23 21:40:55 - /usr/bin/make -B buildkernel KERNCONF=LINT
 Kernel build for LINT started on Fri Dec 23 21:40:55 UTC 2011
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT completed on Fri Dec 23 22:10:55 UTC 2011
 TB --- 2011-12-23 22:10:55 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 22:10:55 - /usr/sbin/config -m LINT-NOINET
 TB --- 2011-12-23 22:10:56 - building LINT-NOINET kernel
 TB --- 2011-12-23 22:10:56 - CROSS_BUILD_TESTING=YES
 TB --- 2011-12-23 22:10:56 - MAKEOBJDIRPREFIX=/obj
 TB --- 2011-12-23 22:10:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2011-12-23 22:10:56 - SRCCONF=/dev/null
 TB --- 2011-12-23 22:10:56 - TARGET=amd64
 TB --- 2011-12-23 22:10:56 - TARGET_ARCH=amd64
 TB --- 2011-12-23 22:10:56 - TZ=UTC
 TB --- 2011-12-23 22:10:56 - __MAKE_CONF=/dev/null
 TB --- 2011-12-23 22:10:56 - cd /src
 TB --- 2011-12-23 22:10:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
 Kernel build for LINT-NOINET started on Fri Dec 23 22:10:56 UTC 2011
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT-NOINET completed on Fri Dec 23 22:39:01 UTC 2011
 TB --- 2011-12-23 22:39:01 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 22:39:01 - /usr/sbin/config -m LINT-NOINET6
 TB --- 2011-12-23 22:39:01 - building LINT-NOINET6 kernel
 TB --- 2011-12-23 22:39:01 - CROSS_BUILD_TESTING=YES
 TB --- 2011-12-23 22:39:01 - MAKEOBJDIRPREFIX=/obj
 TB --- 2011-12-23 22:39:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2011-12-23 22:39:01 - SRCCONF=/dev/null
 TB --- 2011-12-23 22:39:01 - TARGET=amd64
 TB --- 2011-12-23 22:39:01 - TARGET_ARCH=amd64
 TB --- 2011-12-23 22:39:01 - TZ=UTC
 TB --- 2011-12-23 22:39:01 - __MAKE_CONF=/dev/null
 TB --- 2011-12-23 22:39:01 - cd /src
 TB --- 2011-12-23 22:39:01 - /usr/bin/make -B buildkernel 
 KERNCONF=LINT-NOINET6
 Kernel build for LINT-NOINET6 started on Fri Dec 23 22:39:01 UTC 2011
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT-NOINET6 completed on Fri Dec 23 23:08:33 UTC 2011
 TB --- 2011-12-23 23:08:33 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 23:08:33 - /usr/sbin/config -m LINT-NOIP
 TB --- 2011-12-23 23:08:33 - building LINT-NOIP kernel
 TB --- 2011-12-23 23:08:33 - CROSS_BUILD_TESTING=YES
 TB --- 2011-12-23 23:08:33 - 

Re: [head tinderbox] failure on amd64/amd64

[Sergey Kandaurov]

On 24 December 2011 04:02, Sergey Kandaurov pluk...@gmail.com wrote:
 On 24 December 2011 03:39, FreeBSD Tinderbox tinder...@freebsd.org wrote:
 TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on 
 freebsd-current.sentex.ca
 TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for amd64/amd64
 TB --- 2011-12-23 19:00:00 - cleaning the object tree
 TB --- 2011-12-23 19:00:50 - cvsupping the source tree
 TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h 
 cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile
 TB --- 2011-12-23 19:01:13 - building world
 TB --- 2011-12-23 19:01:13 - CROSS_BUILD_TESTING=YES
 TB --- 2011-12-23 19:01:13 - MAKEOBJDIRPREFIX=/obj
 TB --- 2011-12-23 19:01:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2011-12-23 19:01:13 - SRCCONF=/dev/null
 TB --- 2011-12-23 19:01:13 - TARGET=amd64
 TB --- 2011-12-23 19:01:13 - TARGET_ARCH=amd64
 TB --- 2011-12-23 19:01:13 - TZ=UTC
 TB --- 2011-12-23 19:01:13 - __MAKE_CONF=/dev/null
 TB --- 2011-12-23 19:01:13 - cd /src
 TB --- 2011-12-23 19:01:13 - /usr/bin/make -B buildworld
 World build started on Fri Dec 23 19:01:14 UTC 2011
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 stage 5.1: building 32 bit shim libraries
 World build completed on Fri Dec 23 21:40:55 UTC 2011
 TB --- 2011-12-23 21:40:55 - generating LINT kernel config
 TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 21:40:55 - /usr/bin/make -B LINT
 TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 21:40:55 - /usr/sbin/config -m LINT
 TB --- 2011-12-23 21:40:55 - building LINT kernel
 TB --- 2011-12-23 21:40:55 - CROSS_BUILD_TESTING=YES
 TB --- 2011-12-23 21:40:55 - MAKEOBJDIRPREFIX=/obj
 TB --- 2011-12-23 21:40:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2011-12-23 21:40:55 - SRCCONF=/dev/null
 TB --- 2011-12-23 21:40:55 - TARGET=amd64
 TB --- 2011-12-23 21:40:55 - TARGET_ARCH=amd64
 TB --- 2011-12-23 21:40:55 - TZ=UTC
 TB --- 2011-12-23 21:40:55 - __MAKE_CONF=/dev/null
 TB --- 2011-12-23 21:40:55 - cd /src
 TB --- 2011-12-23 21:40:55 - /usr/bin/make -B buildkernel KERNCONF=LINT
 Kernel build for LINT started on Fri Dec 23 21:40:55 UTC 2011
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT completed on Fri Dec 23 22:10:55 UTC 2011
 TB --- 2011-12-23 22:10:55 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 22:10:55 - /usr/sbin/config -m LINT-NOINET
 TB --- 2011-12-23 22:10:56 - building LINT-NOINET kernel
 TB --- 2011-12-23 22:10:56 - CROSS_BUILD_TESTING=YES
 TB --- 2011-12-23 22:10:56 - MAKEOBJDIRPREFIX=/obj
 TB --- 2011-12-23 22:10:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2011-12-23 22:10:56 - SRCCONF=/dev/null
 TB --- 2011-12-23 22:10:56 - TARGET=amd64
 TB --- 2011-12-23 22:10:56 - TARGET_ARCH=amd64
 TB --- 2011-12-23 22:10:56 - TZ=UTC
 TB --- 2011-12-23 22:10:56 - __MAKE_CONF=/dev/null
 TB --- 2011-12-23 22:10:56 - cd /src
 TB --- 2011-12-23 22:10:56 - /usr/bin/make -B buildkernel 
 KERNCONF=LINT-NOINET
 Kernel build for LINT-NOINET started on Fri Dec 23 22:10:56 UTC 2011
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT-NOINET completed on Fri Dec 23 22:39:01 UTC 2011
 TB --- 2011-12-23 22:39:01 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 22:39:01 - /usr/sbin/config -m LINT-NOINET6
 TB --- 2011-12-23 22:39:01 - building LINT-NOINET6 kernel
 TB --- 2011-12-23 22:39:01 - CROSS_BUILD_TESTING=YES
 TB --- 2011-12-23 22:39:01 - MAKEOBJDIRPREFIX=/obj
 TB --- 2011-12-23 22:39:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2011-12-23 22:39:01 - SRCCONF=/dev/null
 TB --- 2011-12-23 22:39:01 - TARGET=amd64
 TB --- 2011-12-23 22:39:01 - TARGET_ARCH=amd64
 TB --- 2011-12-23 22:39:01 - TZ=UTC
 TB --- 2011-12-23 22:39:01 - __MAKE_CONF=/dev/null
 TB --- 2011-12-23 22:39:01 - cd /src
 TB --- 2011-12-23 22:39:01 - /usr/bin/make -B buildkernel 
 KERNCONF=LINT-NOINET6
 Kernel build for LINT-NOINET6 started on Fri Dec 23 22:39:01 UTC 2011
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT-NOINET6 completed on Fri Dec 23 23:08:33 UTC 2011
 TB --- 2011-12-23 23:08:33 - cd /src/sys/amd64/conf
 TB --- 2011-12-23 23:08:33 - /usr/sbin/config -m LINT-NOIP
 TB --- 2011-12-23 23:08:33 - building LINT-NOIP kernel
 TB --- 2011

Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?

[Sergey Kandaurov]

On 1 December 2011 10:20, Milan Obuch freebsd-curr...@dino.sk wrote:
 On Tue, 29 Nov 2011 19:22:39 +0300
 Sergey Kandaurov pluk...@gmail.com wrote:

 On 29 November 2011 20:16, Maxim Khitrov m...@mxcrypt.com wrote:
  On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov
  pluk...@gmail.com wrote:
  On 26 November 2011 11:44, Milan Obuch freebsd-curr...@dino.sk
  wrote:
  Hi,
 
  I am playing a bit with 9.0-PRERELEASE compiling it from source
  updated via csup. In both example files there is line specifying
  what to csup
 
  *default release=cvs tag=RELENG_8
 
  which is incorrect, I think. It is convenient for me to issue just
 
  csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile
 
  to update full sources without need to create any cvsup config
  file, however in system installed from 9.0 snapshot (maybe two
  weeks old) this file points to version 8 files, so I need to
  correct it for 9.0-PRERELEASE to not accidentally download older
  version sources.
 
  The same is also true after upgrade from source - make
  installworld install example files pointing to older version...
 
  Is it something I do not know about or is it an oversight? I
  think this line should already be changed to new tag...
 
  *default release=cvs tag=RELENG_9
 
  Hi.
 
  Fixed. Thanks for your report.
  Now cvs tag points to RELENG_9 in 9.x sources.
 
  Should standard-supfile also be updated to point to RELENG_9_0? I'm
  using csup with tag=RELENG_9_0 and standard-supfile still points
  to HEAD.

 Yep, sure.
 I just sent a request to the Release Engineering Team.


 It works for me now as expected, thanks.

 Anyway, there is a question what the difference between stable-supfile
 and standard-supfile should be. I looked in my local csupped sources,
 they are the same in 6-STABLE (OK, some history here), 7-STABLE,
 8-STABLE and 9-STABLE. Are they expected to be used differently?

In STABLE branches standard-supfile and stable-supfile are used to have
the same cvs tag. FYI, compare how it is done in RELEASE branches.

 And, second one - what about CURRENT? In stable-supfile I see
 tag=RELENG_9 which is not quite clear, but just for some pedantry... I
 use standard-supfile for CURRENT, so this is not an issue for me either.

To my knowledge, in CURRENT a standard-supfile's cvs tag should be
read as the latest (i.e. the most recently created) stable branch.

-- 
wbr,
pluknet
___
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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?

[Sergey Kandaurov]

On 1 December 2011 13:17, Kostik Belousov kostik...@gmail.com wrote:
 On Thu, Dec 01, 2011 at 12:12:18PM +0300, Sergey Kandaurov wrote:
 On 1 December 2011 10:20, Milan Obuch freebsd-curr...@dino.sk wrote:
  On Tue, 29 Nov 2011 19:22:39 +0300
  Sergey Kandaurov pluk...@gmail.com wrote:
 
  On 29 November 2011 20:16, Maxim Khitrov m...@mxcrypt.com wrote:
   On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov
   pluk...@gmail.com wrote:
   On 26 November 2011 11:44, Milan Obuch freebsd-curr...@dino.sk
   wrote:
   Hi,
  
   I am playing a bit with 9.0-PRERELEASE compiling it from source
   updated via csup. In both example files there is line specifying
   what to csup
  
   *default release=cvs tag=RELENG_8
  
   which is incorrect, I think. It is convenient for me to issue just
  
   csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile
  
   to update full sources without need to create any cvsup config
   file, however in system installed from 9.0 snapshot (maybe two
   weeks old) this file points to version 8 files, so I need to
   correct it for 9.0-PRERELEASE to not accidentally download older
   version sources.
  
   The same is also true after upgrade from source - make
   installworld install example files pointing to older version...
  
   Is it something I do not know about or is it an oversight? I
   think this line should already be changed to new tag...
  
   *default release=cvs tag=RELENG_9
  
   Hi.
  
   Fixed. Thanks for your report.
   Now cvs tag points to RELENG_9 in 9.x sources.
  
   Should standard-supfile also be updated to point to RELENG_9_0? I'm
   using csup with tag=RELENG_9_0 and standard-supfile still points
   to HEAD.
 
  Yep, sure.
  I just sent a request to the Release Engineering Team.
 
 
  It works for me now as expected, thanks.
 
  Anyway, there is a question what the difference between stable-supfile
  and standard-supfile should be. I looked in my local csupped sources,
  they are the same in 6-STABLE (OK, some history here), 7-STABLE,
  8-STABLE and 9-STABLE. Are they expected to be used differently?

 In STABLE branches standard-supfile and stable-supfile are used to have
 the same cvs tag. FYI, compare how it is done in RELEASE branches.

  And, second one - what about CURRENT? In stable-supfile I see
  tag=RELENG_9 which is not quite clear, but just for some pedantry... I
  use standard-supfile for CURRENT, so this is not an issue for me either.

 To my knowledge, in CURRENT a standard-supfile's cvs tag should be
 read as the latest (i.e. the most recently created) stable branch.
 Could the supfiles be generated from some value in newvers.sh ?

I have no idea how it could be done gracefully, sorry.

But I like how it is done in www/.
Here are several defined entities used elsewhere in docwww.
!ENTITY rel.head.major '10'
!ENTITY betarel.vers 'RC2'
!ENTITY rel.current.major '8'
!ENTITY rel.current.date 'February 2011'
and so on.

-- 
wbr,
pluknet
___
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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?

[Sergey Kandaurov]

On 26 November 2011 11:44, Milan Obuch freebsd-curr...@dino.sk wrote:
 Hi,

 I am playing a bit with 9.0-PRERELEASE compiling it from source updated
 via csup. In both example files there is line specifying what to csup

 *default release=cvs tag=RELENG_8

 which is incorrect, I think. It is convenient for me to issue just

 csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile

 to update full sources without need to create any cvsup config file,
 however in system installed from 9.0 snapshot (maybe two weeks old)
 this file points to version 8 files, so I need to correct it for
 9.0-PRERELEASE to not accidentally download older version sources.

 The same is also true after upgrade from source - make installworld
 install example files pointing to older version...

 Is it something I do not know about or is it an oversight? I think this
 line should already be changed to new tag...

 *default release=cvs tag=RELENG_9

Hi.

Fixed. Thanks for your report.
Now cvs tag points to RELENG_9 in 9.x sources.

-- 
wbr,
pluknet
___
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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?

[Sergey Kandaurov]

On 29 November 2011 20:16, Maxim Khitrov m...@mxcrypt.com wrote:
 On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov pluk...@gmail.com wrote:
 On 26 November 2011 11:44, Milan Obuch freebsd-curr...@dino.sk wrote:
 Hi,

 I am playing a bit with 9.0-PRERELEASE compiling it from source updated
 via csup. In both example files there is line specifying what to csup

 *default release=cvs tag=RELENG_8

 which is incorrect, I think. It is convenient for me to issue just

 csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile

 to update full sources without need to create any cvsup config file,
 however in system installed from 9.0 snapshot (maybe two weeks old)
 this file points to version 8 files, so I need to correct it for
 9.0-PRERELEASE to not accidentally download older version sources.

 The same is also true after upgrade from source - make installworld
 install example files pointing to older version...

 Is it something I do not know about or is it an oversight? I think this
 line should already be changed to new tag...

 *default release=cvs tag=RELENG_9

 Hi.

 Fixed. Thanks for your report.
 Now cvs tag points to RELENG_9 in 9.x sources.

 Should standard-supfile also be updated to point to RELENG_9_0? I'm
 using csup with tag=RELENG_9_0 and standard-supfile still points to
 HEAD.

Yep, sure.
I just sent a request to the Release Engineering Team.

-- 
wbr,
pluknet
___
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: LOR in route.c // scope6.c

[Sergey Kandaurov]

On 19 August 2011 05:07, Garrett Cooper yaneg...@gmail.com wrote:
 Hi,
    I've periodically seen the following LOR when trying to repro a
 panic after restarting my network configuration:

 :lock order reversal:
  1st 0xc4142f1c rtentry (rtentry) @ /usr/src/sys/net/routec:362
  2nd 0xc3d08604 if_afdata (if_afdata) @ /usr/src/sys/netinet6/scope6.c:417
 KDB: stack backtrace:
 db_trace_self_wrapper(...)
 _witness_debugger(...)
 _rw_wlock(...)
 in6_setscope(...)
 in6_purgeaddr(...)
 in6_control(...)
 ifioctl(...)
 soo_ioctl(...)
 kern_ioctl(...)
 ioctl(...)
 syscallenter(...)
 syscall(...)
 Xint0x80_syscall()

 I don't have a full backtrace or core for this. This was running
 r224948 UP with WITNESS.


I just got exactly the same LOR on a very fresh current with
/etc/rc.d/netif restart, and then I lost the system.
Thanks for the report. I hope to dig out the solution...

-- 
wbr,
pluknet
___
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: Dtrace: type mismatch in sys/kern/kern_sig.c

[Sergey Kandaurov]

On 19 September 2011 19:24, Anton Yuzhaninov cit...@citrin.ru wrote:
 In the file sys/kern/kern_sig.c defined DTrace probe proc:::signal-discard

 SDT_PROBE_DEFINE(proc, kernel, , signal_discard, signal-discard);
 SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 0, struct thread *);
 SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 1, struct proc *);
 SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 2, int);

 Then latter this proble called as:

 SDT_PROBE(proc, kernel, , signal_discard, ps, td, sig, 0, 0 );

 type for var ps is struct sigacts* =! struct thread * (bug?)
 type for var td is struct thread * =! struct proc * (bug?)
 type for var sig is int == int (ok)

 To match solaris DTrace probe shuild called as:

 SDT_PROBE(proc, kernel, , signal_discard, td, p, sig, 0, 0 );


Yes, seems a typo there. Also conforms to the Solaris Dynamic Tracing Guide:
http://download.oracle.com/docs/cd/E19082-01/819-3620/gelse/index.html

(Also, td and p are somewhat different wrt. psinfo_t and lwpsinfo_t in Solaris).

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

Re: FreeBSD 9.0 and 4-socket Intel XEON E7-4870 system -- 80 logical CPUs

[Sergey Kandaurov]

On 8 September 2011 02:27, Hartmann, O. ohart...@zedat.fu-berlin.de wrote:

   Watching the ncpu number, I realized that FreeBSD is limited to 64
   processors.
   Some vendors offer now 4-socket Intel Xeon E7-4870 systems. This
   Westmere
   based CPU has 10 physical  and 20 logical cores, summa summarum 80
   cores.
   Is FreeBSD 9.0 capable of handling such a server?

See kernel option MAXCPU and its description in NOTES.

-- 
wbr,
pluknet
___
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: Kernel panic at boot after an upgrade from 9.0-BETA1 to 9.0-BETA2

[Sergey Kandaurov]

On 2 September 2011 15:41, Piotr Kubaj freebsd.current.l...@gmail.com wrote:
 1. It's in the dump file.
 2. In BEASTIE.
 3. As I wrote before, 9.0-BETA1, but I had used this kernel with 8.2-RELEASE
 and 8.2-STABLE (only did slight modifications for 9.0).
 4. I'm not really into it, what exactly do you mean?

I see from your dmesg in the dump file that you use cuse4bsd and vbox 3rd-party
kernel modules. Probably they do not cope with changes in kernel between BETAs.
Try to boot without them.

-- 
wbr,
pluknet
___
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: http://www.freebsd.org/marketing/os-comparison.html

[Sergey Kandaurov]

On 30 August 2011 13:13, Hartmann, O. ohart...@zedat.fu-berlin.de wrote:
 On 08/30/11 09:29, Hans Petter Selasky wrote:

 On Monday 29 August 2011 21:58:29 Volodymyr Kostyrko wrote:

 27.08.2011 22:13, Hartmann, O. wrote:

 This website should be brushed up or taken offline!
 It seems full of vintage stuff from glory days.

 http://www.freebsd.org/marketing/os-comparison.html

 I think this one would better look like list of major features with os
 comparison, like:

 = Networking =
   * IPv6: major support, best stack around.
   * SCTP: full kernel implementation, still no userland support (i.e.
 ssh doesn't work over sctp by default yet).

 = Data storage =
   * ZFS: full support, datasets, compression, dedup, other stuff. Linux
 has LVM (?features...) and btrfs (?unstable.. ?features..), Windows has
 dynamic disks since XP (?features).

 = SMP =
   * (?something about comparing other shedulers with SCHED_ULE), (?some
 rt stuff), (?some comparison with other interesting shedulers, like
 DragonflyBSD and QNX).

 And USB. I believe there are significant changes in the USB subsystems
 which
 those who are making performance benchmarks completely fail to mention.

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

 What's about DTrace?

 = Development/System Profiling =
  * DTrace: Some notes of the Kernel Gurus what this could mean for
 performance profiling and development

 = Licensing Model =
  * Some striking comments on the advantage for companies or interested
 people of the BSD-like licensing model over the GPLv3 on which Linux is
 based now and which has serious implications for those who wants to develop
 and sell software developed on/with GNU stuff. it would be very honest, if
 we do not only emphasize only the pros. BSD came from the academic
 environment, that was where I met it the first time and I appreciated the
 way things were developed and 'sloppyness' was a nogo. So we should keep it
 up and a serious and honest set of contraru points for all compared OS
 should be appreciable.


 Does the VM of FreeBSD still have advantges (measurable) over Linux?

[Taking random email.]

I think we could merge the $subj web page with this one (which is
more actual, as of 7.0): http://www.freebsd.org/features.html

-- 
wbr,
pluknet
___
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 with 9.0 Beta 1 (arcmsr.c)

[Sergey Kandaurov]

On 23 August 2011 14:57, Uwe Grohnwaldt u...@grohnwaldt.eu wrote:
 Hi,

 i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped with a
 kernel panic:

 panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q buffer lock
 @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093

 A screenshot from the panic can be found here:
 http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png

HI, that should be fixed in head (and in forthcoming BETA2).
You can apply this patch from head to fix panic:
http://svnweb.freebsd.org/base/head/sys/dev/arcmsr/arcmsr.c?view=patchr1=224905r2=224904pathrev=224905


-- 
wbr,
pluknet
___
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: BETA1 IPv6 crash

[Sergey Kandaurov]

On 8 August 2011 22:06, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote:
 2011/8/7 Sergey Kandaurov pluk...@gmail.com:
 On 7 August 2011 17:11, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote:
 I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the
 new installer.

 Major issue I noticed was the missing /home.

 It took me quite some time to get IPv6 working in the guest (a Linux
 configuration issue), but now that it works
 BETA1 panics in about 50% of the boot attempts:

 testbsd dumped core - see /var/crash/vmcore.0

 Sun Aug  7 08:25:28 CEST 2011

 FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16
 UTC 2011     r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
 i386

 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
 /usr/src/sys/netinet6/mld6.c:1676

 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-marcel-freebsd...
 [..]
 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
 /usr/src/sys/netinet6/mld6.c:1676

 cpuid = 0
 KDB: enter: panic
 Uptime: 28s
 Physical memory: 491 MB
 Dumping 45 MB: 30 14

 #0  doadump (textdump=1) at pcpu.h:244
 244     pcpu.h: No such file or directory.
        in pcpu.h
 (kgdb) #0  doadump (textdump=1) at pcpu.h:244
 #1  0xc0a04965 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:430
 #2  0xc0a04291 in panic (fmt=Variable fmt is not available.
 ) at /usr/src/sys/kern/kern_shutdown.c:595
 #3  0xc09f4a4a in _mtx_lock_sleep (m=0xc35f3a28, tid=3278693824, opts=0,
    file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676)
    at /usr/src/sys/kern/kern_mutex.c:341
 #4  0xc09f4c67 in _mtx_lock_flags (m=0xc35f3a28, opts=0,
    file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676)
    at /usr/src/sys/kern/kern_mutex.c:203
 #5  0xc0bbf007 in mld_set_version (mli=0xc3589a00, version=Variable
 version is not available.
 )
    at /usr/src/sys/netinet6/mld6.c:1676
 #6  0xc0bc0c00 in mld_input (m=0xc3951e00, off=48, icmp6len=24)
    at /usr/src/sys/netinet6/mld6.c:690
 #7  0xc0ba5696 in icmp6_input (mp=0xc3313a54, offp=0xc3313a68, proto=58)
    at /usr/src/sys/netinet6/icmp6.c:654
 #8  0xc0bba23a in ip6_input (m=0xc3951e00)
    at /usr/src/sys/netinet6/ip6_input.c:964
 #9  0xc0ac9b1c in netisr_dispatch_src (proto=10, source=0, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1013
 #10 0xc0ac9da0 in netisr_dispatch (proto=10, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1104
 #11 0xc0abecf1 in ether_demux (ifp=0xc35f3800, m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:936
 #12 0xc0abf1b3 in ether_nh_input (m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:755
 #13 0xc0ac9b1c in netisr_dispatch_src (proto=9, source=0, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1013
 #14 0xc0ac9da0 in netisr_dispatch (proto=9, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1104
 #15 0xc0abe7f5 in ether_input (ifp=0xc35f3800, m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:796
 #16 0xc0672bc9 in lem_handle_rxtx (context=0xc3732000, pending=1)
    at /usr/src/sys/dev/e1000/if_lem.c:3554
 #17 0xc0a468ab in taskqueue_run_locked (queue=0xc359ca80)
    at /usr/src/sys/kern/subr_taskqueue.c:306
 #18 0xc0a47307 in taskqueue_thread_loop (arg=0xc37365ec)
    at /usr/src/sys/kern/subr_taskqueue.c:495
 #19 0xc09d7af8 in fork_exit (callout=0xc0a472a0 taskqueue_thread_loop,
    arg=0xc37365ec, frame=0xc3313d28) at /usr/src/sys/kern/kern_fork.c:941
 #20 0xc0d1d714 in fork_trampoline () at 
 /usr/src/sys/i386/i386/exception.s:275
 (kgdb)


 This is the same as in PR kern/158426.
 Can you try the patch from PR followup and report us whether it helps?
 Full link to PR with patch:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/158426


 I applied the patch and tried about 15 reboots and all went fine


Hi, Tom.
A better fix for this problem has been developed since then. Would you
please try it as well? For doing that, you need to revert a previous
patch and apply this one.
Please report if this change also fixes the panic for you, so it  has
better chances to get into 9.0 release.


Index: sys/netinet6/mld6.c
===
--- sys/netinet6/mld6.c (revision 224471)
+++ sys/netinet6/mld6.c (working copy)
@@ -680,7 +680,6 @@ mld_v1_input_query(struct ifnet *ifp, const struct

IN6_MULTI_LOCK();
MLD_LOCK();
-   IF_ADDR_LOCK(ifp);

/*
 * Switch to MLDv1 host compatibility mode.
@@ -693,6 +692,7 @@ mld_v1_input_query(struct ifnet *ifp, const struct
if (timer == 0)
timer = 1;

+   IF_ADDR_LOCK(ifp);
if (is_general_query

Re: kernel build failure without BPF

[Sergey Kandaurov]

On 14 August 2011 06:01, deeptec...@gmail.com deeptec...@gmail.com wrote:
 in the following kernel configuration (notably without ``device
 bfp''), i get the following kernel build error. which is either a bug,
 or not; just posting in case it's in someone's interest.

  build log snippet begins 
 === pfsync (all)

 cc -O2 -fno-strict-aliasing -pipe -march=pentium4 -Werror -D_KERNEL
 -DKLD_MODULE -nostdinc  -I/usr/src/sys/modules/pfsync/../../contrib/pf
 -DHAVE_KERNEL_OPTION_HEADERS -include
 /usr/obj/usr/src/sys/HQ/opt_global.h -I. -I@ -I@/contrib/altq
 -finline-limit=8000 --param inline-unit-growth=100 --param
 large-function-growth=1000 -fno-common  -I/usr/obj/usr/src/sys/HQ
 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx
 -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999
 -fstack-protector -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
 -Wmissing-include-dirs -fdiagnostics-show-option -c
 /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c

 /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c: In
 function 'pfsync_sendout':

 /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:2163:
 error: 'm' undeclared (first use in this function)

 /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:2163:
 error: (Each undeclared identifier is reported only once

 /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:2163:
 error: for each function it appears in.)

 *** Error code 1



 Stop in /usr/src/sys/modules/pfsync.

 *** Error code 1

This is due to mismerge of pf4.5.
The following patch shall fix the build:

Index: sys/contrib/pf/net/if_pfsync.c
===
--- sys/contrib/pf/net/if_pfsync.c  (revision 224568)
+++ sys/contrib/pf/net/if_pfsync.c  (working copy)
@@ -2126,8 +2126,8 @@ pfsync_sendout(void)
 #else
struct ifnet *ifp = sc-sc_if;
 #endif
+#endif
struct mbuf *m;
-#endif
struct ip *ip;
struct pfsync_header *ph;
struct pfsync_subheader *subh;

-- 
wbr,
pluknet
___
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: duplicate output when dumping from ddb

[Sergey Kandaurov]

On 10 August 2011 23:04, Navdeep Parhar npar...@gmail.com wrote:
 dump or call doadump from within ddb display duplicate output.
 This is with a serial console.  I have  console=comconsole,vidconsole
 in /boot/loader.conf and  -D -S115200  in /boot.config.

 db dump
 Dumping 1883 out of 12255 MB:Dumping 1883 out of 12255
 MB:..1%..1%..11%..11%..21%..21%..31%..31%..41%..41%..51%..51%..61%..61%..71%..71%..81%..81%..91%..91%

 Dump complete
 Dump complete
 db

 Something seems to have changed in the last couple of months or so.


Just to confirm with my Same here. I use a serial console with same
settings, too. I am out of ideas how to fix it though.

-- 
wbr,
pluknet
___
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: BETA1 IPv6 crash

[Sergey Kandaurov]

On 7 August 2011 17:11, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote:
 I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the
 new installer.

 Major issue I noticed was the missing /home.

 It took me quite some time to get IPv6 working in the guest (a Linux
 configuration issue), but now that it works
 BETA1 panics in about 50% of the boot attempts:

 testbsd dumped core - see /var/crash/vmcore.0

 Sun Aug  7 08:25:28 CEST 2011

 FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16
 UTC 2011     r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
 i386

 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
 /usr/src/sys/netinet6/mld6.c:1676

 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-marcel-freebsd...
[..]
 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
 /usr/src/sys/netinet6/mld6.c:1676

 cpuid = 0
 KDB: enter: panic
 Uptime: 28s
 Physical memory: 491 MB
 Dumping 45 MB: 30 14

 #0  doadump (textdump=1) at pcpu.h:244
 244     pcpu.h: No such file or directory.
        in pcpu.h
 (kgdb) #0  doadump (textdump=1) at pcpu.h:244
 #1  0xc0a04965 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:430
 #2  0xc0a04291 in panic (fmt=Variable fmt is not available.
 ) at /usr/src/sys/kern/kern_shutdown.c:595
 #3  0xc09f4a4a in _mtx_lock_sleep (m=0xc35f3a28, tid=3278693824, opts=0,
    file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676)
    at /usr/src/sys/kern/kern_mutex.c:341
 #4  0xc09f4c67 in _mtx_lock_flags (m=0xc35f3a28, opts=0,
    file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676)
    at /usr/src/sys/kern/kern_mutex.c:203
 #5  0xc0bbf007 in mld_set_version (mli=0xc3589a00, version=Variable
 version is not available.
 )
    at /usr/src/sys/netinet6/mld6.c:1676
 #6  0xc0bc0c00 in mld_input (m=0xc3951e00, off=48, icmp6len=24)
    at /usr/src/sys/netinet6/mld6.c:690
 #7  0xc0ba5696 in icmp6_input (mp=0xc3313a54, offp=0xc3313a68, proto=58)
    at /usr/src/sys/netinet6/icmp6.c:654
 #8  0xc0bba23a in ip6_input (m=0xc3951e00)
    at /usr/src/sys/netinet6/ip6_input.c:964
 #9  0xc0ac9b1c in netisr_dispatch_src (proto=10, source=0, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1013
 #10 0xc0ac9da0 in netisr_dispatch (proto=10, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1104
 #11 0xc0abecf1 in ether_demux (ifp=0xc35f3800, m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:936
 #12 0xc0abf1b3 in ether_nh_input (m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:755
 #13 0xc0ac9b1c in netisr_dispatch_src (proto=9, source=0, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1013
 #14 0xc0ac9da0 in netisr_dispatch (proto=9, m=0xc3951e00)
    at /usr/src/sys/net/netisr.c:1104
 #15 0xc0abe7f5 in ether_input (ifp=0xc35f3800, m=0xc3951e00)
    at /usr/src/sys/net/if_ethersubr.c:796
 #16 0xc0672bc9 in lem_handle_rxtx (context=0xc3732000, pending=1)
    at /usr/src/sys/dev/e1000/if_lem.c:3554
 #17 0xc0a468ab in taskqueue_run_locked (queue=0xc359ca80)
    at /usr/src/sys/kern/subr_taskqueue.c:306
 #18 0xc0a47307 in taskqueue_thread_loop (arg=0xc37365ec)
    at /usr/src/sys/kern/subr_taskqueue.c:495
 #19 0xc09d7af8 in fork_exit (callout=0xc0a472a0 taskqueue_thread_loop,
    arg=0xc37365ec, frame=0xc3313d28) at /usr/src/sys/kern/kern_fork.c:941
 #20 0xc0d1d714 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275
 (kgdb)


This is the same as in PR kern/158426.
Can you try the patch from PR followup and report us whether it helps?
Full link to PR with patch:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/158426

-- 
wbr,
pluknet
___
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: FreeBSD9 ifnet + Member Function void (*if_watchdog)(struct ifnet *ifp)

[Sergey Kandaurov]

On 1 August 2011 03:09, Olli Hauer oha...@freebsd.org wrote:
 Hi,

 I just tried to build VMware modules for FreeBSD9-BETA1 and noticed
 the ifnet Member Function

  void (*if_watchdog)(struct ifnet *ifp)

 was removed from net/if_var.h.

 Is there a suggested replacement?

Per-ifnet watchdogs were transformed to private per-softc callout timer
in earlier 9.x. See this thread for details:
http://lists.freebsd.org/pipermail/freebsd-net/2009-November/023677.html


 PS:
 The man page for ifnet(9) does not reflect the remove of this
 (now missing) Member Function.

It is massively outdated. I plan to update it some day when I get
some more spare time/review.

-- 
wbr,
pluknet
___
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: issues with vmstat and latest HEAD

[Sergey Kandaurov]

On 27 July 2011 19:08, Brandon Gooch jamesbrandongo...@gmail.com wrote:
 On Jul 27, 2011 7:58 AM, Alexander Best arun...@freebsd.org wrote:

 On Tue Jul 26 11, Alexander Best wrote:
  hi there,
 
  'vmstat -m' and 'vmstat -z' report:
 
  otaku% vmstat -m
  vmstat: memstat_sysctl_malloc: Too many CPUs
  otaku% vmstat -z
  vmstat: memstat_sysctl_uma: Too many CPUs
 
  world and kernel are in sync. i'm running r224294 on amd64.

 please disregard this thread. there's a discussion on svn-src-head@ which
 deals
 with this issue.

 cheers.
 alex

 
  cheers.
  alex


 Do you have a link to the discussion handy?


A fix for vmstat will be committed after BETA1 announce.
Please be patient.

-- 
wbr,
pluknet
___
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: displaying thread id in top -H

[Sergey Kandaurov]

On 6 July 2011 13:19, Alexander Best arun...@freebsd.org wrote:
 hi there,

 any reason why bin/139389 hasn't been committed, yet? i think seeing the 
 thread
 id in top -H output is extremely useful!

I think the main reason is that tid takes a log of space (6 digits + 2 spaces),
and top already suffers from a lack of free columns.

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

Re: FreeBSD 9

[Sergey Kandaurov]

On 30 June 2011 20:11, Niclas Zeising niclas.zeis...@gmail.com wrote:
 On 2011-06-30 17:26, Tim Gustafson wrote:
 Hi,

 I've installed FreeBSD 9 on a new server because 8.2 doesn't have support 
 for the LSI SAS2008 controller.  I've also built the system as a ZFS-root 
 box, and I have to say that I'm quite happy with the disk performance: we're 
 getting about 500MB/s write and 675MB/s read.  All in all, I'm very happy 
 with FreeBSD 9.

 I have noticed two snafus that I thought I'd send to the group just as 
 feedback:

 
 2. secondary IP addresses on network interfaces don't seem to be working
 

 In my rc.conf, I have:

 ifconfig_bce0=1.2.3.4 netmask 255.255.252.0
 ifconfig_bce0_alias0=1.2.3.5 netmask 255.255.255.255

 but when the machine reboots, it only gets its primary IP address.


 I think you need something along the line of ifconfig_bce0_alias0=inet
 1.2.3.5 netmask ..., notice the 'inet', since aliasN can be used for
 both inet and inet6.
 HTH!

Exactly. Since SVN rev 197139 you need to explicitly specify the protocol
family before address in the ifconfig_IF_alias= string.


-- 
wbr,
pluknet
___
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: Intel snd

[Sergey Kandaurov]

On 22 June 2011 17:54, George Kontostanos gkontos.m...@gmail.com wrote:
 I was wondering if there are any issues lately with snd_hda since I am not
 able to load the module anymore.

 Jun 22 16:04:59 core2duo kernel: interface snd_hda.1 already present in the
 KLD 'kernel'!
 Jun 22 16:04:59 core2duo kernel: linker_load_file: Unsupported file type

Hi.
It is in GENERIC since svn r222980 (Jun 11).


-- 
wbr,
pluknet
___
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: Intel snd

[Sergey Kandaurov]

On 22 June 2011 18:30, George Kontostanos gkontos.m...@gmail.com wrote:
 Thanks, so I don't need to load sound.ko anymore either ?

Yes.


 On Wed, Jun 22, 2011 at 4:58 PM, Sergey Kandaurov pluk...@gmail.com wrote:

 On 22 June 2011 17:54, George Kontostanos gkontos.m...@gmail.com wrote:
  I was wondering if there are any issues lately with snd_hda since I am
  not
  able to load the module anymore.
 
  Jun 22 16:04:59 core2duo kernel: interface snd_hda.1 already present in
  the
  KLD 'kernel'!
  Jun 22 16:04:59 core2duo kernel: linker_load_file: Unsupported file type

 Hi.
 It is in GENERIC since svn r222980 (Jun 11).


 --
 wbr,
 pluknet



 --
 George Kontostanos
 aisecure.net





-- 
wbr,
pluknet
___
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 commit: r214611 - head/sys/kern

[Sergey Kandaurov]

On 1 November 2010 03:42, David Xu davi...@freebsd.org wrote:
 Author: davidxu
 Date: Mon Nov  1 00:42:25 2010
 New Revision: 214611
 URL: http://svn.freebsd.org/changeset/base/214611

 Log:
  Use integer for size of cpuset, as it won't be bigger than INT_MAX,
  This is requested by bge.
  Also move the sysctl into file kern_cpuset.c, because it should
  always be there, it is independent of thread scheduler.

Hi.
This breaks for me fetching a cpusetsize value with sysconf(3) interface,
as after this change sysconf(3) consumers expect a long return type, while
sysctl kern.sched.cpusetsize has switched from long to int type in kernel.
That makes for me sizeof(cpusize_t) from 8 to incorrect 34359738376.

In particular, kvm_getpcpu(3) uses sysconf(3) to fetch cpusetsize on
live kernel. That gives me a broken result:
kvm_open: kcpusetsize: 8
pcpu[0] = 0x801072300
kvm_open: kcpusetsize: 34359738376
pcpu[1] = 0x
kvm_open: kcpusetsize: 8
pcpu[2] = 0x801072600
kvm_open: kcpusetsize: 34359738376
pcpu[3] = 0x

This small test indicates that that's due to int-long type conversion:
long lvalue;
size_t len;

len = sizeof(lvalue);
if (sysctlbyname(kern.sched.cpusetsize, lvalue, len, NULL, 0)  0)
err(1, sysctlbyname);
printf(sysctl: %ld\n, lvalue);
printf(sysctl: %d -- explicitly casted to (int)\n, (int)lvalue);
printf(sysconf: %ld\n, sysconf(_SC_CPUSET_SIZE));
printf(sysconf: %d -- explicitly casted to (int)\n,
(int)sysconf(_SC_CPUSET_SIZE));

That prints:
sysctl: 34359738376
sysctl: 8 -- explicitly casted to (int)
sysconf: 34359738376
sysconf: 8 -- explicitly casted to (int)

The other way to solve this other than reverting is to fix all cpusetsize
consumers in userland. Now sysconf() saves long returned value to int:

Index: lib/libkvm/kvm_pcpu.c
===
--- lib/libkvm/kvm_pcpu.c   (revision 223073)
+++ lib/libkvm/kvm_pcpu.c   (working copy)
@@ -120,7 +120,7 @@
 void *
 kvm_getpcpu(kvm_t *kd, int cpu)
 {
-   long kcpusetsize;
+   int kcpusetsize;
ssize_t nbytes;
uintptr_t readptr;
char *buf;

So, after applying the above change all is ok:
kvm_open: kcpusetsize: 8
pcpu[0] = 0x801072300
kvm_open: kcpusetsize: 8
pcpu[1] = 0x801072600
kvm_open: kcpusetsize: 8
pcpu[2] = 0x801072900
kvm_open: kcpusetsize: 8
pcpu[3] = 0x801072c00



 Modified:
  head/sys/kern/kern_cpuset.c
  head/sys/kern/sched_ule.c

 Modified: head/sys/kern/kern_cpuset.c
 ==
 --- head/sys/kern/kern_cpuset.c Sun Oct 31 23:04:15 2010        (r214610)
 +++ head/sys/kern/kern_cpuset.c Mon Nov  1 00:42:25 2010        (r214611)
 @@ -107,6 +107,10 @@ static struct setlist cpuset_ids;
  static struct unrhdr *cpuset_unr;
  static struct cpuset *cpuset_zero;

 +/* Return the size of cpuset_t at the kernel level */
 +SYSCTL_INT(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD,
 +       0, sizeof(cpuset_t), sizeof(cpuset_t));
 +
  cpuset_t *cpuset_root;

  /*

 Modified: head/sys/kern/sched_ule.c
 ==
 --- head/sys/kern/sched_ule.c   Sun Oct 31 23:04:15 2010        (r214610)
 +++ head/sys/kern/sched_ule.c   Mon Nov  1 00:42:25 2010        (r214611)
 @@ -2713,7 +2713,6 @@ sysctl_kern_sched_topology_spec(SYSCTL_H
        return (err);
  }

 -static size_t _kern_cpuset_size = sizeof(cpuset_t);
  #endif

  SYSCTL_NODE(_kern, OID_AUTO, sched, CTLFLAG_RW, 0, Scheduler);
 @@ -2751,14 +2750,6 @@ SYSCTL_PROC(_kern_sched, OID_AUTO, topol
     CTLFLAG_RD, NULL, 0, sysctl_kern_sched_topology_spec, A,
     XML dump of detected CPU topology);

 -/*
 - * Return the size of cpuset_t at the kernel level
 - *
 - * XXX (gcooper): replace ULONG with SIZE once CTLTYPE_SIZE is implemented.
 - */
 -SYSCTL_ULONG(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD,
 -    _kern_cpuset_size, 0, Kernel-level cpuset_t struct size);
 -
  #endif

  /* ps compat.  All cpu percentages from ULE are weighted. */


-- 
wbr,
pluknet
___
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 commit: r214611 - head/sys/kern

[Sergey Kandaurov]

On 15 June 2011 06:20, David Xu davi...@freebsd.org wrote:
 On 2011/06/14 20:02, Sergey Kandaurov wrote:
 On 1 November 2010 03:42, David Xu davi...@freebsd.org wrote:
 Author: davidxu
 Date: Mon Nov  1 00:42:25 2010
 New Revision: 214611
 URL: http://svn.freebsd.org/changeset/base/214611

 Log:
  Use integer for size of cpuset, as it won't be bigger than INT_MAX,
  This is requested by bge.
  Also move the sysctl into file kern_cpuset.c, because it should
  always be there, it is independent of thread scheduler.

 Hi.
 This breaks for me fetching a cpusetsize value with sysconf(3) interface,
 as after this change sysconf(3) consumers expect a long return type, while
 sysctl kern.sched.cpusetsize has switched from long to int type in kernel.
 That makes for me sizeof(cpusize_t) from 8 to incorrect 34359738376.

 In particular, kvm_getpcpu(3) uses sysconf(3) to fetch cpusetsize on
 live kernel. That gives me a broken result:
 kvm_open: kcpusetsize: 8
 pcpu[0] = 0x801072300
 kvm_open: kcpusetsize: 34359738376
 pcpu[1] = 0x
 kvm_open: kcpusetsize: 8
 pcpu[2] = 0x801072600
 kvm_open: kcpusetsize: 34359738376
 pcpu[3] = 0x

 This small test indicates that that's due to int-long type conversion:
         long lvalue;
         size_t len;

         len = sizeof(lvalue);
         if (sysctlbyname(kern.sched.cpusetsize, lvalue, len, NULL, 0)  
 0)
                 err(1, sysctlbyname);
         printf(sysctl: %ld\n, lvalue);
         printf(sysctl: %d -- explicitly casted to (int)\n, (int)lvalue);
         printf(sysconf: %ld\n, sysconf(_SC_CPUSET_SIZE));
         printf(sysconf: %d -- explicitly casted to (int)\n,
 (int)sysconf(_SC_CPUSET_SIZE));

 That prints:
 sysctl: 34359738376
 sysctl: 8 -- explicitly casted to (int)
 sysconf: 34359738376
 sysconf: 8 -- explicitly casted to (int)

 The other way to solve this other than reverting is to fix all cpusetsize
 consumers in userland. Now sysconf() saves long returned value to int:

 Index: lib/libkvm/kvm_pcpu.c
 ===
 --- lib/libkvm/kvm_pcpu.c       (revision 223073)
 +++ lib/libkvm/kvm_pcpu.c       (working copy)
 @@ -120,7 +120,7 @@
  void *
  kvm_getpcpu(kvm_t *kd, int cpu)
  {
 -       long kcpusetsize;
 +       int kcpusetsize;
         ssize_t nbytes;
         uintptr_t readptr;
         char *buf;

 So, after applying the above change all is ok:
 kvm_open: kcpusetsize: 8
 pcpu[0] = 0x801072300
 kvm_open: kcpusetsize: 8
 pcpu[1] = 0x801072600
 kvm_open: kcpusetsize: 8
 pcpu[2] = 0x801072900
 kvm_open: kcpusetsize: 8
 pcpu[3] = 0x801072c00


 Try this patch, I think it should fix it.

 Index: lib/libc/gen/sysconf.c
 ===
 --- lib/libc/gen/sysconf.c      (revision 221356)
 +++ lib/libc/gen/sysconf.c      (working copy)
 @@ -599,11 +599,11 @@

  #ifdef _SC_CPUSET_SIZE
        case _SC_CPUSET_SIZE:
 -               len = sizeof(lvalue);
 -               if (sysctlbyname(kern.sched.cpusetsize, lvalue, len, NULL,
 +               len = sizeof(value);
 +               if (sysctlbyname(kern.sched.cpusetsize, value, len, NULL,
                    0) == -1)
                        return (-1);
 -               return (lvalue);
 +               return ((long)(value));
  #endif

        default:


Great, thanks! Look good for me.
Nitpicking:
 return ((long)value); should be enough (extra parenthesis).

-- 
wbr,
pluknet
___
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: [PATCH] Toggle display of the kernel idle process (per-CPU idle threads) in top

[Sergey Kandaurov]

On 27 May 2011 18:46, John Baldwin j...@freebsd.org wrote:
 Some times in top, I don't want to see all the per-CPU idle threads but
 instead focus on the non-idle threads that are running.  Especially on a
 system with a lot of CPUs, the idle threads can push all the interesting
 threads off of the list.  This patch adds a new 'z' flag (gratuitously chosen
 letter) and interactive command to toggle the display of the system idle
 process.  Patch is tested against 8, but should work fine on HEAD too:

Works on HEAD as well. I like this idea.
Perhaps it could be combined with i key?

 @@ -1075,7 +1081,13 @@
                                reset_display();
                                putchar('\r');
                                break;
 -
 +                           case CMD_kidletog:
 +                               ps.kidle = !ps.kidle;
 +                               new_message(MT_standout | MT_delayed,
 +                                    %sisplaying kernel idle process.,

 +                                   ps.idle ? D : Not d);
^^
typo: s/idle/kidle/


-- 
wbr,
pluknet
___
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: Processes in swapped out states in recent CURRENT?

[Sergey Kandaurov]

On 6 May 2011 00:33, Garrett Cooper yaneg...@gmail.com wrote:
    I was watching top output on my dev box and I noticed that there
 are more swapped out processes present on the system, shortly after
 boot (which doesn't make sense given that I'm not low on resources on
 the box). Also, the os when I run os.waitpid() in python claims that
 the child doesn't exist, so I'm wondering if there's an issue with the
 processes reported via ps, top, etc.
    I'm noting this because it's a behavior change over my
 'stable'-ish workstation, running CURRENT/r220089/amd64, which is
 spec'ed out the same as the dev box, minus some multimedia hardware.
 Thanks,
 -Garrett

 # uname -a
 FreeBSD fallout.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221219M: Thu
 May  5 12:09:37 PDT 2011
 root@fallout.local:/usr/obj/usr/src/sys/FALLOUT  amd6
 # fstat -p 1832
 USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
 root     sshd        1832 root /             2 drwxr-xr-x    1024  r
 root     sshd        1832   wd /             2 drwxr-xr-x    1024  r
 root     sshd        1832 text /usr     730118 -r-xr-xr-x  240944  r
 root     sshd        1832    0 /dev          6 crw-rw-rw-    null  r
 root     sshd        1832    1 /dev          6 crw-rw-rw-    null rw
 root     sshd        1832    2 /dev          6 crw-rw-rw-    null rw
 root     sshd        1832    3* internet stream tcp fe01e56cf000
 root     sshd        1832    4* pseudo-terminal master      pts/1 rw
 root     sshd        1832    5* local stream fe0008f79960 -
 fe0008f79a50
 # fstat -p 149
 USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
 root     adjkerntz    149 root /             2 drwxr-xr-x    1024  r
 root     adjkerntz    149   wd /             2 drwxr-xr-x    1024  r
 root     adjkerntz    149 text /        329805 -r-xr-xr-x    8792  r
 root     adjkerntz    149    0 /dev          6 crw-rw-rw-    null rw
 root     adjkerntz    149    1 /dev          6 crw-rw-rw-    null rw
 root     adjkerntz    149    2 /dev          6 crw-rw-rw-    null rw
 # fstat -p 1479
 USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
 root     syslogd     1479 root /             2 drwxr-xr-x    1024  r
 root     syslogd     1479   wd /             2 drwxr-xr-x    1024  r
 root     syslogd     1479 text /usr     739002 -r-xr-xr-x   39008  r
 root     syslogd     1479    0 /dev          6 crw-rw-rw-    null rw
 root     syslogd     1479    1 /dev          6 crw-rw-rw-    null rw
 root     syslogd     1479    2 /dev          6 crw-rw-rw-    null rw
 root     syslogd     1479    3 /var     353301 -rw---       4  w
 root     syslogd     1479    4* local dgram fe0008cd31e0
 root     syslogd     1479    5* local dgram fe0008cd30f0
 root     syslogd     1479    6* internet6 dgram udp fe0008ced540
 root     syslogd     1479    7* internet dgram udp fe0008ced3f0
 root     syslogd     1479    8 /dev         29 crw---    klog  r
 root     syslogd     1479   10 /var     1389613 -rw-r--r--   25389  w
 root     syslogd     1479   11 /var     1389579 -rw---      62  w
 root     syslogd     1479   12 /var     1389572 -rw---   10164  w
 root     syslogd     1479   13 /var     1389601 -rw-r-    2814  w
 root     syslogd     1479   14 /var     1389575 -rw-r--r--      62  w
 root     syslogd     1479   15 /var     1389580 -rw---      62  w
 root     syslogd     1479   16 /var     1389577 -rw---   57212  w
 root     syslogd     1479   17 /var     1389606 -rw---   38046  w
 root     syslogd     1479   18 /var     1389578 -rw-r-      62  w
 # fstat -p 1829
 USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
 gcooper  sh          1829 root /             2 drwxr-xr-x    1024  r
 gcooper  sh          1829   wd /usr     1884160 drwxr-xr-x    1024  r
 gcooper  sh          1829 text /        212057 -r-xr-xr-x  131784  r
 gcooper  sh          1829    0 /dev        127 crw--w   pts/0 rw
 gcooper  sh          1829    1 /dev        127 crw--w   pts/0 rw
 gcooper  sh          1829    2 /dev        127 crw--w   pts/0 rw
 gcooper  sh          1829   10 /dev        127 crw--w   pts/0 rw

 # python -c 'import os; os.waitpid(1825, 0)'
 Traceback (most recent call last):
  File string, line 1, in module
 OSError: [Errno 10] No child processes

But pid 1825 (sshd) is not a child process of the python process , isn't it?

from waitpid(2):
 [ECHILD]   The calling process has no existing unwaited-for child
processes.

Look at /sys/kern/kern_exit.c:kern_wait(). The function returns ECHILD if
a specified process was not found among p-p_children children group.


 # ps auxww | grep 1825
 root     1825   0.0  0.0  47952      0  ??  IWs  -         0:00.00
 sshd: gcooper [priv] (sshd)
 root    88213   0.0  0.0  16340   1356   3  S+    1:25PM   0:00.00 grep 1825
 # top -b
 last pid: 96740;  load averages:  1.07,  0.98,  0.92  up 0+01:15:32