Nvidia driver cannot compile on FreeBSD 12.0
Hi all I tried to install NVIDIA-FreeBSD-x86_64-418.56 display driver but I get following compilation error: # make install===> src (install)===> src/nvidia (install)cc -O2 -pipe -DNV_VERSION_STRING=\"418.56\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I../common/inc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c nvidia_acpi.c -o nvidia_acpi.oIn file included from nvidia_acpi.c:12:./os-interface.h:27:10: fatal error: 'stdarg.h' file not found#include ^~1 error generated. My OS:# uname -aFreeBSD unga 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64 I used to have a previous version of Nvidia driver running well on FreeBSD 11.2 on the same machine. Any idea? Best regardsUnga ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1 excessive memory allocations [SOLVED]
> > I think you may be reading too much into the malloc manpage. When it > mentions the use of per-thread small-object caches to avoid locking it's > talking about performance, not thread safety. Allocations of all sizes > are thread-safe, the library just assumes that huge allocations are rare > enough that it doesn't use extra per-thread resources to avoid locking > for them, it just uses locking for huge blocks. > > -- Ian > Good to note all allocations are thread safe in FreeBSD. Is it by some standard that malloc should be thread safe regardless the OS (BSDs, Linux, Windows, Android, etc)? Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1 excessive memory allocations [SOLVED]
- Original Message - > From: Ian Lepore > To: Unga > Cc: "freebsd-stable@freebsd.org" > Sent: Wednesday, March 27, 2013 2:06 PM > Subject: Re: FreeBSD 9.1 excessive memory allocations > > On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: >> Hi all >> >> >> I have a heavily threaded C application, developed on an Intel Core i5 > laptop (2 cores) running FreeBSD 8.1-RELEASE. >> >> When this application compile and run on another Intel Core i7 laptop (4 > cores) running FreeBSD 9.1-RELEASE, this application immediately starts > grabbing > memory by over 100MB per second and soon exit with not enough RAM. >> >> >> Both laptops having 4GB RAM. >> >> All malloc and free are mutex locked. >> >> Very rarely this problem happens on the i5 (2 cores) laptop too, but on the > i7 laptop, it happens every time. >> >> Appreciate any feedback to identify and fix this issue. >> >> Best regards >> Unga >> > > Too many moving parts, you need to partition the problem. Is it the > change in OS (and especially libraries) that causes the problem, or the > change in the number of cores (more concurrent threads) is exposing some > sort of application-side race condition? Given the fact that it does > occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely > an application problem. > > Perhaps you could use a tool such as valgrind to help track down the > runaway allocations? > > Another way to expose thread race problems is to force more thread > context switches. A blunt tool for doing so is to set hz=5000 or even > higher in /boot/loader.conf. I've never done that on a desktop or > laptop system, only on embedded systems, but it should still work okay. > If changing the application code is easier, you can get a similar effect > by creating a thread whose only job is to preempt other threads, by > using rtprio_thread() to set it to real time priority, then just have it > sleep for short random intervals (microseconds), all it does is wakes up > and goes right back to sleep. > > Also, FYI, there's no need to use a mutex in your application to protect > allocations. The memory allocator in libc is thread-safe, and in fact > is particularly designed for efficient multi-threaded allocation. > > -- Ian > Dear Tony, Alexander, Jan, Ian and Jeremy Thank you very much for your very valuable comments. Problem seems to be solved. But require more testing. 1. Fixed an application-level crucial bug. This is nearly a 7000 lines C app. It was really hard to see as the application is designed with 8 dedicated threads. 2. At run-time, this application shoots up to about 400 dynamic threads on the i7 machine, whereas on the i5 machine, it only shoots up 57 dynamic threads. It was bit scaring, therefore, made a hard limit on total number of threads to 64. Regarding mutex locks on allocations, as per the malloc(3), it says small and medium size allocations are done from per thread caches, therefore, thread-safe. My allocations are large in nature, about 5-7MB. Best regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 9.1 excessive memory allocations
Hi all I have a heavily threaded C application, developed on an Intel Core i5 laptop (2 cores) running FreeBSD 8.1-RELEASE. When this application compile and run on another Intel Core i7 laptop (4 cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing memory by over 100MB per second and soon exit with not enough RAM. Both laptops having 4GB RAM. All malloc and free are mutex locked. Very rarely this problem happens on the i5 (2 cores) laptop too, but on the i7 laptop, it happens every time. Appreciate any feedback to identify and fix this issue. Best regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
pthreads mostly hang when signal
Hi all
I have a C program with pthreads.
This program creates thousands of detached pthreads for short jobs at the
beginning. They all come and go within the first 10 seconds.
But it has 3 permanently running pthreads.
I signal these 3 permanently running pthreads to stop processing. I send
SIGUSR1 for this purpose.
If I don't interrupt these 3 permanently running pthreads, they run without any
issue and do their job.
If I send the SIGUSR1 to these 3 permanently running pthreads, they rarely
work. That is, these threads immediately receive SIGUSR1 signals.
But when I signal, they mostly hang. That is, these threads don't receive the
signal.
Following code fragment shows how I send the signal and wait till they stop:
LockMutex(threadCountMutex);
tCount = threadCount;
UnlockMutex(threadCountMutex);
printf("B4 stop Thread_1. Threads: %d\n", tCount);
LockMutex(Thread_1varMutex);
Thread_1var.Thread_1Stopped = 0; // Thread_1 not stopped yet.
UnlockMutex(Thread_1varMutex);
if (pthread_kill(tid1, SIGUSR1) != 0) // Send a signal to the thread
{ // to stop processing.
fprintf(stderr, "pthread_kill failed for Thread_1!\n");
exit(1);
}
Delay(25); // Let Thread_1 to settle.
// Check now whether the Thread_1 thread received the signal and stopped
processing.
for (threadActivateDelay=0 ;threadActivateDelay < threadActivateTimeOut;
threadActivateDelay += 50)
{
LockMutex(Thread_1varMutex);
Thread_1Stopped = Thread_1var.Thread_1Stopped;
UnlockMutex(Thread_1varMutex);
if (Thread_1Stopped)
break;
else
Delay(50); // Let Thread_1 thread to settles. 50ms
LockMutex(threadCountMutex);
tCount = threadCount;
UnlockMutex(threadCountMutex);
printf("Wait till Thread_1 stopped, Threads: %d Delay: %d\n", tCount,
threadActivateDelay+50);
}
printf("Came out of Thread_1 loop, threadActivateDelay: %d,
threadActivateTimeOut: %d\n", threadActivateDelay, threadActivateTimeOut);
if (threadActivateDelay >= threadActivateTimeOut) // Something is wrong.
Thread may be dead.
{
fprintf(stderr, "Time out. Thread_1 may be dead!\n");
exit(1);
}
Note, Thread_1var.Thread_1Stopped is set to 1 by the Thread_1 once it receive
the SIGUSR1.
Result of two runs of the program is as follows (values are in milliseconds):
./prog
B4 stop Thread_1. Threads: 3
Thread_1 cought SIGUSR1
Wait till Thread_1 stopped, Threads: 3 Delay: 50
Came out of Thread_1 loop, threadActivateDelay: 50, threadActivateTimeOut: 3000
B4 stop Thread_2. Threads: 3
Thread_2 cought SIGUSR1
Came out of Thread_2 loop, threadActivateDelay: 0, threadActivateTimeOut: 3000
B4 stop Thread_3. Threads: 3
Wait till Thread_3 stopped, Threads: 3 Delay: 50
Wait till Thread_3 stopped, Threads: 3 Delay: 100
Wait till Thread_3 stopped, Threads: 3 Delay: 150
:
:
Wait till Thread_3 stopped, Threads: 3 Delay: 3000
Came out of Thread_3 loop, threadActivateDelay: 3000, threadActivateTimeOut:
3000
Time out. Thread_3 may be dead!
./prog
B4 stop Thread_1. Threads: 3
Wait till Thread_1 stopped, Threads: 3 Delay: 50
Wait till Thread_1 stopped, Threads: 3 Delay: 100
Wait till Thread_1 stopped, Threads: 3 Delay: 150
:
:
Wait till Thread_1 stopped, Threads: 3 Delay: 3000
Came out of Thread_1 loop, threadActivateDelay: 3000, threadActivateTimeOut:
3000
Time out. Thread_1 may be dead!
I have tested this program on FreeBSD 8.1 and 9.0 RC1, both i386. Different
runs hang different threads. Also as I mention earlier, rarely all three
threads stop immediately.
My issue is quite similar to the problem:
http://security.freebsd.org/advisories/FreeBSD-EN-10:02.sched_ule.asc
But it doesn't freeze the system.
Increase threadActivateTimeOut to 6ms also doesn't work once hang.
Please also note, once receive a SIGUSR1, the thread wait on sigwait() till it
receive another signal.
So what have I hit with? Is it a programming error in my side or scheduling
error or something else?
Appreciate very much if FreeBSD guys could help me to solve this issue.
Many thanks in advance.
Best regards
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Weird priority for normal
Hi all I'm using FreeBSD RELENG_7 on i386 and noted with rtprio(2) the priority for root and other normal users is "normal priority" with 65504 as the priority value (rtp.prio). Please note, this is not the latest RELENG_7, my system is compiled somewhere on May. I checked the program flow from /usr/src/usr.bin/su/su.c to /usr/src/lib/libutil/login_class.c and found setusercontext() is setting the priority right but the moment it come out from the setusercontext() call in su.c, the priority has already turn to 65504. It looks like this is a bug. I had a quite thorough look but did not see any error. I'm not sure by now is it been fixed. Do others experience it? Best regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help me to develop a FreeBSD patch for gcc-4.2.1
--- On Wed, 10/8/08, Alexander Kabaev <[EMAIL PROTECTED]> wrote: > If you still have CVS tree available, you can do 'cvs > diff -rFSF' in > contrib/gcc and apply the patches to files gcc-4.2.1/gcc. > Hi Alexander Here is how I made the patch: cd ~ mkdir -pv freebsd cd freebsd cvs -d [EMAIL PROTECTED]:/home/ncvs co -rRELENG_7 src cvs diff -rFSF >& FreeBSD-gcc-4.2.1.patch I have applied the patch on a fresh copy of gcc-4.2.1 and compiled. As before it develops errors: ../../gcc-4.2.1/gcc/c-format.c: In function 'check_format_info_main': ../../gcc-4.2.1/gcc/c-format.c:1780: error: 'flag_format_extensions' undeclared (first use in this function) ../../gcc-4.2.1/gcc/c-format.c:1780: error: (Each undeclared identifier is reported only once ../../gcc-4.2.1/gcc/c-format.c:1780: error: for each function it appears in.) gmake[2]: *** [c-format.o] Error 1 Have I missed out something? Could you help me to move forward from here? For an example, I can over come the above error by adding following lines to the gcc-4.2.1/gcc/config/i386/i386.opt: fformat-extensions Common Report Var(flag_format_extensions) Init(0) Allow FreeBSD kernel-specific printf format specifiers. Is that the correct move forward? Best regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help me to develop a FreeBSD patch for gcc-4.2.1
--- On Wed, 10/8/08, Alexander Kabaev <[EMAIL PROTECTED]> wrote: > > If you still have CVS tree available, you can do 'cvs > diff -rFSF' in > contrib/gcc and apply the patches to files gcc-4.2.1/gcc. > Hi Alexander, thanks for the reply. I'm new to 'cvs diff -rFSF'. I need to do more home work before I try your method. Could you kindly confirm it work for you? after applying the patch, does your compilation of gcc complete cleanly? I get errors. Therefore, could you try it please. I'm waiting for your reply. Best regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help me to develop a FreeBSD patch for gcc-4.2.1
--- On Tue, 10/7/08, Peter Jeremy <[EMAIL PROTECTED]> wrote: > On 2008-Oct-06 06:19:34 -0700, Unga > <[EMAIL PROTECTED]> wrote: > >The FreeBSD stable comes with gcc-4.2.1 but the sources > are scattered > >over the /usr/src, therefore, I find it difficult to > re-create the > >gcc-4.2.1 to its original directory layout to make a > patch. > > The original sources for gcc can be found in > /usr/src/contrib/gcc - > note that this is not a complete gcc 4.2.1 distribution as > parts of > gcc that are not relevant for FreeBSD have been deleted. > Refer to the > FREEBSD-* files for details. > Here is how I did that: 1. Unpack original GCC sources tar -xjf gcc-4.2.1.tar.bz2 mv -v gcc-4.2.1 gcc-4.2.1.orig 2. Bring under one roof FreeBSD-modified GCC sources mkdir -pv gcc-4.2.1 cd gcc-4.2.1 cp -R /usr/src/contrib/gcc . cp -R /usr/src/contrib/gcclibs/ . cp -R /usr/src/contrib/libobjc . cp -R /usr/src/contrib/libstdc++ libstdc++-v3 cd .. 3. Make a patch diff -aur gcc-4.2.1.orig gcc-4.2.1 >& FreeBSD-gcc.patch Now the question is have I collected all the GCC sources from FreeBSD source tree? Have I missed any? Now I unpacked the gcc-4.2.1.tar.bz2 into some other directory and applied this FreeBSD-gcc.patch. Ran configure and compiled. It develop following error: ../../gcc-4.2.1/gcc/c-format.c:1780: error: 'flag_format_extensions' undeclared (first use in this function) ../../gcc-4.2.1/gcc/c-format.c:1780: error: (Each undeclared identifier is reported only once ../../gcc-4.2.1/gcc/c-format.c:1780: error: for each function it appears in.) gmake[2]: *** [c-format.o] Error 1 So where is the flag_format_extensions is declared in FreeBSD? Best regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Help me to develop a FreeBSD patch for gcc-4.2.1
Hi all I need to patch the gcc original sources to suit the FreeBSD, specially to support FreeBSD kernel compilation. I have tried it, spent lot of time, but it still develops compilation errors. The FreeBSD stable comes with gcc-4.2.1 but the sources are scattered over the /usr/src, therefore, I find it difficult to re-create the gcc-4.2.1 to its original directory layout to make a patch. I appreciate it very much, if you guys could help me to identify the pieces. Or alternatively, if someone could straight away put the FreeBSD gcc sources back to a directory and make a patch compared to the original gcc-4.2.1 sources from GNU and post here, I could apply the patch on my side and verify it was done correctly, whether I can compile the FreeBSD kernel or not. Many thanks in advance. Kind regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall compilation issue
--- On Tue, 8/12/08, Unga <[EMAIL PROTECTED]> wrote:
> From: Unga <[EMAIL PROTECTED]>
> Subject: Re: sysinstall compilation issue
> To: freebsd-stable@FreeBSD.ORG
> Cc: [EMAIL PROTECTED]
> Date: Tuesday, August 12, 2008, 3:28 PM
> --- On Fri, 8/8/08, Oliver Fromme
> <[EMAIL PROTECTED]> wrote:
>
> > From: Oliver Fromme <[EMAIL PROTECTED]>
> > Subject: Re: sysinstall compilation issue
> > To: freebsd-stable@FreeBSD.ORG, [EMAIL PROTECTED]
> > Date: Friday, August 8, 2008, 9:36 PM
> > Unga <[EMAIL PROTECTED]> wrote:
> > > This is i386 RELENG_7.
> > >
> > > Following section of the
> > /usr/src/usr.sbin/sysinstall/Makefile does not
> generate C
> > code properly:
> > >
> > > makedevs.c: Makefile rtermcap
> > > echo '#include
> '
> > > makedevs.c
> > > ${RTERMCAP} ansi | \
> > > file2c 'const char
> termcap_ansi[]
> > = {' ',0};' \
> > > > > makedevs.c
> > >
> > > At compile time, above expands to:
> > >
> >
> TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src
> > ./rtermcap ansi | file2c 'const char
> termcap_ansi[] =
> > {' ',0};' >> makedevs.c
> > >
> > > Which generates C code as follows:
> > > const char termcap_ansi[] = {
> > >
> > > ,0};
> > >
> > > That is, it generates 3 lines, which results a
> > compilation error.
> > >
> > > I presume, intended generated code should be:
> > > const char termcap_ansi[] = {' ',0};
> > >
> > > Am I right?
> >
> > No, it should generate an array containung a dump of
> > the "ansi" termcap entry. Please see the
> > file2c(1)
> > manpage.
> >
> > > What is wrong at my end?
> > >
> > > Note, I linked the rtermcap with ncursesw
> libraries,
> > can that be the cause? Any ideas?
> >
> > Yes, that's the cause. Why did you do that?
> >
> > FreeBSD's ncurses port contains a patch so the
> > tgetent()
> > function (which is used by rtermcap) returns the
> actual
> > termcap entry in the buffer. The original ncurses
> code
> > (which is terminfo based) doesn't do that.
> >
> > When you linked rtermcap with the wrong library, you
> > restored the original behaviour of tgetent(), so the
> > output of rtermcap was empty, so file2c produced
> invalid
> > source.
> >
>
> Sorry for my late reply on this. I was not well during
> weekend, an eye ache due to over work :(
>
> Here is the situation at my end, no matter whether I link
> with ncurses widec libs or non-widec libs, its still return
> the same code as above I mentioned.
>
> Possible causes can be:
> 1. The way I compile and install ncurses is not correct.
> 2. OR some essential files required are missing
> 3. OR there can be an other option
>
> I used truss as follows:
> TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src
> truss -o truss.log -f ./rtermcap ansi | file2c 'const
> char termcap_ansi[] = {' ',0};' >>
> makedevs.c
>
> The last few lines of truss.log shows:
> 9310:
> stat("/usr/share/misc/terminfo.db",{mode=-rw-r--r--
> ,inode=22613331,size=
> 3170304,blksize=4096}) = 0 (0x0)
> 9310:
> open("/usr/share/misc/terminfo.db",O_RDONLY,0644)
> = 4 (0x4)
> 9310: fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0)
> 9310:
> read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260)
> = 260 (0x104)
> 9310:
> __sysctl(0xbfbfd574,0x2,0xbfbfd570,0xbfbfd57c,0x0,0x0) = 0
> (0x0)
> 9310: lseek(4,0x132000,SEEK_SET)= 1253376
> (0x132000)
> 9310:
> read(4,"\^^\0\M-|\^O\M-T\^O\M-K\^O\M-*"...,4096)
> = 4096 (0x1000)
> 9310: lseek(4,0x26b000,SEEK_SET)= 2535424
> (0x26b000)
> 9310:
> read(4,"\n\0\M-Y\^O\^O\n\0\n\r\^D\^E\^D"...,4096)
> = 4096 (0x1000)
> 9310: close(4) = 0 (0x0)
> 9310: ioctl(2,TIOCGETA,0xbfbfdba4) = 0 (0x0)
> 9310: ioctl(2,TIOCGETA,0x81020d8) = 0 (0x0)
> 9310: ioctl(2,TIOCGETA,0xbfbfdb64) = 0 (0x0)
> 9310: ioctl(2,TIOCGWINSZ,0xbfbfdbc4)= 0 (0x0)
> 9310: fstat(1,{mode=p-
> ,inode=0,size=0,blksize=4096}) = 0 (0x0)
> 9310: process exit, rval = 0
>
> Note, above log has no entry to open
> /usr/src/usr.sbin/sysinstall/.
Re: sysinstall compilation issue
--- On Fri, 8/8/08, Oliver Fromme <[EMAIL PROTECTED]> wrote:
> From: Oliver Fromme <[EMAIL PROTECTED]>
> Subject: Re: sysinstall compilation issue
> To: freebsd-stable@FreeBSD.ORG, [EMAIL PROTECTED]
> Date: Friday, August 8, 2008, 9:36 PM
> Unga <[EMAIL PROTECTED]> wrote:
> > This is i386 RELENG_7.
> >
> > Following section of the
> /usr/src/usr.sbin/sysinstall/Makefile does not generate C
> code properly:
> >
> > makedevs.c: Makefile rtermcap
> > echo '#include '
> > makedevs.c
> > ${RTERMCAP} ansi | \
> > file2c 'const char termcap_ansi[]
> = {' ',0};' \
> > > > makedevs.c
> >
> > At compile time, above expands to:
> >
> TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src
> ./rtermcap ansi | file2c 'const char termcap_ansi[] =
> {' ',0};' >> makedevs.c
> >
> > Which generates C code as follows:
> > const char termcap_ansi[] = {
> >
> > ,0};
> >
> > That is, it generates 3 lines, which results a
> compilation error.
> >
> > I presume, intended generated code should be:
> > const char termcap_ansi[] = {' ',0};
> >
> > Am I right?
>
> No, it should generate an array containung a dump of
> the "ansi" termcap entry. Please see the
> file2c(1)
> manpage.
>
> > What is wrong at my end?
> >
> > Note, I linked the rtermcap with ncursesw libraries,
> can that be the cause? Any ideas?
>
> Yes, that's the cause. Why did you do that?
>
> FreeBSD's ncurses port contains a patch so the
> tgetent()
> function (which is used by rtermcap) returns the actual
> termcap entry in the buffer. The original ncurses code
> (which is terminfo based) doesn't do that.
>
> When you linked rtermcap with the wrong library, you
> restored the original behaviour of tgetent(), so the
> output of rtermcap was empty, so file2c produced invalid
> source.
>
Sorry for my late reply on this. I was not well during weekend, an eye ache due
to over work :(
Here is the situation at my end, no matter whether I link with ncurses widec
libs or non-widec libs, its still return the same code as above I mentioned.
Possible causes can be:
1. The way I compile and install ncurses is not correct.
2. OR some essential files required are missing
3. OR there can be an other option
I used truss as follows:
TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src truss -o
truss.log -f ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};'
>> makedevs.c
The last few lines of truss.log shows:
9310: stat("/usr/share/misc/terminfo.db",{mode=-rw-r--r-- ,inode=22613331,size=
3170304,blksize=4096}) = 0 (0x0)
9310: open("/usr/share/misc/terminfo.db",O_RDONLY,0644) = 4 (0x4)
9310: fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0)
9310: read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104)
9310: __sysctl(0xbfbfd574,0x2,0xbfbfd570,0xbfbfd57c,0x0,0x0) = 0 (0x0)
9310: lseek(4,0x132000,SEEK_SET)= 1253376 (0x132000)
9310: read(4,"\^^\0\M-|\^O\M-T\^O\M-K\^O\M-*"...,4096) = 4096 (0x1000)
9310: lseek(4,0x26b000,SEEK_SET)= 2535424 (0x26b000)
9310: read(4,"\n\0\M-Y\^O\^O\n\0\n\r\^D\^E\^D"...,4096) = 4096 (0x1000)
9310: close(4) = 0 (0x0)
9310: ioctl(2,TIOCGETA,0xbfbfdba4) = 0 (0x0)
9310: ioctl(2,TIOCGETA,0x81020d8) = 0 (0x0)
9310: ioctl(2,TIOCGETA,0xbfbfdb64) = 0 (0x0)
9310: ioctl(2,TIOCGWINSZ,0xbfbfdbc4)= 0 (0x0)
9310: fstat(1,{mode=p- ,inode=0,size=0,blksize=4096}) = 0 (0x0)
9310: process exit, rval = 0
Note, above log has no entry to open
/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src.
So what can be the issue, ncurses has not been patched correctly or some
essential files missing? If you guys think that ncurses has not been patched
correctly, then I'll open another thread to discuss that.
Best Regards
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysinstall compilation issue
Hi
This is i386 RELENG_7.
Following section of the /usr/src/usr.sbin/sysinstall/Makefile does not
generate C code properly:
makedevs.c: Makefile rtermcap
echo '#include ' > makedevs.c
${RTERMCAP} ansi | \
file2c 'const char termcap_ansi[] = {' ',0};' \
>> makedevs.c
At compile time, above expands to:
TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap
ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c
Which generates C code as follows:
const char termcap_ansi[] = {
,0};
That is, it generates 3 lines, which results a compilation error.
I presume, intended generated code should be:
const char termcap_ansi[] = {' ',0};
Am I right?
That intended code can be generated by a modified statement as:
TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap
ansi | file2c "const char termcap_ansi[] = {""' ',0};"
What is wrong at my end?
Note, I linked the rtermcap with ncursesw libraries, can that be the cause? Any
ideas?
Many thanks in advance.
Kind regards
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bsnmp header files question
Hi Could I know on i386 RELENG_7, what Makefiles install following header files: 1) /usr/include/bsnmp/snmpmod.h 2) /usr/include/bsnmp/snmp_mibII.h 3) /usr/include/bsnmp/snmp_atm.h Appreciate your reply very much. Kind regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: undefined reference to SYS_cpuset
--- On Mon, 7/28/08, Daniel Eischen <[EMAIL PROTECTED]> wrote:
> From: Daniel Eischen <[EMAIL PROTECTED]>
> Subject: Re: undefined reference to SYS_cpuset
> To: "Unga" <[EMAIL PROTECTED]>
> Cc: freebsd-stable@freebsd.org
> Date: Monday, July 28, 2008, 10:58 PM
> On Mon, 28 Jul 2008, Unga wrote:
>
> > --- On Mon, 7/28/08, Daniel Eischen
> <[EMAIL PROTECTED]> wrote:
> >
> >> From: Daniel Eischen <[EMAIL PROTECTED]>
> >> Subject: Re: undefined reference to SYS_cpuset
> >> To: "Unga" <[EMAIL PROTECTED]>
> >> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> freebsd-stable@freebsd.org, [EMAIL PROTECTED]
> >> Date: Monday, July 28, 2008, 10:26 PM
> >> On Mon, 28 Jul 2008, Unga wrote:
> >>
> >>> --- On Mon, 7/28/08, Daniel Eischen
> >> <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> From: Daniel Eischen
> <[EMAIL PROTECTED]>
> >>>> Subject: Re: undefined reference to
> SYS_cpuset
> >>>> To: "Unga"
> <[EMAIL PROTECTED]>
> >>>> Cc: freebsd-stable@freebsd.org
> >>>> Date: Monday, July 28, 2008, 9:19 PM
> >>>> On Mon, 28 Jul 2008, Unga wrote:
> >>>>
> >>>>> Hi all
> >>>>>
> >>>>> Today (28th July) I upgraded the
> FreeBSD
> >> sources
> >>>> (/usr/src) using
> >>>>> cvsup and when try to compile a test C
> program
> >> I get
> >>>> following:
> >>>>>
> >>>>> echo 'main(){}' > dummy.c
> >>>>> cc dummy.c -v -Wl,--verbose
> >>>>>
> >>>>> /usr/lib/libc.so: undefined reference
> to
> >>>> `SYS_cpuset_getaffinity'
> >>>>> /usr/lib/libc.so: undefined reference
> to
> >>>> `SYS_cpuset'
> >>>>> /usr/lib/libc.so: undefined reference
> to
> >>>> `SYS_cpuset_setaffinity'
> >>>>> /usr/lib/libc.so: undefined reference
> to
> >>>> `SYS_cpuset_getid'
> >>>>> /usr/lib/libc.so: undefined reference
> to
> >>>> `SYS_cpuset_setid'
> >>>>> /usr/lib/libc.so: undefined reference
> to
> >>>> `SYS_setfib'
> >>>>> collect2: ld returned 1 exit status
> >>>>>
> >>>>> I can see in logs following programs
> compiled
> >> without
> >>>> any error:
> >>>>> cpuset_getaffinity.S
> >>>>> cpuset.S
> >>>>> cpuset_setaffinity.S
> >>>>> cpuset_getid.S
> >>>>> cpuset_setid.S
> >>>>> setfib.S
> >>>>>
> >>>>> What's gone wrong now? Am I in the
> middle
> >> of a
> >>>> FreeBSD update? or have
> >>>>> I made some mistake? or multiple
> routing
> >> tables update
> >>>> on 20080724
> >>>>> broken something? Any ideas?
> >>>>
> >>>> Did you build and install the kernel
> first?
> >>>>
> >>>
> >>> I have compiled and installed **only**
> following to a
> >> separate location:
> >>> - FreeBSD Headers
> >>> - lib/csu
> >>> - lib/libc
> >>> - lib/msun
> >>> - lib/libc_r
> >>>
> >>> And tested with a simple script whether I can
> compile
> >> and link against new libs successfully before I
> can proceed
> >> with my project. That test, as mentioned in the
> original
> >> post, failed to link against the new C libraries.
> That is,
> >> it looks to me, the libc is now broken.
> >>>
> >>> Of course, the system I'm running is old,
> uname -a
> >> shows May 25. I don't think I have to run the
> latest
> >> kernel for me to separately link against a
> different copy
> >> of libc, do I?
> >>>
> >>> If there a fix or a patch, I can apply against
> the
> >> libc and let you guys know the result.
> >>
> >> The only supported way is to buildkernel and
> buildworld.
> >> You're on your
> >> own if you choose not to go along with the
> procedure in
> >> src/UPDATING.
> >>
> >
> > That may the only way you know how build FreeBSD :(
>
> No, it's not the only way *I* know how to, but if you
> ar
Re: undefined reference to SYS_cpuset
--- On Mon, 7/28/08, Daniel Eischen <[EMAIL PROTECTED]> wrote:
> From: Daniel Eischen <[EMAIL PROTECTED]>
> Subject: Re: undefined reference to SYS_cpuset
> To: "Unga" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], freebsd-stable@freebsd.org, [EMAIL
> PROTECTED]
> Date: Monday, July 28, 2008, 10:26 PM
> On Mon, 28 Jul 2008, Unga wrote:
>
> > --- On Mon, 7/28/08, Daniel Eischen
> <[EMAIL PROTECTED]> wrote:
> >
> >> From: Daniel Eischen <[EMAIL PROTECTED]>
> >> Subject: Re: undefined reference to SYS_cpuset
> >> To: "Unga" <[EMAIL PROTECTED]>
> >> Cc: freebsd-stable@freebsd.org
> >> Date: Monday, July 28, 2008, 9:19 PM
> >> On Mon, 28 Jul 2008, Unga wrote:
> >>
> >>> Hi all
> >>>
> >>> Today (28th July) I upgraded the FreeBSD
> sources
> >> (/usr/src) using
> >>> cvsup and when try to compile a test C program
> I get
> >> following:
> >>>
> >>> echo 'main(){}' > dummy.c
> >>> cc dummy.c -v -Wl,--verbose
> >>>
> >>> /usr/lib/libc.so: undefined reference to
> >> `SYS_cpuset_getaffinity'
> >>> /usr/lib/libc.so: undefined reference to
> >> `SYS_cpuset'
> >>> /usr/lib/libc.so: undefined reference to
> >> `SYS_cpuset_setaffinity'
> >>> /usr/lib/libc.so: undefined reference to
> >> `SYS_cpuset_getid'
> >>> /usr/lib/libc.so: undefined reference to
> >> `SYS_cpuset_setid'
> >>> /usr/lib/libc.so: undefined reference to
> >> `SYS_setfib'
> >>> collect2: ld returned 1 exit status
> >>>
> >>> I can see in logs following programs compiled
> without
> >> any error:
> >>> cpuset_getaffinity.S
> >>> cpuset.S
> >>> cpuset_setaffinity.S
> >>> cpuset_getid.S
> >>> cpuset_setid.S
> >>> setfib.S
> >>>
> >>> What's gone wrong now? Am I in the middle
> of a
> >> FreeBSD update? or have
> >>> I made some mistake? or multiple routing
> tables update
> >> on 20080724
> >>> broken something? Any ideas?
> >>
> >> Did you build and install the kernel first?
> >>
> >
> > I have compiled and installed **only** following to a
> separate location:
> > - FreeBSD Headers
> > - lib/csu
> > - lib/libc
> > - lib/msun
> > - lib/libc_r
> >
> > And tested with a simple script whether I can compile
> and link against new libs successfully before I can proceed
> with my project. That test, as mentioned in the original
> post, failed to link against the new C libraries. That is,
> it looks to me, the libc is now broken.
> >
> > Of course, the system I'm running is old, uname -a
> shows May 25. I don't think I have to run the latest
> kernel for me to separately link against a different copy
> of libc, do I?
> >
> > If there a fix or a patch, I can apply against the
> libc and let you guys know the result.
>
> The only supported way is to buildkernel and buildworld.
> You're on your
> own if you choose not to go along with the procedure in
> src/UPDATING.
>
That may the only way you know how build FreeBSD :(
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: undefined reference to SYS_cpuset
--- On Mon, 7/28/08, Daniel Eischen <[EMAIL PROTECTED]> wrote:
> From: Daniel Eischen <[EMAIL PROTECTED]>
> Subject: Re: undefined reference to SYS_cpuset
> To: "Unga" <[EMAIL PROTECTED]>
> Cc: freebsd-stable@freebsd.org
> Date: Monday, July 28, 2008, 9:19 PM
> On Mon, 28 Jul 2008, Unga wrote:
>
> > Hi all
> >
> > Today (28th July) I upgraded the FreeBSD sources
> (/usr/src) using
> > cvsup and when try to compile a test C program I get
> following:
> >
> > echo 'main(){}' > dummy.c
> > cc dummy.c -v -Wl,--verbose
> >
> > /usr/lib/libc.so: undefined reference to
> `SYS_cpuset_getaffinity'
> > /usr/lib/libc.so: undefined reference to
> `SYS_cpuset'
> > /usr/lib/libc.so: undefined reference to
> `SYS_cpuset_setaffinity'
> > /usr/lib/libc.so: undefined reference to
> `SYS_cpuset_getid'
> > /usr/lib/libc.so: undefined reference to
> `SYS_cpuset_setid'
> > /usr/lib/libc.so: undefined reference to
> `SYS_setfib'
> > collect2: ld returned 1 exit status
> >
> > I can see in logs following programs compiled without
> any error:
> > cpuset_getaffinity.S
> > cpuset.S
> > cpuset_setaffinity.S
> > cpuset_getid.S
> > cpuset_setid.S
> > setfib.S
> >
> > What's gone wrong now? Am I in the middle of a
> FreeBSD update? or have
> > I made some mistake? or multiple routing tables update
> on 20080724
> > broken something? Any ideas?
>
> Did you build and install the kernel first?
>
I have compiled and installed **only** following to a separate location:
- FreeBSD Headers
- lib/csu
- lib/libc
- lib/msun
- lib/libc_r
And tested with a simple script whether I can compile and link against new libs
successfully before I can proceed with my project. That test, as mentioned in
the original post, failed to link against the new C libraries. That is, it
looks to me, the libc is now broken.
Of course, the system I'm running is old, uname -a shows May 25. I don't think
I have to run the latest kernel for me to separately link against a different
copy of libc, do I?
If there a fix or a patch, I can apply against the libc and let you guys know
the result.
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
undefined reference to SYS_cpuset
Hi all
Today (28th July) I upgraded the FreeBSD sources (/usr/src) using cvsup and
when try to compile a test C program I get following:
echo 'main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose
/usr/lib/libc.so: undefined reference to `SYS_cpuset_getaffinity'
/usr/lib/libc.so: undefined reference to `SYS_cpuset'
/usr/lib/libc.so: undefined reference to `SYS_cpuset_setaffinity'
/usr/lib/libc.so: undefined reference to `SYS_cpuset_getid'
/usr/lib/libc.so: undefined reference to `SYS_cpuset_setid'
/usr/lib/libc.so: undefined reference to `SYS_setfib'
collect2: ld returned 1 exit status
I can see in logs following programs compiled without any error:
cpuset_getaffinity.S
cpuset.S
cpuset_setaffinity.S
cpuset_getid.S
cpuset_setid.S
setfib.S
What's gone wrong now? Am I in the middle of a FreeBSD update? or have I made
some mistake? or multiple routing tables update on 20080724 broken something?
Any ideas?
Kind regards
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pseudoterminals increase: compilation error [SOLVED]
--- On Sun, 7/20/08, Peter Jeremy <[EMAIL PROTECTED]> wrote:
> From: Peter Jeremy <[EMAIL PROTECTED]>
> Subject: Re: Pseudoterminals increase: compilation error
> To: "Unga" <[EMAIL PROTECTED]>
> Cc: freebsd-stable@freebsd.org
> Date: Sunday, July 20, 2008, 6:37 PM
> On 2008-Jul-19 19:44:18 -0700, Unga
> <[EMAIL PROTECTED]> wrote:
> >truss -o truss.log -f expect -c "spawn ls"
> >
> > 1178: open("/dev/ptyp0",O_RDWR,027757763030)
>ERR#5 'Input/output error'
> > 1178: open("/dev/ptyp1",O_RDWR,027757763030)
>ERR#5 'Input/output error'
> > 1178: open("/dev/ptyp2",O_RDWR,027757763030)
>= 5 (0x5)
> > 1178: fstat(5,{mode=crw-rw-rw-
> ,inode=178,size=0,blksize=4096}) = 0 (0x0)
> > :
> > :
> > 1178: chown("/dev/ttyp2",1002,4)
>ERR#1 'Operation not permitted'
>
> This is definitely wrong. expect should not be calling
> chown(2),
> it should be calling pt_chown.
>
Yep, it was pt_chown was missing. Fixed the issue. Now ttyp* are created with
correct ownerships.
A big thank specially to Peter Jeremy and all others who helped me to solve
this.
Best regards
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pseudoterminals increase: compilation error
--- On Sun, 7/20/08, Peter Jeremy <[EMAIL PROTECTED]> wrote:
> From: Peter Jeremy <[EMAIL PROTECTED]>
> Subject: Re: Pseudoterminals increase: compilation error
> To: "Unga" <[EMAIL PROTECTED]>
> Cc: freebsd-stable@freebsd.org
> Date: Sunday, July 20, 2008, 6:37 PM
> On 2008-Jul-19 19:44:18 -0700, Unga
> <[EMAIL PROTECTED]> wrote:
> >truss -o truss.log -f expect -c "spawn ls"
> >
> > 1178: open("/dev/ptyp0",O_RDWR,027757763030)
>ERR#5 'Input/output error'
> > 1178: open("/dev/ptyp1",O_RDWR,027757763030)
>ERR#5 'Input/output error'
> > 1178: open("/dev/ptyp2",O_RDWR,027757763030)
>= 5 (0x5)
> > 1178: fstat(5,{mode=crw-rw-rw-
> ,inode=178,size=0,blksize=4096}) = 0 (0x0)
> > :
> > :
> > 1178: chown("/dev/ttyp2",1002,4)
>ERR#1 'Operation not permitted'
>
> This is definitely wrong. expect should not be calling
> chown(2),
> it should be calling pt_chown.
>
Hmm...that's a good point. I'll check that.
> >I'm using Expect-5.43.0 compiled from sources.
> >
> >So, it looks like some sort of a misconfiguration.
> Still investigating.
>
> Have you built the FreeBSD port or used your own build
> configuration?
> If the latter, I suggest you build the port - it works for
> me.
>
Yes, I build my own build configuration. Anyway, I'll check what are the
patches applied by the FreeBSD port.
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pseudoterminals increase: compilation error
--- On Sun, 7/20/08, Unga <[EMAIL PROTECTED]> wrote:
> From: Unga <[EMAIL PROTECTED]>
> Subject: Re: Pseudoterminals increase: compilation error
> To: "Dan Nelson" <[EMAIL PROTECTED]>
> Cc: freebsd-stable@freebsd.org
> Date: Sunday, July 20, 2008, 10:44 AM
> --- On Sun, 7/20/08, Dan Nelson
> <[EMAIL PROTECTED]> wrote:
>
> > Expect's error message doesn't say anything
> except
> > "something isn't
> > working but I won't tell you what". Run
> >
> > truss -o truss.log -f expect -c "spawn ls"
> >
> > and determine which syscall is failing, with what
> error
> > number, just
> > before expect prints its "no more ptys"
> message.
> > That will tell you
> > whether it's a permissions issue, or something
> else.
> > If there are no
> > obvious errors, post a part of the log.
> >
> > Also, what version of expect are you running?
> Versions
> > between
> > 5.38.0_1 and 5.43.0_2 had a bug in the port Makefile
> that
> > limited the
> > number of ptys expect could see. See
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=108311 .
> >
>
> Here are more detail. In fact, I noted it through strace
> after my previous email.
>
> ls -l /dev/ | grep pty
> crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0
> crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:22 ptyp1
>
> truss -o truss.log -f expect -c "spawn ls"
>
> 1178: open("/dev/ptyp0",O_RDWR,027757763030)
> ERR#5 'Input/output error'
> 1178: open("/dev/ptyp1",O_RDWR,027757763030)
> ERR#5 'Input/output error'
> 1178: open("/dev/ptyp2",O_RDWR,027757763030)
> = 5 (0x5)
> 1178: fstat(5,{mode=crw-rw-rw-
> ,inode=178,size=0,blksize=4096}) = 0 (0x0)
> :
> :
> 1178: chown("/dev/ttyp2",1002,4)
> ERR#1 'Operation not permitted'
> 1178: close(5) = 0 (0x0)
> 1178: close(-1) ERR#9
> 'Bad file descriptor'
> 1178: close(-1) ERR#9
> 'Bad file descriptor'
> 1178: open("/",O_RDONLY,027757764430)
> = 5 (0x5)
> 1178: close(5) = 0 (0x0)
> 1178: write(2,"The system has no more ptys.
> As"...,106) = 106 (0x6a)
> 1178: write(2,"\r\n",2)
>= 1179 (0x49b)
> = 2 (0x2)
>
> ls -l /dev/ | grep pty
> crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0
> crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:23 ptyp1
> crw-rw-rw- 1 root wheel 0, 178 Jul 20 10:11 ptyp2
>
> I'm using Expect-5.43.0 compiled from sources.
>
> So, it looks like some sort of a misconfiguration. Still
> investigating.
>
Here is a more narrow down. This problem is happening inside a chroot jail but
only as a normal user:
Here is what it create for following command:
expect -c "spawn ls"
On FreeBSD
==
crw--w 1 test tty 0, 181 Jul 20 10:11 ttyp3
On chroot
=
crw-rw-rw- 1 root wheel 0, 181 Jul 20 10:11 ttyp3
For some reason devfs creates ttys differently.
"devfs rule showsets" shows same for both /dev and /path/dev. Its just 1, 2, 3,
4.
I tried to add a new ruleset as follows (inside chroot jail):
devfs ruleset 10
devfs rule add path tty* type tty mode 660 group tty
devfs rule applyset
Now devfs creates ttys as follows:
crw-rw 1 root tty 0, 179 Jul 20 13:08 ttyp2
So, now the question is how to get the devfs to create ttys owned by the
requested user? or can it be something else?
As for Gavin's suggestion to upgrade to Expect-5.43.0_2, actually, there is no
such version on http://expect.nist.gov/, latest is still Expect-5.43.0.
Regards
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pseudoterminals increase: compilation error
--- On Sun, 7/20/08, Dan Nelson <[EMAIL PROTECTED]> wrote:
> Expect's error message doesn't say anything except
> "something isn't
> working but I won't tell you what". Run
>
> truss -o truss.log -f expect -c "spawn ls"
>
> and determine which syscall is failing, with what error
> number, just
> before expect prints its "no more ptys" message.
> That will tell you
> whether it's a permissions issue, or something else.
> If there are no
> obvious errors, post a part of the log.
>
> Also, what version of expect are you running? Versions
> between
> 5.38.0_1 and 5.43.0_2 had a bug in the port Makefile that
> limited the
> number of ptys expect could see. See
> http://www.freebsd.org/cgi/query-pr.cgi?pr=108311 .
>
Here are more detail. In fact, I noted it through strace after my previous
email.
ls -l /dev/ | grep pty
crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0
crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:22 ptyp1
truss -o truss.log -f expect -c "spawn ls"
1178: open("/dev/ptyp0",O_RDWR,027757763030)ERR#5 'Input/output error'
1178: open("/dev/ptyp1",O_RDWR,027757763030)ERR#5 'Input/output error'
1178: open("/dev/ptyp2",O_RDWR,027757763030)= 5 (0x5)
1178: fstat(5,{mode=crw-rw-rw- ,inode=178,size=0,blksize=4096}) = 0 (0x0)
:
:
1178: chown("/dev/ttyp2",1002,4)ERR#1 'Operation not permitted'
1178: close(5) = 0 (0x0)
1178: close(-1) ERR#9 'Bad file descriptor'
1178: close(-1) ERR#9 'Bad file descriptor'
1178: open("/",O_RDONLY,027757764430) = 5 (0x5)
1178: close(5) = 0 (0x0)
1178: write(2,"The system has no more ptys. As"...,106) = 106 (0x6a)
1178: write(2,"\r\n",2) = 1179 (0x49b)
= 2 (0x2)
ls -l /dev/ | grep pty
crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0
crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:23 ptyp1
crw-rw-rw- 1 root wheel 0, 178 Jul 20 10:11 ptyp2
I'm using Expect-5.43.0 compiled from sources.
So, it looks like some sort of a misconfiguration. Still investigating.
Regards
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pseudoterminals increase: compilation error
--- On Sat, 7/19/08, Peter Jeremy <[EMAIL PROTECTED]> wrote: > From: Peter Jeremy <[EMAIL PROTECTED]> > Subject: Re: Pseudoterminals increase: compilation error > To: "Unga" <[EMAIL PROTECTED]> > Cc: freebsd-stable@freebsd.org > Date: Saturday, July 19, 2008, 8:04 PM > On 2008-Jul-18 18:38:36 -0700, Unga > <[EMAIL PROTECTED]> wrote: > >As per FAQ, > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html, > I tried to increase the number of ptys: > > "10.19.1 > > Build and install a new kernel with the line in the > > configuration file: > > device pty N > > where N is the number of requested > pseudoterminals." > > That has been obsolete for a while. Do you actually have a > problem > with insufficient PTYs? > Looks like, may not be. The Problem: expect -c "spawn ls" spawn ls The system has no more ptys. Ask your system administrator to create more. while executing "spawn ls" It now seems to be a permission problem as explained in http://expect.nist.gov/FAQ.html#q67 . Still investigating. Any help will be very much appreciated. Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pseudoterminals increase: compilation error
--- On Sat, 7/19/08, Unga <[EMAIL PROTECTED]> wrote: > From: Unga <[EMAIL PROTECTED]> > Subject: Re: Pseudoterminals increase: compilation error > To: "Steven Hartland" <[EMAIL PROTECTED]> > Cc: freebsd-stable@freebsd.org > Date: Saturday, July 19, 2008, 10:50 AM > --- On Sat, 7/19/08, Steven Hartland > <[EMAIL PROTECTED]> wrote: > > > From: Steven Hartland <[EMAIL PROTECTED]> > > Subject: Re: Pseudoterminals increase: compilation > error > > To: [EMAIL PROTECTED] > > Cc: freebsd-stable@freebsd.org > > Date: Saturday, July 19, 2008, 10:38 AM > > Ahh according to the man page its not a sysctl: > > kern.pts.max > > > > man 4 pty for more info. > > > > I use the the original BSD pty. According to the man page > kern.pts.max is for SysVR4 pts-like implementation, well, > that how I understand. Anyway, I'll give it a try and > let the list know. > Ooops, I forgot: kern.pts.max defaults to 1000. If this is the default, I may not have a problem :) Regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pseudoterminals increase: compilation error
--- On Sat, 7/19/08, Steven Hartland <[EMAIL PROTECTED]> wrote: > From: Steven Hartland <[EMAIL PROTECTED]> > Subject: Re: Pseudoterminals increase: compilation error > To: [EMAIL PROTECTED] > Cc: freebsd-stable@freebsd.org > Date: Saturday, July 19, 2008, 10:38 AM > Ahh according to the man page its not a sysctl: > kern.pts.max > > man 4 pty for more info. > I use the the original BSD pty. According to the man page kern.pts.max is for SysVR4 pts-like implementation, well, that how I understand. Anyway, I'll give it a try and let the list know. Regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pseudoterminals increase: compilation error
--- On Sat, 7/19/08, Steven Hartland <[EMAIL PROTECTED]> wrote: > From: Steven Hartland <[EMAIL PROTECTED]> > Subject: Re: Pseudoterminals increase: compilation error > To: [EMAIL PROTECTED], freebsd-stable@freebsd.org > Date: Saturday, July 19, 2008, 10:15 AM > iirc pty is totally dynamic in 7 and doesn't require any > special tweaks. > Hi, thanks for the reply. I get this error: "The system has no more ptys. Ask your system administrator to create more." 1) That is, this error message is nothing to do with ptys? What does it trying to say then? 2) Even if ptys are totally dynamic in 7, what is the upper limit and where it is defined? in which source file or header file? Please answer if you know this. I'm really stuck. kind regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Pseudoterminals increase: compilation error
Hi all I'm using FreeBSD 7.0. As per FAQ, http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html, I tried to increase the number of ptys: "10.19.1 Build and install a new kernel with the line in the configuration file: device pty N where N is the number of requested pseudoterminals." I tried to recompile the kernel. I have modified the GENERIC as follows: device pty 64 # Pseudo-ttys (telnet etc) This results a compilation error: config: /usr/src/sys/i386/conf/GENERIC:268: syntax error *** Error code 1 What is the correct syntax? Kind Regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Chuck Swiger <[EMAIL PROTECTED]> wrote: > On May 27, 2008, at 7:51 PM, Unga wrote: > > Appreciate if Chuck Swiger could enlighten us > again on > > what priority X run on Mac OSX? realtime or > normal? > > The X11 server seems to run with mildly elevated > priority (46, where > realtime is > 60 or so); something like an xterm > runs with normal/ > default priority of 31: > > USER PID %CPU %MEM VSZRSS TT STAT > STARTED TIME > PRI COMMAND > root69 0.0 0.279700 3904 ?? Ss > 16May08 0:02.74 > 63 /usr/sbin/coreaudiod Chuck, thank you very much for the info. Can I trouble you a little bit? Is there something equivalent to rtprio(1) (/usr/sbin/rtprio) in Mac OSX? If there is, could you also send following: 1. rtprio 2. rtprio 3. rtprio 4. rtprio Regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Oliver Fromme <[EMAIL PROTECTED]> wrote: > Unga <[EMAIL PROTECTED]> wrote: > > When open an pdf has two types of scenarios in > > FreeBSD: > > 1. When X run as a realtime-prio process, X go > mad and > > swallow up almost all of CPU cycles, making audio > > hiccups. > > That's expected. Running the X server with rtprio > is not > a good idea. There's no reason to do that. > I disagree for this. This may most probably depends on what priority X's clients run. Appreciate if Chuck Swiger could enlighten us again on what priority X run on Mac OSX? realtime or normal? > > 2. When X run as a normal-prio process, X behaves > well > > and rarely gets an audible hiccup. > > That's good. :-) > > > Why X behave different under different priority > > categories? Isn't this scheduler related? > > Very simple: Sometimes the X server consumes lots > of CPU > for a short time. If it runs with rtprio, then no > other > process gets a chance to execute, so your audio > program > will starve. > The audio application obviously run on realtime-prio. So can it starve? If it starve? :) > My recommendation is to not use rtprio or renice. I > think > many people who try to use them are making things > worse. > (In fact I think rtprio and idprio should die.) > Again I disagree on this. I think rtprio and idprio are a great asset to distribute different processes to different priority categories. Example, I may be having the openoffice compilation running for a day. I maybe donating my CPU time to protein synthesis program, SETI, etc and they are running all the time. When I'm not compiling, I may be encoding a hi-def footage running for 10 hours. At the same time, I need to browse and aware what's going on around world and listen to music also. Family members also want to access the computer. You want all of these activities run in one priority category? > > I wonder the issue I mentioned, open a pdf while > > playback audio, is it a issue on Apple Mac OSX? > Could > > somebody give some light here who uses an Apple > Mac > > OSX on this list? > > OSX has a vastly different kernel, scheduler, I/O > system, > audio drivers and so on. It's a completely > different > animal. > Hope by improving things on FreeBSD side, FreeBSD can call it a brother, may be a big bother, rather than an animal :) > Have you tried increasing the audio driver's > buffersize? > It probably helps to alleviate your problem. I > think > OSX sizes the buffer dynamically (not sure though). > This is something I really want to try as soon as I get bit of time. Kind regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Chuck Swiger <[EMAIL PROTECTED]> wrote: > On May 23, 2008, at 6:37 PM, Unga wrote: > > When open an pdf has two types of scenarios in > FreeBSD: > > 1. When X run as a realtime-prio process, X go mad > and swallow up > > almost all of CPU cycles, making audio hiccups. > > > > 2. When X run as a normal-prio process, X behaves > well and rarely > > gets an audible hiccup. > > > > Why X behave different under different priority > categories? Isn't > > this scheduler related? > > Sure. To generalize, the traditional scheduler goal > for Unix has been > to maximize overall throughput and avoid starvation > of even low- > priority tasks, at the expense of higher and > unpredictable latency. > Using realtime priority means that the kernel is > told to minimize > latency for that process even if it means starving > other processes of > CPU time. > > That is well suited for things like CD/DVD burning > or audio/visual > capture, but as you've experienced yourself, it does > poorly for > heavily client-server oriented stuff like X11's > architecture. > > > I wonder the issue I mentioned, open a pdf while > playback audio, is > > it a issue on Apple Mac OSX? > > Nope. :-) > > > Could somebody give some light here who uses an > Apple Mac OSX on > > this list? > > > > If it is not an issue in Mac OSX, how they have > overcome it then? > > > While both FreeBSD and MacOS X are general-purpose > operating systems, > doing multimedia creation and playback is among the > primary > functionality goals for MacOS X, in much the same > way that FreeBSD > regards providing "robust network services" like > Apache, DNS, email, > databases and so forth. > > Core Audio is probably the biggest user of realtime > thread scheduling > under MacOS X, followed by QuickTime or DVD playback > over Core Video. > These frameworks were designed to handle multimedia > without skipping > by preallocating sensible amounts of buffer space, > and they take > advantage of the Mach kernel and IOKit drivers which > are intended to > support realtime needs. Unlike the traditional BSD > kernels, the Mach > kernel was originally designed with SMP, soft & hard > realtime > scheduling in the kernel. The original userland > threads library which > came with Mach, called CThreads, was largely > responsible for the > design that was abstracted into the portable POSIX > threads model > widely used today. > > After FreeBSD 4, there has been a tremendous amount > of work in the > kernel on fine-grained locking and moving device > drivers from running > in the non-preemptable interrupt context to having > device kernel > threads which can be preempted, and there has also > been a lot of work > on the userland side to improve the C threading > libraries and to > improve multithreaded malloc() performance via > jemalloc, but this is > still ongoing and higher level applications like X11 > programs haven't > had years to adapt and take advantage of these > changes. > > Simple things like auto-tuning the size of the audio > buffers to avoid > or minimize skipping or dropouts isn't really in > place yet with > FreeBSD. Realtime video on FreeBSD is dependent > upon X11, which was > originally designed by a bunch of guys at MIT to be > able to display > lots of xterms or other things involving simple > blits of bits, > possibly over the network, in order to replace the > Andrew window > manager system used by CMU, MIT, IBM, and a few > others. X11 wasn't > designed to do alpha channel (aka transparency), > much less stream a > couple of hundred MB per second of data for realtime > OpenGL texturing > or video. (Although, Composite and GLX have since > been added to X11, > they are extensions rather than core functionality, > and hardware > driver support for GLX is less than perfectly > available, especially > once you start looking at the AMD64/EM64T platform, > rather than 32-bit > x86) > > There's a 2002 BSDcon paper here, written around the > time of FreeBSD > 5.x's release, which has more details: > > http://www.usenix.org/events/bsdcon02/full_papers/gerbarg/gerbarg_html/ > Thank you very much for the detailed info. It seems FreeBSD may need two schedulers, one for desktop and one for server, among other things. Kind regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Oliver Fromme <[EMAIL PROTECTED]> wrote: > Unga <[EMAIL PROTECTED]> wrote: > > Idle-prio process which generates lot of I/O is > > understandable. > > > > But when you either record or playback audio as > > realtime-prio and you opened up a pdf document as > > normal-prio, can the pdf rendering in normal-prio > > breaks down the realtime audio process? I don't > think > > pdf rendering is I/O intensive. > > I think it can. > > Opening a PDF causes quite a lot of I/O. The viewer > application has to be paged in from disk, all the > libraries and configuration files it uses, possibly > even parts of the X server have to be paged in, > depending on what features of the X protocol and > which extensions the viewer application uses. > And of course the PDF itself has to be loaded (which > might be not small), and finally all fonts used by > the PDF have to be loaded by the viewer application. > > On the other hand, the default buffer space of the > audio driver is quite small (the reason for that is > to reduce latency for sound effects in games). So > even a very short I/O congestion can cause an > audible > hiccup in audio playback or recording. > > > Using a faster processor or multi-core may solve > this > > problem, > > No, faster I/O hardware will solve it, or hardware > that better supports concurrent access. It's also > quite possible that improvements in FreeBSD's disk > system might solve the problem, i.e. by reordering > disk access in a more efficient manner, but this is > very non-trivial. But all of that is not a matter > of the process scheduler. > > Anotehr solution is to use more aggressive buffering > by either the audio application or the audio driver. > The latter can be set via sysctl. The former is a > matter of your audio application. > > I use mpg123 for mp3 playback on a 3-year old UP > machine. It has a buffer option which I use. > E.g. "mpg123 -b5000" will use 5 MB buffer; that's > enough for half a minute of audio. I do not use > renice, idprio, rtprio or anything, but still > audio playback works perfectly fine, even during > a buildworld. Or when opening a PDF. No hiccups. > Noted your points. When open an pdf has two types of scenarios in FreeBSD: 1. When X run as a realtime-prio process, X go mad and swallow up almost all of CPU cycles, making audio hiccups. 2. When X run as a normal-prio process, X behaves well and rarely gets an audible hiccup. Why X behave different under different priority categories? Isn't this scheduler related? I wonder the issue I mentioned, open a pdf while playback audio, is it a issue on Apple Mac OSX? Could somebody give some light here who uses an Apple Mac OSX on this list? If it is not an issue in Mac OSX, how they have overcome it then? Kind regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Oliver Fromme <[EMAIL PROTECTED]> wrote: > Sorry for the late reply, but I think there's a > technical > detail that should be mentioned ... > > Unga <[EMAIL PROTECTED]> wrote: > > My earlier test shows processes in the normal > category > > can starve processes in real-time category. > That's > > alarming. It should be get fixed. > > Note that FreeBSD does not support "hard real time" > processing. Strictly speaking no OS does that on PC > standard hardware. > > FreeBSD's idprio/rtprio implementation only affects > the decisions of the scheduler, i.e. the assignment > of CPU time slices to processes. However, there are > other resources beside CPU that influence the > execution > of processes. For example disk I/O. > > In other words, if an idle-prio process performs a > lot > of disk accesses, it creates an I/O bottleneck, and > even realtime-prio processes will have to wait > because > the hardware (disk) is blocked. This problem can be > alleviated by using faster and better hardware, e.g. > a SCSI RAID-0 disk subsystem or whatever. Besides, > for professional audio recording you will also need > professional audio hardware (which should include > its > own buffer memory, among other things), not a > consumer > card or an el'cheapo USB dongle. > > Best regards >Oliver > > PS: My notebook at home (Pentium-M, UP, 3 years > old) > works very well with FreeBSD/i386 RELENG_7 + > SCHED_ULE. > Idle-prio process which generates lot of I/O is understandable. But when you either record or playback audio as realtime-prio and you opened up a pdf document as normal-prio, can the pdf rendering in normal-prio breaks down the realtime audio process? I don't think pdf rendering is I/O intensive. Using a faster processor or multi-core may solve this problem, but my question is, can smart scheduling solve it without buying more processors? Kind regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > Can you update your src-all tree to pull this in, > rebuild the kernel, > and tell us if it behaves better for you? > Test 1. amarok in real-time, count in idle priority. last pid: 1331; load averages: 1.15, 1.11, 0.84 up 0+00:22:07 23:03:21 69 processes: 2 running, 67 sleeping CPU: 54.5% user, 0.0% nice, 1.3% system, 0.6% interrupt, 43.6% idle Mem: 119M Active, 168M Inact, 84M Wired, 880K Cache, 60M Buf, 118M Free Swap: 2022M Total, 2022M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1265 root 1 171 i31 3120K 720K CPU0 0 17:54 100.00% count 1239 test 6 440 68380K 54072K ucond 1 0:00 5.37% amarokapp 963 root 1 470 168M 36596K select 0 1:21 4.79% Xorg rtprio 1265 rtprio: idle priority 31 rtprio 1239 rtprio: realtime priority 0 rtprio 963 rtprio: normal priority Result: Excellent. No effect on music for (for 3 songs continuous, count i=63) Interactive response is very good. No complaint. Can browse also at the same time. Test 2. amarok in normal priority, count in idle priority. last pid: 1574; load averages: 1.28, 1.12, 0.95 up 0+00:50:36 23:31:50 68 processes: 2 running, 66 sleeping CPU: 53.0% user, 0.0% nice, 1.3% system, 0.4% interrupt, 45.3% idle Mem: 164M Active, 215M Inact, 84M Wired, 21M Cache, 60M Buf, 4660K Free Swap: 2022M Total, 2022M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1537 root 1 171 i31 3120K 644K CPU0 0 17:20 100.00% count 1509 test 6 450 67356K 43532K ucond 1 0:00 6.40% amarokapp 963 root 1 460 168M 42064K select 0 3:09 3.47% Xorg idprio 1537 idprio: idle priority 31 idprio 1509 idprio: normal priority idprio 963 idprio: normal priority Result: Excellent. No effect on music for (for 4 songs continuous, count i=63) Interactive response is good. Can browse also at the same time. NOTE: Once amarok crashed at count's i=4. This shows processes in idle category does not effect the real-time category as expected. This shows processes in idle category does not effect the normal category as expected, but note amarok crash once with this test. My earlier test shows processes in the normal category can starve processes in real-time category. That's alarming. It should be get fixed. Please make the sched_ule suitable for professional audio production as well as for day to day desktop interactive use. Appreciate if you guys can use JACK to test can there be any audio drop out with various loads when JACK running in real-time as root and real-time normal user. Please compare the sched_ule with Apple Mac OS X, in addition to compare with Linux, Solaris, etc. Its because Apple Mac OS X is used for professional audio and video production, not the Linux or Solaris. Lets get FreeBSD suitable for professional audio and video production. Kind Regards Unga Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> There was a commit to the ULE code in RELENG_7
> approximately 6 hours ago
> by Jeff, indicating some speed improvements in ULE
> when there's heavy
> IRQ activity, and adjustments in the timeslicing
> code for threads which
> don't utilise timesharing:
>
>
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_ule.c
>
> Can you update your src-all tree to pull this in,
> rebuild the kernel,
> and tell us if it behaves better for you?
>
Thanks Jeff for updates and thanks Jeremy for
notifying the list.
I did following test on the new update of sched_ule.c
on RELENG_7.
I ran the amarok music player as realtime, and another
application named count as a normal process. When the
normal process showing the value of i > 20, the amarok
crashes as it cannot keep up the required audio
supply.
That is, normal process starved the realtime process!
PID USERNAMETHR PRI NICE SIZERES STATE C
TIME WCPU COMMAND
1100 root 1 1180 3120K 720K CPU0 0
1:42 100.00% count
963 root 1 460 163M 27368K select 0
0:18 5.96% Xorg
1060 test 6 440 68380K 51568K ucond 1
0:00 5.47% amarokapp
rtprio 963
rtprio: normal priority
rtprio 1060
rtprio: realtime priority 0
rtprio 1100
rtprio: normal priority
/* Count */
#include
main()
{
double nc;
int i;
for (i=0; i < 100; i++)
{
for (nc=0; nc < 20; nc++)
;
printf("%d : %.0f\n", i, nc);
}
}
Kind Regards
Unga
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
ority. You mentioned "experience of massive lagging and slowing down the box when either heavy SATA IO and network IO is performed is aware since then." In this kind of situations, where I/O processing is too much for the current speed of the CPU, you can either increase the speed of the CPU, or introduce multi core or best offload the I/O processing to a I/O co-processor (hardware-based RAID, Intel PRO/1000 network cards can offload IP processing load, etc). I mentioned in my previous email, I listen to music and browse at the same time when buildworld is running. The buildworld is not a I/O intensive process, it's a CPU intensive process. As long as I provide sufficient CPU power and RAM, both 4BSD and ULE schedulers perform well to the extent, the user of the computer is not aware of such a buildworld process is going on. The point I mentioned in my original post is a comparison of the 4BSD to the ULE scheduler. I mentioned the desktop responsiveness of the 4BSD seems better. But the ULE scheduler included in the FreeBSD 7.x is not the latest. The latest ULE scheduler is included in the up coming FreeBSD 8.0. Kind regards Unga Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Norberto Meijome <[EMAIL PROTECTED]> wrote: > On Fri, 11 Apr 2008 07:26:05 -0700 (PDT) > Unga <[EMAIL PROTECTED]> wrote: > > > I listen to FLAC on amarok on professional > headphones > > at the same time browsing web while compiling > 'make > > buildworld' :) > > /me confused... are you saying it your music > listening is not affected by building world while on > 4BSD or ULE ? > > FWIW, i've recently (about 3 weeks) switched to ULE > and I have also seen better performance under heavy > load. > > CPU: Intel(R) Pentium(R) M processor 2.00GHz > (1995.02-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 > Hi Sorry for my late reply. What I mentioned is a fact, that I always do. Yep, the music listening is not affected at all when building world on both 4BSD and ULE. Please note my processor is 3Ghz, may be it can take such a load. Second, I run the buildworld lessor priority than the music player and the browser. Third, have sufficient RAM so that it doesn't swap. Unga Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Pete French <[EMAIL PROTECTED]> wrote: > > What I refer is, when quickly open multiple tabs > (7 or > > 8) in firefox and click on the fist tab to type > user > > id while other tabs still downloading, its seems > there > > is a minor yet noticeable delay that I did not > > experience with sched_4bsd. > > Ah, O.K. - havent noticed that, and it wouldnt > bother me > really. What I found is that if you are doing a > 'make buildworld' > in a window then you can't really use firefox > properly > at all using 4BSD, but you can with ULE. For that I > am > happy to put up with minor delays - overally it's a > lot > more usable. > > > To me, its seems there is no noticeable gain with > > sched_ule, but rather the desktop is bit slow to > > respond. > > Try the compiling experiment and see if you get the > same effect > as I did. For me it;s a bit win, because I couldnt > use the > desktop when I was compiling code. Swingd and > roundabouts > though - if you dont od big comiles then it may seem > theres no > benifit for you. > I listen to FLAC on amarok on professional headphones at the same time browsing web while compiling 'make buildworld' :) Unga __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Pete French <[EMAIL PROTECTED]> wrote: > > I have noted early April that RELENG_7 is upgraded > to > > sched_ule by default and gave it a try with > sched_ule > > until today. My desktop is a 3GHz single Intel > Pentium > > 4 processor with 512MB RAM. I have noted by > desktop > > response wise sched_4bsd is better, ie. the > desktop is > > more responsive. > > Very curious - when I first installed 7.0 the > desktop > performance was horrible and people told me to > switch from > BSd to ULE shceduler. Which I did and it was much > better, > and I have used ULE on all machines even since. I > amm > surprised that you find it worse - what are the > symptoms > here ? > Its not worse, its not as good as sched_4bsd. What I refer is, when quickly open multiple tabs (7 or 8) in firefox and click on the fist tab to type user id while other tabs still downloading, its seems there is a minor yet noticeable delay that I did not experience with sched_4bsd. When I close the firefox, its takes a noticeable delay to go off the window too. To me, its seems there is no noticeable gain with sched_ule, but rather the desktop is bit slow to respond. My point is, the version of the sched_ule in FreeBSD RELENG_7 is old, I like to give it a try with the latest sched_ule to see at least both are equally good on a single processor. The sched_ule should be better on a multi processor machine, but I don't have a one to test it. Unga __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sched_ule performance on single CPU
Hi all I have noted early April that RELENG_7 is upgraded to sched_ule by default and gave it a try with sched_ule until today. My desktop is a 3GHz single Intel Pentium 4 processor with 512MB RAM. I have noted by desktop response wise sched_4bsd is better, ie. the desktop is more responsive. It just noted today the version of the sched_ule.c on RELENG_7 is 1.214.2.2 dated 2007/12/20 and the current version on the CVS is 1.240 dated 2008/04/04. Since the FreeBSD 7.1 is planned to be released with sched_ule by default, why don't you guys sync the sched_ule.c with current so that more users like me who run FreeBSD 7.X (RELENG_7) can give more feedback? Kind regards Unga __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
The Design and Implementation of the FreeBSD Operating System
Hi all Is the following book still relevant to FreeBSD 7.X and upcoming FreeBSD 8.X? Is there a 2nd edition coming soon? The Design and Implementation of the FreeBSD Operating System By Marshall Kirk McKusick, George V. Neville-Neil Published Aug 2, 2004 by Addison Wesley Professional. 1st. Edition ISBN-10: 0-201-70245-2 http://www.informit.com/title/0201702452 Many thanks in advance. Kind regards Unga Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-RELEASE always hang
--- Kevin Oberman <[EMAIL PROTECTED]> wrote: > > From: Tom Evans <[EMAIL PROTECTED]> > > Date: Thu, 29 Nov 2007 12:42:35 + > > Sender: [EMAIL PROTECTED] > > > > On Thu, 2007-11-29 at 03:28 -0800, Unga wrote: > > > --- Michael Proto <[EMAIL PROTECTED]> wrote: > > > > > > > Unga wrote: > > > > > Hi all > > > > > > > > > > I'm using FreeBSD 6.2-RELEASE on Intel P4 > 3.0GHz, > > > > > 512MB Ram computer. > > > > > > > > > > Its very irritatingly hangs very frequently, > more > > > > than > > > > > 10 times a day. Do others find FreeBSD > 6.2-RELEASE > > > > > always hangs? I simply cannot use it for any > > > > serious > > > > > use, not even to send a mail, other than > browsing > > > > web. > > > > > > > > > > I find it mostly when I try to move the > mouse it > > > > > hangs. Upward and downward cursor keys press > and > > > > hold > > > > > also hangs, but not always. These may be > just > > > > > coincidental. How do I find why it hangs? > How is > > > > the > > > > > stability of the upcoming 7.0? > > > > > > > > > > Best Regards > > > > > Unga > > > > > > > > > > > > > I'm sure I'm not alone in this, but I'm > running > > > > several 6.2-RELEASE-p8 > > > > boxes (servers and laptop workstations) for > several > > > > months now without a > > > > single lock-up. I'd first look into hardware, > > > > testing memory, testing > > > > the power supply, and checking CPU/chipset > > > > temperatures as they have > > > > often contributed to problems similar to what > you > > > > are describing. 6.2 > > > > has been working extremely well for me with no > > > > stability issues that > > > > weren't related to hardware problems. > > > > > > > > > > > > > > Thanks for all the replies. > > > > > > It may be a hardware issue. This is a more than > four > > > year old computer. Btw, I forgot to mention this > is > > > not a server, its running KDE, trying to use as > a > > > desktop. > > > > > > Any one of the hangs do not develop any core > dump or > > > /var/crash/kernel.0 or /var/crash/vmcore.0. Just > the > > > cursor disappear and keyboard does not respond. > Only > > > switch off and on can bring the machine up. > > > > > > Are there any hardware analyzing software that I > can > > > run on FreeBSD, so that I could narrow down the > cause? > > > > > > Unga > > > > > > > Can you verify that the machine is actually dead? > Do you have another > > machine that you can hook up either to a serial > console, or ssh into the > > dead box? Weird X symptoms could lead to an > unresponsive keyboard, with > > the machine running just fine underneath X. > > Just to re-enforce this, I have a colleague who is > seeing this on his > Radeon-based Lenovo T43 (m300). The display blanks > and cannot be > resurrected, even CTRL-ALT-BS does not help, but the > system is alive. > > Oddly, I also have a Lenovo T43 based system and it > has never shown this > problem. It might be something in your xorg setup > that is triggering it. > > If your system is a Radeon, you might try booting > with no xorg.conf > file. I have found that worked well for my system. > Other possibilities > include hw.acpi.reset_video=1 (sysctl.conf) and > acpi_video_load="YES" > (loader.conf). > > I would like to figure out why my system has no > issues while others > go off to never-never land. > Mine is also an ATI Radeon card: ATI Technologies Inc RV280 [Radeon 9200 PRO] rev 1 Chipset ATI Radeon 9200PRO 5960 (AGP) I cannot ssh to the machine while its freezes. It says 'no route to host'. That is, the machine is completely dead. The other thing is, FreeBSD installer has not installed an xorg.conf. I have created an xorg.conf using Xorg -configure and moved to /etc/X11/. Adjusted the HorizSync and VertRefresh to match the monitor, driver I used "ati", added Modes and an DRI section with Mode 0666. If it crashes again I'll let the list know. Unga Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-RELEASE always hang
--- Michael Proto <[EMAIL PROTECTED]> wrote: > Unga wrote: > > Hi all > > > > I'm using FreeBSD 6.2-RELEASE on Intel P4 3.0GHz, > > 512MB Ram computer. > > > > Its very irritatingly hangs very frequently, more > than > > 10 times a day. Do others find FreeBSD 6.2-RELEASE > > always hangs? I simply cannot use it for any > serious > > use, not even to send a mail, other than browsing > web. > > > > I find it mostly when I try to move the mouse it > > hangs. Upward and downward cursor keys press and > hold > > also hangs, but not always. These may be just > > coincidental. How do I find why it hangs? How is > the > > stability of the upcoming 7.0? > > > > Best Regards > > Unga > > > > I'm sure I'm not alone in this, but I'm running > several 6.2-RELEASE-p8 > boxes (servers and laptop workstations) for several > months now without a > single lock-up. I'd first look into hardware, > testing memory, testing > the power supply, and checking CPU/chipset > temperatures as they have > often contributed to problems similar to what you > are describing. 6.2 > has been working extremely well for me with no > stability issues that > weren't related to hardware problems. > > Thanks for all the replies. It may be a hardware issue. This is a more than four year old computer. Btw, I forgot to mention this is not a server, its running KDE, trying to use as a desktop. Any one of the hangs do not develop any core dump or /var/crash/kernel.0 or /var/crash/vmcore.0. Just the cursor disappear and keyboard does not respond. Only switch off and on can bring the machine up. Are there any hardware analyzing software that I can run on FreeBSD, so that I could narrow down the cause? Unga Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 6.2-RELEASE always hang
Hi all I'm using FreeBSD 6.2-RELEASE on Intel P4 3.0GHz, 512MB Ram computer. Its very irritatingly hangs very frequently, more than 10 times a day. Do others find FreeBSD 6.2-RELEASE always hangs? I simply cannot use it for any serious use, not even to send a mail, other than browsing web. I find it mostly when I try to move the mouse it hangs. Upward and downward cursor keys press and hold also hangs, but not always. These may be just coincidental. How do I find why it hangs? How is the stability of the upcoming 7.0? Best Regards Unga Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
