Re: /dev/shm
On Monday 07 July 2003 02:41, Thomas E. Dickey wrote: On Mon, 7 Jul 2003, Christopher Vance wrote: On Sun, Jul 06, 2003 at 08:14:44PM -0400, Thomas Dickey wrote: : On Mon, Jul 07, 2003 at 01:58:19AM +0200, Marcin Dalecki wrote: : Myron J. Mayfield wrote: : start it. It gives me an error saying cant find /dev/shm. I tried : adding this to /dev but was unable to. Does anyone have any : : For some unexcused reason there is the trend in Linux to represent : everything as kind of a wired half finished pseudo file system. /proc : pipe devicefs sysctl and so on... The list is really long. Even : shared memmory is mapped to ehrm a filesystem. This is : expected to be mounted at /dev/shm by the system. You can't expect : FreeBSD to follow this path... : : Linux isn't the only system that does this (learn a little, criticize : less). If you're talking about Plan 9 or Inferno, they at least have a history of finishing their filesystems and understanding why it's done that way. If Linux attempts to copy without understanding, and doesn't complete the job, it doesn't imply that the original idea was a Bad Thing, only that the implementation sucks. Better, apparently to copy (not actually), rather than to whine in the background... Still - your response is equally ignorant (Plan 9 is well known - even to students), since it offers no useful information. The /proc stuff is used in real Unix's such as Solaris. Just checking, I see that FreeBSD implements procfs, which is along the same lines. (still waiting for FreeBSD to complete a sysinstall program that doesn't look as if it was an assignment for high-school interns). What's the matter with sysinstall ? I very much like sysinstall as it is now. :) See you. -- JFRH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
On Mon, Jul 07, 2003 at 10:22:02AM +0200, Juan Rodriguez Hervella wrote: (still waiting for FreeBSD to complete a sysinstall program that doesn't look as if it was an assignment for high-school interns). What's the matter with sysinstall ? I very much like sysinstall as it is now. :) to be perfectly fair, the 5.x version of sysinstall is slightly improved from 4.x (it finally - took 5 years - does not overwrite my boot loader when requested not to). however. it still has some odd use of the state information which makes me ask (and this means it's defective) why did it do _that_ (for instance installing something _twice_ because I visited the targets menu twice). if someone set out to test it systematically, it wouldn't require the snide remarks, well, submit patches. -- Thomas E. Dickey [EMAIL PROTECTED] [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Lock order reversal
Dear colleagues, === lock order reversal 1st 0xc2f4b128 vm object (vm object) @ vm/vm_object.c:432 2nd 0xc082f110 system map (system map) @ vm/vm_kern.c:325 Stack backtrace: backtrace(c04eacec,c082f110,c04fb2fa,c04fb2fa,c04fb1a2) at backtrace+0x17 witness_lock(c082f110,8,c04fb1a2,145,c082f0b0) at witness_lock+0x692 _mtx_lock_flags(c082f110,0,c04fb199,145,101) at _mtx_lock_flags+0xb1 _vm_map_lock(c082f0b0,c04fb199,145,0,c05b4600) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,d258fac4,c044c7df) at kmem_malloc+0x3a page_alloc(c083a1c0,1000,d258fab7,101,c05ae0e0) at page_alloc+0x27 slab_zalloc(c083a1c0,101,8,c04fcb37,664) at slab_zalloc+0x14f uma_zone_slab(c083a1c0,101,c04fcb2e,664,0) at uma_zone_slab+0xcb uma_zalloc_internal(c083a1c0,0,101,6e8,0) at uma_zalloc_internal+0x55 uma_zfree_arg(c268aa80,d1c77e04,0,1,0) at uma_zfree_arg+0x2bf swp_pager_meta_free_all(c2f4b128,c04faaf9,c04faa91,1b2) at swp_pager_meta_free_all+0x18f swap_pager_dealloc(c2f4b128,1,c04fca3d,10c,0) at swap_pager_dealloc+0x113 vm_pager_deallocate(c2f4b128,0,c04fbc2b,25f,1b0) at vm_pager_deallocate+0x3d vm_object_terminate(c2f4b128,0,c04fbc2b,1b0,d258fc14) at vm_object_terminate+0x1e8 vm_object_deallocate(c2f4b128,c2b9bd20,c2f4b128,c2b9bd20,d258fc68) at vm_object_deallocate+0x35f vm_map_entry_delete(c2ab2a00,c2b9bd20,c04fb368,8bc,0) at vm_map_entry_delete+000,0,bfc0,c2ab2a00,c26fc700) at vm_map_delete+0x3d3 vm_map_remove(c2ab2a00,0,bfc0,11d,65) at vm_map_remove+0x55 exit1(c2aa15f0,0,c04e5b6a,65,d258fd40) at exit1+0x60d sys_exit(c2aa15f0,d258fd14,c0500c6f,3fd,1) at sys_exit+0x41 syscall(2f,2f,2f,0,) at syscall+0x251 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1), eip = 0x280d159f, esp = 0xbfbff42c, ebp = 0xbfbff448 --- === 5.1-CURRENT from July, 6, 2003. GENERIC kernel. --- Yours Andrew Kolchoogin. [DREW-RIPE, AKOL-RIPN] ... Contrary to popular belief, UNIX is user-friendly. It just happens to be very selective about who it decides to make friends with. A. Haiut. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lock order reversal
On Mon, Jul 07, 2003 at 02:26:43PM +0400, Andrew Kolchoogin wrote: lock order reversal 1st 0xc2f4b128 vm object (vm object) @ vm/vm_object.c:432 2nd 0xc082f110 system map (system map) @ vm/vm_kern.c:325 This is known to be harmless. Kris pgp0.pgp Description: PGP signature
Re: /dev/shm
Marcin Dalecki [EMAIL PROTECTED] writes: There isn't much either Solaris /proc or FresBSD /proc have in common with what Linux calls /proc. And finally on my FreeBSD box - kozaczek# mount /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) kozaczek# top And top doesn't eat tons of CPU time there like it does on Linux. Update your Linux top or run fewer processes on it then. :- -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
Matthias Andree wrote: Marcin Dalecki [EMAIL PROTECTED] writes: There isn't much either Solaris /proc or FresBSD /proc have in common with what Linux calls /proc. And finally on my FreeBSD box - kozaczek# mount /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) kozaczek# top And top doesn't eat tons of CPU time there like it does on Linux. Update your Linux top or run fewer processes on it then. :- You know that file system name lookup is one of the most expensive system calls under UNIX? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
On Mon, Jul 07, 2003 at 02:23:25PM +0200, Marcin Dalecki wrote: You know that file system name lookup is one of the most expensive system calls under UNIX? stating the obvious is a clumsy rhetorical ploy (asking for agreement without making a point). -- Thomas E. Dickey [EMAIL PROTECTED] [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Latest world breaks NIS users
Just updated world/kernel to FreeBSD 5.1-CURRENT #0: Mon Jul 7 07:46:48 EDT 2003 from world/kernel dated 17th June and NIS users are unable to login. # ps ax |fgrep ypbind 47087 ?? Ss 0:00.02 /usr/sbin/ypbind # ypwhich DC3.gc.nat # ypcat passwd |fgrep robin robin:OeIS3xdIRAiQs:20292:30028::/home/robin:/bin/bash # ypcat group |fgrep robin gactr::3:holmesr,wrighta,prestonh,reagind,gankol,cafieroj,cahoonb,pettigr m,brantlek,thumat,dosterc,nate,robin,charles ITS::30026:dosterc,nate,robin,charles NSS::30028:dosterc,nate,robin,charles,test # id robin id: robin: no such user --- Robin P. Blanchard Systems Integration Specialist Georgia Center for Continuing Education fon: 706.542.2404 | fax: 706.542.6546 --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR in vm/swap_pager.c:1166 + vm/vm_kern.c:325
In current from Jul 3 18:36 UTC: lock order reversal 1st 0xc0836ae4 vm object (vm object) @ vm/swap_pager.c:1166 2nd 0xc082e120 system map (system map) @ vm/vm_kern.c:325 Stack backtrace: backtrace(c050c617,c082e120,c051eacf,c051eacf,c051e977) at backtrace+0x17 witness_lock(c082e120,8,c051e977,145,c05da600) at witness_lock+0x697 _mtx_lock_flags(c082e120,0,c051e96e,145,cccab904) at _mtx_lock_flags+0xb1 _vm_map_lock(c082e0c0,c051e96e,145,c083a214,cccab95c) at _vm_map_lock+0x36 kmem_malloc(c082e0c0,1000,101,cccab98c,c046c860) at kmem_malloc+0x39 page_alloc(c083a200,1000,cccab97f,101,c055fb80) at page_alloc+0x27 slab_zalloc(c083a200,101,c052030c,664,c0508c33) at slab_zalloc+0x150 uma_zone_slab(c083a200,101,c0520303,664,0) at uma_zone_slab+0xd8 uma_zalloc_internal(c083a200,0,101,6e8,0) at uma_zalloc_internal+0x55 uma_zfree_arg(c1991300,ccf0,0,1,0) at uma_zfree_arg+0x2d7 swp_pager_meta_ctl(c0836ae4,1f,0,2,cccabb6c) at swp_pager_meta_ctl+0x1bf swap_pager_unswapped(c08f14d8,1,c05072cf,b4,cccabad0) at swap_pager_unswapped+0x2a vm_fault(c0bab770,bfbff000,2,8,c1982390) at vm_fault+0x1181 trap_pfault(cccabbfc,0,bfbffa68,c0507326,bfbffa68) at trap_pfault+0x10f trap(18,10,10,bfbffa68,cccabc6c) at trap+0x3cd calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc04a243c, esp = 0xcccabc3c, ebp = 0xcccabccc --- slow_copyout(c1982390,cccabd10,0,cccabd40,c04a471e) at slow_copyout+0x4 wait4(c1982390,cccabd10,c052441d,3fd,4) at wait4+0x20 syscall(2f,2f,2f,0,3a) at syscall+0x26e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (7), eip = 0x807b26b, esp = 0xbfbffa0c, ebp = 0xbfbffa28 --- -- Peter Holm ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
Thomas Dickey wrote: On Mon, Jul 07, 2003 at 02:23:25PM +0200, Marcin Dalecki wrote: You know that file system name lookup is one of the most expensive system calls under UNIX? stating the obvious is a clumsy rhetorical ploy (asking for agreement without making a point). The point is that this is one of the reasons why the top command in question takes a lot of relative CPU time under Linux. Some faster versions of procps utils try to cache data but the trade off is simply the fact that the results are not 100% accurate. I tought this was obvious? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
Marcin Dalecki schrieb am 2003-07-07: Matthias Andree wrote: Update your Linux top or run fewer processes on it then. :- You know that file system name lookup is one of the most expensive system calls under UNIX? So what? If you don't like the interface because it does ever so expensive file system lookups (I wonder what's so expensive if no disk drive latencies are involved), suggest a better one and donate an implementation. I'm sure I'd find disadvantages of non-Linux top if I only cared to look. I don't. It works when I need it, it's not in my way otherwise, that's as much as I care. -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
Matthias Andree wrote: On Mon, 07 Jul 2003, Marcin Dalecki wrote: The point is that this is one of the reasons why the top command in question takes a lot of relative CPU time under Linux. Some faster versions of procps utils try to cache data but the trade off is simply the fact that the results are not 100% accurate. Top data is not accurate (I though that was obvious ;-). It's an obsolete snapshot the very moment it's printed to your console, Obsolete and never accurate are two different things. You know every information is obsolete the time it is recived. and I bet it changes as you read with a lot of implementations because no-one wants to beat the big kernel lock on the process list just because some user happens to run top, might be a nice DoS otherwise, fork-bombing top... If you want accurate data, use a kernel debugger with remote interface and make sure the machine does nothing except servicing the debugger interface. I tought this was obvious? Why do I care? 0.58user 0.89system 1:00.91elapsed 2%CPU -- on a 266 MHz Pentium-II, Linux 2.4, 5 years old, with 190 processes. The box idles 73% of the time it's up, there's _ample_ CPU power left. Well once in a former live I was administering some servers over sometimes slow lines. And if they where bogged down by actual *load* it was sometimes really really very inconvenient to have no real chance at getting a quick overview of the processes running there and causing the problem becouse top didn't even get a chance to show up due to the hefty IO load it was causing. If the box is idle I don't really care about the load as much as you don't care. :-). This is something that was never a problem on any *BSD or Solaris box I had to deal with thus far. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
buildkernel ULE related breakage
Hi, Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT ( wrapped long lines ) cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c cc1: warnings being treated as errors /usr/src/sys/kern/sched_ule.c: In function `sched_setup': /usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i' *** Error code 1 Stop in /usr/obj/usr/src/sys/TEST. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
In the last episode (Jul 07), Matthias Andree said:
Marcin Dalecki schrieb am 2003-07-07:
Matthias Andree wrote:
Update your Linux top or run fewer processes on it then. :-
You know that file system name lookup is one of the most expensive
system calls under UNIX?
So what? If you don't like the interface because it does ever so
expensive file system lookups (I wonder what's so expensive if no
disk drive latencies are involved), suggest a better one and donate
an implementation.
I'm sure I'd find disadvantages of non-Linux top if I only cared to
look. I don't. It works when I need it, it's not in my way otherwise,
that's as much as I care.
There is already a functional non-procfs implementation that has been
around long before procps top: groupsys top 3.5b12 (i.e. the top that
all other non-Linux systems use) compiles fine on even the newest Linux
kernels with the attached patch. It's one of the first things I build
on a new Linux box. Procps top is way too slow; it takes a full 5
seconds just for the first screen refresh on a mostly-idle box with 400
processes. groupsys top is basically instantaneous. And don't think
about accidentally hitting a cursor or function key which running
procps top; it doesn't even use curses, so it beeps and waits 2 seconds
for each character in the escape sequence :)
--
Dan Nelson
[EMAIL PROTECTED]
diff -burp top-3.5beta12/display.c top-3.5beta12-l/display.c
--- top-3.5beta12/display.c Thu Sep 12 15:24:39 1996
+++ top-3.5beta12-l/display.c Mon Apr 29 12:45:54 2002
@@ -931,12 +931,12 @@ register char **pp;
static void summary_format(str, numbers, names)
char *str;
-int *numbers;
+unsigned int *numbers;
register char **names;
{
register char *p;
-register int num;
+register unsigned int num;
register char *thisname;
register int useM = No;
@@ -946,6 +946,8 @@ register char **names;
{
/* get the number to format */
num = *numbers++;
+
+/* fprintf(stderr,%lu\n,num); */
/* display only non-zero numbers */
if (num 0)
diff -burp top-3.5beta12/machine/m_linux.c top-3.5beta12-l/machine/m_linux.c
--- top-3.5beta12/machine/m_linux.c Fri Jan 15 08:42:07 1999
+++ top-3.5beta12-l/machine/m_linux.c Mon Apr 29 12:45:54 2002
@@ -36,7 +36,8 @@
#include sys/param.h /* for HZ */
#include asm/page.h /* for PAGE_SHIFT */
-#include linux/tasks.h /* for NR_TASKS */
+/* #include linux/tasks.h */ /* for NR_TASKS */
+#define NR_TASKS 8192
#if 0
#include linux/proc_fs.h /* for PROC_SUPER_MAGIC */
@@ -139,7 +140,7 @@ static struct top_proc **nextactive;
static int cpu_states[NCPUSTATES];
static int process_states[NPROCSTATES];
-static int memory_stats[NMEMSTATS];
+static unsigned int memory_stats[NMEMSTATS];
/* usefull macros */
#define bytetok(x) (((x) + 512) 10)
diff -burp top-3.5beta12/screen.c top-3.5beta12-l/screen.c
--- top-3.5beta12/screen.c Wed Dec 15 11:44:10 1993
+++ top-3.5beta12-l/screen.cMon Apr 29 12:45:54 2002
@@ -71,7 +71,6 @@ char *start_standout;
char *end_standout;
char *terminal_init;
char *terminal_end;
-short ospeed;
#ifdef SGTTY
static struct sgttyb old_settings;
diff -burp top-3.5beta12/utils.c top-3.5beta12-l/utils.c
--- top-3.5beta12/utils.c Mon Jun 1 12:58:17 1998
+++ top-3.5beta12-l/utils.c Mon Apr 29 12:45:54 2002
@@ -59,27 +59,16 @@ char *str;
char *itoa(val)
-register int val;
+register unsigned int val;
{
-register char *ptr;
static char buffer[16];/* result is built here */
/* 16 is sufficient since the largest number
we will ever convert will be 2^32-1,
which is 10 digits. */
-ptr = buffer + sizeof(buffer);
-*--ptr = '\0';
-if (val == 0)
-{
- *--ptr = '0';
-}
-else while (val != 0)
-{
- *--ptr = (val % 10) + '0';
- val /= 10;
-}
-return(ptr);
+ sprintf(buffer,%lu,val);
+ return buffer;
}
/*
@@ -437,7 +426,7 @@ long seconds;
char *format_k(amt)
-int amt;
+unsigned int amt;
{
static char retarray[NUM_STRINGS][16];
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
how to create device nodes when devfs doesn't do it?
Hi, After googling and searching in the mailing list archive I still can't figure out how to make device nodes in -current when devfs doesn't do this automatically. I have an external USB-drive (external 3.5 case with leftover 1.6 GB HD) from which I want to mount /dev/da0s4h. It works fine in -stable, after MAKEDEV'ing the node, but on -current I only get da0s4. My USB flash drive (Apacer Handysteno) works fine; /dev/da0s1d is created after insertion of the flash drive (I reformatted it to UFS, but it also worked with msdosfs, though slower). Using disklabel on the external USB drive shows some warnings: phys9911# disklabel da0s4 # /dev/da0s4: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a:72513 634.2BSD 1024 819216 b: 26989272576 swap c: 3324825 63unused0 0 # raw part, don't edit d: 131544 3424684.2BSD 1024 819216 e:49896 4740124.2BSD 1024 819216 g: 716688 5239084.2BSD 1024 819216 h: 2084292 12405964.2BSD 1024 819216 disklabel: partition c doesn't start at 0! disklabel: partition c doesn't cover the whole unit! disklabel: An incorrect partition c may cause problems for standard system utilities FWIW, this drive contains an OpenBSD 2.7 installation. All partitioning was done by the OpenBSD installer. Any suggestion? (Apart from newfs...) Karel. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
On Mon, Jul 07, 2003 at 03:35:21PM +0200, Marcin Dalecki wrote: Thomas Dickey wrote: On Mon, Jul 07, 2003 at 02:23:25PM +0200, Marcin Dalecki wrote: You know that file system name lookup is one of the most expensive system calls under UNIX? stating the obvious is a clumsy rhetorical ploy (asking for agreement without making a point). The point is that this is one of the reasons why the top command in question takes a lot of relative CPU time under Linux. Some faster versions of procps utils try to cache data but the trade off is simply the fact that the results are not 100% accurate. I tought this was obvious? too obvious. supposing that the application kept an open stream on the procps file and simply did a rewind. (That's assuming that procps was done properly - making it just like a real file ;-) -- Thomas E. Dickey [EMAIL PROTECTED] [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
Hi, I'm not sure, whether this mailing list is the correct place for linux-centered discussions. Perhaps you want to continue via private mail? Regards, harti On Mon, 7 Jul 2003, Dan Nelson wrote: DNIn the last episode (Jul 07), Matthias Andree said: DN Marcin Dalecki schrieb am 2003-07-07: DN Matthias Andree wrote: DN Update your Linux top or run fewer processes on it then. :- DN DN You know that file system name lookup is one of the most expensive DN system calls under UNIX? DN DN So what? If you don't like the interface because it does ever so DN expensive file system lookups (I wonder what's so expensive if no DN disk drive latencies are involved), suggest a better one and donate DN an implementation. DN DN I'm sure I'd find disadvantages of non-Linux top if I only cared to DN look. I don't. It works when I need it, it's not in my way otherwise, DN that's as much as I care. DN DNThere is already a functional non-procfs implementation that has been DNaround long before procps top: groupsys top 3.5b12 (i.e. the top that DNall other non-Linux systems use) compiles fine on even the newest Linux DNkernels with the attached patch. It's one of the first things I build DNon a new Linux box. Procps top is way too slow; it takes a full 5 DNseconds just for the first screen refresh on a mostly-idle box with 400 DNprocesses. groupsys top is basically instantaneous. And don't think DNabout accidentally hitting a cursor or function key which running DNprocps top; it doesn't even use curses, so it beeps and waits 2 seconds DNfor each character in the escape sequence :) DN DN -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildkernel ULE related breakage
On Mon, Jul 07, 2003 at 05:20:10PM +0200, Michal Suszko wrote:
Hi,
Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT
( wrapped long lines )
cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I.
-I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica
-I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
-I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
-fno-common -mno-align-long-strings -mpreferred-stack-boundary=2
-ffreestanding -Werror /usr/src/sys/kern/sched_ule.c
cc1: warnings being treated as errors
/usr/src/sys/kern/sched_ule.c: In function `sched_setup':
/usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i'
*** Error code 1
Stop in /usr/obj/usr/src/sys/TEST.
*** Error code 1
Stop in /usr/src.
*** Error code 1
I sent Jeff the following patch.
--- sched_ule.c.origSun Jul 6 10:43:15 2003
+++ sched_ule.c Sun Jul 6 10:44:00 2003
@@ -528,7 +528,9 @@
static void
sched_setup(void *dummy)
{
+#ifdef SMP
int i;
+#endif
slice_min = (hz/100); /* 10ms */
slice_max = (hz/7); /* ~140ms */
--
Steve
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to create device nodes when devfs doesn't do it?
Karel J. Bosschaart wrote: Hi, After googling and searching in the mailing list archive I still can't figure out how to make device nodes in -current when devfs doesn't do this automatically. I have an external USB-drive (external 3.5 case with leftover 1.6 GB HD) from which I want to mount /dev/da0s4h. It works fine in -stable, after MAKEDEV'ing the node, but on -current I only get da0s4. Have you tried mounting da0s4h? It may show up in /dev after mounting it. Using disklabel on the external USB drive shows some warnings: phys9911# disklabel da0s4 # /dev/da0s4: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a:72513 634.2BSD 1024 819216 b: 26989272576 swap c: 3324825 63unused0 0 # raw part, don't edit d: 131544 3424684.2BSD 1024 819216 e:49896 4740124.2BSD 1024 819216 g: 716688 5239084.2BSD 1024 819216 h: 2084292 12405964.2BSD 1024 819216 disklabel: partition c doesn't start at 0! disklabel: partition c doesn't cover the whole unit! disklabel: An incorrect partition c may cause problems for standard system utilities My experience is that these warnings can be ignored as long as the drive will mount. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/shm
On Mon, 07 Jul 2003, Marcin Dalecki wrote: The point is that this is one of the reasons why the top command in question takes a lot of relative CPU time under Linux. Some faster versions of procps utils try to cache data but the trade off is simply the fact that the results are not 100% accurate. Top data is not accurate (I though that was obvious ;-). It's an obsolete snapshot the very moment it's printed to your console, and I bet it changes as you read with a lot of implementations because no-one wants to beat the big kernel lock on the process list just because some user happens to run top, might be a nice DoS otherwise, fork-bombing top... If you want accurate data, use a kernel debugger with remote interface and make sure the machine does nothing except servicing the debugger interface. I tought this was obvious? Why do I care? 0.58user 0.89system 1:00.91elapsed 2%CPU -- on a 266 MHz Pentium-II, Linux 2.4, 5 years old, with 190 processes. The box idles 73% of the time it's up, there's _ample_ CPU power left. -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
