Re: What to do with witness verbiage (is this new?)?
On Tue, Jul 16, 2002 at 07:14:05PM -0400, John Baldwin wrote: This is because USB network drivers are possibly doing bad things. Either that or the network locking is making bogus assumptions about what device driver routines will and will not do. Probably the network stack should not hold locks across a driver's start method. Thanks John. Ian Dowse has a patch that we're playing with at the moment that appears to fix the problem. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg41170/pgp0.pgp Description: PGP signature
Re: What to do with witness verbiage (is this new?)?
On Thu, Jul 11, 2002 at 12:33:27PM +0100, Josef Karthauser wrote: On Thu, Jul 11, 2002 at 04:01:08AM -0700, Don Lewis wrote: [stuff about could sleep with inp locked from /usr/src/sys/netinet/tcp_usrreq.c:647 could sleep with tcp locked from /usr/src/sys/netinet/tcp_usrreq.c:630 cut] I saw the recent changes to -current to try and fix this, but I'm still seeing it. Here's a typical stack trace: Debugger(c0374e00,c0389851,534,c0374e47,c037d8c8) at Debugger+0x54 witness_sleep(1,0,c0389851,534,c021bf24) at witness_sleep+0x135 uma_zalloc_arg(c1564000,0,4,c021bf24,c1564000) at uma_zalloc_arg+0x39 malloc(50,c03c1060,4,c40e5000,c40e5000) at malloc+0x55 uhci_allocm(c40e5000,c40edc40,a4,c024a000,c160e72e) at uhci_allocm+0x3d usbd_transfer(c40edc00,c434b600,c4126174,c42b1000,a4) at usbd_transfer+0xba aue_encap(c4126000,c160e700,0,49c,c41260dc) at aue_encap+0xa2 aue_start(c4126000,0,c0379f81,134,0) at aue_start+0xcc if_handoff(c41260c8,c160e700,c4126000,0,de0259e4) at if_handoff+0x107 ether_output_frame(c4126000,c160e700,6,c4336ba8,de0259e4) at ether_output_frame+0x241 ether_output(c4126000,c160e700,c4336ba8,c4ace200,0) at ether_output+0x4a2 ip_output(c160e700,0,c4336ba4,0,0) at ip_output+0xa75 tcp_output(c4336c68,c160ed00,c037de40,287,0) at tcp_output+0xc60 tcp_usr_send(c4ce1320,0,c160ed00,0,0) at tcp_usr_send+0x1be sosend(c4ce1320,0,de025c7c,c160ed00,0) at sosend+0x4c3 soo_write(c4d62078,de025c7c,c4d5cc80,0 Is anyone anywhere near this code at the moment? Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg41117/pgp0.pgp Description: PGP signature
Re: What to do with witness verbiage (is this new?)?
On 16-Jul-2002 Josef Karthauser wrote: On Thu, Jul 11, 2002 at 12:33:27PM +0100, Josef Karthauser wrote: On Thu, Jul 11, 2002 at 04:01:08AM -0700, Don Lewis wrote: [stuff about could sleep with inp locked from /usr/src/sys/netinet/tcp_usrreq.c:647 could sleep with tcp locked from /usr/src/sys/netinet/tcp_usrreq.c:630 cut] I saw the recent changes to -current to try and fix this, but I'm still seeing it. Here's a typical stack trace: Debugger(c0374e00,c0389851,534,c0374e47,c037d8c8) at Debugger+0x54 witness_sleep(1,0,c0389851,534,c021bf24) at witness_sleep+0x135 uma_zalloc_arg(c1564000,0,4,c021bf24,c1564000) at uma_zalloc_arg+0x39 malloc(50,c03c1060,4,c40e5000,c40e5000) at malloc+0x55 uhci_allocm(c40e5000,c40edc40,a4,c024a000,c160e72e) at uhci_allocm+0x3d usbd_transfer(c40edc00,c434b600,c4126174,c42b1000,a4) at usbd_transfer+0xba aue_encap(c4126000,c160e700,0,49c,c41260dc) at aue_encap+0xa2 aue_start(c4126000,0,c0379f81,134,0) at aue_start+0xcc if_handoff(c41260c8,c160e700,c4126000,0,de0259e4) at if_handoff+0x107 ether_output_frame(c4126000,c160e700,6,c4336ba8,de0259e4) at ether_output_frame+0x241 ether_output(c4126000,c160e700,c4336ba8,c4ace200,0) at ether_output+0x4a2 ip_output(c160e700,0,c4336ba4,0,0) at ip_output+0xa75 tcp_output(c4336c68,c160ed00,c037de40,287,0) at tcp_output+0xc60 tcp_usr_send(c4ce1320,0,c160ed00,0,0) at tcp_usr_send+0x1be sosend(c4ce1320,0,de025c7c,c160ed00,0) at sosend+0x4c3 soo_write(c4d62078,de025c7c,c4d5cc80,0 Is anyone anywhere near this code at the moment? This is because USB network drivers are possibly doing bad things. Either that or the network locking is making bogus assumptions about what device driver routines will and will not do. Probably the network stack should not hold locks across a driver's start method. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Wed, Jul 10, 2002 at 01:36:46PM -0700, Don Lewis wrote: It'll drop into ddb every time you get a witness error and you'll have to tell ddb to continue. This could be a might annoying if you are getting errors ever ten seconds ... I'm seeing this: ../../../vm/uma_core.c:1332: could sleep with kernel linker locked from ../../../kern/kern_linker.c:1797 very early on (before rc.sysctl is read -- okay I'm still using the old rc scripts). Is there any way to set debug.witness_ddb=1 from the loader? This is entirely repeatable (just boot up the machine), also seems to happen a few times at random while the system is running. I figure if I could get it to panic in the repeatable case... - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Fri, Jul 12, 2002 at 08:33:39 -0700, Alex Zepeda wrote: On Wed, Jul 10, 2002 at 01:36:46PM -0700, Don Lewis wrote: It'll drop into ddb every time you get a witness error and you'll have to tell ddb to continue. This could be a might annoying if you are getting errors ever ten seconds ... I'm seeing this: ../../../vm/uma_core.c:1332: could sleep with kernel linker locked from ../../../kern/kern_linker.c:1797 very early on (before rc.sysctl is read -- okay I'm still using the old rc scripts). Is there any way to set debug.witness_ddb=1 from the loader? This is entirely repeatable (just boot up the machine), also seems to happen a few times at random while the system is running. I figure if I could get it to panic in the repeatable case... You can set debug.witness_ddb from the loader. It'll get propagated to the sysctl once you boot. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On 12 Jul, Alex Zepeda wrote: On Wed, Jul 10, 2002 at 01:36:46PM -0700, Don Lewis wrote: It'll drop into ddb every time you get a witness error and you'll have to tell ddb to continue. This could be a might annoying if you are getting errors ever ten seconds ... I'm seeing this: ../../../vm/uma_core.c:1332: could sleep with kernel linker locked from ../../../kern/kern_linker.c:1797 very early on (before rc.sysctl is read -- okay I'm still using the old rc scripts). I see that one also and I know what the problem is. Unfortunately I don't know of a good way of fixing it. The problem is that SYSCTL_OUT() is being called while a lock is held, and SYSCTL_OUT() can potentially block. I've posted a lot more information about this error in another thread. Check the archives for the subject '/usr/src/sys/vm/uma_core.c:1332: could sleep with kernel li', I guess my original subject got truncated. Is there any way to set debug.witness_ddb=1 from the loader? Dunno, but you could tweak the source to change the default value and recompile, or you could binary patch the kernel. It's not worth doing it in this case though. This is entirely repeatable (just boot up the machine), also seems to happen a few times at random while the system is running. I figure if I could get it to panic in the repeatable case... You can also reproduce it by running sysctl -a, but I'll save you the trouble. Here's the stack trace: witness_sleep() uma_zalloc_arg() vm_map_entry_create() vm_map_clip_start() vm_map_wire() vslock() sysctl_old_user() sysctl_kern_function_list_iterate() link_elf_each_function_name() sysctl_kern_function_list() ... There were some other similar cases in the kernel that I've already fixed because they were easy, but I don't know of a good fix for the general case. I'm planning to solicit ideas from the freebsd-arch list. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On 10 Jul, Alex Zepeda wrote:
On Wed, Jul 10, 2002 at 01:34:50PM -0700, Don Lewis wrote:
../../../vm/uma_core.c:1332: could sleep with inp locked from
../../../netinet/tcp_subr.c:935
../../../vm/uma_core.c:1332: could sleep with tcp locked from
../../../netinet/tcp_subr.c:928
I've never seen that one. I'll take a look at the code, though.
I'm seeing the same (once at bootup tho).
sm:blarf:~$uptime
8:48PM up 18:52, 4 users, load averages: 0.11, 0.06, 0.01
sm:blarf:~$
I tracked it down to tcp_getcred() calling SYSCTL_OUT(), which can
potentially block, before releasing the locks tcp_getcred() is holding.
This routine is used by the net.inet.tcp.getcred sysctl, and the only
user of that seems to be the builtin ident code in inetd. I'm not
seeing this error because I'm not running inetd on my -current box.
This bug is similar to the kernel linker bug, but is much easier to
fix. There are similar errors in tcp6_getcred() and udp_getcred().
Give this patch a try:
Index: sys/netinet/tcp_subr.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.134
diff -u -r1.134 tcp_subr.c
--- sys/netinet/tcp_subr.c 30 Jun 2002 20:07:21 - 1.134
+++ sys/netinet/tcp_subr.c 11 Jul 2002 08:23:37 -
@@ -931,24 +931,23 @@
if (inp == NULL) {
error = ENOENT;
goto outunlocked;
- } else {
- INP_LOCK(inp);
- if (inp-inp_socket == NULL) {
- error = ENOENT;
- goto out;
- }
}
-
+ INP_LOCK(inp);
+ if (inp-inp_socket == NULL) {
+ error = ENOENT;
+ goto out;
+ }
error = cr_canseesocket(req-td-td_ucred, inp-inp_socket);
if (error)
goto out;
cru2x(inp-inp_socket-so_cred, xuc);
- error = SYSCTL_OUT(req, xuc, sizeof(struct xucred));
out:
INP_UNLOCK(inp);
outunlocked:
INP_INFO_RUNLOCK(tcbinfo);
splx(s);
+ if (error == 0)
+ error = SYSCTL_OUT(req, xuc, sizeof(struct xucred));
return (error);
}
@@ -994,22 +993,22 @@
if (inp == NULL) {
error = ENOENT;
goto outunlocked;
- } else {
- INP_LOCK(inp);
- if (inp-inp_socket == NULL) {
- error = ENOENT;
- goto out;
- }
+ }
+ INP_LOCK(inp);
+ if (inp-inp_socket == NULL) {
+ error = ENOENT;
+ goto out;
}
error = cr_canseesocket(req-td-td_ucred, inp-inp_socket);
if (error)
goto out;
cru2x(inp-inp_socket-so_cred, xuc);
- error = SYSCTL_OUT(req, xuc, sizeof(struct xucred));
out:
INP_UNLOCK(inp);
outunlocked:
INP_INFO_RUNLOCK(tcbinfo);
+ if (error == 0)
+ error = SYSCTL_OUT(req, xuc, sizeof(struct xucred));
splx(s);
return (error);
}
Index: sys/netinet/udp_usrreq.c
===
RCS file: /home/ncvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.114
diff -u -r1.114 udp_usrreq.c
--- sys/netinet/udp_usrreq.c21 Jun 2002 22:54:16 - 1.114
+++ sys/netinet/udp_usrreq.c11 Jul 2002 08:27:56 -
@@ -681,6 +681,7 @@
INP_INFO_RLOCK(udbinfo);
inp = in_pcblookup_hash(udbinfo, addrs[1].sin_addr, addrs[1].sin_port,
addrs[0].sin_addr, addrs[0].sin_port, 1, NULL);
+ /* XXX - call INP_LOCK(inp)? - see tcp_getcred() */
if (inp == NULL || inp-inp_socket == NULL) {
error = ENOENT;
goto out;
@@ -689,10 +690,12 @@
if (error)
goto out;
cru2x(inp-inp_socket-so_cred, xuc);
- error = SYSCTL_OUT(req, xuc, sizeof(struct xucred));
+ /* XXX - call INP_UNLOCK(inp)? */
out:
INP_INFO_RUNLOCK(udbinfo);
splx(s);
+ if (error == 0)
+ error = SYSCTL_OUT(req, xuc, sizeof(struct xucred));
return (error);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Thu, Jul 11, 2002 at 03:12:34AM -0700, Don Lewis wrote: I've never seen that one. I'll take a look at the code, though. I'm seeing the same (once at bootup tho). sm:blarf:~$uptime 8:48PM up 18:52, 4 users, load averages: 0.11, 0.06, 0.01 sm:blarf:~$ I tracked it down to tcp_getcred() calling SYSCTL_OUT(), which can potentially block, before releasing the locks tcp_getcred() is holding. This routine is used by the net.inet.tcp.getcred sysctl, and the only user of that seems to be the builtin ident code in inetd. I'm not seeing this error because I'm not running inetd on my -current box. I get it whenever cron kicks of a cvsup also. Joe msg40864/pgp0.pgp Description: PGP signature
Re: What to do with witness verbiage (is this new?)?
On Thu, Jul 11, 2002 at 11:35:46AM +0100, Josef Karthauser wrote: I tracked it down to tcp_getcred() calling SYSCTL_OUT(), which can potentially block, before releasing the locks tcp_getcred() is holding. This routine is used by the net.inet.tcp.getcred sysctl, and the only user of that seems to be the builtin ident code in inetd. I'm not seeing this error because I'm not running inetd on my -current box. I get it whenever cron kicks of a cvsup also. Oh, and also when postfix sends or recives an email. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg40865/pgp0.pgp Description: PGP signature
Re: What to do with witness verbiage (is this new?)?
On 11 Jul, Josef Karthauser wrote: On Thu, Jul 11, 2002 at 11:35:46AM +0100, Josef Karthauser wrote: I tracked it down to tcp_getcred() calling SYSCTL_OUT(), which can potentially block, before releasing the locks tcp_getcred() is holding. This routine is used by the net.inet.tcp.getcred sysctl, and the only user of that seems to be the builtin ident code in inetd. I'm not seeing this error because I'm not running inetd on my -current box. I get it whenever cron kicks of a cvsup also. Oh, and also when postfix sends or recives an email. I would expect this if you are running inetd and have its builtin ident service enabled. When you are sending email and your MTA connects to a remote MTA, it is quite common for the remote MTA to connect to the ident port on your host to get more information about the user who initiated the connection request. The cvsup server may also be making ident queries. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Thu, Jul 11, 2002 at 04:01:08AM -0700, Don Lewis wrote: On 11 Jul, Josef Karthauser wrote: On Thu, Jul 11, 2002 at 11:35:46AM +0100, Josef Karthauser wrote: I tracked it down to tcp_getcred() calling SYSCTL_OUT(), which can potentially block, before releasing the locks tcp_getcred() is holding. This routine is used by the net.inet.tcp.getcred sysctl, and the only user of that seems to be the builtin ident code in inetd. I'm not seeing this error because I'm not running inetd on my -current box. I get it whenever cron kicks of a cvsup also. Oh, and also when postfix sends or recives an email. I would expect this if you are running inetd and have its builtin ident service enabled. When you are sending email and your MTA connects to a remote MTA, it is quite common for the remote MTA to connect to the ident port on your host to get more information about the user who initiated the connection request. Ok, that explains that. The cvsup server may also be making ident queries. If it is, it is making lots and lots of them, at a rate of around 5 or 10 a second or more when the cvsup is running. That seems excessive. To test it I've just killed inetd and it's still happening - there must be something else tickling this also. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg40868/pgp0.pgp Description: PGP signature
Re: What to do with witness verbiage (is this new?)?
On 11 Jul, Josef Karthauser wrote: On Thu, Jul 11, 2002 at 04:01:08AM -0700, Don Lewis wrote: On 11 Jul, Josef Karthauser wrote: I get it whenever cron kicks of a cvsup also. The cvsup server may also be making ident queries. If it is, it is making lots and lots of them, at a rate of around 5 or 10 a second or more when the cvsup is running. That seems excessive. To test it I've just killed inetd and it's still happening - there must be something else tickling this also. I'd only expect one ident connection when cvsup connects to the server. Maybe cvsup is calling this sysctl for some reason ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On 11 Jul, Don Lewis wrote: On 10 Jul, Alex Zepeda wrote: On Wed, Jul 10, 2002 at 01:34:50PM -0700, Don Lewis wrote: ../../../vm/uma_core.c:1332: could sleep with inp locked from ../../../netinet/tcp_subr.c:935 ../../../vm/uma_core.c:1332: could sleep with tcp locked from ../../../netinet/tcp_subr.c:928 I tracked it down to tcp_getcred() calling SYSCTL_OUT(), which can potentially block, before releasing the locks tcp_getcred() is holding. This routine is used by the net.inet.tcp.getcred sysctl, and the only user of that seems to be the builtin ident code in inetd. I'm not seeing this error because I'm not running inetd on my -current box. This bug is similar to the kernel linker bug, but is much easier to fix. There are similar errors in tcp6_getcred() and udp_getcred(). Give this patch a try: I just committed the patch. Enjoy! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On 10 Jul, Alex Zepeda wrote After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel (and boy is it wickedly unstable as of now). I haven't had any instability problems in a while on my UP box. Anyways.. is there any sort of list of known warnings? I'm seeing a few consistantly relating to pcm0:play:0, pcm0, inp, tcp, and kernel linker. The pcm related ones are well known, right? I don't have the pcm hardware. The only WITNESS message I consistently see is the kernel linker one. The most recent one I'm seeing (that I'd never seen before) is this: ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 I haven't seen that one. If you can reproduce it, you might try setting the debug.witness_ddb sysctl to 1 and get a stack trace from ddb. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
Alex Zepeda [EMAIL PROTECTED] writes: After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel Congratulations in turning your -CURRENT box into a doorstop! ;) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Wed, Jul 10, 2002 at 02:43:54AM -0700, Don Lewis wrote: I haven't had any instability problems in a while on my UP box. Seems like the UP kernels are more unstable for me. Go figure. ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 I haven't seen that one. If you can reproduce it, you might try setting the debug.witness_ddb sysctl to 1 and get a stack trace from ddb. This happened just before the box fell over (I'm now running a different kernel.. SMP.. so far so good). What's the downside to sticking debug.witness_ddb=1 in /etc/sysctl.conf? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
In the last episode (Jul 10), Don Lewis said: On 10 Jul, Alex Zepeda wrote After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel (and boy is it wickedly unstable as of now). I haven't had any instability problems in a while on my UP box. Anyways.. is there any sort of list of known warnings? I'm seeing a few consistantly relating to pcm0:play:0, pcm0, inp, tcp, and kernel linker. The pcm related ones are well known, right? I don't have the pcm hardware. The only WITNESS message I consistently see is the kernel linker one. The most recent one I'm seeing (that I'd never seen before) is this: ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 I haven't seen that one. If you can reproduce it, you might try setting the debug.witness_ddb sysctl to 1 and get a stack trace from ddb. I see this one once every 10 seconds or so: ../../../vm/uma_core.c:1332: could sleep with inp locked from ../../../netinet/tcp_subr.c:935 ../../../vm/uma_core.c:1332: could sleep with tcp locked from ../../../netinet/tcp_subr.c:928 -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On 10 Jul, Dan Nelson wrote: I see this one once every 10 seconds or so: ../../../vm/uma_core.c:1332: could sleep with inp locked from ../../../netinet/tcp_subr.c:935 ../../../vm/uma_core.c:1332: could sleep with tcp locked from ../../../netinet/tcp_subr.c:928 I've never seen that one. I'll take a look at the code, though. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On 10 Jul, Alex Zepeda wrote: On Wed, Jul 10, 2002 at 02:43:54AM -0700, Don Lewis wrote: I haven't had any instability problems in a while on my UP box. Seems like the UP kernels are more unstable for me. Go figure. ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 I haven't seen that one. If you can reproduce it, you might try setting the debug.witness_ddb sysctl to 1 and get a stack trace from ddb. This happened just before the box fell over (I'm now running a different kernel.. SMP.. so far so good). What's the downside to sticking debug.witness_ddb=1 in /etc/sysctl.conf? It'll drop into ddb every time you get a witness error and you'll have to tell ddb to continue. This could be a might annoying if you are getting errors ever ten seconds ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
Dag-Erling Smorgrav wrote: Alex Zepeda [EMAIL PROTECTED] writes: After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel Congratulations in turning your -CURRENT box into a doorstop! ;) Magician: For my fisrt trick, I shall install -current! Audience: Oooh! Magician: Now I will attempt to obtain a crash dump... this is a very dangerous trick... very few magicians alive today can perform this trick, although in the past, it was very common... Audience: Aaah! Magician: For my next trick, I will turn on WITNESS! Please be quiet! Many magicians have died doing this! Audience: Oooh! Magician: And for my final trick of the evening, I will throw this frisbee so that it lands under a car, just out of reach... Man (to wife): I think I'm beginning to see a pattern... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Wed, Jul 10, 2002 at 01:34:50PM -0700, Don Lewis wrote: ../../../vm/uma_core.c:1332: could sleep with inp locked from ../../../netinet/tcp_subr.c:935 ../../../vm/uma_core.c:1332: could sleep with tcp locked from ../../../netinet/tcp_subr.c:928 I've never seen that one. I'll take a look at the code, though. I'm seeing the same (once at bootup tho). sm:blarf:~$uptime 8:48PM up 18:52, 4 users, load averages: 0.11, 0.06, 0.01 sm:blarf:~$ Sweet. Oddly the SMP kernels seem a tad more stable. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
