Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
Antony Mawer skrev: On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best wrote: hi everyone, together with hugh mahon (the author of ee) i've been trying to fix a nasty bug in ee. for some reason ee exits (not crashes) and leaves the console corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all running ee instances). I noticed this the other day when working on a new 8.0-RC1 system... in my case I was using putty (Windows ssh client) to access the system and maximised the window I had ee running in, and noticed ee just dumped me straight to the prompt. I am wondering if this has anything to do with the new tty subsystem in 8.0, as this wasn't a problem I've experienced before under 7.x... I've been using ee in Mac OSX for a while and I see the exact same behaviour, ee exits when I resize the terminal window. I haven't seen it in FreeBSD yet, but that is probably because I don't use Xorg on any of my FreeBSD systems... -- Joel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
On Fri, 23 Oct 2009, Antony Mawer wrote: On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best wrote: hi everyone, together with hugh mahon (the author of ee) i've been trying to fix a nasty bug in ee. for some reason ee exits (not crashes) and leaves the console corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all running ee instances). I noticed this the other day when working on a new 8.0-RC1 system... in my case I was using putty (Windows ssh client) to access the system and maximised the window I had ee running in, and noticed ee just dumped me straight to the prompt. Seems a good start might be to compile ncurses with -g, link ee against it, put a breakpoint on the SIGWINCH handler, and start single stepping... -- Nate Eldredge n...@thatsmathematics.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best wrote: > hi everyone, > > together with hugh mahon (the author of ee) i've been trying to fix a nasty > bug in ee. for some reason ee exits (not crashes) and leaves the console > corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all > running ee instances). I noticed this the other day when working on a new 8.0-RC1 system... in my case I was using putty (Windows ssh client) to access the system and maximised the window I had ee running in, and noticed ee just dumped me straight to the prompt. I am wondering if this has anything to do with the new tty subsystem in 8.0, as this wasn't a problem I've experienced before under 7.x... Maybe worth cc'ing ed@ to see if he has any thoughts? --Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
help needed to fix contrib/ee crash/exit when receiving SIGWINCH
hi everyone,
together with hugh mahon (the author of ee) i've been trying to fix a nasty
bug in ee. for some reason ee exits (not crashes) and leaves the console
corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all
running ee instances).
unfortunately we were unable to find the problem. it seems to be related to
ncurses. running the ee linux binary under freebsd causes no problem with
SIGWINCH at all. since the linux binary doesn't need to be linked against
ncurses (linux has termio.h/sgtty.h) we assume the problem is related to
ncurses.
right at the beginning of the ee code all signals get set to SIG_IGN:
for (counter = 1; counter <= 32; counter++)
signal(counter, SIG_IGN);
so actually SIGWINCH shouldn't cause any problems since it gets discarded.
looking through the src i'm quite sure that SIGWINCH stays set to SIG_IGN the
whole time.
yet running ee with truss shows this result when doing `grep WINCH`:
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigaction(SIGWINCH,{ SIG_IGN SA_RESTART ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
sigaction(SIGWINCH,0x0,{ SIG_IGN SA_RESTART ss_t }) = 0 (0x0)
sigaction(SIGWINCH,{ 0x280bc130 0x0 ss_t },0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
so SIGWINCH doesn't stay set to SIG_IGN the whole time. it seems the problem
is being caused by some ncurses function which gets called in contrib/ee/ee.c.
contrib/ee/new_curse* aren't used since ee relies in freebsd's local ncurse
implementation.
it would be really great if this nasty bug could be fixed. you'll find a
problem report here: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/136223
please don't hesitate to ask for more details.
cheers.
alex
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Failure to boot from HD formatted not by FreeBSD
Looks to me like you're trying to get your computer to dual-boot Vista and FreeBSD 8.0, something I finally succeeded in doing. If by "MBR" you mean the first-stage boot program (512 bytes), I couldn't get that to work, nor could I use the standard boot0 menu from FreeBSD. I'm using the windows boot program instead. I think what I did was copy "/boot/boot1" from my root partition to my NTFS partition and then added an option to the Windows boot menu to boot with it. I get the GEOM "track boundary" complaint when I boot up as well. The FBSD 8.0 kernel has a new option 'GEOM_PART_MBR" on by default. Vista insisted on partitioning my drive, so if the new partition handler doesn't like it, it can lump it. In order to get the 8.0 kernel to recognise your old partitions, you need the "GEOM_MBR" option activated. That means you need to load "geom_mbr.ko" into memory before you load and boot from the 8.0 kernel. If you're booting from a FreeBSD 8.0 CD directly into sysinstall, you can escape to a shell and kldload geom_mbr.ko, but you have to then restart sysinstall without rebooting the computer in order for your hard disk partitions to show up. The only reliable way I could find to restart systinstall without rebooting was by pressing the power button. Wierd, eh? I added "option GEOM_MBR" back into my kernel, recompiled, fiddled with my network settings, and now everything seems to work alright. Anyway, all this procedure should be 75% correct since I've managed to successfully upgrade to 8.0 from 7-stable this way. For all I know, I might end up with a corrupted partition six months from now. Either that or Marcel Moolenar will get angry at me. Regards, Andrew Lankford ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bug in pkg_add ? doesn't fetch dependencies from set path
I realized that this was probably the case only after I sent the email, but this keeps me from having to test so thanks. I do think the documentation leads one to think differently about what PACKAGESITE does; perhaps I'll try to submit a clarification. As I read it, it talks about "subverting the logic" of the fetches, which led me to think the expected hierarchy would be subverted- something like that. -T --- On Thu, 10/22/09, Glen Barber wrote: From: Glen Barber Subject: Re: bug in pkg_add ? doesn't fetch dependencies from set path To: "Trever" Cc: freebsd-hackers@freebsd.org Date: Thursday, October 22, 2009, 12:57 PM Hello, On Thu, Oct 22, 2009 at 2:41 PM, Trever wrote: > Does anyone else have this problem? > # env | grep PACKAGEPACKAGESITE=ftp://ftp.ourdomain.gov/FBSD/# pkg_add -r > subversion-1.6.5Fetching ftp://ftp.ourdomain.gov/FBSD/subversion-1.6.5.tbz... > Done.Error: FTP Unable to get > ftp://ftp.ourdomain.gov/All/pkg-config-0.23_1.tbz: File unavailable (e.g., > file not found, no access)Error: FTP Unable to get > ftp://ftp.ourdomain.gov/All/sqlite3-3.6.14.2.tbz: File unavailable (e.g., > file not found, no access)Error: FTP Unable to get > ftp://ftp.ourdomain.gov/All/gettext-0.17_1.tbz: File unavailable (e.g., file > not found, no access)Error: FTP Unable to get > ftp://ftp.ourdomain.gov/All/neon28-0.28.4.tbz: File unavailable (e.g., file > not found, no access) > > In plain English:pkg_add -r goes to the correct domain and path (per > environment variable I set) to fetch the package I want to install, but when > it goes to get the dependencies for the package it just correctly fetched, it > subsequently fetches to the wrong path (goes to /All instead of /FBSD), > though it does fetch to the correct domain. > This is a pain because our ftp server has many uses, and having an "All" > directory in the root is ugliness (whether All is a link to FBSD or whatever, > I don't want "All", I just want "FBSD"). > I have tried various combinations of setting both or one of PACKAGESITE > and/or PACKAGEROOT, just in case that would somehow help, but to no avail. > Of course it would seem that PACKAGESITE alone is what I want (but that and > nothing else I have tried works). > Thank you much. > -T > pkg_add(1) expects the PACKAGESITE to follow the same hierarchy as a tinderbox. Without a tinderbox, you can 'mkdir /usr/ports/packages' on your local build server. When you 'make package' (or your preferred choice) the packages will be put in /usr/ports/packages with the correct hierarchy, symlinks to PACKAGESITE/All/ etc. HTH. -- Glen Barber ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: semaphores between processes
On Thu, Oct 22, 2009 at 04:08:11PM -0400, Andrew Gallatin wrote: > We then moved on to posix semaphores. Using sem_wait/sem_post > with the sem_t residing in a shared page seems to work on > all 3 platforms. However, the FreeBSD (7-stable) man page > for sem_init(3) has this scary text regarding the pshared > value: > The sem_init() function initializes the unnamed semaphore pointed > to by > sem to have the value value. A non-zero value for pshared specifies a > shared semaphore that can be used by multiple processes, which this > implementation is not capable of. > Is this text obsolete? Or is my test just "getting lucky"? They work, but only if the processes are related and do not exec and the parent process initializes the semaphores before forking. This is because sem_t is a pointer to a malloc'ed structure. For process-shared semaphores this really only contains an identifier of the kernel semaphore. This also means process-shared semaphores are slower than in-process semaphores (libthr implements those using atomics and umtx so that system calls are only needed if a thread needs to sleep or be awakened). This is documented in comments in the source code, but not in man pages or other documentation. > Is there recommended way to do this? Apart from sysv semaphores, perhaps posix named semaphores (sem_open() etc). These require a 'kldload sem' on older versions though. -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Failure to boot from HD formatted not by FreBSD
I wonder what are the limitations of MBR (/boot/boot0)? I have the OEM-formatted harddrive (160MB), on which I want to add FreeBSD into the free space. I created the FreeBSD partition, set MBR (in 8.0-RC2), but when it displays the boot prompt and I hit some key I only see '#' character printed and nothing happens. When I took MBR from my older FreeBSD HD and placed it on that one, it doesn't print '#' characters but also doesn't boot. When I boot into the healthy system with this new OEM HD attached I also see dmesg messages like this: GEOM: ad4: partition 2 does not start on a track boundary. What could be wrong, why it doesn't boot? Yuri --- partitions in MBR --- Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX) start 2079, size 44039457 (21503 Meg), flag 80 (active) beg: cyl 0/ head 33/ sector 1; end: cyl 1023/ head 116/ sector 63 The data for partition 2 is: sysid 15 (0x0f),(Extended DOS (LBA)) start 220416000, size 61222912 (29894 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 53/ sector 58 The data for partition 3 is: sysid 18 (0x12),(Compaq diagnostics) start 281638912, size 30942896 (15108 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 80/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 44041536, size 176373792 (86120 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 55/ sector 63 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: semaphores between processes
On Thu, Oct 22, 2009 at 11:08 PM, Andrew Gallatin wrote: > Hi, > > We're designing some software which has to lock access to > shared memory pages between several processes, and has to > run on Linux, Solaris, and FreeBSD. We were planning to > have the lock be a pthread_mutex_t residing in the > shared memory page. This works well on Linux and Solaris, > but FreeBSD (at least 7-stable) does not support > PTHREAD_PROCESS_SHARED mutexes. > > We then moved on to posix semaphores. Using sem_wait/sem_post > with the sem_t residing in a shared page seems to work on > all 3 platforms. However, the FreeBSD (7-stable) man page > for sem_init(3) has this scary text regarding the pshared > value: > > The sem_init() function initializes the unnamed semaphore pointed to by > sem to have the value value. A non-zero value for pshared specifies a > shared semaphore that can be used by multiple processes, which this > implementation is not capable of. > > Is this text obsolete? Or is my test just "getting lucky"? > > Is there recommended way to do this? > > Thanks, > > Drew Hi Andrew, This works in Linux is because Linux defines sem_t as a struct type(or union, IIRC), while our sem_t is a pointer type (with more state kept in the pointed struct). SYSV semaphores seems the way to go... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: semaphores between processes
On Thu, 22 Oct 2009, Andrew Gallatin wrote: Daniel Eischen wrote: On Thu, 22 Oct 2009, Andrew Gallatin wrote: Hi, We're designing some software which has to lock access to shared memory pages between several processes, and has to run on Linux, Solaris, and FreeBSD. We were planning to have the lock be a pthread_mutex_t residing in the shared memory page. This works well on Linux and Solaris, but FreeBSD (at least 7-stable) does not support PTHREAD_PROCESS_SHARED mutexes. We then moved on to posix semaphores. Using sem_wait/sem_post with the sem_t residing in a shared page seems to work on all 3 platforms. However, the FreeBSD (7-stable) man page for sem_init(3) has this scary text regarding the pshared value: The sem_init() function initializes the unnamed semaphore pointed to by sem to have the value value. A non-zero value for pshared specifies a shared semaphore that can be used by multiple processes, which this implementation is not capable of. Is this text obsolete? Or is my test just "getting lucky"? I think you're getting lucky. Yes, after playing with the code some, I now see that. :( Is there recommended way to do this? I believe the only way to do this is with SYSV semaphores (semop, semget, semctl). Unfortunately, these are not as easy to use, IMHO. Yes, they are pretty ugly, and we were hoping to avoid them. Are there any plans to support either PTHREAD_PROCESS_SHARED mutexes, or pshared posix semaphores in FreeBSD? It's planned, just not (yet) being actively worked on. It's a API change mostly, and then adding in all the compat hooks so we don't break ABI. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: semaphores between processes
On Thu, 22 Oct 2009, Andrew Gallatin wrote: Hi, We're designing some software which has to lock access to shared memory pages between several processes, and has to run on Linux, Solaris, and FreeBSD. We were planning to have the lock be a pthread_mutex_t residing in the shared memory page. This works well on Linux and Solaris, but FreeBSD (at least 7-stable) does not support PTHREAD_PROCESS_SHARED mutexes. We then moved on to posix semaphores. Using sem_wait/sem_post with the sem_t residing in a shared page seems to work on all 3 platforms. However, the FreeBSD (7-stable) man page for sem_init(3) has this scary text regarding the pshared value: The sem_init() function initializes the unnamed semaphore pointed to by sem to have the value value. A non-zero value for pshared specifies a shared semaphore that can be used by multiple processes, which this implementation is not capable of. Is this text obsolete? Or is my test just "getting lucky"? I think you're getting lucky. Is there recommended way to do this? I believe the only way to do this is with SYSV semaphores (semop, semget, semctl). Unfortunately, these are not as easy to use, IMHO. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: semaphores between processes
Daniel Eischen wrote: On Thu, 22 Oct 2009, Andrew Gallatin wrote: Hi, We're designing some software which has to lock access to shared memory pages between several processes, and has to run on Linux, Solaris, and FreeBSD. We were planning to have the lock be a pthread_mutex_t residing in the shared memory page. This works well on Linux and Solaris, but FreeBSD (at least 7-stable) does not support PTHREAD_PROCESS_SHARED mutexes. We then moved on to posix semaphores. Using sem_wait/sem_post with the sem_t residing in a shared page seems to work on all 3 platforms. However, the FreeBSD (7-stable) man page for sem_init(3) has this scary text regarding the pshared value: The sem_init() function initializes the unnamed semaphore pointed to by sem to have the value value. A non-zero value for pshared specifies a shared semaphore that can be used by multiple processes, which this implementation is not capable of. Is this text obsolete? Or is my test just "getting lucky"? I think you're getting lucky. Yes, after playing with the code some, I now see that. :( Is there recommended way to do this? I believe the only way to do this is with SYSV semaphores (semop, semget, semctl). Unfortunately, these are not as easy to use, IMHO. Yes, they are pretty ugly, and we were hoping to avoid them. Are there any plans to support either PTHREAD_PROCESS_SHARED mutexes, or pshared posix semaphores in FreeBSD? Thanks, Drew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bug in pkg_add ? doesn't fetch dependencies from set path
Hello, On Thu, Oct 22, 2009 at 2:41 PM, Trever wrote: > Does anyone else have this problem? > # env | grep PACKAGEPACKAGESITE=ftp://ftp.ourdomain.gov/FBSD/# pkg_add -r > subversion-1.6.5Fetching ftp://ftp.ourdomain.gov/FBSD/subversion-1.6.5.tbz... > Done.Error: FTP Unable to get > ftp://ftp.ourdomain.gov/All/pkg-config-0.23_1.tbz: File unavailable (e.g., > file not found, no access)Error: FTP Unable to get > ftp://ftp.ourdomain.gov/All/sqlite3-3.6.14.2.tbz: File unavailable (e.g., > file not found, no access)Error: FTP Unable to get > ftp://ftp.ourdomain.gov/All/gettext-0.17_1.tbz: File unavailable (e.g., file > not found, no access)Error: FTP Unable to get > ftp://ftp.ourdomain.gov/All/neon28-0.28.4.tbz: File unavailable (e.g., file > not found, no access) > > In plain English:pkg_add -r goes to the correct domain and path (per > environment variable I set) to fetch the package I want to install, but when > it goes to get the dependencies for the package it just correctly fetched, it > subsequently fetches to the wrong path (goes to /All instead of /FBSD), > though it does fetch to the correct domain. > This is a pain because our ftp server has many uses, and having an "All" > directory in the root is ugliness (whether All is a link to FBSD or whatever, > I don't want "All", I just want "FBSD"). > I have tried various combinations of setting both or one of PACKAGESITE > and/or PACKAGEROOT, just in case that would somehow help, but to no avail. > Of course it would seem that PACKAGESITE alone is what I want (but that and > nothing else I have tried works). > Thank you much. > -T > pkg_add(1) expects the PACKAGESITE to follow the same hierarchy as a tinderbox. Without a tinderbox, you can 'mkdir /usr/ports/packages' on your local build server. When you 'make package' (or your preferred choice) the packages will be put in /usr/ports/packages with the correct hierarchy, symlinks to PACKAGESITE/All/ etc. HTH. -- Glen Barber ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
semaphores between processes
Hi, We're designing some software which has to lock access to shared memory pages between several processes, and has to run on Linux, Solaris, and FreeBSD. We were planning to have the lock be a pthread_mutex_t residing in the shared memory page. This works well on Linux and Solaris, but FreeBSD (at least 7-stable) does not support PTHREAD_PROCESS_SHARED mutexes. We then moved on to posix semaphores. Using sem_wait/sem_post with the sem_t residing in a shared page seems to work on all 3 platforms. However, the FreeBSD (7-stable) man page for sem_init(3) has this scary text regarding the pshared value: The sem_init() function initializes the unnamed semaphore pointed to by sem to have the value value. A non-zero value for pshared specifies a shared semaphore that can be used by multiple processes, which this implementation is not capable of. Is this text obsolete? Or is my test just "getting lucky"? Is there recommended way to do this? Thanks, Drew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
bug in pkg_add ? doesn't fetch dependencies from set path
Does anyone else have this problem? # env | grep PACKAGEPACKAGESITE=ftp://ftp.ourdomain.gov/FBSD/# pkg_add -r subversion-1.6.5Fetching ftp://ftp.ourdomain.gov/FBSD/subversion-1.6.5.tbz... Done.Error: FTP Unable to get ftp://ftp.ourdomain.gov/All/pkg-config-0.23_1.tbz: File unavailable (e.g., file not found, no access)Error: FTP Unable to get ftp://ftp.ourdomain.gov/All/sqlite3-3.6.14.2.tbz: File unavailable (e.g., file not found, no access)Error: FTP Unable to get ftp://ftp.ourdomain.gov/All/gettext-0.17_1.tbz: File unavailable (e.g., file not found, no access)Error: FTP Unable to get ftp://ftp.ourdomain.gov/All/neon28-0.28.4.tbz: File unavailable (e.g., file not found, no access) In plain English:pkg_add -r goes to the correct domain and path (per environment variable I set) to fetch the package I want to install, but when it goes to get the dependencies for the package it just correctly fetched, it subsequently fetches to the wrong path (goes to /All instead of /FBSD), though it does fetch to the correct domain. This is a pain because our ftp server has many uses, and having an "All" directory in the root is ugliness (whether All is a link to FBSD or whatever, I don't want "All", I just want "FBSD"). I have tried various combinations of setting both or one of PACKAGESITE and/or PACKAGEROOT, just in case that would somehow help, but to no avail. Of course it would seem that PACKAGESITE alone is what I want (but that and nothing else I have tried works). Thank you much. -T ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: About FreeBSD syscall usage
Stanislav Sedov wrote: On Thu, 22 Oct 2009 16:20:32 +0800 "Yan, Yeqing" mentioned: kse_exit kse_wakeup kse_create kse_thr_interrupt kse_release kse_switchin I read $man kse, but I can not find any example about how to use it. I write some test codes to call these function but all these codes are failed. The kse man page documents the syscalls but they are intended to be used only by the libkse library. there was some early test code in /usr/src/tools/KSE but it probably doesn't eve n compile any more. mac_syscall I read $man 3 mac, but I can not find the usage about mac_syscall function. thr_create thr_suspend thr_kill2 Once again, these calls are meant to be only accessed from the threading library. (though man pages should be written) I fear there's no documentation on these syscalls exists. So for use information you'll have to refer to the actual source code of these syscalls/or and libc/libthr source code which makes uses of them. By the way, it is said “I think that KSE was used in 5.x and 6.x and then dropped in favor of a 1:1 threading model when 7.0 was released” Does it mean the KSE syscall can be removed from FreeBSD 7.0? it will remain oin all 7.x kernels but is removed from 8.x libkse (M:N threading) was default threading library on FreeBSD versions prior to 7.0, and the default has changed to libthr (1:1 threading in FreeBSD 7). libkse was completely removed in FreeBSD 8, but it is still functional on FreeBSD 7.x. KSE based threading, while theoretically useful introduces a number of annoying complications to the kernel and was "holding up" other developement. Since Linux has gone with 1:1 threading, nearly all applications a re now written with 1:1 threading in mind so it made little sense to maintain all the extra complexity for no reason. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: About FreeBSD syscall usage
On Thursday 22 October 2009 4:20:32 am Yan, Yeqing wrote: > Hi: > > I’m from Intel China. Our project use FreeBSD 7.0. I have some question about syscall usage but I think mail to the wrong address before. > > Is there having any doc or example about how to use these syscall? > > > > kse_exit > > kse_wakeup > > kse_create > > kse_thr_interrupt > > kse_release > > kse_switchin These are used internally to implement pthreads when using KSE. Probably the only useful documentation would be the source for libkse. > I read $man kse, but I can not find any example about how to use it. I write some test codes to call these function but all these codes are failed. > > > > mac_syscall > > I read $man 3 mac, but I can not find the usage about mac_syscall function. This one I am not sure of. > thr_create > > thr_suspend > > thr_kill2 These are used by libpthread to implement pthreads (libthr in < 7.x). The best documentation for these would be the source to libpthread as well. > By the way, it is said “I think that KSE was used in 5.x and 6.x and then dropped in favor of a 1:1 threading model when 7.0 was released” > > Does it mean the KSE syscall can be removed from FreeBSD 7.0? It has been removed entirely from 8.0. It is still present in 7, but it is deprecated and not the default. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: About FreeBSD syscall usage
On Thu, 22 Oct 2009 16:20:32 +0800 "Yan, Yeqing" mentioned: > kse_exit > > kse_wakeup > > kse_create > > kse_thr_interrupt > > kse_release > > kse_switchin > > I read $man kse, but I can not find any example about how to use it. I write > some test codes to call these function but all these codes are failed. > > > > mac_syscall > > I read $man 3 mac, but I can not find the usage about mac_syscall function. > > > > thr_create > > thr_suspend > > thr_kill2 > I fear there's no documentation on these syscalls exists. So for use information you'll have to refer to the actual source code of these syscalls/or and libc/libthr source code which makes uses of them. > > By the way, it is said “I think that KSE was used in 5.x and 6.x and then > dropped in favor of a 1:1 threading model when 7.0 was released” > > Does it mean the KSE syscall can be removed from FreeBSD 7.0? > libkse (M:N threading) was default threading library on FreeBSD versions prior to 7.0, and the default has changed to libthr (1:1 threading in FreeBSD 7). libkse was completely removed in FreeBSD 8, but it is still functional on FreeBSD 7.x. -- Stanislav Sedov ST4096-RIPE pgpRYNN2HYp1t.pgp Description: PGP signature
About FreeBSD syscall usage
Hi: I’m from Intel China. Our project use FreeBSD 7.0. I have some question about syscall usage but I think mail to the wrong address before. Is there having any doc or example about how to use these syscall? kse_exit kse_wakeup kse_create kse_thr_interrupt kse_release kse_switchin I read $man kse, but I can not find any example about how to use it. I write some test codes to call these function but all these codes are failed. mac_syscall I read $man 3 mac, but I can not find the usage about mac_syscall function. thr_create thr_suspend thr_kill2 By the way, it is said “I think that KSE was used in 5.x and 6.x and then dropped in favor of a 1:1 threading model when 7.0 was released” Does it mean the KSE syscall can be removed from FreeBSD 7.0? Thank you very much! -Original Message- From: Kevin Kinsey [mailto:k...@daleco.biz] Sent: 2009年10月21日 22:18 To: Yan, Yeqing Cc: freebsd-questi...@freebsd.org Subject: Re: Question about FreeBSD syscall usage Yan, Yeqing wrote: > Hi: > I'm from Intel China. Our project use FreeBSD 7.0 > and I have some questions about the FreeBSD syscall. > I don't know how to use these syscall below. > Is there having some doc or example about how to use these syscall? > > kse_exit > kse_wakeup > kse_create > kse_thr_interrupt > kse_release > kse_switchin > > mac_syscall > > thr_create > thr_suspend > thr_kill2 > > Thank you very much! > > Best Regards > Yan, Yeqing Hello Yeqing, You might want to write to "hack...@freebsd.org" ... ... some of those guys *wrote* these syscalls. However, since it's a question, I'll take a stab at it. Have you read: $man kse $man 3 mac $man libthr ? Also, see www.freebsd.org/kse/ However, I think that KSE was used in 5.x and 6.x and then dropped in favor of a 1:1 threading model when 7.0 was released (I'm sure some "hacker@" can correct this information if I'm wrong). I hope this is helpful to you. Kevin Kinsey Best Regards Yan, Yeqing ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
Alan Cox wrote:
On Wed, Oct 21, 2009 at 10:51 AM, Alexander Best <
alexbes...@math.uni-muenster.de> wrote:
although the mmap(2) manual states in section MAP_ANON:
"The offset argument is ignored."
this doesn't seem to be true. running
printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1,
0x12345678));
and
printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1, 0));
produces different outputs. i've attached a patch to solve the problem. the
patch is similar to the one proposed in this PR, but should apply cleanly
to
CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258
The standards for mmap(2) actually disallow values of "off" that are not a
multiple of the page size.
See http://www.opengroup.org/onlinepubs/95399/functions/mmap.html for
the following:
[EINVAL]The *addr* argument (if MAP_FIXED was specified) or *off* is not a
multiple of the page size as returned by
*sysconf*(),
or is considered invalid by the implementation.Both Solaris and Linux
enforce this restriction.
I'm not convinced that the ability to specify a value for "off" that is not
a multiple of the page size is a useful differentiating feature of FreeBSD
versus Solaris or Linux. Does anyone have a compelling argument (or use
case) to motivate us being different in this respect?
If you disallow values for "off" that are not a multiple of the page size,
then you are effectively ignoring "off" for MAP_ANON.
Regards,
Alan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
would it be such a bad idea as to round up the addr/off arguments to the
next page size? This was most likely the intention of the caller anyway.
Cheers,
Ben
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
