From yanefbsd at gmail.com Thu Jan 1 01:57:29 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jan 1 01:57:35 2009 Subject: Posting a bounty for the nVidia 64-bit wishlist Message-ID: <7d6fde3d0812311757t7b7f6830jb1351d550ceeacd9@mail.gmail.com> Hello Hackers, I have a request related to making FreeBSD to be a viable platform on AMD/Intel 64-bit architectures, such that functionality as requested by Chris (see: ). Please note that some of these things would also no doubt positively affect other groups (ATI, Intel, etc) when writing x*64 drivers for FreeBSD, so the list isn't just necessarily just applicable to nVidia. If someone could list a number of sys/... files that I could look at in order to get a brief grasp of what needs to be modified to support proper 64-bit architecture vmem, pmap, etc, that would be extremely helpful; I want to establish a reasonable timeframe and skill set required for the task set, so I can establish a reasonable monetary figure and/or resources to donate to the project. Also, if anyone else is interested in this pursuit (I know there are quite a few), feel free to contact me so we can coordinate our efforts and pool our resources to get these sets of loose ends finally tied up to have a more accessible FreeBSD based desktop. Thanks! -Garrett From agh at coolrhaug.com Thu Jan 1 05:28:06 2009 From: agh at coolrhaug.com (Alastair Hogge) Date: Thu Jan 1 05:28:12 2009 Subject: Posting a bounty for the nVidia 64-bit wishlist In-Reply-To: <7d6fde3d0812311757t7b7f6830jb1351d550ceeacd9@mail.gmail.com> References: <7d6fde3d0812311757t7b7f6830jb1351d550ceeacd9@mail.gmail.com> Message-ID: <200901011403.13435.agh@coolrhaug.com> On Thursday 01 January 2009 10:57:26 Garrett Cooper wrote: > Hello Hackers, > I have a request related to making FreeBSD to be a viable platform > on AMD/Intel 64-bit architectures, such that functionality as > requested by Chris (see: > ). Please note that > some of these things would also no doubt positively affect other > groups (ATI, Intel, etc) when writing x*64 drivers for FreeBSD, so the > list isn't just necessarily just applicable to nVidia. > If someone could list a number of sys/... files that I could look > at in order to get a brief grasp of what needs to be modified to > support proper 64-bit architecture vmem, pmap, etc, that would be > extremely helpful; I want to establish a reasonable timeframe and > skill set required for the task set, so I can establish a reasonable > monetary figure and/or resources to donate to the project. > Also, if anyone else is interested in this pursuit (I know there > are quite a few), feel free to contact me so we can coordinate our > efforts and pool our resources to get these sets of loose ends finally > tied up to have a more accessible FreeBSD based desktop. > Thanks! > -Garrett Are you aware of the efforts the PC-BSD project is making? http://trac.pcbsd.org/browser/freebsd-projects/nvidia-work Thanks -Alastair From rdivacky at freebsd.org Thu Jan 1 13:18:00 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu Jan 1 13:18:08 2009 Subject: Posting a bounty for the nVidia 64-bit wishlist In-Reply-To: <200901011403.13435.agh@coolrhaug.com> References: <7d6fde3d0812311757t7b7f6830jb1351d550ceeacd9@mail.gmail.com> <200901011403.13435.agh@coolrhaug.com> Message-ID: <20090101130232.GA26197@freebsd.org> On Thu, Jan 01, 2009 at 02:03:13PM +0900, Alastair Hogge wrote: > On Thursday 01 January 2009 10:57:26 Garrett Cooper wrote: > > Hello Hackers, > > I have a request related to making FreeBSD to be a viable platform > > on AMD/Intel 64-bit architectures, such that functionality as > > requested by Chris (see: > > ). Please note that > > some of these things would also no doubt positively affect other > > groups (ATI, Intel, etc) when writing x*64 drivers for FreeBSD, so the > > list isn't just necessarily just applicable to nVidia. > > If someone could list a number of sys/... files that I could look > > at in order to get a brief grasp of what needs to be modified to > > support proper 64-bit architecture vmem, pmap, etc, that would be > > extremely helpful; I want to establish a reasonable timeframe and > > skill set required for the task set, so I can establish a reasonable > > monetary figure and/or resources to donate to the project. > > Also, if anyone else is interested in this pursuit (I know there > > are quite a few), feel free to contact me so we can coordinate our > > efforts and pool our resources to get these sets of loose ends finally > > tied up to have a more accessible FreeBSD based desktop. > > Thanks! > > -Garrett > Are you aware of the efforts the PC-BSD project is making? > > http://trac.pcbsd.org/browser/freebsd-projects/nvidia-work wow, is anyone working on this being review/integrated? From patfbsd at davenulle.org Thu Jan 1 18:31:06 2009 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Thu Jan 1 18:31:14 2009 Subject: hifn(4) few small changes Message-ID: <20090101193102.2ebbbd53@baby-jane-lamaiziere-net.local> Hello and happy new year, I would like to suggest few changes in the hifn driver: diff between CURRENT: http://user.lamaiziere.net/patrick/hifn-010109/hifn-patch.txt hifn_attach() - Useless bzero of softc hifn_detach() - Return EBUSY if there is active session - Free the sessions - Use callout_drain() instead callout_stop() hifn_rng() - Remove the unused macro RANDOM_BITS hifn_newsession() - Add and use a rwlock to lock the sessions (sc->sc_sessions_lock). - Remove useless bzero of the sessions (use malloc with M_ZERO) - Use arc4rand() instead read_random() hifn_freesession() - Use a rwlock to lock the sessions hifn_process() - Use a rwlock to lock the sessions. In the current driver there is no lock to protect the sessions in hifn_process() but the sessions can be reallocated in hifn_newsession(). I think this is the cause of PR kern/91407 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/91407 hifn_callback() - Use a rwlock to lock the sessions. I've tested on a Soekris vpn 1411 (hifn 7955) with ipsec and openssl. Regards. (With big thanks to Mike Tancsa) From yanefbsd at gmail.com Thu Jan 1 21:44:17 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jan 1 21:44:24 2009 Subject: Posting a bounty for the nVidia 64-bit wishlist In-Reply-To: <20090101130232.GA26197@freebsd.org> References: <7d6fde3d0812311757t7b7f6830jb1351d550ceeacd9@mail.gmail.com> <200901011403.13435.agh@coolrhaug.com> <20090101130232.GA26197@freebsd.org> Message-ID: <03CD2B60-80A5-49D8-A504-DE2D68D643E7@gmail.com> On Jan 1, 2009, at 5:02, Roman Divacky wrote: > On Thu, Jan 01, 2009 at 02:03:13PM +0900, Alastair Hogge wrote: >> On Thursday 01 January 2009 10:57:26 Garrett Cooper wrote: >>> Hello Hackers, >>> I have a request related to making FreeBSD to be a viable >>> platform >>> on AMD/Intel 64-bit architectures, such that functionality as >>> requested by Chris (see: >>> ). Please note that >>> some of these things would also no doubt positively affect other >>> groups (ATI, Intel, etc) when writing x*64 drivers for FreeBSD, so >>> the >>> list isn't just necessarily just applicable to nVidia. >>> If someone could list a number of sys/... files that I could look >>> at in order to get a brief grasp of what needs to be modified to >>> support proper 64-bit architecture vmem, pmap, etc, that would be >>> extremely helpful; I want to establish a reasonable timeframe and >>> skill set required for the task set, so I can establish a reasonable >>> monetary figure and/or resources to donate to the project. >>> Also, if anyone else is interested in this pursuit (I know there >>> are quite a few), feel free to contact me so we can coordinate our >>> efforts and pool our resources to get these sets of loose ends >>> finally >>> tied up to have a more accessible FreeBSD based desktop. >>> Thanks! >>> -Garrett >> Are you aware of the efforts the PC-BSD project is making? >> >> http://trac.pcbsd.org/browser/freebsd-projects/nvidia-work > > wow, is anyone working on this being review/integrated? I wasn't aware of that either. I'd be more than happy to support that work if it makes it back into the main tree. Thanks! -Garrett From freebsd at bitfreak.org Fri Jan 2 02:11:54 2009 From: freebsd at bitfreak.org (Darren Pilgrim) Date: Fri Jan 2 02:12:01 2009 Subject: Is the FreeBSD clock UTC or TAI? Message-ID: <495D7421.1090208@bitfreak.org> This came up during discussion of leap seconds and why UTC and TAI are different. My question is, does FreeBSD's internal clock use UTC or TAI for timekeeping? That is, is wallclock calculated from an exact count of the number of seconds since epoch (TAI), then adjusted with a leap seconds table to match UTC, or does it internally use UTC and have code to deal with the ambiguous seconds that occur at each leap second? From shilp.kamal at yahoo.com Fri Jan 2 02:41:05 2009 From: shilp.kamal at yahoo.com (Kamlesh Patel) Date: Fri Jan 2 02:41:14 2009 Subject: FreeBSD kernel Debugging tools for Virtual Memory Module Message-ID: <387210.21917.qm@web45407.mail.sp1.yahoo.com> Hi Friends, Happy New Year, I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever i modify little code of vmpage.c file i need to build the whole kernel to check the modification and i even am not able to debug the kernel code. Could anyone please inform me kernel Debugging tools for FreeBSD OS? Kamlesh MS CS, CSUS From ertr1013 at student.uu.se Fri Jan 2 03:29:54 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Fri Jan 2 03:30:01 2009 Subject: Is the FreeBSD clock UTC or TAI? In-Reply-To: <495D7421.1090208@bitfreak.org> References: <495D7421.1090208@bitfreak.org> Message-ID: <20090102032949.GA33780@owl.midgard.homeip.net> On Thu, Jan 01, 2009 at 05:55:45PM -0800, Darren Pilgrim wrote: > This came up during discussion of leap seconds and why UTC and TAI are > different. My question is, does FreeBSD's internal clock use UTC or TAI > for timekeeping? That is, is wallclock calculated from an exact count > of the number of seconds since epoch (TAI), then adjusted with a leap > seconds table to match UTC, or does it internally use UTC and have code > to deal with the ambiguous seconds that occur at each leap second? I think the answer is no. Instead I believe FreeBSD follows the POSIX rules which mandates using UTC, while completely ignoring the concept of leap seconds. There was a long thread over on freebsd-current@ in early January 2006 titled "FreeBSD handles leapsecond correctly" that discussed this at length. (The general consensus seems to have been that leap seconds are evil and a PITA and essentially impossible to handle 'correctly' since various standards differ on how they should be handled. What to do about them is less clear however.) -- Erik Trulsson ertr1013@student.uu.se From lazaax.und at gmail.com Fri Jan 2 05:33:45 2009 From: lazaax.und at gmail.com (lazaax -) Date: Fri Jan 2 05:33:51 2009 Subject: imac g4 dont boot Message-ID: <4374ff010901012133i6cbe920du28cdf4c829f2990d@mail.gmail.com> hi, hackers, i need a help with a imac g4,i put the power cable and i push the power botton to turn on the mac and it makes a sound at start but the porblem is that dont boot, and keep like panic o somthing like that, i want to try install freebsd to this mac o restore the sistema mac that was installed, thanks people...... -- Leon Chavez Colima, Mexico "lazaax" From mehulc87 at gmail.com Fri Jan 2 03:28:20 2009 From: mehulc87 at gmail.com (Mehul Chadha) Date: Fri Jan 2 05:54:00 2009 Subject: FreeBSD kernel Debugging tools for Virtual Memory Module In-Reply-To: <387210.21917.qm@web45407.mail.sp1.yahoo.com> References: <387210.21917.qm@web45407.mail.sp1.yahoo.com> Message-ID: <251d650c0901011856n20dd48efuc6a5ef714320e1cf@mail.gmail.com> Hi kamlesh, Happy New Year. I am not aware of the debugging tools in freebsd available right now in the market. But I am working on a virtual mode freebsd project similar to what UML does in linux. This will help in executing the entire OS in the user space of real OS running on HW. This will be the best debugging tool to debug all the non architecture specific code in freebsd. The project is specially catered to problems similar to what you are facing. We are expecting the project to be completed in next 3 months. Regards, Mehul On Fri, Jan 2, 2009 at 7:57 AM, Kamlesh Patel wrote: > Hi Friends, Happy New Year, > > I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever > i modify little code of vmpage.c file i need to build the whole kernel to > check the modification and i even am not able to debug the kernel code. > > Could anyone please inform me kernel Debugging tools for FreeBSD OS? > > Kamlesh > MS CS, CSUS > > > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > From pranavpeshwe at gmail.com Fri Jan 2 07:40:38 2009 From: pranavpeshwe at gmail.com (Pranav Peshwe) Date: Fri Jan 2 07:40:45 2009 Subject: FreeBSD kernel Debugging tools for Virtual Memory Module In-Reply-To: <387210.21917.qm@web45407.mail.sp1.yahoo.com> References: <387210.21917.qm@web45407.mail.sp1.yahoo.com> Message-ID: On Fri, Jan 2, 2009 at 7:57 AM, Kamlesh Patel wrote: > Hi Friends, Happy New Year, > > I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever > i modify little code of vmpage.c file i need to build the whole kernel to > check the modification and i even am not able to debug the kernel code. > > Could anyone please inform me kernel Debugging tools for FreeBSD OS? > Hi, ddb and kgdb are two useful and often indispensable tools for kernel debugging on FBSD. ddb won't allow you source level debugging, kgdb will, but you'll need an extra machine. Dtrace from the Solaris world is being ported to FBSD, that too can be useful at times. You can find more information in the FBSD developers handbook here - http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html AFAIK, if you are modifying the kernel source directly there is no option but to recompile all the changed and dependent files. I do not know whether it works out of the box, but you can try using ccache to speed up the compilation. HTH. Best regards, Pranav http://pranavsbrain.peshwe.com From bakul at bitblocks.com Fri Jan 2 08:51:42 2009 From: bakul at bitblocks.com (Bakul Shah) Date: Fri Jan 2 08:51:48 2009 Subject: FreeBSD kernel Debugging tools for Virtual Memory Module In-Reply-To: Your message of "Fri, 02 Jan 2009 12:40:08 +0530." References: <387210.21917.qm@web45407.mail.sp1.yahoo.com> Message-ID: <20090102084609.8F5A35B05@mail.bitblocks.com> > ddb and kgdb are two useful and often indispensable tools for kernel > debugging on FBSD. ddb won't allow you source level debugging, kgdb will, > but you'll need an extra machine. If the code you are debugging doesn't depend on specific hardware, one option is to run FreeBSD (with the kernel being debugged) under qemu and run kgdb on the host FreeBSD. Something like In Window1 $ qemu -s freebsd-disk-img ... In Window2 $ cd $ kgdb kernel.debug (gdb) target remote localhost:1234 (gdb) detach Ending remote debugging. (gdb) q $ Note: I have not tried this recently but it should work. > AFAIK, if you are modifying the kernel source directly there is no option > but to recompile all the changed and dependent files. Well... there used to be a debugger called ups with a builtin C interpreter. It allowed you to add code at run time. This was quite handy when you wanted to temporarily patch things up and continue debugging or set conditional breakpoints or insert assertion verification code on the fly. The C interpreter is worth adding to gdb but I am not sure if any of ups code can be reused. See http://ups.sourceforge.net/ From dougb at dougbarton.us Fri Jan 2 08:08:56 2009 From: dougb at dougbarton.us (Doug Barton) Date: Fri Jan 2 12:23:28 2009 Subject: bsd.obj.mk does not set CANONICALOBJDIR correctly when TARGET_ARCH and MAKEOBJDIRPREFIX are set Message-ID: <495DC554.9030408@dougbarton.us> In working on cross-platform support for mergemaster I came across the following problem. I set MAKEOBJDIRPREFIX to be that of the temproot environment, which works fine when you do not specify a TARGET_ARCH. When you do specify TARGET_ARCH there is a conflict between src/Makefile.inc1 and share/mk/bsd.obj.mk. The former does this: .if ${MACHINE} == ${TARGET} && !defined(CROSS_BUILD_TESTING) OBJTREE= ${MAKEOBJDIRPREFIX} .else OBJTREE= ${MAKEOBJDIRPREFIX}/${TARGET} .endif however the latter does this: .if defined(MAKEOBJDIRPREFIX) CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR} .else CANONICALOBJDIR:=/usr/obj${.CURDIR} .endif When trying to install the stuff in src/etc/sendmail install(1) cannot find the file because it is built in /obj but it's looking for it in /obj/$target The simplest fix I found was to do the following in bsd.obj.mk: Index: bsd.obj.mk =================================================================== --- bsd.obj.mk (revision 186676) +++ bsd.obj.mk (working copy) @@ -43,7 +43,7 @@ .include .if defined(MAKEOBJDIRPREFIX) -CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR} +CANONICALOBJDIR:=${OBJTREE}${.CURDIR} .else CANONICALOBJDIR:=/usr/obj${.CURDIR} .endif However I would be happy with any solution that makes it work. It's trivial to test with 'mergemaster -i -D -A arm' Doug From eugen at kuzbass.ru Fri Jan 2 08:56:16 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Jan 2 12:23:41 2009 Subject: FreeBSD kernel Debugging tools for Virtual Memory Module In-Reply-To: <387210.21917.qm@web45407.mail.sp1.yahoo.com> References: <387210.21917.qm@web45407.mail.sp1.yahoo.com> Message-ID: <20090102082117.GA78125@svzserv.kemerovo.su> On Thu, Jan 01, 2009 at 06:27:44PM -0800, Kamlesh Patel wrote: > I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever i modify little code of vmpage.c file i need to build the whole kernel to check the modification and i even am not able to debug the kernel code. > > Could anyone please inform me kernel Debugging tools for FreeBSD OS? First, you need to recompile source you change for sure :-) But you have not rebuild all other files all the time. You need to add to your /etc/src.conf (or /etc/make.conf for 6.x and earlier): MODULES_WITH_WORLD=yes This will skip rebuilding of all modules during 'make buildkernel' but you MUST to copy all modules from /boot/kernel to /boot/modules (all files other than /boot/kernel/kernel*) if you do this. Otherwise, you'll lose modules and system may not boot due to missing vital modules like acpi.ko Then, if you do not change kernel config file, recompile your changes with command (only second time and then): cd /usr/src; make NO_KERNELDEPEND=yes NO_KERNELCLEAN=yes buildkernel So, your rebuild time changes drastically: no modules rebuild, no other sources rebuild other that you touched last time. It will relink previously compiled object code with your changes only, that's way much quicker. Reinstall kernel and reboot. Second, you should use some kind of virtual machine (like qemu from ports) to speedup your development cycle even more: install the system into virtual machine and you'll need not another box to debug the kernel and need not rebuild your development box. Test your changes with the system installed into VM and reboot it only. Use ddb or kgdb already noted here. Eugene Grosbein From unixmania at gmail.com Fri Jan 2 17:44:37 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Fri Jan 2 17:44:43 2009 Subject: imac g4 dont boot In-Reply-To: <4374ff010901012133i6cbe920du28cdf4c829f2990d@mail.gmail.com> References: <4374ff010901012133i6cbe920du28cdf4c829f2990d@mail.gmail.com> Message-ID: On Fri, Jan 2, 2009 at 3:33 AM, lazaax - wrote: > hi, hackers, > i need a help with a imac g4,i put the power cable > and i push the power botton to turn on the mac and it makes a sound at > start but the porblem is that dont boot, and keep like panic o > somthing like that, i want to try install freebsd to this mac o > restore the sistema mac that was installed, > > thanks people...... If you don't have FreeBSD installed on the machine then this is not a FreeBSD-related problem. At least not yet. :-) I suggest you to ask for help on at a Mac-specific forums, instead of asking at freebsd-hackers. The purpose of this list is discussing FreeBSD hacking and development. It is not for general user support. You will likely get better results asking at freebsd-questions. The purpose of each list is shown here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL -- cd /usr/ports/sysutils/life make clean From yanefbsd at gmail.com Fri Jan 2 19:06:22 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 2 19:06:28 2009 Subject: imac g4 dont boot In-Reply-To: References: <4374ff010901012133i6cbe920du28cdf4c829f2990d@mail.gmail.com> Message-ID: <6C034DD4-8B6B-4457-9184-42010BAE155C@gmail.com> On Jan 2, 2009, at 9:44, "Carlos A. M. dos Santos" wrote: > On Fri, Jan 2, 2009 at 3:33 AM, lazaax - wrote: >> hi, hackers, >> i need a help with a imac g4,i put the power cable >> and i push the power botton to turn on the mac and it makes a sound >> at >> start but the porblem is that dont boot, and keep like panic o >> somthing like that, i want to try install freebsd to this mac o >> restore the sistema mac that was installed, >> >> thanks people...... > > If you don't have FreeBSD installed on the machine then this is not a > FreeBSD-related problem. At least not yet. :-) > > I suggest you to ask for help on at a Mac-specific forums, instead of > asking at freebsd-hackers. The purpose of this list is discussing > FreeBSD hacking and development. It is not for general user support. > You will likely get better results asking at freebsd-questions. The > purpose of each list is shown here: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL > > -- > cd /usr/ports/sysutils/life > make clean Asking on ppc@freebsd.org would probably be more appropriate as it's a ppc based mac and the install directions vary. Cheers, -Garrett From rwatson at FreeBSD.org Sat Jan 3 11:17:43 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Jan 3 11:17:50 2009 Subject: TPM Device Driver - FreeBSD In-Reply-To: <20081201133333.GA6445@marinos.ceid.upatras.gr> References: <20081201133333.GA6445@marinos.ceid.upatras.gr> Message-ID: On Mon, 1 Dec 2008, Ilias Marinos wrote: > We are two undergraduate students studying computer engineering and > informatics at Patra's University, Greece. We are currently working on our > diploma thesis which is about developing a driver for the TPM (Trusted > Platform Module) for FreeBSD.We think that TPM can enhance security in > FreeBSD and could be a great addition to the TrustedBSD project. > > We are still in the begining of the project and since this is our first > effort in implementing a device driver we are trying to gather and read all > available documentation on the subject first. However, we were unable to > find a source of information related to how the BSD kernel and device > communication is implemented and we would greatly appreciate it if you could > point us one; either in form of a book or an article/tutorial. > > Last but not least, we'd like to make clear that we are oppossed to any > DRM-related use of this device, however we believe that the TPM can be used > in security or cryptographic applications. Hi Marinos, Mellos, I was wondering if you had managed to find the information you were looking for, and if you'd had any luck with putting together a TPM driver as yet? thanks, Robert N M Watson Computer Laboratory University of Cambridge > > Best Regards, > Marinos Ilias > Mellos Seraphim > > > -- > echo "Sysadmin know better bash than english." | sed s/min/mins/ \ > | sed 's/better bash/bash better/' > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From kes-kes at yandex.ru Sun Jan 4 14:27:16 2009 From: kes-kes at yandex.ru (KES) Date: Sun Jan 4 15:09:35 2009 Subject: tcpdump filter for out/in traffic Message-ID: <179479624.20090104160500@yandex.ru> ????????????, Questions. There will be very usefull to have options for tcpdump to monitor incomint or outgoing traffic regardless of src/dst IPs or ports or protocol For example: kes# tcpdump -n -i rl4 out EXPECTED: show traffic outgoing on rl4 ACTUAL: tcpdump: syntax error kes# tcpdump -n -i rl4 in EXPECTED: show traffic incoming on rl4 ACTUAL: tcpdump: syntax error -- ? ?????????, KES mailto:kes-kes@yandex.ru From eugen at kuzbass.ru Sun Jan 4 16:26:17 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Jan 4 17:01:50 2009 Subject: tcpdump filter for out/in traffic In-Reply-To: <179479624.20090104160500@yandex.ru> References: <179479624.20090104160500@yandex.ru> Message-ID: <20090104155638.GA76773@svzserv.kemerovo.su> On Sun, Jan 04, 2009 at 04:05:00PM +0200, KES wrote: > There will be very usefull to have options for tcpdump to monitor > incomint or outgoing traffic regardless of src/dst IPs or ports or protocol > > For example: > > kes# tcpdump -n -i rl4 out > EXPECTED: show traffic outgoing on rl4 > ACTUAL: tcpdump: syntax error > > kes# tcpdump -n -i rl4 in > EXPECTED: show traffic incoming on rl4 > ACTUAL: tcpdump: syntax error Hi! I use following trick for that: tcpdump -n -p -i rl4 ether src me-rl4 # for outgoing tcpdump -n -p -i tl4 not ether src me-rl4 # for incoming And add MAC-address of rl4 to /etc/ethers with name 'me-rl4' or just 'me' if you need not watch other interfaces this way. Eugene Grosbein From kitchetech at gmail.com Sun Jan 4 20:54:23 2009 From: kitchetech at gmail.com (matt donovan) Date: Sun Jan 4 20:54:29 2009 Subject: tcpdump filter for out/in traffic In-Reply-To: <20090104155638.GA76773@svzserv.kemerovo.su> References: <179479624.20090104160500@yandex.ru> <20090104155638.GA76773@svzserv.kemerovo.su> Message-ID: <28283d910901041223x7210db5lcf8df9ef5f1da56b@mail.gmail.com> On Sun, Jan 4, 2009 at 10:56 AM, Eugene Grosbein wrote: > On Sun, Jan 04, 2009 at 04:05:00PM +0200, KES wrote: > > > There will be very usefull to have options for tcpdump to monitor > > incomint or outgoing traffic regardless of src/dst IPs or ports or > protocol > > > > For example: > > > > kes# tcpdump -n -i rl4 out > > EXPECTED: show traffic outgoing on rl4 > > ACTUAL: tcpdump: syntax error > > > > kes# tcpdump -n -i rl4 in > > EXPECTED: show traffic incoming on rl4 > > ACTUAL: tcpdump: syntax error > > Hi! > > I use following trick for that: > > tcpdump -n -p -i rl4 ether src me-rl4 # for outgoing > tcpdump -n -p -i tl4 not ether src me-rl4 # for incoming > > And add MAC-address of rl4 to /etc/ethers with name 'me-rl4' > or just 'me' if you need not watch other interfaces this way. > > Eugene Grosbein > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > don't even need an option you just have to filter the traffic correctly using tcpdump which Eugene already point out From ru at freebsd.org Sun Jan 4 20:56:58 2009 From: ru at freebsd.org (Ruslan Ermilov) Date: Sun Jan 4 20:57:19 2009 Subject: bsd.obj.mk does not set CANONICALOBJDIR correctly when TARGET_ARCH and MAKEOBJDIRPREFIX are set In-Reply-To: <495DC554.9030408@dougbarton.us> References: <495DC554.9030408@dougbarton.us> Message-ID: <20090104203042.GA59395@edoofus.dev.vega.ru> Hi, On Thu, Jan 01, 2009 at 11:42:12PM -0800, Doug Barton wrote: > In working on cross-platform support for mergemaster I came across the > following problem. I set MAKEOBJDIRPREFIX to be that of the temproot > environment, which works fine when you do not specify a TARGET_ARCH. > When you do specify TARGET_ARCH there is a conflict between > src/Makefile.inc1 and share/mk/bsd.obj.mk. > The former does this: > > .if ${MACHINE} == ${TARGET} && !defined(CROSS_BUILD_TESTING) > OBJTREE= ${MAKEOBJDIRPREFIX} > .else > OBJTREE= ${MAKEOBJDIRPREFIX}/${TARGET} > .endif OBJTREE is a variable internal to Makefile.inc1; it's then assigned to a MAKEOBJDIRPREFIX environment variable which make(1) understands and uses to find the actual object directory. > however the latter does this: > > .if defined(MAKEOBJDIRPREFIX) > CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR} > .else > CANONICALOBJDIR:=/usr/obj${.CURDIR} > .endif CANONICALOBJDIR is what we (BSD, FreeBSD) choose to be a canonical object directory out of the list of possible object directories make(1) understands; the list is documented in the manpage: : 1. ${MAKEOBJDIRPREFIX}/`pwd` : 2. ${MAKEOBJDIR} : 3. obj.${MACHINE} : 4. obj : 5. /usr/obj/`pwd` That is, 1 and 5. There's no conflict between bsd.obj.mk and Makefile.inc1; the former creates a canonical object directory with the default "obj" target, ${MAKEOBJDIRPREFIX}/`pwd` or /usr/obj/`pwd`, and Makefile.inc1 only changes the value of MAKEOBJDIRPREFIX environment variable. bsd.obj.mk doesn't (and shouldn't) know anything about OBJTREE which is internal to Makefile.inc1. > When trying to install the stuff in src/etc/sendmail install(1) cannot > find the file because it is built in /obj but it's looking for it > in /obj/$target You should set MAKEOBJDIRPREFIX to the same value for "build" and "install" targets. If you set it only for the "install" target, you'll get what you describe; let's see... > The simplest fix I found was to do the following in bsd.obj.mk: > > Index: bsd.obj.mk > =================================================================== > --- bsd.obj.mk (revision 186676) > +++ bsd.obj.mk (working copy) > @@ -43,7 +43,7 @@ > .include > > .if defined(MAKEOBJDIRPREFIX) > -CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR} > +CANONICALOBJDIR:=${OBJTREE}${.CURDIR} > .else > CANONICALOBJDIR:=/usr/obj${.CURDIR} > .endif This change is plain wrong and shouldn't be committed. > However I would be happy with any solution that makes it work. It's > trivial to test with 'mergemaster -i -D -A arm' The problem is that Makefile.inc1 sets MAKEOBJDIRPREFIX for world- related targets specially, taking into account the value of ${TARGET}, to be able to use a single directory to build worlds for different architectures. mergemaster.sh uses "obj" and "all" targets which aren't cross-build aware (don't take ${TARGET} into account) to build etc/ bits, and then "distribution" target (which is cross-build aware) to install then. The effect of this is that you end up with "build" and "install" targets having different ideas of MAKEOBJDIRPREFIX. The fix is to use cross-aware versions of "obj" and "all" targets: %%% Index: mergemaster.sh =================================================================== RCS file: /home/ncvs/src/usr.sbin/mergemaster/mergemaster.sh,v retrieving revision 1.63 diff -u -p -r1.63 mergemaster.sh --- mergemaster.sh 2 Jan 2009 00:37:59 -0000 1.63 +++ mergemaster.sh 4 Jan 2009 20:18:40 -0000 @@ -588,8 +588,8 @@ case "${RERUN}" in ;; esac ${MM_MAKE} DESTDIR=${TEMPROOT} ${ARCHSTRING} distrib-dirs && - MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} obj SUBDIR_OVERRIDE=etc && - MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} all SUBDIR_OVERRIDE=etc && + MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} _obj SUBDIR_OVERRIDE=etc && + MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} everything SUBDIR_OVERRIDE=etc && MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} \ DESTDIR=${TEMPROOT} distribution;} || { echo ''; %%% Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From kris at FreeBSD.org Sun Jan 4 21:25:34 2009 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Jan 4 21:25:41 2009 Subject: lzo2 shows insane speed gap In-Reply-To: References: <20081230004747.GA55542@lorvorc.mips.inka.de> <20081230020524.2563a6ac@gluon> Message-ID: <4961294D.8080200@FreeBSD.org> Christian Weisgerber wrote: > Bruce Cran wrote: > >> I'm running 8.0-CURRENT amd64 here on a Turion64 X2 machine. Without >> malloc debugging (malloc.conf -> aj) 'make test' takes 25s; after >> removing malloc.conf thus turning on debugging, it takes over 10 >> minutes. > > Wow! That. Is. It. > > Toggling malloc debugging option J makes the "slow" machines "fast" > and vice versa. > >>> Athlon 64 X2 5200+ 2.6 GHz, FreeBSD 8.0-CURRENT amd64 ~60 min > > 19 seconds. > > I guess that falls under the "obvious" configuration differences > to check, but since it usually doesn't cause a significant slowdown > I completely forgot about it. Embarrassing. > > But still. Two orders of magnitude? That is a pathological case. > Probably it means that lzo2 is doing pathological numbers of mallocs. Kris From dougb at FreeBSD.org Sun Jan 4 21:36:59 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Jan 4 21:37:06 2009 Subject: bsd.obj.mk does not set CANONICALOBJDIR correctly when TARGET_ARCH and MAKEOBJDIRPREFIX are set Message-ID: <496125BA.1080902@FreeBSD.org> Ruslan Ermilov wrote: > mergemaster.sh uses "obj" and "all" targets which aren't cross-build > aware (don't take ${TARGET} into account) to build etc/ bits, and then > "distribution" target (which is cross-build aware) to install then. > The effect of this is that you end up with "build" and "install" targets > having different ideas of MAKEOBJDIRPREFIX. The fix is to use cross-aware > versions of "obj" and "all" targets: Thanks for responding. I was working on this the other day and discovered that the reason my suggested change "worked" was really an unintended side effect. Your suggestion works great, so I've committed it. Doug -- This .signature sanitized for your protection From doconnor at gsoft.com.au Sun Jan 4 23:36:27 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sun Jan 4 23:36:40 2009 Subject: tcpdump filter for out/in traffic In-Reply-To: <20090104155638.GA76773@svzserv.kemerovo.su> References: <179479624.20090104160500@yandex.ru> <20090104155638.GA76773@svzserv.kemerovo.su> Message-ID: <200901050954.02759.doconnor@gsoft.com.au> On Monday 05 January 2009 02:26:38 Eugene Grosbein wrote: > On Sun, Jan 04, 2009 at 04:05:00PM +0200, KES wrote: > > There will be very usefull to have options for tcpdump to monitor > > incomint or outgoing traffic regardless of src/dst IPs or ports or > > protocol > > > > For example: > > > > kes# tcpdump -n -i rl4 out > > EXPECTED: show traffic outgoing on rl4 > > ACTUAL: tcpdump: syntax error > > > > kes# tcpdump -n -i rl4 in > > EXPECTED: show traffic incoming on rl4 > > ACTUAL: tcpdump: syntax error > > Hi! > > I use following trick for that: > > tcpdump -n -p -i rl4 ether src me-rl4 # for outgoing > tcpdump -n -p -i tl4 not ether src me-rl4 # for incoming > > And add MAC-address of rl4 to /etc/ethers with name 'me-rl4' > or just 'me' if you need not watch other interfaces this way. I think it's more a question for the tcpdump maintainers. Also, in & out don't necessarily mean traffic from your MAC address or the inverse. eg if you are running a bridge then in & out will mean something different. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090104/1bf359bd/attachment.pgp From doconnor at gsoft.com.au Sun Jan 4 23:36:27 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sun Jan 4 23:36:40 2009 Subject: tcpdump filter for out/in traffic In-Reply-To: <20090104155638.GA76773@svzserv.kemerovo.su> References: <179479624.20090104160500@yandex.ru> <20090104155638.GA76773@svzserv.kemerovo.su> Message-ID: <200901050954.02759.doconnor@gsoft.com.au> On Monday 05 January 2009 02:26:38 Eugene Grosbein wrote: > On Sun, Jan 04, 2009 at 04:05:00PM +0200, KES wrote: > > There will be very usefull to have options for tcpdump to monitor > > incomint or outgoing traffic regardless of src/dst IPs or ports or > > protocol > > > > For example: > > > > kes# tcpdump -n -i rl4 out > > EXPECTED: show traffic outgoing on rl4 > > ACTUAL: tcpdump: syntax error > > > > kes# tcpdump -n -i rl4 in > > EXPECTED: show traffic incoming on rl4 > > ACTUAL: tcpdump: syntax error > > Hi! > > I use following trick for that: > > tcpdump -n -p -i rl4 ether src me-rl4 # for outgoing > tcpdump -n -p -i tl4 not ether src me-rl4 # for incoming > > And add MAC-address of rl4 to /etc/ethers with name 'me-rl4' > or just 'me' if you need not watch other interfaces this way. I think it's more a question for the tcpdump maintainers. Also, in & out don't necessarily mean traffic from your MAC address or the inverse. eg if you are running a bridge then in & out will mean something different. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090104/1bf359bd/attachment-0001.pgp From des at des.no Mon Jan 5 15:33:24 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jan 5 15:33:32 2009 Subject: FreeBSD kernel Debugging tools for Virtual Memory Module In-Reply-To: <20090102082117.GA78125@svzserv.kemerovo.su> (Eugene Grosbein's message of "Fri, 2 Jan 2009 15:21:17 +0700") References: <387210.21917.qm@web45407.mail.sp1.yahoo.com> <20090102082117.GA78125@svzserv.kemerovo.su> Message-ID: <86fxjxkbst.fsf@ds4.des.no> Eugene Grosbein writes: > First, you need to recompile source you change for sure :-) > But you have not rebuild all other files all the time. > You need to add to your /etc/src.conf (or /etc/make.conf for 6.x and earlier): > > MODULES_WITH_WORLD=yes > > This will skip rebuilding of all modules during 'make buildkernel' > but you MUST to copy all modules from /boot/kernel to /boot/modules > (all files other than /boot/kernel/kernel*) if you do this. What is the point, if you use NO_KERNELCLEAN as recommended below? The modules won't be rebuilt either unless something that affects them has changed. Running a new kernel with old modules is a great way to shoot yourself in the foot. If you absolutely want to skip modules, build your kernel with -DNO_MODULES, but install it normally, or use reinstallkernel instead of installkernel. The latter will overwrite your running kernel - but you should keep an unmodified kernel around anyway. You can boot entirely without modules if you include everything you need (including acpi) in your kernel config. > Then, if you do not change kernel config file, > recompile your changes with command (only second time and then): > > cd /usr/src; make NO_KERNELDEPEND=yes NO_KERNELCLEAN=yes buildkernel You should not use -DNO_KERNELDEPEND unless you know for sure that no #include directives have been added or removed and no kernel options have changed. It is safe to use -DNO_KERNELCLEAN, but not -DNO_KERNELDEPEND, even if your config file changed. > Second, you should use some kind of virtual machine (like qemu from > ports) to speedup your development cycle even more: install the system > into virtual machine and you'll need not another box to debug the > kernel and need not rebuild your development box. Test your changes > with the system installed into VM and reboot it only. Use ddb or kgdb > already noted here. The best solution by far is to use actual hardware and netboot from your development machine. It's easy to set up, and you don't lose context every time you reboot the test system. DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Mon Jan 5 15:37:27 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jan 5 15:37:34 2009 Subject: tcpdump filter for out/in traffic In-Reply-To: <200901050954.02759.doconnor@gsoft.com.au> (Daniel O'Connor's message of "Mon, 5 Jan 2009 09:54:00 +1030") References: <179479624.20090104160500@yandex.ru> <20090104155638.GA76773@svzserv.kemerovo.su> <200901050954.02759.doconnor@gsoft.com.au> Message-ID: <86bpulkbm1.fsf@ds4.des.no> "Daniel O'Connor" writes: > I think it's more a question for the tcpdump maintainers. tcpdump does not parse the filter expression, it just passes it along to libpcap. DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Mon Jan 5 15:55:09 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jan 5 15:55:16 2009 Subject: tcpdump filter for out/in traffic In-Reply-To: <200901050954.02759.doconnor@gsoft.com.au> (Daniel O'Connor's message of "Mon, 5 Jan 2009 09:54:00 +1030") References: <179479624.20090104160500@yandex.ru> <20090104155638.GA76773@svzserv.kemerovo.su> <200901050954.02759.doconnor@gsoft.com.au> Message-ID: <86bpulkbm1.fsf@ds4.des.no> "Daniel O'Connor" writes: > I think it's more a question for the tcpdump maintainers. tcpdump does not parse the filter expression, it just passes it along to libpcap. DES -- Dag-Erling Sm?rgrav - des@des.no From kes-kes at yandex.ru Mon Jan 5 16:53:29 2009 From: kes-kes at yandex.ru (KES) Date: Mon Jan 5 17:23:57 2009 Subject: tcpdump filter for out/in traffic In-Reply-To: <28283d910901041223x7210db5lcf8df9ef5f1da56b@mail.gmail.com> References: <179479624.20090104160500@yandex.ru> <20090104155638.GA76773@svzserv.kemerovo.su> <28283d910901041223x7210db5lcf8df9ef5f1da56b@mail.gmail.com> Message-ID: <1873024003.20090105185324@yandex.ru> Zdravstvujte, matt. Vy pisali 4 yanvarya 2009 g., 22:23:16: > On Sun, Jan 4, 2009 at 10:56 AM, Eugene Grosbein <[1]eugen@kuzbass.ru> wrote: On Sun, Jan 04, 2009 at 04:05:00PM +0200, KES wrote: > There will be very usefull to have options for tcpdump to monitor > incomint or outgoing traffic regardless of src/dst IPs or ports or protocol > > For example: > > kes# tcpdump -n -i rl4 out > EXPECTED: show traffic outgoing on rl4 > ACTUAL: tcpdump: syntax error > > kes# tcpdump -n -i rl4 in > EXPECTED: show traffic incoming on rl4 > ACTUAL: tcpdump: syntax error Hi! I use following trick for that: tcpdump -n -p -i rl4 ether src me-rl4 # for outgoing tcpdump -n -p -i tl4 not ether src me-rl4 # for incoming And add MAC-address of rl4 to /etc/ethers with name 'me-rl4' or just 'me' if you need not watch other interfaces this way. Eugene Grosbein _______________________________________________ [2]freebsd-hackers@freebsd.org mailing list [3]http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[4]freebsd-hackers-unsubscribe@freebsd.org" don't even need an option you just have to filter the traffic correctly using tcpdump which Eugene already point out >tcpdump -n -p -i rl4 ether src me-rl4 # for outgoing >tcpdump -n -p -i tl4 not ether src me-rl4 # for incoming That will not help I can not add ether because of this is PPPoE interface. I can not use 'me' because of I need to view going through traffic. It is not originated from 'me'. For example I have mpd5. I set up PPPoE connection with my ISP. (ng0) I have VPN server for LAN users it also mpd5 (ng1 ng2 ng3 .... etc) I do NAT with MPD. so when I do tcpdump -n -i ng0 I get: 18:52:11.781281 IP 192.168.5.11.2348 > 95.57.143.109.64350: P 1853247053:1853247057(4) ack 1650009540 win 17080 18:52:11.783777 IP 81.19.80.166.80 > 192.168.4.5.2839: . 11790:13150(1360) ack 0 win 65535 18:52:11.784218 IP 192.168.4.9.3298 > 82.144.223.61.80: . ack 21761 win 17680 18:52:11.787732 IP 81.19.80.166.80 > 192.168.4.5.2839: . 13150:14510(1360) ack 0 win 65535 18:52:11.789122 IP 192.168.5.15.2903 > 89.178.118.23.16562: . 13601:14961(1360) ack 0 win 16659 18:52:11.790065 IP 192.168.5.15.1386 > 78.106.215.39.18155: . ack 18981 win 17680 18:52:11.791181 IP 192.168.5.15.1311 > 79.174.64.193.80: . ack 5441 win 17680 18:52:11.791889 IP 81.19.80.166.80 > 192.168.4.5.2839: . 14510:15870(1360) ack 0 win 65535 18:52:11.792176 IP 192.168.5.15.4969 > 87.241.174.129.41954: . ack 18 win 16635 18:52:11.792200 IP 192.168.8.13.1616 > 217.20.174.228.80: . ack 1361 win65535 So 'in/out' ouptions will help. -- S uvazheniem, KES [5]mailto:kes-kes@yandex.ru References 1. mailto:eugen@kuzbass.ru 2. mailto:freebsd-hackers@freebsd.org 3. http://lists.freebsd.org/mailman/listinfo/freebsd-hackers 4. mailto:freebsd-hackers-unsubscribe@freebsd.org 5. mailto:kes-kes@yandex.ru From sheldon at sigsegv.ca Tue Jan 6 19:52:43 2009 From: sheldon at sigsegv.ca (Sheldon Givens) Date: Tue Jan 6 19:52:53 2009 Subject: Small change to 'ps' Message-ID: Hello everyone, It occurs to me that FreeBSD ps lacks the ability to disable header. This seems like a really obvious feature, and I may have simply missed it's existence (despite my relentlessly searching the man page) but here is a small patch that sets the flag 'n' to disable header output. Diff from CURRENT: http://sigsegv.ca/sheldon/ps.c-diff http://sigsegv.ca/sheldon/ps.1-diff Happy New Year, everyone! From dougb at FreeBSD.org Wed Jan 7 05:43:57 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jan 7 05:44:04 2009 Subject: Small change to 'ps' In-Reply-To: References: Message-ID: <49643F8B.1010904@FreeBSD.org> Sheldon Givens wrote: > Hello everyone, > > It occurs to me that FreeBSD ps lacks the ability to disable header. Why is this necessary? Doug -- This .signature sanitized for your protection From wsw1wsw2 at gmail.com Wed Jan 7 08:29:13 2009 From: wsw1wsw2 at gmail.com (Shaowei Wang (wsw)) Date: Wed Jan 7 08:29:20 2009 Subject: A patch of HPTIOP driver for 7.1-RELEASE Message-ID: <2e566b9e0901070005s630c2212k44a0e59a1bcf69aa@mail.gmail.com> Hi, guys hptiop driver in the 7.1 release has a little bug. Because this issue the Raid-manage GUI program which we provided can NOT work anymore. So we give the patch: Index: hptiop.h =================================================================== --- hptiop.h (revision 186851) +++ hptiop.h (working copy) @@ -260,7 +260,7 @@ unsigned long lpOutBuffer; /* output data buffer */ u_int32_t nOutBufferSize; /* size of output data buffer */ unsigned long lpBytesReturned; /* count of HPT_U8s returned */ -}; +}__attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) ==================================================================== -wsw /************************************************************************/ ???? hptiop????7.1?????????? ???????????????????????? ???????? Index: hptiop.h =================================================================== --- hptiop.h (revision 186851) +++ hptiop.h (working copy) @@ -260,7 +260,7 @@ unsigned long lpOutBuffer; /* output data buffer */ u_int32_t nOutBufferSize; /* size of output data buffer */ unsigned long lpBytesReturned; /* count of HPT_U8s returned */ -}; +}__attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) ==================================================================== -wsw From eitans at mellanox.co.il Wed Jan 7 11:57:39 2009 From: eitans at mellanox.co.il (Eitan Shefi) Date: Wed Jan 7 11:57:52 2009 Subject: "/var/log/messages" logs appear in the output of "sysctl -a" Message-ID: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> I am testing a NIC driver. I found it's logs and "/var/log/messages" logs in the output of "sysctl -a": I run "sysctl -a | less", and there I find: kern.devstat.version: 6 kern.devstat.generation: 137 kern.devstat.numdevs: 1 kern.kobj_methodcount: 143 kern.log_wakeups_per_second: 5 kern.msgbuf_clear: 0 kern.msgbuf: ound file system checks in 60 seconds. <118> mtnic0: FW version:2.6.0 mtnic0: Board ID: mtnic0: Using 1 tx rings for port:1 [4096] mtnic0: Using 4 rx rings for port:1 [1024] mtnic0: Using 1 tx rings for port:2 [4096] mtnic0: Using 4 rx rings for port:2 [1024] mtnic0: Initializing MSIX mtnic0: Enabling MSI-X (11 vectors) mtnic0: Board ID:MT_0BD0110004 mtnic0: [ITHREAD] mtnic0: Activating port:1 mtnic0: Ethernet address: 00:02:c9:03:35:20 mtnic0: Activating port:2 mtnic1: Ethernet address: 00:02:c9:03:35:21 mtnic0: [ITHREAD] mtnic0: [ITHREAD] mtnic0: mtnic0: mtnic0: mtnic0: Port 1 - link up mtnic0: [ITHREAD] mtnic0: [ITHREAD] mtnic0: [ITHREAD] Limiting icmp ping response from 300 to 200 packets/sec Limiting icmp ping response from 300 to 200 packets/sec Limiting icmp ping response from 1497 to 200 packets/sec Limiting icmp ping response from 1500 to 200 packets/sec Limiting icmp ping response from 1498 to 200 packets/sec Limiting icmp ping response from 1500 to 200 packets/sec Any idea how can such logs apear in "sysctl -a" ? Thanks, Eitan From gary.jennejohn at freenet.de Wed Jan 7 12:14:23 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Jan 7 12:14:32 2009 Subject: "/var/log/messages" logs appear in the output of "sysctl -a" In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> Message-ID: <20090107131417.609c602d@ernst.jennejohn.org> On Wed, 7 Jan 2009 13:30:20 +0200 "Eitan Shefi" wrote: > I am testing a NIC driver. > I found it's logs and "/var/log/messages" logs in the output of "sysctl > -a": > I run "sysctl -a | less", and there I find: > > kern.devstat.version: 6 > kern.devstat.generation: 137 > kern.devstat.numdevs: 1 > kern.kobj_methodcount: 143 > kern.log_wakeups_per_second: 5 > kern.msgbuf_clear: 0 > kern.msgbuf: ound file system checks in 60 seconds. > <118> > mtnic0: FW version:2.6.0 > mtnic0: Board ID: > mtnic0: Using 1 tx rings for port:1 [4096] > mtnic0: Using 4 rx rings for port:1 [1024] > mtnic0: Using 1 tx rings for port:2 [4096] > mtnic0: Using 4 rx rings for port:2 [1024] > mtnic0: Initializing MSIX > mtnic0: Enabling MSI-X (11 vectors) > mtnic0: Board ID:MT_0BD0110004 > mtnic0: [ITHREAD] > mtnic0: Activating port:1 > mtnic0: Ethernet address: 00:02:c9:03:35:20 > mtnic0: Activating port:2 > mtnic1: Ethernet address: 00:02:c9:03:35:21 > mtnic0: [ITHREAD] > mtnic0: [ITHREAD] > mtnic0: > mtnic0: > mtnic0: > mtnic0: Port 1 - link up > mtnic0: [ITHREAD] > mtnic0: [ITHREAD] > mtnic0: [ITHREAD] > Limiting icmp ping response from 300 to 200 packets/sec > Limiting icmp ping response from 300 to 200 packets/sec > Limiting icmp ping response from 1497 to 200 packets/sec > Limiting icmp ping response from 1500 to 200 packets/sec > Limiting icmp ping response from 1498 to 200 packets/sec > Limiting icmp ping response from 1500 to 200 packets/sec > > > Any idea how can such logs apear in "sysctl -a" ? > If you were viewing this as root on the console then you were simply seeing kernel output interleaved with the output from sysctl. --- Gary Jennejohn From maxim at macomnet.ru Wed Jan 7 12:21:31 2009 From: maxim at macomnet.ru (Maxim Konovalov) Date: Wed Jan 7 12:21:43 2009 Subject: "/var/log/messages" logs appear in the output of "sysctl -a" In-Reply-To: <20090107131417.609c602d@ernst.jennejohn.org> References: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> <20090107131417.609c602d@ernst.jennejohn.org> Message-ID: <20090107152107.F7116@mp2.macomnet.net> On Wed, 7 Jan 2009, 13:14+0100, Gary Jennejohn wrote: > On Wed, 7 Jan 2009 13:30:20 +0200 > "Eitan Shefi" wrote: > > > I am testing a NIC driver. > > I found it's logs and "/var/log/messages" logs in the output of "sysctl > > -a": > > I run "sysctl -a | less", and there I find: > > > > kern.devstat.version: 6 > > kern.devstat.generation: 137 > > kern.devstat.numdevs: 1 > > kern.kobj_methodcount: 143 > > kern.log_wakeups_per_second: 5 > > kern.msgbuf_clear: 0 > > kern.msgbuf: ound file system checks in 60 seconds. > > <118> > > mtnic0: FW version:2.6.0 > > mtnic0: Board ID: > > mtnic0: Using 1 tx rings for port:1 [4096] > > mtnic0: Using 4 rx rings for port:1 [1024] > > mtnic0: Using 1 tx rings for port:2 [4096] > > mtnic0: Using 4 rx rings for port:2 [1024] > > mtnic0: Initializing MSIX > > mtnic0: Enabling MSI-X (11 vectors) > > mtnic0: Board ID:MT_0BD0110004 > > mtnic0: [ITHREAD] > > mtnic0: Activating port:1 > > mtnic0: Ethernet address: 00:02:c9:03:35:20 > > mtnic0: Activating port:2 > > mtnic1: Ethernet address: 00:02:c9:03:35:21 > > mtnic0: [ITHREAD] > > mtnic0: [ITHREAD] > > mtnic0: > > mtnic0: > > mtnic0: > > mtnic0: Port 1 - link up > > mtnic0: [ITHREAD] > > mtnic0: [ITHREAD] > > mtnic0: [ITHREAD] > > Limiting icmp ping response from 300 to 200 packets/sec > > Limiting icmp ping response from 300 to 200 packets/sec > > Limiting icmp ping response from 1497 to 200 packets/sec > > Limiting icmp ping response from 1500 to 200 packets/sec > > Limiting icmp ping response from 1498 to 200 packets/sec > > Limiting icmp ping response from 1500 to 200 packets/sec > > > > > > Any idea how can such logs apear in "sysctl -a" ? > > > > If you were viewing this as root on the console then you were simply > seeing kernel output interleaved with the output from sysctl. > This is just an output from sysctl kern.msgbuf. -- Maxim Konovalov From mjguzik at gmail.com Wed Jan 7 12:25:05 2009 From: mjguzik at gmail.com (Mateusz Guzik) Date: Wed Jan 7 12:25:37 2009 Subject: "/var/log/messages" logs appear in the output of "sysctl -a" In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> Message-ID: <20090107122503.GA12470@skucha> On Wed, Jan 07, 2009 at 01:30:20PM +0200, Eitan Shefi wrote: > I am testing a NIC driver. > I found it's logs and "/var/log/messages" logs in the output of "sysctl > -a": > I run "sysctl -a | less", and there I find: > [..] > kern.msgbuf: ound file system checks in 60 seconds. > <118> > mtnic0: FW version:2.6.0 > mtnic0: Board ID: > mtnic0: Using 1 tx rings for port:1 [4096] > mtnic0: Using 4 rx rings for port:1 [1024] > mtnic0: Using 1 tx rings for port:2 [4096] > mtnic0: Using 4 rx rings for port:2 [1024] [..] > > Any idea how can such logs apear in "sysctl -a" ? > kern.msgbuf dumps so called 'message buf' containing messages printed by the kernel (for example by a NIC driver). It's accessible also via /dev/klog and syslogd uses it as a source for /var/log/messages. -- Mateusz Guzik From remko at elvandar.org Wed Jan 7 12:30:03 2009 From: remko at elvandar.org (Remko Lodder) Date: Wed Jan 7 12:30:10 2009 Subject: "/var/log/messages" logs appear in the output of "sysctl -a" In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> Message-ID: <013A849A-9F3C-4414-B022-61A87AADB478@elvandar.org> You are looking at the kernel message buffer with 'sysctl -a'. (kern.msgbuf). Nothing wrong with that. //Remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From uspoerlein at gmail.com Wed Jan 7 13:06:44 2009 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Wed Jan 7 13:06:51 2009 Subject: Small change to 'ps' In-Reply-To: References: Message-ID: <20090107125759.GA1462@roadrunner.spoerlein.net> On Tue, 06.01.2009 at 11:52:39 -0800, Sheldon Givens wrote: > Hello everyone, > > It occurs to me that FreeBSD ps lacks the ability to disable header. This > seems like a really obvious feature, and I may have simply missed it's > existence (despite my relentlessly searching the man page) but here is a > small patch that sets the flag 'n' to disable header output. You've missed it, probably because it is non-obvious: % ps -p 1 -o pid,cpu PID CPU 1 0 % ps -p 1 -o pid= -o cpu= 1 0 % Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From scf at FreeBSD.org Wed Jan 7 15:24:44 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Wed Jan 7 15:24:51 2009 Subject: Small change to 'ps' In-Reply-To: <20090107125759.GA1462@roadrunner.spoerlein.net> References: <20090107125759.GA1462@roadrunner.spoerlein.net> Message-ID: On Wed, 7 Jan 2009, Ulrich Spoerlein wrote: > On Tue, 06.01.2009 at 11:52:39 -0800, Sheldon Givens wrote: >> Hello everyone, >> >> It occurs to me that FreeBSD ps lacks the ability to disable header. >> This seems like a really obvious feature, and I may have simply >> missed it's existence (despite my relentlessly searching the man >> page) but here is a small patch that sets the flag 'n' to disable >> header output. > > You've missed it, probably because it is non-obvious: > > % ps -p 1 -o pid,cpu > PID CPU > 1 0 > % ps -p 1 -o pid= -o cpu= > 1 0 > % Another way: ps | tail +2 Sean -- scf@FreeBSD.org From uspoerlein at gmail.com Wed Jan 7 15:49:00 2009 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Wed Jan 7 15:49:07 2009 Subject: Small change to 'ps' In-Reply-To: References: <20090107125759.GA1462@roadrunner.spoerlein.net> Message-ID: <20090107154854.GC1462@roadrunner.spoerlein.net> On Wed, 07.01.2009 at 08:54:41 -0600, Sean C. Farley wrote: > On Wed, 7 Jan 2009, Ulrich Spoerlein wrote: > > > On Tue, 06.01.2009 at 11:52:39 -0800, Sheldon Givens wrote: > >> Hello everyone, > >> > >> It occurs to me that FreeBSD ps lacks the ability to disable header. > >> This seems like a really obvious feature, and I may have simply > >> missed it's existence (despite my relentlessly searching the man > >> page) but here is a small patch that sets the flag 'n' to disable > >> header output. > > > > You've missed it, probably because it is non-obvious: > > > > % ps -p 1 -o pid,cpu > > PID CPU > > 1 0 > > % ps -p 1 -o pid= -o cpu= > > 1 0 > > % > > Another way: > ps | tail +2 I'm not sure about the portability of tail +N, I seem to remember that AIX doesn't support it. Therefore I'd rather use % ps | sed 1d which is way more portable. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From vladimirt at partygaming.com Wed Jan 7 17:10:03 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Wed Jan 7 17:10:10 2009 Subject: /dev/dsp* & /dev/audio* devices not present Message-ID: <1231347151.49524.19.camel@daemon2.partygaming.local> Hi Hackers, i have a workstation equipped with "Intel 82801G High Definition Audio Controller". The workstation is running FreeBSD 7.0 Release i386. I built a custom kernel and compiled the driver into it, using the following lines in the kernel configuration file: device sound device snd_hda The driver seems to recognize the controller: $ dmesg | grep pcm pcm0: mem 0xe04c0000-0xe04c3fff irq 21 at device 27.0 on pci0 pcm0: [ITHREAD] pcm0: pcm0: This is also confirmed here: $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) Installed devices: pcm0: at memory 0xe04c0000 irq 21 [20071129_0050] [MPSAFE] (1p:1v/1r:1v channels duplex default) Now the problem ... The strange thing is all audio related devices are missing in /dev $ ls -l /dev/audio* /dev/dsp* ls: /dev/audio*: No such file or directory ls: /dev/dsp*: No such file or directory Respectively i have no working sound support :( Could someone help we with this issue? Any ideas are appreciated! Thanks in advance! Vladimir This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From sheldon at sigsegv.ca Wed Jan 7 17:27:25 2009 From: sheldon at sigsegv.ca (Sheldon Givens) Date: Wed Jan 7 17:27:32 2009 Subject: Small change to 'ps' In-Reply-To: <20090107154854.GC1462@roadrunner.spoerlein.net> References: <20090107125759.GA1462@roadrunner.spoerlein.net> <20090107154854.GC1462@roadrunner.spoerlein.net> Message-ID: On Wed, Jan 7, 2009 at 7:48 AM, Ulrich Spoerlein wrote: > On Wed, 07.01.2009 at 08:54:41 -0600, Sean C. Farley wrote: > > On Wed, 7 Jan 2009, Ulrich Spoerlein wrote: > > > > > On Tue, 06.01.2009 at 11:52:39 -0800, Sheldon Givens wrote: > > >> Hello everyone, > > >> > > >> It occurs to me that FreeBSD ps lacks the ability to disable header. > > >> This seems like a really obvious feature, and I may have simply > > >> missed it's existence (despite my relentlessly searching the man > > >> page) but here is a small patch that sets the flag 'n' to disable > > >> header output. > > > > > > You've missed it, probably because it is non-obvious: > > > > > > % ps -p 1 -o pid,cpu > > > PID CPU > > > 1 0 > > > % ps -p 1 -o pid= -o cpu= > > > 1 0 > > > % > > > > Another way: > > ps | tail +2 > > I'm not sure about the portability of tail +N, I seem to remember that > AIX doesn't support it. Therefore I'd rather use > > % ps | sed 1d > > which is way more portable. > > Cheers, > Ulrich Spoerlein > -- > It is better to remain silent and be thought a fool, > than to speak, and remove all doubt. > Hello everybody, Ulrich: I appreciate your solution, but it ends up being a pretty ridiculous command when you start desiring 6 or 7 fields. Sean: Ulrich is right in saying that tail +val is unreliable when coding for portability. And I guess I just feel like running a second command to do what should be possible to do with the first command (and is, on many platforms. ps --no-headers on linux for example) is a problem and presents opportunity for continued refinement of the utility. Sheldon From guru at unixarea.de Wed Jan 7 18:15:37 2009 From: guru at unixarea.de (Matthias Apitz) Date: Wed Jan 7 18:15:45 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <1231347151.49524.19.camel@daemon2.partygaming.local> References: <1231347151.49524.19.camel@daemon2.partygaming.local> Message-ID: <20090107181032.GA2808@rebelion.Sisis.de> El d?a Wednesday, January 07, 2009 a las 06:52:31PM +0200, Vladimir Terziev escribi?: ... > device sound > device snd_hda > > > The driver seems to recognize the controller: > > $ dmesg | grep pcm > > pcm0: mem > 0xe04c0000-0xe04c3fff irq 21 at device 27.0 on pci0 > pcm0: [ITHREAD] > pcm0: > pcm0: > > > This is also confirmed here: > > $ cat /dev/sndstat > FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) > Installed devices: > pcm0: at memory > 0xe04c0000 irq 21 [20071129_0050] [MPSAFE] (1p:1v/1r:1v channels duplex > default) all fine until here; > > Now the problem ... > The strange thing is all audio related devices are missing in /dev > > $ ls -l /dev/audio* /dev/dsp* > ls: /dev/audio*: No such file or directory > ls: /dev/dsp*: No such file or directory fine too; you will not see /dev/dsp* with ls(1), just open the device /dev/dsp with some application and it will appear; > Respectively i have no working sound support :( what you mean exactly with 'i have no working sound support'? try changing the values with the mixer(1) command if no sound is coming out from apps; matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen >From: -40 % die Neujahrsaktion From kientzle at freebsd.org Wed Jan 7 18:33:15 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Wed Jan 7 18:33:21 2009 Subject: lzo2 shows insane speed gap In-Reply-To: <4961294D.8080200@FreeBSD.org> References: <20081230004747.GA55542@lorvorc.mips.inka.de> <20081230020524.2563a6ac@gluon> <4961294D.8080200@FreeBSD.org> Message-ID: <4964F565.2080201@freebsd.org> Kris Kennaway wrote: > Christian Weisgerber wrote: >> Bruce Cran wrote: >> >>> I'm running 8.0-CURRENT amd64 here on a Turion64 X2 machine. Without >>> malloc debugging (malloc.conf -> aj) 'make test' takes 25s; after >>> removing malloc.conf thus turning on debugging, it takes over 10 >>> minutes. >> ... >> >> But still. Two orders of magnitude? That is a pathological case. > > Probably it means that lzo2 is doing pathological numbers of mallocs. Rather, the lzo2 test suite. Test suites do tend to hammer malloc() pretty hard. I see similar variations for the libarchive test suite with malloc debugging. Tim From xistence at 0x58.com Wed Jan 7 18:58:49 2009 From: xistence at 0x58.com (Bert JW Regeer) Date: Wed Jan 7 18:58:56 2009 Subject: Small change to 'ps' In-Reply-To: References: <20090107125759.GA1462@roadrunner.spoerlein.net> <20090107154854.GC1462@roadrunner.spoerlein.net> Message-ID: <5E170DCF-F139-4CBC-A343-EA91CE3BD458@0x58.com> On Jan 7, 2009, at 10:27 , Sheldon Givens wrote: > On Wed, Jan 7, 2009 at 7:48 AM, Ulrich Spoerlein > wrote: > >> On Wed, 07.01.2009 at 08:54:41 -0600, Sean C. Farley wrote: >>> On Wed, 7 Jan 2009, Ulrich Spoerlein wrote: >>> >>>> On Tue, 06.01.2009 at 11:52:39 -0800, Sheldon Givens wrote: >>>>> Hello everyone, >>>>> >>>>> It occurs to me that FreeBSD ps lacks the ability to disable >>>>> header. >>>>> This seems like a really obvious feature, and I may have simply >>>>> missed it's existence (despite my relentlessly searching the man >>>>> page) but here is a small patch that sets the flag 'n' to disable >>>>> header output. >>>> >>>> You've missed it, probably because it is non-obvious: >>>> >>>> % ps -p 1 -o pid,cpu >>>> PID CPU >>>> 1 0 >>>> % ps -p 1 -o pid= -o cpu= >>>> 1 0 >>>> % >>> >>> Another way: >>> ps | tail +2 >> >> I'm not sure about the portability of tail +N, I seem to remember >> that >> AIX doesn't support it. Therefore I'd rather use >> >> % ps | sed 1d >> >> which is way more portable. The three solutions above all work on my OpenSolaris machine (other than cpu=, since the field is named pcpu). I don't currently have access to HP-UX or AIX to test which do and do not work. >> >> >> Cheers, >> Ulrich Spoerlein >> -- >> It is better to remain silent and be thought a fool, >> than to speak, and remove all doubt. >> > > Hello everybody, > > Ulrich: I appreciate your solution, but it ends up being a pretty > ridiculous > command when you start desiring 6 or 7 fields. Yes, which is why the sed/tail will do exactly what you want. UNIX was built on the fact that small tools together will work together to do something larger, no need to move all of the functionality into one tool, that creates maintenance nightmares and just complicates otherwise simple code. > > > > Sean: Ulrich is right in saying that tail +val is unreliable when > coding for > portability. > > > And I guess I just feel like running a second command to do what > should be > possible to do with the first command (and is, on many platforms. ps > --no-headers on linux for example) is a problem and presents > opportunity for > continued refinement of the utility. What other platforms besides Linux distributions? Just because they exist by the hundreds does not mean they are different platforms. xistence@Keyhole.network.lan:~$ ps -AflZ --no-headers ps: illegal option -- no-headers usage: ps [ -aAdefHlcjLPyZ ] [ -o format ] [ -t termlist ] [ -u userlist ] [ -U userlist ] [ -G grouplist ] [ -p proclist ] [ -g pgrplist ] [ -s sidlist ] [ -z zonelist ] [-h lgrplist] 'format' is one or more of: user ruser group rgroup uid ruid gid rgid pid ppid pgid sid taskid ctid pri opri pcpu pmem vsz rss osz nice class time etime stime zone zoneid f s c lwp nlwp psr tty addr wchan fname comm args projid project pset lgrp xistence@Keyhole.network.lan:~$ uname -a SunOS Keyhole.network.lan 5.11 snv_101b i86pc i386 i86pc Solaris I also read the entire man page for ps that is included and could not find a single way to not include a header by using a simple flag, in the man page they list the -o format as the only way to remove the header. HP-UX man page does not include an option either, besides the aforementioned -o format option: http://docs.hp.com/en/B2355-90690/ps.1.html Same goes for IBM's AIX system: http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds4/ps.htm Just because Linux has it does not mean it is an improvement that should be imported. I think it is rather dumb idea really. What if in the future we add a new field to the output of ps to give more information (on Solaris for example, the -Z function lists what Zone the command is running in (global, or non-global)), this changes the amounts of fields that are listed. Now lets say some shell script that was written a few years ago requires a certain option to be located in field 7, and now that is moved over to field 8 it could cause all kinds of issues, instead if the command is written out with -o pid=, it is static and it won't change even if a new field is introduced to ps, thereby decreasing future issues, and increasing portability since you can select only the fields you require, making it more portable (if using standardised fields) because now the field will always be in the same place, no matter the platform. > > > Sheldon Linuxisms that are bad should not be imported into FreeBSD. There is a valid and documented way to suppress the header information using ps, use it. If you are using this in a script of some sort, writing it out once will save you a lot of headache and trouble later. Bert JW Regeer From vladimirt at partygaming.com Thu Jan 8 07:07:11 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Thu Jan 8 07:07:19 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <20090107181032.GA2808@rebelion.Sisis.de> References: <20090107181032.GA2808@rebelion.Sisis.de> Message-ID: <1231398405.2842.1.camel@daemon2.partygaming.local> Hi Matthias, i configured Ekiga and during the configuration process it didn't find any Audio device, so i think /dev/dsp* devices must be present, isn't it ? Regards, Vladimir On Wed, 2009-01-07 at 20:10 +0200, Matthias Apitz wrote: > El d?a Wednesday, January 07, 2009 a las 06:52:31PM +0200, Vladimir > Terziev escribi?: > > ... > > > device sound > > device snd_hda > > > > > > The driver seems to recognize the controller: > > > > $ dmesg | grep pcm > > > > pcm0: mem > > 0xe04c0000-0xe04c3fff irq 21 at device 27.0 on pci0 > > pcm0: [ITHREAD] > > pcm0: > > pcm0: > > > > > > This is also confirmed here: > > > > $ cat /dev/sndstat > > FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) > > Installed devices: > > pcm0: at memory > > 0xe04c0000 irq 21 [20071129_0050] [MPSAFE] (1p:1v/1r:1v channels > duplex > > default) > > all fine until here; > > > > > Now the problem ... > > The strange thing is all audio related devices are missing in /dev > > > > $ ls -l /dev/audio* /dev/dsp* > > ls: /dev/audio*: No such file or directory > > ls: /dev/dsp*: No such file or directory > > fine too; you will not see /dev/dsp* with ls(1), just open the device > /dev/dsp with some application and it will appear; > > > Respectively i have no working sound support :( > > what you mean exactly with 'i have no working sound support'? > try changing the values with the mixer(1) command if no sound is > coming > out from apps; > > matthias > -- > Matthias Apitz > Manager Technical Support - OCLC GmbH > Gruenwalder Weg 28g - 82041 Oberhaching - Germany > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.oclc.org/ > http://www.UnixArea.de/ > b http://gurucubano.blogspot.com/ > > SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen > >From: -40 % die Neujahrsaktion > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From uspoerlein at gmail.com Thu Jan 8 08:16:10 2009 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Thu Jan 8 08:16:17 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <1231398405.2842.1.camel@daemon2.partygaming.local> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> Message-ID: <20090108080708.GE1462@roadrunner.spoerlein.net> On Thu, 08.01.2009 at 09:06:45 +0200, Vladimir Terziev wrote: > Hi Matthias, > > i configured Ekiga and during the configuration process it didn't find > any Audio device, so i think /dev/dsp* devices must be present, isn't > it ? Please run % cat /dev/sndstat % ls -l /dev/dsp0 /dev/dsp0.0 The reason you are not seeing them with 'ls /dev/dsp*' is because devfs is creating the nodes when they are open(2)'ed. Using shell globbing will search the output of readdir(2) for matches to dsp* where devfs has no way of dynamically creating nodes (which ones should it create anyway?) This is a FAQ really. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From vladimirt at partygaming.com Thu Jan 8 08:29:13 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Thu Jan 8 08:29:20 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <20090108080708.GE1462@roadrunner.spoerlein.net> References: <20090108080708.GE1462@roadrunner.spoerlein.net> Message-ID: <1231403337.2842.7.camel@daemon2.partygaming.local> Thank you very much Ulrich! After running "ls -l /dev/dsp0 /dev/dsp0.0" the devices are present and Ekiga has found them. The reasonable question is why Ekiga was not able to discover them without the hack you suggested. Regards, Vladimir On Thu, 2009-01-08 at 10:07 +0200, Ulrich Spoerlein wrote: > On Thu, 08.01.2009 at 09:06:45 +0200, Vladimir Terziev wrote: > > Hi Matthias, > > > > i configured Ekiga and during the configuration process it didn't > find > > any Audio device, so i think /dev/dsp* devices must be present, > isn't > > it ? > > Please run > % cat /dev/sndstat > % ls -l /dev/dsp0 /dev/dsp0.0 > > The reason you are not seeing them with 'ls /dev/dsp*' is because > devfs > is creating the nodes when they are open(2)'ed. Using shell globbing > will > search the output of readdir(2) for matches to dsp* where devfs has no > way of dynamically creating nodes (which ones should it create > anyway?) > > This is a FAQ really. > > Cheers, > Ulrich Spoerlein > -- > It is better to remain silent and be thought a fool, > than to speak, and remove all doubt. > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From vladimirt at partygaming.com Thu Jan 8 08:42:23 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Thu Jan 8 08:42:30 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <20090108083106.GA1717@rebelion.Sisis.de> References: <20090108083106.GA1717@rebelion.Sisis.de> Message-ID: <1231404134.2842.10.camel@daemon2.partygaming.local> Hi Matthias, the version of Ekiga i'm exploring is built from ports and it's ekiga-2.0.11_4 . Regards, Vladimir On Thu, 2009-01-08 at 10:31 +0200, Matthias Apitz wrote: > El d?a Thursday, January 08, 2009 a las 09:06:45AM +0200, Vladimir > Terziev escribi?: > > > Hi Matthias, > > > > i configured Ekiga and during the configuration process it didn't > find > > any Audio device, so i think /dev/dsp* devices must be present, > isn't > > it ? > > > > Regards, > > > > Vladimir > > Which version of Ekiga you are using? In the past I've send patches to > the Ekiga maintainer to make /dev/dsp working. I don't know if they > made > it, for example, into the version the 7.0 port is using. > > matthias > > -- > Matthias Apitz > Manager Technical Support - OCLC GmbH > Gruenwalder Weg 28g - 82041 Oberhaching - Germany > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.oclc.org/ > http://www.UnixArea.de/ > b http://gurucubano.blogspot.com/ > > SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen > >From: -40 % die Neujahrsaktion > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From guru at unixarea.de Thu Jan 8 08:43:12 2009 From: guru at unixarea.de (Matthias Apitz) Date: Thu Jan 8 08:43:19 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <1231398405.2842.1.camel@daemon2.partygaming.local> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> Message-ID: <20090108083106.GA1717@rebelion.Sisis.de> El d?a Thursday, January 08, 2009 a las 09:06:45AM +0200, Vladimir Terziev escribi?: > Hi Matthias, > > i configured Ekiga and during the configuration process it didn't find > any Audio device, so i think /dev/dsp* devices must be present, isn't > it ? > > Regards, > > Vladimir Which version of Ekiga you are using? In the past I've send patches to the Ekiga maintainer to make /dev/dsp working. I don't know if they made it, for example, into the version the 7.0 port is using. matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen >From: -40 % die Neujahrsaktion From aksoy.for.research at gmail.com Thu Jan 8 09:44:00 2009 From: aksoy.for.research at gmail.com (=?ISO-8859-1?Q?Mehmet_Ali_Aksoy_T=DCYS=DCZ?=) Date: Thu Jan 8 09:44:07 2009 Subject: Threads and SMP kernel scheduling Message-ID: <14ded62c0901080123u7268055epb3e17d84aa757051@mail.gmail.com> Hi all, After I had a bit googling I got confused. My questions are simple and they are as follows : 1-) "Are pthreads (or threads in general) of one process scheduled to different cores on multi-core systems running Linux or BSD?" 2-) What if there are multiple processes which have multiple threads? Does it change the answer of (1)? I found some answers but they are not sharp. Somebody says "can be scheduled" but "can be" is not a precise answer (in my opinion.) Thanks everybody in advance. Mehmet From ulf.lilleengen at gmail.com Thu Jan 8 14:08:12 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Thu Jan 8 14:08:18 2009 Subject: Threads and SMP kernel scheduling In-Reply-To: <14ded62c0901080123u7268055epb3e17d84aa757051@mail.gmail.com> References: <14ded62c0901080123u7268055epb3e17d84aa757051@mail.gmail.com> Message-ID: <20090108150807.GA1264@carrot.pvv.ntnu.no> On Thu, Jan 08, 2009 at 04:23:08AM -0500, Mehmet Ali Aksoy T?YS?Z wrote: > Hi all, > > After I had a bit googling I got confused. > > My questions are simple and they are as follows : > > 1-) "Are pthreads (or threads in general) of one process scheduled to > different cores on multi-core systems running Linux or BSD?" > The standard threading library in FreeBSD will use a 1:1 mapping between userland threads(pthreads) and kernel threads. This means that each thread may run on a different core than other threads. > 2-) What if there are multiple processes which have multiple threads? Does > it change the answer of (1)? No, the same mapping applies. Although threads of one process may preferably run on the same core, each thread of a process may run on any of the cores available. > > I found some answers but they are not sharp. Somebody says "can be > scheduled" but "can be" is not a precise answer (in my opinion.) Well, it means that there are more factors deciding where a thread is put. If you look at a factor such as affinity, one thread may preferable be scheduled to the same core since the cache may contain data relevant to the thread. > > Thanks everybody in advance. > Hope everything is at least a bit clearer. -- Ulf Lilleengen From aksoy.for.research at gmail.com Thu Jan 8 14:16:28 2009 From: aksoy.for.research at gmail.com (=?ISO-8859-1?Q?Mehmet_Ali_Aksoy_T=DCYS=DCZ?=) Date: Thu Jan 8 14:16:35 2009 Subject: Threads and SMP kernel scheduling In-Reply-To: <20090108150807.GA1264@carrot.pvv.ntnu.no> References: <14ded62c0901080123u7268055epb3e17d84aa757051@mail.gmail.com> <20090108150807.GA1264@carrot.pvv.ntnu.no> Message-ID: <14ded62c0901080616o68bad18cg256fa10f12c4560b@mail.gmail.com> Hi, Thank you very much for your response Ulf. It is a very clear answer. Thanks again. By the way, any information for the Linux case? Regards, Mehmet On Thu, Jan 8, 2009 at 10:08 AM, Ulf Lilleengen wrote: > On Thu, Jan 08, 2009 at 04:23:08AM -0500, Mehmet Ali Aksoy T?YS?Z wrote: > > Hi all, > > > > After I had a bit googling I got confused. > > > > My questions are simple and they are as follows : > > > > 1-) "Are pthreads (or threads in general) of one process scheduled to > > different cores on multi-core systems running Linux or BSD?" > > > The standard threading library in FreeBSD will use a 1:1 mapping between > userland threads(pthreads) and kernel threads. This means that each thread > may run on a different core than other threads. > > > 2-) What if there are multiple processes which have multiple threads? > Does > > it change the answer of (1)? > No, the same mapping applies. Although threads of one process may > preferably > run on the same core, each thread of a process may run on any of the cores > available. > > > > > I found some answers but they are not sharp. Somebody says "can be > > scheduled" but "can be" is not a precise answer (in my opinion.) > Well, it means that there are more factors deciding where a thread is put. > If > you look at a factor such as affinity, one thread may preferable be > scheduled > to the same core since the cache may contain data relevant to the thread. > > > > > Thanks everybody in advance. > > > Hope everything is at least a bit clearer. > > -- > Ulf Lilleengen > From ulf.lilleengen at gmail.com Thu Jan 8 20:59:19 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Thu Jan 8 20:59:25 2009 Subject: Threads and SMP kernel scheduling In-Reply-To: <14ded62c0901080616o68bad18cg256fa10f12c4560b@mail.gmail.com> References: <14ded62c0901080123u7268055epb3e17d84aa757051@mail.gmail.com> <20090108150807.GA1264@carrot.pvv.ntnu.no> <14ded62c0901080616o68bad18cg256fa10f12c4560b@mail.gmail.com> Message-ID: <20090108215917.GA1375@carrot.default.net> On tor, jan 08, 2009 at 09:16:26am -0500, Mehmet Ali Aksoy T?YS?Z wrote: > Hi, > > Thank you very much for your response Ulf. It is a very clear answer. Thanks > again. > > By the way, any information for the Linux case? > I think this applies to Linux as well, since it's NPTL(Native Posix Threading Library) uses a 1:1 mapping also. I'm not 100% sure, so you might want to ask on a linux mailing list. -- Ulf Lilleengen From green at FreeBSD.org Fri Jan 9 03:30:09 2009 From: green at FreeBSD.org (Brian Fundakowski Feldman) Date: Fri Jan 9 03:30:16 2009 Subject: threaded, forked, rethreaded processes will deadlock Message-ID: <20090109031942.GA2825@green.homeunix.org> It appears that the post-fork hooks for malloc(3) are somewhat broken such that when a threaded program forks, and then its child attempts to go threaded, it deadlocks because it already appears to have locks held. I am not familiar enough with the current libthr/libc/rtld-elf interaction that I've been able to fix it myself, unfortunately. I discovered this today upgrading my work box from 7.0 to 7.1, but I can easily reproduce it at home on a stale -CURRENT as well. Testing on an OS X box to make sure, the regression test does exit 0 there. Has anyone happened to have fixed this already locally? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From eischen at vigrid.com Fri Jan 9 03:58:40 2009 From: eischen at vigrid.com (Daniel Eischen) Date: Fri Jan 9 03:58:48 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090109031942.GA2825@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> Message-ID: On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: > It appears that the post-fork hooks for malloc(3) are somewhat broken such that > when a threaded program forks, and then its child attempts to go threaded, it > deadlocks because it already appears to have locks held. I am not familiar > enough with the current libthr/libc/rtld-elf interaction that I've been able > to fix it myself, unfortunately. There's really nothing to fix - according to POSIX you are only allowed to call async-signal-safe functions in the child forked from a threaded process. If you are trying to do anything other than that, it may or may not work on FreeBSD, but it is not guaranteed and is not portable. The rationale is that what is the point of forking and creating more threads, when you can just as easily create more threads in the parent without forking? The only reason to fork from a threaded process is to call one of the exec() functions. -- DE -------------- next part -------------- _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From dnelson at allantgroup.com Fri Jan 9 04:22:12 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Fri Jan 9 04:22:27 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: References: <20090109031942.GA2825@green.homeunix.org> Message-ID: <20090109041038.GA52729@dan.emsphone.com> In the last episode (Jan 08), Daniel Eischen said: > On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: > > It appears that the post-fork hooks for malloc(3) are somewhat > > broken such that when a threaded program forks, and then its child > > attempts to go threaded, it deadlocks because it already appears to > > have locks held. I am not familiar enough with the current > > libthr/libc/rtld-elf interaction that I've been able to fix it > > myself, unfortunately. > > There's really nothing to fix - according to POSIX you are only > allowed to call async-signal-safe functions in the child forked from > a threaded process. If you are trying to do anything other than > that, it may or may not work on FreeBSD, but it is not guaranteed and > is not portable. The Rationale section of the pthread_atfork() page is a good read here, too. -- Dan Nelson dnelson@allantgroup.com From green at freebsd.org Fri Jan 9 05:31:20 2009 From: green at freebsd.org (Brian Fundakowski Feldman) Date: Fri Jan 9 05:31:27 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: References: <20090109031942.GA2825@green.homeunix.org> Message-ID: <20090109053117.GB2825@green.homeunix.org> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: > On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: > >> It appears that the post-fork hooks for malloc(3) are somewhat broken such that >> when a threaded program forks, and then its child attempts to go threaded, it >> deadlocks because it already appears to have locks held. I am not familiar >> enough with the current libthr/libc/rtld-elf interaction that I've been able >> to fix it myself, unfortunately. > > There's really nothing to fix - according to POSIX you are only > allowed to call async-signal-safe functions in the child forked > from a threaded process. If you are trying to do anything other > than that, it may or may not work on FreeBSD, but it is not > guaranteed and is not portable. > > The rationale is that what is the point of forking and creating > more threads, when you can just as easily create more threads in > the parent without forking? The only reason to fork from a threaded > process is to call one of the exec() functions. Well, it worked until the last major set of changes to malloc. For me, the point was that I was able to have transparent background worker threads in any program regardless of its architecture, using the standard pthread fork hooks. Could you point me to the POSIX section covering fork and threads? If it's really not supposed to work then that's fine, but there's an awful lot of code there dedicated to support going threaded again after a fork. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From perryh at pluto.rain.com Fri Jan 9 06:01:02 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Fri Jan 9 06:01:08 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <20090108080708.GE1462@roadrunner.spoerlein.net> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> Message-ID: <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> Ulrich Spoerlein wrote: > Please run > % cat /dev/sndstat > % ls -l /dev/dsp0 /dev/dsp0.0 > > The reason you are not seeing them with 'ls /dev/dsp*' is because > devfs is creating the nodes when they are open(2)'ed. Using shell > globbing will search the output of readdir(2) for matches to dsp* > where devfs has no way of dynamically creating nodes (which ones > should it create anyway?) In principle, everything that would be successfully created if open(2)'ed. It doesn't necessarily need to actually create them, but the results from readdir(2) should be as if they had been created. The whole point of things like ls(1) and readdir(2) is to find out what-all is available to be opened, without having to already know the answer. > This is a FAQ really. It may be an FAQ, but it is also a bug, granted one that may not be easy to fix. From kientzle at freebsd.org Fri Jan 9 06:39:31 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Fri Jan 9 06:39:37 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090109053117.GB2825@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> Message-ID: <4966ED8A.4080307@freebsd.org> Brian Fundakowski Feldman wrote: > On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >>On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >> >>>It appears that the post-fork hooks for malloc(3) are somewhat broken such that >>>when a threaded program forks, and then its child attempts to go threaded, it >>>deadlocks because it already appears to have locks held. I am not familiar >>>enough with the current libthr/libc/rtld-elf interaction that I've been able >>>to fix it myself, unfortunately. What version of FreeBSD? I've only glanced through the relevant code, but the malloc() implementation in -CURRENT certainly tries to claim all malloc locks before the fork and releases them all (in both child and parent) just after the fork, so the scenario you describe shouldn't happen. Of course, there may be other locks getting in the way. Tim From julian at elischer.org Fri Jan 9 07:20:32 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Jan 9 07:20:40 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090109053117.GB2825@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> Message-ID: <4966F81C.3070406@elischer.org> Brian Fundakowski Feldman wrote: > On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >> >>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that >>> when a threaded program forks, and then its child attempts to go threaded, it >>> deadlocks because it already appears to have locks held. I am not familiar >>> enough with the current libthr/libc/rtld-elf interaction that I've been able >>> to fix it myself, unfortunately. >> There's really nothing to fix - according to POSIX you are only >> allowed to call async-signal-safe functions in the child forked >> from a threaded process. If you are trying to do anything other >> than that, it may or may not work on FreeBSD, but it is not >> guaranteed and is not portable. >> >> The rationale is that what is the point of forking and creating >> more threads, when you can just as easily create more threads in >> the parent without forking? The only reason to fork from a threaded >> process is to call one of the exec() functions. > > Well, it worked until the last major set of changes to malloc. For me, the point > was that I was able to have transparent background worker threads in any program > regardless of its architecture, using the standard pthread fork hooks. Could you > point me to the POSIX section covering fork and threads? If it's really not > supposed to work then that's fine, but there's an awful lot of code there dedicated > to support going threaded again after a fork. > Practically, you can't go threaded again after a fork (by which I mean creating new threads or use things like mutexes etc.) in any posix system I know of. It would require that: The forking thread stop until: Every other thread has released every resource it owns and reports itself to be in a "safe quiescent state", or at least report every resource it owns, especially locks, and After the fork: The child, post fork, to take ownership of all of them, and free them. You might be able to do that in a simple threaded program, but consider then that the libraries may have threads running in them of which you are unaware, and that some of the resources may interract with resources owned by the forking thread. Add to this that there may be a signal thrown into this mix as well (signals are the bane of thread developement) From shilp.kamal at yahoo.com Fri Jan 9 08:18:47 2009 From: shilp.kamal at yahoo.com (Kamlesh Patel) Date: Fri Jan 9 08:18:54 2009 Subject: kernel panic Message-ID: <468090.72533.qm@web45413.mail.sp1.yahoo.com> Hi there, I changed the following file of FreeBSD 7.0: sys/boot/forth/beastie.4th variable rebootkey variable mykey (added line) I built and installed kernel, then i reboot the system, it gives me the following error: --------------------------------------------------- " panic: free: guard1 fail @ 0x6e104 from /usr/src/sys/boot/i386/loader/../../common/module.c:959 --> Press a key on the console to reboot <-- " ---------------------------------------------------- How do i recover the system from this error. I can't reload the loader.old Could anyone please help me? Kamlesh MS CS, CSUS From aksoy.for.research at gmail.com Fri Jan 9 09:57:17 2009 From: aksoy.for.research at gmail.com (=?ISO-8859-1?Q?Mehmet_Ali_Aksoy_T=DCYS=DCZ?=) Date: Fri Jan 9 09:57:24 2009 Subject: Threads and SMP kernel scheduling In-Reply-To: <20090108215917.GA1375@carrot.default.net> References: <14ded62c0901080123u7268055epb3e17d84aa757051@mail.gmail.com> <20090108150807.GA1264@carrot.pvv.ntnu.no> <14ded62c0901080616o68bad18cg256fa10f12c4560b@mail.gmail.com> <20090108215917.GA1375@carrot.default.net> Message-ID: <14ded62c0901090157t7397f615ted93a979fdda5e14@mail.gmail.com> Hi, Thank you very much again Ulf. I found this http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library and it describes 1:1 correspondence of Linux threads. So, you were right and thank you very much again. Regards, Mehmet On Thu, Jan 8, 2009 at 4:59 PM, Ulf Lilleengen wrote: > On tor, jan 08, 2009 at 09:16:26am -0500, Mehmet Ali Aksoy T?YS?Z wrote: > > Hi, > > > > Thank you very much for your response Ulf. It is a very clear answer. > Thanks > > again. > > > > By the way, any information for the Linux case? > > > I think this applies to Linux as well, since it's NPTL(Native Posix > Threading > Library) uses a 1:1 mapping also. I'm not 100% sure, so you might want to > ask > on a linux mailing list. > > -- > Ulf Lilleengen > From mwm at mired.org Fri Jan 9 07:17:53 2009 From: mwm at mired.org (Mike Meyer) Date: Fri Jan 9 12:16:53 2009 Subject: Small change to 'ps' In-Reply-To: References: <20090107125759.GA1462@roadrunner.spoerlein.net> <20090107154854.GC1462@roadrunner.spoerlein.net> Message-ID: <20090109015106.3614a378@mbook.local> On Wed, 7 Jan 2009 09:27:24 -0800 "Sheldon Givens" wrote: > And I guess I just feel like running a second command to do what should be > possible to do with the first command (and is, on many platforms. ps > --no-headers on linux for example) is a problem and presents opportunity for > continued refinement of the utility. I agree. However, I think we might want to look at a broader scope, in that the same argument applies to pretty much every command that outputs headers - if you're feeding the output to a program, you probably don't want the headers, and copying all the output through another process for the sole purpose of removing them seems wasteful. That we already have commands in the base system that implement this functionality would imply that others agree with this. So `--no-headers' is ok. However, `-n' has lots of different meanings in different commands. How about borrowing from existing commands that already implement this functionality (zfs and zpool) and using `-H', which is relatively rarely used elsewhere? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From deischen at freebsd.org Fri Jan 9 15:52:07 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Fri Jan 9 15:52:14 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090109053117.GB2825@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> Message-ID: On Fri, 9 Jan 2009, Brian Fundakowski Feldman wrote: > On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >> >>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that >>> when a threaded program forks, and then its child attempts to go threaded, it >>> deadlocks because it already appears to have locks held. I am not familiar >>> enough with the current libthr/libc/rtld-elf interaction that I've been able >>> to fix it myself, unfortunately. >> >> There's really nothing to fix - according to POSIX you are only >> allowed to call async-signal-safe functions in the child forked >> from a threaded process. If you are trying to do anything other >> than that, it may or may not work on FreeBSD, but it is not >> guaranteed and is not portable. >> >> The rationale is that what is the point of forking and creating >> more threads, when you can just as easily create more threads in >> the parent without forking? The only reason to fork from a threaded >> process is to call one of the exec() functions. > > Well, it worked until the last major set of changes to malloc. For me, the point > was that I was able to have transparent background worker threads in any program > regardless of its architecture, using the standard pthread fork hooks. Could you > point me to the POSIX section covering fork and threads? If it's really not > supposed to work then that's fine, but there's an awful lot of code there dedicated > to support going threaded again after a fork. I don't know if this link will work for you, but you can start here: http://www.opengroup.org/onlinepubs/009695399/nframe.html "It is suggested that programs that use fork() call an exec function very soon afterwards in the child process, thus resetting all states. In the meantime, only a short list of async-signal-safe library routines are promised to be available." -- DE -- From green at freebsd.org Fri Jan 9 16:34:38 2009 From: green at freebsd.org (Brian Fundakowski Feldman) Date: Fri Jan 9 16:34:45 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <4966F81C.3070406@elischer.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> Message-ID: <20090109163426.GC2825@green.homeunix.org> On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: > Brian Fundakowski Feldman wrote: >> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >>> >>>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that >>>> when a threaded program forks, and then its child attempts to go threaded, it >>>> deadlocks because it already appears to have locks held. I am not familiar >>>> enough with the current libthr/libc/rtld-elf interaction that I've been able >>>> to fix it myself, unfortunately. >>> There's really nothing to fix - according to POSIX you are only >>> allowed to call async-signal-safe functions in the child forked >>> from a threaded process. If you are trying to do anything other >>> than that, it may or may not work on FreeBSD, but it is not >>> guaranteed and is not portable. >>> >>> The rationale is that what is the point of forking and creating >>> more threads, when you can just as easily create more threads in >>> the parent without forking? The only reason to fork from a threaded >>> process is to call one of the exec() functions. >> >> Well, it worked until the last major set of changes to malloc. For me, the point >> was that I was able to have transparent background worker threads in any program >> regardless of its architecture, using the standard pthread fork hooks. Could you >> point me to the POSIX section covering fork and threads? If it's really not >> supposed to work then that's fine, but there's an awful lot of code there dedicated >> to support going threaded again after a fork. >> > > Practically, you can't go threaded again after a fork > (by which I mean creating new threads or use things > like mutexes etc.) in any posix system I know of. > > It would require that: > The forking thread stop until: > Every other thread has released every resource it owns > and reports itself to be in a "safe quiescent state", > or at least report every resource it owns, especially > locks, > and > After the fork: > The child, post fork, to take ownership of all > of them, and free them. > > You might be able to do that in a simple > threaded program, but consider then that the libraries may have > threads running in them of which you are unaware, and that > some of the resources may interract with resources owned by the > forking thread. > > Add to this that there may be a signal thrown into this mix as well > > (signals are the bane of thread developement) Well, I wouldn't mind showing all of you what I can of what I had been doing with the background threads -- it works pretty well modulo this particular malloc lock bug. Due to it being inappropriate to share library resources between a child and parent for an open socket connection, I always considered the only "safe" behavior to be going single-threaded for the duration of the fork processes in both the parent and child, and the pthread_atfork(3) hooks have been sufficient to do so. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From imp at bsdimp.com Fri Jan 9 16:50:21 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 9 16:50:28 2009 Subject: 3x read to write ratio on dump/restore Message-ID: <20090109.095027.-1672857892.imp@bsdimp.com> I just copied a disk using dump + restore. I noticed something through the whole run of this 500GB operation: L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 3 231 231 14754 9.5 0 0 0.0 97.5| da1s1a 0 39 0 0 0.0 39 4982 10.0 38.7| da2s1a The read kBps was 3x the write kBps. While the dump is going through the raw device, and the restore is going through the file system, I can't imagine why we'd have such a huge difference that would be utter consistent for the whole 15 hour run. Any ideas what gives? I observed this with 16MB cache and with 32MB cache, fwiw. Warner From omerfsen at gmail.com Fri Jan 9 17:11:50 2009 From: omerfsen at gmail.com (Omer Faruk Sen) Date: Fri Jan 9 17:11:56 2009 Subject: kernel dump with 7.1-RELEASE Message-ID: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> Hi, I am having kernel dump with FreeBSD 7.1: Here is crashinfo output of it (Actually i don't know the state of crashinfo in Fbsd 7.1) 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 panic: semexit - semid not allocated GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Physical memory: 8173 MB Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff804b4ce9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff804b50f2 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff804f846d in semexit_myhook (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/sysv_sem.c:1328 #5 0xffffffff80490dbc in exit1 (td=0xffffff000995f370, rv=0) at /usr/src/sys/kern/kern_exit.c:244 #6 0xffffffff8049239e in sys_exit (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_exit.c:109 #7 0xffffffff8078a7c7 in syscall (frame=0xffffffffb0d4ac80) at /usr/src/sys/amd64/amd64/trap.c:907 #8 0xffffffff8077088b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #9 0x0000000800a2a30c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From julian at elischer.org Fri Jan 9 17:39:38 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Jan 9 17:39:46 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090109163426.GC2825@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> Message-ID: <49678BBC.8050306@elischer.org> Brian Fundakowski Feldman wrote: > On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: >> Brian Fundakowski Feldman wrote: >>> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >>>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >>>> >>>>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that >>>>> when a threaded program forks, and then its child attempts to go threaded, it >>>>> deadlocks because it already appears to have locks held. I am not familiar >>>>> enough with the current libthr/libc/rtld-elf interaction that I've been able >>>>> to fix it myself, unfortunately. >>>> There's really nothing to fix - according to POSIX you are only >>>> allowed to call async-signal-safe functions in the child forked >>>> from a threaded process. If you are trying to do anything other >>>> than that, it may or may not work on FreeBSD, but it is not >>>> guaranteed and is not portable. >>>> >>>> The rationale is that what is the point of forking and creating >>>> more threads, when you can just as easily create more threads in >>>> the parent without forking? The only reason to fork from a threaded >>>> process is to call one of the exec() functions. >>> Well, it worked until the last major set of changes to malloc. For me, the point >>> was that I was able to have transparent background worker threads in any program >>> regardless of its architecture, using the standard pthread fork hooks. Could you >>> point me to the POSIX section covering fork and threads? If it's really not >>> supposed to work then that's fine, but there's an awful lot of code there dedicated >>> to support going threaded again after a fork. >>> >> Practically, you can't go threaded again after a fork >> (by which I mean creating new threads or use things >> like mutexes etc.) in any posix system I know of. >> >> It would require that: >> The forking thread stop until: >> Every other thread has released every resource it owns >> and reports itself to be in a "safe quiescent state", >> or at least report every resource it owns, especially >> locks, >> and >> After the fork: >> The child, post fork, to take ownership of all >> of them, and free them. >> >> You might be able to do that in a simple >> threaded program, but consider then that the libraries may have >> threads running in them of which you are unaware, and that >> some of the resources may interract with resources owned by the >> forking thread. >> >> Add to this that there may be a signal thrown into this mix as well >> >> (signals are the bane of thread developement) > > Well, I wouldn't mind showing all of you what I can of what I had been doing > with the background threads -- it works pretty well modulo this particular > malloc lock bug. Due to it being inappropriate to share library resources > between a child and parent for an open socket connection, I always considered > the only "safe" behavior to be going single-threaded for the duration of the fork > processes in both the parent and child, and the pthread_atfork(3) hooks have been > sufficient to do so. ahhhh well going single threaded for the duration of the fork, changes everything! > From kostikbel at gmail.com Fri Jan 9 17:42:40 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Jan 9 17:42:48 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090109163426.GC2825@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> Message-ID: <20090109174232.GI93900@deviant.kiev.zoral.com.ua> On Fri, Jan 09, 2009 at 11:34:26AM -0500, Brian Fundakowski Feldman wrote: > On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: > > Brian Fundakowski Feldman wrote: > >> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: > >>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: > >>> > >>>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that > >>>> when a threaded program forks, and then its child attempts to go threaded, it > >>>> deadlocks because it already appears to have locks held. I am not familiar > >>>> enough with the current libthr/libc/rtld-elf interaction that I've been able > >>>> to fix it myself, unfortunately. > >>> There's really nothing to fix - according to POSIX you are only > >>> allowed to call async-signal-safe functions in the child forked > >>> from a threaded process. If you are trying to do anything other > >>> than that, it may or may not work on FreeBSD, but it is not > >>> guaranteed and is not portable. > >>> > >>> The rationale is that what is the point of forking and creating > >>> more threads, when you can just as easily create more threads in > >>> the parent without forking? The only reason to fork from a threaded > >>> process is to call one of the exec() functions. > >> > >> Well, it worked until the last major set of changes to malloc. For me, the point > >> was that I was able to have transparent background worker threads in any program > >> regardless of its architecture, using the standard pthread fork hooks. Could you > >> point me to the POSIX section covering fork and threads? If it's really not > >> supposed to work then that's fine, but there's an awful lot of code there dedicated > >> to support going threaded again after a fork. > >> > > > > Practically, you can't go threaded again after a fork > > (by which I mean creating new threads or use things > > like mutexes etc.) in any posix system I know of. > > > > It would require that: > > The forking thread stop until: > > Every other thread has released every resource it owns > > and reports itself to be in a "safe quiescent state", > > or at least report every resource it owns, especially > > locks, > > and > > After the fork: > > The child, post fork, to take ownership of all > > of them, and free them. > > > > You might be able to do that in a simple > > threaded program, but consider then that the libraries may have > > threads running in them of which you are unaware, and that > > some of the resources may interract with resources owned by the > > forking thread. > > > > Add to this that there may be a signal thrown into this mix as well > > > > (signals are the bane of thread developement) > > Well, I wouldn't mind showing all of you what I can of what I had been doing > with the background threads -- it works pretty well modulo this particular > malloc lock bug. Due to it being inappropriate to share library resources > between a child and parent for an open socket connection, I always considered > the only "safe" behavior to be going single-threaded for the duration of the fork > processes in both the parent and child, and the pthread_atfork(3) hooks have been > sufficient to do so. > In fact, try recent HEAD, it contains the fixed for deadlocks caused by fork calls in mt processes. Also, see r185456, that may be directly relevant to your problem. The MFC to the stable/7 is doable, but depends on the MFC of some stuff committed by David Xu, that would take me some time to look into. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090109/978c350e/attachment.pgp From shilp.kamal at yahoo.com Fri Jan 9 18:08:16 2009 From: shilp.kamal at yahoo.com (Kamlesh Patel) Date: Fri Jan 9 18:28:52 2009 Subject: Having a problem of kernel panic Message-ID: <989835.14737.qm@web45407.mail.sp1.yahoo.com> Hi all, I am having a problem of kernel panic in FreeBSD 7.0: In sys/boot/forth/beastie.4th variable rebootkey variable mykey (added line) After building and installing the kernel, when i reboot the system it gives me the following error: --------------------------------------------------- " panic: free: guard1 fail @ 0x6e104 from /usr/src/sys/boot/i386/loader/../../common/module.c:959 --> Press a key on the console to reboot <-- " ---------------------------------------------------- How do i recover the system from this error. I can't reload the loader.old Could anyone please help me? From julian at elischer.org Fri Jan 9 18:47:56 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Jan 9 18:48:02 2009 Subject: Having a problem of kernel panic In-Reply-To: <989835.14737.qm@web45407.mail.sp1.yahoo.com> References: <989835.14737.qm@web45407.mail.sp1.yahoo.com> Message-ID: <49679BDA.1010209@elischer.org> Kamlesh Patel wrote: > Hi all, > > I am having a problem of kernel panic in FreeBSD 7.0: > > In sys/boot/forth/beastie.4th > variable rebootkey > variable mykey (added line) > > After building and installing the kernel, when i reboot the system it gives me the following error: > > --------------------------------------------------- > " panic: free: guard1 fail @ 0x6e104 from > /usr/src/sys/boot/i386/loader/../../common/module.c:959 > > --> Press a key on the console to reboot <-- " > > ---------------------------------------------------- > > How do i recover the system from this error. I can't reload the loader.old > > Could anyone please help me? it's the loader that is crashing, not the kernel. (at least that is what it looks like to me) maybe reinstall loader from cd? actually you should be able to bypass the loader using the bootblocks.. teh sysntax is arcane but you get a chance to enter something in the bootblocks before the loader. (hit space) replace /boot/loader with /boot/kernel/kernel in teh string (I think... it's been a long time since I tried this.) > > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From green at freebsd.org Fri Jan 9 18:53:05 2009 From: green at freebsd.org (Brian Fundakowski Feldman) Date: Fri Jan 9 18:53:12 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090109174232.GI93900@deviant.kiev.zoral.com.ua> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <20090109174232.GI93900@deviant.kiev.zoral.com.ua> Message-ID: <20090109185255.GD2825@green.homeunix.org> On Fri, Jan 09, 2009 at 07:42:32PM +0200, Kostik Belousov wrote: > On Fri, Jan 09, 2009 at 11:34:26AM -0500, Brian Fundakowski Feldman wrote: > > On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: > > > Brian Fundakowski Feldman wrote: > > >> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: > > >>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: > > >>> > > >>>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that > > >>>> when a threaded program forks, and then its child attempts to go threaded, it > > >>>> deadlocks because it already appears to have locks held. I am not familiar > > >>>> enough with the current libthr/libc/rtld-elf interaction that I've been able > > >>>> to fix it myself, unfortunately. > > >>> There's really nothing to fix - according to POSIX you are only > > >>> allowed to call async-signal-safe functions in the child forked > > >>> from a threaded process. If you are trying to do anything other > > >>> than that, it may or may not work on FreeBSD, but it is not > > >>> guaranteed and is not portable. > > >>> > > >>> The rationale is that what is the point of forking and creating > > >>> more threads, when you can just as easily create more threads in > > >>> the parent without forking? The only reason to fork from a threaded > > >>> process is to call one of the exec() functions. > > >> > > >> Well, it worked until the last major set of changes to malloc. For me, the point > > >> was that I was able to have transparent background worker threads in any program > > >> regardless of its architecture, using the standard pthread fork hooks. Could you > > >> point me to the POSIX section covering fork and threads? If it's really not > > >> supposed to work then that's fine, but there's an awful lot of code there dedicated > > >> to support going threaded again after a fork. > > >> > > > > > > Practically, you can't go threaded again after a fork > > > (by which I mean creating new threads or use things > > > like mutexes etc.) in any posix system I know of. > > > > > > It would require that: > > > The forking thread stop until: > > > Every other thread has released every resource it owns > > > and reports itself to be in a "safe quiescent state", > > > or at least report every resource it owns, especially > > > locks, > > > and > > > After the fork: > > > The child, post fork, to take ownership of all > > > of them, and free them. > > > > > > You might be able to do that in a simple > > > threaded program, but consider then that the libraries may have > > > threads running in them of which you are unaware, and that > > > some of the resources may interract with resources owned by the > > > forking thread. > > > > > > Add to this that there may be a signal thrown into this mix as well > > > > > > (signals are the bane of thread developement) > > > > Well, I wouldn't mind showing all of you what I can of what I had been doing > > with the background threads -- it works pretty well modulo this particular > > malloc lock bug. Due to it being inappropriate to share library resources > > between a child and parent for an open socket connection, I always considered > > the only "safe" behavior to be going single-threaded for the duration of the fork > > processes in both the parent and child, and the pthread_atfork(3) hooks have been > > sufficient to do so. > > > In fact, try recent HEAD, it contains the fixed for deadlocks caused by > fork calls in mt processes. Also, see r185456, that may be directly > relevant to your problem. > > The MFC to the stable/7 is doable, but depends on the MFC of some stuff > committed by David Xu, that would take me some time to look into. Ah, thank you for the pointer. Seems this is an opportunity for me to catch up with our switch to SVN, then. I'll take a further look at this this weekend. For reference, these platforms passed the particular regression test I posted: Linux 2.6.18-92.1.17.el5 SunOS 5.10 Generic_137138-09 Darwin macintosh.green.homeunix.org 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008;root:xnu-1228.9.59~1/RELEASE_I386 i386 FreeBSD 7.0-RELEASE -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From uspoerlein at gmail.com Fri Jan 9 20:20:22 2009 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Fri Jan 9 20:20:29 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> Message-ID: <20090109201201.GA1538@roadrunner.spoerlein.net> On Thu, 08.01.2009 at 21:50:47 -0800, perryh@pluto.rain.com wrote: > Ulrich Spoerlein wrote: Ummm, out of curiosity, are your receiving your mail via UUCP? :) > > Please run > > % cat /dev/sndstat > > % ls -l /dev/dsp0 /dev/dsp0.0 > > > > The reason you are not seeing them with 'ls /dev/dsp*' is because > > devfs is creating the nodes when they are open(2)'ed. Using shell > > globbing will search the output of readdir(2) for matches to dsp* > > where devfs has no way of dynamically creating nodes (which ones > > should it create anyway?) > > In principle, everything that would be successfully created if > open(2)'ed. It doesn't necessarily need to actually create them, > but the results from readdir(2) should be as if they had been > created. The whole point of things like ls(1) and readdir(2) is > to find out what-all is available to be opened, without having to > already know the answer. Not according to my understanding, which may be flawed of course. devfs(4) would have to create all devices, which may be open(2)ed up front, for dsp that would have to be 32 instances (for my system): % ll /dev/dsp0.{0,9,11,21,31} crw-rw-rw- 1 root wheel 0, 142 Jan 9 20:57 /dev/dsp0.0 crw-rw-rw- 1 root wheel 0, 153 Jan 9 20:20 /dev/dsp0.11 crw-rw-rw- 1 root wheel 0, 154 Jan 9 20:20 /dev/dsp0.21 crw-rw-rw- 1 root wheel 0, 151 Jan 9 20:20 /dev/dsp0.31 crw-rw-rw- 1 root wheel 0, 152 Jan 9 20:20 /dev/dsp0.9 It would also cloud the information about devices in-use. > > This is a FAQ really. > > It may be an FAQ, but it is also a bug, granted one that may not be > easy to fix. You really want all cloneable instances to show up with a readdir, which would mean that they would have to created upon device attachment? I really don't think so ... For /dev/dsp0 the semantics are pretty clear: try to open /dev/dsp0, if it succeeds fine, if not, there is no vchan available and you're SOL. No need to play the guess-a-free-dsp-device game. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From rick-freebsd2008 at kiwi-computer.com Fri Jan 9 20:40:17 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Fri Jan 9 20:40:24 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> Message-ID: <20090109204014.GA83381@keira.kiwi-computer.com> On Thu, Jan 08, 2009 at 09:50:47PM -0800, perryh@pluto.rain.com wrote: > > In principle, everything that would be successfully created if > open(2)'ed. It doesn't necessarily need to actually create them, > but the results from readdir(2) should be as if they had been > created. The whole point of things like ls(1) and readdir(2) is > to find out what-all is available to be opened, without having to > already know the answer. That's not how devfs works. It's actually a feature that devfs doesn't list everything ever possible (things looked terrible back in the old MAKEDEV days with all those polluted names). I'd rather be able to list to see things that are in use, although at first glance I didn't like devfs hidden nodes. Otherwise you'd be stuck printing tunXXX through infinity instead of this: % ls /dev/tun* /dev/tun0 /dev/tun115 /dev/tun194 Maybe you could argue that dsp should work differently, but some sound cards and configurations would give you infinite (within reason) device nodes, IIRC. > > This is a FAQ really. > > It may be an FAQ, but it is also a bug, granted one that may not be > easy to fix. This is not a bug, it is designed behavior. It was intentionally written to dynamically create device nodes when needed. -- Rick C. Petty From eitanadlerlist at gmail.com Fri Jan 9 21:36:34 2009 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Fri Jan 9 21:36:45 2009 Subject: bringing ee up to date Message-ID: <4967BBB5.3030703@gmail.com> I think that these three files bring ee up to date from 1.4.2 to 1.4.6. -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen -------------- next part -------------- --- ee/nls/en_US.US-ASCII/ee.msg 2009-01-09 15:52:22.000000000 -0500 +++ easyedit/nls/en_US.US-ASCII/ee.msg 1996-11-29 22:24:20.000000000 -0500 @@ -3,7 +3,7 @@ $ $ For ee patchlevel 3 $ -$ $FreeBSD$ +$ $Header: /home/hugh/sources/old_ae/RCS/ee.msg,v 1.8 1996/11/30 03:23:40 hugh Exp $ $ $ $set 1 @@ -51,7 +51,7 @@ 41 "^f undelete char ^n next page ^x search " 42 "^g begin of line ^o end of line ^y delete line " 43 "^h backspace ^p prev page ^z undelete line " -44 "^[ (escape) menu ESC-Enter: exit ee " +44 "^[ (escape) menu " 45 " " 46 "Commands: " 47 "help : get this info file : print file name " @@ -68,7 +68,7 @@ 58 "^a ascii code ^x search ^z undelete line ^d down ^n next page " 59 "^b bottom of text ^g begin of line ^w delete word ^l left " 60 "^t top of text ^o end of line ^v undelete word ^r right " -61 "^c command ^k delete char ^f undelete char ESC-Enter: exit ee " +61 "^c command ^k delete char ^f undelete char " 62 "help : get help info |file : print file name |line : print line # " 63 "read : read a file |char : ascii code of char |0-9 : go to line \"#\"" 64 "write: write a file |case : case sensitive search |exit : leave and save " @@ -110,7 +110,7 @@ 100 " ...searching" 101 "string \"%s\" not found" 102 "search for: " -103 "could not exec %s" +103 "could not exec %s\n" 104 "press return to continue " 105 "press Esc to cancel" 106 "menu too large for window" @@ -154,8 +154,8 @@ 144 "NOEIGHTBIT" 145 "emacs key bindings " 146 "^a beginning of line ^i tab ^r restore word " -147 "^b back 1 char ^j undel char ^t begin of file " -148 "^c command ^k delete line ^u end of file " +147 "^b back 1 char ^j undel char ^t top of text " +148 "^c command ^k delete line ^u bottom of text " 149 "^d delete char ^l undelete line ^v next page " 150 "^e end of line ^m newline ^w delete word " 151 "^f forward 1 char ^n next line ^x search " @@ -164,7 +164,7 @@ 154 "^[ (escape) menu ^y search prompt ^k delete line ^p prev li ^g prev page" 155 "^o ascii code ^x search ^l undelete line ^n next li ^v next page" 156 "^u end of file ^a begin of line ^w delete word ^b back 1 char " -157 "^t begin of file ^e end of line ^r restore word ^f forward 1 char " +157 "^t top of text ^e end of line ^r restore word ^f forward 1 char " 158 "^c command ^d delete char ^j undelete char ^z next word " 159 "EMACS" 160 "NOEMACS" -------------- next part -------------- Only in easyedit/: Changes diff -u ee/ee.1 easyedit/ee.1 --- ee/ee.1 2009-01-09 15:52:22.000000000 -0500 +++ easyedit/ee.1 2001-12-15 23:49:37.000000000 -0500 @@ -1,623 +1,543 @@ .\" -.\" $FreeBSD$ .\" -.Dd August 30, 1995 -.Dt EE 1 -.Os -.Sh NAME -.Nm ee -.Nd easy editor -.Sh SYNOPSIS -.Nm -.Op Fl eih -.Op +# -.Op Ar -.Nm ree -.Op Fl eih -.Op +# -.Op Ar -.Sh DESCRIPTION -The -.Nm -utility -is a simple screen oriented text editor. -It is always in text insertion -mode unless there is a prompt at the bottom of the terminal, or a -menu present (in a box in the middle of the terminal). -The -.Nm ree -utility is the same as -.Nm , -but restricted to editing the named +.\" To format this reference page, use the command: +.\" +.\" nroff -man ee.1 +.\" +.\" $Header: /home/hugh/sources/old_ae/RCS/ee.1,v 1.22 2001/12/16 04:49:27 hugh Exp $ +.\" +.\" +.TH ee 1 "" "" "" "" +.SH NAME +ee \- easy editor +.SH SYNOPSIS +.nf +ee [-e] [-i] [-h] [+#] [\fIfile\fR ...] +ree [-e] [-i] [-h] [+#] [\fIfile\fR ...] +.ta +.fi +.ad b +.SH DESCRIPTION +The command +.I ee +is a simple screen oriented text editor. It is always in text insertion +mode unless there is a prompt at the bottom of the terminal, or a +menu present (in a box in the middle of the terminal). The command +.I ree +is the same as +.I ee, +but restricted to editing the named file (no file operations, or shell escapes are allowed). -.Pp -For -.Nm -to work properly, the environment variable -.Ev TERM -must be set to indicate the type of terminal being used. -For -example, for an -.Tn HP 700/92 -terminal, the -.Ev TERM -variable should be set to "70092". -See your System Administrator if +.PP +An editor with similar user-friendly qualities but more features is available +and is called +.I aee. +.PP +For +.I ee +to work properly, the environment variable +.SM TERM +must be set to indicate the type of terminal being used. For +example, for an +.SM HP 700/92 +terminal, the +.SM TERM +variable should be set to "70092". See your System Administrator if you need more information. -.Pp -The following options are available: -.Bl -tag -width indent -.It Fl e -Turn off expansion of tab character to spaces. -.It Fl i -Turn off display of information window at top of terminal. -.It Fl h -Turn off highlighting of borders of windows and menus (improves +.\" +.\" options +.\" +.SS Options +The following options are available from the command line: +.PP +.TP 4 +.B -e +Turns off expansion of tab character to spaces. +.TP +.B -i +Turns off display of information window at top of terminal. +.TP +.B -h +Turns off highlighting of borders of windows and menus (improves performance on some terminals). -.It Sy +# -Move the cursor to line '#' at startup. -.El -.Ss "Control keys" -To do anything other than insert text, the user must use the control -keys (the -.Li Control -key, represented by a "^", pressed in conjunction with an -alphabetic key, e.g., ^a) and function keys available on the keyboard -(such as -.Em "Next Page" , -.Em "Prev Page" , +.TP +.B +# +Moves the cursor to line '#' at startup. +.br +.\" +.\" control keys +.\" +.SS "Control keys" +To do anything other than insert text, the user must use the control +keys (the +.B Control +key, represented by a "^", pressed in conjunction with an +alphabetic key, e.g., ^a) and function keys available on the keyboard +(such as +.BR "Next Page" ", " "Prev Page" , arrow keys, etc.). -.Pp -Since not all terminals have function keys, -.Nm -has the basic cursor movement functions assigned to control keys as -well as more intuitive keys on the keyboard when available. -For -instance, to move the cursor up, the user can use the up arrow key, -or -.Em ^u . -.Bl -tag -width indent -.It ^a -Prompt for the decimal value of a character to insert. -.It ^b -Move to the bottom of the text. -.It ^c -Get the prompt for a command. -.It ^d -Move the cursor down. -.It ^e -Prompt for the string to search for. -.It ^f -Undelete the last deleted character. -.It ^g -Move to the beginning of the line. -.It ^h -Backspace. -.It ^i -Tab. -.It ^j -Insert a newline. -.It ^k -Delete the character the cursor is sitting on. -.It ^l -Move the cursor left. -.It ^m -Insert a newline. -.It ^n -Move to the next page. -.It ^o -Move to the end of the line. -.It ^p -Move to the previous page. -.It ^r -Move the cursor to the right. -.It ^t -Move to the top of the text. -.It ^u -Move the cursor up. -.It ^v -Undelete the last deleted word. -.It ^w -Delete the word beginning at the cursor position. -.It ^x -Search. -.It ^y -Delete from the cursor position to the end of line. -.It ^z -Undelete the last deleted line. -.It ^[ (ESC) -Pop up menu. -.El -.Ss "EMACS keys mode" -Since many shells provide an Emacs mode (for cursor movement and other editing -operations), some bindings that may be more useful for people familiar with -those bindings have been provided. -These are accessible via the -.Em settings -menu, or via the initialization file (see below). -The mappings are as follows: -.Bl -tag -width indent -.It ^a -Move to the beginning of the line. -.It ^b -Back 1 character. -.It ^c -Command prompt. -.It ^d -Delete character the cursor is sitting on. -.It ^e -End of line. -.It ^f -Forward 1 character. -.It ^g -Go back 1 page. -.It ^h -Backspace. -.It ^i -Tab. -.It ^j -Undelete last deleted character. -.It ^k -Delete line. -.It ^l -Undelete last deleted line. -.It ^m -Insert a newline. -.It ^n -Move to the next line. -.It ^o -Prompt for the decimal value of a character to insert. -.It ^p -Previous line. -.It ^r -Restore last deleted word. -.It ^t -Move to the top of the text. -.It ^u -Move to the bottom of the text. -.It ^v -Move to the next page. -.It ^w -Delete the word beginning at the cursor position. -.It ^y -Prompt for the string to search for. -.It ^z -Next word. -.It ^[ (ESC) -Pop up menu. -.El -.Ss "Function Keys" -.Bl -tag -width indent -.It Next Page +.PP +Since not all terminals have function keys, +.I ee +has the basic cursor movement functions assigned to control keys as +well as more intuitive keys on the keyboard when available. For +instance, to move the cursor up, the user can use the up arrow key, +or +.BR ^u . +.RS 4 +.nf +.ta 1.4i +.sp +^a Prompt for the decimal value of a character to insert. +^b Move to the bottom of the text. +^c Get the prompt for a command. +^d Move the cursor down. +^e Prompt for the string to search for. +^f Undelete the last deleted character. +^g Move to the beginning of the line. +^h Backspace. +^i Tab. +^j Insert a newline. +^k Delete the character the cursor is sitting on. +^l Move the cursor left. +^m Insert a newline. +^n Move to the next page. +^o Move to the end of the line. +^p Move to the previous page. +^r Move the cursor to the right. +^t Move to the top of the text. +^u Move the cursor up. +^v Undelete the last deleted word. +^w Delete the word beginning at the cursor position. +^x Search. +^y Delete from the cursor position to the end of line. +^z Undelete the last deleted line. +^[ (ESC) Pop up menu. +.ta +.fi +.RE +.sp +.SS "EMACS keys mode" +.PP +Since many shells provide an Emacs mode (for cursor movement and other editing +operations), some bindings that may be more useful for people familiar with +those bindings have been provided. These are accessible via the +.B settings +menu, or via the initialization file (see below). The mappings are as follows: +.RS +.nf +.ta 1.4i +^a Move to the beginning of the line. +^b Back 1 character. +^c Command prompt. +^d Delete character the cursor is sitting on. +^e End of line. +^f Forward 1 character. +^g Go back 1 page. +^h Backspace. +^i Tab. +^j Undelete last deleted character. +^k Delete line. +^l Undelete last deleted line. +^m Insert a newline. +^n Move to the next line. +^o Prompt for the decimal value of a character to insert. +^p Previous line. +^r Restore last deleted word. +^t Move to the top of the text. +^u Move to the bottom of the text. +^v Move to the next page. +^w Delete the word beginning at the cursor position. +^y Prompt for the string to search for. +^z Next word. +^[ (ESC) Pop up menu. +.ta +.fi +.RE +.sp +.\" +.\" function keys +.\" +.SS "Function Keys" +.RS 4 +.IP "\fBNext Page\fR" Move to the next page. -.It Prev Page +.IP "\fBPrev Page\fR" Move to the previous page. -.It Delete Char +.IP "\fBDelete Char\fR" Delete the character the cursor is on. -.It Delete Line +.IP "\fBDelete Line\fR" Delete from the cursor to the end of line. -.It Insert line +.IP "\fBInsert line\fR" Insert a newline at the cursor position. -.It Arrow keys +.IP "\fBArrow keys\fR" Move the cursor in the direction indicated. -.El -.Ss Commands -Some operations require more information than a single keystroke can -provide. -For the most basic operations, there is a menu that can be -obtained by pressing the -.Tn ESC -key. -The same operations, and more can be performed by obtaining the +.RE +.\" +.\" commands +.\" +.SS Commands +.PP +Some operations require more information than a single keystroke can +provide. For the most basic operations, there is a menu that can be +obtained by pressing the +.SM \fBESC\fR +key. The same operations, and more can be performed by obtaining the command prompt (^c) and typing in one of the commands below. -.Bl -tag -width indent -.It ! Ns Ar cmd -Execute -.Ar cmd -in a shell. -.It 0-9 +.RS 4 +.IP "!\fBcmd\fR" +Execute \fBcmd\fR in a shell. +.IP "\fB0-9\fR" Move to the line indicated. -.It case +.IP "\fBcase\fR" Make searches case sensitive. -.It character -Display the ASCII value of the character at the cursor. -.It exit +.IP "\fBcharacter\fR" +Display the ascii value of the character at the cursor. +.IP "\fBexit\fR" Save the edited text, and leave the editor. -.It expand +.IP "\fBexpand\fR" Expand tabs to spaces. -.It file +.IP "\fBfile\fR" Print the name of the file. -.It help +.IP "\fBhelp\fR" Display help screen. -.It line +.IP "\fBline\fR" Display the current line number. -.It nocase +.IP "\fBnocase\fR Make searches insensitive to case (the default). -.It noexpand -Do not expand tab to spaces when the TAB key is pressed. -.It quit +.IP "\fBnoexpand\fR" +Don't expand tab to spaces when the TAB key is pressed. +.IP "\fBquit\fR" Leave the editor without saving changes. -.It read Ar file -Read the named -.Ar file . -.It write Ar file -Write the text to the named -.Ar file . -.El -.Ss "Menu Operations" -Pop-up menus can be obtained by pressing the -.Em escape -key (or -.Em ^[ -if no -.Em escape -key is present). -When in the menu, the escape key can be -used to leave the menu without performing any operations. -Use the up and -down arrow keys, or -.Em ^u -for moving up and -.Em ^d -for moving down to move to the desired items in the menu, then press -.Em return +.IP "\fBread\fR \fIfile\fR" +Read the named \fIfile\fR. +.IP "\fBwrite\fR \fIfile\fR" +Write the text to the named \fIfile\fR. +.RE +.\" +.\" menu operations +.\" +.SS "Menu Operations" +.PP +Pop-up menus can be obtained by pressing the +.B escape +key (or +.B ^[ +if no +.B escape +key is present). When in the menu, the escape key can be +used to leave the menu without performing any operations. Use the up and +down arrow keys, or +.B ^u +for moving up and +.B ^d +for moving down to move to the desired items in the menu, then press +.B return to perform the indicated task. -.Pp -To the left of each menu item is a letter, which if the corresponding +.PP +To the left of each menu item is a letter, which if the corresponding letter is pressed on the keyboard selects that menu entry. -.Pp -The main menu in -.Nm -is as follows: -.Bl -tag -width indent -.It leave editor -If changes have been made, the user will get a menu prompting whether or +.PP +The main menu in \fIee\fR is as follows: +.RS 4 +.IP "\fBleave editor\fR" +If changes have been made, the user will get a menu prompting whether or not the changes should be saved. -.It help -Display a help screen, with all of the keyboard operations and commands. -.It file operations -Pop up a menu for selecting whether to read a file, write to a file, or -save the current contents of the editor, as well as send the contents of -the editor to a print command (see the section -.Sx "Initializing ee from a file" ) . -.It redraw screen -Provide a means to repaint the screen if the screen has been corrupted. -.It settings -Show the current values of the operating modes, and right margin. -By -pressing return when the cursor is on a particular item, the value can be -changed. -To leave this menu, press the -.Em escape -key. -(See -.Sx Modes +.IP "\fBhelp\fR" +Displays a help screen, with all of the keyboard operations and commands. +.IP "\fBfile operations\fR" +Pops up a menu for selecting whether to read a file, write to a file, or +save the current contents of the editor, as well as send the contents of +the editor to a print command (see the section \fBInitializing ee from a +file\fR). +.IP "\fBredraw screen\fR" +Provides a means to repaint the screen if the screen has been corrupted. +.IP "\fBsettings\fR" +Shows the current values of the operating modes, and right margin. By +pressing return when the cursor is on a particular item, the value can be +changed. To leave this menu, press the \fBescape\fR key. (See \fBModes\fR below.) -.It search -Pop up a menu in which the user may choose to enter a string to search +.IP "\fBsearch\fR" +.br +Pops up a menu in which the user may choose to enter a string to search for, or search for a string already entered. -.It miscellaneous -Pop up a menu that allows the user to format the current paragraph, +.IP "\fBmiscellaneous\fR" +Pops up a menu that allows the user to format the current paragraph, execute a shell command, or check the spelling of the text in the editor. -.El -.Ss "Paragraph Formatting" -Paragraphs are defined for -.Nm -by a block of text bounded by: -.Bl -bullet -width indent -.It +.RE +.\" +.\" paragraph formatting +.\" +.SS "Paragraph Formatting" +.PP +Paragraphs are defined for \fIee\fR by a block of text bounded by: +.sp +.RS 8 +.IP \(bu Begin or end of file. -.It +.IP \(bu Line with no characters, or only spaces and/or tabs. -.It +.IP \(bu Line starting with a period ('.') or right angle bracket ('>'). -.El -.Pp -A paragraph may be formatted two ways: explicitly by choosing the -.Em format paragraph -menu item, or by setting -.Nm -to automatically -format paragraphs. -The automatic mode may be set via a menu, or via the +.RE +.PP +A paragraph may be formatted two ways: explicitly by choosing the +\fBformat paragraph\fR menu item, or by setting \fIee\fR to automatically +format paragraphs. The automatic mode may be set via a menu, or via the initialization file. -.Pp -There are three states for text operation in -.Nm : -free-form, margins, +.PP +There are three states for text operation in \fIee\fR: free-form, margins, and automatic formatting. -.Pp -"Free-form" is best used for things like programming. -There are no +.PP +"Free-form" is best used for things like programming. There are no restrictions on the length of lines, and no formatting takes place. -.Pp -"Margins" allows the user to type in text without having to worry about going -beyond the right margin (the right margin may be set in the -.Em settings -menu, the default is for the margin to be the right edge of the -terminal). -This is the mode that allows the -.Em format paragraph -menu item to work. -.Pp -"Automatic formatting" provides word-processor-like behavior. -The user -may type in text, while -.Nm -will make sure the entire paragraph fits -within the width of the terminal every time the user inserts a space after -typing or deleting text. -Margin observation must also be enabled in order for +.PP +"Margins" allows the user to type in text without having to worry about going +beyond the right margin (the right margin may be set in the \fBsettings\fR +menu, the default is for the margin to be the right edge of the +terminal). This is the mode that allows the \fBformat paragraph\fR menu +item to work. +.PP +"Automatic formatting" provides word-processor-like behavior. The user +may type in text, while \fIee\fR will make sure the entire paragraph fits +within the width of the terminal every time the user inserts a space after +typing or deleting text. Margin observation must also be enabled in order for automatic formatting to occur. -.Ss Modes -Although -.Nm -is a 'modeless' editor (it is in text insertion mode all the -time), there are modes in some of the things it does. -These include: -.Bl -tag -width indent -.It tab expansion +.\" +.\" modes +.\" +.SS Modes +.PP +Although ee is a 'modeless' editor (it is in text insertion mode all the +time), there are modes in some of the things it does. These include: +.RS 4 +.IP "\fBtab expansion\fR" Tabs may be inserted as a single tab character, or replaced with spaces. -.It case sensitivity -The search operation can be sensitive to whether characters are upper- or +.IP "\fBcase sensitivity\fR" +The search operation can be sensitive to whether characters are upper- or lower-case, or ignore case completely. -.It margins observed +.IP "\fBmargins observed\fR" Lines can either be truncated at the right margin, or extend on forever. -.It auto paragraph formatting -While typing in text, the editor can try to keep it looking reasonably well +.IP "\fBauto paragraph formatting\fR" +While typing in text, the editor can try to keep it looking reasonably well within the width of the screen. -.It eightbit characters -Toggle whether eight bit characters are displayed as their value in angle -brackets (e.g.\& "<220>") or as a character. -.It info window -A window showing the keyboard operations that can be performed can be +.IP "\fBeightbit characters\fR" +Toggles whether eight bit characters are displayed as their value in angle +brackets (e.g. "<220>") or as a character. +.IP "\fBinfo window\fR" +A window showing the keyboard operations that can be performed can be displayed or not. -.It emacs keys +.IP "\fBemacs keys\fR" Control keys may be given bindings similar to emacs, or not. -.It 16 bit characters -Toggles whether sixteen bit characters are handled as one 16-bit quantities or -two 8-bit quantities. -This works primarily with the Chinese Big 5 code set. -.El -.Pp -You may set these modes via the initialization file (see below), or with a +.IP "\f16 bit characters\fR" +Toggles whether sixteen bit characters are handled as one 16-bit quantities or +two 8-bit quantities. This works primarily with the Chinese Big 5 code set. +.RE +.PP +You may set these modes via the initialization file (see below), or with a menu (see above). -.Ss "Spell Checking" -There are two ways to have the spelling in the text checked from -.Nm . -One is by the traditional -.Xr spell 1 -command, the other is with the -optional -.Nm ispell -command. -.Pp -Using -.Nm spell , -the words that are not recognized will be placed at the top -of the file. -For the -.Nm ispell -option, the file is written to disk, -then -.Nm ispell -run on the file, and the file read back in once -.Nm ispell -has completed making changes to the file. -.Ss "Printing the contents of the editor" -The user may select a menu item which prints the contents of the editor. -The -.Nm -utility pipes the text in the editor to the command specified by the -initialization command -.Em printcommand -(see the section -.Sx Initializing ee from a file -below). -The default is to send the contents to -.Xr lp 1 . -.Pp -Whatever the user assigns to -.Em printcommand -must take input from -standard input. -See your system administrator for more details. -.Ss "Shell operations" -Shell commands can be executed from within -.Nm -by selecting the -.Em shell command -item in the -.Em miscellaneous -menu, or by placing an exclamation mark ("!") before the command to -execute at the -.Em command: -prompt. -Additionally, the user may direct the contents of the edit buffer -out to a shell operation (via a pipe) by using the left angle bracket -(">"), followed by a "!" and the shell command to execute. -The output of -a shell operation can also be directed into the edit buffer by using a -right angle bracket ("<") before the exclamation mark. -These can even be -used together to send output to a shell operation and read back the -results into the editor. -So, if the editor contained a list of words -to be sorted, they could be sorted by typing the following at the command +.\" +.\" spell checking +.\" +.SS "Spell Checking" +.PP +There are two ways to have the spelling in the text checked from \fIee\fR. +One is by the traditional \fIspell\fR(1) command, the other is with the +optional \fIispell\fR(1) command. +.PP +Using \fIspell\fR, the words that are not recognized will be placed at the top +of the file. For the \fIispell\fR option, the file is written to disk, +then \fIispell\fR run on the file, and the file read back in once +\fIispell\fR has completed making changes to the file. +.\" +.\" printing +.\" +.SS "Printing the contents of the editor" +.PP +The user may select a menu item which prints the contents of the editor. +.I ee +pipes the text in the editor to the command specified by the +initialization command +.B printcommand +(see the section +.B Initializing ee from a file +below). The default is to send the contents to "lp". +.PP +Whatever the user assigns to +.B printcommand +must take input from +standard input. See your system administrator for more details. +.\" +.\" shell operations +.\" +.SS "Shell operations" +.PP +Shell commands can be executed from within +.I ee +by selecting the +.B shell command +item in the +.B miscellaneous +menu, or by placing an exclamation mark ("!") before the command to +execute at the +.B command: +prompt. Additionally, the user may direct the contents of the edit buffer +out to a shell operation (via a pipe) by using the left angle bracket +(">"), followed by a "!" and the shell command to execute. The output of +a shell operation can also be directed into the edit buffer by using a +right angle bracket ("<") before the exclamation mark. These can even be +used together to send output to a shell operation and read back the +results into the editor. So, if the editor contained a list of words +to be sorted, they could be sorted by typing the following at the command prompt: -.Dl >"). -.It 16bit +.IP \fB16bit\fR Turns on handling of 16-bit characters. -.It no16bit +.IP \fbno16bit\fR Turns off handling of 16-bit characters. -.It emacs +.IP \fBemacs\fR Turns on emacs key bindings. -.It noemacs +.IP \fBnoemacs\fR Turns off emacs key bindings. -.El -.Ss "Save Editor Configuration" -When using this entry from the -.Em settings -menu, the user may choose to save the current configuration of -the editor (see -.Sx Initializing ee from a file -above) to a file named -.Pa .init.ee -in the current directory or the user's home directory. -If a file named -.Pa .init.ee -already exists, it will be renamed -.Pa .init.ee.old . -.Sh CAVEATS -THIS MATERIAL IS PROVIDED "AS IS". -THERE ARE -NO WARRANTIES OF ANY KIND WITH REGARD TO THIS -MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE -IMPLIED WARRANTIES OF MERCHANTABILITY AND -FITNESS FOR A PARTICULAR PURPOSE. -Neither -Hewlett-Packard nor Hugh Mahon shall be liable -for errors contained herein, nor for -incidental or consequential damages in -connection with the furnishing, performance or -use of this material. -Neither Hewlett-Packard -nor Hugh Mahon assumes any responsibility for -the use or reliability of this software or -documentation. -This software and -documentation is totally UNSUPPORTED. -There -is no support contract available. -Hewlett-Packard -has done NO Quality Assurance on ANY -of the program or documentation. -You may find -the quality of the materials inferior to -supported materials. -.Pp -Always make a copy of files that cannot be easily reproduced before -editing. -Save files early, and save often. -.Ss "International Code Set Support" -The -.Nm -utility supports single-byte character code sets (eight-bit clean), or the -Chinese Big-5 code set. -(Other multi-byte code sets may function, but the -reason Big-5 works is that a two-byte character also takes up two columns on +.RE +.\" +.\" save editor configuration +.\" +.SS "Save Editor Configuration" +.PP +When using this entry from the +.B settings +menu, the user may choose to save the current configuration of +the editor (see \fBInitializing ee from a +file\fR above) to a file named +.I .init.ee +in the current directory or the user's home directory. If a file named +.I .init.ee +already exists, it will be renamed +.IR .init.ee.old . +.\" +.\" Caveats +.\" +.SH CAVEATS +.PP +THIS MATERIAL IS PROVIDED "AS IS". THERE ARE +NO WARRANTIES OF ANY KIND WITH REGARD TO THIS +MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND +FITNESS FOR A PARTICULAR PURPOSE. Neither +Hewlett-Packard nor Hugh Mahon shall be liable +for errors contained herein, nor for +incidental or consequential damages in +connection with the furnishing, performance or +use of this material. Neither Hewlett-Packard +nor Hugh Mahon assumes any responsibility for +the use or reliability of this software or +documentation. This software and +documentation is totally UNSUPPORTED. There +is no support contract available. Hewlett-Packard +has done NO Quality Assurance on ANY +of the program or documentation. You may find +the quality of the materials inferior to +supported materials. +.PP +Always make a copy of files that cannot be easily reproduced before +editing. Save files early, and save often. +.SS "International Code Set Support" +.I ee +supports single-byte character code sets (eight-bit clean), or the +Chinese Big-5 code set. (Other multi-byte code sets may function, but the +reason Big-5 works is that a two-byte character also takes up two columns on the screen.) -.Sh WARNINGS -The automatic paragraph formatting operation +.SH WARNINGS +The automatic paragraph formatting operation may be too slow for slower systems. -.Sh FILES -.Bl -tag -width /usr/share/misc/init.ee -compact -.It Pa /usr/share/misc/init.ee -.It Pa $HOME/.init.ee -.It Pa .init.ee -.El -.Sh AUTHORS -The software -.Nm -was developed by -.An Hugh Mahon . -.Pp -This software and documentation contains -proprietary information which is protected by -copyright. -All rights are reserved. -.Pp -Copyright (c) 1990, 1991, 1992, 1993, 1995, 1996 Hugh Mahon. -.Sh "SEE ALSO" -.Xr ispell 1 Pq Pa ports/textproc/ispell , -.Xr lpr 1 , -.Xr spell 1 , -.Xr termcap 5 , -.Xr terminfo 5 , -.Xr environ 7 +.SH FILES +.PP +.I /usr/local/lib/init.ee +.br +.I $HOME/.init.ee +.br +.I .init.ee +.SH AUTHOR +.PP +The software +.I ee +was developed by Hugh Mahon. +.PP +This software and documentation contains +proprietary information which is protected by +copyright. All rights are reserved. +.PP +Copyright (c) 1990, 1991, 1992, 1993, 1995, 1996, 2001 Hugh Mahon. +.SH "SEE ALSO" +.PP +termcap(4), terminfo(4), environ(5), spell(1), ispell(1), lp(1), aee(1) + diff -u ee/ee.c easyedit/ee.c --- ee/ee.c 2009-01-09 15:52:22.000000000 -0500 +++ easyedit/ee.c 2002-09-20 20:46:16.000000000 -0400 @@ -48,11 +48,11 @@ | This software and documentation contains | proprietary information which is protected by | copyright. All rights are reserved. + | + | $Header: /home/hugh/sources/old_ae/RCS/ee.c,v 1.99 2001/12/24 05:43:32 hugh Exp $ + | */ -#include -__FBSDID("$FreeBSD$"); - char *ee_copyright_message = "Copyright (c) 1986, 1990, 1991, 1992, 1993, 1994, 1995, 1996 Hugh Mahon "; @@ -62,41 +62,45 @@ "copyright. All rights are reserved." }; -char *version = "@(#) ee, version 1.4.1"; +#include "ee_version.h" + +char *version = "@(#) ee, version " EE_VERSION " $Revision: 1.99 $"; #ifdef NCURSE #include "new_curse.h" -#elif HAS_NCURSES -#include #else #include #endif -#ifdef HAS_CTYPE -#include -#endif -#include -#include -#include -#include -#include #include +#include #include #include +#include +#include +#include + #ifdef HAS_SYS_WAIT #include #endif -#ifdef HAS_STDARG -#include -#endif + #ifdef HAS_STDLIB #include #endif -#include + +#ifdef HAS_STDARG +#include +#endif + #ifdef HAS_UNISTD #include #endif +#ifdef HAS_CTYPE +#include +#endif + + #ifndef NO_CATGETS #include #include @@ -200,11 +204,8 @@ unsigned char *d_word; /* deleted word */ unsigned char *d_line; /* deleted line */ char in_string[513]; /* buffer for reading a file */ -unsigned char *print_command = "lpr"; /* string to use for the print command */ +unsigned char *print_command = "lp"; /* string to use for the print command */ unsigned char *start_at_line = NULL; /* move to this line at start of session*/ -const char count_text_default[] = "==============================================================================="; -int count_text_len = sizeof(count_text_default); /* length of the line above */ -char count_text[sizeof(count_text_default)]; /* buffer for current position display */ int in; /* input character */ FILE *temp_fp; /* temporary file pointer */ @@ -220,7 +221,6 @@ WINDOW *text_win; WINDOW *help_win; WINDOW *info_win; -WINDOW *count_win; #if defined(__STDC__) || defined(__cplusplus) #define P_(s) s @@ -300,7 +300,7 @@ int quit P_((int noverify)); void edit_abort P_((int arg)); void delete_text P_((void)); -int write_file P_((char *file_name, int warn_if_exists)); +int write_file P_((char *file_name)); int search P_((int display_message)); void search_prompt P_((void)); void del_char P_((void)); @@ -341,7 +341,6 @@ char *resolve_name P_((char *name)); int restrict_mode P_((void)); int unique_test P_((char *string, char *list[])); -void renumber_lines P_((struct text *firstline, int startnumber)); void strings_init P_((void)); #undef P_ @@ -538,23 +537,29 @@ char *chinese_cmd, *nochinese_cmd; +#ifndef __STDC__ +#ifndef HAS_STDLIB +extern char *malloc(); +extern char *realloc(); +extern char *getenv(); +FILE *fopen(); /* declaration for open function */ +#endif /* HAS_STDLIB */ +#endif /* __STDC__ */ int main(argc, argv) /* beginning of main program */ int argc; char *argv[]; { - /* Always read from (and write to) a terminal. */ - if (!isatty(STDIN_FILENO) || !isatty(STDOUT_FILENO)) { - fprintf(stderr, "ee's standard input and output must be a terminal\n"); - exit(1); - } + int counter; + pid_t parent_pid; + + for (counter = 1; counter < 24; counter++) + signal(counter, SIG_IGN); signal(SIGCHLD, SIG_DFL); signal(SIGSEGV, SIG_DFL); signal(SIGINT, edit_abort); - signal(SIGHUP, edit_abort); - d_char = malloc(3); /* provide a buffer for multi-byte chars */ d_word = malloc(150); *d_word = (char) NULL; @@ -575,7 +580,7 @@ scr_pos =0; scr_vert = 0; scr_horz = 0; - bit_bucket = fopen(_PATH_DEVNULL, "w"); + bit_bucket = fopen("/dev/null", "w"); edit = TRUE; gold = case_sen = FALSE; shell_fork = TRUE; @@ -604,26 +609,30 @@ clear_com_win = TRUE; + counter = 0; + while(edit) { - if (info_window) - { - snprintf(count_text, count_text_len, "L: %d C: %d %s", \ - curr_line->line_number, scr_horz + 1, count_text_default); - wmove(count_win, 0, 0); - if (!nohighlight) - wstandout(count_win); - wprintw(count_win, count_text); - wstandend(count_win); - wnoutrefresh(count_win); - } - - wnoutrefresh(text_win); - doupdate(); + wrefresh(text_win); in = wgetch(text_win); if (in == -1) - continue; - + exit(0); + /* + | The above check used to work to detect if the parent + | process died, but now it seems we need a more + | sophisticated check. + */ + if (counter > 50) + { + parent_pid = getppid(); + if (parent_pid == 1) + edit_abort(1); + else + counter = 0; + } + else + counter++; + resize_check(); if (clear_com_win) @@ -821,7 +830,6 @@ if (temp_buff->next_line != NULL) temp_buff->next_line->prev_line = curr_line; curr_line->next_line = temp_buff->next_line; - renumber_lines(curr_line->next_line, curr_line->line_number + 1); temp2 = temp_buff->line; if (in == 8) { @@ -955,13 +963,13 @@ } else { - waddch(window, (unsigned char)character ); + waddch(window, (char)character ); return(1); } } else { - waddch(window, (unsigned char)character); + waddch(window, (char)character); return(1); } for (i2 = 0; (string[i2] != (char) NULL) && (((column+i2+1)-horiz_offset) < last_col); i2++) @@ -1066,8 +1074,8 @@ temp_nod->line = extra= malloc(10); temp_nod->line_length = 1; temp_nod->max_length = 10; + temp_nod->line_number = curr_line->line_number + 1; temp_nod->next_line = curr_line->next_line; - renumber_lines(temp_nod, curr_line->line_number + 1); if (temp_nod->next_line != NULL) temp_nod->next_line->prev_line = temp_nod; temp_nod->prev_line = curr_line; @@ -1519,10 +1527,8 @@ left(TRUE); else if (in == KEY_RIGHT) right(TRUE); - else if (in == KEY_HOME) - bol(); - else if (in == KEY_END) - eol(); + else if ( in == KEY_HOME) + top(); else if ( in == KEY_UP) up(); else if (in == KEY_DOWN) @@ -1688,7 +1694,7 @@ cmd_str = cmd_str2 = get_string(file_write_prompt_str, TRUE); } tmp_file = resolve_name(cmd_str); - write_file(tmp_file, 1); + write_file(tmp_file); if (tmp_file != cmd_str) free(tmp_file); } @@ -1869,7 +1875,7 @@ esc_flag = FALSE; in = wgetch(com_win); if (in == -1) - continue; + exit(0); if (((in == 8) || (in == 127) || (in == KEY_BACKSPACE)) && (g_pos > 0)) { tmp_int = g_horz; @@ -1894,7 +1900,7 @@ esc_flag = TRUE; in = wgetch(com_win); if (in == -1) - continue; + exit(0); } *nam_str = in; g_pos++; @@ -1968,7 +1974,7 @@ int number; int i; char *ptr; - char *direction = NULL; + char *direction; struct text *t_line; ptr = cmd_str; @@ -2039,7 +2045,7 @@ { char *buff; int count; - struct files *temp_names = NULL; + struct files *temp_names; char *name; char *ptr; int no_more_opts = FALSE; @@ -2059,7 +2065,7 @@ input_file = FALSE; recv_file = FALSE; count = 1; - while ((count < numargs) && (!no_more_opts)) + while ((count < numargs)&& (!no_more_opts)) { buff = arguments[count]; if (!strcmp("-i", buff)) @@ -2083,7 +2089,7 @@ fprintf(stderr, usage4); exit(1); } - else if (*buff == '+') + else if ((*buff == '+') && (start_at_line == NULL)) { buff++; start_at_line = buff; @@ -2315,8 +2321,8 @@ if (!(*append)) /* if not append to current line, insert new one */ { tline = txtalloc(); /* allocate data structure for next line */ + tline->line_number = curr_line->line_number + 1; tline->next_line = curr_line->next_line; - renumber_lines(tline, curr_line->line_number + 1); tline->prev_line = curr_line; curr_line->next_line = tline; if (tline->next_line != NULL) @@ -2395,7 +2401,7 @@ file_name = tmp_file; } - if (write_file(file_name, 1)) + if (write_file(file_name)) { text_changes = FALSE; quit(0); @@ -2435,7 +2441,6 @@ recv_file = TRUE; input_file = TRUE; check_fp(); - text_changes = FALSE; } return(0); } @@ -2472,9 +2477,8 @@ } int -write_file(file_name, warn_if_exists) +write_file(file_name) char *file_name; -int warn_if_exists; { char cr; char *tmp_point; @@ -2484,8 +2488,7 @@ int write_flag = TRUE; charac = lines = 0; - if (warn_if_exists && - ((in_file_name == NULL) || strcmp(in_file_name, file_name))) + if ((in_file_name == NULL) || strcmp(in_file_name, file_name)) { if ((temp_fp = fopen(file_name, "r"))) { @@ -3151,8 +3154,9 @@ } for (value = 1; value < 24; value++) signal(value, SIG_DFL); - execl(path, last_slash, "-c", string, (char *)NULL); - errx(1, exec_err_msg, path); + execl(path, last_slash, "-c", string, NULL); + printf(exec_err_msg, path); + exit(-1); } else /* if the parent */ { @@ -3195,7 +3199,7 @@ } if (shell_fork) { - printf("%s", continue_msg); + printf(continue_msg); fflush(stdout); while ((in = getchar()) != '\n') ; @@ -3255,12 +3259,9 @@ if (info_window) { info_type = CONTROL_KEYS; - info_win = newwin(5, COLS, 0, 0); + info_win = newwin(6, COLS, 0, 0); werase(info_win); paint_info_win(); - count_win = newwin(1, COLS, 5, 0); - leaveok(count_win, TRUE); - wrefresh(count_win); } last_col = COLS - 1; @@ -3285,7 +3286,6 @@ delwin(text_win); delwin(com_win); delwin(help_win); - delwin(count_win); set_up_term(); redraw(); wrefresh(text_win); @@ -3303,7 +3303,7 @@ int counter; int length; int input; - int temp = 0; + int temp; int list_size; int top_offset; /* offset from top where menu items start */ int vert_pos; /* vertical position */ @@ -3385,7 +3385,10 @@ wmove(temp_win, (counter + top_offset - off_start), 3); wrefresh(temp_win); - input = wgetch(temp_win); + in = wgetch(temp_win); + input = in; + if (input == -1) + exit(0); if (((tolower(input) >= 'a') && (tolower(input) <= 'z')) || ((input >= '0') && (input <= '9'))) @@ -3628,6 +3631,8 @@ wprintw(com_win, press_any_key_msg); wrefresh(com_win); counter = wgetch(com_win); + if (counter == -1) + exit(0); werase(com_win); wmove(com_win, 0, 0); werase(help_win); @@ -3655,6 +3660,11 @@ else if (info_type == COMMANDS) waddstr(info_win, command_strings[counter]); } + wmove(info_win, 5, 0); + if (!nohighlight) + wstandout(info_win); + waddstr(info_win, "==============================================================================="); + wstandend(info_win); wrefresh(info_win); } @@ -3688,15 +3698,12 @@ idlok(text_win, TRUE); werase(text_win); info_window = TRUE; - info_win = newwin(5, COLS, 0, 0); + info_win = newwin(6, COLS, 0, 0); werase(info_win); info_type = CONTROL_KEYS; midscreen(min(scr_vert, last_line), point); clearok(info_win, TRUE); paint_info_win(); - count_win = newwin(1, COLS, 5, 0); - leaveok(count_win, TRUE); - wrefresh(count_win); wrefresh(text_win); clear_com_win = TRUE; } @@ -3727,7 +3734,7 @@ { string = get_string(file_write_prompt_str, TRUE); tmp_file = resolve_name(string); - write_file(tmp_file, 1); + write_file(tmp_file); if (tmp_file != string) free(tmp_file); free(string); @@ -3764,7 +3771,7 @@ string = tmp_file; } } - if (write_file(string, 1)) + if (write_file(string)) { in_file_name = string; text_changes = FALSE; @@ -4073,7 +4080,7 @@ } unsigned char *init_name[3] = { - "/usr/share/misc/init.ee", + "/usr/local/lib/init.ee", NULL, ".init.ee" }; @@ -4090,8 +4097,6 @@ int temp_int; string = getenv("HOME"); - if (!string) - string = "/root"; /* Set to reasonable default so we don't crash */ str1 = home = malloc(strlen(string)+10); strcpy(home, string); strcat(home, "/.init.ee"); @@ -4377,25 +4382,17 @@ void ispell_op() { - char template[128], *name; + char name[128]; char string[256]; - int fd; + int pid; if (restrict_mode()) { return; } - (void)sprintf(template, "/tmp/ee.XXXXXXXX"); - name = mktemp(&template[0]); - fd = open(name, O_CREAT | O_EXCL | O_RDWR, 0600); - if (fd < 0) { - wmove(com_win, 0, 0); - wprintw(com_win, create_file_fail_msg, name); - wrefresh(com_win); - return; - } - close(fd); - if (write_file(name, 0)) + pid = getpid(); + sprintf(name, "/tmp/ee.%d", pid); + if (write_file(name)) { sprintf(string, "ispell %s", name); sh_command(string); @@ -4993,19 +4990,6 @@ return(num_match); } -void -renumber_lines(firstline, startnumber) -struct text *firstline; -int startnumber; -{ - struct text *lineptr; - int i; - - i = startnumber; - for (lineptr = firstline; lineptr != NULL; lineptr = lineptr->next_line) - lineptr->line_number = i++; -} - #ifndef NO_CATGETS /* | Get the catalog entry, and if it got it from the catalog, @@ -5046,7 +5030,7 @@ #ifndef NO_CATGETS setlocale(LC_ALL, ""); - catalog = catopen("ee", NL_CAT_LOCALE); + catalog = catopen("ee", 0); #endif /* NO_CATGETS */ modes_menu[0].item_string = catgetlocal( 1, "modes menu"); @@ -5092,7 +5076,7 @@ help_text[6] = catgetlocal( 41, "^f undelete char ^n next page ^x search "); help_text[7] = catgetlocal( 42, "^g begin of line ^o end of line ^y delete line "); help_text[8] = catgetlocal( 43, "^h backspace ^p prev page ^z undelete line "); - help_text[9] = catgetlocal( 44, "^[ (escape) menu ESC-Enter: exit ee "); + help_text[9] = catgetlocal( 44, "^[ (escape) menu "); help_text[10] = catgetlocal( 45, " "); help_text[11] = catgetlocal( 46, "Commands: "); help_text[12] = catgetlocal( 47, "help : get this info file : print file name "); @@ -5109,7 +5093,7 @@ control_keys[1] = catgetlocal( 58, "^a ascii code ^x search ^z undelete line ^d down ^n next page "); control_keys[2] = catgetlocal( 59, "^b bottom of text ^g begin of line ^w delete word ^l left "); control_keys[3] = catgetlocal( 60, "^t top of text ^o end of line ^v undelete word ^r right "); - control_keys[4] = catgetlocal( 61, "^c command ^k delete char ^f undelete char ESC-Enter: exit ee "); + control_keys[4] = catgetlocal( 61, "^c command ^k delete char ^f undelete char "); command_strings[0] = catgetlocal( 62, "help : get help info |file : print file name |line : print line # "); command_strings[1] = catgetlocal( 63, "read : read a file |char : ascii code of char |0-9 : go to line \"#\""); command_strings[2] = catgetlocal( 64, "write: write a file |case : case sensitive search |exit : leave and save "); @@ -5151,7 +5135,7 @@ searching_msg = catgetlocal( 100, " ...searching"); str_not_found_msg = catgetlocal( 101, "string \"%s\" not found"); search_prompt_str = catgetlocal( 102, "search for: "); - exec_err_msg = catgetlocal( 103, "could not exec %s"); + exec_err_msg = catgetlocal( 103, "could not exec %s\n"); continue_msg = catgetlocal( 104, "press return to continue "); menu_cancel_msg = catgetlocal( 105, "press Esc to cancel"); menu_size_err_msg = catgetlocal( 106, "menu too large for window"); @@ -5199,8 +5183,8 @@ mode_strings[7] = catgetlocal( 145, "emacs key bindings "); emacs_help_text[0] = help_text[0]; emacs_help_text[1] = catgetlocal( 146, "^a beginning of line ^i tab ^r restore word "); - emacs_help_text[2] = catgetlocal( 147, "^b back 1 char ^j undel char ^t begin of file "); - emacs_help_text[3] = catgetlocal( 148, "^c command ^k delete line ^u end of file "); + emacs_help_text[2] = catgetlocal( 147, "^b back 1 char ^j undel char ^t top of text "); + emacs_help_text[3] = catgetlocal( 148, "^c command ^k delete line ^u bottom of text "); emacs_help_text[4] = catgetlocal( 149, "^d delete char ^l undelete line ^v next page "); emacs_help_text[5] = catgetlocal( 150, "^e end of line ^m newline ^w delete word "); emacs_help_text[6] = catgetlocal( 151, "^f forward 1 char ^n next line ^x search "); @@ -5219,11 +5203,11 @@ emacs_help_text[19] = help_text[19]; emacs_help_text[20] = help_text[20]; emacs_help_text[21] = help_text[21]; - emacs_control_keys[0] = catgetlocal( 154, "^[ (escape) menu ^y search prompt ^k delete line ^p prev line ^g prev page"); - emacs_control_keys[1] = catgetlocal( 155, "^o ascii code ^x search ^l undelete line ^n next line ^v next page"); - emacs_control_keys[2] = catgetlocal( 156, "^u end of file ^a begin of line ^w delete word ^b back char ^z next word"); - emacs_control_keys[3] = catgetlocal( 157, "^t begin of file ^e end of line ^r restore word ^f forward char "); - emacs_control_keys[4] = catgetlocal( 158, "^c command ^d delete char ^j undelete char ESC-Enter: exit"); + emacs_control_keys[0] = catgetlocal( 154, "^[ (escape) menu ^y search prompt ^k delete line ^p prev li ^g prev page"); + emacs_control_keys[1] = catgetlocal( 155, "^o ascii code ^x search ^l undelete line ^n next li ^v next page"); + emacs_control_keys[2] = catgetlocal( 156, "^u end of file ^a begin of line ^w delete word ^b back 1 char "); + emacs_control_keys[3] = catgetlocal( 157, "^t top of text ^e end of line ^r restore word ^f forward 1 char "); + emacs_control_keys[4] = catgetlocal( 158, "^c command ^d delete char ^j undelete char ^z next word "); EMACS_string = catgetlocal( 159, "EMACS"); NOEMACS_string = catgetlocal( 160, "NOEMACS"); usage4 = catgetlocal( 161, " +# put cursor at line #\n"); Only in easyedit/: ee_version.h diff -u ee/new_curse.c easyedit/new_curse.c --- ee/new_curse.c 2009-01-09 15:52:22.000000000 -0500 +++ easyedit/new_curse.c 2002-09-20 20:48:03.000000000 -0400 @@ -37,15 +37,14 @@ | Copyright (c) 1986, 1987, 1988, 1991, 1992, 1993, 1994, 1995 Hugh Mahon | All are rights reserved. | - | $Header: /home/hugh/sources/old_ae/RCS/new_curse.c,v 1.49 1998/12/21 02:25:59 hugh Exp hugh $ + | $Header: /home/hugh/sources/old_ae/RCS/new_curse.c,v 1.54 2002/09/21 00:47:14 hugh Exp $ | */ char *copyright_message[] = { "Copyright (c) 1986, 1987, 1988, 1991, 1992, 1993, 1994, 1995 Hugh Mahon", "All rights are reserved."}; -#include -__FBSDID("$FreeBSD$"); +char * new_curse_name= "@(#) new_curse.c $Revision: 1.54 $"; #include "new_curse.h" #include @@ -71,7 +70,11 @@ #include #endif +#if defined(__STDC__) #include +#else +#include +#endif #ifdef HAS_UNISTD #include @@ -498,6 +501,10 @@ char *Strings; #endif +#if !defined(TERMCAP) +#define TERMCAP "/etc/termcap" +#endif + struct KEYS { int length; /* length of string sent by key */ char *string; /* string sent by key */ @@ -655,15 +662,39 @@ static char nc_scrolling_ability = FALSE; +char *terminfo_path[] = { + "/usr/lib/terminfo", + "/usr/share/lib/terminfo", + "/usr/share/terminfo", + NULL + }; + #ifdef CAP -int tc_Get_int(int); -void CAP_PARSE(void); -void Find_term(void); +#if defined(__STDC__) || defined(__cplusplus) +#define P_(s) s +#else +#define P_(s) () +#endif /* __STDC__ */ + +int tc_Get_int P_((int)); +void CAP_PARSE P_((void)); +void Find_term P_((void)); + +#undef P_ #endif /* CAP */ +#ifndef __STDC__ +#ifndef HAS_STDLIB +extern char *fgets(); +extern char *malloc(); +extern char *getenv(); +FILE *fopen(); /* declaration for open function */ +#endif /* HAS_STDLIB */ +#endif /* __STDC__ */ + #ifdef SIGWINCH /* @@ -747,6 +778,7 @@ initscr() /* initialize terminal for operations */ { int value; + int counter; char *lines_string; char *columns_string; #ifdef CAP @@ -879,30 +911,26 @@ Term_File_name = malloc(Data_Line_len); sprintf(Term_File_name, "%s/%c/%s", TERM_PATH, *TERMINAL_TYPE, TERMINAL_TYPE); Fildes = open(Term_File_name, O_RDONLY); + if (Fildes == -1) + { + sprintf(Term_File_name, "%s/%x/%s", TERM_PATH, *TERMINAL_TYPE, TERMINAL_TYPE); + Fildes = open(Term_File_name, O_RDONLY); + } } - if (Fildes == -1) - { - TERM_PATH = "/usr/lib/terminfo"; - Data_Line_len = 23 + strlen(TERM_PATH) + strlen(TERMINAL_TYPE); - Term_File_name = malloc(Data_Line_len); - sprintf(Term_File_name, "%s/%c/%s", TERM_PATH, *TERMINAL_TYPE, TERMINAL_TYPE); - Fildes = open(Term_File_name, O_RDONLY); - } - if (Fildes == -1) - { - TERM_PATH = "/usr/share/lib/terminfo"; - Data_Line_len = 23 + strlen(TERM_PATH) + strlen(TERMINAL_TYPE); - Term_File_name = malloc(Data_Line_len); - sprintf(Term_File_name, "%s/%c/%s", TERM_PATH, *TERMINAL_TYPE, TERMINAL_TYPE); - Fildes = open(Term_File_name, O_RDONLY); - } - if (Fildes == -1) + counter = 0; + while ((Fildes == -1) && (terminfo_path[counter] != NULL)) { - TERM_PATH = "/usr/share/terminfo"; + TERM_PATH = terminfo_path[counter]; Data_Line_len = 23 + strlen(TERM_PATH) + strlen(TERMINAL_TYPE); Term_File_name = malloc(Data_Line_len); sprintf(Term_File_name, "%s/%c/%s", TERM_PATH, *TERMINAL_TYPE, TERMINAL_TYPE); Fildes = open(Term_File_name, O_RDONLY); + if (Fildes == -1) + { + sprintf(Term_File_name, "%s/%x/%s", TERM_PATH, *TERMINAL_TYPE, TERMINAL_TYPE); + Fildes = open(Term_File_name, O_RDONLY); + } + counter++; } if (Fildes == -1) { @@ -919,15 +947,15 @@ if ((pointer = Term_File_name = getenv("TERMCAP")) != NULL) { if (*Term_File_name != '/') - Term_File_name = "/etc/termcap"; + Term_File_name = TERMCAP; } else { - Term_File_name = "/etc/termcap"; + Term_File_name = TERMCAP; } if ((TFP = fopen(Term_File_name, "r")) == NULL) { - printf("unable to open /etc/termcap file \n"); + printf("unable to open %s file \n", TERMCAP); exit(0); } for (value = 0; value < 1024; value++) @@ -1340,7 +1368,7 @@ char *Name; char *Ftemp; - Ftemp = Name = malloc(strlen(TERMINAL_TYPE + 1) + 1); + Ftemp = Name = malloc(strlen(TERMINAL_TYPE) + 2); strcpy(Name, TERMINAL_TYPE); while (*Ftemp != (char)NULL) Ftemp++; @@ -1425,7 +1453,6 @@ TERMINAL_TYPE = tc_; rewind(TFP); Find_term(); - free(tc_); tc_ = NULL; CAP_PARSE(); } @@ -1480,12 +1507,17 @@ Ntemp->Attrib = FALSE; Ntemp->first_line = temp_screen = Screenalloc(cols); Ntemp->first_line->number = 0; + Ntemp->line_array = (struct _line **) malloc(LINES * sizeof(struct _line *)); + + Ntemp->line_array[0] = Ntemp->first_line; + for (i = 1; i < lines; i++) { temp_screen->next_screen = Screenalloc(cols); temp_screen->next_screen->number = i; temp_screen->next_screen->prev_screen = temp_screen; temp_screen = temp_screen->next_screen; + Ntemp->line_array[i] = temp_screen; } Ntemp->first_line->prev_screen = NULL; temp_screen->next_screen = NULL; @@ -2010,16 +2042,17 @@ int j; if (column > line->last_char) - line->row[line->last_char] = ' '; + { + for (j = line->last_char; j < column; j++) + { + line->row[j] = ' '; + line->attributes[j] = (char) NULL; + } + } line->last_char = column; line->row[column] = (char) NULL; line->attributes[column] = (char) NULL; line->changed = TRUE; - for (j = column + 1; j < cols; j++) - { - line->row[j] = ' '; - line->attributes[j] = (char) NULL; - } } void @@ -2137,12 +2170,21 @@ { for (user_col = 0, virt_col = window->SC; (virt_col < virtual_scr->Num_cols) - && (user_col < window->Num_cols); + && (user_col < user_line->last_char); virt_col++, user_col++) { virtual_line->row[virt_col] = user_line->row[user_col]; virtual_line->attributes[virt_col] = user_line->attributes[user_col]; } + for (user_col = user_line->last_char, + virt_col = window->SC + user_line->last_char; + (virt_col < virtual_scr->Num_cols) + && (user_col < window->Num_cols); + virt_col++, user_col++) + { + virtual_line->row[virt_col] = ' '; + virtual_line->attributes[virt_col] = (char) NULL; + } } if (virtual_scr->Num_cols != window->Num_cols) { @@ -2154,11 +2196,6 @@ min(virtual_scr->Num_cols, (user_line->last_char + window->SC)); } - else if (virtual_line->last_char > (user_line->last_char + window->SC)) - { - virtual_line->row[min(virtual_scr->Num_cols, - (user_line->last_char + window->SC))] = ' '; - } } else virtual_line->last_char = user_line->last_char; @@ -2214,7 +2251,7 @@ return(-1); } - return(read(STDIN_FILENO, &temp, 1)? temp : -1); + return(read(0, &temp, 1)? temp : -1); } #endif @@ -2232,11 +2269,11 @@ if (Noblock) in_value = ((bufp > 0) ? in_buff[--bufp] : timed_getchar()); else - in_value = ((bufp > 0) ? in_buff[--bufp] : read(STDIN_FILENO, &temp, 1)? temp : -1); + in_value = ((bufp > 0) ? in_buff[--bufp] : read(0, &temp, 1)? temp : -1); #else /* BSD_SELECT */ #ifdef SYS5 in_value = ((bufp > 0) ? in_buff[--bufp] : - (read(STDIN_FILENO, &temp, 1)> 0) ? temp : -1); + (read(0, &temp, 1)> 0) ? temp : -1); #else /* SYS5 */ if (Noblock) { @@ -2244,7 +2281,7 @@ old_arg = fcntl(0, F_GETFL, 0); in_value = fcntl(0, F_SETFL, old_arg | FNDELAY); } - in_value = ((bufp > 0) ? in_buff[--bufp] : read(STDIN_FILENO, &temp, 1)? temp : -1); + in_value = ((bufp > 0) ? in_buff[--bufp] : read(0, &temp, 1)? temp : -1); if (Noblock) { fcntl(0, F_SETFL, old_arg); @@ -2379,14 +2416,13 @@ WINDOW *window; int c; { - int row, column; + int column, j; int shift; /* number of spaces to shift if a tab */ struct _line *tmpline; #ifdef DIAG /*printf("starting waddch \n");fflush(stdout);*/ #endif - row = window->LY; column = window->LX; if (c == '\t') { @@ -2401,27 +2437,25 @@ waddch(window, ' '); } } - else if ((column < window->Num_cols) && (row < window->Num_lines)) + else if ((column < window->Num_cols) && (window->LY < window->Num_lines)) { if ((c == '~') && (Booleans[hz__])) c = '@'; if (( c != '\b') && (c != '\n') && (c != '\r')) { - row = 0; - tmpline = window->first_line; - while (row < window->LY) - { - row++; - tmpline = tmpline->next_screen; - } + tmpline = window->line_array[window->LY]; tmpline->row[column] = c; tmpline->attributes[column] = window->Attrib; tmpline->changed = TRUE; if (column >= tmpline->last_char) { if (column > tmpline->last_char) - tmpline->row[tmpline->last_char] = ' '; + for (j = tmpline->last_char; j < column; j++) + { + tmpline->row[j] = ' '; + tmpline->attributes[j] = (char) NULL; + } tmpline->row[column + 1] = (char) NULL; tmpline->attributes[column + 1] = (char) NULL; tmpline->last_char = column + 1; @@ -2495,6 +2529,13 @@ } if (window->LY == 0) window->first_line = tmp1; + + for (row = 0, tmp1 = window->first_line; + row < window->Num_lines; row++) + { + window->line_array[row] = tmp1; + tmp1 = tmp1->next_screen; + } } void @@ -2538,6 +2579,12 @@ else tmp = tmpline; tmp->next_screen = NULL; + + for (row = 0, tmp = window->first_line; row < window->Num_lines; row++) + { + window->line_array[row] = tmp; + tmp = tmp->next_screen; + } } else { @@ -2648,7 +2695,7 @@ Terminal.c_lflag &= ~IEXTEN; #endif Terminal.c_cc[VMIN] = 1; /* minimum of one character */ - Terminal.c_cc[VTIME] = 255; /* timeout value */ + Terminal.c_cc[VTIME] = 0; /* timeout value */ Terminal.c_cc[VINTR] = 0; /* eliminate interrupt */ value = ioctl(0, TCSETA, &Terminal); /* set characteristics */ #else @@ -2805,15 +2852,33 @@ } } +#ifndef __STDC__ +void +wprintw(va_alist) +va_dcl +#else /* __STDC__ */ void wprintw(WINDOW *window, const char *format, ...) +#endif /* __STDC__ */ { +#ifndef __STDC__ + WINDOW *window; + char *format; + va_list ap; +#else va_list ap; +#endif int value; char *fpoint; char *wtemp; +#ifndef __STDC__ + va_start(ap); + window = va_arg(ap, WINDOW *); + format = va_arg(ap, char *); +#else /* __STDC__ */ va_start(ap, format); +#endif /* __STDC__ */ fpoint = (char *) format; while (*fpoint != (char) NULL) @@ -2858,7 +2923,9 @@ else waddch(window, *fpoint++); } +#ifdef __STDC__ va_end(ap); +#endif /* __STDC__ */ } void @@ -2878,35 +2945,28 @@ struct _line *line1; struct _line *line2; { - int count1, count2; + int count1; int i; char *att1, *att2; char *c1, *c2; + if (line1->last_char != line2->last_char) + return(2); + c1 = line1->row; c2 = line2->row; att1 = line1->attributes; att2 = line2->attributes; - count2 = strlen(c1) + 1; - count1 = strlen(c2) + 1; - if (count1 > count2) - { - i = count2; - count2 = count1; - count1 = i; - } - if (count2 > (count1 + count1)) - return(2); i = 0; while ((c1[i] != (char) NULL) && (c2[i] != (char) NULL) && (c1[i] == c2[i]) && (att1[i] == att2[i])) i++; count1 = i + 1; - if ((count1 == 1) && (count2 == 1)) + if ((count1 == 1) && (c1[i] == (char) NULL) && (c2[i] == (char) NULL)) count1 = 0; /* both lines blank */ - else if (count2 == count1) + else if ((c1[i] == (char) NULL) && (c2[i] == (char) NULL)) count1 = -1; /* equal */ else - count1 = count2 / count1; /* lines unequal */ + count1 = 1; /* lines unequal */ return(count1); } @@ -3212,6 +3272,7 @@ int first_same; int last_same; int list[10]; + int bottom; struct _line *curr; struct _line *virt; @@ -3219,6 +3280,8 @@ struct _line *new; + struct _line *old1, *new1; + char *cur_lin; char *vrt_lin; char *cur_att; @@ -3302,7 +3365,6 @@ (first_same > from_top) && (virtual_lines[first_same - 1]); first_same--) ; - count1 = first_same - 1; for (last_same = 0; (last_same < window->Num_lines) && (virtual_lines[last_same]== FALSE); last_same++) @@ -3311,7 +3373,6 @@ /* check entire lines for diffs */ { - if (from_top >= last_same) { for (last_same = from_top; @@ -3334,39 +3395,55 @@ { if ((Comp_line(old, virt) == -1) && (!virtual_lines[from_top])) { - if (String_table[cs__]) /* scrolling region */ + /* + | Find the bottom of the + | area that should be + | scrolled. + */ + for (bottom = tmp_ft, old1 = old, + new1 = virt, count1 = 0; + (bottom < window->Num_lines) && + (Comp_line(old1, new1) <= 0); + bottom++, old1 = old1->next_screen, + new1 = new1->next_screen, + count1++) + ; + if (count1 > 3) { - list[1] = from_top; - list[0] = min((last_same - 1), (window->Num_lines - 1)); - String_Out(String_table[cs__], list, 2); - Curr_y = Curr_x = -1; - } + if (String_table[cs__]) /* scrolling region */ + { + list[1] = from_top; + list[0] = min((bottom - 1), (window->Num_lines - 1)); + String_Out(String_table[cs__], list, 2); + Curr_y = Curr_x = -1; + } - for (offset = (tmp_ft - from_top); (offset > 0); offset--) - { - old = Delete_line(from_top, min((last_same - 1), (window->Num_lines - 1)), window); - diff = FALSE; - } + for (offset = (tmp_ft - from_top); (offset > 0); offset--) + { + old = Delete_line(from_top, min((bottom - 1), (window->Num_lines - 1)), window); + diff = FALSE; + } - if (String_table[cs__]) /* scrolling region */ - { - list[1] = 0; - list[0] = LINES - 1; - String_Out(String_table[cs__], list, 2); - Curr_y = Curr_x = -1; + if (String_table[cs__]) /* scrolling region */ + { + list[1] = 0; + list[0] = LINES - 1; + String_Out(String_table[cs__], list, 2); + Curr_y = Curr_x = -1; } - top_of_win = curscr->first_line; - curr = top_of_win; - for (offset = 0; offset < from_top; offset++) - curr = curr->next_screen; - for (offset = from_top, old=curr, new=virt; - offset < window->Num_lines; - old=old->next_screen, new=new->next_screen, - offset++) - { - similar = Comp_line(old, new); - virtual_lines[offset] = (similar > 0 ? FALSE : TRUE); + top_of_win = curscr->first_line; + curr = top_of_win; + for (offset = 0; offset < from_top; offset++) + curr = curr->next_screen; + for (offset = from_top, old=curr, new=virt; + offset < window->Num_lines; + old=old->next_screen, new=new->next_screen, + offset++) + { + similar = Comp_line(old, new); + virtual_lines[offset] = (similar > 0 ? FALSE : TRUE); + } } } else @@ -3383,39 +3460,55 @@ { if (Comp_line(old, virt) == -1) { - if (String_table[cs__]) /* scrolling region */ + /* + | Find the bottom of the + | area that should be + | scrolled. + */ + for (bottom = from_top, old1 = old, + new1 = virt, count1 = 0; + (bottom < window->Num_lines) && + (Comp_line(old1, new1) <= 0); + bottom++, old1 = old1->next_screen, + new1 = new1->next_screen, + count1++) + ; + if (count1 > 3) { - list[1] = tmp_ft; - list[0] = min((last_same - 1), (window->Num_lines - 1)); - String_Out(String_table[cs__], list, 2); - Curr_y = Curr_x = -1; - } + if (String_table[cs__]) /* scrolling region */ + { + list[1] = tmp_ft; + list[0] = min((bottom - 1), (window->Num_lines - 1)); + String_Out(String_table[cs__], list, 2); + Curr_y = Curr_x = -1; + } - for (offset = (from_top - tmp_ft); (offset > 0); offset--) - { - old = Insert_line(tmp_ft, min((last_same - 1), (window->Num_lines -1)), window); - diff = FALSE; - } + for (offset = (from_top - tmp_ft); (offset > 0); offset--) + { + old = Insert_line(tmp_ft, min((bottom - 1), (window->Num_lines -1)), window); + diff = FALSE; + } - if (String_table[cs__]) /* scrolling region */ - { - list[1] = 0; - list[0] = LINES - 1; - String_Out(String_table[cs__], list, 2); - Curr_y = Curr_x = -1; - } + if (String_table[cs__]) /* scrolling region */ + { + list[1] = 0; + list[0] = LINES - 1; + String_Out(String_table[cs__], list, 2); + Curr_y = Curr_x = -1; + } - top_of_win = curscr->first_line; - curr = top_of_win; - for (offset = 0; offset < from_top; offset++) - curr = curr->next_screen; - for (offset = from_top, old=curr, new=virt; - offset < window->Num_lines; - old=old->next_screen, new=new->next_screen, - offset++) - { - similar = Comp_line(old, new); - virtual_lines[offset] = (similar > 0 ? FALSE : TRUE); + top_of_win = curscr->first_line; + curr = top_of_win; + for (offset = 0; offset < from_top; offset++) + curr = curr->next_screen; + for (offset = from_top, old=curr, new=virt; + offset < window->Num_lines; + old=old->next_screen, new=new->next_screen, + offset++) + { + similar = Comp_line(old, new); + virtual_lines[offset] = (similar > 0 ? FALSE : TRUE); + } } } else diff -u ee/new_curse.h easyedit/new_curse.h --- ee/new_curse.h 2009-01-09 15:52:22.000000000 -0500 +++ easyedit/new_curse.h 1997-05-02 23:57:42.000000000 -0400 @@ -37,8 +37,6 @@ | Copyright (c) 1986, 1987, 1988, 1991, 1995 Hugh Mahon | All are rights reserved. | - | $FreeBSD$ - | */ #include @@ -178,6 +176,7 @@ int scroll_down; int SCROLL_CLEAR; /* indicates that window has been scrolled or cleared */ struct _line *first_line; + struct _line **line_array; } WINDOW; extern WINDOW *curscr; @@ -185,7 +184,7 @@ extern int LINES, COLS; -#if __STDC__ || defined(__cplusplus) +#if defined(__STDC__) || defined(__cplusplus) #define P_(s) s #else #define P_(s) () Common subdirectories: ee/nls and easyedit/nls -------------- next part -------------- /* | provide a version number for ee */ #define EE_VERSION "1.4.6" #define DATE_STRING "$Date: 2002/09/21 00:50:54 $" From aryeh.friedman at gmail.com Sat Jan 10 02:18:04 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Sat Jan 10 02:18:11 2009 Subject: support for i45 (ich10) chipsets Message-ID: <4967FE4C.2050301@gmail.com> I just got a i45 based motherboard and everything works except for the following pci: none2@pci0:1:0:0: class=0x020000 card=0x83671043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet does -current support it or should I stay with 7.1-RELEASE ? (i386) From Danovitsch at vitsch.net Sat Jan 10 00:00:00 2009 From: Danovitsch at vitsch.net (Daan Vreeken [PA4DAN]) Date: Sat Jan 10 04:21:17 2009 Subject: 3x read to write ratio on dump/restore In-Reply-To: <20090109.095027.-1672857892.imp@bsdimp.com> References: <20090109.095027.-1672857892.imp@bsdimp.com> Message-ID: <200901100059.48906.Danovitsch@vitsch.net> Hi Warner, On Friday 09 January 2009 17:50:27 M. Warner Losh wrote: > I just copied a disk using dump + restore. I noticed something > through the whole run of this 500GB operation: > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 3 231 231 14754 9.5 0 0 0.0 97.5| da1s1a > 0 39 0 0 0.0 39 4982 10.0 38.7| da2s1a > > The read kBps was 3x the write kBps. While the dump is going through > the raw device, and the restore is going through the file system, I > can't imagine why we'd have such a huge difference that would be utter > consistent for the whole 15 hour run. > > Any ideas what gives? I observed this with 16MB cache and with 32MB > cache, fwiw. I've noticed this too. Last week I upgraded a laptop harddisk and used dump + restore to copy files from the original harddisk (attached to the laptop using a USB bracket). During the entire copy process I also saw about a 3x difference. -- Daan From perryh at pluto.rain.com Sat Jan 10 12:20:50 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sat Jan 10 12:21:04 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <20090109201201.GA1538@roadrunner.spoerlein.net> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109201201.GA1538@roadrunner.spoerlein.net> Message-ID: <49689250.ShPX42arkUMbD6aD%perryh@pluto.rain.com> Ulrich Spoerlein wrote: > On Thu, 08.01.2009 at 21:50:47 -0800, perryh@pluto.rain.com wrote: > > Ulrich Spoerlein wrote: > > Ummm, out of curiosity, are your receiving your mail via UUCP? :) http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020645.html From perryh at pluto.rain.com Sat Jan 10 12:20:50 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sat Jan 10 12:21:05 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <20090109204014.GA83381@keira.kiwi-computer.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> Message-ID: <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> "Rick C. Petty" wrote: > On Thu, Jan 08, 2009 at 09:50:47PM -0800, perryh@pluto.rain.com wrote: > > > In principle, everything that would be successfully created if > > open(2)'ed. It doesn't necessarily need to actually create them, > > but the results from readdir(2) should be as if they had been > > created. The whole point of things like ls(1) and readdir(2) is > > to find out what-all is available to be opened, without having to > > already know the answer. > > That's not how devfs works. It's actually a feature > that devfs doesn't list everything ever possible http://storage9.myopera.com/freejerk/files/bug-feature.jpg > (things looked terrible back in the old MAKEDEV days with > all those polluted names). Yes, MAKEDEV can create the opposite problem, wherein /dev contains nodes for devices whose drivers and/or hardware aren't present. Such orphan nodes aren't a whole lot better than missing nodes. > I'd rather be able to list to see things that are in use, although > at first glance I didn't like devfs hidden nodes. Otherwise you'd > be stuck printing tunXXX through infinity instead of this: > > % ls /dev/tun* > /dev/tun0 /dev/tun115 /dev/tun194 In any other part of the directory tree we expect ls to provide a list of names that are available to be opened (subject to permissions). Why should /dev be any different? Since you aren't supposed to open (say) /dev/tun85, but only /dev/tun0, correspondence between readdir and open would not demand that readdir return the (large, if not infinite) list of potential instances. It would however seem reasonable for that ls command to show /dev/tun0 if its driver is loaded, even if the device has not been instantiated because the node has never been opened. > This is not a bug, it is designed behavior. It was intentionally > written to dynamically create device nodes when needed. That the code faithfully adheres to the design does not guarantee that the design is flawless. IMO it violates POLA, if not POSIX, for open(2) to succeed when applied to a name which, according to readdir(2), does not exist; and it is suboptimal to have "stealth" drivers whose availability for use cannot be discovered by examining /dev. From aryeh.friedman at gmail.com Sat Jan 10 15:23:33 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Sat Jan 10 15:23:40 2009 Subject: support for i45 (ich10) chipsets In-Reply-To: <367b2c980901100718s12a3d6balcf5fbf2ecde24bf2@mail.gmail.com> References: <4967FE4C.2050301@gmail.com> <367b2c980901100718s12a3d6balcf5fbf2ecde24bf2@mail.gmail.com> Message-ID: <4968BD72.50306@gmail.com> Olivier SMEDTS wrote: > Hello, > > 2009/1/10 Aryeh M. Friedman : > >> I just got a i45 based motherboard and everything works except for the >> following pci: >> >> none2@pci0:1:0:0: class=0x020000 card=0x83671043 chip=0x816810ec >> rev=0x02 hdr=0x00 >> vendor = 'Realtek Semiconductor' >> device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' >> class = network >> subclass = ethernet >> > > This does not seem to be related to the Intel ICH10 chipsets. This > must be a second network adapter on your motherboard. For information, > my ASUS P5Q3 (Intel ICH10 too) works very well, everything is > detected. The two network controllers are a "88E8056 Yukon PCI-E > Same motherboard > Gigabit Ethernet Controller" (if_msk driver) and a "Yukon > 88E8001/8003/8010 PCI Gigabit Ethernet Controller (Copper)" (if_sk > driver). > Is your watchdog detected (ichwd driver) ? > I'm also using the ichsmb driver without issues. > > See the following thread on freebsd-questions : > http://lists.freebsd.org/pipermail/freebsd-questions/2008-November/187147.html > > According to it, RTL8168/8111 should work with 7.1-RELEASE. Are you > using the if_re driver ? Try loading the if_re.ko module, as I think > it's not in the GENERIC kernel. > I am used to current where it is in GENERIC so will add it to my config I guess > Cheers > > >> does -current support it or should I stay with 7.1-RELEASE ? (i386) >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >> > > From olivier at gid0.org Sat Jan 10 15:40:00 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Sat Jan 10 15:40:07 2009 Subject: support for i45 (ich10) chipsets In-Reply-To: <4968BD72.50306@gmail.com> References: <4967FE4C.2050301@gmail.com> <367b2c980901100718s12a3d6balcf5fbf2ecde24bf2@mail.gmail.com> <4968BD72.50306@gmail.com> Message-ID: <367b2c980901100739v2127adb6u8950ffa0efc032de@mail.gmail.com> 2009/1/10 Aryeh M. Friedman : > Olivier SMEDTS wrote: >> Hello, >> >> 2009/1/10 Aryeh M. Friedman : >> >>> I just got a i45 based motherboard and everything works except for the >>> following pci: >>> >>> none2@pci0:1:0:0: class=0x020000 card=0x83671043 chip=0x816810ec >>> rev=0x02 hdr=0x00 >>> vendor = 'Realtek Semiconductor' >>> device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' >>> class = network >>> subclass = ethernet >>> >> >> This does not seem to be related to the Intel ICH10 chipsets. This >> must be a second network adapter on your motherboard. For information, >> my ASUS P5Q3 (Intel ICH10 too) works very well, everything is >> detected. The two network controllers are a "88E8056 Yukon PCI-E >> > > Same motherboard ASUS P5Q3 or P5Q3 Deluxe ? I've got the Deluxe one, maybe the ethernet controllers are different. The only thing not working on mine is the integrated 802.11n wireless controller. It's a Ralink chipset (don't remember which one) attached to the USB bus. There's a linux driver available. >> Gigabit Ethernet Controller" (if_msk driver) and a "Yukon >> 88E8001/8003/8010 PCI Gigabit Ethernet Controller (Copper)" (if_sk >> driver). >> Is your watchdog detected (ichwd driver) ? >> I'm also using the ichsmb driver without issues. >> >> See the following thread on freebsd-questions : >> http://lists.freebsd.org/pipermail/freebsd-questions/2008-November/187147.html >> >> According to it, RTL8168/8111 should work with 7.1-RELEASE. Are you >> using the if_re driver ? Try loading the if_re.ko module, as I think >> it's not in the GENERIC kernel. >> > > I am used to current where it is in GENERIC so will add it to my config > I guess >> Cheers >> >> >>> does -current support it or should I stay with 7.1-RELEASE ? (i386) >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> >>> >> >> > > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From olivier at gid0.org Sat Jan 10 15:43:04 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Sat Jan 10 15:43:10 2009 Subject: support for i45 (ich10) chipsets In-Reply-To: <4967FE4C.2050301@gmail.com> References: <4967FE4C.2050301@gmail.com> Message-ID: <367b2c980901100718s12a3d6balcf5fbf2ecde24bf2@mail.gmail.com> Hello, 2009/1/10 Aryeh M. Friedman : > I just got a i45 based motherboard and everything works except for the > following pci: > > none2@pci0:1:0:0: class=0x020000 card=0x83671043 chip=0x816810ec > rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet This does not seem to be related to the Intel ICH10 chipsets. This must be a second network adapter on your motherboard. For information, my ASUS P5Q3 (Intel ICH10 too) works very well, everything is detected. The two network controllers are a "88E8056 Yukon PCI-E Gigabit Ethernet Controller" (if_msk driver) and a "Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller (Copper)" (if_sk driver). Is your watchdog detected (ichwd driver) ? I'm also using the ichsmb driver without issues. See the following thread on freebsd-questions : http://lists.freebsd.org/pipermail/freebsd-questions/2008-November/187147.html According to it, RTL8168/8111 should work with 7.1-RELEASE. Are you using the if_re driver ? Try loading the if_re.ko module, as I think it's not in the GENERIC kernel. Cheers > > does -current support it or should I stay with 7.1-RELEASE ? (i386) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From aryeh.friedman at gmail.com Sat Jan 10 15:54:34 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Sat Jan 10 15:54:41 2009 Subject: support for i45 (ich10) chipsets In-Reply-To: <367b2c980901100739v2127adb6u8950ffa0efc032de@mail.gmail.com> References: <4967FE4C.2050301@gmail.com> <367b2c980901100718s12a3d6balcf5fbf2ecde24bf2@mail.gmail.com> <4968BD72.50306@gmail.com> <367b2c980901100739v2127adb6u8950ffa0efc032de@mail.gmail.com> Message-ID: <4968C4B6.3040203@gmail.com> Olivier SMEDTS wrote: > 2009/1/10 Aryeh M. Friedman : > >> Olivier SMEDTS wrote: >> >>> Hello, >>> >>> 2009/1/10 Aryeh M. Friedman : >>> >>> >>>> I just got a i45 based motherboard and everything works except for the >>>> following pci: >>>> >>>> none2@pci0:1:0:0: class=0x020000 card=0x83671043 chip=0x816810ec >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Realtek Semiconductor' >>>> device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' >>>> class = network >>>> subclass = ethernet >>>> >>>> >>> This does not seem to be related to the Intel ICH10 chipsets. This >>> must be a second network adapter on your motherboard. For information, >>> my ASUS P5Q3 (Intel ICH10 too) works very well, everything is >>> detected. The two network controllers are a "88E8056 Yukon PCI-E >>> >>> >> Same motherboard >> > > ASUS P5Q3 or P5Q3 Deluxe ? I've got the Deluxe one, maybe the ethernet > controllers are different. The only thing not working on mine is the > integrated 802.11n wireless controller. It's a Ralink chipset (don't > remember which one) attached to the USB bus. There's a linux driver > available. > I assume deluxe but I do not have access to the machine physically right now but it was bought earlier this week and my boss asked if I wanted deluxe or not (he bought it) > >>> Gigabit Ethernet Controller" (if_msk driver) and a "Yukon >>> 88E8001/8003/8010 PCI Gigabit Ethernet Controller (Copper)" (if_sk >>> driver). >>> Is your watchdog detected (ichwd driver) ? >>> I'm also using the ichsmb driver without issues. >>> >>> See the following thread on freebsd-questions : >>> http://lists.freebsd.org/pipermail/freebsd-questions/2008-November/187147.html >>> >>> According to it, RTL8168/8111 should work with 7.1-RELEASE. Are you >>> using the if_re driver ? Try loading the if_re.ko module, as I think >>> it's not in the GENERIC kernel. >>> >>> >> I am used to current where it is in GENERIC so will add it to my config >> I guess >> I guess not: # kldstat Id Refs Address Size Name 1 3 0xc0400000 94f054 kernel 2 1 0xc0d50000 68304 acpi.ko # kldload if_re kldload: can't load if_re: File exists in the config (unmodified except setting IPI_PREMPTION): device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device re # RealTek 8139C+/8169/8169S/8110S >>> Cheers >>> >>> >>> >>>> does -current support it or should I stay with 7.1-RELEASE ? (i386) >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>>> >>>> >>>> >>> >> > > > > From uspoerlein at gmail.com Sat Jan 10 10:51:43 2009 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Sat Jan 10 10:51:51 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> Message-ID: <20090110185135.GB83079@roadrunner.spoerlein.net> I cannot really comment on the devfs(4) design issues, and quite frankly it hasn't bothered my thus far. Just another little quirk you get to remember. On Sat, 10.01.2009 at 04:20:58 -0800, perryh@pluto.rain.com wrote: > That the code faithfully adheres to the design does not guarantee > that the design is flawless. IMO it violates POLA, if not POSIX, > for open(2) to succeed when applied to a name which, according to > readdir(2), does not exist; and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. You forgot directories with --x permissions. You can open many files inside them, but readdir(2) will get you nowhere. So this is a poor standard by which to judge devfs(4) device cloning. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From kientzle at freebsd.org Sat Jan 10 11:00:40 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sat Jan 10 11:01:15 2009 Subject: Small change to 'ps' In-Reply-To: <20090109015106.3614a378@mbook.local> References: <20090107125759.GA1462@roadrunner.spoerlein.net> <20090107154854.GC1462@roadrunner.spoerlein.net> <20090109015106.3614a378@mbook.local> Message-ID: <4968F055.8060001@freebsd.org> Mike Meyer wrote: > How about borrowing from existing commands that > already implement this functionality (zfs and zpool) and using `-H', > which is relatively rarely used elsewhere? Every BSD command that walks a filesystem supports -L, -P, and -H with consistent semantics: -L Logical traversal (follow all symlinks) -P Physical traversal (follow no symlinks) -H Hybrid traversal (follow symlinks given on command line) Tim From Alexander at Leidinger.net Sat Jan 10 12:27:07 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Jan 10 13:28:06 2009 Subject: bringing ee up to date In-Reply-To: <4967BBB5.3030703@gmail.com> References: <4967BBB5.3030703@gmail.com> Message-ID: <20090110211051.31066z47fw0zw7k8@webmail.leidinger.net> Quoting Eitan Adler (from Fri, 09 Jan 2009 16:03:49 -0500): > I think that these three files bring ee up to date from 1.4.2 to 1.4.6. Sorry, but the patch as is is wrong fore sure. I've seen "lp" instead of "lpr", and even at least one wrong path. For other paths I would have to check to say something definitive. A little bit more work is needed to get an update of this into FreeBSD. How did you proceeded to have a look at the update? Here's how I would do it: 1) diff the version we have with the same version of the vendor + in case of a difference the functionaility needs to be forward ported 2) diff the vendor src of the version of what we have with the next version after it 3) add the differences to our version taking 1) into account and taking care if some path which may be in the new version is OK for us 3.5) if in doubt, ask here, together with a description of what is changed / improved / new 4) repeat from 2) until the most recent version is reached Bye, Alexander. -- LEVERAGE: Even if someone doesn't care what the world thinks about them, they always hope their mother doesn't find out. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From kientzle at freebsd.org Sat Jan 10 14:51:08 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sat Jan 10 14:51:15 2009 Subject: extattr problems? Message-ID: <49692659.2030306@freebsd.org> FreeBSD 6.3: fd = open("test", O_WRONLY | O_CREAT | O_EXCL, 0777); n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4); After this, fd=3, n is non-zero, errno = 9 (EBADF) Huh? I would have expected EOPNOTSUPP if extended attributes weren't supported on this filesystem. The file descriptor is clearly valid. Tim From perryh at pluto.rain.com Sat Jan 10 16:13:58 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sat Jan 10 16:14:06 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <20090110185135.GB83079@roadrunner.spoerlein.net> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> <20090110185135.GB83079@roadrunner.spoerlein.net> Message-ID: <49693902.0x2OQspLPLnuQLwg%perryh@pluto.rain.com> Ulrich Spoerlein wrote: > I cannot really comment on the devfs(4) design issues, > and quite frankly it hasn't bothered my thus far. It evidently inconvenienced the OP. > Just another little quirk you get to remember. If we followed that line of reasoning to its logical conclusion we would eliminate POLA entirely. > > IMO it violates POLA, if not POSIX, for open(2) to succeed when > > applied to a name which, according to readdir(2), does not > > exist; and it is suboptimal to have "stealth" drivers whose > > availability for use cannot be discovered by examining /dev. > > You forgot directories with --x permissions. You can open many > files inside them, but readdir(2) will get you nowhere. So this > is a poor standard by which to judge devfs(4) device cloning. There are at least two problems with that analysis: * /dev does not ordinarily have --x permissions. Even if I amended the principle to allow for that case, it would not affect its application to this case. * readdir works for root, even in directories with --x permissions. For example: $ mkdir test $ touch test/file $ ls -la test total 4 drwxr-xr-x 2 perryh perryh 512 Jan 10 15:39 . drwxr-xr-x 3 perryh perryh 512 Jan 10 15:39 .. -rw-r--r-- 1 perryh perryh 0 Jan 10 15:39 file $ chmod 111 test $ ls -ld test d--x--x--x 2 perryh perryh 512 Jan 10 15:39 test $ ls -la test total 0 ls: test: Permission denied # ls -la test total 4 d--x--x--x 2 perryh perryh 512 Jan 10 15:39 . drwxr-xr-x 3 perryh perryh 512 Jan 10 15:39 .. -rw-r--r-- 1 perryh perryh 0 Jan 10 15:39 file From pluknet at gmail.com Sat Jan 10 18:37:01 2009 From: pluknet at gmail.com (pluknet) Date: Sat Jan 10 18:37:08 2009 Subject: extattr problems? In-Reply-To: <49692659.2030306@freebsd.org> References: <49692659.2030306@freebsd.org> Message-ID: 2009/1/11 Tim Kientzle : > FreeBSD 6.3: > > fd = open("test", O_WRONLY | O_CREAT | O_EXCL, 0777); > n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4); > > After this, fd=3, n is non-zero, errno = 9 (EBADF) > > Huh? I would have expected EOPNOTSUPP if > extended attributes weren't supported on this > filesystem. The file descriptor is clearly > valid. Simple guess. Don't hit me if I'm wrong. :) You call open() with (O_CREAT | O_EXCL) on an already existing file. If such then open() returns -1 with EEXIST and subsequent extattr_set_fd() call with fd (-1) returns EBADF from getvnode() on failed (td->td_proc->p_fd == NULL) or (fp = fdp->fd_ofiles[fd]) == NULL) checks. > > Tim -- wbr, pluknet From kientzle at freebsd.org Sat Jan 10 19:48:55 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sat Jan 10 19:49:01 2009 Subject: extattr problems? In-Reply-To: References: <49692659.2030306@freebsd.org> Message-ID: <49696C24.8010601@freebsd.org> pluknet wrote: > 2009/1/11 Tim Kientzle : > >>FreeBSD 6.3: >> >>fd = open("test", O_WRONLY | O_CREAT | O_EXCL, 0777); >>n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4); >> >>After this, fd=3, n is non-zero, errno = 9 (EBADF) >> >>Huh? I would have expected EOPNOTSUPP if >>extended attributes weren't supported on this >>filesystem. The file descriptor is clearly >>valid. > > Simple guess. > Don't hit me if I'm wrong. :) > > You call open() with (O_CREAT | O_EXCL) on an already existing file. Nope. As you can see from my earlier summary, fd=3 immediately after this, so the open did succeed normally. Oh, but that gives me an idea ... ... darn. Still no joy. I tried changing the open to open("test", O_RDWR | O_CREATE, 0777) and it still fails in exactly the same way. The open still succeeds and the extattr_set_fd() still fails with a nonsensical errno value. Time to dig through kernel sources.... Tim From pyunyh at gmail.com Sat Jan 10 19:50:57 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Jan 10 19:51:03 2009 Subject: support for i45 (ich10) chipsets In-Reply-To: <4967FE4C.2050301@gmail.com> References: <4967FE4C.2050301@gmail.com> Message-ID: <20090111032243.GC42714@cdnetworks.co.kr> On Fri, Jan 09, 2009 at 08:47:56PM -0500, Aryeh M. Friedman wrote: > I just got a i45 based motherboard and everything works except for the > following pci: > > none2@pci0:1:0:0: class=0x020000 card=0x83671043 chip=0x816810ec > rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > > does -current support it or should I stay with 7.1-RELEASE ? (i386) If re(4) didn't serve the controller, re(4) might have printed some informational messages to console. So would you show me the dmesg output? BTW, I think stable@ would be appropriate list for this kind of issue. -- Regards, Pyun YongHyeon From imp at bsdimp.com Sat Jan 10 21:05:24 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Jan 10 21:05:31 2009 Subject: 3x read to write ratio on dump/restore In-Reply-To: <20090111041710.GB5661@server.vk2pj.dyndns.org> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> Message-ID: <20090110.220322.2008390173.imp@bsdimp.com> In message: <20090111041710.GB5661@server.vk2pj.dyndns.org> Peter Jeremy writes: : On 2009-Jan-09 09:50:27 -0700, "M. Warner Losh" wrote: : >The read kBps was 3x the write kBps. : ... : >Any ideas what gives? I observed this with 16MB cache and with 32MB : >cache, fwiw. : : I've seen this as well. AFAIK, this is a side-effect of dump's caching. : : My top-of-head explanation is that each dump process has its own cache : but actual I/O is round-robined on a (roughly) block scale so a large : contiguous file will wind up in each 'slave' process's cache. : : The most obvious (and easiest) fixes are to either implement a shared : cache (though this means another level of inter-process communication) : or only use a single 'slave' process when caching is enabled. I'll have to look into this... Most of the files I was backing up were large contiguous files (26 10GiB .dv files from my camera). : The cache algorithm could probably be enhanced as well - apart from : inode blocks, any block will only be accessed once so once a block has : been accessed, it can be purged from the cache (which is completely : opposite to a "normal" cache). Yes, read everything, purge once it is touched. Warner From peterjeremy at optushome.com.au Sat Jan 10 23:12:21 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat Jan 10 23:12:28 2009 Subject: 3x read to write ratio on dump/restore In-Reply-To: <20090109.095027.-1672857892.imp@bsdimp.com> References: <20090109.095027.-1672857892.imp@bsdimp.com> Message-ID: <20090111041710.GB5661@server.vk2pj.dyndns.org> On 2009-Jan-09 09:50:27 -0700, "M. Warner Losh" wrote: >The read kBps was 3x the write kBps. ... >Any ideas what gives? I observed this with 16MB cache and with 32MB >cache, fwiw. I've seen this as well. AFAIK, this is a side-effect of dump's caching. My top-of-head explanation is that each dump process has its own cache but actual I/O is round-robined on a (roughly) block scale so a large contiguous file will wind up in each 'slave' process's cache. The most obvious (and easiest) fixes are to either implement a shared cache (though this means another level of inter-process communication) or only use a single 'slave' process when caching is enabled. The cache algorithm could probably be enhanced as well - apart from inode blocks, any block will only be accessed once so once a block has been accessed, it can be purged from the cache (which is completely opposite to a "normal" cache). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090111/c5457fe8/attachment.pgp From pluknet at gmail.com Sun Jan 11 00:04:47 2009 From: pluknet at gmail.com (pluknet) Date: Sun Jan 11 00:04:54 2009 Subject: extattr problems? In-Reply-To: <49696C24.8010601@freebsd.org> References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> Message-ID: 2009/1/11 Tim Kientzle : > pluknet wrote: >> >> 2009/1/11 Tim Kientzle : >> >>> FreeBSD 6.3: >>> >>> fd = open("test", O_WRONLY | O_CREAT | O_EXCL, 0777); >>> n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4); >>> >>> After this, fd=3, n is non-zero, errno = 9 (EBADF) >>> >>> Huh? I would have expected EOPNOTSUPP if >>> extended attributes weren't supported on this >>> filesystem. The file descriptor is clearly >>> valid. >> >> Simple guess. >> Don't hit me if I'm wrong. :) >> >> You call open() with (O_CREAT | O_EXCL) on an already existing file. > > Nope. As you can see from my earlier summary, > fd=3 immediately after this, so the open did > succeed normally. Ah, I'm sorry. My inadvertency. > > Oh, but that gives me an idea ... > ... darn. Still no joy. I tried changing the open to > open("test", O_RDWR | O_CREATE, 0777) and it still > fails in exactly the same way. The open still succeeds > and the extattr_set_fd() still fails with a nonsensical > errno value. It's strange.. FreeBSD jaw.ripn.net 6.3-RELEASE-p5. works for me (tm), extattr_set_fd() returns 4 as expected. Also works on 7.1 at home. > > Time to dig through kernel sources.... > > Tim > -- wbr, pluknet From peterjeremy at optushome.com.au Sun Jan 11 00:33:04 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun Jan 11 00:33:17 2009 Subject: kernel panic In-Reply-To: <468090.72533.qm@web45413.mail.sp1.yahoo.com> References: <468090.72533.qm@web45413.mail.sp1.yahoo.com> Message-ID: <20090111083300.GC7054@server.vk2pj.dyndns.org> On 2009-Jan-09 00:05:47 -0800, Kamlesh Patel wrote: >How do i recover the system from this error. I can't reload the loader.old If you press any key during the first spinner, you should get a prompt similar to the following: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: You can then enter the name of the program you wish to run - eg /boot/loader.old (or directly load /boot/kernel/kernel) See the following for a more complete description: http://www.freebsd.org/cgi/man.cgi?query=boot&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090111/0341dace/attachment.pgp From kostikbel at gmail.com Sun Jan 11 07:59:05 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Jan 11 07:59:14 2009 Subject: kernel dump with 7.1-RELEASE In-Reply-To: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> References: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> Message-ID: <20090111155854.GS93900@deviant.kiev.zoral.com.ua> On Fri, Jan 09, 2009 at 06:39:53PM +0200, Omer Faruk Sen wrote: > Hi, > > I am having kernel dump with FreeBSD 7.1: > > Here is crashinfo output of it (Actually i don't know the state of > crashinfo in Fbsd 7.1) > > 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > > > panic: semexit - semid not allocated > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > Physical memory: 8173 MB > Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230 > 214 198 182 166 150 134 118 102 86 70 54 38 22 6 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:195 > #1 0x0000000000000004 in ?? () > #2 0xffffffff804b4ce9 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:418 > #3 0xffffffff804b50f2 in panic (fmt=0x104
) > at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff804f846d in semexit_myhook (arg=Variable "arg" is not available. > ) > at /usr/src/sys/kern/sysv_sem.c:1328 > #5 0xffffffff80490dbc in exit1 (td=0xffffff000995f370, rv=0) > at /usr/src/sys/kern/kern_exit.c:244 > #6 0xffffffff8049239e in sys_exit (td=Variable "td" is not available. > ) at /usr/src/sys/kern/kern_exit.c:109 > #7 0xffffffff8078a7c7 in syscall (frame=0xffffffffb0d4ac80) > at /usr/src/sys/amd64/amd64/trap.c:907 > #8 0xffffffff8077088b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:330 > #9 0x0000000800a2a30c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) It seems that there are at least two issues with IPC_RMID operation on SysV semaphores. 1. The squeeze of the semaphore array in the kern_semctl() modifies sem_base for the semaphores, as well as the values of the semaphores, without locking their mutex. This can lead to (killable) hangs or unexpected behaviour of the processes performing any sem operations while other process does IPC_RMID. 2. The semexit_myhook() eventhandler does not lock SEMUNDO_LOCK() while accessing *suptr. I think that this allows for IPC_RMID to be performed in parallel with the sem id referenced by the current undo structure. Patch below is the backport of the patch I developed and lightly tested on CURRENT, that shuffle locking to solve the listed issues. Testing consisted of running several instances of tools/regression/sysvsem. diff --git a/sys/kern/sysv_sem.c b/sys/kern/sysv_sem.c index 80d07ba..6bc4cce 100644 --- a/sys/kern/sysv_sem.c +++ b/sys/kern/sysv_sem.c @@ -88,7 +88,7 @@ int semop(struct thread *td, struct semop_args *uap); static struct sem_undo *semu_alloc(struct thread *td); static int semundo_adjust(struct thread *td, struct sem_undo **supptr, - int semid, int semnum, int adjval); + int semid, int semseq, int semnum, int adjval); static void semundo_clear(int semid, int semnum); /* XXX casting to (sy_call_t *) is bogus, as usual. */ @@ -98,15 +98,17 @@ static sy_call_t *semcalls[] = { }; static struct mtx sem_mtx; /* semaphore global lock */ +static struct mtx sem_undo_mtx; static int semtot = 0; static struct semid_kernel *sema; /* semaphore id pool */ static struct mtx *sema_mtx; /* semaphore id pool mutexes*/ static struct sem *sem; /* semaphore pool */ -SLIST_HEAD(, sem_undo) semu_list; /* list of active undo structures */ +LIST_HEAD(, sem_undo) semu_list; /* list of active undo structures */ +LIST_HEAD(, sem_undo) semu_free_list; /* list of free undo structures */ static int *semu; /* undo structure pool */ static eventhandler_tag semexit_tag; -#define SEMUNDO_MTX sem_mtx +#define SEMUNDO_MTX sem_undo_mtx #define SEMUNDO_LOCK() mtx_lock(&SEMUNDO_MTX); #define SEMUNDO_UNLOCK() mtx_unlock(&SEMUNDO_MTX); #define SEMUNDO_LOCKASSERT(how) mtx_assert(&SEMUNDO_MTX, (how)); @@ -122,13 +124,15 @@ struct sem { * Undo structure (one per process) */ struct sem_undo { - SLIST_ENTRY(sem_undo) un_next; /* ptr to next active undo structure */ + LIST_ENTRY(sem_undo) un_next; /* ptr to next active undo structure */ struct proc *un_proc; /* owner of this structure */ short un_cnt; /* # of active entries */ struct undo { short un_adjval; /* adjust on exit values */ short un_num; /* semaphore # */ int un_id; /* semid */ + unsigned short un_seq; + } un_ent[1]; /* undo entries */ }; @@ -250,12 +254,15 @@ seminit(void) } for (i = 0; i < seminfo.semmni; i++) mtx_init(&sema_mtx[i], "semid", NULL, MTX_DEF); + LIST_INIT(&semu_free_list); for (i = 0; i < seminfo.semmnu; i++) { struct sem_undo *suptr = SEMU(i); suptr->un_proc = NULL; + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); } - SLIST_INIT(&semu_list); + LIST_INIT(&semu_list); mtx_init(&sem_mtx, "sem", NULL, MTX_DEF); + mtx_init(&sem_undo_mtx, "semu", NULL, MTX_DEF); semexit_tag = EVENTHANDLER_REGISTER(process_exit, semexit_myhook, NULL, EVENTHANDLER_PRI_ANY); } @@ -265,6 +272,7 @@ semunload(void) { int i; + /* XXXKIB */ if (semtot != 0) return (EBUSY); @@ -279,6 +287,7 @@ semunload(void) for (i = 0; i < seminfo.semmni; i++) mtx_destroy(&sema_mtx[i]); mtx_destroy(&sem_mtx); + mtx_destroy(&sem_undo_mtx); return (0); } @@ -350,69 +359,31 @@ semsys(td, uap) */ static struct sem_undo * -semu_alloc(td) - struct thread *td; +semu_alloc(struct thread *td) { - int i; struct sem_undo *suptr; - struct sem_undo **supptr; - int attempt; SEMUNDO_LOCKASSERT(MA_OWNED); - /* - * Try twice to allocate something. - * (we'll purge an empty structure after the first pass so - * two passes are always enough) - */ - - for (attempt = 0; attempt < 2; attempt++) { - /* - * Look for a free structure. - * Fill it in and return it if we find one. - */ - - for (i = 0; i < seminfo.semmnu; i++) { - suptr = SEMU(i); - if (suptr->un_proc == NULL) { - SLIST_INSERT_HEAD(&semu_list, suptr, un_next); - suptr->un_cnt = 0; - suptr->un_proc = td->td_proc; - return(suptr); - } - } - - /* - * We didn't find a free one, if this is the first attempt - * then try to free a structure. - */ + if ((suptr = LIST_FIRST(&semu_free_list)) == NULL) + return (NULL); + LIST_REMOVE(suptr, un_next); + LIST_INSERT_HEAD(&semu_list, suptr, un_next); + suptr->un_cnt = 0; + suptr->un_proc = td->td_proc; + return (suptr); +} - if (attempt == 0) { - /* All the structures are in use - try to free one */ - int did_something = 0; +static int +semu_try_free(struct sem_undo *suptr) +{ - SLIST_FOREACH_PREVPTR(suptr, supptr, &semu_list, - un_next) { - if (suptr->un_cnt == 0) { - suptr->un_proc = NULL; - did_something = 1; - *supptr = SLIST_NEXT(suptr, un_next); - break; - } - } + SEMUNDO_LOCKASSERT(MA_OWNED); - /* If we didn't free anything then just give-up */ - if (!did_something) - return(NULL); - } else { - /* - * The second pass failed even though we freed - * something after the first pass! - * This is IMPOSSIBLE! - */ - panic("semu_alloc - second attempt failed"); - } - } - return (NULL); + if (suptr->un_cnt != 0) + return (0); + LIST_REMOVE(suptr, un_next); + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); + return (1); } /* @@ -420,11 +391,8 @@ semu_alloc(td) */ static int -semundo_adjust(td, supptr, semid, semnum, adjval) - struct thread *td; - struct sem_undo **supptr; - int semid, semnum; - int adjval; +semundo_adjust(struct thread *td, struct sem_undo **supptr, int semid, + int semseq, int semnum, int adjval) { struct proc *p = td->td_proc; struct sem_undo *suptr; @@ -437,7 +405,7 @@ semundo_adjust(td, supptr, semid, semnum, adjval) suptr = *supptr; if (suptr == NULL) { - SLIST_FOREACH(suptr, &semu_list, un_next) { + LIST_FOREACH(suptr, &semu_list, un_next) { if (suptr->un_proc == p) { *supptr = suptr; break; @@ -448,7 +416,7 @@ semundo_adjust(td, supptr, semid, semnum, adjval) return(0); suptr = semu_alloc(td); if (suptr == NULL) - return(ENOSPC); + return (ENOSPC); *supptr = suptr; } } @@ -472,58 +440,59 @@ semundo_adjust(td, supptr, semid, semnum, adjval) if (i < suptr->un_cnt) suptr->un_ent[i] = suptr->un_ent[suptr->un_cnt]; + if (suptr->un_cnt == 0) + semu_try_free(suptr); } - return(0); + return (0); } /* Didn't find the right entry - create it */ if (adjval == 0) - return(0); + return (0); if (adjval > seminfo.semaem || adjval < -seminfo.semaem) return (ERANGE); if (suptr->un_cnt != seminfo.semume) { sunptr = &suptr->un_ent[suptr->un_cnt]; suptr->un_cnt++; sunptr->un_adjval = adjval; - sunptr->un_id = semid; sunptr->un_num = semnum; + sunptr->un_id = semid; + sunptr->un_num = semnum; + sunptr->un_seq = semseq; } else - return(EINVAL); - return(0); + return (EINVAL); + return (0); } static void -semundo_clear(semid, semnum) - int semid, semnum; +semundo_clear(int semid, int semnum) { - struct sem_undo *suptr; + struct sem_undo *suptr, *suptr1; + struct undo *sunptr; + int i; SEMUNDO_LOCKASSERT(MA_OWNED); - SLIST_FOREACH(suptr, &semu_list, un_next) { - struct undo *sunptr = &suptr->un_ent[0]; - int i = 0; - - while (i < suptr->un_cnt) { - if (sunptr->un_id == semid) { - if (semnum == -1 || sunptr->un_num == semnum) { - suptr->un_cnt--; - if (i < suptr->un_cnt) { - suptr->un_ent[i] = - suptr->un_ent[suptr->un_cnt]; - continue; - } + LIST_FOREACH_SAFE(suptr, &semu_list, un_next, suptr1) { + sunptr = &suptr->un_ent[0]; + for (i = 0; i < suptr->un_cnt; i++, sunptr++) { + if (sunptr->un_id != semid) + continue; + if (semnum == -1 || sunptr->un_num == semnum) { + suptr->un_cnt--; + if (i < suptr->un_cnt) { + suptr->un_ent[i] = + suptr->un_ent[suptr->un_cnt]; + continue; } - if (semnum != -1) - break; + semu_try_free(suptr); } - i++, sunptr++; + if (semnum != -1) + break; } } } static int -semvalid(semid, semakptr) - int semid; - struct semid_kernel *semakptr; +semvalid(int semid, struct semid_kernel *semakptr) { return ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0 || @@ -542,9 +511,7 @@ struct __semctl_args { }; #endif int -__semctl(td, uap) - struct thread *td; - struct __semctl_args *uap; +__semctl(struct thread *td, struct __semctl_args *uap) { struct semid_ds dsbuf; union semun arg, semun; @@ -655,6 +622,8 @@ kern_semctl(struct thread *td, int semid, int semnum, int cmd, semakptr = &sema[semidx]; sema_mtxp = &sema_mtx[semidx]; + if (cmd == IPC_RMID) + mtx_lock(&sem_mtx); mtx_lock(sema_mtxp); #ifdef MAC error = mac_check_sysv_sem_semctl(cred, semakptr, cmd); @@ -673,22 +642,29 @@ kern_semctl(struct thread *td, int semid, int semnum, int cmd, goto done2; semakptr->u.sem_perm.cuid = cred->cr_uid; semakptr->u.sem_perm.uid = cred->cr_uid; - semtot -= semakptr->u.sem_nsems; + semakptr->u.sem_perm.mode = 0; + SEMUNDO_LOCK(); + semundo_clear(semidx, -1); + SEMUNDO_UNLOCK(); +#ifdef MAC + mac_cleanup_sysv_sem(semakptr); +#endif + wakeup(semakptr); + for (i = 0; i < seminfo.semmni; i++) { + if ((sema[i].u.sem_perm.mode & SEM_ALLOC) && + sema[i].u.sem_base > semakptr->u.sem_base) + mtx_lock(&sema_mtx[i]); + } for (i = semakptr->u.sem_base - sem; i < semtot; i++) sem[i] = sem[i + semakptr->u.sem_nsems]; for (i = 0; i < seminfo.semmni; i++) { if ((sema[i].u.sem_perm.mode & SEM_ALLOC) && - sema[i].u.sem_base > semakptr->u.sem_base) + sema[i].u.sem_base > semakptr->u.sem_base) { sema[i].u.sem_base -= semakptr->u.sem_nsems; + mtx_unlock(&sema_mtx[i]); + } } - semakptr->u.sem_perm.mode = 0; -#ifdef MAC - mac_cleanup_sysv_sem(semakptr); -#endif - SEMUNDO_LOCK(); - semundo_clear(semidx, -1); - SEMUNDO_UNLOCK(); - wakeup(semakptr); + semtot -= semakptr->u.sem_nsems; break; case IPC_SET: @@ -855,6 +831,8 @@ kern_semctl(struct thread *td, int semid, int semnum, int cmd, done2: mtx_unlock(sema_mtxp); + if (cmd == IPC_RMID) + mtx_unlock(&sem_mtx); if (array != NULL) free(array, M_TEMP); return(error); @@ -868,21 +846,23 @@ struct semget_args { }; #endif int -semget(td, uap) - struct thread *td; - struct semget_args *uap; +semget(struct thread *td, struct semget_args *uap) { int semid, error = 0; int key = uap->key; int nsems = uap->nsems; int semflg = uap->semflg; struct ucred *cred = td->td_ucred; + register_t ret; +#ifdef MAC + int sem_found; +#endif DPRINTF(("semget(0x%x, %d, 0%o)\n", key, nsems, semflg)); if (!jail_sysvipc_allowed && jailed(td->td_ucred)) return (ENOSYS); - mtx_lock(&Giant); + mtx_lock(&sem_mtx); if (key != IPC_PRIVATE) { for (semid = 0; semid < seminfo.semmni; semid++) { if ((sema[semid].u.sem_perm.mode & SEM_ALLOC) && @@ -905,15 +885,12 @@ semget(td, uap) error = EEXIST; goto done2; } -#ifdef MAC - error = mac_check_sysv_semget(cred, &sema[semid]); - if (error != 0) - goto done2; -#endif + sem_found = 1; goto found; } } + sem_found = 0; DPRINTF(("need to allocate the semid_kernel\n")); if (key == IPC_PRIVATE || (semflg & IPC_CREAT)) { if (nsems <= 0 || nsems > seminfo.semmsl) { @@ -955,7 +932,6 @@ semget(td, uap) bzero(sema[semid].u.sem_base, sizeof(sema[semid].u.sem_base[0])*nsems); #ifdef MAC - mac_create_sysv_sem(cred, &sema[semid]); #endif DPRINTF(("sembase = %p, next = %p\n", sema[semid].u.sem_base, &sem[semtot])); @@ -966,9 +942,19 @@ semget(td, uap) } found: - td->td_retval[0] = IXSEQ_TO_IPCID(semid, sema[semid].u.sem_perm); + ret = IXSEQ_TO_IPCID(semid, sema[semid].u.sem_perm); + mtx_unlock(&sem_mtx); +#ifdef MAC + if (error == 0) { + if (sem_found) + error = mac_check_sysv_semget(cred, &sema[semid]); + else + mac_create_sysv_sem(cred, &sema[semid]); + } + if (error == 0) +#endif + td->td_retval[0] = ret; done2: - mtx_unlock(&Giant); return (error); } @@ -980,9 +966,7 @@ struct semop_args { }; #endif int -semop(td, uap) - struct thread *td; - struct semop_args *uap; +semop(struct thread *td, struct semop_args *uap) { #define SMALL_SOPS 8 struct sembuf small_sops[SMALL_SOPS]; @@ -997,6 +981,7 @@ semop(td, uap) size_t i, j, k; int error; int do_wakeup, do_undos; + unsigned short seq; #ifdef SEM_DEBUG sops = NULL; @@ -1036,7 +1021,8 @@ semop(td, uap) error = EINVAL; goto done2; } - if (semakptr->u.sem_perm.seq != IPCID_TO_SEQ(uap->semid)) { + seq = semakptr->u.sem_perm.seq; + if (seq != IPCID_TO_SEQ(uap->semid)) { error = EINVAL; goto done2; } @@ -1160,8 +1146,9 @@ semop(td, uap) /* * Make sure that the semaphore still exists */ + seq = semakptr->u.sem_perm.seq; if ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0 || - semakptr->u.sem_perm.seq != IPCID_TO_SEQ(uap->semid)) { + seq != IPCID_TO_SEQ(uap->semid)) { error = EIDRM; goto done2; } @@ -1213,7 +1200,7 @@ done: adjval = sops[i].sem_op; if (adjval == 0) continue; - error = semundo_adjust(td, &suptr, semid, + error = semundo_adjust(td, &suptr, semid, seq, sops[i].sem_num, -adjval); if (error == 0) continue; @@ -1234,7 +1221,7 @@ done: adjval = sops[k].sem_op; if (adjval == 0) continue; - if (semundo_adjust(td, &suptr, semid, + if (semundo_adjust(td, &suptr, semid, seq, sops[k].sem_num, adjval) != 0) panic("semop - can't undo undos"); } @@ -1281,28 +1268,28 @@ done2: * semaphores. */ static void -semexit_myhook(arg, p) - void *arg; - struct proc *p; +semexit_myhook(void *arg, struct proc *p) { struct sem_undo *suptr; - struct sem_undo **supptr; + struct semid_kernel *semakptr; + struct mtx *sema_mtxp; + int semid, semnum, adjval, ix; + unsigned short seq; /* * Go through the chain of undo vectors looking for one * associated with this process. */ SEMUNDO_LOCK(); - SLIST_FOREACH_PREVPTR(suptr, supptr, &semu_list, un_next) { - if (suptr->un_proc == p) { - *supptr = SLIST_NEXT(suptr, un_next); + LIST_FOREACH(suptr, &semu_list, un_next) { + if (suptr->un_proc == p) break; - } } - SEMUNDO_UNLOCK(); - - if (suptr == NULL) + if (suptr == NULL) { + SEMUNDO_UNLOCK(); return; + } + LIST_REMOVE(suptr, un_next); DPRINTF(("proc @%p has undo structure with %d entries\n", p, suptr->un_cnt)); @@ -1311,21 +1298,21 @@ semexit_myhook(arg, p) * If there are any active undo elements then process them. */ if (suptr->un_cnt > 0) { - int ix; - + SEMUNDO_UNLOCK(); for (ix = 0; ix < suptr->un_cnt; ix++) { - int semid = suptr->un_ent[ix].un_id; - int semnum = suptr->un_ent[ix].un_num; - int adjval = suptr->un_ent[ix].un_adjval; - struct semid_kernel *semakptr; - struct mtx *sema_mtxp; - + semid = suptr->un_ent[ix].un_id; + semnum = suptr->un_ent[ix].un_num; + adjval = suptr->un_ent[ix].un_adjval; + seq = suptr->un_ent[ix].un_seq; semakptr = &sema[semid]; sema_mtxp = &sema_mtx[semid]; + mtx_lock(sema_mtxp); - SEMUNDO_LOCK(); - if ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0) - panic("semexit - semid not allocated"); + if ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0 || + (semakptr->u.sem_perm.seq != seq)) { + mtx_unlock(sema_mtxp); + continue; + } if (semnum >= semakptr->u.sem_nsems) panic("semexit - semnum out of range"); @@ -1336,29 +1323,26 @@ semexit_myhook(arg, p) suptr->un_ent[ix].un_adjval, semakptr->u.sem_base[semnum].semval)); - if (adjval < 0) { - if (semakptr->u.sem_base[semnum].semval < - -adjval) - semakptr->u.sem_base[semnum].semval = 0; - else - semakptr->u.sem_base[semnum].semval += - adjval; - } else + if (adjval < 0 && semakptr->u.sem_base[semnum].semval < + -adjval) + semakptr->u.sem_base[semnum].semval = 0; + else semakptr->u.sem_base[semnum].semval += adjval; wakeup(semakptr); DPRINTF(("semexit: back from wakeup\n")); mtx_unlock(sema_mtxp); - SEMUNDO_UNLOCK(); } + SEMUNDO_LOCK(); } /* * Deallocate the undo vector. */ DPRINTF(("removing vector\n")); - SEMUNDO_LOCK(); suptr->un_proc = NULL; + suptr->un_cnt = 0; + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); SEMUNDO_UNLOCK(); } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090111/2adc1446/attachment.pgp From rick-freebsd2008 at kiwi-computer.com Sun Jan 11 08:01:40 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Sun Jan 11 08:01:49 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> Message-ID: <20090111160138.GA2386@keira.kiwi-computer.com> On Sat, Jan 10, 2009 at 04:20:58AM -0800, perryh@pluto.rain.com wrote: > "Rick C. Petty" wrote: > > > > That's not how devfs works. It's actually a feature > > that devfs doesn't list everything ever possible > > http://storage9.myopera.com/freejerk/files/bug-feature.jpg Funny. But this isn't a bug disguised as a feature. It's a feature that you believe is a bug. > > I'd rather be able to list to see things that are in use, although > > at first glance I didn't like devfs hidden nodes. Otherwise you'd > > be stuck printing tunXXX through infinity instead of this: > > > > % ls /dev/tun* > > /dev/tun0 /dev/tun115 /dev/tun194 > > In any other part of the directory tree we expect ls to provide > a list of names that are available to be opened (subject to > permissions). Why should /dev be any different? Because it's a special filesystem. > Since you aren't supposed to open (say) /dev/tun85, but only > /dev/tun0, correspondence between readdir and open would not demand What? Why aren't you supposed to open tun85? I use this behavior all the time and have for years. It helps keep track of things. Otherwise I would have to keep my natd configuration, firewall rules, and openvpn configuration all in sync. Please provide a reference describing you're not "supposed to" open any arbitrary tunnelling device. > that readdir return the (large, if not infinite) list of potential > instances. It would however seem reasonable for that ls command to > show /dev/tun0 if its driver is loaded, even if the device has not > been instantiated because the node has never been opened. I don't buy that argument at all. If anything it should show "/dev/tun", but why create device nodes when they aren't necessary, as you have to clone the nodes (or create new ones) when an actual open(2) occurs? > > This is not a bug, it is designed behavior. It was intentionally > > written to dynamically create device nodes when needed. > > That the code faithfully adheres to the design does not guarantee > that the design is flawless. IMO it violates POLA, if not POSIX, Please provide the reference where it violates POSIX. > for open(2) to succeed when applied to a name which, according to > readdir(2), does not exist; What? This can happen already-- there is no atomicity between a readdir and an open. And what about msdosfs and case-insensitivity? You can certainly open files that weren't a part of your readdir. Also no one in their right mind would be coding a readdir/open solution against a filesystem known to be completely dynamic and especially against devfs. You would want to tie in directly to devctl, sysctl, or syscall. > and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. Why is it suboptimal? I think you have that backwards-- it's more optimal not to have to create superfluous device nodes when they are not needed, at least from the kernel efficiency perspective. -- Rick C. Petty From omerfsen at gmail.com Sun Jan 11 11:04:13 2009 From: omerfsen at gmail.com (Omer Faruk Sen) Date: Sun Jan 11 11:04:20 2009 Subject: kernel dump with 7.1-RELEASE In-Reply-To: <20090111155854.GS93900@deviant.kiev.zoral.com.ua> References: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> <20090111155854.GS93900@deviant.kiev.zoral.com.ua> Message-ID: <75a268720901111104m6297614jae11f5d1ea4f85df@mail.gmail.com> Hi Kostik, I will try that patch and will return to -hackers if that solves semid not allocated problem. Thanks for prompt action. Best Regards. On Sun, Jan 11, 2009 at 5:58 PM, Kostik Belousov wrote: > On Fri, Jan 09, 2009 at 06:39:53PM +0200, Omer Faruk Sen wrote: > > Hi, > > > > I am having kernel dump with FreeBSD 7.1: > > > > Here is crashinfo output of it (Actually i don't know the state of > > crashinfo in Fbsd 7.1) > > > > 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 > > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > > > > > > > panic: semexit - semid not allocated > > > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > are > > welcome to change it and/or distribute copies of it under certain > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > details. > > This GDB was configured as "amd64-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > Physical memory: 8173 MB > > Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230 > > 214 198 182 166 150 134 118 102 86 70 54 38 22 6 > > > > #0 doadump () at pcpu.h:195 > > 195 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) #0 doadump () at pcpu.h:195 > > #1 0x0000000000000004 in ?? () > > #2 0xffffffff804b4ce9 in boot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:418 > > #3 0xffffffff804b50f2 in panic (fmt=0x104
) > > at /usr/src/sys/kern/kern_shutdown.c:574 > > #4 0xffffffff804f846d in semexit_myhook (arg=Variable "arg" is not > available. > > ) > > at /usr/src/sys/kern/sysv_sem.c:1328 > > #5 0xffffffff80490dbc in exit1 (td=0xffffff000995f370, rv=0) > > at /usr/src/sys/kern/kern_exit.c:244 > > #6 0xffffffff8049239e in sys_exit (td=Variable "td" is not available. > > ) at /usr/src/sys/kern/kern_exit.c:109 > > #7 0xffffffff8078a7c7 in syscall (frame=0xffffffffb0d4ac80) > > at /usr/src/sys/amd64/amd64/trap.c:907 > > #8 0xffffffff8077088b in Xfast_syscall () > > at /usr/src/sys/amd64/amd64/exception.S:330 > > #9 0x0000000800a2a30c in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > It seems that there are at least two issues with IPC_RMID operation > on SysV semaphores. > 1. The squeeze of the semaphore array in the kern_semctl() modifies > sem_base for the semaphores, as well as the values of the > semaphores, without locking their mutex. This can lead to > (killable) hangs or unexpected behaviour of the processes > performing any sem operations while other process does IPC_RMID. > 2. The semexit_myhook() eventhandler does not lock SEMUNDO_LOCK() > while accessing *suptr. I think that this allows for IPC_RMID > to be performed in parallel with the sem id referenced by the > current undo structure. > > Patch below is the backport of the patch I developed and lightly > tested on CURRENT, that shuffle locking to solve the listed issues. > Testing consisted of running several instances of > tools/regression/sysvsem. > > diff --git a/sys/kern/sysv_sem.c b/sys/kern/sysv_sem.c > index 80d07ba..6bc4cce 100644 > --- a/sys/kern/sysv_sem.c > +++ b/sys/kern/sysv_sem.c > @@ -88,7 +88,7 @@ int semop(struct thread *td, struct semop_args *uap); > > static struct sem_undo *semu_alloc(struct thread *td); > static int semundo_adjust(struct thread *td, struct sem_undo **supptr, > - int semid, int semnum, int adjval); > + int semid, int semseq, int semnum, int adjval); > static void semundo_clear(int semid, int semnum); > > /* XXX casting to (sy_call_t *) is bogus, as usual. */ > @@ -98,15 +98,17 @@ static sy_call_t *semcalls[] = { > }; > > static struct mtx sem_mtx; /* semaphore global lock */ > +static struct mtx sem_undo_mtx; > static int semtot = 0; > static struct semid_kernel *sema; /* semaphore id pool */ > static struct mtx *sema_mtx; /* semaphore id pool mutexes*/ > static struct sem *sem; /* semaphore pool */ > -SLIST_HEAD(, sem_undo) semu_list; /* list of active undo structures > */ > +LIST_HEAD(, sem_undo) semu_list; /* list of active undo structures > */ > +LIST_HEAD(, sem_undo) semu_free_list; /* list of free undo structures */ > static int *semu; /* undo structure pool */ > static eventhandler_tag semexit_tag; > > -#define SEMUNDO_MTX sem_mtx > +#define SEMUNDO_MTX sem_undo_mtx > #define SEMUNDO_LOCK() mtx_lock(&SEMUNDO_MTX); > #define SEMUNDO_UNLOCK() mtx_unlock(&SEMUNDO_MTX); > #define SEMUNDO_LOCKASSERT(how) mtx_assert(&SEMUNDO_MTX, (how)); > @@ -122,13 +124,15 @@ struct sem { > * Undo structure (one per process) > */ > struct sem_undo { > - SLIST_ENTRY(sem_undo) un_next; /* ptr to next active undo > structure */ > + LIST_ENTRY(sem_undo) un_next; /* ptr to next active undo > structure */ > struct proc *un_proc; /* owner of this structure */ > short un_cnt; /* # of active entries */ > struct undo { > short un_adjval; /* adjust on exit values */ > short un_num; /* semaphore # */ > int un_id; /* semid */ > + unsigned short un_seq; > + > } un_ent[1]; /* undo entries */ > }; > > @@ -250,12 +254,15 @@ seminit(void) > } > for (i = 0; i < seminfo.semmni; i++) > mtx_init(&sema_mtx[i], "semid", NULL, MTX_DEF); > + LIST_INIT(&semu_free_list); > for (i = 0; i < seminfo.semmnu; i++) { > struct sem_undo *suptr = SEMU(i); > suptr->un_proc = NULL; > + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); > } > - SLIST_INIT(&semu_list); > + LIST_INIT(&semu_list); > mtx_init(&sem_mtx, "sem", NULL, MTX_DEF); > + mtx_init(&sem_undo_mtx, "semu", NULL, MTX_DEF); > semexit_tag = EVENTHANDLER_REGISTER(process_exit, semexit_myhook, > NULL, > EVENTHANDLER_PRI_ANY); > } > @@ -265,6 +272,7 @@ semunload(void) > { > int i; > > + /* XXXKIB */ > if (semtot != 0) > return (EBUSY); > > @@ -279,6 +287,7 @@ semunload(void) > for (i = 0; i < seminfo.semmni; i++) > mtx_destroy(&sema_mtx[i]); > mtx_destroy(&sem_mtx); > + mtx_destroy(&sem_undo_mtx); > return (0); > } > > @@ -350,69 +359,31 @@ semsys(td, uap) > */ > > static struct sem_undo * > -semu_alloc(td) > - struct thread *td; > +semu_alloc(struct thread *td) > { > - int i; > struct sem_undo *suptr; > - struct sem_undo **supptr; > - int attempt; > > SEMUNDO_LOCKASSERT(MA_OWNED); > - /* > - * Try twice to allocate something. > - * (we'll purge an empty structure after the first pass so > - * two passes are always enough) > - */ > - > - for (attempt = 0; attempt < 2; attempt++) { > - /* > - * Look for a free structure. > - * Fill it in and return it if we find one. > - */ > - > - for (i = 0; i < seminfo.semmnu; i++) { > - suptr = SEMU(i); > - if (suptr->un_proc == NULL) { > - SLIST_INSERT_HEAD(&semu_list, suptr, > un_next); > - suptr->un_cnt = 0; > - suptr->un_proc = td->td_proc; > - return(suptr); > - } > - } > - > - /* > - * We didn't find a free one, if this is the first attempt > - * then try to free a structure. > - */ > + if ((suptr = LIST_FIRST(&semu_free_list)) == NULL) > + return (NULL); > + LIST_REMOVE(suptr, un_next); > + LIST_INSERT_HEAD(&semu_list, suptr, un_next); > + suptr->un_cnt = 0; > + suptr->un_proc = td->td_proc; > + return (suptr); > +} > > - if (attempt == 0) { > - /* All the structures are in use - try to free one > */ > - int did_something = 0; > +static int > +semu_try_free(struct sem_undo *suptr) > +{ > > - SLIST_FOREACH_PREVPTR(suptr, supptr, &semu_list, > - un_next) { > - if (suptr->un_cnt == 0) { > - suptr->un_proc = NULL; > - did_something = 1; > - *supptr = SLIST_NEXT(suptr, > un_next); > - break; > - } > - } > + SEMUNDO_LOCKASSERT(MA_OWNED); > > - /* If we didn't free anything then just give-up */ > - if (!did_something) > - return(NULL); > - } else { > - /* > - * The second pass failed even though we freed > - * something after the first pass! > - * This is IMPOSSIBLE! > - */ > - panic("semu_alloc - second attempt failed"); > - } > - } > - return (NULL); > + if (suptr->un_cnt != 0) > + return (0); > + LIST_REMOVE(suptr, un_next); > + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); > + return (1); > } > > /* > @@ -420,11 +391,8 @@ semu_alloc(td) > */ > > static int > -semundo_adjust(td, supptr, semid, semnum, adjval) > - struct thread *td; > - struct sem_undo **supptr; > - int semid, semnum; > - int adjval; > +semundo_adjust(struct thread *td, struct sem_undo **supptr, int semid, > + int semseq, int semnum, int adjval) > { > struct proc *p = td->td_proc; > struct sem_undo *suptr; > @@ -437,7 +405,7 @@ semundo_adjust(td, supptr, semid, semnum, adjval) > > suptr = *supptr; > if (suptr == NULL) { > - SLIST_FOREACH(suptr, &semu_list, un_next) { > + LIST_FOREACH(suptr, &semu_list, un_next) { > if (suptr->un_proc == p) { > *supptr = suptr; > break; > @@ -448,7 +416,7 @@ semundo_adjust(td, supptr, semid, semnum, adjval) > return(0); > suptr = semu_alloc(td); > if (suptr == NULL) > - return(ENOSPC); > + return (ENOSPC); > *supptr = suptr; > } > } > @@ -472,58 +440,59 @@ semundo_adjust(td, supptr, semid, semnum, adjval) > if (i < suptr->un_cnt) > suptr->un_ent[i] = > suptr->un_ent[suptr->un_cnt]; > + if (suptr->un_cnt == 0) > + semu_try_free(suptr); > } > - return(0); > + return (0); > } > > /* Didn't find the right entry - create it */ > if (adjval == 0) > - return(0); > + return (0); > if (adjval > seminfo.semaem || adjval < -seminfo.semaem) > return (ERANGE); > if (suptr->un_cnt != seminfo.semume) { > sunptr = &suptr->un_ent[suptr->un_cnt]; > suptr->un_cnt++; > sunptr->un_adjval = adjval; > - sunptr->un_id = semid; sunptr->un_num = semnum; > + sunptr->un_id = semid; > + sunptr->un_num = semnum; > + sunptr->un_seq = semseq; > } else > - return(EINVAL); > - return(0); > + return (EINVAL); > + return (0); > } > > static void > -semundo_clear(semid, semnum) > - int semid, semnum; > +semundo_clear(int semid, int semnum) > { > - struct sem_undo *suptr; > + struct sem_undo *suptr, *suptr1; > + struct undo *sunptr; > + int i; > > SEMUNDO_LOCKASSERT(MA_OWNED); > - SLIST_FOREACH(suptr, &semu_list, un_next) { > - struct undo *sunptr = &suptr->un_ent[0]; > - int i = 0; > - > - while (i < suptr->un_cnt) { > - if (sunptr->un_id == semid) { > - if (semnum == -1 || sunptr->un_num == > semnum) { > - suptr->un_cnt--; > - if (i < suptr->un_cnt) { > - suptr->un_ent[i] = > - > suptr->un_ent[suptr->un_cnt]; > - continue; > - } > + LIST_FOREACH_SAFE(suptr, &semu_list, un_next, suptr1) { > + sunptr = &suptr->un_ent[0]; > + for (i = 0; i < suptr->un_cnt; i++, sunptr++) { > + if (sunptr->un_id != semid) > + continue; > + if (semnum == -1 || sunptr->un_num == semnum) { > + suptr->un_cnt--; > + if (i < suptr->un_cnt) { > + suptr->un_ent[i] = > + suptr->un_ent[suptr->un_cnt]; > + continue; > } > - if (semnum != -1) > - break; > + semu_try_free(suptr); > } > - i++, sunptr++; > + if (semnum != -1) > + break; > } > } > } > > static int > -semvalid(semid, semakptr) > - int semid; > - struct semid_kernel *semakptr; > +semvalid(int semid, struct semid_kernel *semakptr) > { > > return ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0 || > @@ -542,9 +511,7 @@ struct __semctl_args { > }; > #endif > int > -__semctl(td, uap) > - struct thread *td; > - struct __semctl_args *uap; > +__semctl(struct thread *td, struct __semctl_args *uap) > { > struct semid_ds dsbuf; > union semun arg, semun; > @@ -655,6 +622,8 @@ kern_semctl(struct thread *td, int semid, int semnum, > int cmd, > > semakptr = &sema[semidx]; > sema_mtxp = &sema_mtx[semidx]; > + if (cmd == IPC_RMID) > + mtx_lock(&sem_mtx); > mtx_lock(sema_mtxp); > #ifdef MAC > error = mac_check_sysv_sem_semctl(cred, semakptr, cmd); > @@ -673,22 +642,29 @@ kern_semctl(struct thread *td, int semid, int semnum, > int cmd, > goto done2; > semakptr->u.sem_perm.cuid = cred->cr_uid; > semakptr->u.sem_perm.uid = cred->cr_uid; > - semtot -= semakptr->u.sem_nsems; > + semakptr->u.sem_perm.mode = 0; > + SEMUNDO_LOCK(); > + semundo_clear(semidx, -1); > + SEMUNDO_UNLOCK(); > +#ifdef MAC > + mac_cleanup_sysv_sem(semakptr); > +#endif > + wakeup(semakptr); > + for (i = 0; i < seminfo.semmni; i++) { > + if ((sema[i].u.sem_perm.mode & SEM_ALLOC) && > + sema[i].u.sem_base > semakptr->u.sem_base) > + mtx_lock(&sema_mtx[i]); > + } > for (i = semakptr->u.sem_base - sem; i < semtot; i++) > sem[i] = sem[i + semakptr->u.sem_nsems]; > for (i = 0; i < seminfo.semmni; i++) { > if ((sema[i].u.sem_perm.mode & SEM_ALLOC) && > - sema[i].u.sem_base > semakptr->u.sem_base) > + sema[i].u.sem_base > semakptr->u.sem_base) { > sema[i].u.sem_base -= semakptr->u.sem_nsems; > + mtx_unlock(&sema_mtx[i]); > + } > } > - semakptr->u.sem_perm.mode = 0; > -#ifdef MAC > - mac_cleanup_sysv_sem(semakptr); > -#endif > - SEMUNDO_LOCK(); > - semundo_clear(semidx, -1); > - SEMUNDO_UNLOCK(); > - wakeup(semakptr); > + semtot -= semakptr->u.sem_nsems; > break; > > case IPC_SET: > @@ -855,6 +831,8 @@ kern_semctl(struct thread *td, int semid, int semnum, > int cmd, > > done2: > mtx_unlock(sema_mtxp); > + if (cmd == IPC_RMID) > + mtx_unlock(&sem_mtx); > if (array != NULL) > free(array, M_TEMP); > return(error); > @@ -868,21 +846,23 @@ struct semget_args { > }; > #endif > int > -semget(td, uap) > - struct thread *td; > - struct semget_args *uap; > +semget(struct thread *td, struct semget_args *uap) > { > int semid, error = 0; > int key = uap->key; > int nsems = uap->nsems; > int semflg = uap->semflg; > struct ucred *cred = td->td_ucred; > + register_t ret; > +#ifdef MAC > + int sem_found; > +#endif > > DPRINTF(("semget(0x%x, %d, 0%o)\n", key, nsems, semflg)); > if (!jail_sysvipc_allowed && jailed(td->td_ucred)) > return (ENOSYS); > > - mtx_lock(&Giant); > + mtx_lock(&sem_mtx); > if (key != IPC_PRIVATE) { > for (semid = 0; semid < seminfo.semmni; semid++) { > if ((sema[semid].u.sem_perm.mode & SEM_ALLOC) && > @@ -905,15 +885,12 @@ semget(td, uap) > error = EEXIST; > goto done2; > } > -#ifdef MAC > - error = mac_check_sysv_semget(cred, &sema[semid]); > - if (error != 0) > - goto done2; > -#endif > + sem_found = 1; > goto found; > } > } > > + sem_found = 0; > DPRINTF(("need to allocate the semid_kernel\n")); > if (key == IPC_PRIVATE || (semflg & IPC_CREAT)) { > if (nsems <= 0 || nsems > seminfo.semmsl) { > @@ -955,7 +932,6 @@ semget(td, uap) > bzero(sema[semid].u.sem_base, > sizeof(sema[semid].u.sem_base[0])*nsems); > #ifdef MAC > - mac_create_sysv_sem(cred, &sema[semid]); > #endif > DPRINTF(("sembase = %p, next = %p\n", > sema[semid].u.sem_base, &sem[semtot])); > @@ -966,9 +942,19 @@ semget(td, uap) > } > > found: > - td->td_retval[0] = IXSEQ_TO_IPCID(semid, sema[semid].u.sem_perm); > + ret = IXSEQ_TO_IPCID(semid, sema[semid].u.sem_perm); > + mtx_unlock(&sem_mtx); > +#ifdef MAC > + if (error == 0) { > + if (sem_found) > + error = mac_check_sysv_semget(cred, &sema[semid]); > + else > + mac_create_sysv_sem(cred, &sema[semid]); > + } > + if (error == 0) > +#endif > + td->td_retval[0] = ret; > done2: > - mtx_unlock(&Giant); > return (error); > } > > @@ -980,9 +966,7 @@ struct semop_args { > }; > #endif > int > -semop(td, uap) > - struct thread *td; > - struct semop_args *uap; > +semop(struct thread *td, struct semop_args *uap) > { > #define SMALL_SOPS 8 > struct sembuf small_sops[SMALL_SOPS]; > @@ -997,6 +981,7 @@ semop(td, uap) > size_t i, j, k; > int error; > int do_wakeup, do_undos; > + unsigned short seq; > > #ifdef SEM_DEBUG > sops = NULL; > @@ -1036,7 +1021,8 @@ semop(td, uap) > error = EINVAL; > goto done2; > } > - if (semakptr->u.sem_perm.seq != IPCID_TO_SEQ(uap->semid)) { > + seq = semakptr->u.sem_perm.seq; > + if (seq != IPCID_TO_SEQ(uap->semid)) { > error = EINVAL; > goto done2; > } > @@ -1160,8 +1146,9 @@ semop(td, uap) > /* > * Make sure that the semaphore still exists > */ > + seq = semakptr->u.sem_perm.seq; > if ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0 || > - semakptr->u.sem_perm.seq != IPCID_TO_SEQ(uap->semid)) { > + seq != IPCID_TO_SEQ(uap->semid)) { > error = EIDRM; > goto done2; > } > @@ -1213,7 +1200,7 @@ done: > adjval = sops[i].sem_op; > if (adjval == 0) > continue; > - error = semundo_adjust(td, &suptr, semid, > + error = semundo_adjust(td, &suptr, semid, seq, > sops[i].sem_num, -adjval); > if (error == 0) > continue; > @@ -1234,7 +1221,7 @@ done: > adjval = sops[k].sem_op; > if (adjval == 0) > continue; > - if (semundo_adjust(td, &suptr, semid, > + if (semundo_adjust(td, &suptr, semid, seq, > sops[k].sem_num, adjval) != 0) > panic("semop - can't undo undos"); > } > @@ -1281,28 +1268,28 @@ done2: > * semaphores. > */ > static void > -semexit_myhook(arg, p) > - void *arg; > - struct proc *p; > +semexit_myhook(void *arg, struct proc *p) > { > struct sem_undo *suptr; > - struct sem_undo **supptr; > + struct semid_kernel *semakptr; > + struct mtx *sema_mtxp; > + int semid, semnum, adjval, ix; > + unsigned short seq; > > /* > * Go through the chain of undo vectors looking for one > * associated with this process. > */ > SEMUNDO_LOCK(); > - SLIST_FOREACH_PREVPTR(suptr, supptr, &semu_list, un_next) { > - if (suptr->un_proc == p) { > - *supptr = SLIST_NEXT(suptr, un_next); > + LIST_FOREACH(suptr, &semu_list, un_next) { > + if (suptr->un_proc == p) > break; > - } > } > - SEMUNDO_UNLOCK(); > - > - if (suptr == NULL) > + if (suptr == NULL) { > + SEMUNDO_UNLOCK(); > return; > + } > + LIST_REMOVE(suptr, un_next); > > DPRINTF(("proc @%p has undo structure with %d entries\n", p, > suptr->un_cnt)); > @@ -1311,21 +1298,21 @@ semexit_myhook(arg, p) > * If there are any active undo elements then process them. > */ > if (suptr->un_cnt > 0) { > - int ix; > - > + SEMUNDO_UNLOCK(); > for (ix = 0; ix < suptr->un_cnt; ix++) { > - int semid = suptr->un_ent[ix].un_id; > - int semnum = suptr->un_ent[ix].un_num; > - int adjval = suptr->un_ent[ix].un_adjval; > - struct semid_kernel *semakptr; > - struct mtx *sema_mtxp; > - > + semid = suptr->un_ent[ix].un_id; > + semnum = suptr->un_ent[ix].un_num; > + adjval = suptr->un_ent[ix].un_adjval; > + seq = suptr->un_ent[ix].un_seq; > semakptr = &sema[semid]; > sema_mtxp = &sema_mtx[semid]; > + > mtx_lock(sema_mtxp); > - SEMUNDO_LOCK(); > - if ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0) > - panic("semexit - semid not allocated"); > + if ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0 || > + (semakptr->u.sem_perm.seq != seq)) { > + mtx_unlock(sema_mtxp); > + continue; > + } > if (semnum >= semakptr->u.sem_nsems) > panic("semexit - semnum out of range"); > > @@ -1336,29 +1323,26 @@ semexit_myhook(arg, p) > suptr->un_ent[ix].un_adjval, > semakptr->u.sem_base[semnum].semval)); > > - if (adjval < 0) { > - if (semakptr->u.sem_base[semnum].semval < > - -adjval) > - semakptr->u.sem_base[semnum].semval > = 0; > - else > - semakptr->u.sem_base[semnum].semval > += > - adjval; > - } else > + if (adjval < 0 && > semakptr->u.sem_base[semnum].semval < > + -adjval) > + semakptr->u.sem_base[semnum].semval = 0; > + else > semakptr->u.sem_base[semnum].semval += > adjval; > > wakeup(semakptr); > DPRINTF(("semexit: back from wakeup\n")); > mtx_unlock(sema_mtxp); > - SEMUNDO_UNLOCK(); > } > + SEMUNDO_LOCK(); > } > > /* > * Deallocate the undo vector. > */ > DPRINTF(("removing vector\n")); > - SEMUNDO_LOCK(); > suptr->un_proc = NULL; > + suptr->un_cnt = 0; > + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); > SEMUNDO_UNLOCK(); > } > > From gad at FreeBSD.org Sun Jan 11 15:10:52 2009 From: gad at FreeBSD.org (Garance A Drosehn) Date: Sun Jan 11 15:10:59 2009 Subject: Small change to 'ps' In-Reply-To: <20090109015106.3614a378@mbook.local> References: <20090107125759.GA1462@roadrunner.spoerlein.net> <20090107154854.GC1462@roadrunner.spoerlein.net> <20090109015106.3614a378@mbook.local> Message-ID: At 1:51 AM -0500 1/9/09, Mike Meyer wrote: >On Wed, 7 Jan 2009 "Sheldon Givens" wrote: > > And I guess I just feel like running a second command to do what should be >> possible to do with the first command (and is, on many platforms. ps >> --no-headers on linux for example) is a problem and presents opportunity for >> continued refinement of the utility. > >I agree. However, [...] > >So `--no-headers' is ok. However, `-n' has lots of different meanings >in different commands. How about borrowing from existing commands that >already implement this functionality (zfs and zpool) and using `-H', >which is relatively rarely used elsewhere? I recommend against adding any single-letter option to the `ps' command. This command is already an absolute minefield of headaches when it comes to portability across operating systems (and POSIX). Trying to sneak in some single-letter option is bound to give us headaches in the long run. Adding something like '--no-headers' is pretty safe, although that opens up a different set of arguments (heh) when it comes to `ps' on freebsd. Namely, we don't have any long-options in our `ps'. Yet another tactic might be to add another accepted keyword to '-o', since it already uses words as its acceptable values. We'd be bending the definition of `-o' a bit to do that, but we could at least do that in a way which would be very unlikely to conflict with an option in any other version of `ps'. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From christoph.mallon at gmx.de Sun Jan 11 15:37:09 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sun Jan 11 15:37:16 2009 Subject: Question about panic in brelse() Message-ID: <496A82A2.9010509@gmx.de> Hi, I observe a failed assertion in the VFS regarding a buffer. I investigated a bit and now I want to present my findings and I have a question: Assume I have a buffer with b_iocmd = BIO_WRITE b_ioflags = BIO_ERROR b_error = EIO b_flags = B_NOCACHE passed to brelse() in kern/vfs_bio.c[0]. - This particular combination of values (line 1144) causes BIO_ERROR to be cleared (line 1152) and B_DELWRI is set in bdirty() (line 1031, called in line 1153). - Because of B_NOCACHE (line 1343) this buffer gets moved to QUEUE_CLEAN (line 1349). Also B_INVAL gets set here (line 1345). - A few lines down (line 1375) bundirty() gets called because of B_INVAL and B_DELWRI. - bundirty() instantly panics because the buffer is not in QUEUE_NONE (line 1075). My question is: Is this a bug in brelse() or was the combination of flag B_NOCACHE with a failed write attempt (BIO_WRITE, BIO_ERROR, EIO) invalid when the buffer was passed to brelse()? Below is a dump of the buffer right when the assertion is triggered. If you want any further information about this issue, please tell me. Hopefully somebody can shed some light on this Christoph { b_bufobj = 0xffffff0030005e00, b_bcount = 16384, b_caller1 = 0x0, b_data = 0xfffffffea2c57000 "", b_error = 5, (EIO) b_iocmd = 2 '\002', (BIO_WRITE) b_ioflags = 2 '\002', (BIO_DONE) b_iooffset = 98304, b_resid = 16384, b_iodone = 0, b_blkno = 192, b_offset = 98304, b_bobufs = { tqe_next = 0x0, tqe_prev = 0xffffff0030005e40}, b_left = 0x0, b_right = 0x0, b_vflags = 0, b_freelist = { tqe_next = 0xfffffffe92d747c8, tqe_prev = 0xffffffff80d340f0 }, b_qindex = 1, (QUEUE_CLEAN) b_flags = 41092, (B_NOCACHE | b_INVAL | B_DELWRI | B_ASYNC) b_xflags = 33 '!', b_lock = { lock_object = { lo_name = 0xffffffff808d01b6 "bufwait", lo_flags = 91947008, lo_data = 0, lo_witness = 0xfffffffe40206180 }, lk_lock = 18446744073709551608, lk_timo = 0, lk_pri = 80 }, b_bufsize = 16384, b_runningbufspace = 0, b_kvabase = 0xfffffffea2c57000 "", b_kvasize = 16384, b_lblkno = 192, b_vp = 0xffffff0030005ce8, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xfffffffea2c57000, b_pager = {pg_reqpage = 0}, b_cluster = { cluster_head = { tqh_first = 0xfffffffe92d747c8, tqh_last = 0xfffffffe92d73ad0 }, cluster_entry = { tqe_next = 0xfffffffe92d747c8, tqe_prev = 0xfffffffe92d73ad0 } }, b_pages = { 0xffffff00de3ce5a0, 0xffffff00de3ce610, 0xffffff00de3ce680, 0xffffff00de3ce6f0, $0x0 }, b_npages = 4, b_dep = { lh_first = 0x0 }, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0 } [0] r183754 in head/, which is the latest version of kern/vfs_bio.c. From kientzle at freebsd.org Sun Jan 11 18:12:40 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sun Jan 11 18:12:47 2009 Subject: extattr problems? In-Reply-To: References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> Message-ID: <496AA714.1090904@freebsd.org> pluknet wrote: > > It's strange.. > FreeBSD jaw.ripn.net 6.3-RELEASE-p5. > works for me (tm), extattr_set_fd() returns 4 as expected. Thank you! *That* was my mistake; I thought extattr_set_fd() returned 0 on success, non-zero on error. I re-read the man page and now everything makes sense. Thank you again! Tim From kientzle at freebsd.org Sun Jan 11 19:48:45 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sun Jan 11 19:48:56 2009 Subject: extattr problems? In-Reply-To: <496AA714.1090904@freebsd.org> References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> <496AA714.1090904@freebsd.org> Message-ID: <496ABD9A.8080006@freebsd.org> I think this one is a bug. It appears that extattr_set_fd() obeys the permissions on the file, not the permissions of the descriptor. In particular, I see this on FreeBSD 6.3: [tim@dark /tmp]$ ./extattr_test fd=3 extattr_set_fd() = -1 errno = 13 (Permission denied) [tim@dark /tmp]$ cat extattr_test.c #include #include #include #include #include int main(int argc, char **argv) { int n, fd; fd = open("/tmp/test12345", O_RDWR | O_CREAT | O_EXCL, 0000); printf("fd=%d\n", fd); n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4); printf("extattr_set_fd() = %d\n", n); if (n != 0) printf("errno = %d (%s)\n", errno, strerror(errno)); exit(0); } From perryh at pluto.rain.com Sun Jan 11 21:24:56 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sun Jan 11 21:25:03 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <20090111160138.GA2386@keira.kiwi-computer.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> <20090111160138.GA2386@keira.kiwi-computer.com> Message-ID: <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> "Rick C. Petty" wrote: > On Sat, Jan 10, 2009 at 04:20:58AM -0800, perryh@pluto.rain.com wrote: > > "Rick C. Petty" wrote: > > > > > > That's not how devfs works. It's actually a feature > > > that devfs doesn't list everything ever possible > > > > http://storage9.myopera.com/freejerk/files/bug-feature.jpg > > Funny. But this isn't a bug disguised as a feature. > It's a feature that you believe is a bug. I would call it a bug that you believe is a feature. > > > I'd rather be able to list to see things that are in use, > > > although at first glance I didn't like devfs hidden nodes. > > > Otherwise you'd be stuck printing tunXXX through infinity > > > instead of this: > > > > > > % ls /dev/tun* > > > /dev/tun0 /dev/tun115 /dev/tun194 > > > > In any other part of the directory tree we expect ls to provide > > a list of names that are available to be opened (subject to > > permissions). Why should /dev be any different? > > Because it's a special filesystem. I think that constitutes an admission that it violates POLA, and it's not much of a justification IMO. > > Since you aren't supposed to open (say) /dev/tun85, but only > > /dev/tun0, correspondence between readdir and open would not > > demand > > What? Why aren't you supposed to open tun85? I use this behavior > all the time and have for years. It helps keep track of things. > Otherwise I would have to keep my natd configuration, firewall > rules, and openvpn configuration all in sync. Please provide a > reference describing you're not "supposed to" open any arbitrary > tunnelling device. The manpage for tun(4) says: tun does for network interfaces what the pty(4) driver does for terminals ... The network interfaces are named ``tun0'', ``tun1'', etc., one for each control device that has been opened ... The tun interface permits opens on the special control device /dev/tun. When this device is opened, tun will return a handle for the **lowest** unused tun device ... (emphasis added). The whole point of cloning devices is to avoid the need for the application to loop through a sequence of possible names to find one that is not in use; it simply opens the generic name and gets a (pseudo) device. BTW I was slightly off -- it is /dev/tun rather than /dev/tun0 that's supposed to be opened -- but if anything this strengthens my point (see below). > > that readdir return the (large, if not infinite) list of > > potential instances. It would however seem reasonable for > > that ls command to show /dev/tun0 if its driver is loaded, > > even if the device has not been instantiated because the > > node has never been opened. > > I don't buy that argument at all. If anything it should show > "/dev/tun", Agreed it should be /dev/tun -- see above. > but why create device nodes when they aren't necessary, as you > have to clone the nodes (or create new ones) when an actual > open(2) occurs? As I stated earlier in this thread: * It doesn't necessarily need to actually create them, but the * results from readdir(2) should be as if they had been created. > > > This is not a bug, it is designed behavior. It was > > > intentionally written to dynamically create device > > > nodes when needed. > > > > That the code faithfully adheres to the design does not > > guarantee that the design is flawless. IMO it violates > > POLA, if not POSIX, > > Please provide the reference where it violates POSIX. I am not familiar with POSIX in detail, which is why I only suggest that it *may* violate POSIX. You're welcome to research the matter. I would *expect* that research to find that there is supposed to be a correspondence between what readdir reports as the contents of a directory, and the results of attempting to open a filename in the directory whose contents were read; if not, what would be the point of having readdir in the first place? > > for open(2) to succeed when applied to a name which, according > > to readdir(2), does not exist; > > What? This can happen already-- there is no atomicity between > a readdir and an open. Of course not, but we are not dealing here with a case in which process A reads the directory, then process B creates a file in it, and thus that file becomes visible to process A. Instead we have a magical side-effect, wherein process A opens a file which (per readdir) does not exist, and thereby calls into existence a new file, while the name that process A opened *still* does not exist. > And what about msdosfs and case-insensitivity? You can > certainly open files that weren't a part of your readdir. The semantics of msdosfs are driven by the need to maintain compatibility with a certain other operating system -- the one which defined that filesystem representation in the first place. I hardly think it should be considered a good precedent. > Also no one in their right mind would be coding a readdir/open > solution against a filesystem known to be completely dynamic and > especially against devfs. You would want to tie in directly to > devctl, sysctl, or syscall. Programmatically, yes. But long-standing historical precedent, going back at least as far as the AT&T sixth research edition, would have an administrator or knowledgeable user believe that the contents of /dev are related to the collection of drivers that the system supports. The aspect of devfs that prevents the existence of orphan nodes in /dev is an excellent improvement which strengthens that precedent -- now I can find out from /dev not merely that the system supports a particular device in principle but also whether it actually has that device attached. Why would we want to trash that concept by allowing the existence of phantom drivers, which have no presence in /dev unless/until they have been opened? > > and it is suboptimal to have "stealth" drivers whose > > availability for use cannot be discovered by examining /dev. > > Why is it suboptimal? As in the case of the OP, it is suboptimal from the standpoint of a human who wants to know what devices and drivers exist in the system -- AFAIK the output of ls(1) is intended primarily for human consumption. Of course, for ls(1) to do its job, readdir(2) has to provide the data. > I think you have that backwards-- it's more optimal not to have to > create superfluous device nodes when they are not needed, at least > from the kernel efficiency perspective. If /dev/tun does not exist, how does an open on it succeed? Either there is special-case code that somehow scans the list of installed drivers in addition to examining the contents of /dev, or the node actually exists but readdir avoids reporting its existence. Either way, the kernel is having to do extra work to maintain the disagreement between the contents of the directory as reported by readdir and the list of names that are known to open. From rick-freebsd2008 at kiwi-computer.com Mon Jan 12 00:02:28 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Mon Jan 12 00:02:36 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> <20090111160138.GA2386@keira.kiwi-computer.com> <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> Message-ID: <20090112080227.GA8590@keira.kiwi-computer.com> On Sun, Jan 11, 2009 at 09:14:53PM -0800, perryh@pluto.rain.com wrote: > > > Funny. But this isn't a bug disguised as a feature. > > It's a feature that you believe is a bug. > > I would call it a bug that you believe is a feature. Not just me, but freebsd developers including those who wrote devfs. > > > In any other part of the directory tree we expect ls to provide > > > a list of names that are available to be opened (subject to > > > permissions). Why should /dev be any different? > > > > Because it's a special filesystem. > > I think that constitutes an admission that it violates POLA, > and it's not much of a justification IMO. Only you and a small group of people seem to be astonished by this, something that's been in FreeBSD since 4.0. Glad you're voicing your opinion now, before it's too late. > The manpage for tun(4) says: > > tun does for network interfaces what the pty(4) driver does for > terminals ... The network interfaces are named ``tun0'', ``tun1'', > etc., one for each control device that has been opened ... The tun > interface permits opens on the special control device /dev/tun. > When this device is opened, tun will return a handle for the > **lowest** unused tun device ... > > (emphasis added). The whole point of cloning devices is to avoid > the need for the application to loop through a sequence of possible > names to find one that is not in use; it simply opens the generic > name and gets a (pseudo) device. Yes, when using /dev/tun, you get the lowest. That's expected behavior. But it doesn't say not to use your own numbering. I'll stand by my previous statements. > > but why create device nodes when they aren't necessary, as you > > have to clone the nodes (or create new ones) when an actual > > open(2) occurs? > > As I stated earlier in this thread: > > * It doesn't necessarily need to actually create them, but the > * results from readdir(2) should be as if they had been created. I think you may find this is not as trivial as you make it sound. > > Please provide the reference where it violates POSIX. > > I am not familiar with POSIX in detail, which is why I only suggest > that it *may* violate POSIX. That much is obvious. > You're welcome to research the matter. No thanks, I've read it back to front. But you seem to imply that you're the expert, so I was hoping for you to point out how I've misread it. > I would *expect* that research to find that there is supposed to be > a correspondence between what readdir reports as the contents of a > directory, and the results of attempting to open a filename in the > directory whose contents were read; if not, what would be the point > of having readdir in the first place? Good point. We should probably rewrite syscalls to use vnode references instead of names. That would solve all ambiguity problems as well. > Of course not, but we are not dealing here with a case in which > process A reads the directory, then process B creates a file in > it, and thus that file becomes visible to process A. Instead we > have a magical side-effect, wherein process A opens a file which > (per readdir) does not exist, and thereby calls into existence a > new file, while the name that process A opened *still* does not > exist. There is nothing magical about it, nor did this just happen overnight. Perhaps it's not well-documented but it is well-known. > > And what about msdosfs and case-insensitivity? You can > > certainly open files that weren't a part of your readdir. > > The semantics of msdosfs are driven by the need to maintain > compatibility with a certain other operating system -- the one > which defined that filesystem representation in the first place. Just like devfs, which defined the filesystem representation that there are invisible nodes and pseudo-nodes. > I hardly think it should be considered a good precedent. Obviously kernel developers disagreed with you. > > Also no one in their right mind would be coding a readdir/open > > solution against a filesystem known to be completely dynamic and > > especially against devfs. You would want to tie in directly to > > devctl, sysctl, or syscall. > > Programmatically, yes. But long-standing historical precedent, > going back at least as far as the AT&T sixth research edition, > would have an administrator or knowledgeable user believe that the > contents of /dev are related to the collection of drivers that the > system supports. So we should go back to the precedent and make all dev entries static once again? You can't argue for progress in the same case that you argue for precedence. > actually has that device attached. Why would we want to trash that > concept by allowing the existence of phantom drivers, which have no > presence in /dev unless/until they have been opened? The drivers aren't phantom-- their instances are. > > Why is it suboptimal? > > As in the case of the OP, it is suboptimal from the standpoint of > a human who wants to know what devices and drivers exist in the > system You mean a human who does not understand enough about devfs to know its design quirks? This same human who does not care to look in /var/run/dmesg.boot? This same human who expects FreeBSD to behave as any other OS when it comes to device drivers and doesn't know to check /dev/sndstat? That's not what I think about when I hear the word "suboptimal". I think you're trying to argue that certain devfs semantics are confusing to beginners. I would call that perhaps "confusing" or perhaps "misleading" (which is a stretch). > -- AFAIK the output of ls(1) is intended primarily for human > consumption. Of course, for ls(1) to do its job, readdir(2) has to > provide the data. ls(1) is doing its job. Perhaps your argument for having one non-phantom device node appear for each driver is useful, but don't discount the utility and flexibility of phantom nodes in other cases. I agree that better documentation would also help. So I look forward to your patches for either of these areas. > > I think you have that backwards-- it's more optimal not to have to > > create superfluous device nodes when they are not needed, at least > > from the kernel efficiency perspective. > > If /dev/tun does not exist, how does an open on it succeed? Who says it doesn't exist? The open succeeds so it apparently does exist. In unix, there's never been a guarantee that after you readdir that an open will succeed, nor that a subsequent readdir will show the file you've opened. > Either there is special-case code that somehow scans the list of > installed drivers in addition to examining the contents of /dev, or > the node actually exists but readdir avoids reporting its existence. I don't think you understand how devices work (specifically, pseudo devices). You may wish to look at make_dev(9) and maybe source code for a device driver. > Either way, the kernel is having to do extra work to maintain the > disagreement between the contents of the directory as reported by > readdir and the list of names that are known to open. No, I believe it's less work this way, but I'm no expert here. I did not design devfs nor did I like it myself initially, but after time I grew to prefer it and its behavior. This issue about invisible device nodes has come up numerous times in the past and I believe its proponents and opponents have argued it to death which is why no one else is speaking up now. I encourage you to submit patches. Either you will find it more difficult your way or you may have a difficult time convincing others of its necessity. Just disagreeing with me will not change anything. -- Rick C. Petty From ota at j.email.ne.jp Mon Jan 12 02:25:14 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Mon Jan 12 02:25:20 2009 Subject: 3x read to write ratio on dump/restore In-Reply-To: <20090111041710.GB5661@server.vk2pj.dyndns.org> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> Message-ID: <20090112050537.f423215c.ota@j.email.ne.jp> Jermey, I tought you wrote this, http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html. Try GEOM Cache(gcache). It will be like, $ gcache create temp -s /dev/XXYsZ $ dump /dev/cache/temp <...> It's been 9 months since I tested so I don't remember about the detail numbers. However, I think it reduced user-time with dump to a half. I only wish gcache creates devices with .cache suffix like /dev/XXYsZ.cache. The cache cannot be shared among other providers anyway, it looks suffix style is more appropriate. Regards, Hiro On Sun, 11 Jan 2009 15:17:10 +1100 Peter Jeremy wrote: > On 2009-Jan-09 09:50:27 -0700, "M. Warner Losh" wrote: > >The read kBps was 3x the write kBps. > ... > >Any ideas what gives? I observed this with 16MB cache and with 32MB > >cache, fwiw. > > I've seen this as well. AFAIK, this is a side-effect of dump's caching. > > My top-of-head explanation is that each dump process has its own cache > but actual I/O is round-robined on a (roughly) block scale so a large > contiguous file will wind up in each 'slave' process's cache. > > The most obvious (and easiest) fixes are to either implement a shared > cache (though this means another level of inter-process communication) > or only use a single 'slave' process when caching is enabled. > > The cache algorithm could probably be enhanced as well - apart from > inode blocks, any block will only be accessed once so once a block has > been accessed, it can be purged from the cache (which is completely > opposite to a "normal" cache). > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > From christoph.mallon at gmx.de Mon Jan 12 03:07:57 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Mon Jan 12 03:10:03 2009 Subject: gcache [was: Re: 3x read to write ratio on dump/restore] In-Reply-To: <20090112050537.f423215c.ota@j.email.ne.jp> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> Message-ID: <496B1E47.1030403@gmx.de> Yoshihiro Ota schrieb: > Try GEOM Cache(gcache). Just a side note: gcache does not seem to have any documentation. "man gcache" is unsuccessful, geom(8) does not mention it (geom and gcache are the same hardlinked binary). Is there information about it somewhere? From roberto at keltia.freenix.fr Mon Jan 12 03:20:57 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Mon Jan 12 03:21:04 2009 Subject: 3x read to write ratio on dump/restore In-Reply-To: <20090109.095027.-1672857892.imp@bsdimp.com> References: <20090109.095027.-1672857892.imp@bsdimp.com> Message-ID: <20090112112046.GA52776@keltia.freenix.fr> According to M. Warner Losh: > The read kBps was 3x the write kBps. While the dump is going through > the raw device, and the restore is going through the file system, I > can't imagine why we'd have such a huge difference that would be utter > consistent for the whole 15 hour run. dump launches several processes to read the raw device and use a buffer between them whereas restore is single process. When copying from disk to disk, I often use team (sysutils/team) to stream. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Dons / donation Ondine : http://ondine.keltia.net/ From ivoras at freebsd.org Mon Jan 12 03:51:42 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Jan 12 03:51:49 2009 Subject: gcache [was: Re: 3x read to write ratio on dump/restore] In-Reply-To: <496B1E47.1030403@gmx.de> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> <496B1E47.1030403@gmx.de> Message-ID: Christoph Mallon wrote: > Yoshihiro Ota schrieb: >> Try GEOM Cache(gcache). > > Just a side note: gcache does not seem to have any documentation. "man > gcache" is unsuccessful, geom(8) does not mention it (geom and gcache > are the same hardlinked binary). Is there information about it somewhere? AFAIK it's very experimental, might not be there in this form in the future. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090112/f08ce4f2/signature.pgp From brueffer at FreeBSD.org Mon Jan 12 04:01:03 2009 From: brueffer at FreeBSD.org (Christian Brueffer) Date: Mon Jan 12 04:01:11 2009 Subject: gcache [was: Re: 3x read to write ratio on dump/restore] In-Reply-To: <496B1E47.1030403@gmx.de> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> <496B1E47.1030403@gmx.de> Message-ID: <20090112113057.GA1277@haakonia.hitnet.RWTH-Aachen.DE> On Mon, Jan 12, 2009 at 11:41:11AM +0100, Christoph Mallon wrote: > Yoshihiro Ota schrieb: > >Try GEOM Cache(gcache). > > Just a side note: gcache does not seem to have any documentation. "man > gcache" is unsuccessful, geom(8) does not mention it (geom and gcache > are the same hardlinked binary). Is there information about it somewhere? > _______________________________________________ A manpage for gcache is currently under review. Hopefully it will be committed in the next couple of days. - Christian -- Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090112/363ad3ad/attachment.pgp From brampton at gmail.com Mon Jan 12 04:15:42 2009 From: brampton at gmail.com (Andrew Brampton) Date: Mon Jan 12 04:28:06 2009 Subject: Determine if a kernel is built with a specific option? Message-ID: Hi, I was wondering how a autoconf configure script can determine if the kernel is built with a particular option. In this case the code I have can make use of the FreeBSD polling driver, which by default isn't built into a kernel. So I want my configure script to determine if the kernel supports it, if so sets a #define, otherwise doesn't. In the past I have basically hacked my way though these configure scripts by looking at other examples. One such example I found was for Linux, which does something like this: AC_CACHE_CHECK(for device polling kernel extension, ac_cv_linux_poll_extension, [if grep polling `find_linuxpath include/linux/netdevice.h` >/dev/null 2>&1; then ac_cv_linux_poll_extension=yes else ac_cv_linux_poll_extension=no; fi]) if test $ac_cv_linux_poll_extension = yes; then AC_DEFINE(HAVE_LINUX_POLLING) fi So I simply want to figure out an equalavant check I can do on FreeBSD. thanks Andrew From m.seaman at infracaninophile.co.uk Mon Jan 12 04:31:08 2009 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Mon Jan 12 04:31:15 2009 Subject: gcache [was: Re: 3x read to write ratio on dump/restore] In-Reply-To: <20090112113057.GA1277@haakonia.hitnet.RWTH-Aachen.DE> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> <496B1E47.1030403@gmx.de> <20090112113057.GA1277@haakonia.hitnet.RWTH-Aachen.DE> Message-ID: <496B37FD.7040209@infracaninophile.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Christian Brueffer wrote: | On Mon, Jan 12, 2009 at 11:41:11AM +0100, Christoph Mallon wrote: |> Yoshihiro Ota schrieb: |>> Try GEOM Cache(gcache). |> Just a side note: gcache does not seem to have any documentation. "man |> gcache" is unsuccessful, geom(8) does not mention it (geom and gcache |> are the same hardlinked binary). Is there information about it somewhere? |> _______________________________________________ | | A manpage for gcache is currently under review. Hopefully it will be | committed in the next couple of days. Unfortunate name clash with apache13-ssl's gcache though. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. Flat 3 ~ 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate ~ Kent, CT11 9PW, UK -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREDAAYFAklrN/0ACgkQ8Mjk52CukIxRcwCfQYWp6FHjrsFn0u3MBofWlhNg mhgAnRz2zNyW4WSe8W8Lc+0XK49LVPud =trWs -----END PGP SIGNATURE----- From pluknet at gmail.com Mon Jan 12 05:00:31 2009 From: pluknet at gmail.com (pluknet) Date: Mon Jan 12 05:00:45 2009 Subject: Determine if a kernel is built with a specific option? In-Reply-To: References: Message-ID: 2009/1/12 Andrew Brampton : > Hi, > I was wondering how a autoconf configure script can determine if the > kernel is built with a particular option. In this case the code I have > can make use of the FreeBSD polling driver, which by default isn't > built into a kernel. So I want my configure script to determine if the > kernel supports it, if so sets a #define, otherwise doesn't. > > In the past I have basically hacked my way though these configure > scripts by looking at other examples. One such example I found was for > Linux, which does something like this: > > AC_CACHE_CHECK(for device polling kernel extension, ac_cv_linux_poll_extension, > [if grep polling `find_linuxpath include/linux/netdevice.h` >/dev/null > 2>&1; then > ac_cv_linux_poll_extension=yes > else ac_cv_linux_poll_extension=no; fi]) > if test $ac_cv_linux_poll_extension = yes; then > AC_DEFINE(HAVE_LINUX_POLLING) > fi > > So I simply want to figure out an equalavant check I can do on FreeBSD. > Hi. You may look at sysctl kern.polling presence. -- wbr, pluknet From bsd.quest at googlemail.com Mon Jan 12 05:48:00 2009 From: bsd.quest at googlemail.com (Alexej Sokolov) Date: Mon Jan 12 05:48:06 2009 Subject: panic by unlocking of mutex in KLD Message-ID: <20090112134726.GA2988@debian.samsung.router> Hello, by unloading of folowing module I have kernel panic. I would like to get any explanation about my mistake. #include #include #include #include #include #include #include #include #include #include #include struct mtx my_mtx; /* Load handler */ static int load(struct module *mod, int cmd, void *arg) { int error = 0; switch(cmd) { case MOD_LOAD: printf("Start! Addres of mutex = 0x%X \n", &my_mtx); mtx_init(&my_mtx, "My mutex name", "My mutex type", MTX_DEF); mtx_lock(&my_mtx); break; case MOD_UNLOAD: printf("Stop! Addres of mutex = 0x%X \n", &my_mtx); mtx_unlock(&my_mtx); break; default: error = EOPNOTSUPP; break; } return (error); } /* Module structure */ static moduledata_t mod_data = { "mymod", load, NULL }; MODULE_VERSION (kld, 1); DECLARE_MODULE (kld, mod_data, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); Thanx -- Alexej Sokolov From mjguzik at gmail.com Mon Jan 12 06:10:32 2009 From: mjguzik at gmail.com (Mateusz Guzik) Date: Mon Jan 12 06:10:39 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <20090112134726.GA2988@debian.samsung.router> References: <20090112134726.GA2988@debian.samsung.router> Message-ID: <20090112141029.GA31108@skucha> On Mon, Jan 12, 2009 at 02:47:26PM +0100, Alexej Sokolov wrote: > Hello, > > by unloading of folowing module I have kernel panic. > > I would like to get any explanation about my mistake. > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > > struct mtx my_mtx; > > > /* Load handler */ > static int > load(struct module *mod, int cmd, void *arg) > { > int error = 0; > switch(cmd) { > case MOD_LOAD: > printf("Start! Addres of mutex = 0x%X \n", > &my_mtx); > mtx_init(&my_mtx, "My mutex name", "My mutex > type", MTX_DEF); > > mtx_lock(&my_mtx); > break; > case MOD_UNLOAD: > printf("Stop! Addres of mutex = 0x%X \n", > &my_mtx); > mtx_unlock(&my_mtx); > break; > default: > error = EOPNOTSUPP; > break; > } > > return (error); > } > > /* Module structure */ > static moduledata_t mod_data = { > "mymod", > load, > NULL > }; > MODULE_VERSION (kld, 1); > DECLARE_MODULE (kld, mod_data, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); > > Acutally it panics even on loading. :) Mutexes have owners. It panics on loading because processes cannot return to userland with locks held. It panics on unloading (in your case) because curproc != my_mtx's owner. -- Mateusz Guzik From des at des.no Mon Jan 12 06:39:23 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jan 12 06:39:35 2009 Subject: "/var/log/messages" logs appear in the output of "sysctl -a" In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> (Eitan Shefi's message of "Wed, 7 Jan 2009 13:30:20 +0200") References: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> Message-ID: <86hc447fmu.fsf@ds4.des.no> "Eitan Shefi" writes: > I run "sysctl -a | less" why? DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Mon Jan 12 06:45:11 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jan 12 06:45:17 2009 Subject: /dev/dsp* & /dev/audio* devices not present In-Reply-To: <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> (perryh@pluto.rain.com's message of "Sun, 11 Jan 2009 21:14:53 -0800") References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> <20090111160138.GA2386@keira.kiwi-computer.com> <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> Message-ID: <86d4es7fd6.fsf@ds4.des.no> perryh@pluto.rain.com writes: > "Rick C. Petty" writes: > > Funny. But this isn't a bug disguised as a feature. > > It's a feature that you believe is a bug. > I would call it a bug that you believe is a feature. It is *by definition* a feature. The code works as intended. If it didn't, that would be a bug. The fact that you wish the code worked differently doesn't make it a bug. Anyway, you can complain until you're blue in the face, but it's not going to change, for a number of very good reasons (which have mostly been listed in other posts in this thread). DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Mon Jan 12 06:50:57 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jan 12 06:51:04 2009 Subject: kernel panic In-Reply-To: <20090111083300.GC7054@server.vk2pj.dyndns.org> (Peter Jeremy's message of "Sun, 11 Jan 2009 19:33:00 +1100") References: <468090.72533.qm@web45413.mail.sp1.yahoo.com> <20090111083300.GC7054@server.vk2pj.dyndns.org> Message-ID: <868wpg7f3k.fsf@ds4.des.no> Peter Jeremy writes: > Kamlesh Patel writes: > > How do i recover the system from this error. I can't reload the > > loader.old > > If you press any key during the first spinner [...] You can then > enter the name of the program you wish to run - eg /boot/loader.old That won't work - he changed the forth code, not the compiled code. > (or directly load /boot/kernel/kernel) That will work. DES -- Dag-Erling Sm?rgrav - des@des.no From brampton+freebsd-hackers at gmail.com Mon Jan 12 06:56:24 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Mon Jan 12 06:56:30 2009 Subject: Determine if a kernel is built with a specific option? In-Reply-To: <20090112145131.GA4375@svzserv.kemerovo.su> References: <20090112145131.GA4375@svzserv.kemerovo.su> Message-ID: 2009/1/12 Eugene Grosbein : >> I was wondering how a autoconf configure script can determine if the >> kernel is built with a particular option. In this case the code I have >> can make use of the FreeBSD polling driver, which by default isn't >> built into a kernel. So I want my configure script to determine if the >> kernel supports it, if so sets a #define, otherwise doesn't. > > You should not assume that compiled code does not need polling support > just because _buildbox_ doesn't have it enabled in time of build. > If the code builds here, it does not mean it will run here. > > Eugene Grosbein > Thanks for your comments Eugene. I know that is a bad assumption to make, but I'm basically updating someone else's software which already had that assumption for Linux. If you were going to do this, would you make it a configure flag... ie --enable-polling... That way it doesn't matter if the build box is different? thanks Andrew From hselasky at c2i.net Mon Jan 12 06:58:08 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jan 12 06:58:15 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <20090112134726.GA2988@debian.samsung.router> References: <20090112134726.GA2988@debian.samsung.router> Message-ID: <200901121500.21657.hselasky@c2i.net> On Monday 12 January 2009, Alexej Sokolov wrote: > Hello, > > by unloading of folowing module I have kernel panic. > > I would like to get any explanation about my mistake. > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > > struct mtx my_mtx; > > > /* Load handler */ > static int > load(struct module *mod, int cmd, void *arg) > { > int error = 0; > switch(cmd) { > case MOD_LOAD: > printf("Start! Addres of mutex = 0x%X \n", > &my_mtx); > mtx_init(&my_mtx, "My mutex name", "My mutex > type", MTX_DEF); > > mtx_lock(&my_mtx); > break; > case MOD_UNLOAD: > printf("Stop! Addres of mutex = 0x%X \n", > &my_mtx); > mtx_unlock(&my_mtx); > break; > default: > error = EOPNOTSUPP; > break; > } > > return (error); > } > > /* Module structure */ > static moduledata_t mod_data = { > "mymod", > load, > NULL > }; > MODULE_VERSION (kld, 1); > DECLARE_MODULE (kld, mod_data, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); > > > Thanx Hi, You cannot do like this. Remember, two different threads are doing the load/unload. The mutex is associated with a thread. Print out "curthread" aswell and you will see. The mutex can only be unlocked by the same thread that locked it. --HPS From eugen at kuzbass.ru Mon Jan 12 06:51:34 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Jan 12 07:17:01 2009 Subject: Determine if a kernel is built with a specific option? In-Reply-To: References: Message-ID: <20090112145131.GA4375@svzserv.kemerovo.su> > I was wondering how a autoconf configure script can determine if the > kernel is built with a particular option. In this case the code I have > can make use of the FreeBSD polling driver, which by default isn't > built into a kernel. So I want my configure script to determine if the > kernel supports it, if so sets a #define, otherwise doesn't. You should not assume that compiled code does not need polling support just because _buildbox_ doesn't have it enabled in time of build. If the code builds here, it does not mean it will run here. Eugene Grosbein From rwatson at FreeBSD.org Mon Jan 12 07:45:45 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jan 12 07:45:51 2009 Subject: extattr problems? In-Reply-To: <496ABD9A.8080006@freebsd.org> References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> <496AA714.1090904@freebsd.org> <496ABD9A.8080006@freebsd.org> Message-ID: On Sun, 11 Jan 2009, Tim Kientzle wrote: > I think this one is a bug. It appears that extattr_set_fd() obeys the > permissions on the file, not the permissions of the descriptor. In > particular, I see this on FreeBSD 6.3: Hmm. Not clear. EAs live in a slightly hazy world between data and meta-data. Normally you can perform operations like fchmod(2), which are strictly meta-data operations, regardless of the flags of the file descriptor they are performed on, subject to ownership/permissions. With NFSv4 ACLs, where the right to change ACLs can be delegated, this only becomes more true. I've chosen to generally treat EAs as meta-data in this regard, where the file descriptor simply names the object rather than as an access method as occurs with write(), etc. How do other systems handle this -- for example, Linux, with its notion of user vs. system namespaces? Robert N M Watson Computer Laboratory University of Cambridge > > [tim@dark /tmp]$ ./extattr_test > fd=3 > extattr_set_fd() = -1 > errno = 13 (Permission denied) > [tim@dark /tmp]$ cat extattr_test.c > #include > #include > #include > #include > #include > > int > main(int argc, char **argv) > { > int n, fd; > > fd = open("/tmp/test12345", O_RDWR | O_CREAT | O_EXCL, 0000); > printf("fd=%d\n", fd); > n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, > "testattr", "1234", 4); > printf("extattr_set_fd() = %d\n", n); > if (n != 0) > printf("errno = %d (%s)\n", > errno, strerror(errno)); > exit(0); > } > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From thompsa at FreeBSD.org Mon Jan 12 08:03:07 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Mon Jan 12 08:03:14 2009 Subject: Determine if a kernel is built with a specific option? In-Reply-To: References: Message-ID: <20090112153620.GA76347@citylink.fud.org.nz> On Mon, Jan 12, 2009 at 11:55:11AM +0000, Andrew Brampton wrote: > Hi, > I was wondering how a autoconf configure script can determine if the > kernel is built with a particular option. In this case the code I have > can make use of the FreeBSD polling driver, which by default isn't > built into a kernel. So I want my configure script to determine if the > kernel supports it, if so sets a #define, otherwise doesn't. > > In the past I have basically hacked my way though these configure > scripts by looking at other examples. One such example I found was for > Linux, which does something like this: > > AC_CACHE_CHECK(for device polling kernel extension, ac_cv_linux_poll_extension, > [if grep polling `find_linuxpath include/linux/netdevice.h` >/dev/null > 2>&1; then > ac_cv_linux_poll_extension=yes > else ac_cv_linux_poll_extension=no; fi]) > if test $ac_cv_linux_poll_extension = yes; then > AC_DEFINE(HAVE_LINUX_POLLING) > fi > > So I simply want to figure out an equalavant check I can do on FreeBSD. I believe the correct way is to read kern.features from sysctl and the appropriate code marks it with FEATURE(name, "description"); Having said that the polling code does not set this so would need to be added. Andrew From bsd.quest at googlemail.com Mon Jan 12 08:19:57 2009 From: bsd.quest at googlemail.com (Alexej Sokolov) Date: Mon Jan 12 08:20:04 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <20090112141029.GA31108@skucha> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> Message-ID: <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> 2009/1/12 Mateusz Guzik > On Mon, Jan 12, 2009 at 02:47:26PM +0100, Alexej Sokolov wrote: > > Hello, > > > > by unloading of folowing module I have kernel panic. > > > > I would like to get any explanation about my mistake. > > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > > > struct mtx my_mtx; > > > > > > /* Load handler */ > > static int > > load(struct module *mod, int cmd, void *arg) > > { > > int error = 0; > > switch(cmd) { > > case MOD_LOAD: > > printf("Start! Addres of mutex = 0x%X \n", > > &my_mtx); > > mtx_init(&my_mtx, "My mutex name", "My mutex > > type", MTX_DEF); > > > > mtx_lock(&my_mtx); > > break; > > case MOD_UNLOAD: > > printf("Stop! Addres of mutex = 0x%X \n", > > &my_mtx); > > mtx_unlock(&my_mtx); > > break; > > default: > > error = EOPNOTSUPP; > > break; > > } > > > > return (error); > > } > > > > /* Module structure */ > > static moduledata_t mod_data = { > > "mymod", > > load, > > NULL > > }; > > MODULE_VERSION (kld, 1); > > DECLARE_MODULE (kld, mod_data, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); > > > > > > Acutally it panics even on loading. :) Thanks, a lot. Yes, in this case the different processes try to lock and unlock the same mutex. Stupid mistake! But... > > > Mutexes have owners. It panics on loading because processes cannot > return to userland with locks held. i am not sure about it. Some time ago i implemented a charecter device with two syscalls: write, read. "write" lock the mutex and "read" unlock it. The user space programm opens device, then mekes "write" (mutex will held in kernel), goes back to user space, then makes "read" (mutex will unlocked in kernel) and it all run without panic. If needed i can post the source code. > It panics on unloading (in your > case) because curproc != my_mtx's owner. > > -- > Mateusz Guzik > Thanks, Alexej From brampton+freebsd-hackers at gmail.com Mon Jan 12 08:27:12 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Mon Jan 12 08:27:18 2009 Subject: Determine if a kernel is built with a specific option? In-Reply-To: <873afolcrh.fsf@kobe.laptop> References: <20090112145131.GA4375@svzserv.kemerovo.su> <873afolcrh.fsf@kobe.laptop> Message-ID: 2009/1/12 Giorgos Keramidas : > On Mon, 12 Jan 2009 14:56:21 +0000, "Andrew Brampton" wrote: >> If you were going to do this, would you make it a configure flag... ie >> --enable-polling... That way it doesn't matter if the build box is >> different? > > If both choices are available (i.e. no header files are missing, no > link-time libraries are unavailable, and so on), I'd probably make it a > runtime option: That is the problem, if polling is enabled there are some symbols which are required which are unavailable if running on a GENERIC kernel. By turning off polling, different #defines are used in the code, removing any calls to the kernel polling functions. So as much as I was like to make this a runtime option, I don't think I can. > > * A configure-time flag to set the 'default' and > > * A runtime option to explicitly specify the current preference when > the program runs. > > This seems a bit more flexible, and does not require an expensive ``go > back to your vendor, and ask for a special build-time option'' cycle to > test different setups when a field installation is done. > Thanks to everyone that has replied. I think I'm just going to make this a configure flag, and if the target system doesn't have a suitable kernel then the software (or kernel) will have to be rebuilt. thanks for your wisdom Andrew From kientzle at freebsd.org Mon Jan 12 08:44:52 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Jan 12 08:44:58 2009 Subject: extattr problems? In-Reply-To: References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> <496AA714.1090904@freebsd.org> <496ABD9A.8080006@freebsd.org> Message-ID: <496B7380.10804@freebsd.org> Robert Watson wrote: > On Sun, 11 Jan 2009, Tim Kientzle wrote: > >> I think this one is a bug. It appears that extattr_set_fd() obeys the >> permissions on the file, not the permissions of the descriptor. > > Hmm. Not clear. EAs live in a slightly hazy world between data and > meta-data. Normally you can perform operations like fchmod(2), which > are strictly meta-data operations, regardless of the flags of the file > descriptor they are performed on, subject to ownership/permissions. You can always call fchmod() on a newly-created file. But you cannot currently always call extattr_set_fd() on a newly created file. So extattr_set_fd() does not currently behave like other metadata operations. > With NFSv4 ACLs, where the right to change ACLs can be delegated, this > only becomes more true. I've chosen to generally treat EAs as meta-data > in this regard, where the file descriptor simply names the object rather > than as an access method as occurs with write(), etc. Hmmmm.... Then what is the secure way to create a file with no write permissions and EAs? The policy you've adopted means that you must open write permissions on the file even if the final file should not have such permissions. I'm also unclear about your reasoning here. There are only two ways to get a writable FD: You have write permissions on an existing file (or rather, *had* write permissions at the time you opened it), or you've just created the file. The former case would seem to cover your concerns here; I see no justification for disallowing the latter. I'm especially unhappy about this in the case of tar because it means I would have to introduce another system call (an otherwise-redundant fchmod()) into the performance-critical file creation path, not to mention some rather ugly logic to modify modes on newly created files if that file has extattrs and you're on FreeBSD. > How do other > systems handle this -- for example, Linux, with its notion of user vs. > system namespaces? I need to do some more research here. I'll let you know what I find. Tim From mjguzik at gmail.com Mon Jan 12 09:39:26 2009 From: mjguzik at gmail.com (Mateusz Guzik) Date: Mon Jan 12 09:39:35 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> Message-ID: <20090112173913.GA2102@skucha> On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > > Mutexes have owners. It panics on loading because processes cannot > > return to userland with locks held. > > i am not sure about it. Some time ago i implemented a charecter device with > two syscalls: write, read. "write" lock the mutex and "read" unlock it. The > user space programm opens device, then mekes "write" (mutex will held in > kernel), goes back to user space, then makes "read" (mutex will unlocked in > kernel) and it all run without panic. If needed i can post the source code. > Do you have kernel compiled with WITNESS? At least on -CURRENT the kernel panicked like this (while loading your module): System call kldload returning with 1 locks held -- Mateusz Guzik From bsd.quest at googlemail.com Mon Jan 12 10:16:53 2009 From: bsd.quest at googlemail.com (Alexej Sokolov) Date: Mon Jan 12 10:17:00 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <20090112173913.GA2102@skucha> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> Message-ID: <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> 2009/1/12 Mateusz Guzik > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > 2009/1/12 Mateusz Guzik > > > Mutexes have owners. It panics on loading because processes cannot > > > return to userland with locks held. > > > > i am not sure about it. Some time ago i implemented a charecter device > with > > two syscalls: write, read. "write" lock the mutex and "read" unlock it. > The > > user space programm opens device, then mekes "write" (mutex will held in > > kernel), goes back to user space, then makes "read" (mutex will unlocked > in > > kernel) and it all run without panic. If needed i can post the source > code. > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > kernel panicked like this (while loading your module): > > System call kldload returning with 1 locks held My kernel is compiled without WITNESS. And it allows to lock mutex in one systcall (for example "write") and to unlock it in other ("read"). Do you mean it is "very bad idea" to do something like this ? I could not find anywhere in the documentation that a it is not allowed to return in the user space with a locked mutex. Can you give me some reference on man page, source code or something other from where can I understand it ? Thanx a lot, Alexej > > > -- > Mateusz Guzik > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From yanefbsd at gmail.com Mon Jan 12 10:47:14 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jan 12 10:47:20 2009 Subject: kernel panic In-Reply-To: <868wpg7f3k.fsf@ds4.des.no> References: <468090.72533.qm@web45413.mail.sp1.yahoo.com> <20090111083300.GC7054@server.vk2pj.dyndns.org> <868wpg7f3k.fsf@ds4.des.no> Message-ID: <7d6fde3d0901121020j52e8b6b4saf8ad10b10df4ae1@mail.gmail.com> On Mon, Jan 12, 2009 at 6:50 AM, Dag-Erling Sm?rgrav wrote: > Peter Jeremy writes: >> Kamlesh Patel writes: >> > How do i recover the system from this error. I can't reload the >> > loader.old >> >> If you press any key during the first spinner [...] You can then >> enter the name of the program you wish to run - eg /boot/loader.old > > That won't work - he changed the forth code, not the compiled code. > >> (or directly load /boot/kernel/kernel) > > That will work. > > DES Maybe this? - Grab the liveCD (ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/7.0/7.0-RELEASE-i386-livefs.iso, or ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/7.0/7.0-RELEASE-amd64-livefs.iso). Don't grab the 7.1 ones because they don't boot on all systems (it's in the release notes). - Mount your system. - chroot /wherever/your/install/is/mounted /bin/tcsh - Repeat steps to compile and install kernel Cheers, -Garrett From des at des.no Mon Jan 12 11:23:14 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jan 12 11:23:27 2009 Subject: kernel panic In-Reply-To: <7d6fde3d0901121020j52e8b6b4saf8ad10b10df4ae1@mail.gmail.com> (Garrett Cooper's message of "Mon, 12 Jan 2009 10:20:29 -0800") References: <468090.72533.qm@web45413.mail.sp1.yahoo.com> <20090111083300.GC7054@server.vk2pj.dyndns.org> <868wpg7f3k.fsf@ds4.des.no> <7d6fde3d0901121020j52e8b6b4saf8ad10b10df4ae1@mail.gmail.com> Message-ID: <86k590fhwf.fsf@ds4.des.no> "Garrett Cooper" writes: > Dag-Erling Sm?rgrav writes: > > Peter Jeremy writes: > > > If you press any key during the first spinner [...] You can then > > > enter the name of the program you wish to run - eg /boot/loader.old > > That won't work - he changed the forth code, not the compiled code. > [...] > - Repeat steps to compile and install kernel which will achieve absolutely nothing, since the bug is in the forth code, not in the kernel or any other compiled code. DES -- Dag-Erling Sm?rgrav - des@des.no From mjguzik at gmail.com Mon Jan 12 11:28:24 2009 From: mjguzik at gmail.com (Mateusz Guzik) Date: Mon Jan 12 11:28:30 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> Message-ID: <20090112192822.GB2102@skucha> On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > 2009/1/12 Mateusz Guzik > > > > Mutexes have owners. It panics on loading because processes cannot > > > > return to userland with locks held. > > > > > > i am not sure about it. Some time ago i implemented a charecter device > > with > > > two syscalls: write, read. "write" lock the mutex and "read" unlock it. > > The > > > user space programm opens device, then mekes "write" (mutex will held in > > > kernel), goes back to user space, then makes "read" (mutex will unlocked > > in > > > kernel) and it all run without panic. If needed i can post the source > > code. > > > > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > > kernel panicked like this (while loading your module): > > > > System call kldload returning with 1 locks held > > My kernel is compiled without WITNESS. And it allows to lock mutex in one > systcall (for example "write") and to unlock it in other ("read"). > Do you mean it is "very bad idea" to do something like this ? > I could not find anywhere in the documentation that a it is not allowed to > return in the user space with a locked mutex. > Can you give me some reference on man page, source code or something other > from where can I understand it ? > Locks are used to synchronize access to data changeable by other threads. I don't know if I'm correct here, but let's consider the following situation: your process grabs a mutex and returns to userland, then it's killed due to segmentation violation. This mutex should (and can be) unlocked on exit, but the state of data protected by it is unknown. (For example your process was killed while inserting something into linked list.) So even if the kernel could be guided to unlock it on exit, the data could be in inconsistent state. Also your locking scheme doesn't make much sense. Consider this: proc1 calls write on your cdev but in the meantime proc2 calls read on your cdev So you get panic because proc1 was writing some data. (attempt to unlock mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would read inconsistend data because proc1 was writing. Proper solution is to lock mutex before and after reading/writing data. For working example you can check how devctl was implemented (sys/kern/subr_bus.c). -- Mateusz Guzik From bsd.quest at googlemail.com Mon Jan 12 11:50:00 2009 From: bsd.quest at googlemail.com (Alexej Sokolov) Date: Mon Jan 12 11:50:07 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <20090112192822.GB2102@skucha> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> Message-ID: <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com> 2009/1/12 Mateusz Guzik > On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > > 2009/1/12 Mateusz Guzik > > > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > > 2009/1/12 Mateusz Guzik > > > > > Mutexes have owners. It panics on loading because processes cannot > > > > > return to userland with locks held. > > > > > > > > i am not sure about it. Some time ago i implemented a charecter > device > > > with > > > > two syscalls: write, read. "write" lock the mutex and "read" unlock > it. > > > The > > > > user space programm opens device, then mekes "write" (mutex will held > in > > > > kernel), goes back to user space, then makes "read" (mutex will > unlocked > > > in > > > > kernel) and it all run without panic. If needed i can post the source > > > code. > > > > > > > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > > > kernel panicked like this (while loading your module): > > > > > > System call kldload returning with 1 locks held > > > > My kernel is compiled without WITNESS. And it allows to lock mutex in one > > systcall (for example "write") and to unlock it in other ("read"). > > Do you mean it is "very bad idea" to do something like this ? > > I could not find anywhere in the documentation that a it is not allowed > to > > return in the user space with a locked mutex. > > Can you give me some reference on man page, source code or something > other > > from where can I understand it ? > > > > Locks are used to synchronize access to data changeable by other > threads. I don't know if I'm correct here, but let's consider the > following situation: your process grabs a mutex and returns to userland, > then it's killed due to segmentation violation. This mutex should (and > can be) unlocked on exit, but the state of data protected by it is > unknown. (For example your process was killed while inserting something > into linked list.) So even if the kernel could be guided to unlock it on > exit, the data could be in inconsistent state. > > Also your locking scheme doesn't make much sense. Consider this: > proc1 calls write on your cdev > but in the meantime > proc2 calls read on your cdev > > So you get panic because proc1 was writing some data. (attempt to unlock > mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would > read inconsistend data because proc1 was writing. Proper solution is to > lock mutex before and after reading/writing data. For working example > you can check how devctl was implemented (sys/kern/subr_bus.c). > > -- > Mateusz Guzik > Ok , now I understaand it. If a thread return to user space with locked mutex, kernel doesen't know if the thread will come back to unlock it. It is really unsafe return to userspace without unlocking of helding mutexes. Thanks a lot for your help. From bsd.quest at googlemail.com Mon Jan 12 11:50:55 2009 From: bsd.quest at googlemail.com (Alexej Sokolov) Date: Mon Jan 12 11:51:12 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <20090112192822.GB2102@skucha> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> Message-ID: <671bb5fc0901121150s1951ab0cm646818ab3d12134e@mail.gmail.com> 2009/1/12 Mateusz Guzik > On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > > 2009/1/12 Mateusz Guzik > > > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > > 2009/1/12 Mateusz Guzik > > > > > Mutexes have owners. It panics on loading because processes cannot > > > > > return to userland with locks held. > > > > > > > > i am not sure about it. Some time ago i implemented a charecter > device > > > with > > > > two syscalls: write, read. "write" lock the mutex and "read" unlock > it. > > > The > > > > user space programm opens device, then mekes "write" (mutex will held > in > > > > kernel), goes back to user space, then makes "read" (mutex will > unlocked > > > in > > > > kernel) and it all run without panic. If needed i can post the source > > > code. > > > > > > > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > > > kernel panicked like this (while loading your module): > > > > > > System call kldload returning with 1 locks held > > > > My kernel is compiled without WITNESS. And it allows to lock mutex in one > > systcall (for example "write") and to unlock it in other ("read"). > > Do you mean it is "very bad idea" to do something like this ? > > I could not find anywhere in the documentation that a it is not allowed > to > > return in the user space with a locked mutex. > > Can you give me some reference on man page, source code or something > other > > from where can I understand it ? > > > > Locks are used to synchronize access to data changeable by other > threads. I don't know if I'm correct here, but let's consider the > following situation: your process grabs a mutex and returns to userland, > then it's killed due to segmentation violation. This mutex should (and > can be) unlocked on exit, but the state of data protected by it is > unknown. (For example your process was killed while inserting something > into linked list.) So even if the kernel could be guided to unlock it on > exit, the data could be in inconsistent state. > > Also your locking scheme doesn't make much sense. Consider this: > proc1 calls write on your cdev > but in the meantime > proc2 calls read on your cdev > > So you get panic because proc1 was writing some data. (attempt to unlock > mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would > read inconsistend data because proc1 was writing. Proper solution is to > lock mutex before and after reading/writing data. For working example > you can check how devctl was implemented (sys/kern/subr_bus.c). > > -- > Mateusz Guzik > Ok , now I understaand it. If a thread return to user space with locked mutex, kernel doesen't know if the thread will come back to unlock it. It is really unsafe return to userspace without unlocking of helding mutexes. Thanks a lot for your help. From keramida at ceid.upatras.gr Mon Jan 12 12:07:15 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Mon Jan 12 12:07:21 2009 Subject: Determine if a kernel is built with a specific option? In-Reply-To: (Andrew Brampton's message of "Mon, 12 Jan 2009 14:56:21 +0000") References: <20090112145131.GA4375@svzserv.kemerovo.su> Message-ID: <873afolcrh.fsf@kobe.laptop> On Mon, 12 Jan 2009 14:56:21 +0000, "Andrew Brampton" wrote: > If you were going to do this, would you make it a configure flag... ie > --enable-polling... That way it doesn't matter if the build box is > different? If both choices are available (i.e. no header files are missing, no link-time libraries are unavailable, and so on), I'd probably make it a runtime option: * A configure-time flag to set the 'default' and * A runtime option to explicitly specify the current preference when the program runs. This seems a bit more flexible, and does not require an expensive ``go back to your vendor, and ask for a special build-time option'' cycle to test different setups when a field installation is done. From mjguzik at gmail.com Mon Jan 12 12:22:09 2009 From: mjguzik at gmail.com (Mateusz Guzik) Date: Mon Jan 12 12:22:16 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com> Message-ID: <20090112202152.GC2102@skucha> On Mon, Jan 12, 2009 at 08:49:59PM +0100, Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > > > On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > > > 2009/1/12 Mateusz Guzik > > > > > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > > > 2009/1/12 Mateusz Guzik > > > > > > Mutexes have owners. It panics on loading because processes cannot > > > > > > return to userland with locks held. > > > > > > > > > > i am not sure about it. Some time ago i implemented a charecter > > device > > > > with > > > > > two syscalls: write, read. "write" lock the mutex and "read" unlock > > it. > > > > The > > > > > user space programm opens device, then mekes "write" (mutex will held > > in > > > > > kernel), goes back to user space, then makes "read" (mutex will > > unlocked > > > > in > > > > > kernel) and it all run without panic. If needed i can post the source > > > > code. > > > > > > > > > > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > > > > kernel panicked like this (while loading your module): > > > > > > > > System call kldload returning with 1 locks held > > > > > > My kernel is compiled without WITNESS. And it allows to lock mutex in one > > > systcall (for example "write") and to unlock it in other ("read"). > > > Do you mean it is "very bad idea" to do something like this ? > > > I could not find anywhere in the documentation that a it is not allowed > > to > > > return in the user space with a locked mutex. > > > Can you give me some reference on man page, source code or something > > other > > > from where can I understand it ? > > > > > > > Locks are used to synchronize access to data changeable by other > > threads. I don't know if I'm correct here, but let's consider the > > following situation: your process grabs a mutex and returns to userland, > > then it's killed due to segmentation violation. This mutex should (and > > can be) unlocked on exit, but the state of data protected by it is > > unknown. (For example your process was killed while inserting something > > into linked list.) So even if the kernel could be guided to unlock it on > > exit, the data could be in inconsistent state. > > > > Also your locking scheme doesn't make much sense. Consider this: > > proc1 calls write on your cdev > > but in the meantime > > proc2 calls read on your cdev > > > > So you get panic because proc1 was writing some data. (attempt to unlock > > mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would > > read inconsistend data because proc1 was writing. Proper solution is to > > lock mutex before and after reading/writing data. For working example > > you can check how devctl was implemented (sys/kern/subr_bus.c). > > > > -- > > Mateusz Guzik > > > > Ok , now I understaand it. > If a thread return to user space with locked mutex, kernel doesen't know if > the thread will come back to unlock it. It is really unsafe return to > userspace without unlocking of helding mutexes. > Provided example is really unfortunate. :/ Forget it. (And a proper solution for your locking issue is of course to lock mutex before read/write and *unlock* it after it's done. (missed that word in my previous mail)) Threads in userland holding kernel locks would lead to panics in a lot of situations. For example you already have sleepable mutex and call some kernel function that acquires sx lock - the kernel panics as this is not allowed combination. -- Mateusz Guzik From julian at elischer.org Mon Jan 12 12:41:01 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Jan 12 12:41:09 2009 Subject: panic by unlocking of mutex in KLD In-Reply-To: <671bb5fc0901121150s1951ab0cm646818ab3d12134e@mail.gmail.com> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> <671bb5fc0901121150s1951ab0cm646818ab3d12134e@mail.gmail.com> Message-ID: <496BA428.8040102@elischer.org> Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > >> On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: >>> 2009/1/12 Mateusz Guzik >>> >>>> On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: >>>>> 2009/1/12 Mateusz Guzik >>>>>> Mutexes have owners. It panics on loading because processes cannot >>>>>> return to userland with locks held. >>>>> i am not sure about it. Some time ago i implemented a charecter >> device >>>> with >>>>> two syscalls: write, read. "write" lock the mutex and "read" unlock >> it. >>>> The >>>>> user space programm opens device, then mekes "write" (mutex will held >> in >>>>> kernel), goes back to user space, then makes "read" (mutex will >> unlocked >>>> in >>>>> kernel) and it all run without panic. If needed i can post the source >>>> code. >>>> Do you have kernel compiled with WITNESS? At least on -CURRENT the >>>> kernel panicked like this (while loading your module): >>>> >>>> System call kldload returning with 1 locks held >>> My kernel is compiled without WITNESS. And it allows to lock mutex in one >>> systcall (for example "write") and to unlock it in other ("read"). >>> Do you mean it is "very bad idea" to do something like this ? >>> I could not find anywhere in the documentation that a it is not allowed >> to >>> return in the user space with a locked mutex. >>> Can you give me some reference on man page, source code or something >> other >>> from where can I understand it ? >>> >> Locks are used to synchronize access to data changeable by other >> threads. I don't know if I'm correct here, but let's consider the >> following situation: your process grabs a mutex and returns to userland, >> then it's killed due to segmentation violation. This mutex should (and >> can be) unlocked on exit, but the state of data protected by it is >> unknown. (For example your process was killed while inserting something >> into linked list.) So even if the kernel could be guided to unlock it on >> exit, the data could be in inconsistent state. >> >> Also your locking scheme doesn't make much sense. Consider this: >> proc1 calls write on your cdev >> but in the meantime >> proc2 calls read on your cdev >> >> So you get panic because proc1 was writing some data. (attempt to unlock >> mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would >> read inconsistend data because proc1 was writing. Proper solution is to >> lock mutex before and after reading/writing data. For working example >> you can check how devctl was implemented (sys/kern/subr_bus.c). >> >> -- >> Mateusz Guzik >> > > Ok , now I understaand it. > If a thread return to user space with locked mutex, kernel doesen't know if > the thread will come back to unlock it. It is really unsafe return to > userspace without unlocking of helding mutexes. The system should panic if you try, and at least in debu mode it does chack and panic. I'm not sure if it does if all debugging is turned off. > > Thanks a lot for your help. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From ota at j.email.ne.jp Mon Jan 12 18:54:59 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Mon Jan 12 18:55:30 2009 Subject: gcache [was: Re: 3x read to write ratio on dump/restore] In-Reply-To: <496B1E47.1030403@gmx.de> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> <496B1E47.1030403@gmx.de> Message-ID: <20090112215322.1c284010.ota@j.email.ne.jp> On Mon, 12 Jan 2009 11:41:11 +0100 Christoph Mallon wrote: > Yoshihiro Ota schrieb: > > Try GEOM Cache(gcache). > > Just a side note: gcache does not seem to have any documentation. "man > gcache" is unsuccessful, geom(8) does not mention it (geom and gcache > are the same hardlinked binary). Is there information about it somewhere? The CVS log was the best document available I took a look back in one year ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/cache/g_cache.h?rev=1.1 About the link, it is also true for many other providors, too. That is based on how GEOM library were implemented and so on. % ls -i /sbin/g* 590 /sbin/gbde 495 /sbin/ggatel 520 /sbin/gpt 592 /sbin/gcache 592 /sbin/gjournal 592 /sbin/graid3 592 /sbin/gconcat 592 /sbin/glabel 524 /sbin/growfs 592 /sbin/geli 592 /sbin/gmirror 592 /sbin/gshsec 592 /sbin/geom 592 /sbin/gmultipath 592 /sbin/gstripe 258 /sbin/ggatec 592 /sbin/gnop 528 /sbin/gvinum 440 /sbin/ggated 592 /sbin/gpart 592 /sbin/gvirstor Hiro From peterjeremy at optusnet.com.au Tue Jan 13 00:07:27 2009 From: peterjeremy at optusnet.com.au (Peter Jeremy) Date: Tue Jan 13 04:20:02 2009 Subject: 3x read to write ratio on dump/restore In-Reply-To: <20090112050537.f423215c.ota@j.email.ne.jp> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> Message-ID: <20090113075600.GA31919@server.vk2pj.dyndns.org> On 2009-Jan-12 05:05:37 -0500, Yoshihiro Ota wrote: >Jermey, I tought you wrote this, >http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html. Yes, that is my message. I had forgotten it. If you dig back further, you'll find that I looked into the poor read behaviour of dump before the caching code existed (and one of the outcomes of that thread was the current caching code). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090113/0300a5ae/attachment.pgp From kostikbel at gmail.com Wed Jan 14 07:29:36 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jan 14 07:29:42 2009 Subject: kernel dump with 7.1-RELEASE In-Reply-To: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> References: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> Message-ID: <20090114152929.GO2247@deviant.kiev.zoral.com.ua> On Fri, Jan 09, 2009 at 06:39:53PM +0200, Omer Faruk Sen wrote: > Hi, > > I am having kernel dump with FreeBSD 7.1: > > Here is crashinfo output of it (Actually i don't know the state of > crashinfo in Fbsd 7.1) > > 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > > > panic: semexit - semid not allocated > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > Physical memory: 8173 MB > Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230 > 214 198 182 166 150 134 118 102 86 70 54 38 22 6 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:195 > #1 0x0000000000000004 in ?? () > #2 0xffffffff804b4ce9 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:418 > #3 0xffffffff804b50f2 in panic (fmt=0x104
) > at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff804f846d in semexit_myhook (arg=Variable "arg" is not available. > ) > at /usr/src/sys/kern/sysv_sem.c:1328 > #5 0xffffffff80490dbc in exit1 (td=0xffffff000995f370, rv=0) > at /usr/src/sys/kern/kern_exit.c:244 > #6 0xffffffff8049239e in sys_exit (td=Variable "td" is not available. > ) at /usr/src/sys/kern/kern_exit.c:109 > #7 0xffffffff8078a7c7 in syscall (frame=0xffffffffb0d4ac80) > at /usr/src/sys/amd64/amd64/trap.c:907 > #8 0xffffffff8077088b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:330 > #9 0x0000000800a2a30c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) The change that is believed to fix the reported panic is committed as r187223 to HEAD. MFC is set to 1 month, because, mmm, because. The MFC requires mostly mechanical changes of the MAC hook names. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090114/378c04e2/attachment.pgp From freebsd.dev at gmail.com Wed Jan 14 10:01:45 2009 From: freebsd.dev at gmail.com (Biks N) Date: Wed Jan 14 10:01:52 2009 Subject: how ipfw firewall is implemented in the kernel Message-ID: <50cd4e5f0901140932x5ed9fd09p7ef4fb35095a59a2@mail.gmail.com> Hi, Can anyone please help me understand how the IPFW firewall is implemented in the kernel. I have created new ACTIONS in ipfw. I have already implemented in the userland. Now i need to check the IPFW rule list (in ip_input.c and in ip_output.c) and call a custom routine if there is a match to those rules. I would really appreciate if anyone could point me to right direction/reference. thanks From to.my.trociny at gmail.com Wed Jan 14 11:22:43 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Wed Jan 14 11:22:50 2009 Subject: How to calculate current kmem usage? Message-ID: <86iqohoh4b.fsf@kopusha.onet> Hi, Could someone explain please, how to calculate current kernel memory utilization, one that is limited by vm.kmem_size? There is a script on http://wiki.freebsd.org/ZFSTuningGuide that calculates kernel memory utilization by summing the values from `kldstat' output (TEXT) and the values from `vmstat -m' output (DATA). Are these the only data needed for proper calculation of kmem? What about zone(9) allocations? Shouldn't data from `vmstat -z' output be added to calculate kmem usage? The reason I am asking about this is that we are tuning vfs.ufs.dirhash_maxmem on our storage servers. By default it is 2Mb that looks like very small value. We increased it to 30Mb and all 30Mb were filled very quickly, so we are considering to increase it more but we need the method to monitor the system resources we can hit (we use the default value for vm.kmem_size 300Mb that is not so large). So what the system parameters we should monitor increasing vfs.ufs.dirhash_maxmem? I see the growth of dirhash_maxmem corresponds the growth of wired memory. Currently wired is 222M on this host. Isn't wired memory limited by vm.kmem_size or it is limited only by vm.kvm_size? BTW, how reasonably large the value of vfs.ufs.dirhash_maxmem can be? I have seen recommendations to increase it until it all in usage, but may be there are other considerations I should take into account? We use rsync on our storage servers to synchronize data between the hosts and I suppose this is the main dirhash_mem eater. -- Mikolaj Golub From max at love2party.net Wed Jan 14 11:42:23 2009 From: max at love2party.net (Max Laier) Date: Wed Jan 14 11:42:30 2009 Subject: how ipfw firewall is implemented in the kernel In-Reply-To: <50cd4e5f0901140932x5ed9fd09p7ef4fb35095a59a2@mail.gmail.com> References: <50cd4e5f0901140932x5ed9fd09p7ef4fb35095a59a2@mail.gmail.com> Message-ID: <200901142042.20449.max@love2party.net> On Wednesday 14 January 2009 18:32:07 Biks N wrote: > Hi, > > Can anyone please help me understand how the IPFW firewall is > implemented in the kernel. > > I have created new ACTIONS in ipfw. I have already implemented in the > userland. > > Now i need to check the IPFW rule list (in ip_input.c and in > ip_output.c) and call a custom routine if there is a match to those > rules. > > I would really appreciate if anyone could point me to right > direction/reference. ipfw is hooked into the pfil(9) hook points in ip_{in,out}put() (look for calls to pfil_run_hooks() in the respective files). From there the call path goes on to the ipfw_check_* functions defined in netinet/ip_fw_pfil.c Finally ipfw_chk() in netinet/ip_fw2.c where the ruleset is processed and where you should add your required processing. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From freebsd.dev at gmail.com Wed Jan 14 12:20:33 2009 From: freebsd.dev at gmail.com (Biks N) Date: Wed Jan 14 12:20:40 2009 Subject: how ipfw firewall is implemented in the kernel In-Reply-To: <200901142042.20449.max@love2party.net> References: <50cd4e5f0901140932x5ed9fd09p7ef4fb35095a59a2@mail.gmail.com> <200901142042.20449.max@love2party.net> Message-ID: <50cd4e5f0901141220o531c6a8hbb5d8097e5b22e6a@mail.gmail.com> Thanks a lot! That was really very helpful!!! On Wed, Jan 14, 2009 at 1:42 PM, Max Laier wrote: > On Wednesday 14 January 2009 18:32:07 Biks N wrote: >> Hi, >> >> Can anyone please help me understand how the IPFW firewall is >> implemented in the kernel. >> >> I have created new ACTIONS in ipfw. I have already implemented in the >> userland. >> >> Now i need to check the IPFW rule list (in ip_input.c and in >> ip_output.c) and call a custom routine if there is a match to those >> rules. >> >> I would really appreciate if anyone could point me to right >> direction/reference. > > ipfw is hooked into the pfil(9) hook points in ip_{in,out}put() (look for > calls to pfil_run_hooks() in the respective files). > > From there the call path goes on to the ipfw_check_* functions defined in > netinet/ip_fw_pfil.c > > Finally ipfw_chk() in netinet/ip_fw2.c where the ruleset is processed and > where you should add your required processing. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > From shilp.kamal at yahoo.com Wed Jan 14 21:30:34 2009 From: shilp.kamal at yahoo.com (Kamlesh Patel) Date: Wed Jan 14 21:51:06 2009 Subject: panic: Going nowhere without my init! Message-ID: <550328.24456.qm@web45404.mail.sp1.yahoo.com> Hi All, Thanks for answering my previous question "FreeBSD kernel Debugging tools for Virtual Memory Module", thank you Dag-Erling Sm?rgrav. Today i made a comment in Getpid() function of sys/kern/kern_prot.c file and i got error of -------------------------------------------------------------------------------- panic: Going nowhere without my init! Can not dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort-------------------------------------------------------------------------------- Could anyone help me in solving this error? Thanks Kamlesh MS CS, CSUS From callumgibson at optusnet.com.au Wed Jan 14 22:12:31 2009 From: callumgibson at optusnet.com.au (Callum Gibson) Date: Wed Jan 14 22:12:38 2009 Subject: bg_fsck ignores fstab pass numbers? Message-ID: <20090115023843.GA30963@omma.gibson.athome> Hi, I've noticed that fsck in background mode never checks separate disks in parallel for pass numbers >=2, as described in fsck(8). Taking a look at preen.c:checkfstab() (if I understand correctly) reveals that in background mode it will explicitly check each disk in turn (ironically in the foreground), rather than fork them off and queue up waiting for the children. Does anyone know the reason for that? Is it simply a matter of wanting to lower the impact and resource usage on the system? C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From bsd.quest at googlemail.com Thu Jan 15 10:31:01 2009 From: bsd.quest at googlemail.com (Alexej Sokolov) Date: Thu Jan 15 10:31:08 2009 Subject: How to access kernel memory from user space In-Reply-To: <20081223000534.f740ca8a@mail01.compvia.com> References: <20081223000534.f740ca8a@mail01.compvia.com> Message-ID: <671bb5fc0901151031w2da249ebu273dfb9429f82ac7@mail.gmail.com> 2008/12/23 Gerry Weaver > Hello All, > > I am working on a driver that collects various network statistics via pfil. > I have a simple array of structures that I use to store the statistics. I > also have a user space process that needs to collect these statistics every > second or so. A copy operation from kernel to user space would be too > expensive. Is there a mechanism that would allow me to gain direct access to > my kernel array from user space? The user process would only need read > access. It seems like maybe this could be done with mmap, but since this is > not a character driver, there is no device file etc.. I'm a newbie, so I > apologize if this is something that should be obvious. > > > Thanks in advance, > Gerry > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Hi, some times ago I solve this task. That's my solution in a system call (whithout cdev). Thanx in advance for founded mistakes and possible bugs (-: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* Arguments for syscall */ struct args { /* Pointer to allocated Buffer */ unsigned int *p; }; /* String to be located in maped buffer */ const char *str = "BSD IS SEXY"; /* Syscall func */ static int syscf(struct thread *td, void *sa) { int error; struct args *uap; vm_offset_t addr; /* Kernel space address */ vm_offset_t user_addr; /* User space address */ struct proc *procp = (struct proc *)td->td_proc; struct vmspace *vms = procp->p_vmspace; uap = (struct args *)sa; PROC_LOCK(procp); user_addr = round_page((vm_offset_t)vms->vm_daddr + lim_max(procp, RLIMIT_DATA)); PROC_UNLOCK(procp); MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO); vm_map_entry_t myentry; vm_object_t myobject; vm_pindex_t mypindex; vm_prot_t myprot; boolean_t mywired; vm_ooffset_t objoffset; vm_map_lookup(&kmem_map, addr, VM_PROT_ALL, &myentry, &myobject, &mypindex, &myprot, &mywired); /* OUT */ vm_map_lookup_done(kmem_map, myentry); printf("---> Syscall: hint for allocating space = 0x%X\n", addr); if (myobject == kmem_object){ printf("---> Syscall: Yes, it is kmem_obj! \n"); } /* Offset in vm_object */ objoffset = addr - myentry->start + myentry->offset; printf("------> Syscall: Object offset = 0x%X \n", (unsigned int)objoffset); /* * Try to map kernel buffer to user space */ vm_object_reference(myobject); /* NEEDED Increment vm_obj references */ error = vm_map_find(&vms->vm_map, myobject, objoffset, (vm_offset_t *)&user_addr, PAGE_SIZE, TRUE, VM_PROT_RW, VM_PROT_RW, MAP_ENTRY_NOFAULT); if (error == KERN_SUCCESS) { /* copy string using kernel address */ size_t len; copystr(str, (void *)addr, 12, &len); /* * Tell to user process it's user space address */ *uap->p = user_addr; /* * Try to read the string using user space address */ printf("String: %s\n", (char *)*uap->p); printf("---> Syscall: user_addr for allocating space = 0x%X\n", user_addr); } return (0); } /* Sysent entity for syscall */ static struct sysent sc_sysent = { 1, /* Number of arguments */ syscf /* Syscall function */ }; /* Offset in sysent[] */ static int offset = NO_SYSCALL; /* Loader */ static int load (struct module *m, int cmd, void *something) { int error = 0; switch(cmd){ case MOD_LOAD: printf("Module with sysc loaded. Offset = %d \n", offset); break; case MOD_UNLOAD: printf("Module with sysc unloaded. Offset = %d \n", offset); break; default: error = EOPNOTSUPP; break; } return (error); } /* Syscall macro*/ SYSCALL_MODULE(fiveg_sysc, &offset, &sc_sysent, load, NULL); If needed, I can post user space program. From gerryw at compvia.com Thu Jan 15 11:22:46 2009 From: gerryw at compvia.com (Gerry Weaver) Date: Thu Jan 15 11:22:52 2009 Subject: How to access kernel memory from user space In-Reply-To: 671bb5fc0901151031w2da249ebu273dfb9429f82ac7@mail.gmail.com Message-ID: <20090115192242.4fce7e00@mail01.compvia.com> _____ From: Alexej Sokolov [mailto:bsd.quest@googlemail.com] To: Gerry Weaver [mailto:gerryw@compvia.com] Cc: freebsd-hackers@freebsd.org Sent: Thu, 15 Jan 2009 12:31:00 -0600 Subject: Re: How to access kernel memory from user space 2008/12/23 Gerry Weaver Hello All, I am working on a driver that collects various network statistics via pfil. I have a simple array of structures that I use to store the statistics. I also have a user space process that needs to collect these statistics every second or so. A copy operation from kernel to user space would be too expensive. Is there a mechanism that would allow me to gain direct access to my kernel array from user space? The user process would only need read access. It seems like maybe this could be done with mmap, but since this is not a character driver, there is no device file etc.. I'm a newbie, so I apologize if this is something that should be obvious. Thanks in advance, Gerry _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Hi, some times ago I solve this task. That's my solution in a system call (whithout cdev). Thanx in advance for founded mistakes and possible bugs (-: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* Arguments for syscall */ struct args { /* Pointer to allocated Buffer */ unsigned int *p; }; /* String to be located in maped buffer */ const char *str = "BSD IS SEXY"; /* Syscall func */ static int syscf(struct thread *td, void *sa) { int error; struct args *uap; vm_offset_t addr; /* Kernel space address */ vm_offset_t user_addr; /* User space address */ struct proc *procp = (struct proc *)td->td_proc; struct vmspace *vms = procp->p_vmspace; uap = (struct args *)sa; PROC_LOCK(procp); user_addr = round_page((vm_offset_t)vms->vm_daddr + lim_max(procp, RLIMIT_DATA)); PROC_UNLOCK(procp); MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO); vm_map_entry_t myentry; vm_object_t myobject; vm_pindex_t mypindex; vm_prot_t myprot; boolean_t mywired; vm_ooffset_t objoffset; vm_map_lookup(&kmem_map, addr, VM_PROT_ALL, &myentry, &myobject, &mypindex, &myprot, &mywired); /* OUT */ vm_map_lookup_done(kmem_map, myentry); printf("---> Syscall: hint for allocating space = 0x%X\n", addr); if (myobject == kmem_object){ printf("---> Syscall: Yes, it is kmem_obj! \n"); } /* Offset in vm_object */ objoffset = addr - myentry->start + myentry->offset; printf("------> Syscall: Object offset = 0x%X \n", (unsigned int)objoffset); /* * Try to map kernel buffer to user space */ vm_object_reference(myobject); /* NEEDED Increment vm_obj references */ error = vm_map_find(&vms->vm_map, myobject, objoffset, (vm_offset_t *)&user_addr, PAGE_SIZE, TRUE, VM_PROT_RW, VM_PROT_RW, MAP_ENTRY_NOFAULT); if (error == KERN_SUCCESS) { /* copy string using kernel address */ size_t len; copystr(str, (void *)addr, 12, &len); /* * Tell to user process it's user space address */ *uap->p = user_addr; /* * Try to read the string using user space address */ printf("String: %s\n", (char *)*uap->p); printf("---> Syscall: user_addr for allocating space = 0x%X\n", user_addr); } return (0); } /* Sysent entity for syscall */ static struct sysent sc_sysent = { 1, /* Number of arguments */ syscf /* Syscall function */ }; /* Offset in sysent[] */ static int offset = NO_SYSCALL; /* Loader */ static int load (struct module *m, int cmd, void *something) { int error = 0; switch(cmd){ case MOD_LOAD: printf("Module with sysc loaded. Offset = %d \n", offset); break; case MOD_UNLOAD: printf("Module with sysc unloaded. Offset = %d \n", offset); break; default: error = EOPNOTSUPP; break; } return (error); } /* Syscall macro*/ SYSCALL_MODULE(fiveg_sysc, &offset, &sc_sysent, load, NULL); If needed, I can post user space program. Hi, This looks like a very nice solution. I would like to see the user space code very much. I really appreciate your help! Thanks Again, Gerry From yanefbsd at gmail.com Thu Jan 15 23:33:55 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jan 15 23:34:00 2009 Subject: panic: Going nowhere without my init! In-Reply-To: <550328.24456.qm@web45404.mail.sp1.yahoo.com> References: <550328.24456.qm@web45404.mail.sp1.yahoo.com> Message-ID: <7d6fde3d0901152333i53108c49m64e92abb7c5329cb@mail.gmail.com> On Wed, Jan 14, 2009 at 9:30 PM, Kamlesh Patel wrote: > Hi All, > > Thanks for answering my previous question "FreeBSD kernel Debugging tools for Virtual Memory Module", thank you Dag-Erling Sm?rgrav. > > Today i made a comment in Getpid() function of sys/kern/kern_prot.c file and i got error of > > -------------------------------------------------------------------------------- > panic: Going nowhere without my init! > Can not dump. No dump device defined. > Automatic reboot in 15 seconds - press a key on the console to abort-------------------------------------------------------------------------------- > > Could anyone help me in solving this error? "Made a comment" -- what kind of comment? Do you in fact mean add additional code? -Garrett From yanefbsd at gmail.com Fri Jan 16 00:41:40 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 16 00:41:53 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's Message-ID: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Hi amd64 and Hackers, Uh, I'm really confused why 1) this error (errno => ENOMEM) would occur when I have more than enough free memory (both on x86 and amd64) and 2) why strerror would segfault in the call to errx in the attached sourcefile on amd64 only. Not initializing len causes the second output sample (errno => 14, which is EFAULT). Any ideas? Please CC me if mailing on amd64@ as I'm not subscribed to the list. Thanks, -Garrett /* Program */ #include #include #include #include #include int main() { int mib[4]; size_t len; if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { printf("Errno: %d\n", errno); errx(errno, "Error: %s", strerror(errno)); } printf("%lu\n", len); return 0; } # output for len preset to 0: [gcooper@optimus ~]$ ./test2 Errno: 12 test2: Segmentation fault: 11 (core dumped) [gcooper@optimus ~]$ uname -a FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Sun Jan 11 12:30:31 PST 2009 root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 [gcooper@orangebox /usr/home/gcooper]$ ./test Errno: 12 test: Error: Cannot allocate memory [gcooper@orangebox /usr/home/gcooper]$ uname -a FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Sat Jan 3 22:54:52 PST 2009 gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX i386 # output for len not preset to 0: [gcooper@optimus ~]$ ./test2 Errno: 14 test2: Segmentation fault: 11 (core dumped) From yanefbsd at gmail.com Fri Jan 16 00:44:30 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 16 00:44:37 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Message-ID: <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: > Hi amd64 and Hackers, > Uh, I'm really confused why 1) this error (errno => ENOMEM) would > occur when I have more than enough free memory (both on x86 and amd64) > and 2) why strerror would segfault in the call to errx in the attached > sourcefile on amd64 only. Not initializing len causes the second > output sample (errno => 14, which is EFAULT). > Any ideas? > Please CC me if mailing on amd64@ as I'm not subscribed to the list. > Thanks, > -Garrett > > /* Program */ > #include > #include > #include > #include > #include > > int > main() { > > int mib[4]; > > size_t len; > > if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { > printf("Errno: %d\n", errno); > errx(errno, "Error: %s", strerror(errno)); > } > > printf("%lu\n", len); > > return 0; > > } > > # output for len preset to 0: > [gcooper@optimus ~]$ ./test2 > Errno: 12 > test2: Segmentation fault: 11 (core dumped) > [gcooper@optimus ~]$ uname -a > FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: > Sun Jan 11 12:30:31 PST 2009 > root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 > > [gcooper@orangebox /usr/home/gcooper]$ ./test > Errno: 12 > test: Error: Cannot allocate memory > [gcooper@orangebox /usr/home/gcooper]$ uname -a > FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT > #4: Sat Jan 3 22:54:52 PST 2009 > gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX > i386 > > # output for len not preset to 0: > [gcooper@optimus ~]$ ./test2 > Errno: 14 > test2: Segmentation fault: 11 (core dumped) Almost forgot -- here are the actual values reported by sysctl(1), just for reference: [gcooper@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax kern.ipc.shmall: 8192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 [gcooper@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax kern.ipc.shmall: 8192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 Thanks, -Garrett From christoph.mallon at gmx.de Fri Jan 16 00:53:03 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 16 00:53:11 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Message-ID: <49704AEC.3080709@gmx.de> Garrett Cooper schrieb: > Hi amd64 and Hackers, > Uh, I'm really confused why 1) this error (errno => ENOMEM) would > occur when I have more than enough free memory (both on x86 and amd64) > and 2) why strerror would segfault in the call to errx in the attached > sourcefile on amd64 only. Not initializing len causes the second > output sample (errno => 14, which is EFAULT). > Any ideas? > Please CC me if mailing on amd64@ as I'm not subscribed to the list. > Thanks, > -Garrett len is not uninitialised. This leads to undefined behaviour. Anything can happen. Probably the syscall overwrites parts of the stack because len has some (random) high value. > /* Program */ > #include > #include > #include > #include > #include > > int > main() { > > int mib[4]; > > size_t len; > > if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { > printf("Errno: %d\n", errno); > errx(errno, "Error: %s", strerror(errno)); The use of errno is wrong. printf might change errno. Store the errno into a local variable before you do any call, which might modify it. From yanefbsd at gmail.com Fri Jan 16 00:53:21 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 16 00:53:29 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Message-ID: <7d6fde3d0901160053y22b2f9c9vb37d0f0621c2a7c9@mail.gmail.com> On Fri, Jan 16, 2009 at 12:47 AM, Jacques Fourie wrote: > > You need to initialize len to the number of entries in the mib array. > Try adding 'len = 4' before calling sysctlnametomib() and see if your > issues go away. Ok, that solution works (I think). So, problem 2 down. Now: what about the segfaulting strerror(3) call on amd64 ;\? -Garrett From maxim at macomnet.ru Fri Jan 16 00:55:22 2009 From: maxim at macomnet.ru (Maxim Konovalov) Date: Fri Jan 16 00:55:35 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Message-ID: <20090116115448.A32187@mp2.macomnet.net> On Fri, 16 Jan 2009, 00:44-0800, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: > > Hi amd64 and Hackers, > > Uh, I'm really confused why 1) this error (errno => ENOMEM) would > > occur when I have more than enough free memory (both on x86 and amd64) > > and 2) why strerror would segfault in the call to errx in the attached > > sourcefile on amd64 only. Not initializing len causes the second > > output sample (errno => 14, which is EFAULT). > > Any ideas? - size_t len; + size_t len = 4; -- Maxim Konovalov From jacques.fourie at gmail.com Fri Jan 16 00:57:50 2009 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Fri Jan 16 00:58:02 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Message-ID: On Fri, Jan 16, 2009 at 10:47 AM, Jacques Fourie wrote: > On Fri, Jan 16, 2009 at 10:44 AM, Garrett Cooper wrote: >> On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: >>> Hi amd64 and Hackers, >>> Uh, I'm really confused why 1) this error (errno => ENOMEM) would >>> occur when I have more than enough free memory (both on x86 and amd64) >>> and 2) why strerror would segfault in the call to errx in the attached >>> sourcefile on amd64 only. Not initializing len causes the second >>> output sample (errno => 14, which is EFAULT). >>> Any ideas? >>> Please CC me if mailing on amd64@ as I'm not subscribed to the list. >>> Thanks, >>> -Garrett >>> >>> /* Program */ >>> #include >>> #include >>> #include >>> #include >>> #include >>> >>> int >>> main() { >>> >>> int mib[4]; >>> >>> size_t len; >>> >>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >>> printf("Errno: %d\n", errno); >>> errx(errno, "Error: %s", strerror(errno)); >>> } >>> >>> printf("%lu\n", len); >>> >>> return 0; >>> >>> } >>> >>> # output for len preset to 0: >>> [gcooper@optimus ~]$ ./test2 >>> Errno: 12 >>> test2: Segmentation fault: 11 (core dumped) >>> [gcooper@optimus ~]$ uname -a >>> FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: >>> Sun Jan 11 12:30:31 PST 2009 >>> root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 >>> >>> [gcooper@orangebox /usr/home/gcooper]$ ./test >>> Errno: 12 >>> test: Error: Cannot allocate memory >>> [gcooper@orangebox /usr/home/gcooper]$ uname -a >>> FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT >>> #4: Sat Jan 3 22:54:52 PST 2009 >>> gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX >>> i386 >>> >>> # output for len not preset to 0: >>> [gcooper@optimus ~]$ ./test2 >>> Errno: 14 >>> test2: Segmentation fault: 11 (core dumped) >> >> Almost forgot -- here are the actual values reported by sysctl(1), >> just for reference: >> >> [gcooper@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax >> kern.ipc.shmall: 8192 >> kern.ipc.shmmin: 1 >> kern.ipc.shmmax: 33554432 >> >> [gcooper@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall >> kern.ipc.shmmin kern.ipc.shmmax >> kern.ipc.shmall: 8192 >> kern.ipc.shmmin: 1 >> kern.ipc.shmmax: 33554432 >> >> Thanks, >> -Garrett >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > You need to initialize len to the number of entries in the mib array. > Try adding 'len = 4' before calling sysctlnametomib() and see if your > issues go away. > Sorry, I only scanned through the code without reading the whole message before replying :) Please ignore... From yanefbsd at gmail.com Fri Jan 16 00:59:00 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 16 00:59:08 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: <49704C13.60505@gmx.de> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> Message-ID: <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon wrote: > Garrett Cooper schrieb: >> >> Good point. I modified the source to do that. >> Thanks, >> -Garrett > > You should reply to all so the discussion stays on the list. Yeah, that was a goofup on my part. Go-go Gmail web interface! -Garrett From jacques.fourie at gmail.com Fri Jan 16 01:15:44 2009 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Fri Jan 16 01:15:51 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Message-ID: On Fri, Jan 16, 2009 at 10:44 AM, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: >> Hi amd64 and Hackers, >> Uh, I'm really confused why 1) this error (errno => ENOMEM) would >> occur when I have more than enough free memory (both on x86 and amd64) >> and 2) why strerror would segfault in the call to errx in the attached >> sourcefile on amd64 only. Not initializing len causes the second >> output sample (errno => 14, which is EFAULT). >> Any ideas? >> Please CC me if mailing on amd64@ as I'm not subscribed to the list. >> Thanks, >> -Garrett >> >> /* Program */ >> #include >> #include >> #include >> #include >> #include >> >> int >> main() { >> >> int mib[4]; >> >> size_t len; >> >> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >> printf("Errno: %d\n", errno); >> errx(errno, "Error: %s", strerror(errno)); >> } >> >> printf("%lu\n", len); >> >> return 0; >> >> } >> >> # output for len preset to 0: >> [gcooper@optimus ~]$ ./test2 >> Errno: 12 >> test2: Segmentation fault: 11 (core dumped) >> [gcooper@optimus ~]$ uname -a >> FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: >> Sun Jan 11 12:30:31 PST 2009 >> root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 >> >> [gcooper@orangebox /usr/home/gcooper]$ ./test >> Errno: 12 >> test: Error: Cannot allocate memory >> [gcooper@orangebox /usr/home/gcooper]$ uname -a >> FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT >> #4: Sat Jan 3 22:54:52 PST 2009 >> gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX >> i386 >> >> # output for len not preset to 0: >> [gcooper@optimus ~]$ ./test2 >> Errno: 14 >> test2: Segmentation fault: 11 (core dumped) > > Almost forgot -- here are the actual values reported by sysctl(1), > just for reference: > > [gcooper@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax > kern.ipc.shmall: 8192 > kern.ipc.shmmin: 1 > kern.ipc.shmmax: 33554432 > > [gcooper@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall > kern.ipc.shmmin kern.ipc.shmmax > kern.ipc.shmall: 8192 > kern.ipc.shmmin: 1 > kern.ipc.shmmax: 33554432 > > Thanks, > -Garrett > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > You need to initialize len to the number of entries in the mib array. Try adding 'len = 4' before calling sysctlnametomib() and see if your issues go away. From yanefbsd at gmail.com Fri Jan 16 01:19:52 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 16 01:20:00 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> Message-ID: <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon > wrote: >> Garrett Cooper schrieb: >>> >>> Good point. I modified the source to do that. >>> Thanks, >>> -Garrett >> >> You should reply to all so the discussion stays on the list. > > Yeah, that was a goofup on my part. Go-go Gmail web interface! > -Garrett Hmmm... looks like the strerror issue it could be a serious bug: #include #include #include int main() { struct stat sb; int o_errno; if (stat("/some/file/that/doesn't/exist", &sb) != 0) { o_errno = errno; printf("Errno: %d\n", errno); err(errno, "%s", strerror(o_errno)); } return 0; } [gcooper@optimus ~]$ ./badfile Errno: 2 badfile: Segmentation fault: 11 (core dumped) I rebuilt my kernel and installed it, and I rebuilt world, but haven't installed it yet though, so let me reboot the amd64 machine and see what happens (may be a mismatched ABI issue)... Cheers, -Garrett From christoph.mallon at gmx.de Fri Jan 16 01:38:21 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 16 01:38:33 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> Message-ID: <4970558A.1010705@gmx.de> Garrett Cooper schrieb: > On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote: >> On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon >> wrote: >>> Garrett Cooper schrieb: >>>> Good point. I modified the source to do that. >>>> Thanks, >>>> -Garrett >>> You should reply to all so the discussion stays on the list. >> Yeah, that was a goofup on my part. Go-go Gmail web interface! >> -Garrett > > Hmmm... looks like the strerror issue it could be a serious bug: > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > err(errno, "%s", strerror(o_errno)); You are still using the wrong errno. Also err() itself prints the error string using strerror(). There might be some interference when the result of one call to strerror() (your call) is used after another call to strerror() (err() internally). I doubt there is a bug in the library, otherwise we would see many bugreports of segfaults on AMD64. From christian.kandeler at hob.de Fri Jan 16 02:03:53 2009 From: christian.kandeler at hob.de (Christian Kandeler) Date: Fri Jan 16 02:04:00 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <49704AEC.3080709@gmx.de> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> Message-ID: <200901161039.00232.christian.kandeler@hob.de> On Friday 16 January 2009 09:53, Christoph Mallon wrote: > > int > > main() { > > > > int mib[4]; > > > > size_t len; > > > > if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { > > printf("Errno: %d\n", errno); > > errx(errno, "Error: %s", strerror(errno)); > > The use of errno is wrong. printf might change errno. I don't think printf() can set errno. And even if it could, it wouldn't matter, because C has call-by-value semantics. Christian From christoph.mallon at gmx.de Fri Jan 16 02:21:27 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 16 02:21:42 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <200901161039.00232.christian.kandeler@hob.de> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> Message-ID: <49705FA2.2020605@gmx.de> Christian Kandeler schrieb: > On Friday 16 January 2009 09:53, Christoph Mallon wrote: > >>> int >>> main() { >>> >>> int mib[4]; >>> >>> size_t len; >>> >>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >>> printf("Errno: %d\n", errno); >>> errx(errno, "Error: %s", strerror(errno)); >> The use of errno is wrong. printf might change errno. > > I don't think printf() can set errno. And even if it could, it Of course it can. See ISO/IEC 9899:1999 (E) ?7.5:3. > wouldn't matter, because C has call-by-value semantics. This has nothing to do with call-by-value. errno is read (even twice!) *after* the call to printf(). From yanefbsd at gmail.com Fri Jan 16 02:36:01 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 16 02:36:08 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <49705FA2.2020605@gmx.de> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> Message-ID: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon wrote: > Christian Kandeler schrieb: >> >> On Friday 16 January 2009 09:53, Christoph Mallon wrote: >> >>>> int >>>> main() { >>>> >>>> int mib[4]; >>>> >>>> size_t len; >>>> >>>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >>>> printf("Errno: %d\n", errno); >>>> errx(errno, "Error: %s", strerror(errno)); >>> >>> The use of errno is wrong. printf might change errno. >> >> I don't think printf() can set errno. And even if it could, it > > Of course it can. See ISO/IEC 9899:1999 (E) ?7.5:3. > >> wouldn't matter, because C has call-by-value semantics. > > This has nothing to do with call-by-value. errno is read (even twice!) > *after* the call to printf(). Ok, I just installworld'ed, recompiled the program with the following modifications, and I still get segfaults. And the question of the night is: why amd64 on a VERY recent CURRENT? I'm going to try the same app on an amd64 freebsd VMware instance with RELENG_7. Remember: just because a bunch of other people aren't reporting issues with CURRENT/amd64 doesn't mean that it isn't environmental, related to my hardware or compile options ;). Cheers, -Garrett #include #include #include int main() { struct stat sb; int o_errno; if (stat("/some/file/that/doesn't/exist", &sb) != 0) { o_errno = errno; printf("Errno: %d\n", errno); printf("%s\n", strerror(o_errno)); } return 0; } #include #include #include int main() { struct stat sb; int o_errno; if (stat("/some/file/that/doesn't/exist", &sb) != 0) { o_errno = errno; printf("Errno: %d\n", errno); printf("%s\n", strerror(o_errno)); } return 0; } [gcooper@optimus ~]$ gcc -o badfile badfile.c [gcooper@optimus ~]$ ./badfile Errno: 2 Segmentation fault: 11 (core dumped) [gcooper@optimus ~]$ From yanefbsd at gmail.com Fri Jan 16 02:44:30 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 16 02:44:51 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> Message-ID: <7d6fde3d0901160244r6d72a3f1k5c27ea03fbc37ef5@mail.gmail.com> On Fri, Jan 16, 2009 at 2:35 AM, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon > wrote: >> Christian Kandeler schrieb: >>> >>> On Friday 16 January 2009 09:53, Christoph Mallon wrote: >>> >>>>> int >>>>> main() { >>>>> >>>>> int mib[4]; >>>>> >>>>> size_t len; >>>>> >>>>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >>>>> printf("Errno: %d\n", errno); >>>>> errx(errno, "Error: %s", strerror(errno)); >>>> >>>> The use of errno is wrong. printf might change errno. >>> >>> I don't think printf() can set errno. And even if it could, it >> >> Of course it can. See ISO/IEC 9899:1999 (E) ?7.5:3. >> >>> wouldn't matter, because C has call-by-value semantics. >> >> This has nothing to do with call-by-value. errno is read (even twice!) >> *after* the call to printf(). > > Ok, I just installworld'ed, recompiled the program with the > following modifications, and I still get segfaults. And the question > of the night is: why amd64 on a VERY recent CURRENT? > I'm going to try the same app on an amd64 freebsd VMware instance > with RELENG_7. > Remember: just because a bunch of other people aren't reporting > issues with CURRENT/amd64 doesn't mean that it isn't environmental, > related to my hardware or compile options ;). > Cheers, > -Garrett Ugh... I pasted it twice by accident. Sorry. -Garrett From christoph.mallon at gmx.de Fri Jan 16 02:48:17 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 16 02:48:24 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> Message-ID: <497065ED.7050705@gmx.de> Garrett Cooper schrieb: > Ok, I just installworld'ed, recompiled the program with the > following modifications, and I still get segfaults. And the question > of the night is: why amd64 on a VERY recent CURRENT? > I'm going to try the same app on an amd64 freebsd VMware instance > with RELENG_7. > Remember: just because a bunch of other people aren't reporting > issues with CURRENT/amd64 doesn't mean that it isn't environmental, > related to my hardware or compile options ;). > Cheers, > -Garrett > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > > [gcooper@optimus ~]$ gcc -o badfile badfile.c > [gcooper@optimus ~]$ ./badfile > Errno: 2 > Segmentation fault: 11 (core dumped) > [gcooper@optimus ~]$ Well, compile with -g, start in gdb, check what value is wrong, the usual stuff. Probably the return value of strerror() is interesting. From christoph.mallon at gmx.de Fri Jan 16 03:01:04 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 16 03:01:11 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> Message-ID: <497068E5.1050903@gmx.de> Garrett Cooper schrieb: > On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon > wrote: >> Christian Kandeler schrieb: >>> On Friday 16 January 2009 09:53, Christoph Mallon wrote: >>> >>>>> int >>>>> main() { >>>>> >>>>> int mib[4]; >>>>> >>>>> size_t len; >>>>> >>>>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >>>>> printf("Errno: %d\n", errno); >>>>> errx(errno, "Error: %s", strerror(errno)); >>>> The use of errno is wrong. printf might change errno. >>> I don't think printf() can set errno. And even if it could, it >> Of course it can. See ISO/IEC 9899:1999 (E) ?7.5:3. >> >>> wouldn't matter, because C has call-by-value semantics. >> This has nothing to do with call-by-value. errno is read (even twice!) >> *after* the call to printf(). > > Ok, I just installworld'ed, recompiled the program with the > following modifications, and I still get segfaults. And the question > of the night is: why amd64 on a VERY recent CURRENT? > I'm going to try the same app on an amd64 freebsd VMware instance > with RELENG_7. > Remember: just because a bunch of other people aren't reporting > issues with CURRENT/amd64 doesn't mean that it isn't environmental, > related to my hardware or compile options ;). > Cheers, > -Garrett > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > > [gcooper@optimus ~]$ gcc -o badfile badfile.c > [gcooper@optimus ~]$ ./badfile > Errno: 2 > Segmentation fault: 11 (core dumped) > [gcooper@optimus ~]$ Compile with -Wall (you ALWAYS should do that) and then you'll see what the problem is. From danny at cs.huji.ac.il Fri Jan 16 03:33:42 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Jan 16 03:33:49 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <497065ED.7050705@gmx.de> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <497065ED.7050705@gmx.de> Message-ID: > Garrett Cooper schrieb: > > Ok, I just installworld'ed, recompiled the program with the > > following modifications, and I still get segfaults. And the question > > of the night is: why amd64 on a VERY recent CURRENT? > > I'm going to try the same app on an amd64 freebsd VMware instance > > with RELENG_7. > > Remember: just because a bunch of other people aren't reporting > > issues with CURRENT/amd64 doesn't mean that it isn't environmental, > > related to my hardware or compile options ;). > > Cheers, > > -Garrett > > > > #include > > #include > > #include > > > > int > > main() > > { > > > > struct stat sb; > > > > int o_errno; > > > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > > o_errno = errno; > > printf("Errno: %d\n", errno); > > printf("%s\n", strerror(o_errno)); > > } > > > > return 0; > > > > } > > > > #include > > #include > > #include > > > > int > > main() > > { > > > > struct stat sb; > > > > int o_errno; > > > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > > o_errno = errno; > > printf("Errno: %d\n", errno); > > printf("%s\n", strerror(o_errno)); > > } > > > > return 0; > > > > } > > > > [gcooper@optimus ~]$ gcc -o badfile badfile.c > > [gcooper@optimus ~]$ ./badfile > > Errno: 2 > > Segmentation fault: 11 (core dumped) > > [gcooper@optimus ~]$ > > Well, compile with -g, start in gdb, check what value is wrong, the > usual stuff. Probably the return value of strerror() is interesting. some facts: #include int main() { printf("%s\n", strerror(2)); return 0; } 1- it works fine on i386 2- it bombs on amd64 3- with a local strerror.c (instead of the one in libc) works fine so, there is something realy wrong going on here! (and it gows back to at least 7.0-stable) danny From christoph.mallon at gmx.de Fri Jan 16 03:39:17 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 16 03:39:23 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <497065ED.7050705@gmx.de> Message-ID: <497071E2.3040809@gmx.de> Danny Braniss schrieb: > some facts: > #include > int > main() > { > printf("%s\n", strerror(2)); > return 0; > } > > 1- it works fine on i386 > 2- it bombs on amd64 > 3- with a local strerror.c (instead of the one in libc) > works fine > so, there is something realy wrong going on here! > (and it gows back to at least 7.0-stable) No, everything is perfectly correct. I suggested this earlier: Compile with -Wall and you'll see what the problem is. From danny at cs.huji.ac.il Fri Jan 16 03:50:49 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Jan 16 03:50:55 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <20090116113928.GA1361@lizard.fafoe.narf.at> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <497065ED.7050705@gmx.de> <20090116113928.GA1361@lizard.fafoe.narf.at> Message-ID: > On Fri, Jan 16, 2009 at 01:33:38PM +0200, Danny Braniss wrote: > > some facts: > > #include > > int > > main() > > { > > printf("%s\n", strerror(2)); > > return 0; > > } > > > > 1- it works fine on i386 > > 2- it bombs on amd64 > > 3- with a local strerror.c (instead of the one in libc) > > works fine > > so, there is something realy wrong going on here! > > (and it gows back to at least 7.0-stable) > > The compiler thinks strerror returns an int. Include . ahh, RTFM ALL THE WAY! I just saw the top few lines: LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include but later it shows: #include char * strerror(int errnum); on the other hand, compiling with -static workes ok, which sent me on the wrong trail. danny From stefan at fafoe.narf.at Fri Jan 16 03:57:02 2009 From: stefan at fafoe.narf.at (Stefan Farfeleder) Date: Fri Jan 16 03:57:10 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <497065ED.7050705@gmx.de> Message-ID: <20090116113928.GA1361@lizard.fafoe.narf.at> On Fri, Jan 16, 2009 at 01:33:38PM +0200, Danny Braniss wrote: > some facts: > #include > int > main() > { > printf("%s\n", strerror(2)); > return 0; > } > > 1- it works fine on i386 > 2- it bombs on amd64 > 3- with a local strerror.c (instead of the one in libc) > works fine > so, there is something realy wrong going on here! > (and it gows back to at least 7.0-stable) The compiler thinks strerror returns an int. Include . From thierry.herbelot at free.fr Fri Jan 16 03:10:47 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Fri Jan 16 04:25:33 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> Message-ID: <200901161152.53478.thierry.herbelot@free.fr> Le Friday 16 January 2009, Garrett Cooper a ?crit : > On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > with this, it's better on an amd64/ RELENG_7 machine : % diff -ub badfile.c.ori badfile.c --- badfile.c.ori 2009-01-16 11:49:44.778991057 +0100 +++ badfile.c 2009-01-16 11:49:03.470465677 +0100 @@ -1,6 +1,7 @@ #include #include #include +#include int main() Cheers TfH From bsd.quest at googlemail.com Fri Jan 16 05:21:25 2009 From: bsd.quest at googlemail.com (Alexej Sokolov) Date: Fri Jan 16 05:21:32 2009 Subject: How to access kernel memory from user space In-Reply-To: <20090115192242.4fce7e00@mail01.compvia.com> References: <20090115192242.4fce7e00@mail01.compvia.com> Message-ID: <20090116132053.GA3271@debian.samsung.router> On Thu, Jan 15, 2009 at 01:22:18PM -0600, Gerry Weaver wrote: > _____ > > From: Alexej Sokolov [mailto:bsd.quest@googlemail.com] > To: Gerry Weaver [mailto:gerryw@compvia.com] > Cc: freebsd-hackers@freebsd.org > Sent: Thu, 15 Jan 2009 12:31:00 -0600 > Subject: Re: How to access kernel memory from user space > > > > > 2008/12/23 Gerry Weaver > Hello All, > > I am working on a driver that collects various network statistics via pfil. I have a simple array of structures that I use to store the statistics. I also have a user space process that needs to collect these statistics every second or so. A copy operation from kernel to user space would be too expensive. Is there a mechanism that would allow me to gain direct access to my kernel array from user space? The user process would only need read access. It seems like maybe this could be done with mmap, but since this is not a character driver, there is no device file etc.. I'm a newbie, so I apologize if this is something that should be obvious. > > > Thanks in advance, > Gerry > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Hi, > some times ago I solve this task. That's my solution in a system call (whithout cdev). > Thanx in advance for founded mistakes and possible bugs (-: > > > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #include > #include > #include > #include > #include > #include > > > /* Arguments for syscall */ > struct args { > > /* Pointer to allocated Buffer */ > unsigned int *p; > }; > > /* String to be located in maped buffer */ > const char *str = "BSD IS SEXY"; > > /* Syscall func */ > static int > syscf(struct thread *td, void *sa) > { > int error; > struct args *uap; > vm_offset_t addr; /* Kernel space address */ > vm_offset_t user_addr; /* User space address */ > > struct proc *procp = (struct proc *)td->td_proc; > > struct vmspace *vms = procp->p_vmspace; > > uap = (struct args *)sa; > > PROC_LOCK(procp); > user_addr = round_page((vm_offset_t)vms->vm_daddr + > lim_max(procp, RLIMIT_DATA)); > PROC_UNLOCK(procp); > > MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO); > > vm_map_entry_t myentry; > vm_object_t myobject; > vm_pindex_t mypindex; > vm_prot_t myprot; > boolean_t mywired; > vm_ooffset_t objoffset; > > vm_map_lookup(&kmem_map, addr, VM_PROT_ALL, > &myentry, &myobject, &mypindex, &myprot, &mywired); /* OUT */ > vm_map_lookup_done(kmem_map, myentry); > > printf("---> Syscall: hint for allocating space = 0x%X\n", addr); > > if (myobject == kmem_object){ > printf("---> Syscall: Yes, it is kmem_obj! \n"); > } > > /* Offset in vm_object */ > objoffset = addr - myentry->start + myentry->offset; > > printf("------> Syscall: Object offset = 0x%X \n", (unsigned int)objoffset); > > /* > * Try to map kernel buffer to user space > */ > vm_object_reference(myobject); /* NEEDED Increment vm_obj references */ > error = vm_map_find(&vms->vm_map, myobject, objoffset, (vm_offset_t *)&user_addr, > PAGE_SIZE, TRUE, VM_PROT_RW, VM_PROT_RW, > MAP_ENTRY_NOFAULT); > > if (error == KERN_SUCCESS) { > /* copy string using kernel address */ > size_t len; > copystr(str, (void *)addr, 12, &len); > > /* > * Tell to user process it's user space address > */ > *uap->p = user_addr; > > /* > * Try to read the string using user space address > */ > printf("String: %s\n", (char *)*uap->p); > > printf("---> Syscall: user_addr for allocating space = 0x%X\n", user_addr); > } > > return (0); > } > > /* Sysent entity for syscall */ > static struct sysent sc_sysent = { > 1, /* Number of arguments */ > syscf /* Syscall function */ > }; > > /* Offset in sysent[] */ > static int offset = NO_SYSCALL; > > /* Loader */ > static int > load (struct module *m, int cmd, void *something) > { > int error = 0; > switch(cmd){ > case MOD_LOAD: > printf("Module with sysc loaded. Offset = %d \n", offset); > break; > > case MOD_UNLOAD: > printf("Module with sysc unloaded. Offset = %d \n", offset); > break; > > default: > error = EOPNOTSUPP; > break; > } > return (error); > } > > /* Syscall macro*/ > SYSCALL_MODULE(fiveg_sysc, &offset, &sc_sysent, load, NULL); > > If needed, I can post user space program. > Hi, > > This looks like a very nice solution. I would like to see the user space code very much. > I really appreciate your help! > > Thanks Again, > Gerry User space program: #include #include #include #include #include #include int main(int argc, char *argv[]) { int sysc_num, error; struct module_stat mstat; /* This Variable will save the addres of remapped buffer */ unsigned int some_var; /* Pointer to pointer to remapped buffer */ unsigned int *p = &some_var; printf("USER: Pointer = %p \n", p); /* Search module with system call */ mstat.version = sizeof(mstat); if ( !(modstat(modfind("fiveg_sysc"), &mstat)) ){ /* Our module */ sysc_num = mstat.data.intval; printf("USER: Module found! Syscall number = %d \n", sysc_num); /* make system call */ error = syscall(sysc_num, p); /* Read the string from remapped buffer */ printf("USER: String = %s\n", (char *)*p); } else { printf("USER: Module seems to be not loaded! \n"); } return(0); } -- Alexej Sokolov From clc at ournetos.com Fri Jan 16 09:38:22 2009 From: clc at ournetos.com (clc@ournetos.com) Date: Fri Jan 16 09:55:11 2009 Subject: a CD you might interested in Message-ID: <59218.123.203.190.250.1232125165.squirrel@www.ournetos.com> Dear All, I think the following CD might interest you. URL: http://www.ournetos.com/itcf3.iso & http://www.compass.com.hk/itcf3.iso It is a bootable CD using grub-0.95 as of Nevada-b99, so, it is UNDI-based NICs netbootable. Also, I'd put onto it gPXE-0.96 *.lkrn for using gPXE of http://etherboot.org. Network installation media for a) FreeBSD-7.1 b) Nevada-b105 c) Debian-4.0 d) Fedora-10 e) OpenSUSE-11.1 f) Ubuntu-8.10 are on it. Also, flavors of Linuxes may be WANbooted on PCs w/ internet connectivity. Wish you enjoy it, Clarence Data Expert Limited clc@ournetos.com From yanefbsd at gmail.com Fri Jan 16 10:06:55 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 16 10:07:01 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <200901161152.53478.thierry.herbelot@free.fr> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <200901161152.53478.thierry.herbelot@free.fr> Message-ID: <7d6fde3d0901161006r79f0cac4yf80c9c5079152b87@mail.gmail.com> On Fri, Jan 16, 2009 at 2:52 AM, Thierry Herbelot wrote: > Le Friday 16 January 2009, Garrett Cooper a ?crit : >> On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon >> >> #include >> #include >> #include >> >> int >> main() >> { >> >> struct stat sb; >> >> int o_errno; >> >> if (stat("/some/file/that/doesn't/exist", &sb) != 0) { >> o_errno = errno; >> printf("Errno: %d\n", errno); >> printf("%s\n", strerror(o_errno)); >> } >> >> return 0; >> >> } >> > with this, it's better on an amd64/ RELENG_7 machine : > > % diff -ub badfile.c.ori badfile.c > --- badfile.c.ori 2009-01-16 11:49:44.778991057 +0100 > +++ badfile.c 2009-01-16 11:49:03.470465677 +0100 > @@ -1,6 +1,7 @@ > #include > #include > #include > +#include > > int > main() > > Cheers > > TfH That's hilarious -- why does it pass though without issue on x86 though? -Garrett From neldredge at math.ucsd.edu Fri Jan 16 10:33:18 2009 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Fri Jan 16 10:33:25 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: <7d6fde3d0901161006r79f0cac4yf80c9c5079152b87@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <200901161152.53478.thierry.herbelot@free.fr> <7d6fde3d0901161006r79f0cac4yf80c9c5079152b87@mail.gmail.com> Message-ID: On Fri, 16 Jan 2009, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 2:52 AM, Thierry Herbelot > wrote: >> Le Friday 16 January 2009, Garrett Cooper a ?crit : >>> On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon >>> >>> #include >>> #include >>> #include >>> >>> int >>> main() >>> { >>> >>> struct stat sb; >>> >>> int o_errno; >>> >>> if (stat("/some/file/that/doesn't/exist", &sb) != 0) { >>> o_errno = errno; >>> printf("Errno: %d\n", errno); >>> printf("%s\n", strerror(o_errno)); >>> } >>> >>> return 0; >>> >>> } >>> >> with this, it's better on an amd64/ RELENG_7 machine : >> >> % diff -ub badfile.c.ori badfile.c >> --- badfile.c.ori 2009-01-16 11:49:44.778991057 +0100 >> +++ badfile.c 2009-01-16 11:49:03.470465677 +0100 >> @@ -1,6 +1,7 @@ >> #include >> #include >> #include >> +#include >> >> int >> main() >> >> Cheers >> >> TfH > > That's hilarious -- why does it pass though without issue on x86 though? > -Garrett As pointed out, when you don't have a declaration for strerror, it's implicitly assumed to return `int'. This "feature" was widely used in the early days of C and so continues to be accepted by compilers, and gcc by default doesn't warn about it. On x86, int and char * are the same size. So even though the compiler thinks strerror is returning an int which is being passed to printf, the code it generates is the same as for a char *. On amd64, int is 32 bits but char * is 64. When the compiler thinks it's using int, it only keeps track of the lower 32 bits, and the upper 32 bits get zeroed. So the pointer that printf receives has had its upper 32 bits zeroed, and no longer points where it should. Hence segfault. Since running on amd64 I've seen a lot of bugs where people carelessly assume (perhaps without noticing) that ints and pointers are practically interchangeable, which works on x86 and the like but breaks on amd64. Variadic functions are special offenders because the compiler can't do much type checking. Pop quiz: which of the following statements is correct? #include #include execl("/bin/sh", "/bin/sh", 0); execl("/bin/sh", "/bin/sh", NULL); -- Nate Eldredge neldredge@math.ucsd.edu From stefan at fafoe.narf.at Fri Jan 16 10:38:15 2009 From: stefan at fafoe.narf.at (Stefan Farfeleder) Date: Fri Jan 16 10:38:21 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's In-Reply-To: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <200901161152.53478.thierry.herbelot@free.fr> <7d6fde3d0901161006r79f0cac4yf80c9c5079152b87@mail.gmail.com> Message-ID: <20090116183806.GB1355@lizard.fafoe.narf.at> On Fri, Jan 16, 2009 at 10:33:15AM -0800, Nate Eldredge wrote: > Pop quiz: which of the following statements is correct? > > #include > #include > > execl("/bin/sh", "/bin/sh", 0); > execl("/bin/sh", "/bin/sh", NULL); None, as NULL is allowed to expand to 0. You have to write execl("/bin/sh", "/bin/sh", (char *)0); From green at freebsd.org Fri Jan 16 13:20:14 2009 From: green at freebsd.org (Brian Fundakowski Feldman) Date: Fri Jan 16 13:20:21 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <49678BBC.8050306@elischer.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> Message-ID: <20090116211959.GA12007@green.homeunix.org> On Fri, Jan 09, 2009 at 09:39:08AM -0800, Julian Elischer wrote: > Brian Fundakowski Feldman wrote: >> On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: >>> Brian Fundakowski Feldman wrote: >>>> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >>>>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >>>>> >>>>>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that >>>>>> when a threaded program forks, and then its child attempts to go threaded, it >>>>>> deadlocks because it already appears to have locks held. I am not familiar >>>>>> enough with the current libthr/libc/rtld-elf interaction that I've been able >>>>>> to fix it myself, unfortunately. >>>>> There's really nothing to fix - according to POSIX you are only >>>>> allowed to call async-signal-safe functions in the child forked >>>>> from a threaded process. If you are trying to do anything other >>>>> than that, it may or may not work on FreeBSD, but it is not >>>>> guaranteed and is not portable. >>>>> >>>>> The rationale is that what is the point of forking and creating >>>>> more threads, when you can just as easily create more threads in >>>>> the parent without forking? The only reason to fork from a threaded >>>>> process is to call one of the exec() functions. >>>> Well, it worked until the last major set of changes to malloc. For me, the point >>>> was that I was able to have transparent background worker threads in any program >>>> regardless of its architecture, using the standard pthread fork hooks. Could you >>>> point me to the POSIX section covering fork and threads? If it's really not >>>> supposed to work then that's fine, but there's an awful lot of code there dedicated >>>> to support going threaded again after a fork. >>>> >>> Practically, you can't go threaded again after a fork >>> (by which I mean creating new threads or use things >>> like mutexes etc.) in any posix system I know of. >>> >>> It would require that: >>> The forking thread stop until: >>> Every other thread has released every resource it owns >>> and reports itself to be in a "safe quiescent state", >>> or at least report every resource it owns, especially >>> locks, >>> and >>> After the fork: >>> The child, post fork, to take ownership of all >>> of them, and free them. >>> >>> You might be able to do that in a simple >>> threaded program, but consider then that the libraries may have >>> threads running in them of which you are unaware, and that >>> some of the resources may interract with resources owned by the >>> forking thread. >>> >>> Add to this that there may be a signal thrown into this mix as well >>> >>> (signals are the bane of thread developement) >> >> Well, I wouldn't mind showing all of you what I can of what I had been doing >> with the background threads -- it works pretty well modulo this particular >> malloc lock bug. Due to it being inappropriate to share library resources >> between a child and parent for an open socket connection, I always considered >> the only "safe" behavior to be going single-threaded for the duration of the fork >> processes in both the parent and child, and the pthread_atfork(3) hooks have been >> sufficient to do so. > > > ahhhh > well going single threaded for the duration of the fork, changes > everything! Could you, and anyone else who would care to, check this out? It's a regression fix but it also makes the code a little bit clearer. Thanks! Index: lib/libc/stdlib/malloc.c =================================================================== --- lib/libc/stdlib/malloc.c (revision 187160) +++ lib/libc/stdlib/malloc.c (working copy) @@ -415,6 +415,7 @@ /* Set to true once the allocator has been initialized. */ static bool malloc_initialized = false; +static bool malloc_during_fork = false; /* Used to avoid initialization races. */ static malloc_mutex_t init_lock = {_SPINLOCK_INITIALIZER}; @@ -1205,7 +1206,7 @@ malloc_mutex_lock(malloc_mutex_t *mutex) { - if (__isthreaded) + if (__isthreaded || malloc_during_fork) _SPINLOCK(&mutex->lock); } @@ -1213,7 +1214,7 @@ malloc_mutex_unlock(malloc_mutex_t *mutex) { - if (__isthreaded) + if (__isthreaded || malloc_during_fork) _SPINUNLOCK(&mutex->lock); } @@ -1260,7 +1261,7 @@ { unsigned ret = 0; - if (__isthreaded) { + if (__isthreaded || malloc_during_fork) { if (_pthread_mutex_trylock(lock) != 0) { /* Exponentially back off if there are multiple CPUs. */ if (ncpus > 1) { @@ -1296,7 +1297,7 @@ malloc_spin_unlock(pthread_mutex_t *lock) { - if (__isthreaded) + if (__isthreaded || malloc_during_fork) _pthread_mutex_unlock(lock); } @@ -5515,9 +5516,8 @@ void _malloc_prefork(void) { + arena_t *larenas[narenas]; bool again; - unsigned i, j; - arena_t *larenas[narenas], *tarenas[narenas]; /* Acquire all mutexes in a safe order. */ @@ -5530,19 +5530,23 @@ */ memset(larenas, 0, sizeof(arena_t *) * narenas); do { + unsigned int i; + again = false; malloc_spin_lock(&arenas_lock); for (i = 0; i < narenas; i++) { if (arenas[i] != larenas[i]) { + arena_t *tarenas[narenas]; + unsigned int j; + memcpy(tarenas, arenas, sizeof(arena_t *) * narenas); malloc_spin_unlock(&arenas_lock); for (j = 0; j < narenas; j++) { if (larenas[j] != tarenas[j]) { larenas[j] = tarenas[j]; - malloc_spin_lock( - &larenas[j]->lock); + malloc_spin_lock(&larenas[j]->lock); } } again = true; @@ -5558,6 +5562,7 @@ #ifdef MALLOC_DSS malloc_mutex_lock(&dss_mtx); #endif + malloc_during_fork = true; } void @@ -5582,6 +5587,12 @@ if (larenas[i] != NULL) malloc_spin_unlock(&larenas[i]->lock); } + /* + * This ends the special post-__isthreaded exemption behavior for + * malloc stuff. We should really be single threaded right now + * in effect regardless of __isthreaded status. + */ + malloc_during_fork = false; } /* Index: lib/libthr/thread/thr_fork.c =================================================================== --- lib/libthr/thread/thr_fork.c (revision 187160) +++ lib/libthr/thread/thr_fork.c (working copy) @@ -105,7 +105,7 @@ struct pthread_atfork *af; pid_t ret; int errsave; - int unlock_malloc; + int was_threaded; int rtld_locks[MAX_RTLD_LOCKS]; if (!_thr_is_inited()) @@ -122,16 +122,16 @@ } /* - * Try our best to protect memory from being corrupted in - * child process because another thread in malloc code will - * simply be kill by fork(). + * All bets are off as to what should happen soon if the parent + * process was not so kindly as to set up pthread fork hooks to + * relinquish all running threads. */ if (_thr_isthreaded() != 0) { - unlock_malloc = 1; + was_threaded = 1; _malloc_prefork(); _rtld_atfork_pre(rtld_locks); } else { - unlock_malloc = 0; + was_threaded = 0; } /* @@ -159,7 +159,7 @@ _thr_umutex_init(&curthread->lock); _thr_umutex_init(&_thr_atfork_lock); - if (unlock_malloc) + if (was_threaded) _rtld_atfork_post(rtld_locks); _thr_setthreaded(0); @@ -173,7 +173,7 @@ /* Ready to continue, unblock signals. */ _thr_signal_unblock(curthread); - if (unlock_malloc) + if (was_threaded) _malloc_postfork(); /* Run down atfork child handlers. */ @@ -188,7 +188,7 @@ /* Ready to continue, unblock signals. */ _thr_signal_unblock(curthread); - if (unlock_malloc) { + if (was_threaded) { _rtld_atfork_post(rtld_locks); _malloc_postfork(); } Index: tools/regression/pthread/malloc_thread_fork_survival/no_deadlock.c =================================================================== --- tools/regression/pthread/malloc_thread_fork_survival/no_deadlock.c (revision 0) +++ tools/regression/pthread/malloc_thread_fork_survival/no_deadlock.c (revision 0) @@ -0,0 +1,55 @@ +/* + * Public domain, originally by Brian Fundakowski Feldman . + * $FreeBSD$ + */ +#include +#include + +#include +#include +#include +#include + +void * +noop(void *unused) +{ + return (NULL); +} + +void * +exit0(void *unused) +{ + const char ok[] = "ok\n"; + write(1, ok, sizeof(ok)); + exit(0); +} + +void * +exitN(int code) +{ + if (code == 0) { + exit0(NULL); + } else { + const char not_ok[] = "not ok\n"; + write(1, not_ok, sizeof(not_ok)); + exit(code); + } +} + +int +main() +{ + pthread_t thread; + int exited; + + pthread_create(&thread, NULL, noop, NULL); + pthread_join(thread, NULL); + if (fork() == 0) { + alarm(1); + pthread_create(&thread, NULL, exit0, NULL); + pthread_join(thread, NULL); + /* UNREACHED */ + } + wait(&exited); + exitN(WIFSIGNALED(exited) ? WTERMSIG(exited) : WEXITSTATUS(exited)); +} Index: tools/regression/pthread/malloc_thread_fork_survival/Makefile =================================================================== --- tools/regression/pthread/malloc_thread_fork_survival/Makefile (revision 0) +++ tools/regression/pthread/malloc_thread_fork_survival/Makefile (working copy) @@ -1,8 +1,8 @@ # $FreeBSD$ -PROG= cv_cancel1 +PROG= no_deadlock NO_MAN= -LDADD= -lpthread +LDADD= -lthr .include -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From delphij at delphij.net Fri Jan 16 14:46:55 2009 From: delphij at delphij.net (Xin LI) Date: Fri Jan 16 14:47:03 2009 Subject: A patch of HPTIOP driver for 7.1-RELEASE In-Reply-To: <2e566b9e0901070005s630c2212k44a0e59a1bcf69aa@mail.gmail.com> References: <2e566b9e0901070005s630c2212k44a0e59a1bcf69aa@mail.gmail.com> Message-ID: <49710E4F.6020404@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Shaowei, It seems that I can not apply your patch directly, I have tried to do it manually, as attached, please let me know if it's Ok. I can commit for you against -HEAD if it looks fine and take care for MFC. Note that, however, I am more or less concerned about the driver if 32-bit utility is running on amd64 platform. There seems to have three pointer style field in hpt_iop_ioctl_param. I have checked hptrr(4) and found that it has defined a 32-bit compatibility ioctl structure. According to my understanding to hptiop(4), this could be a problem. PS. For faster handling it is probably a good idea to submit patch through our PR system: http://www.freebsd.org/send-pr.html Shaowei Wang (wsw) wrote: > Hi, guys > > hptiop driver in the 7.1 release has a little bug. > Because this issue the Raid-manage GUI program which we provided can NOT > work anymore. > > So we give the patch: > > Index: hptiop.h > =================================================================== > --- hptiop.h (revision 186851) > +++ hptiop.h (working copy) > @@ -260,7 +260,7 @@ > unsigned long lpOutBuffer; /* output data buffer */ > u_int32_t nOutBufferSize; /* size of output data buffer > */ > unsigned long lpBytesReturned; /* count of HPT_U8s returned */ > -}; > +}__attribute__((packed)); > > #define HPT_IOCTL_FLAG_OPEN 1 > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > ==================================================================== > > -wsw > > /************************************************************************/ > > ???? > > hptiop????7.1?????????? > ???????????????????????? > > ???????? > > Index: hptiop.h > =================================================================== > --- hptiop.h (revision 186851) > +++ hptiop.h (working copy) > @@ -260,7 +260,7 @@ > unsigned long lpOutBuffer; /* output data buffer */ > u_int32_t nOutBufferSize; /* size of output data buffer > */ > unsigned long lpBytesReturned; /* count of HPT_U8s returned */ > -}; > +}__attribute__((packed)); > > #define HPT_IOCTL_FLAG_OPEN 1 > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > ==================================================================== > > -wsw > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAklxDk4ACgkQi+vbBBjt66CvUQCfaAnk0XQTh3Wrn2O4Dy0pEUFW oqsAoIvlTSNGRDg71SNyGfZ5VjDh9Z93 =1xSB -----END PGP SIGNATURE----- -------------- next part -------------- Index: sys/dev/hptiop/hptiop.h =================================================================== --- sys/dev/hptiop/hptiop.h ??? 187338? +++ sys/dev/hptiop/hptiop.h ?????? @@ -260,7 +260,7 @@ unsigned long lpOutBuffer; /* output data buffer */ u_int32_t nOutBufferSize; /* size of output data buffer */ unsigned long lpBytesReturned; /* count of HPT_U8s returned */ -}; +} __attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) From jasone at FreeBSD.org Fri Jan 16 14:54:59 2009 From: jasone at FreeBSD.org (Jason Evans) Date: Fri Jan 16 14:55:06 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090116211959.GA12007@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> Message-ID: <49710BD6.7040705@FreeBSD.org> Brian Fundakowski Feldman wrote: > Could you, and anyone else who would care to, check this out? It's a regression > fix but it also makes the code a little bit clearer. Thanks! > > Index: lib/libc/stdlib/malloc.c Why does malloc need to change for this? Unless there's a really good reason, I don't want the extra branches in the locking functions. Thanks, Jason From des at des.no Sat Jan 17 05:23:51 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat Jan 17 05:23:59 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> (Garrett Cooper's message of "Fri, 16 Jan 2009 00:41:37 -0800") References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Message-ID: <86wscuyska.fsf@ds4.des.no> Garrett Cooper writes: > #include > #include > #include > #include > #include You should always put your sys includes before your non-sys includes, and in any case, should always come first. > printf("Errno: %d\n", errno); > errx(errno, "Error: %s", strerror(errno)); In addition to what everybody else said, errno is not an appropriate value for errx's first argument. Use 1 or EXIT_FAILURE (or one of the macros defined in , but I wouldn't recommend it). Also, you probably want to use err(), not errx(), and *always* compile with -Wall -Wextra, and unless you're going to run gdb on your program, -O2 (which enables additional code analysis) DES -- Dag-Erling Sm?rgrav - des@des.no From lazaax.und at gmail.com Sat Jan 17 06:49:52 2009 From: lazaax.und at gmail.com (lazaax -) Date: Sat Jan 17 06:49:59 2009 Subject: admin jop Message-ID: <4374ff010901170649t38435dc4jdea9684cfa147b45@mail.gmail.com> hi hackers, is someone that can tell me how mach money can a company pay me each mount for admin a bsd server installed in the company, i will adminthe server remotly, is not a stable jop.... please can tell me on us dolar -- Leon Chavez Colima, Mexico "lazaax" From mbsd at pacbell.net Sat Jan 17 14:16:29 2009 From: mbsd at pacbell.net (=?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?=) Date: Sat Jan 17 14:16:36 2009 Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's In-Reply-To: <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> Message-ID: <20090117140506.A2568@antec.home> Hi Garrett, On Fri, 16 Jan 2009, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote: >> On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon >> wrote: >>> Garrett Cooper schrieb: >>>> >>>> Good point. I modified the source to do that. >>>> Thanks, >>>> -Garrett >>> >>> You should reply to all so the discussion stays on the list. >> >> Yeah, that was a goofup on my part. Go-go Gmail web interface! >> -Garrett > > Hmmm... looks like the strerror issue it could be a serious bug: Add #include . Without it you don't get the strerror() prototype, so the return value defaults to an int. Thus the compiler will truncate the pointer value to junk. The crash happens when formatting the output. Compile with -Wall and pay attention to warnings (or use -Werror) to catch these things. $.02, /Mikko > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > err(errno, "%s", strerror(o_errno)); > } > > return 0; > > } > > [gcooper@optimus ~]$ ./badfile > Errno: 2 > badfile: Segmentation fault: 11 (core dumped) > > I rebuilt my kernel and installed it, and I rebuilt world, but > haven't installed it yet though, so let me reboot the amd64 machine > and see what happens (may be a mismatched ABI issue)... > Cheers, > -Garrett > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > From xorquewasp at googlemail.com Sat Jan 17 15:41:58 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Jan 17 15:42:06 2009 Subject: gcc 4.3.2 libgcc_s.so exception handling broken? Message-ID: <20090117231404.GB77134@logik.internal.network> Hello. I have some C code that's compiled with -fexceptions using the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. A function c_function in the C code takes a callback as an argument. I'm passing this function the address of a function ext_function defined in another language (Ada, to be precise, but it seems to happen with C++ too). The main body of my program is written in this language so C is effectively the "foreign" code (whatever). If ext_function raises an exception, the exception is NOT propagated through the C code, the process simply exits. To clarify: 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. process exits In this case, the C code lives inside a dynamic library, which is linked against /usr/local/lib/gcc-4.3.2/libgcc_s.so (I never specified this explicity, I'm assuming -fexceptions causes this). If I statically link the C code (so libgcc_s.so isn't involved, I think), the exception is propagated correctly. 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. stack unwinds back to Ada_program_main. 5. Ada_program_main handles exception. Why is it that the code can't unwind the call stack correctly? Is this a bug? The same code seems to work correctly on Debian Lenny with the same compiler. Any help would be appreciated. xw From shilp.kamal at yahoo.com Sat Jan 17 18:10:37 2009 From: shilp.kamal at yahoo.com (Kamlesh Patel) Date: Sat Jan 17 18:10:43 2009 Subject: Remote kernel debugging in FreeBSD using serial communication Message-ID: <568396.13362.qm@web45414.mail.sp1.yahoo.com> Hi All, I am trying remote kernel debugging in FreeBSD using serial communication. I got the following link. http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 My problem is my developing and target system does not have DS25 female port. Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F Serial cable or any other remote debugging idea? Thanks, Kamlesh MS CS CSUS From bakul at bitblocks.com Sat Jan 17 18:52:45 2009 From: bakul at bitblocks.com (Bakul Shah) Date: Sat Jan 17 18:52:51 2009 Subject: Remote kernel debugging in FreeBSD using serial communication In-Reply-To: Your message of "Sat, 17 Jan 2009 17:57:10 PST." <568396.13362.qm@web45414.mail.sp1.yahoo.com> References: <568396.13362.qm@web45414.mail.sp1.yahoo.com> Message-ID: <20090118023553.8E7C45B11@mail.bitblocks.com> On Sat, 17 Jan 2009 17:57:10 PST Kamlesh Patel wrote: > Hi All, > > I am trying remote kernel debugging in FreeBSD using serial communication. I > got the following link. > > http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 > > My problem is my developing and target system does not have DS25 female port. > > Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F S > erial cable or any other remote debugging idea? Get one or more modular kits like the one below: http://www.cablesnmor.com/modular-kit-db9f-rj45.aspx Now wire it according to the pinouts here: http://yost.com/computers/RJ45-serial/index.html If (in the unlikely event) you have any more RS-232 devices, you can attach a similar db{9,25}{f,m}-rj45 adapter to each -- just make sure that on the RJ-45 side signals come out as specified in the web page above (also reproduced below). Now you can use a "half-twist" 8 conductor cable to connect *any* two such devices. You can even use a 4 or 6 conductor half-twist cable with the same RJ-45 jacks since the layout is such that the more important signals are towards the middle. 1 2 3 4 5 6 7 8 CTS DCD RD SG SG TD DTR RTS From rwmaillists at googlemail.com Sat Jan 17 19:00:44 2009 From: rwmaillists at googlemail.com (RW) Date: Sat Jan 17 19:00:50 2009 Subject: Remote kernel debugging in FreeBSD using serial communication In-Reply-To: <568396.13362.qm@web45414.mail.sp1.yahoo.com> References: <568396.13362.qm@web45414.mail.sp1.yahoo.com> Message-ID: <20090118023905.5d42271c@gumby.homeunix.com> On Sat, 17 Jan 2009 17:57:10 -0800 (PST) Kamlesh Patel wrote: > Hi All, > > I am trying remote kernel debugging in FreeBSD using serial > communication. I got the following link. > > http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 > > My problem is my developing and target system does not have DS25 > female port. > > Anyone have any idea about Remote kernel debugging in FreeBSD using > DS9 F/F Serial cable or any other remote debugging idea? > Have you tried following the link about 9-pin null-modem cables on the above page? Is there a particular problem? If you go to PC World, or equivalent, a null modem cable will have 9-pin connectors. From christoph.mallon at gmx.de Sat Jan 17 22:39:54 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sat Jan 17 22:40:02 2009 Subject: gcc 4.3.2 libgcc_s.so exception handling broken? In-Reply-To: <20090117231404.GB77134@logik.internal.network> References: <20090117231404.GB77134@logik.internal.network> Message-ID: <4972CEB7.40505@gmx.de> xorquewasp@googlemail.com schrieb: > Hello. > > I have some C code that's compiled with -fexceptions using > the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. > > A function c_function in the C code takes a callback as an argument. > > I'm passing this function the address of a function ext_function defined > in another language (Ada, to be precise, but it seems to happen > with C++ too). The main body of my program is written in this language > so C is effectively the "foreign" code (whatever). > > If ext_function raises an exception, the exception is NOT propagated > through the C code, the process simply exits. > > To clarify: > > 1. Ada_program_main calls c_function, passing ext_function as argument. > 2. c_function calls ext_function. > 3. ext_function raises exception. > 4. process exits > > In this case, the C code lives inside a dynamic library, which is > linked against /usr/local/lib/gcc-4.3.2/libgcc_s.so (I never specified > this explicity, I'm assuming -fexceptions causes this). > > If I statically link the C code (so libgcc_s.so isn't involved, I think), > the exception is propagated correctly. > > 1. Ada_program_main calls c_function, passing ext_function as argument. > 2. c_function calls ext_function. > 3. ext_function raises exception. > 4. stack unwinds back to Ada_program_main. > 5. Ada_program_main handles exception. > > Why is it that the code can't unwind the call stack correctly? Is this > a bug? The same code seems to work correctly on Debian Lenny with the same > compiler. > > Any help would be appreciated. > xw Are more C functions involved? E.g. is the function pointer passed to qsort(), which lives in libc, which is not compiled with -fexceptions. Look at the stack trace when the exception occurs. In gdb you can use the command "catch throw" (sic) to break when an exception gets thrown. Conversely you can break at the catcher with "catch catch" (if it gets this far). From grog at FreeBSD.org Sat Jan 17 22:45:15 2009 From: grog at FreeBSD.org (Greg 'groggy' Lehey) Date: Sat Jan 17 22:45:27 2009 Subject: Remote kernel debugging in FreeBSD using serial communication In-Reply-To: <568396.13362.qm@web45414.mail.sp1.yahoo.com> References: <568396.13362.qm@web45414.mail.sp1.yahoo.com> Message-ID: <20090118042206.GH5043@dereel.lemis.com> On Saturday, 17 January 2009 at 17:57:10 -0800, Kamlesh Patel wrote: > Hi All, > > I am trying remote kernel debugging in FreeBSD using serial > communication. I got the following link. > > http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 This article is inaccurate in a number of points, notably building the kernel. I'd recommend that you read the document at http://www.lemis.com/grog/Papers/Debug-tutorial/, which also gives you much more information about the debugging process. > My problem is my developing and target system does not have DS25 > female port. It doesn't have to be DB25, and it doesn't have to be female. > Anyone have any idea about Remote kernel debugging in FreeBSD using > DS9 F/F Serial cable or any other remote debugging idea? That should work just as well. There's nothing special about the link. But if you have any alternatives, don't use an async serial cable for kernel debugging. It's glacially slow, and people have had all sorts of problems with it in the course of time. Firewire is much better, and you may even find that the hardware is cheaper. Greg -- See complete headers for address and phone numbers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090118/3b410554/attachment.pgp From neldredge at math.ucsd.edu Sat Jan 17 23:07:30 2009 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Sat Jan 17 23:07:39 2009 Subject: gcc 4.3.2 libgcc_s.so exception handling broken? In-Reply-To: <20090117231404.GB77134@logik.internal.network> References: <20090117231404.GB77134@logik.internal.network> Message-ID: On Sat, 17 Jan 2009, xorquewasp@googlemail.com wrote: > Hello. > > I have some C code that's compiled with -fexceptions using > the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. > > A function c_function in the C code takes a callback as an argument. > > I'm passing this function the address of a function ext_function defined > in another language (Ada, to be precise, but it seems to happen > with C++ too). The main body of my program is written in this language > so C is effectively the "foreign" code (whatever). > > If ext_function raises an exception, the exception is NOT propagated > through the C code, the process simply exits. I tried a simple example of this in C++ and it works as expected. (I am on 7.0-RELEASE/amd64.) So it isn't completely busted, at least. Can you post an example that exhibits the problem? Ideally, something complete that can be compiled and is as simple as possible. If you can do it with C++ rather than Ada it might be easier, so people don't have to install the Ada compiler. Also please mention the commands you use to compile, and what they output when you compile using -v, and what architecture you are on. -- Nate Eldredge neldredge@math.ucsd.edu From xorquewasp at googlemail.com Sat Jan 17 23:19:28 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Jan 17 23:19:35 2009 Subject: gcc 4.3.2 libgcc_s.so exception handling broken? In-Reply-To: <4972CEB7.40505@gmx.de> References: <20090117231404.GB77134@logik.internal.network> <4972CEB7.40505@gmx.de> Message-ID: <20090118071924.GA43496@logik.internal.network> On 2009-01-18 07:39:51, Christoph Mallon wrote: > > Are more C functions involved? E.g. is the function pointer passed to > qsort(), which lives in libc, which is not compiled with -fexceptions. > Look at the stack trace when the exception occurs. In gdb you can use the > command "catch throw" (sic) to break when an exception gets thrown. > Conversely you can break at the catcher with "catch catch" (if it gets this > far). Unfortunately not. That was the first thing I looked at. Here's the complete test: /* c_function.c */ #include void c_function (void (*func)(int x)) { printf ("-- %s enter\n", __func__); func (23); printf ("-- %s exit\n", __func__); } -- ada_main.adb with interfaces.c; with ada.text_io; procedure ada_main is package c renames interfaces.c; test_error : exception; procedure ext_function (x : in c.int) is begin ada.text_io.put_line ("-- ext_function " & c.int'image (x)); raise test_error; end ext_function; procedure c_function (process : access procedure (x : in c.int)); pragma import (c, c_function, "c_function"); begin ada.text_io.put_line ("-- ada_main entry"); c_function (ext_function'access); exception when test_error => ada.text_io.put_line ("-- ada_main caught test_error"); end ada_main; Compilation: gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror -Wall -std=c99 -pedantic-errors -Wno-unused-parameter gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc gcc43 -o ada_main.o -c ada_main.adb -g -fstack-check -gnatwaleFG -gnatVa -gnato -gnata gnatbind ada_main.ali gnatlink -o main-dynamic ada_main.ali c_function.so gnatbind ada_main.ali gnatlink -o main-static ada_main.ali c_function.o $ LD_LIBRARY_PATH=. ldd c_function.so c_function.so: libc.so.6 => /lib/libc.so.6 (0x2807d000) libgcc_s.so.1 => /usr/local/lib/gcc-4.2.3/libgcc_s.so.1 (0x28170000) Test: $ ./main-static -- ada_main entry -- c_function enter -- ext_function 23 -- ada_main caught test_error $ LD_LIBRARY_PATH=. ./main-dynamic -- ada_main entry -- c_function enter -- ext_function 23 raised ADA_MAIN.TEST_ERROR : ada_main.adb:15 $ LD_LIBRARY_PATH=. gdb68 ./main-dynamic (gdb) catch exception Catchpoint 1: all Ada exceptions (gdb) b __gnat_os_exit Breakpoint 2 at 0x805851b: file adaint.c, line 2116. (gdb) r Catchpoint 1, ADA_MAIN.TEST_ERROR at 0x08049cda in ada_main.ext_function (x=23) at ada_main.adb:15 15 raise test_error; (gdb) bt #0 <__gnat_debug_raise_exception> (e=0x8061168) at s-except.adb:48 #1 0x0804b620 in <__gnat_raise_nodefer_with_msg> (e=0x8061168) at a-except.adb:830 #2 0x0804b698 in <__gnat_raise_exception> (e=0x8061168, message=0x8061168) at a-except.adb:870 #3 0x08049cda in ada_main.ext_function (x=23) at ada_main.adb:15 #4 0x280927ae in c_function (func=0x8049bf8 ) at c_function.c:9 #5 0x08049b5c in ada_main () at ada_main.adb:24 (gdb) c Breakpoint 2, __gnat_os_exit (status=1) at adaint.c:2116 (gdb) bt #0 __gnat_os_exit (status=1) at adaint.c:2116 #1 0x0805a41e in __gnat_unhandled_terminate () at raise.c:78 #2 0x0805a1f1 in <__gnat_last_chance_handler> (except=@0x8071000) at a-elchha.adb:138 #3 0x0804ae14 in ada.exceptions.exception_traces.unhandled_exception_terminate () at a-exextr.adb:175 #4 0x0804aad2 in ada.exceptions.exception_propagation.cleanupunwind_handler (uw_version=1, uw_phases=10, uw_eclass=5138137877735301376, uw_exception=0xa, uw_context=3217024852, uw_argument=0, =134587758) at a-exexpr.adb:369 #5 0x0805c282 in _Unwind_ForcedUnwind_Phase2 (exc=0x806f000, context=0xbfbfe754) at ../.././..//gcc-4.3.2/libgcc/../gcc/unwind.inc:168 #6 0x0805c4d6 in _Unwind_Resume (exc=0x806f000) at ../.././..//gcc-4.3.2/libgcc/../gcc/unwind.inc:237 #7 0x08049cfa in ada_main.ext_function (x=23) at ada_main.adb:16 #8 0x280927ae in c_function (func=0x8049bf8 ) at c_function.c:9 #9 0x08049b5c in ada_main () at ada_main.adb:24 From xorquewasp at googlemail.com Sat Jan 17 23:41:01 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Jan 17 23:41:07 2009 Subject: gcc 4.3.2 libgcc_s.so exception handling broken? In-Reply-To: References: <20090117231404.GB77134@logik.internal.network> Message-ID: <20090118074057.GB43496@logik.internal.network> On 2009-01-17 23:07:29, Nate Eldredge wrote: > I tried a simple example of this in C++ and it works as expected. (I am on > 7.0-RELEASE/amd64.) So it isn't completely busted, at least. > > Can you post an example that exhibits the problem? Ideally, something > complete that can be compiled and is as simple as possible. If you can do > it with C++ rather than Ada it might be easier, so people don't have to > install the Ada compiler. Also please mention the commands you use to > compile, and what they output when you compile using -v, and what > architecture you are on. Hello. You're right, the C++ example works here. I'm not sure why it didn't before. Here's a C++ version: /* main.cpp */ #include extern "C" { extern void c_function (void (*func)(int x)); } void ext_function (int x) { printf ("-- ext_function %d\n", x); throw "test_error"; } int main (void) { try { c_function (&ext_function); } catch (...) { printf ("caught test_error\n"); } return 0; } /* c_function.c */ #include void c_function (void (*func)(int x)) { printf ("-- %s enter\n", __func__); func (23); printf ("-- %s exit\n", __func__); } $ uname -smir FreeBSD 6.4-RELEASE-p1 i386 GENERIC $ gcc43 -v Using built-in specs. Target: i386-portbld-freebsd6.4 Configured with: ./..//gcc-4.3.2/configure --enable-languages=c,ada --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=43 --bindir=/usr/local/bin/gcc43 --libdir=/usr/local/lib/gcc-4.3.2 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc43 --build=i386-portbld-freebsd6.4 Thread model: posix gcc version 4.3.2 (GCC) $ c++ -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 $ gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror -Wall -std=c99 -pedantic-errors -Wno-unused-parameter $ gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc $ c++ -o main.o -c main.cpp -fexceptions -g -W -Werror -Wall -pedantic-errors -Wno-unused-parameter $ c++ -o main-dynamic main.o c_function.so $ c++ -o main-static main.o c_function.o $ ./main-static -- c_function enter -- ext_function 23 caught test_error LD_LIBRARY_PATH=. ./main-dynamic -- c_function enter -- ext_function 23 caught test_error This example is problematic, however - the C++ compiler is 3.4.6 (I'm not sure how to compile a 4.3.2 gcc with C, Ada and C++ support). From yanefbsd at gmail.com Sun Jan 18 01:38:14 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sun Jan 18 01:38:23 2009 Subject: gcc 4.3.2 libgcc_s.so exception handling broken? In-Reply-To: <20090118074057.GB43496@logik.internal.network> References: <20090117231404.GB77134@logik.internal.network> <20090118074057.GB43496@logik.internal.network> Message-ID: <7d6fde3d0901180138y61cf4a8bgc01fd5baa684954b@mail.gmail.com> On Sat, Jan 17, 2009 at 11:40 PM, wrote: > On 2009-01-17 23:07:29, Nate Eldredge wrote: >> I tried a simple example of this in C++ and it works as expected. (I am on >> 7.0-RELEASE/amd64.) So it isn't completely busted, at least. >> >> Can you post an example that exhibits the problem? Ideally, something >> complete that can be compiled and is as simple as possible. If you can do >> it with C++ rather than Ada it might be easier, so people don't have to >> install the Ada compiler. Also please mention the commands you use to >> compile, and what they output when you compile using -v, and what >> architecture you are on. > > Hello. > > You're right, the C++ example works here. I'm not sure why it didn't before. > > Here's a C++ version: > > /* main.cpp */ > > #include > > extern "C" { > extern void > c_function (void (*func)(int x)); > } > > void > ext_function (int x) > { > printf ("-- ext_function %d\n", x); > throw "test_error"; > } > > int > main (void) > { > try { > c_function (&ext_function); > } catch (...) { > printf ("caught test_error\n"); > } > return 0; > } > > /* c_function.c */ > > #include > > void > c_function (void (*func)(int x)) > { > printf ("-- %s enter\n", __func__); > func (23); > printf ("-- %s exit\n", __func__); > } > > $ uname -smir > FreeBSD 6.4-RELEASE-p1 i386 GENERIC > > $ gcc43 -v > Using built-in specs. > Target: i386-portbld-freebsd6.4 > Configured with: ./..//gcc-4.3.2/configure --enable-languages=c,ada --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=43 --bindir=/usr/local/bin/gcc43 --libdir=/usr/local/lib/gcc-4.3.2 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc43 --build=i386-portbld-freebsd6.4 > Thread model: posix > gcc version 4.3.2 (GCC) > > $ c++ -v > Using built-in specs. > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 3.4.6 [FreeBSD] 20060305 > > $ gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror -Wall -std=c99 -pedantic-errors -Wno-unused-parameter > $ gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc > $ c++ -o main.o -c main.cpp -fexceptions -g -W -Werror -Wall -pedantic-errors -Wno-unused-parameter > $ c++ -o main-dynamic main.o c_function.so > $ c++ -o main-static main.o c_function.o > > $ ./main-static > -- c_function enter > -- ext_function 23 > caught test_error > LD_LIBRARY_PATH=. ./main-dynamic > -- c_function enter > -- ext_function 23 > caught test_error > > This example is problematic, however - the C++ compiler is 3.4.6 > (I'm not sure how to compile a 4.3.2 gcc with C, Ada and C++ support). I'd check the release notes between 4.2.x and 4.3.x, and see whether or not they invalidated a certain lexigraphical part of C++ that was a gray area, which could be affecting your compilation. Have you possibly discussed this very issue on the gcc lists yet? Also, what CFLAGS / CXXFLAGS / CPUTYPE are you using? Cheers, -Garrett From yanefbsd at gmail.com Sun Jan 18 01:43:30 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sun Jan 18 01:43:36 2009 Subject: panic: Going nowhere without my init! In-Reply-To: <722201.19666.qm@web45408.mail.sp1.yahoo.com> References: <7d6fde3d0901152333i53108c49m64e92abb7c5329cb@mail.gmail.com> <722201.19666.qm@web45408.mail.sp1.yahoo.com> Message-ID: <7d6fde3d0901180143g6345c128mcbdf72799472ed03@mail.gmail.com> On Sat, Jan 17, 2009 at 6:00 PM, Kamlesh Patel wrote: > Ya, I added three extra lines. > > --- On Thu, 1/15/09, Garrett Cooper wrote: > >> From: Garrett Cooper >> Subject: Re: panic: Going nowhere without my init! >> To: shilp.kamal@yahoo.com >> Cc: "Hackers freeBSD" >> Date: Thursday, January 15, 2009, 11:33 PM >> On Wed, Jan 14, 2009 at 9:30 PM, Kamlesh Patel >> wrote: >> > Hi All, >> > >> > Thanks for answering my previous question >> "FreeBSD kernel Debugging tools for Virtual Memory >> Module", thank you Dag-Erling Sm?rgrav. >> > >> > Today i made a comment in Getpid() function of >> sys/kern/kern_prot.c file and i got error of >> > >> > >> -------------------------------------------------------------------------------- >> > panic: Going nowhere without my init! >> > Can not dump. No dump device defined. >> > Automatic reboot in 15 seconds - press a key on the >> console to >> abort-------------------------------------------------------------------------------- >> > >> > Could anyone help me in solving this error? >> >> "Made a comment" -- what kind of comment? Do you >> in fact mean add >> additional code? >> -Garrett Ok...? Why not just replace the init with a working copy off of a compatible CD? I still don't understand why adding a [C, etc] `comment' would cause these problems. Thanks, -Garrett PS Please don't top-post. PPS Please CC the list. From xorquewasp at googlemail.com Sun Jan 18 01:57:53 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sun Jan 18 01:58:00 2009 Subject: gcc 4.3.2 libgcc_s.so exception handling broken? In-Reply-To: <7d6fde3d0901180138y61cf4a8bgc01fd5baa684954b@mail.gmail.com> References: <20090117231404.GB77134@logik.internal.network> <20090118074057.GB43496@logik.internal.network> <7d6fde3d0901180138y61cf4a8bgc01fd5baa684954b@mail.gmail.com> Message-ID: <20090118095749.GA63288@logik.internal.network> On 2009-01-18 01:38:12, Garrett Cooper wrote: > > I'd check the release notes between 4.2.x and 4.3.x, and see whether > or not they invalidated a certain lexigraphical part of C++ that was a > gray area, which could be affecting your compilation. Have you > possibly discussed this very issue on the gcc lists yet? Hello. Just want to clarify that the C++ example I just gave was because someone specifically asked for it. I don't think the problem is specific to a language (and I'm not even using C++) as gcc exception handling is language independent. Right now, I'm assuming that this is a bug that's turned up in (at least) 4.3.2 on FreeBSD (works on Debian). I haven't gone to the gcc lists yet because it seems like this problem only happens on FreeBSD. They're for later... > > Also, what CFLAGS / CXXFLAGS / CPUTYPE are you using? > Exactly what was shown above plus -O switches - For C: -fexceptions -O2 -g -W -Werror -Wall -std=c99 -pedantic-errors -Wno-unused-parameter For Ada: -O3 -g -fstack-check -gnatwaleFG -gnatVa -gnato -gnata thanks, xw From unixmania at gmail.com Sun Jan 18 04:38:20 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Sun Jan 18 04:38:26 2009 Subject: admin jop In-Reply-To: <4374ff010901170649t38435dc4jdea9684cfa147b45@mail.gmail.com> References: <4374ff010901170649t38435dc4jdea9684cfa147b45@mail.gmail.com> Message-ID: On Sat, Jan 17, 2009 at 12:49 PM, lazaax - wrote: > hi hackers, is someone that can tell me how mach money can a company > pay me each mount for admin a bsd server installed in the company, i > will adminthe server remotly, is not a stable jop.... please can tell > me on us dolar This list is dedicated to discuss the development of FreeBSD. Please ask at freebsd-jobs or at -questios. Also, if you look at the -jobs archive you will find a lot of job offerings that can help you: http://lists.freebsd.org/pipermail/freebsd-jobs/ -- cd /usr/ports/sysutils/life make clean From avg at icyb.net.ua Mon Jan 19 04:11:57 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Jan 19 04:12:10 2009 Subject: ich watchdog vs intel smm code Message-ID: <49746E05.1070109@icyb.net.ua> Some time earlier I reported that ichwd driver doesn't produce any effect on my system with Intel DG33TL motherboard when watchdog timer is allowed to expire. I did some investigation and also discussed the issue with a maintainer of Linux iTCO_wdt driver, Wim Van Sebroeck. He told me that the issue is present on most of Intel motherboards with ICH9 chipset. All evidence seems to point in one direction - Intel SMM code. It seems that ICH9 always gets configured by BIOS to produce an SMI when a watchdog timer expires. Also, ICH watchdog has a logic to cause a reboot if its timer expires twice in a row, this is to avoid a potential hang in SMI handler. ICH9 allows SMI to be globally enabled and disabled. BIOS configures it to be enabled. Sometimes this bit is locked down (by BIOS), so it's not possible to change it, but sometimes it is not locked. So, if we globally disable SMI, then the watchdog in ICH9 does indeed cause a reboot. Evidently this happens after the timer expires twice in row. My conclusion is that SMI handler installed by BIOS somehow acknowledges watchdog SMI (e.g. clears a certain status bit, or performs watchdog timer reload). But it doesn't execute any "corrective" action. My guess is there might some configuration (or some other form of massaging) that needs to be done in order to convince SMM code to perform a reboot upon watchdog SMI. It would be nice if we had some Intel insiders who could provide a glimpse into Intel SMM code logic with respect to the watchdog. Finally some technical details: NMI2SMI_EN and TCO_LOCK bits of TCO1_CNT are set 1: pmbase+0x0068: 0x1200 (TCO1_CNT) in SMI_EN register TCO_EN bit is 1, GBL_SMI_EN is 1, "End of SMI (EOS)" bit is 1 and (not sure if this matters) LEGACY_USB_EN is 1: pmbase+0x0030: 0x0000203b (SMI_EN) "No Reboot (NR)" bit of GCS register is zero: 0x3410: 0x00c01444 -- Andriy Gapon From ken at mthelicon.com Mon Jan 19 04:27:25 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Mon Jan 19 04:27:32 2009 Subject: ich watchdog vs intel smm code In-Reply-To: <49746E05.1070109@icyb.net.ua> References: <49746E05.1070109@icyb.net.ua> Message-ID: ----- Original Message ----- From: "Andriy Gapon" To: ; Sent: Monday, January 19, 2009 12:11 PM Subject: ich watchdog vs intel smm code > > Some time earlier I reported that ichwd driver doesn't produce any > effect on my system with Intel DG33TL motherboard when watchdog timer is > allowed to expire. > I did some investigation and also discussed the issue with a maintainer > of Linux iTCO_wdt driver, Wim Van Sebroeck. He told me that the issue is > present on most of Intel motherboards with ICH9 chipset. > > All evidence seems to point in one direction - Intel SMM code. > It seems that ICH9 always gets configured by BIOS to produce an SMI when > a watchdog timer expires. Also, ICH watchdog has a logic to cause a > reboot if its timer expires twice in a row, this is to avoid a potential > hang in SMI handler. > ICH9 allows SMI to be globally enabled and disabled. BIOS configures it > to be enabled. Sometimes this bit is locked down (by BIOS), so it's not > possible to change it, but sometimes it is not locked. > So, if we globally disable SMI, then the watchdog in ICH9 does indeed > cause a reboot. Evidently this happens after the timer expires twice in > row. > > My conclusion is that SMI handler installed by BIOS somehow acknowledges > watchdog SMI (e.g. clears a certain status bit, or performs watchdog > timer reload). But it doesn't execute any "corrective" action. > > My guess is there might some configuration (or some other form of > massaging) that needs to be done in order to convince SMM code to > perform a reboot upon watchdog SMI. > > It would be nice if we had some Intel insiders who could provide a > glimpse into Intel SMM code logic with respect to the watchdog. > > Finally some technical details: > > NMI2SMI_EN and TCO_LOCK bits of TCO1_CNT are set 1: > pmbase+0x0068: 0x1200 (TCO1_CNT) > > in SMI_EN register TCO_EN bit is 1, GBL_SMI_EN is 1, "End of SMI > (EOS)" bit is 1 and (not sure if this matters) LEGACY_USB_EN is 1: > pmbase+0x0030: 0x0000203b (SMI_EN) > > "No Reboot (NR)" bit of GCS register is zero: > 0x3410: 0x00c01444 I have a simmilar problem on my gigabyte motherboard (one of the X48 ones), however, I believe the fault to be in hardware and not in firmware or software.. Mentioned in the datasheet for the ICH9, the speaker pin is used as a configuration pin while reset it asserted. If a logic 1 is present on this pin when reset is deasserted, the ICH9 chip locks out the ability for software to enable the watchdog. With the ichwd driver for BSD, this condition is announced with a message like "Watchdog present, but disabled in BIOS". (Well.. something close to that) ~Peg From avg at icyb.net.ua Mon Jan 19 04:37:17 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Jan 19 04:37:29 2009 Subject: ich watchdog vs intel smm code In-Reply-To: References: <49746E05.1070109@icyb.net.ua> Message-ID: <497473F5.4030506@icyb.net.ua> on 19/01/2009 14:27 Pegasus Mc Cleaft said the following: > > ----- Original Message ----- From: "Andriy Gapon" [snip] >> So, if we globally disable SMI, then the watchdog in ICH9 does indeed >> cause a reboot. Evidently this happens after the timer expires twice >> in row. [snip] > Mentioned in the datasheet for the ICH9, the speaker pin is used as a > configuration pin while reset it asserted. If a logic 1 is present on > this pin when reset is deasserted, the ICH9 chip locks out the ability > for software to enable the watchdog. With the ichwd driver for BSD, this > condition is announced with a message like "Watchdog present, but > disabled in BIOS". (Well.. something close to that) "ICH WDT present but disabled in BIOS or hardware" I believe your issue is quite a different one, it is older and known and explicitly reported by the driver. In this case the watchdog does work and does seem to generate SMI. -- Andriy Gapon From ed at 80386.nl Mon Jan 19 05:06:42 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Jan 19 05:06:49 2009 Subject: panic: Going nowhere without my init! In-Reply-To: <7d6fde3d0901180143g6345c128mcbdf72799472ed03@mail.gmail.com> References: <7d6fde3d0901152333i53108c49m64e92abb7c5329cb@mail.gmail.com> <722201.19666.qm@web45408.mail.sp1.yahoo.com> <7d6fde3d0901180143g6345c128mcbdf72799472ed03@mail.gmail.com> Message-ID: <20090119130640.GD1247@hoeg.nl> * Garrett Cooper wrote: > I still don't understand why adding a [C, etc] `comment' would cause > these problems. I guess if you break getpid() to not return 1 in the case of init(8), it will just say "init: already running" and quit. This causes this panic to occur. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090119/fb8c5616/attachment.pgp From iek at a-ka.net Mon Jan 19 05:45:26 2009 From: iek at a-ka.net (igor krasnoselski) Date: Mon Jan 19 05:56:19 2009 Subject: Wi-Fi support - which iface works better? Message-ID: <651996463.20090119153255@a-ka.net> Hi world, I'm up to build a little Wi-Fi network at my home. So I need to know, what Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: ZyXEL G-302 EE D-link DWA-510 ASUS WL-138g V2 TRENDnet TEW-423PI P.S. Digging the "7.1 Hardware Notes" on the Web gave me no information about that cards. Please note me if they are supported at all. WBR, Igor Krasnoselski From wahjava.ml at gmail.com Mon Jan 19 10:00:21 2009 From: wahjava.ml at gmail.com (Ashish SHUKLA) Date: Mon Jan 19 10:00:27 2009 Subject: Wi-Fi support - which iface works better? In-Reply-To: <651996463.20090119153255@a-ka.net> (igor krasnoselski's message of "Mon, 19 Jan 2009 15:32:55 +0200") References: <651996463.20090119153255@a-ka.net> Message-ID: <877i4rtd9a.fsf@chateau.d.lf> igor krasnoselski writes: > Hi world, > I'm up to build a little Wi-Fi network at my home. So I need to know, what Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: > ZyXEL G-302 EE > D-link DWA-510 > ASUS WL-138g V2 > TRENDnet TEW-423PI > P.S. Digging the "7.1 Hardware Notes" on the Web gave me no > information about that cards. Please note me if they are supported at > all. It depends on the wifi chipset present in those NICs. I prefer Atheros, as it is well supported (at least in 8-CURRENT) and has complete FOSS drivers :). So I think you should find which NIC has which chipset. HTH -- Ashish SHUKLA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090119/f8a38ccd/attachment.pgp From yuri at rawbw.com Mon Jan 19 10:08:26 2009 From: yuri at rawbw.com (Yuri) Date: Mon Jan 19 10:08:57 2009 Subject: Wi-Fi support - which iface works better? In-Reply-To: <651996463.20090119153255@a-ka.net> References: <651996463.20090119153255@a-ka.net> Message-ID: <4974BD3B.3020407@rawbw.com> igor krasnoselski wrote: > I'm up to build a little Wi-Fi network at my home. So I need to know, what Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: > ZyXEL G-302 EE > D-link DWA-510 > ASUS WL-138g V2 > TRENDnet TEW-423PI > P.S. Digging the "7.1 Hardware Notes" on the Web gave me no information about that cards. Please note me if they are supported at all. > > WBR, Igor Krasnoselski > This depends on the card chipset. It's sometimes hard to tell by the card model and I don't know which chipsets these cards have. I used two cards with chipsets: Atheros 5212 (ath) and Ralink Technology RT2561S (ral). Both of them don't work in a stable way under 71-PRERELEASE and in a very similar way. Connections get broken, link goes down sporadically. 'up scan' hangs, pings often don't go through after link is established, 'airdump' command stops working after a while on both of them. Based on these experiences i came to a conclusion that WiFi support isn't stable yet in FreeBSD. Yuri From des at des.no Mon Jan 19 15:13:57 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jan 19 15:14:04 2009 Subject: panic: Going nowhere without my init! In-Reply-To: <20090119130640.GD1247@hoeg.nl> (Ed Schouten's message of "Mon, 19 Jan 2009 14:06:40 +0100") References: <7d6fde3d0901152333i53108c49m64e92abb7c5329cb@mail.gmail.com> <722201.19666.qm@web45408.mail.sp1.yahoo.com> <7d6fde3d0901180143g6345c128mcbdf72799472ed03@mail.gmail.com> <20090119130640.GD1247@hoeg.nl> Message-ID: <86wscqanyl.fsf@ds4.des.no> Ed Schouten writes: > I guess if you break getpid() to not return 1 in the case of init(8), it > will just say "init: already running" and quit. This causes this panic > to occur. Who knows? We have no idea what the OP actually did, because he didn't bother to tell us. DES -- Dag-Erling Sm?rgrav - des@des.no From green at FreeBSD.org Mon Jan 19 16:41:42 2009 From: green at FreeBSD.org (Brian Fundakowski Feldman) Date: Mon Jan 19 16:41:50 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <49710BD6.7040705@FreeBSD.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> Message-ID: <20090120004135.GB12007@green.homeunix.org> On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote: > Brian Fundakowski Feldman wrote: > > Could you, and anyone else who would care to, check this out? It's a > regression >> fix but it also makes the code a little bit clearer. Thanks! >> >> Index: lib/libc/stdlib/malloc.c > > Why does malloc need to change for this? Unless there's a really good > reason, I don't want the extra branches in the locking functions. Because malloc is the thing causing the regression. It is easy enough to optimize out the one extra fetch and branch in the single-threaded case if I can get some consensus that the fix to it is actually fine. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From shilp.kamal at yahoo.com Mon Jan 19 17:00:51 2009 From: shilp.kamal at yahoo.com (Kamlesh Patel) Date: Mon Jan 19 17:00:58 2009 Subject: panic: Going nowhere without my init! In-Reply-To: <86wscqanyl.fsf@ds4.des.no> Message-ID: <560136.94786.qm@web45402.mail.sp1.yahoo.com> Hi All, Sorry for late reply, i was out of work for a week. I made wrong comment in Getpid(): Getpid() { /* ...... /* ... */ .... */ return() } I removed it and now it is working fine. Thanks --- On Mon, 1/19/09, Dag-Erling Sm?rgrav wrote: From: Dag-Erling Sm?rgrav Subject: Re: panic: Going nowhere without my init! To: "Ed Schouten" Cc: "Garrett Cooper" , shilp.kamal@yahoo.com, "FreeBSD Hackers" Date: Monday, January 19, 2009, 3:13 PM Ed Schouten writes: > I guess if you break getpid() to not return 1 in the case of init(8), it > will just say "init: already running" and quit. This causes this panic > to occur. Who knows? We have no idea what the OP actually did, because he didn't bother to tell us. DES -- Dag-Erling Sm?rgrav - des@des.no _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From des at des.no Tue Jan 20 00:56:29 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Jan 20 00:56:36 2009 Subject: panic: Going nowhere without my init! In-Reply-To: <560136.94786.qm@web45402.mail.sp1.yahoo.com> (Kamlesh Patel's message of "Mon, 19 Jan 2009 16:59:50 -0800 (PST)") References: <560136.94786.qm@web45402.mail.sp1.yahoo.com> Message-ID: <86k58qs6dg.fsf@ds4.des.no> Kamlesh Patel writes: > I made wrong comment in Getpid(): > > Getpid() { > > /* ...... > > /* ... */ > > .... */ > > return() > } That still doesn't tell us anything. To start with, there is no function named Getpid() anywhere in the tree. Secondly, the code you show us won't even compile (improperly nested comments), much less run. Thirdly, you haven't told us what you were trying to achieve with your modification, so we can't even help you get it right. Also, please don't top-post. DES -- Dag-Erling Sm?rgrav - des@des.no From christoph.mallon at gmx.de Tue Jan 20 02:43:27 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Tue Jan 20 02:43:34 2009 Subject: Question about panic in brelse() In-Reply-To: <496D94FD.9030300@gmx.de> References: <496D94FD.9030300@gmx.de> Message-ID: <4975AACA.3050906@gmx.de> Sadly I got no response about the panic problem so far. I investigated further and I came to the conclusion, that there are at least two problems/bugs in brelse(). Here are my findings. All lines refer to sys/kern/vfs_bio.c at r183754, which is the most recent version of this file. Below is the KASSERT(), which triggers in bundirty() (which is called by brelse()): KASSERT(bp->b_flags & B_REMFREE || bp->b_qindex == QUEUE_NONE, ("bundirty: buffer %p still on queue %d", bp, bp->b_qindex)); So this assertion triggers, if neither B_REMFREE is set nor the buffer is in QUEUE_NONE. Now lets have a look at brelse() before the call to bundirty() happens. In line 1325 we find: if (bp->b_flags & B_REMFREE) bremfreel(bp); In bremfreel() B_REMFREE is cleared (line 684). So after this B_REMFREE is guaranteed to be clear and so the first part of the triggered KASSERT() will be false. Now for the second part, i.e. QUEUE_NONE: At line 1331 starts an if-cascade. No matter which case of this cascade is entered, b_qindex is set and it especially in no case it is set to QUEUE_NONE. so after this if-cascade it is guaranteed that b_qindex is *not* QUEUE_NONE. So when we arrive at line 1373ff at the problematic call to bundirty(), which contains the KASSERT(), it is guaranteed that neither B_REMFREE is set nor the buffer is in QUEUE_NONE and therefore the KASSERT() will be triggered. So we have a serious problem here: When the call is done, it *will* fail. This is one part of the problem. I have no solution, I don't know what would be correct here. Further, I looked at r93707 when this call to bundirty() was added. The situation was basically the same back then, i.e. the buffer could not be in QUEUE_NONE (the check for B_REMFREE did not exist back then, so the KASSERT() was more strict). So this change seems to wrong all along or at least dubious. The commit log of r93707 on the other hand claims that it solved a serious problem. If this was tested back then, it must have been done without INVARIANTS. It seems to be, that it was a hot fix - mind the MFC time of 1 day. Now for the second problem. As stated in the original mail, there is a buffer for which a write attempt failed: > b_iocmd = BIO_WRITE > b_ioflags = BIO_ERROR > b_error = EIO > b_flags = B_NOCACHE Because the error ist "just" an EIO, the buffer is re-dirtied and BIO_ERROR is cleared (line 1144ff). So writing the buffer should be tried again. But later in line 1342ff it is determined that the buffer contains junk, because B_NOCACHE is set so B_INVAL is also set. This leads to entering the path in line 1373, which then triggers the KASSERT(). On the other hand, the buffer does not contain junk, because it should be retried to be written! It only should be not kept around after the write was successful (or is considered to be failed permamently). So I think testing B_NOCACHE here alone is to weak and the condition has to be modified. I propose this change: @@ -1340,7 +1340,8 @@ } TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist); /* buffers with junk contents */ - } else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) || + } else if (bp->b_flags & (B_INVAL | B_RELBUF) || + ((bp->b_flags & (B_NOCACHE | B_DELWRI)) == B_NOCACHE) (bp->b_ioflags & BIO_ERROR)) { bp->b_flags |= B_INVAL; bp->b_xflags &= ~(BX_BKGRDWRITE | BX_ALTDATA); This only enters the path to invalidate the buffer in case of B_NOCACHE being set, if B_DELWRI is *not* set. Can somebody reconstruct my analysis and confirm/reject it? Does my proposed solution for the second problem look sensible? Are the two problems related, i.e. can the first problem only occur because the second problem exists? What about the change in r93707 in general? Is it wrong? Does my proposal remove the cause for the change done in r93707 or are there other circumstances by which the situation can be triggered? Hopefully somebody can shed some more light on this. Christoph From christoph.mallon at gmx.de Tue Jan 20 03:54:16 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Tue Jan 20 03:54:37 2009 Subject: Question about panic in brelse() In-Reply-To: <4975AACA.3050906@gmx.de> References: <496D94FD.9030300@gmx.de> <4975AACA.3050906@gmx.de> Message-ID: <4975BB65.2020502@gmx.de> Christoph Mallon schrieb: > @@ -1340,7 +1340,8 @@ > } > TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist); > /* buffers with junk contents */ > - } else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) || > + } else if (bp->b_flags & (B_INVAL | B_RELBUF) || > + ((bp->b_flags & (B_NOCACHE | B_DELWRI)) == B_NOCACHE) > (bp->b_ioflags & BIO_ERROR)) { > bp->b_flags |= B_INVAL; > bp->b_xflags &= ~(BX_BKGRDWRITE | BX_ALTDATA); I just realised that somehow a || got lost. The diff should read: @@ -1340,7 +1340,8 @@ } TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist); /* buffers with junk contents */ - } else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) || + } else if (bp->b_flags & (B_INVAL | B_RELBUF) || + ((bp->b_flags & (B_NOCACHE | B_DELWRI)) == B_NOCACHE) || (bp->b_ioflags & BIO_ERROR)) { bp->b_flags |= B_INVAL; bp->b_xflags &= ~(BX_BKGRDWRITE | BX_ALTDATA); From creddym at gmail.com Tue Jan 20 00:21:26 2009 From: creddym at gmail.com (chandra reddy) Date: Tue Jan 20 04:19:47 2009 Subject: tar fails on FreeBSD 7 and passes on FreeBSD 6 for the same input Message-ID: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> Hi, I am getting the following error when i run tar on a directory. [chandra@home]$ tar zcf config-xsl.tar config-xsl/9.6 tar: Cannot open directory config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-liveness-detection/detection-time: No such file or directory tar: Cannot open directory config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-liveness-detection/failure-action: No such file or directory [chandra@home]$ ldd tar tar: libc.so.6 => /usr/local/lib/compat/libc.so.6 (0x28097000) chandra@home]$ uname -a FreeBSD chandra 7.1-RC1 FreeBSD 7.1-RC1 #0: Sun Dec 7 05:57:33 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 I have debugged libc and found that system call "fstafs" is failing and returning -1. Can any one help me what is the real problem here and how to fix it? Thanks Chandra_ -- "debugging a buggy debugger with a cross buggy debugger leads to a buggy life " From creddym at gmail.com Tue Jan 20 00:58:15 2009 From: creddym at gmail.com (chandra reddy) Date: Tue Jan 20 04:20:49 2009 Subject: tar fails on FreeBSD 7 and passes on FreeBSD 6 for the same input In-Reply-To: References: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> Message-ID: <3f95d3db0901200058w281f9f06rb3c7b1d63b1d401d@mail.gmail.com> Hi Doug, I have checked the files permission. It is fine. It passes on FreeBSD6 but fails on FreeBSD 7. It passes on a local file system but fails on NFS file system. Thanks -Chandra On Tue, Jan 20, 2009 at 2:02 PM, Doug Hardie wrote: > > On Jan 19, 2009, at 23:54, chandra reddy wrote: > > Hi, >> >> I am getting the following error when i run tar on a directory. >> >> [chandra@home]$ tar zcf config-xsl.tar config-xsl/9.6 >> >> tar: Cannot open directory >> >> config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-liveness-detection/detection-time: >> No such file or directory >> tar: Cannot open directory >> >> config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-liveness-detection/failure-action: >> No such file or directory >> [chandra@home]$ ldd tar >> tar: >> libc.so.6 => /usr/local/lib/compat/libc.so.6 (0x28097000) >> chandra@home]$ uname -a >> FreeBSD chandra 7.1-RC1 FreeBSD 7.1-RC1 #0: Sun Dec 7 05:57:33 UTC 2008 >> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> I have debugged libc and found that system call "fstafs" is failing and >> returning -1. >> >> Can any one help me what is the real problem here and how to fix it? >> > > Check and be sure that those directories have r and x for the user running > tar. It looks like a permission problem. > -- "debugging a buggy debugger with a cross buggy debugger leads to a buggy life " From david at catwhisker.org Tue Jan 20 05:17:41 2009 From: david at catwhisker.org (David Wolfskill) Date: Tue Jan 20 05:17:48 2009 Subject: tar fails on FreeBSD 7 and passes on FreeBSD 6 for the same input In-Reply-To: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> References: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> Message-ID: <20090120124903.GH17567@albert.catwhisker.org> On Tue, Jan 20, 2009 at 01:24:41PM +0530, chandra reddy wrote: > Hi, > > I am getting the following error when i run tar on a directory. > > [chandra@home]$ tar zcf config-xsl.tar config-xsl/9.6 > > tar: Cannot open directory > config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-liveness-detection/detection-time: > No such file or directory > tar: Cannot open directory > ... > FreeBSD chandra 7.1-RC1 FreeBSD 7.1-RC1 #0: Sun Dec 7 05:57:33 UTC 2008 > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > I have debugged libc and found that system call "fstafs" is failing and > returning -1. I believe you will find that the system call is "fstatfs". > Can any one help me what is the real problem here and how to fix it? A subsequent message of your verified that the hierarchy being read was on an NFS-mounted file system. Perchance, was that NFS mount managwed by amd(8)? If so, while I do not have a "fix" for you, I am relieved to see someone else finally report these symptoms. Please see for an archived copy of my initial message in a thread reporting this. There is additional detail (including kernel trace information & how-to-repeat instructions) in subsequent messages in the thread. Also mentioned is a circumvention -- basically, crippling amd(8) so it no longer attempts to unmount() a file system. However, I was unable to re-create the symptoms at home -- only at work. A colleague at work was able to re-create the symptoms, and was intending to experiment a bit more, but he's been busy with other things recently. Please contact me (off-list, if you prefer), and we can discuss additional details. Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090120/2d10270f/attachment.pgp From danny at cs.huji.ac.il Tue Jan 20 05:46:33 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Jan 20 05:46:40 2009 Subject: ps acting weird? Message-ID: I just stumbled on this, ps(1) gives different info if the user is root or a simple mortal: simple-mortal> ps p8130 PID TT STAT TIME COMMAND 8130 ?? Is 0:05.72 [java] root# ps p8130 PID TT STAT TIME COMMAND 8130 ?? Is 0:05.73 /usr/local/diablo-jdk1.6.0/bin/java ... was this always like this? btw, this is on 7.1-stable danny From rwatson at FreeBSD.org Tue Jan 20 07:49:11 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Jan 20 07:49:18 2009 Subject: ps acting weird? In-Reply-To: References: Message-ID: On Tue, 20 Jan 2009, Danny Braniss wrote: > I just stumbled on this, ps(1) gives different info if the user is root or a > simple mortal: > > simple-mortal> ps p8130 > PID TT STAT TIME COMMAND > 8130 ?? Is 0:05.72 [java] > > root# ps p8130 > > PID TT STAT TIME COMMAND > 8130 ?? Is 0:05.73 /usr/local/diablo-jdk1.6.0/bin/java ... > > was this always like this? > btw, this is on 7.1-stable This happens when command lines are really long -- the kernel caches certain command line data when it's short (i.e., under a couple of hundred characters), but when it's long the only way to get it is to attach to the process's address space using debugging interfaces and read it from there. This requires ps(1) to have debugging rights for the target process, which will not always be true for simple mortal users, but will often be true for root. You can set the kern.ps_arg_cache_limit sysctl to increase the limit, which will take effect when the command line is next changed (typically, when the program is run again, but there are some programs that update their command lines to show status information, in which case it will be when they next update). This shows up particularly for Java command lines, which are often long. I would be careful not to tune it up too high as it will use up kernel memory/address space, but setting it to, say, 4k or 8k on modern systems shouldn't really be a problem, especially since most commands don't have long command lines. The problem this limit addresses is what happens when maxproc processes all set maximally-sized command lines. I.e., if your maxproc is 6,000, then fully filling the command line cache gives you 1.5MB of command line in kernel address space and memory - a lot, but very little compared to making the limit 4000 bytes, in which case it's more around 24MB. Robert N M Watson Computer Laboratory University of Cambridge > > danny > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From assaulter0x80 at gmail.com Tue Jan 20 08:23:53 2009 From: assaulter0x80 at gmail.com (Jacky Oh) Date: Tue Jan 20 08:24:00 2009 Subject: KLD: program.ko: depends of kernel - no avaiable Message-ID: Hi, I'm writing a syscall module and he compiles well but at load time, kldload shows: KLD: program.ko: depends of kernel - no avaiable anyone know something about this? Thanks! From onemda at gmail.com Tue Jan 20 09:25:08 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Jan 20 09:25:14 2009 Subject: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: References: Message-ID: <3a142e750901200925g5c648c08t6d9364be9027407@mail.gmail.com> On 1/20/09, Jacky Oh wrote: > Hi, > > I'm writing a syscall module and he compiles well but at load time, kldload > shows: > > KLD: program.ko: depends of kernel - no avaiable program.ko expect kernel that is not currently running. This usually means that kernel which you are currently using and source from which you are building program.ko are not in sync. It is hard to guess because you did not give any useful information. And this is one really belongs to questions@ and not to hackers@ > anyone know something about this? > > Thanks! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Paul From stas at FreeBSD.org Tue Jan 20 12:02:40 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Jan 20 12:02:47 2009 Subject: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: <3a142e750901200925g5c648c08t6d9364be9027407@mail.gmail.com> References: <3a142e750901200925g5c648c08t6d9364be9027407@mail.gmail.com> Message-ID: <20090120230240.c1047c0d.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 20 Jan 2009 18:25:06 +0100 "Paul B. Mahol" mentioned: > On 1/20/09, Jacky Oh wrote: > > Hi, > > > > I'm writing a syscall module and he compiles well but at load time, kldload > > shows: > > > > KLD: program.ko: depends of kernel - no avaiable > > program.ko expect kernel that is not currently running. > This usually means that kernel which you are currently using and > source from which you are building program.ko are not in sync. > It is hard to guess because you did not give any useful information. > And this is one really belongs to questions@ and not to hackers@ > The other possible reason that you used the symbol undefined in kernel (e.g. called unexistent function). - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkl2LeAACgkQK/VZk+smlYFLwgCfVxU28ltWAe66XcxkSzXtR+wA 4SAAoIJmjx/aLIr4mI2k81bfl3gX++sf =Er2z -----END PGP SIGNATURE----- !DSPAM:49762ddd967007949615204! From imp at bsdimp.com Tue Jan 20 12:18:16 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Jan 20 12:18:26 2009 Subject: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: References: Message-ID: <20090120.131627.-1717264382.imp@bsdimp.com> In message: "Jacky Oh" writes: : Hi, : : I'm writing a syscall module and he compiles well but at load time, kldload : shows: : : KLD: program.ko: depends of kernel - no avaiable : : anyone know something about this? Yes. rebuild the kernel and modules to have the same __FreeBSD_version warner From gonzo at bluezbox.com Tue Jan 20 12:22:12 2009 From: gonzo at bluezbox.com (Oleksandr Tymoshenko) Date: Tue Jan 20 12:22:49 2009 Subject: uart and big-endian targets Message-ID: <4976297C.7020405@bluezbox.com> Yesterday I ran into a "problem" with uart(4) on big-endian MIPS board. uart code treats registers as bytes and reads/writes them using bus_space_read_1/bus_space_write_1. To handle word-aligned registers we have regshft in uart_bas structure. It works for little-endian flags where lowest byte resides at uart_base + (regnum << regshft) address but for big endian targets actual data resides at uart_base + ((regnum + 1) << regshft) - 1. One way to solve it is to increase uart_base when setting uart_bas, but it's not obvious and requires knowledge of uart(4) internals. I think better solution would be to take into account endianess when defining uart_regofs. Or if other BE devices have data in highest byte new field should be added to uart_bas (defaulted to 0) Any thoughts? -- gonzo From imp at bsdimp.com Tue Jan 20 12:33:49 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Jan 20 12:33:55 2009 Subject: uart and big-endian targets In-Reply-To: <4976297C.7020405@bluezbox.com> References: <4976297C.7020405@bluezbox.com> Message-ID: <20090120.133113.-1630673491.imp@bsdimp.com> In message: <4976297C.7020405@bluezbox.com> Oleksandr Tymoshenko writes: : Yesterday I ran into a "problem" with uart(4) on big-endian MIPS : board. uart code treats registers as bytes and reads/writes them using : bus_space_read_1/bus_space_write_1. To handle word-aligned registers we : have regshft in uart_bas structure. It works for little-endian flags : where lowest byte resides at uart_base + (regnum << regshft) address : but for big endian targets actual data resides at : uart_base + ((regnum + 1) << regshft) - 1. That's not the problem. The problem is that we're trying to do byte accesses to word registers. That's why we see a disconnect between the addresses since we're reading the wrong byte. also, we may be getting lucky with this access, but many chips have issues when you access word registers as bytes. : One way to solve it is to increase uart_base when setting uart_bas, : but it's not obvious and requires knowledge of uart(4) internals. : I think better solution would be to take into account endianess : when defining uart_regofs. Or if other BE devices have data in : highest byte new field should be added to uart_bas (defaulted to 0) : : Any thoughts? The base problem here is: uart.h: #define uart_getreg(bas, reg) \ bus_space_read_1((bas)->bst, (bas)->bsh, uart_regofs(bas, reg)) #define uart_setreg(bas, reg, value) \ bus_space_write_1((bas)->bst, (bas)->bsh, uart_regofs(bas, reg), value) These should be, for the platform you are using: #define uart_getreg(bas, reg) \ bus_space_read_4((bas)->bst, (bas)->bsh, uart_regofs(bas, reg)) #define uart_setreg(bas, reg, value) \ bus_space_write_4((bas)->bst, (bas)->bsh, uart_regofs(bas, reg), value) There's no easy way to swap these out, nor is there a way to have variants for different kinds of hardware attached to the same machine (the UART on the SoC will have different access patterns than the UART on the modem on the PC Card that's plugged in, for example). This is a short-coming in the design of UART. One that's relatively easy to fix, mind you, and one that could easily be fixed. There's so many twists like this that it can be hard to anticipate them all. The Octeon port basically copies uart_dev_ns8250.c and provides its own set of accessors. This is right from a accessing the hardware correctly point of view, but a pita from a code reuse point of view. Were it not for the other quirks in Cavium's serial ports, there'd be little reason to go this route... Warner From chris at young-alumni.com Tue Jan 20 12:49:21 2009 From: chris at young-alumni.com (Chris Ruiz) Date: Tue Jan 20 12:49:28 2009 Subject: tar fails on FreeBSD 7 and passes on FreeBSD 6 for the same input In-Reply-To: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> References: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> Message-ID: On Jan 20, 2009, at 1:54 AM, chandra reddy wrote: > Hi, > > I am getting the following error when i run tar on a directory. > > [chandra@home]$ tar zcf config-xsl.tar config-xsl/9.6 > > tar: Cannot open directory > config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/ > bfd-liveness-detection/detection-time: > No such file or directory > tar: Cannot open directory > config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/ > bfd-liveness-detection/failure-action: > No such file or directory > [chandra@home]$ ldd tar > tar: > libc.so.6 => /usr/local/lib/compat/libc.so.6 (0x28097000) I am a little confused by the above. It shows your tar binary being linked to a library from freebsd 6 NOT 7. Did you update your "world" when you updated your kernel to 7? This is the appropriate output on a recent CURRENT: # ldd /usr/bin/tar /usr/bin/tar: libarchive.so.4 => /usr/lib/libarchive.so.4 (0x800649000) libbz2.so.3 => /usr/lib/libbz2.so.3 (0x800774000) libz.so.4 => /lib/libz.so.4 (0x800884000) libc.so.7 => /lib/libc.so.7 (0x800998000) IIRC, 7 should have very similar output and should be linked to libc.so.7. > chandra@home]$ uname -a > FreeBSD chandra 7.1-RC1 FreeBSD 7.1-RC1 #0: Sun Dec 7 05:57:33 UTC > 2008 > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > I have debugged libc and found that system call "fstafs" is failing > and > returning -1. > > Can any one help me what is the real problem here and how to fix it? > > > > Thanks > Chandra_ My best guess is that you have an incompletely upgraded system. Chris Ruiz From imp at bsdimp.com Tue Jan 20 13:18:30 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Jan 20 13:18:36 2009 Subject: uart and big-endian targets In-Reply-To: <20090120.133113.-1630673491.imp@bsdimp.com> References: <4976297C.7020405@bluezbox.com> <20090120.133113.-1630673491.imp@bsdimp.com> Message-ID: <20090120.141631.-1146313365.imp@bsdimp.com> In message: <20090120.133113.-1630673491.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <4976297C.7020405@bluezbox.com> : Oleksandr Tymoshenko writes: : : Yesterday I ran into a "problem" with uart(4) on big-endian MIPS : : board. uart code treats registers as bytes and reads/writes them using : : bus_space_read_1/bus_space_write_1. To handle word-aligned registers we : : have regshft in uart_bas structure. It works for little-endian flags : : where lowest byte resides at uart_base + (regnum << regshft) address : : but for big endian targets actual data resides at : : uart_base + ((regnum + 1) << regshft) - 1. : : That's not the problem. The problem is that we're trying to do byte : accesses to word registers. That's why we see a disconnect between : the addresses since we're reading the wrong byte. also, we may be : getting lucky with this access, but many chips have issues when you : access word registers as bytes. : : : One way to solve it is to increase uart_base when setting uart_bas, : : but it's not obvious and requires knowledge of uart(4) internals. : : I think better solution would be to take into account endianess : : when defining uart_regofs. Or if other BE devices have data in : : highest byte new field should be added to uart_bas (defaulted to 0) : : : : Any thoughts? : : The base problem here is: : : uart.h: : : #define uart_getreg(bas, reg) \ : bus_space_read_1((bas)->bst, (bas)->bsh, uart_regofs(bas, reg)) : #define uart_setreg(bas, reg, value) \ : bus_space_write_1((bas)->bst, (bas)->bsh, uart_regofs(bas, reg), value) : : These should be, for the platform you are using: : : #define uart_getreg(bas, reg) \ : bus_space_read_4((bas)->bst, (bas)->bsh, uart_regofs(bas, reg)) : #define uart_setreg(bas, reg, value) \ : bus_space_write_4((bas)->bst, (bas)->bsh, uart_regofs(bas, reg), value) : : There's no easy way to swap these out, nor is there a way to have : variants for different kinds of hardware attached to the same machine : (the UART on the SoC will have different access patterns than the UART : on the modem on the PC Card that's plugged in, for example). This is : a short-coming in the design of UART. One that's relatively easy to : fix, mind you, and one that could easily be fixed. There's so many : twists like this that it can be hard to anticipate them all. : : The Octeon port basically copies uart_dev_ns8250.c and provides its : own set of accessors. This is right from a accessing the hardware : correctly point of view, but a pita from a code reuse point of view. : Were it not for the other quirks in Cavium's serial ports, there'd be : little reason to go this route... actually, the more I've thought about this, and chatted with folks offline, I think the right way to fix this is in bus_space... Warner From mcsiv at mcsiv.hu Tue Jan 20 13:51:18 2009 From: mcsiv at mcsiv.hu (=?ISO-8859-2?Q?Moln=E1r_Zolt=E1n?=) Date: Tue Jan 20 13:51:25 2009 Subject: hp dl-380 and freebsd 6.4,7.1 problem Message-ID: <497642F6.7000405@mcsiv.hu> Hi everybody! First of all, sorry for my bad english. I have two hp dl-380 server with 6.4 and 7.1 freebsd, but all of them have a poor performance. To illustrate the problem: Reference machine (AMD 2500 Athlon, pata disk, 6.4 bsd with generic kernel): # time tar xvzf php-5.1.4.tar.gz 0.980u 1.260s 0:14.48 15.4% 61+416k 210+20413io 4pf+0w HP DL-380 (3000 dual xeon, scsi disk, 6.4 bsd with generic kernel): # time tar xvzf php-5.1.4.tar.gz 0.668u 1.234s 1:58.47 1.5% 65+443k 0+19205io 0pf+0w The cream of the joke: (on HP) # time tar xvzf php-5.1.4.tar.gz -O > /dev/null 0.412u 0.096s 0:03.62 13.8% 60+357k 0+0io 0pf+0w Seems good, another probe: # time tar xvzf php-5.1.4.tar.gz -O > ./asdasd 0.494u 0.224s 0:06.21 11.4% 64+384k 0+324io 0pf+0w Hmmm, what the hell is that? Copying a big file (1Gb) from partition to another partition, its fast enough. Copying a big file from ftp seems ok, no performance problem. HP utility says everything ok with the server (memory, processors, disks and others) # diskinfo -t /dev/da0s1 Seek times: Full stroke: 250 iter in 1.135873 sec = 4.543 msec Half stroke: 250 iter in 1.090216 sec = 4.361 msec Quarter stroke: 500 iter in 2.994673 sec = 5.989 msec Short forward: 400 iter in 1.230212 sec = 3.076 msec Short backward: 400 iter in 1.592944 sec = 3.982 msec Seq outer: 2048 iter in 0.356638 sec = 0.174 msec Seq inner: 2048 iter in 0.354043 sec = 0.173 msec Transfer rates: outside: 102400 kbytes in 1.567910 sec = 65310 kbytes/sec middle: 102400 kbytes in 1.831442 sec = 55912 kbytes/sec inside: 102400 kbytes in 3.978799 sec = 25736 kbytes/sec It`s seems ok. The performance problem is come forward again while executiing a php script, its 10x slower then running same script on the reference machine. No errors in dmesg, no errors in log, SMP seems working normal, systat says balanced usage on each processor while a task running. vmstat doesnt appear abnormal working. Where can i find the problem? Thanks for any suggestion. Zolt?n Moln?r // From danny at cs.huji.ac.il Wed Jan 21 01:38:33 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Jan 21 01:38:40 2009 Subject: ps acting weird? In-Reply-To: References: Message-ID: > > On Tue, 20 Jan 2009, Danny Braniss wrote: > > > I just stumbled on this, ps(1) gives different info if the user is root or a > > simple mortal: > > > > simple-mortal> ps p8130 > > PID TT STAT TIME COMMAND > > 8130 ?? Is 0:05.72 [java] > > > > root# ps p8130 > > > > PID TT STAT TIME COMMAND > > 8130 ?? Is 0:05.73 /usr/local/diablo-jdk1.6.0/bin/java ... > > > > was this always like this? > > btw, this is on 7.1-stable > > This happens when command lines are really long -- the kernel caches certain > command line data when it's short (i.e., under a couple of hundred > characters), but when it's long the only way to get it is to attach to the > process's address space using debugging interfaces and read it from there. > This requires ps(1) to have debugging rights for the target process, which > will not always be true for simple mortal users, but will often be true for > root. > > You can set the kern.ps_arg_cache_limit sysctl to increase the limit, which > will take effect when the command line is next changed (typically, when the > program is run again, but there are some programs that update their command > lines to show status information, in which case it will be when they next > update). This shows up particularly for Java command lines, which are often > long. > > I would be careful not to tune it up too high as it will use up kernel > memory/address space, but setting it to, say, 4k or 8k on modern systems > shouldn't really be a problem, especially since most commands don't have long > command lines. The problem this limit addresses is what happens when maxproc > processes all set maximally-sized command lines. I.e., if your maxproc is > 6,000, then fully filling the command line cache gives you 1.5MB of command > line in kernel address space and memory - a lot, but very little compared to > making the limit 4000 bytes, in which case it's more around 24MB. > > Robert N M Watson > Computer Laboratory > University of Cambridge > thanks Robert, it is always educational to read your answers! i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 would have been enough (excluding those pathological cases of 'command *') btw, this tomcat/java command line was 312 (why not use a config file!). which brings on another issue: ps -o command= -p 777 /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] while ps -o comm= -p 777 java thanks, danny From rwatson at FreeBSD.org Wed Jan 21 03:06:45 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jan 21 03:06:53 2009 Subject: ps acting weird? In-Reply-To: References: Message-ID: On Wed, 21 Jan 2009, Danny Braniss wrote: > thanks Robert, it is always educational to read your answers! > > i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 > would have been enough (excluding those pathological cases of 'command *') > btw, this tomcat/java command line was 312 (why not use a config file!). > > which brings on another issue: > > ps -o command= -p 777 > /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] > while > ps -o comm= -p 777 > java ps distinguishes "comm", which is the binary name as stored in the process structure's p_comm field, and the command line, which is p_args. From the ps(1) man page: KEYWORDS The following is a complete list of the available keywords and their meanings. Several of them have aliases (keywords which are synonyms). ... comm command command command and arguments Robert N M Watson Computer Laboratory University of Cambridge From avg at icyb.net.ua Wed Jan 21 03:20:56 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jan 21 03:21:04 2009 Subject: device driver: cdesw questions? Message-ID: <49770513.8090203@icyb.net.ua> Question 1: I am writing a driver that would use per-open private data (among other features). Do I have to use D_TRACKCLOSE flag in this case? In general I am a little bit confused about when d_close is invoked. Supposing D_TRACKCLOSE is not set and multiple programs concurrently open, use and close a device - when d_close is called - when one program closes its last descriptor tied to the device or when the system-wide last such descriptor is closed? Question 2: I also would like the driver to provide a select capability quite similar to that of network (e.g. TCP) sockets using d_poll. I.e. a userland program should be able to query when it can write data to the device without blocking and when it can read data without blocking, plus when an error occurred in the device/driver, so there is no point in further waiting. At this moment I am thoroughly confused by meaning of various event masks described in poll(2). E.g. what is normal priority, non-zero priority and high priority. Which flags should I care about if all data is the same priority for me? Which flag(s) should I set when I'd like to communicate an error condition (e.g. similar to TCP connection reset)? -- Andriy Gapon From danny at cs.huji.ac.il Wed Jan 21 03:21:18 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Jan 21 03:21:24 2009 Subject: ps acting weird? In-Reply-To: References: Message-ID: > On Wed, 21 Jan 2009, Danny Braniss wrote: > > > thanks Robert, it is always educational to read your answers! > > > > i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 > > would have been enough (excluding those pathological cases of 'command *') > > btw, this tomcat/java command line was 312 (why not use a config file!). > > > > which brings on another issue: > > > > ps -o command= -p 777 > > /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] > > while > > ps -o comm= -p 777 > > java > > ps distinguishes "comm", which is the binary name as stored in the process > structure's p_comm field, and the command line, which is p_args. From the > ps(1) man page: > > KEYWORDS > The following is a complete list of the available keywords and their > meanings. Several of them have aliases (keywords which are synonyms). > ... > comm command > command command and arguments hehe, i read the manual :-), hence my question, the only difference, from the manual, is that command is comm and arguments, which now you explained that it's not so. danny From avg at icyb.net.ua Wed Jan 21 03:30:43 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jan 21 03:30:50 2009 Subject: device driver: cdesw questions? In-Reply-To: <49770513.8090203@icyb.net.ua> References: <49770513.8090203@icyb.net.ua> Message-ID: <4977075F.2010003@icyb.net.ua> Question 3: is it ok to use M_WAITOK in pci attach routine? -- Andriy Gapon From hselasky at c2i.net Wed Jan 21 04:28:11 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Jan 21 04:28:18 2009 Subject: device driver: cdesw questions? In-Reply-To: <4977075F.2010003@icyb.net.ua> References: <49770513.8090203@icyb.net.ua> <4977075F.2010003@icyb.net.ua> Message-ID: <200901211330.32679.hselasky@c2i.net> On Wednesday 21 January 2009, Andriy Gapon wrote: > Question 3: > is it ok to use M_WAITOK in pci attach routine? Yes. --HPS From brampton+freebsd-hackers at gmail.com Wed Jan 21 04:37:34 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Wed Jan 21 04:37:41 2009 Subject: Kernel Module - GCC Requires memmove Message-ID: Hi, I'm doing the unusual task of converting some c++ code into a FreeBSD kernel module. Now all has been going great, and thus far I've been able to debug quite a bit of it using printfs. However, I decided to start using a kernel debugger, and to make this easier I passed g++ the ?O0 flag, to make it compile without optimisations. Bang, I hit a problem. All of a sudden when using the ?O0 my module wouldn't load because it was missing an undefined reference to memmove. I found the specific object file which was using memmove. I did that by doing objdump ?t *.o and finding which file had an undefined symbol memmove. Once I found the object file I grepped the associated source and I was sure I was not using memmove. I then got gcc to output both the post-processed source, as well as the asm. The .ii file (post-processed source) did NOT mention memmove at all. So I found it very odd that an undefined symbol existed in the object file. So then I looked in the .s file (asm), and it was clearing making a single call to memmove. So after a few hours of pulling my hair out I found this in the gcc manual: "-nostdlib .... The compiler may generate calls to memcmp, memset, memcpy and memmove. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified." So it appears that gcc may add calls to those four functions even if you don't use them yourself? I assume this has not been a problem for anyone yet due to only crazy people trying to use c++ in the kernel, and the specific set of gcc options I'm using. For the moment I have fixed this problem now by defining my own memmove like so: extern "C" void * memmove(void * dst, const void * src, size_t len) { bcopy(src, dst, len); return dst; } But I was wondering if those four functions should be defined in the kernel? I notice that memcpy and memset are already defined by the kernel somewhere, so perhaps memmove and memcmp should join them? Oh I should mention this was happening with the default gcc under FreeBSD 7.1. Thanks Andrew From kostikbel at gmail.com Wed Jan 21 05:35:27 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jan 21 05:35:37 2009 Subject: device driver: cdesw questions? In-Reply-To: <49770513.8090203@icyb.net.ua> References: <49770513.8090203@icyb.net.ua> Message-ID: <20090121133520.GK58517@deviant.kiev.zoral.com.ua> On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: > > Question 1: > I am writing a driver that would use per-open private data (among other > features). > Do I have to use D_TRACKCLOSE flag in this case? No, the dtr registered with devfs_set_cdevpriv(), is called exactly once when the last close is performed, or the device is destroyed. > In general I am a little bit confused about when d_close is invoked. > Supposing D_TRACKCLOSE is not set and multiple programs concurrently > open, use and close a device - when d_close is called - when one program > closes its last descriptor tied to the device or when the system-wide > last such descriptor is closed? D_TRACKCLOSE (attempt to) tracks _file_ close, not filedescriptor close. This actually becomes quite messed up when revoke(2) or forced unmounts of the devfs mount points are mixed in. > > Question 2: > I also would like the driver to provide a select capability quite > similar to that of network (e.g. TCP) sockets using d_poll. I.e. a > userland program should be able to query when it can write data to the > device without blocking and when it can read data without blocking, plus > when an error occurred in the device/driver, so there is no point in > further waiting. > At this moment I am thoroughly confused by meaning of various event > masks described in poll(2). E.g. what is normal priority, non-zero > priority and high priority. poll(2) comes from the Streams, where the messages in the queues do have priorities. See getmsgp(2) on Solaris for the start. Most likely, you do not need any priorities except POLLXXNORM, and FreeBSD uses POLLRDBAND for OOB TCP data only. > Which flags should I care about if all data is the same priority for me? > Which flag(s) should I set when I'd like to communicate an error > condition (e.g. similar to TCP connection reset)? I believe, it is a POLLHUP. See the sys_pipe.c, pipe_poll() for the rather clean example of the poll handler. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090121/a5485a99/attachment.pgp From avg at icyb.net.ua Wed Jan 21 05:40:34 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jan 21 05:40:41 2009 Subject: device driver: cdesw questions? In-Reply-To: <20090121133520.GK58517@deviant.kiev.zoral.com.ua> References: <49770513.8090203@icyb.net.ua> <20090121133520.GK58517@deviant.kiev.zoral.com.ua> Message-ID: <497725C8.4010101@icyb.net.ua> on 21/01/2009 15:35 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: >> Question 1: >> I am writing a driver that would use per-open private data (among other >> features). >> Do I have to use D_TRACKCLOSE flag in this case? > No, the dtr registered with devfs_set_cdevpriv(), is called exactly once > when the last close is performed, or the device is destroyed. Kostik, thanks a lot for the explanation! I am still a little bit confused about the term "last close" - what is it? I.e. I'd like to get an answer to the below question. >> In general I am a little bit confused about when d_close is invoked. >> Supposing D_TRACKCLOSE is not set and multiple programs concurrently >> open, use and close a device - when d_close is called - when one program >> closes its last descriptor tied to the device or when the system-wide >> last such descriptor is closed? -- Andriy Gapon From rwatson at FreeBSD.org Wed Jan 21 05:52:57 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jan 21 05:53:05 2009 Subject: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: <20090120.131627.-1717264382.imp@bsdimp.com> References: <20090120.131627.-1717264382.imp@bsdimp.com> Message-ID: On Tue, 20 Jan 2009, M. Warner Losh wrote: > In message: > "Jacky Oh" writes: > : Hi, > : > : I'm writing a syscall module and he compiles well but at load time, kldload > : shows: > : > : KLD: program.ko: depends of kernel - no avaiable > : > : anyone know something about this? > > Yes. rebuild the kernel and modules to have the same __FreeBSD_version It would be nice if the kernel linker included version numbers, both expected and found, in these messages. Unfortunately, this code is rather well-abstracted, and the specific version numbers are rather inaccessible at the point where the error message is printed. Robert N M Watson Computer Laboratory University of Cambridge From kostikbel at gmail.com Wed Jan 21 05:55:21 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jan 21 05:55:32 2009 Subject: device driver: cdesw questions? In-Reply-To: <497725C8.4010101@icyb.net.ua> References: <49770513.8090203@icyb.net.ua> <20090121133520.GK58517@deviant.kiev.zoral.com.ua> <497725C8.4010101@icyb.net.ua> Message-ID: <20090121135510.GL58517@deviant.kiev.zoral.com.ua> On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: > on 21/01/2009 15:35 Kostik Belousov said the following: > > On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: > >> Question 1: > >> I am writing a driver that would use per-open private data (among other > >> features). > >> Do I have to use D_TRACKCLOSE flag in this case? > > No, the dtr registered with devfs_set_cdevpriv(), is called exactly once > > when the last close is performed, or the device is destroyed. > > Kostik, > > thanks a lot for the explanation! > I am still a little bit confused about the term "last close" - what is > it? I.e. I'd like to get an answer to the below question. > > >> In general I am a little bit confused about when d_close is invoked. > >> Supposing D_TRACKCLOSE is not set and multiple programs concurrently > >> open, use and close a device - when d_close is called - when one program > >> closes its last descriptor tied to the device or when the system-wide > >> last such descriptor is closed? The kernel data structures for the opened device are as follows: filedesc ---> struct file ---> vnode ---> cdev [cdevpriv] \ / --------->----- Each -> arrow represents a "many to one" relation. There may be zero or one cdevpriv datum associated with struct file. cdev maintains the si_usecount, that is an accumulation of the vref counters for all devfs vnodes that are attached to the cdev. devfs_close() vop is called when the struct file is released. When D_TRACKCLOSE is specified, d_close driver method will be called unconditionally. When D_TRACKCLOSE is not specified, d_close is called when si_usecount is exactly 1, to become zero after the last close of the file that opened a vnode referencing cdev. Also, d_close() is called if the vnode is being reclaimed. Possible causes are revoke(2) call or forced devfs mp unmount. This interferes with close counting. cdevpriv dtr is called when either struct file is released, or device is destroyed by the destroy_dev(). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090121/bbaa9af2/attachment.pgp From rwatson at FreeBSD.org Wed Jan 21 06:05:30 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jan 21 06:05:37 2009 Subject: device driver: cdesw questions? In-Reply-To: <49770513.8090203@icyb.net.ua> References: <49770513.8090203@icyb.net.ua> Message-ID: On Wed, 21 Jan 2009, Andriy Gapon wrote: > Question 1: I am writing a driver that would use per-open private data > (among other features). Do I have to use D_TRACKCLOSE flag in this case? In > general I am a little bit confused about when d_close is invoked. Supposing > D_TRACKCLOSE is not set and multiple programs concurrently open, use and > close a device - when d_close is called - when one program closes its last > descriptor tied to the device or when the system-wide last such descriptor > is closed? Kostik has already pointed at the cdevpriv API, but just to reiterate his point: most people will find the semantics of D_TRACKCLOSE confusing and consider them incorrect, so I would advise against using them. > I also would like the driver to provide a select capability quite > similar to that of network (e.g. TCP) sockets using d_poll. I.e. a > userland program should be able to query when it can write data to the > device without blocking and when it can read data without blocking, plus > when an error occurred in the device/driver, so there is no point in > further waiting. > At this moment I am thoroughly confused by meaning of various event > masks described in poll(2). E.g. what is normal priority, non-zero > priority and high priority. > Which flags should I care about if all data is the same priority for me? > Which flag(s) should I set when I'd like to communicate an error > condition (e.g. similar to TCP connection reset)? I find that the description of the polling flags is at best confusing in both man pages and specifications. The best bet is to look at the existing TCP semantics, which are basically defined in sopoll_generic(): if (events & (POLLIN | POLLRDNORM)) if (soreadable(so)) revents |= events & (POLLIN | POLLRDNORM); if (events & POLLINIGNEOF) if (so->so_rcv.sb_cc >= so->so_rcv.sb_lowat || !TAILQ_EMPTY(&so->so_comp) || so->so_error) revents |= POLLINIGNEOF; if (events & (POLLOUT | POLLWRNORM)) if (sowriteable(so)) revents |= events & (POLLOUT | POLLWRNORM); if (events & (POLLPRI | POLLRDBAND)) if (so->so_oobmark || (so->so_rcv.sb_state & SBS_RCVATMARK)) revents |= events & (POLLPRI | POLLRDBAND); A few observations: - Neither POLLHUP nor POLLERR appear to be implemented for sockets (all protocols use sopoll_generic in practice). This is surprising given the wording in the poll(2) man page. - Make sure to distinguish POLLIN and POLLINIGNEOF -- the difference between soreadable() and the test in POLLIGNEOF is that POLLIN also considers SBS_CANTRCVMORE (i.e., at least half-close in the receive direction) but POLLIGNEOF doesn't. I think Kostik's pointer to the pipe_poll() code is a good one, but if you're looking to emulate TCP semantics a bit more exactly, these differences should be taken into account. Robert N M Watson Computer Laboratory University of Cambridge From avg at icyb.net.ua Wed Jan 21 06:08:01 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jan 21 06:08:09 2009 Subject: device driver: cdesw questions? In-Reply-To: <20090121135510.GL58517@deviant.kiev.zoral.com.ua> References: <49770513.8090203@icyb.net.ua> <20090121133520.GK58517@deviant.kiev.zoral.com.ua> <497725C8.4010101@icyb.net.ua> <20090121135510.GL58517@deviant.kiev.zoral.com.ua> Message-ID: <49772C3A.10005@icyb.net.ua> on 21/01/2009 15:55 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: >> on 21/01/2009 15:35 Kostik Belousov said the following: >>> On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: >>>> Question 1: >>>> I am writing a driver that would use per-open private data (among other >>>> features). >>>> Do I have to use D_TRACKCLOSE flag in this case? >>> No, the dtr registered with devfs_set_cdevpriv(), is called exactly once >>> when the last close is performed, or the device is destroyed. >> Kostik, >> >> thanks a lot for the explanation! >> I am still a little bit confused about the term "last close" - what is >> it? I.e. I'd like to get an answer to the below question. >> >>>> In general I am a little bit confused about when d_close is invoked. >>>> Supposing D_TRACKCLOSE is not set and multiple programs concurrently >>>> open, use and close a device - when d_close is called - when one program >>>> closes its last descriptor tied to the device or when the system-wide >>>> last such descriptor is closed? > > The kernel data structures for the opened device are as follows: > > filedesc ---> struct file ---> vnode ---> cdev > [cdevpriv] \ / > --------->----- > > Each -> arrow represents a "many to one" relation. There may be zero > or one cdevpriv datum associated with struct file. > > cdev maintains the si_usecount, that is an accumulation of the vref > counters for all devfs vnodes that are attached to the cdev. > devfs_close() vop is called when the struct file is released. > When D_TRACKCLOSE is specified, d_close driver method will be > called unconditionally. > When D_TRACKCLOSE is not specified, d_close is called when si_usecount > is exactly 1, to become zero after the last close of the file that > opened a vnode referencing cdev. > Also, d_close() is called if the vnode is being reclaimed. Possible > causes are revoke(2) call or forced devfs mp unmount. This interferes > with close counting. > > cdevpriv dtr is called when either struct file is released, or > device is destroyed by the destroy_dev(). Kostik, is the following true: if D_TRACKCLOSE is specified then a number of d_close() calls and a number of cdevpriv dtr calls are equal (provide each file gets cdevpriv data) ? If not, what is the case where one is called but not the other? -- Andriy Gapon From avg at icyb.net.ua Wed Jan 21 06:12:30 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jan 21 06:12:36 2009 Subject: device driver: cdesw questions? In-Reply-To: References: <49770513.8090203@icyb.net.ua> Message-ID: <49772D47.2090602@icyb.net.ua> on 21/01/2009 16:05 Robert Watson said the following: > > On Wed, 21 Jan 2009, Andriy Gapon wrote: > >> Question 1: I am writing a driver that would use per-open private data >> (among other features). Do I have to use D_TRACKCLOSE flag in this >> case? In general I am a little bit confused about when d_close is >> invoked. Supposing D_TRACKCLOSE is not set and multiple programs >> concurrently open, use and close a device - when d_close is called - >> when one program closes its last descriptor tied to the device or when >> the system-wide last such descriptor is closed? > > Kostik has already pointed at the cdevpriv API, but just to reiterate > his point: most people will find the semantics of D_TRACKCLOSE confusing > and consider them incorrect, so I would advise against using them. Robert, Kostik, in simplistic layman's terms I need the following - when a particular program "closes my cdev" (explicitly or via exit) I need to catch that and de-allocate certain resources. There can be multiple concurrent programs opening, using and closing my cdev. I guess what you both say is that I shouldn't use D_TRACKCLOSE, instead I should perform the resource management in cdevpriv destructor. Am I guessing correctly this time? -- Andriy Gapon From kostikbel at gmail.com Wed Jan 21 06:14:08 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jan 21 06:14:14 2009 Subject: device driver: cdesw questions? In-Reply-To: <49772C3A.10005@icyb.net.ua> References: <49770513.8090203@icyb.net.ua> <20090121133520.GK58517@deviant.kiev.zoral.com.ua> <497725C8.4010101@icyb.net.ua> <20090121135510.GL58517@deviant.kiev.zoral.com.ua> <49772C3A.10005@icyb.net.ua> Message-ID: <20090121141355.GM58517@deviant.kiev.zoral.com.ua> On Wed, Jan 21, 2009 at 04:07:54PM +0200, Andriy Gapon wrote: > on 21/01/2009 15:55 Kostik Belousov said the following: > > On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: > >> on 21/01/2009 15:35 Kostik Belousov said the following: > >>> On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: > >>>> Question 1: > >>>> I am writing a driver that would use per-open private data (among other > >>>> features). > >>>> Do I have to use D_TRACKCLOSE flag in this case? > >>> No, the dtr registered with devfs_set_cdevpriv(), is called exactly once > >>> when the last close is performed, or the device is destroyed. > >> Kostik, > >> > >> thanks a lot for the explanation! > >> I am still a little bit confused about the term "last close" - what is > >> it? I.e. I'd like to get an answer to the below question. > >> > >>>> In general I am a little bit confused about when d_close is invoked. > >>>> Supposing D_TRACKCLOSE is not set and multiple programs concurrently > >>>> open, use and close a device - when d_close is called - when one program > >>>> closes its last descriptor tied to the device or when the system-wide > >>>> last such descriptor is closed? > > > > The kernel data structures for the opened device are as follows: > > > > filedesc ---> struct file ---> vnode ---> cdev > > [cdevpriv] \ / > > --------->----- > > > > Each -> arrow represents a "many to one" relation. There may be zero > > or one cdevpriv datum associated with struct file. > > > > cdev maintains the si_usecount, that is an accumulation of the vref > > counters for all devfs vnodes that are attached to the cdev. > > devfs_close() vop is called when the struct file is released. > > When D_TRACKCLOSE is specified, d_close driver method will be > > called unconditionally. > > When D_TRACKCLOSE is not specified, d_close is called when si_usecount > > is exactly 1, to become zero after the last close of the file that > > opened a vnode referencing cdev. > > Also, d_close() is called if the vnode is being reclaimed. Possible > > causes are revoke(2) call or forced devfs mp unmount. This interferes > > with close counting. > > > > cdevpriv dtr is called when either struct file is released, or > > device is destroyed by the destroy_dev(). > > Kostik, > > is the following true: if D_TRACKCLOSE is specified then a number of > d_close() calls and a number of cdevpriv dtr calls are equal (provide > each file gets cdevpriv data) ? > If not, what is the case where one is called but not the other? No, I already described this. See the note about vnode reclamation. Also, d_close counter would have an interacation with destroy_dev(). To give you short summary, for D_TRACKCLOSE, d_close() may be called less times then dtr. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090121/5b8f7de0/attachment.pgp From kostikbel at gmail.com Wed Jan 21 06:15:16 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jan 21 06:15:23 2009 Subject: device driver: cdesw questions? In-Reply-To: <49772D47.2090602@icyb.net.ua> References: <49770513.8090203@icyb.net.ua> <49772D47.2090602@icyb.net.ua> Message-ID: <20090121141509.GN58517@deviant.kiev.zoral.com.ua> On Wed, Jan 21, 2009 at 04:12:23PM +0200, Andriy Gapon wrote: > on 21/01/2009 16:05 Robert Watson said the following: > > > > On Wed, 21 Jan 2009, Andriy Gapon wrote: > > > >> Question 1: I am writing a driver that would use per-open private data > >> (among other features). Do I have to use D_TRACKCLOSE flag in this > >> case? In general I am a little bit confused about when d_close is > >> invoked. Supposing D_TRACKCLOSE is not set and multiple programs > >> concurrently open, use and close a device - when d_close is called - > >> when one program closes its last descriptor tied to the device or when > >> the system-wide last such descriptor is closed? > > > > Kostik has already pointed at the cdevpriv API, but just to reiterate > > his point: most people will find the semantics of D_TRACKCLOSE confusing > > and consider them incorrect, so I would advise against using them. > > Robert, Kostik, > > in simplistic layman's terms I need the following - when a particular > program "closes my cdev" (explicitly or via exit) I need to catch that > and de-allocate certain resources. There can be multiple concurrent > programs opening, using and closing my cdev. > > I guess what you both say is that I shouldn't use D_TRACKCLOSE, instead > I should perform the resource management in cdevpriv destructor. > Am I guessing correctly this time? Yes. This is the purpose of the cdevpriv KPI. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090121/4bf2d0ce/attachment.pgp From avg at icyb.net.ua Wed Jan 21 06:16:18 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jan 21 06:16:24 2009 Subject: device driver: cdesw questions? In-Reply-To: <20090121141509.GN58517@deviant.kiev.zoral.com.ua> References: <49770513.8090203@icyb.net.ua> <49772D47.2090602@icyb.net.ua> <20090121141509.GN58517@deviant.kiev.zoral.com.ua> Message-ID: <49772E2C.7050008@icyb.net.ua> on 21/01/2009 16:15 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 04:12:23PM +0200, Andriy Gapon wrote: >> on 21/01/2009 16:05 Robert Watson said the following: >>> On Wed, 21 Jan 2009, Andriy Gapon wrote: >>> >>>> Question 1: I am writing a driver that would use per-open private data >>>> (among other features). Do I have to use D_TRACKCLOSE flag in this >>>> case? In general I am a little bit confused about when d_close is >>>> invoked. Supposing D_TRACKCLOSE is not set and multiple programs >>>> concurrently open, use and close a device - when d_close is called - >>>> when one program closes its last descriptor tied to the device or when >>>> the system-wide last such descriptor is closed? >>> Kostik has already pointed at the cdevpriv API, but just to reiterate >>> his point: most people will find the semantics of D_TRACKCLOSE confusing >>> and consider them incorrect, so I would advise against using them. >> Robert, Kostik, >> >> in simplistic layman's terms I need the following - when a particular >> program "closes my cdev" (explicitly or via exit) I need to catch that >> and de-allocate certain resources. There can be multiple concurrent >> programs opening, using and closing my cdev. >> >> I guess what you both say is that I shouldn't use D_TRACKCLOSE, instead >> I should perform the resource management in cdevpriv destructor. >> Am I guessing correctly this time? > > Yes. This is the purpose of the cdevpriv KPI. Thank you! Sorry for being so thick :-) -- Andriy Gapon From avg at icyb.net.ua Wed Jan 21 07:03:24 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jan 21 07:03:32 2009 Subject: MOD_UNLOAD and driver with cdev Message-ID: <49773938.5010000@icyb.net.ua> Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? I see in the current code that one strategy is to simply call destroy_dev(). I guess detach routines are called automatically and destroy_dev can be done there as well.. Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? How to check for that best? -- Andriy Gapon From kostikbel at gmail.com Wed Jan 21 07:39:13 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jan 21 07:39:20 2009 Subject: MOD_UNLOAD and driver with cdev In-Reply-To: <49773938.5010000@icyb.net.ua> References: <49773938.5010000@icyb.net.ua> Message-ID: <20090121153908.GO58517@deviant.kiev.zoral.com.ua> On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: > > Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? > I see in the current code that one strategy is to simply call > destroy_dev(). I guess detach routines are called automatically and > destroy_dev can be done there as well.. What are the detach routines ? Do you mean newbus device detach ? Yes, the usual strategy is to call destroy_dev from unload handler. > > Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? > How to check for that best? This cannot be checked race-free. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090121/2dcdfd7f/attachment.pgp From avg at icyb.net.ua Wed Jan 21 07:50:45 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jan 21 07:50:51 2009 Subject: MOD_UNLOAD and driver with cdev In-Reply-To: <20090121153908.GO58517@deviant.kiev.zoral.com.ua> References: <49773938.5010000@icyb.net.ua> <20090121153908.GO58517@deviant.kiev.zoral.com.ua> Message-ID: <4977444E.8050306@icyb.net.ua> on 21/01/2009 17:39 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: >> Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? >> I see in the current code that one strategy is to simply call >> destroy_dev(). I guess detach routines are called automatically and >> destroy_dev can be done there as well.. > What are the detach routines ? Do you mean newbus device detach ? Yes, device_detach. This seems to work and make_device_driver.sh also suggests it this way. But I am not sure about possible races. > Yes, the usual strategy is to call destroy_dev from unload handler. > >> Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? >> How to check for that best? > > This cannot be checked race-free. So no point in trying? -- Andriy Gapon From kostikbel at gmail.com Wed Jan 21 07:57:18 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jan 21 07:57:25 2009 Subject: MOD_UNLOAD and driver with cdev In-Reply-To: <4977444E.8050306@icyb.net.ua> References: <49773938.5010000@icyb.net.ua> <20090121153908.GO58517@deviant.kiev.zoral.com.ua> <4977444E.8050306@icyb.net.ua> Message-ID: <20090121155713.GP58517@deviant.kiev.zoral.com.ua> On Wed, Jan 21, 2009 at 05:50:38PM +0200, Andriy Gapon wrote: > on 21/01/2009 17:39 Kostik Belousov said the following: > > On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: > >> Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? > >> I see in the current code that one strategy is to simply call > >> destroy_dev(). I guess detach routines are called automatically and > >> destroy_dev can be done there as well.. > > What are the detach routines ? Do you mean newbus device detach ? > > Yes, device_detach. This seems to work and make_device_driver.sh also > suggests it this way. But I am not sure about possible races. > > > Yes, the usual strategy is to call destroy_dev from unload handler. > > > >> Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? > >> How to check for that best? > > > > This cannot be checked race-free. > > So no point in trying? I would say no. You could use count_dev(), but my own experience shown that ability to unload driver is more important then unadvertently knock out filedescriptor from under the running program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090121/0573c82b/attachment.pgp From jhb at freebsd.org Wed Jan 21 12:09:41 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jan 21 12:10:07 2009 Subject: PRINTF_BUFR_SIZE in freebsd6 In-Reply-To: References: Message-ID: <200901211402.52967.jhb@freebsd.org> On Wednesday 17 December 2008 8:52:38 am pluknet wrote: > 2008/12/17 pluknet : > > 2008/12/16 Kostik Belousov : > >> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote: > >>> Hi. > >>> > >>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 without > >>> merging a possible underlining infrastructure and breaking something else? > >>> I want to use it in my custom freebsd6 because I see "interspersed strings > >>> written from different CPUs at the same time": > >>> > >>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t > >>> pde) eaxtx cfcorke1 22e3e > >>> deded ebyd by28 296898 68(h t(tpdh) att ftorkp1 22d3 > >>> ) at fork1 223 > >>> > >>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129. > >>> > >>> Thanks. > >> > >> I did a backport of the option some time ago, see > >> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch > >> > > > > Thank you! > > > > 6.3 system panics (many page faults, one after another) early at boot > > without the option, and boots with it in the QEMU environment. > > Next step to test it on a real (and SMPable) hardware. > > > > Now tested on a real 2xXeon 3.0 w/ HTT enabled w/ PRINTF_BUFR_SIZE enabled. > > Received the following panic: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x72 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07fc8c3 > stack pointer = 0x28:0xe4f56a78 > frame pointer = 0x28:0xe4f56b44 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 14 (swi4: clock sio) > [thread pid 14 tid 100002 ] > Stopped at vm_fault+0x1e3: cmpw $0,0x72(%eax) > db> bt > Tracing pid 14 tid 100002 td 0xc63e9c80 > vm_fault(c1066000,c009e000,2,0) at vm_fault+0x1e3 > trap_pfault(e4f56bb0,0,c009effe) at trap_pfault+0x137 > trap(410008,c63e0028,e4f50028,c009effe,c638effe,...) at trap+0x325 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc08a2cad, esp = 0xe4f56bf0, ebp = 0xe4f56c10 --- > generic_bcopy(c0a63a68,7cf,c0a63a4c,7cf,fffff832) at generic_bcopy+0x41 > vga_txtdraw(c0a63a40,7cf,fffff832,0) at vga_txtdraw+0xbe > scrn_update(c0a63a40,1) at scrn_update+0x22d > scrn_timer(c0a6c1e0) at scrn_timer+0x1e0 > softclock(0) at softclock+0x1f4 > ithread_execute_handlers(c63e8460,c6629800) at ithread_execute_handlers+0xd6 > ithread_loop(c63a7910,e4f56d38,c0a10040,0,c0922ea6,...) at ithread_loop+0x53 > fork_exit(c068d158,c63a7910,e4f56d38) at fork_exit+0x61 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe4f56d6c, ebp = 0 --- > db> I've seen this panic (or varations of it) on stock 6.x for a long time. I suspect some sort of bug in syscons itself. -- John Baldwin From jhb at freebsd.org Wed Jan 21 12:09:48 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jan 21 12:10:08 2009 Subject: usb keyboard vs btx: an SMI theory In-Reply-To: <4947AA3C.4040005@icyb.net.ua> References: <4947AA3C.4040005@icyb.net.ua> Message-ID: <200901211407.44021.jhb@freebsd.org> On Tuesday 16 December 2008 8:16:44 am Andriy Gapon wrote: > Again, I am very fuzzy about the exact details, but I think that this is > something that could be happening and I think that SMI is of primary > interest here. I also think that this might explain to a certain degree > the difference in behavior between "older" btx and "newer" btx. One thing to keep in mind is that when an SMI# is delivered, the processor enters System Management Mode (SMM). In SMM, the CPU actually uses a different set of memory for its RAM. It also runs in a sort of weird 32-bit real mode. It is not going to call the stock IRQ 1 handler. Instead, it passes data back to "normal" mode by changing the values restored into registers when exiting SMM. Typically doing an I/O port access to the ports backing the keyboard (0x60 and 0x64) cause an SMI# and the SMM handler emulates the inb/outb request by storing the resulting data for an inb in the %ax register the "normal" mode sees once it resumes execution after the 'inb' instruction. -- John Baldwin From jhb at freebsd.org Wed Jan 21 12:09:54 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jan 21 12:10:09 2009 Subject: How to "detach" a foreign driver from a device so my driver can attach? In-Reply-To: <20081223173322.GA4123@curry.mchp.siemens.de> References: <20081216230430.GA24352@curry.mchp.siemens.de> <20081223173322.GA4123@curry.mchp.siemens.de> Message-ID: <200901211408.37883.jhb@freebsd.org> On Tuesday 23 December 2008 12:33:22 pm Andre Albsmeier wrote: > On Wed, 17-Dec-2008 at 00:04:30 +0100, Andre Albsmeier wrote: > > Hello all, > > > > I am writing a driver which attaches to the Host-PCI bridge. When > > compiled into the kernel or loaded by the loader everything works > > and the driver gets attached. This is due to the fact that I return > > BUS_PROBE_SPECIFIC in my probe routine which gains over the -10000 > > returned by pci_hostb_probe() in i386/pci/pci_bus.c. > > > > However, when I want to load my driver via kldload this fails since > > the hostb device has already been attached during kernel load (when > > my driver was not present): > > > > hostb0@pci0:0:0: class=0x060000 card=0x11d510cf chip=0x35808086 rev=0x02 hdr=0x00 > > > > What can I do to make my driver load via kldload? > > Is there a way to detach the hostb0 from the Host-PCI bridge? > > Found the answer myself but will post it here in case anyone > got a similar problem one day: I added the device detach method > for the hostb driver to sys/i386/pci/pci_bus.c: > > --- sys/i386/pci/pci_bus.c.ORI 2007-08-17 08:12:33.000000000 +0200 > +++ sys/i386/pci/pci_bus.c 2008-12-23 13:34:35.000000000 +0100 > @@ -619,10 +619,13 @@ > return 0; > } > > +static int pci_hostb_detach(device_t dev) { return 0; } > + > static device_method_t pci_hostb_methods[] = { > /* Device interface */ > DEVMETHOD(device_probe, pci_hostb_probe), > DEVMETHOD(device_attach, pci_hostb_attach), > + DEVMETHOD(device_detach, pci_hostb_detach), > DEVMETHOD(device_shutdown, bus_generic_shutdown), > DEVMETHOD(device_suspend, bus_generic_suspend), > DEVMETHOD(device_resume, bus_generic_resume), > > Now, when kldload'ing my driver, it can walk through all devices > and detach hostb using device_detach(). In the case of hostb, this is wrong however. You want to attach as a child of hostb as other devices (e.g. agp(4)) need to attach to host-pci bridges as well. -- John Baldwin From green at FreeBSD.org Wed Jan 21 15:00:37 2009 From: green at FreeBSD.org (Brian Fundakowski Feldman) Date: Wed Jan 21 15:00:43 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090120004135.GB12007@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> Message-ID: <20090121230033.GC12007@green.homeunix.org> On Mon, Jan 19, 2009 at 07:41:35PM -0500, Brian Fundakowski Feldman wrote: > On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote: > > Brian Fundakowski Feldman wrote: > > > Could you, and anyone else who would care to, check this out? It's a > > regression > >> fix but it also makes the code a little bit clearer. Thanks! > >> > >> Index: lib/libc/stdlib/malloc.c > > > > Why does malloc need to change for this? Unless there's a really good > > reason, I don't want the extra branches in the locking functions. > > Because malloc is the thing causing the regression. It is easy enough > to optimize out the one extra fetch and branch in the single-threaded case > if I can get some consensus that the fix to it is actually fine. Pessimization removed: Index: lib/libc/stdlib/malloc.c =================================================================== --- lib/libc/stdlib/malloc.c (revision 187160) +++ lib/libc/stdlib/malloc.c (working copy) @@ -1217,6 +1217,13 @@ _SPINUNLOCK(&mutex->lock); } +static inline void +malloc_mutex_always_unlock(malloc_mutex_t *mutex) +{ + + _SPINUNLOCK(&mutex->lock); +} + /* * End mutex. */ @@ -1300,6 +1307,13 @@ _pthread_mutex_unlock(lock); } +static inline void +malloc_spin_always_unlock(pthread_mutex_t *lock) +{ + + _pthread_mutex_unlock(lock); +} + /* * End spin lock. */ @@ -5515,9 +5529,8 @@ void _malloc_prefork(void) { + arena_t *larenas[narenas]; bool again; - unsigned i, j; - arena_t *larenas[narenas], *tarenas[narenas]; /* Acquire all mutexes in a safe order. */ @@ -5530,19 +5543,23 @@ */ memset(larenas, 0, sizeof(arena_t *) * narenas); do { + unsigned int i; + again = false; malloc_spin_lock(&arenas_lock); for (i = 0; i < narenas; i++) { if (arenas[i] != larenas[i]) { + arena_t *tarenas[narenas]; + unsigned int j; + memcpy(tarenas, arenas, sizeof(arena_t *) * narenas); malloc_spin_unlock(&arenas_lock); for (j = 0; j < narenas; j++) { if (larenas[j] != tarenas[j]) { larenas[j] = tarenas[j]; - malloc_spin_lock( - &larenas[j]->lock); + malloc_spin_lock(&larenas[j]->lock); } } again = true; @@ -5569,19 +5586,24 @@ /* Release all mutexes, now that fork() has completed. */ #ifdef MALLOC_DSS - malloc_mutex_unlock(&dss_mtx); + malloc_mutex_always_unlock(&dss_mtx); #endif - malloc_mutex_unlock(&huge_mtx); + malloc_mutex_always_unlock(&huge_mtx); - malloc_mutex_unlock(&base_mtx); + malloc_mutex_always_unlock(&base_mtx); memcpy(larenas, arenas, sizeof(arena_t *) * narenas); - malloc_spin_unlock(&arenas_lock); + malloc_spin_always_unlock(&arenas_lock); for (i = 0; i < narenas; i++) { if (larenas[i] != NULL) - malloc_spin_unlock(&larenas[i]->lock); + malloc_spin_always_unlock(&larenas[i]->lock); } + /* + * This ends the special post-__isthreaded exemption behavior for + * malloc stuff. We should really be single threaded right now + * in effect regardless of __isthreaded status. + */ } /* Index: lib/libthr/thread/thr_fork.c =================================================================== --- lib/libthr/thread/thr_fork.c (revision 187160) +++ lib/libthr/thread/thr_fork.c (working copy) @@ -105,7 +105,7 @@ struct pthread_atfork *af; pid_t ret; int errsave; - int unlock_malloc; + int was_threaded; int rtld_locks[MAX_RTLD_LOCKS]; if (!_thr_is_inited()) @@ -122,16 +122,16 @@ } /* - * Try our best to protect memory from being corrupted in - * child process because another thread in malloc code will - * simply be kill by fork(). + * All bets are off as to what should happen soon if the parent + * process was not so kindly as to set up pthread fork hooks to + * relinquish all running threads. */ if (_thr_isthreaded() != 0) { - unlock_malloc = 1; + was_threaded = 1; _malloc_prefork(); _rtld_atfork_pre(rtld_locks); } else { - unlock_malloc = 0; + was_threaded = 0; } /* @@ -159,7 +159,7 @@ _thr_umutex_init(&curthread->lock); _thr_umutex_init(&_thr_atfork_lock); - if (unlock_malloc) + if (was_threaded) _rtld_atfork_post(rtld_locks); _thr_setthreaded(0); @@ -173,7 +173,7 @@ /* Ready to continue, unblock signals. */ _thr_signal_unblock(curthread); - if (unlock_malloc) + if (was_threaded) _malloc_postfork(); /* Run down atfork child handlers. */ @@ -188,7 +188,7 @@ /* Ready to continue, unblock signals. */ _thr_signal_unblock(curthread); - if (unlock_malloc) { + if (was_threaded) { _rtld_atfork_post(rtld_locks); _malloc_postfork(); } -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From yanefbsd at gmail.com Wed Jan 21 15:26:11 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Wed Jan 21 15:26:20 2009 Subject: Kernel Module - GCC Requires memmove In-Reply-To: References: Message-ID: <7d6fde3d0901211526x26e03968n658874fe7a7b85cf@mail.gmail.com> On Wed, Jan 21, 2009 at 4:12 AM, Andrew Brampton wrote: > Hi, > I'm doing the unusual task of converting some c++ code into a FreeBSD > kernel module. Now all has been going great, and thus far I've been > able to debug quite a bit of it using printfs. However, I decided to > start using a kernel debugger, and to make this easier I passed g++ > the ?O0 flag, to make it compile without optimisations. > > Bang, I hit a problem. All of a sudden when using the ?O0 my module > wouldn't load because it was missing an undefined reference to > memmove. I found the specific object file which was using memmove. I > did that by doing objdump ?t *.o and finding which file had an > undefined symbol memmove. Once I found the object file I grepped the > associated source and I was sure I was not using memmove. I then got > gcc to output both the post-processed source, as well as the asm. > > The .ii file (post-processed source) did NOT mention memmove at all. > So I found it very odd that an undefined symbol existed in the object > file. So then I looked in the .s file (asm), and it was clearing > making a single call to memmove. > > So after a few hours of pulling my hair out I found this in the gcc manual: > "-nostdlib .... The compiler may generate calls to memcmp, memset, > memcpy and memmove. These entries are usually resolved by entries in > libc. These entry points should be supplied through some other > mechanism when this option is specified." > > So it appears that gcc may add calls to those four functions even if > you don't use them yourself? I assume this has not been a problem for > anyone yet due to only crazy people trying to use c++ in the kernel, > and the specific set of gcc options I'm using. > > For the moment I have fixed this problem now by defining my own memmove like so: > > extern "C" void * memmove(void * dst, const void * src, size_t len) { > bcopy(src, dst, len); > return dst; > } > > But I was wondering if those four functions should be defined in the > kernel? I notice that memcpy and memset are already defined by the > kernel somewhere, so perhaps memmove and memcmp should join them? > > Oh I should mention this was happening with the default gcc under FreeBSD 7.1. > > Thanks > Andrew And you #include'd string.h? -Garrett From deischen at freebsd.org Wed Jan 21 15:36:01 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Wed Jan 21 15:36:08 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090121230033.GC12007@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> Message-ID: On Wed, 21 Jan 2009, Brian Fundakowski Feldman wrote: > On Mon, Jan 19, 2009 at 07:41:35PM -0500, Brian Fundakowski Feldman wrote: >> On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote: >>> Brian Fundakowski Feldman wrote: >>> > Could you, and anyone else who would care to, check this out? It's a >>> regression >>>> fix but it also makes the code a little bit clearer. Thanks! >>>> >>>> Index: lib/libc/stdlib/malloc.c >>> >>> Why does malloc need to change for this? Unless there's a really good >>> reason, I don't want the extra branches in the locking functions. >> >> Because malloc is the thing causing the regression. It is easy enough >> to optimize out the one extra fetch and branch in the single-threaded case >> if I can get some consensus that the fix to it is actually fine. The changes to thr_fork.c seem gratuituous; they don't affect any functionality, and I don't see the difference between the flag saying "unlock the malloc mutex" or "I was threaded". Clearly, it is set in "if (__isthreaded)", so it is obvious that it indeed was threaded. I can't speak to the malloc changes... -- DE From dimitry at andric.com Wed Jan 21 15:44:23 2009 From: dimitry at andric.com (Dimitry Andric) Date: Wed Jan 21 15:44:29 2009 Subject: Kernel Module - GCC Requires memmove In-Reply-To: References: Message-ID: <4977B357.2080500@andric.com> On 2009-01-21 13:12, Andrew Brampton wrote: > The .ii file (post-processed source) did NOT mention memmove at all. > So I found it very odd that an undefined symbol existed in the object > file. So then I looked in the .s file (asm), and it was clearing > making a single call to memmove. This can (amongst others) occur if you assign structs, e.g.: int test(void) { struct foo { char bar[100]; } a, b; b = a; } Compile this with gcc -O0 -S, and you'll see it generates a call to memcpy(). From kabaev at gmail.com Wed Jan 21 16:14:55 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Wed Jan 21 16:15:01 2009 Subject: Kernel Module - GCC Requires memmove In-Reply-To: <4977B357.2080500@andric.com> References: <4977B357.2080500@andric.com> Message-ID: <20090121185245.00739316@kan.dnsalias.net> On Thu, 22 Jan 2009 00:44:23 +0100 Dimitry Andric wrote: > On 2009-01-21 13:12, Andrew Brampton wrote: > > The .ii file (post-processed source) did NOT mention memmove at all. > > So I found it very odd that an undefined symbol existed in the > > object file. So then I looked in the .s file (asm), and it was > > clearing making a single call to memmove. > > This can (amongst others) occur if you assign structs, e.g.: > > int test(void) > { > struct foo { > char bar[100]; > } a, b; > > b = a; > } > > Compile this with gcc -O0 -S, and you'll see it generates a call to > memcpy(). > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From GCC's info pages: Most of the compiler support routines used by GCC are present in `libgcc', but there are a few exceptions. GCC requires the freestanding environment provide `memcpy', `memmove', `memset' and `memcmp'. We do not provide all necessary functions in kernel and mostly depend on luck for the kernel to link. Your luck apparently ran out :( -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090122/ac6bcba1/signature.pgp From brampton+freebsd-hackers at gmail.com Wed Jan 21 16:52:15 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Wed Jan 21 16:52:22 2009 Subject: Kernel Module - GCC Requires memmove In-Reply-To: <20090121185245.00739316@kan.dnsalias.net> References: <4977B357.2080500@andric.com> <20090121185245.00739316@kan.dnsalias.net> Message-ID: 2009/1/21 Alexander Kabaev : > From GCC's info pages: > > Most of the compiler support routines used by GCC are present in > `libgcc', but there are a few exceptions. GCC requires the > freestanding environment provide `memcpy', `memmove', `memset' and > `memcmp'. > > > We do not provide all necessary functions in kernel and mostly depend > on luck for the kernel to link. Your luck apparently ran out :( > Thanks for the info, good thing I'm not a gambling man. Anyway I also read that part of the GCC manual, so my next question is: If code can be generated with those four functions, why are they not exported by the kernel? Surely another kernel module will at some point also be hit by this? thanks Andrew From kabaev at gmail.com Wed Jan 21 17:07:37 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Wed Jan 21 17:07:43 2009 Subject: Kernel Module - GCC Requires memmove In-Reply-To: References: <4977B357.2080500@andric.com> <20090121185245.00739316@kan.dnsalias.net> Message-ID: <20090121200730.121e3e28@kan.dnsalias.net> On Thu, 22 Jan 2009 00:52:13 +0000 Andrew Brampton wrote: > 2009/1/21 Alexander Kabaev : > > From GCC's info pages: > > > > Most of the compiler support routines used by GCC are present in > > `libgcc', but there are a few exceptions. GCC requires the > > freestanding environment provide `memcpy', `memmove', `memset' and > > `memcmp'. > > > > > > We do not provide all necessary functions in kernel and mostly > > depend on luck for the kernel to link. Your luck apparently ran > > out :( > > > > Thanks for the info, good thing I'm not a gambling man. Anyway I also > read that part of the GCC manual, so my next question is: If code can > be generated with those four functions, why are they not exported by > the kernel? Surely another kernel module will at some point also be > hit by this? > > thanks > Andrew Very good question and the answer is simple: we do not export these functions because nobody needed them yet :) Historically we have grown these functions on an 'as needed' basis. I am sure the patch to add missing functions would get committed if it were made available. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090122/507e7bd1/signature.pgp From neldredge at math.ucsd.edu Wed Jan 21 17:14:45 2009 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Wed Jan 21 17:14:51 2009 Subject: Kernel Module - GCC Requires memmove In-Reply-To: References: <4977B357.2080500@andric.com> <20090121185245.00739316@kan.dnsalias.net> Message-ID: On Thu, 22 Jan 2009, Andrew Brampton wrote: > 2009/1/21 Alexander Kabaev : >> From GCC's info pages: >> >> Most of the compiler support routines used by GCC are present in >> `libgcc', but there are a few exceptions. GCC requires the >> freestanding environment provide `memcpy', `memmove', `memset' and >> `memcmp'. >> >> >> We do not provide all necessary functions in kernel and mostly depend >> on luck for the kernel to link. Your luck apparently ran out :( >> > > Thanks for the info, good thing I'm not a gambling man. Anyway I also > read that part of the GCC manual, so my next question is: If code can > be generated with those four functions, why are they not exported by > the kernel? Surely another kernel module will at some point also be > hit by this? Possibly because the kernel is usually compiled with optimization, in which case the compiler presumably generates inline code for these functions. I vaguely recall Linux having a policy that compiling the kernel without optimization was not supported, possibly because of situations like this. -- Nate Eldredge neldredge@math.ucsd.edu From das at FreeBSD.ORG Wed Jan 21 21:06:12 2009 From: das at FreeBSD.ORG (David Schultz) Date: Wed Jan 21 21:06:19 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: References: <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> Message-ID: <20090122045637.GA61058@zim.MIT.EDU> I think there *is* a real bug here, but there's two distinct ways to fix it. When a threaded process forks, malloc acquires all its locks so that its state is consistent after a fork. However, the post-fork hook that's supposed to release these locks fails to do so in the child because the child process isn't threaded, and malloc_mutex_unlock() is optimized to be a no-op in single-threaded processes. If the child *stays* single-threaded, malloc() works by accident even with all the locks held because malloc_mutex_lock() is also a no-op in single-threaded processes. But if the child goes multi-threaded, then things break. Solution 1 is to actually unlock the locks in the child process, which is what Brian is proposing. Solution 2 is to take the position that all of this pre- and post-fork bloat in the fork() path is gratuitous and should be removed. The rationale here is that if you fork with multiple running threads, there's scads of ways in which the child's heap could be inconsistent; fork hooks would be needed not just in malloc(), but in stdio, third party libraries, etc. Why should malloc() be special? It's the programmer's job to quiesce all the threads before calling fork(), and if the programmer doesn't do this, then POSIX only guarantees that async-signal-safe functions will work. Note that Solution 2 also fixes Brian's problem if he quiesces all of his worker threads before forking (as he should!) With the pre-fork hook removed, all the locks will start out free in the child. So that's what I vote for... From deischen at freebsd.org Wed Jan 21 21:43:00 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Wed Jan 21 21:43:07 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090122045637.GA61058@zim.MIT.EDU> References: <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> <20090122045637.GA61058@zim.MIT.EDU> Message-ID: On Wed, 21 Jan 2009, David Schultz wrote: > I think there *is* a real bug here, but there's two distinct ways > to fix it. When a threaded process forks, malloc acquires all its > locks so that its state is consistent after a fork. However, the > post-fork hook that's supposed to release these locks fails to do > so in the child because the child process isn't threaded, and > malloc_mutex_unlock() is optimized to be a no-op in > single-threaded processes. If the child *stays* single-threaded, > malloc() works by accident even with all the locks held because > malloc_mutex_lock() is also a no-op in single-threaded processes. > But if the child goes multi-threaded, then things break. > > Solution 1 is to actually unlock the locks in the child process, > which is what Brian is proposing. > > Solution 2 is to take the position that all of this pre- and > post-fork bloat in the fork() path is gratuitous and should be > removed. The rationale here is that if you fork with multiple > running threads, there's scads of ways in which the child's heap > could be inconsistent; fork hooks would be needed not just in > malloc(), but in stdio, third party libraries, etc. Why should > malloc() be special? It's the programmer's job to quiesce all the > threads before calling fork(), and if the programmer doesn't do > this, then POSIX only guarantees that async-signal-safe functions > will work. > > Note that Solution 2 also fixes Brian's problem if he quiesces all > of his worker threads before forking (as he should!) With the > pre-fork hook removed, all the locks will start out free in the > child. So that's what I vote for... The problem is that our own libraries (libthr included) need to malloc() for themselves, even after a fork() in the child. After a fork(), the malloc locks should be reinitialized in the child if it was threaded, so that our implementation actually works for all the async signal calls, fork(), exec(), etc. I forget the exact failure modes for very common cases, but if you remove the re-initialization of the malloc locks, I'm sure you will have problems. Perhaps much of this malloc() stuff goes away when we move to pthread locks that are not pointers to allocated objects, but instead are actual objects/structures. This needs to be done in order for mutexes/CVs/etc to be PTHREAD_PROCESS_SHARED (placed in shared memory and used by multiple processes). In other words, pthread_mutex_t goes from this: typedef struct pthread_mutex *pthread_mutex_t; to something like this: struct __pthread_mutex { uint32_t lock; ... } typedef struct __pthread_mutex pthread_mutex_t; Same thing for CVs, and we probably should convert any other locks used internally by libc/libpthread (spinlocks). So after a fork(), there is no need to reallocate anything, it can just be reinitialized if necessary. -- DE From Andre.Albsmeier at siemens.com Wed Jan 21 23:15:18 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Wed Jan 21 23:15:25 2009 Subject: How to "detach" a foreign driver from a device so my driver can attach? In-Reply-To: <200901211408.37883.jhb@freebsd.org> References: <20081216230430.GA24352@curry.mchp.siemens.de> <20081223173322.GA4123@curry.mchp.siemens.de> <200901211408.37883.jhb@freebsd.org> Message-ID: <20090122071515.GA97409@curry.mchp.siemens.de> On Wed, 21-Jan-2009 at 14:08:37 -0500, John Baldwin wrote: > On Tuesday 23 December 2008 12:33:22 pm Andre Albsmeier wrote: > > On Wed, 17-Dec-2008 at 00:04:30 +0100, Andre Albsmeier wrote: > > > Hello all, > > > > > > I am writing a driver which attaches to the Host-PCI bridge. When > > > compiled into the kernel or loaded by the loader everything works > > > and the driver gets attached. This is due to the fact that I return > > > BUS_PROBE_SPECIFIC in my probe routine which gains over the -10000 > > > returned by pci_hostb_probe() in i386/pci/pci_bus.c. > > > > > > However, when I want to load my driver via kldload this fails since > > > the hostb device has already been attached during kernel load (when > > > my driver was not present): > > > > > > hostb0@pci0:0:0: class=0x060000 card=0x11d510cf chip=0x35808086 > rev=0x02 hdr=0x00 > > > > > > What can I do to make my driver load via kldload? > > > Is there a way to detach the hostb0 from the Host-PCI bridge? > > > > Found the answer myself but will post it here in case anyone > > got a similar problem one day: I added the device detach method > > for the hostb driver to sys/i386/pci/pci_bus.c: > > > > --- sys/i386/pci/pci_bus.c.ORI 2007-08-17 08:12:33.000000000 +0200 > > +++ sys/i386/pci/pci_bus.c 2008-12-23 13:34:35.000000000 +0100 > > @@ -619,10 +619,13 @@ > > return 0; > > } > > > > +static int pci_hostb_detach(device_t dev) { return 0; } > > + > > static device_method_t pci_hostb_methods[] = { > > /* Device interface */ > > DEVMETHOD(device_probe, pci_hostb_probe), > > DEVMETHOD(device_attach, pci_hostb_attach), > > + DEVMETHOD(device_detach, pci_hostb_detach), > > DEVMETHOD(device_shutdown, bus_generic_shutdown), > > DEVMETHOD(device_suspend, bus_generic_suspend), > > DEVMETHOD(device_resume, bus_generic_resume), > > > > Now, when kldload'ing my driver, it can walk through all devices > > and detach hostb using device_detach(). > > In the case of hostb, this is wrong however. You want to attach as a child of As I learned in the meanwhile, yes. But it was quite interesting to learn how things work when you have never been into FreeBSD driver hacking before ;-). > hostb as other devices (e.g. agp(4)) need to attach to host-pci bridges as > well. Would this work in 6.x as well? You wrote in another mail that in 7.0 agp attaches to hostb. This makes me think that in 6.x things are handled differently. If not, I will stick to my detaching while I am on 6.x (don't need agp on my 440BXs) and do it right when I have migrated to 7.x... Thanks, -Andre From das at FreeBSD.ORG Wed Jan 21 23:15:24 2009 From: das at FreeBSD.ORG (David Schultz) Date: Wed Jan 21 23:15:32 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: References: <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> <20090122045637.GA61058@zim.MIT.EDU> Message-ID: <20090122071703.GA61697@zim.MIT.EDU> On Thu, Jan 22, 2009, Daniel Eischen wrote: > On Wed, 21 Jan 2009, David Schultz wrote: > > >I think there *is* a real bug here, but there's two distinct ways > >to fix it. When a threaded process forks, malloc acquires all its > >locks so that its state is consistent after a fork. However, the > >post-fork hook that's supposed to release these locks fails to do > >so in the child because the child process isn't threaded, and > >malloc_mutex_unlock() is optimized to be a no-op in > >single-threaded processes. If the child *stays* single-threaded, > >malloc() works by accident even with all the locks held because > >malloc_mutex_lock() is also a no-op in single-threaded processes. > >But if the child goes multi-threaded, then things break. > > > >Solution 1 is to actually unlock the locks in the child process, > >which is what Brian is proposing. > > > >Solution 2 is to take the position that all of this pre- and > >post-fork bloat in the fork() path is gratuitous and should be > >removed. The rationale here is that if you fork with multiple > >running threads, there's scads of ways in which the child's heap > >could be inconsistent; fork hooks would be needed not just in > >malloc(), but in stdio, third party libraries, etc. Why should > >malloc() be special? It's the programmer's job to quiesce all the > >threads before calling fork(), and if the programmer doesn't do > >this, then POSIX only guarantees that async-signal-safe functions > >will work. > > > >Note that Solution 2 also fixes Brian's problem if he quiesces all > >of his worker threads before forking (as he should!) With the > >pre-fork hook removed, all the locks will start out free in the > >child. So that's what I vote for... > > The problem is that our own libraries (libthr included) > need to malloc() for themselves, even after a fork() in > the child. After a fork(), the malloc locks should be > reinitialized in the child if it was threaded, so that > our implementation actually works for all the async > signal calls, fork(), exec(), etc. I forget the exact > failure modes for very common cases, but if you remove > the re-initialization of the malloc locks, I'm sure > you will have problems. If you can't implement functions that are required to be async-signal-safe like fork() and exec() without malloc(), then for now I guess we should go for something along the lines of what Brian is proposing. If the app programmer has taken special pains to ensure that all other threads are stopped when a fork happens, the fork() call shouldn't return in the child with all the malloc locks bogusly held. From das at FreeBSD.ORG Wed Jan 21 23:42:58 2009 From: das at FreeBSD.ORG (David Schultz) Date: Wed Jan 21 23:43:05 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: <20090122071703.GA61697@zim.MIT.EDU> References: <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> <20090122045637.GA61058@zim.MIT.EDU> <20090122071703.GA61697@zim.MIT.EDU> Message-ID: <20090122074437.GA61965@zim.MIT.EDU> On Thu, Jan 22, 2009, David Schultz wrote: > If you can't implement functions that are required to be > async-signal-safe like fork() and exec() without malloc(), then > for now I guess we should go for something along the lines of what > Brian is proposing. If the app programmer has taken special pains > to ensure that all other threads are stopped when a fork happens, > the fork() call shouldn't return in the child with all the malloc > locks bogusly held. Note that even with Brian's patch, the memory associated with the all the parent's threads' stacks is leaked, and libthr can't be expected to be in a particularly happy state after all of its threads disappear. It just happens to (sort of) work for now. In any case, it's clearly a bug that libthr's fork handler calls _malloc_postfork() in the child even when _malloc_postfork() doesn't work properly in the (now single-threaded) child. Which way to fix it is up to you guys... From xistence at 0x58.com Thu Jan 22 00:45:56 2009 From: xistence at 0x58.com (Bert JW Regeer) Date: Thu Jan 22 00:46:03 2009 Subject: freebsd-update's install_verify routine excessive stating Message-ID: Hackers, Recently I decided it would be time to upgrade an older laptop that was still running 6.2-RELEASE to a more recent release 7.1-RELEASE (re- install not possible, laptop has no cd-rom drive, and does not boot from a USB one). Everything went well, including the kernel update. It was not until after I rebooted and ran: ./freebsd-update.sh -f freebsd-update.conf install That I started noticing something rather weird. It had been running for a good 30 minutes before I started wondering what was going on. top gave me nothing of value, other than that all of the time was spent running sh, and that it was spending all of its time in system, not user where I would have expected it. Thinking went wrong I stopped the process and started it again. After a ktrace and kdump I found the culprit in install_verify in the freebsd-update utility, it would read one line, and then run stat on one of the many files that was listed in /usr/upgrade/files/. install_verify () { # Generate a list of hashes cat $@ | cut -f 2,7 -d '|' | grep -E '^f' | cut -f 2 -d '|' | sort -u > filelist # Make sure all the hashes exist while read HASH; do if ! [ -f files/${HASH}.gz ]; then echo -n "Update files missing -- " echo "this should never happen." echo "Re-run '$0 fetch'." return 1 fi done < filelist # Clean up rm filelist } running find /usr/upgrade/files/ | wc -l showed over 64000 files. So what was happening here is that freebsd-update.sh is doing due diligence in checking that all the files exist, however it uses the built in test utility to do so. While in normal situations this may not be that big of a deal since the changeset is likely to be small, running stat on 64000 individual files in a loop is rather slow. In my case I have just removed the offending code and hoped all went well, however this is off course not an acceptable solution. I have not yet come up with an acceptable way to fix the offending code, hence my post to hackers. I am also not sure as to how I would file a pr bug report for this situation, any guidance would be greatly appreciated. This email has become much longer than I had originally intended. I just wanted to get this out to see what you all had to say about this. Cheers, Bert JW Regeer From dimitry at andric.com Thu Jan 22 02:20:26 2009 From: dimitry at andric.com (Dimitry Andric) Date: Thu Jan 22 02:20:43 2009 Subject: Kernel Module - GCC Requires memmove In-Reply-To: References: <4977B357.2080500@andric.com> <20090121185245.00739316@kan.dnsalias.net> Message-ID: <4978486B.3070504@andric.com> On 2009-01-22 02:14, Nate Eldredge wrote: > I vaguely recall Linux having a policy that compiling the kernel without > optimization was not supported, possibly because of situations like this. No, Linux has its own implementations of mem{cmp,cpy,move,set}, both in fallback C versions, and optimized versions for several arches. Compiling Linux without optimization will fail at the linking stage, due to extern inline functions in header files, without implementation in separate .c files. From olli at lurza.secnetix.de Thu Jan 22 04:17:46 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Jan 22 04:17:58 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: Message-ID: <200901221217.n0MCHfY3086653@lurza.secnetix.de> Hi, I've Cc'ed Colin Percival, the author of freebsd-update. Bert JW Regeer wrote: > Recently I decided it would be time to upgrade an older laptop that > was still running 6.2-RELEASE to a more recent release 7.1-RELEASE > [...] > Everything went well, including the kernel update. It was not until > after I rebooted and ran: > > ./freebsd-update.sh -f freebsd-update.conf install > > That I started noticing something rather weird. It had been running > for a good 30 minutes before I started wondering what was going on. > top gave me nothing of value, other than that all of the time was > spent running sh, and that it was spending all of its time in system, > not user where I would have expected it. Thinking went wrong I stopped > the process and started it again. > > After a ktrace and kdump I found the culprit in install_verify in the > freebsd-update utility, it would read one line, and then run stat on > one of the many files that was listed in /usr/upgrade/files/. > > install_verify () { > # Generate a list of hashes > cat $@ | That should be "$@" with double quotes. $@ doesn't make sense without the quotes. Apart from that, it's a typical case of "useless use of cat". > cut -f 2,7 -d '|' | > grep -E '^f' | > cut -f 2 -d '|' | > sort -u > filelist It's unclear why there are two "cut" commands. The 7th field isn't used at all. Also, the -E option to grep is superfluous here. Finally, using awk might be more efficient than cut + grep. So I would suggest to replace the whole pipe with this: awk -F "|" '$2 ~ /^f/ {print $2}' "$@" | sort -u > filelist > # Make sure all the hashes exist > while read HASH; do > if ! [ -f files/${HASH}.gz ]; then > echo -n "Update files missing -- " > echo "this should never happen." > echo "Re-run '$0 fetch'." > return 1 > fi > done < filelist > > # Clean up > rm filelist > } > > running find /usr/upgrade/files/ | wc -l showed over 64000 files. So > what was happening here is that freebsd-update.sh is doing due > diligence in checking that all the files exist, however it uses the > built in test utility to do so. While in normal situations this may > not be that big of a deal since the changeset is likely to be small, > running stat on 64000 individual files in a loop is rather slow. > > In my case I have just removed the offending code and hoped all went > well, however this is off course not an acceptable solution. I have > not yet come up with an acceptable way to fix the offending code, > hence my post to hackers. I am also not sure as to how I would file a > pr bug report for this situation, any guidance would be greatly > appreciated. You are right, that loop doesn't scale very well. I'm not surprised it is horribly slow with 64000 files on an old laptop that probably has a disk that isn't too fast. It would be much better to generate two lists: - The list of hashes, as already done ("filelist") - A list of gzipped files present, stripped to the hash: (cd files; echo *.gz) | tr ' ' '\n' | sed 's/\.gz$//' > filespresent Note we use "echo" instead of "ls", in order to avoid the kern.argmax limit. 64000 files would certainly exceed that limit. Also note that the output is already sorted because the shell sorts wildcard expansions. Now that we have those two files, we can use comm(1) to find out whether there are any hashes in filelist that are not in filespresent: if [ -n "$(comm -23 filelist filespresent)" ]; then echo -n "Update files missing -- " ... fi That solution scales much better because no shell loop is required at all. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" From christoph.mallon at gmx.de Thu Jan 22 04:33:49 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Thu Jan 22 04:33:57 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <200901221217.n0MCHfY3086653@lurza.secnetix.de> References: <200901221217.n0MCHfY3086653@lurza.secnetix.de> Message-ID: <497867A9.7000801@gmx.de> Oliver Fromme schrieb: > > cut -f 2,7 -d '|' | > > grep -E '^f' | > > cut -f 2 -d '|' | > > sort -u > filelist > > It's unclear why there are two "cut" commands. The 7th > field isn't used at all. Also, the -E option to grep After the first cut the seventh field becomes the second: echo 'a|b|c|d|e|f|g' | cut -f 2,7 -d '|' So the second cut selects the original seventh field and fills it into the file "filelist". > > So I would suggest to replace the whole pipe with this: > > awk -F "|" '$2 ~ /^f/ {print $2}' "$@" | > sort -u > filelist It should print $7, see above. Christoph From avg at icyb.net.ua Thu Jan 22 04:44:49 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jan 22 04:44:58 2009 Subject: device driver: cdesw questions? In-Reply-To: References: <49770513.8090203@icyb.net.ua> Message-ID: <49786A3C.9070502@icyb.net.ua> on 21/01/2009 16:05 Robert Watson said the following: > > On Wed, 21 Jan 2009, Andriy Gapon wrote: >> I also would like the driver to provide a select capability quite >> similar to that of network (e.g. TCP) sockets using d_poll. I.e. a >> userland program should be able to query when it can write data to the >> device without blocking and when it can read data without blocking, plus >> when an error occurred in the device/driver, so there is no point in >> further waiting. >> At this moment I am thoroughly confused by meaning of various event >> masks described in poll(2). E.g. what is normal priority, non-zero >> priority and high priority. >> Which flags should I care about if all data is the same priority for me? >> Which flag(s) should I set when I'd like to communicate an error >> condition (e.g. similar to TCP connection reset)? > > I find that the description of the polling flags is at best confusing in > both man pages and specifications. The best bet is to look at the > existing TCP semantics, which are basically defined in sopoll_generic(): [snip] > A few observations: > > - Neither POLLHUP nor POLLERR appear to be implemented for sockets (all > protocols use sopoll_generic in practice). This is surprising given the > wording in the poll(2) man page. > > - Make sure to distinguish POLLIN and POLLINIGNEOF -- the difference > between > soreadable() and the test in POLLIGNEOF is that POLLIN also considers > SBS_CANTRCVMORE (i.e., at least half-close in the receive direction) but > POLLIGNEOF doesn't. > > I think Kostik's pointer to the pipe_poll() code is a good one, but if > you're looking to emulate TCP semantics a bit more exactly, these > differences should be taken into account. Robert, Kostik, thank you for the great pointers. >From previous network programming I recall that if an error occurs on a TCP socket then select(2) marks the socket as available for reading (and probably for writing too), then a subsequent operation gets actual error code. I think that maybe this was the only way to do it in select-only days. I am a little bit confused about exceptfds parameter of select, the manual page says "The only exceptional condition detectable is out-of-band data received on a socket" and I am not sure what that would be for TCP and how that could be used in practice. Anyway, I'd probably stick to the same strategy - mark the device as available for reading and writing if an error occurs and then return error code in actual read/write. -- Andriy Gapon From avg at icyb.net.ua Thu Jan 22 05:29:16 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jan 22 05:29:28 2009 Subject: usb keyboard vs btx: an SMI theory In-Reply-To: <200901211407.44021.jhb@freebsd.org> References: <4947AA3C.4040005@icyb.net.ua> <200901211407.44021.jhb@freebsd.org> Message-ID: <497874A8.3070205@icyb.net.ua> on 21/01/2009 21:07 John Baldwin said the following: > On Tuesday 16 December 2008 8:16:44 am Andriy Gapon wrote: >> Again, I am very fuzzy about the exact details, but I think that this is >> something that could be happening and I think that SMI is of primary >> interest here. I also think that this might explain to a certain degree >> the difference in behavior between "older" btx and "newer" btx. > > One thing to keep in mind is that when an SMI# is delivered, the processor > enters System Management Mode (SMM). In SMM, the CPU actually uses a > different set of memory for its RAM. It also runs in a sort of weird 32-bit > real mode. It is not going to call the stock IRQ 1 handler. Instead, it > passes data back to "normal" mode by changing the values restored into > registers when exiting SMM. Typically doing an I/O port access to the ports > backing the keyboard (0x60 and 0x64) cause an SMI# and the SMM handler > emulates the inb/outb request by storing the resulting data for an inb in > the %ax register the "normal" mode sees once it resumes execution after > the 'inb' instruction. > I've been thinking about that and also decided that my SMI theory is rubbish. On the other hand, I still suspect that there could be some race in protected<->real transition, but from looking at the code I can not imagine how it could happen. -- Andriy Gapon From olli at lurza.secnetix.de Thu Jan 22 06:19:57 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Jan 22 06:20:04 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <497867A9.7000801@gmx.de> Message-ID: <200901221419.n0MEJrsK092478@lurza.secnetix.de> Christoph Mallon wrote: > Oliver Fromme schrieb: > > > cut -f 2,7 -d '|' | > > > grep -E '^f' | > > > cut -f 2 -d '|' | > > > sort -u > filelist > > > > It's unclear why there are two "cut" commands. The 7th > > field isn't used at all. Also, the -E option to grep > > After the first cut the seventh field becomes the second: Ah yes, you're right, of course. My caffeine level was insufficient, I guess. :-) > > So I would suggest to replace the whole pipe with this: > > > > awk -F "|" '$2 ~ /^f/ {print $2}' "$@" | > > sort -u > filelist > > It should print $7, see above. Right. Thanks for pointing it out. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Whatever happened to the days when hacking started at the cerebral cortex, and not at the keyboard?" -- Sid on userfriendly.org by Illiad, 2007-06-20 From jhb at freebsd.org Thu Jan 22 07:42:01 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jan 22 07:42:12 2009 Subject: How to "detach" a foreign driver from a device so my driver can attach? In-Reply-To: <20090122071515.GA97409@curry.mchp.siemens.de> References: <20081216230430.GA24352@curry.mchp.siemens.de> <200901211408.37883.jhb@freebsd.org> <20090122071515.GA97409@curry.mchp.siemens.de> Message-ID: <200901221018.05726.jhb@freebsd.org> On Thursday 22 January 2009 2:15:15 am Andre Albsmeier wrote: > On Wed, 21-Jan-2009 at 14:08:37 -0500, John Baldwin wrote: > > hostb as other devices (e.g. agp(4)) need to attach to host-pci bridges as > > well. > > Would this work in 6.x as well? You wrote in another mail that > in 7.0 agp attaches to hostb. This makes me think that in 6.x > things are handled differently. Yes, 6.x does not work this way. -- John Baldwin From des at des.no Thu Jan 22 08:35:47 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Jan 22 08:35:55 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: (Bert JW Regeer's message of "Thu, 22 Jan 2009 01:45:47 -0700") References: Message-ID: <86vds7nvrx.fsf@ds4.des.no> Bert JW Regeer writes: > [problems with freebsd-update] You should probably send a copy of this to cperciva@... DES -- Dag-Erling Sm?rgrav - des@des.no From ota at j.email.ne.jp Thu Jan 22 17:57:30 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Thu Jan 22 17:58:01 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <200901221217.n0MCHfY3086653@lurza.secnetix.de> References: <200901221217.n0MCHfY3086653@lurza.secnetix.de> Message-ID: <20090122203819.585fb35f.ota@j.email.ne.jp> Hi. It's interesting. On Thu, 22 Jan 2009 13:17:41 +0100 (CET) Oliver Fromme wrote: > Hi, > > > So I would suggest to replace the whole pipe with this: > > awk -F "|" '$2 ~ /^f/ {print $2}' "$@" | > sort -u > filelist > > It would be much better to generate two lists: > - The list of hashes, as already done ("filelist") > - A list of gzipped files present, stripped to the hash: > > (cd files; echo *.gz) | > tr ' ' '\n' | > sed 's/\.gz$//' > filespresent > > Note we use "echo" instead of "ls", in order to avoid the > kern.argmax limit. 64000 files would certainly exceed that > limit. Also note that the output is already sorted because > the shell sorts wildcard expansions. > > Now that we have those two files, we can use comm(1) to > find out whether there are any hashes in filelist that are > not in filespresent: > > if [ -n "$(comm -23 filelist filespresent)" ]; then > echo -n "Update files missing -- " > ... > fi > > That solution scales much better because no shell loop is > required at all. This will probably be the fastest. awk -F "|" ' $2 ~ /^f/{required[$7]=$7; count++} END{FS="[/.]"; while("find files -name *.gz" | getline>0) if($2 in required) if(--count<=0) exit(0); exit(count)}' "$@" It verifies entries using hashtable instead of sort. Therefore, it is O(n+m) instead of O(n*log(n))+O(m*log(m)) in theory. I am not well aware how good awk's associate array is, though. Regards, Hiro From olli at lurza.secnetix.de Fri Jan 23 03:09:09 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Jan 23 03:09:15 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <20090122203819.585fb35f.ota@j.email.ne.jp> Message-ID: <200901231109.n0NB933k069163@lurza.secnetix.de> Yoshihiro Ota wrote: > Oliver Fromme wrote: > > It would be much better to generate two lists: > > - The list of hashes, as already done ("filelist") > > - A list of gzipped files present, stripped to the hash: > > > > (cd files; echo *.gz) | > > tr ' ' '\n' | > > sed 's/\.gz$//' > filespresent > > > > Note we use "echo" instead of "ls", in order to avoid the > > kern.argmax limit. 64000 files would certainly exceed that > > limit. Also note that the output is already sorted because > > the shell sorts wildcard expansions. > > > > Now that we have those two files, we can use comm(1) to > > find out whether there are any hashes in filelist that are > > not in filespresent: > > > > if [ -n "$(comm -23 filelist filespresent)" ]; then > > echo -n "Update files missing -- " > > ... > > fi > > > > That solution scales much better because no shell loop is > > required at all. > > This will probably be the fastest. Are you sure? I'm not. Only a benchmark can answer that. See below. > awk -F "|" ' > $2 ~ /^f/{required[$7]=$7; count++} > END{FS="[/.]"; > while("find files -name *.gz" | getline>0) > if($2 in required) > if(--count<=0) > exit(0); > exit(count)}' "$@" I think this awk solution is more difficult to read and understand, which means that it is also more prone to introduce errors. In fact, there are several problems already: First, you didn't quote the *.gz wildcard, so it will fail if there happens to be a file "*.gz" in the current directory. Second, the script makes assumptions about the format of the hash strings, e.g. that they don't contain dots. (Currently they only contain hex digits, AFAICT, but what if the format changes in the future.) Third, exit(count) is a bad idea, because exit codes are truncated to 8 bits. If 256 files happen to be missing, the script will seem to exit successfully. All these flaws could be fixed, of course, but it will introduce more complexity. The shell code using sort(1) and comm(1) doesn't have those flaws and appears more robust. > It verifies entries using hashtable instead of sort. > Therefore, it is O(n+m) instead of O(n*log(n))+O(m*log(m)) in theory. > I am not well aware how good awk's associate array is, though. It is pretty simple. It's a hash list that starts with 50 buckets. The number of buckets is doubled (and all entries re-hashed!) when the average number of elements per bucket exceeds 2. The hash function is very simple, it's just "hash = hash * 31 + c" for every character c in the string, the result is modulo the current number of buckets. Note that freebsd-update uses SHA256 hashes which are fairly long (64 characters). BTW, you can easily make benchmarks. The following command will create 64000 files of the format "%64x.gz". Be sure to have enough free inodes on your file system ("df -i"). jot -rw "%08x" 64000 0 2000000000 | sed 's/.*/&&&&&&&&.gz/' | xargs touch This took 2 minutes on my notebook (3 years old). I also noticed that the first 47000 inodes were created very quickly (about 5 seconds), but then the speed dropped down suddenly to about 150 inodes per second for the rest of the two minutes. CPU was 100% system according to top. Removing the files is equally slow. So there seems to be a limit of about 47000 inodes per directory -- any more than that and it gets horribly inefficient. Therefore it would probably be a good idea to change freebsd-update to create subdirectories and distribute the files among them. For example, make 16 subdirectories [0-9a-f] and put the files into them according to the first digit of the hash. This will probably boost performance noticeably. Sorting those 64000 files is really *not* an issue. The difference between "ls" and "ls -f" is only 0.2 seconds on my notebook. When using "ls -f | sort", sort(1) uses only 0.12 seconds of CPU time. This is negligible. Next I made a simple test with awk within that directory: awk 'BEGIN{while("find . -name \\*.gz" | getline>0)required[$1]=$1}' That script (which does only half of the required work) takes 4 seconds, reproducible. So I didn't bother to write and test the full awk solution. Bottom line: The awk solution is less robust, less readable, and much slower. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The most important decision in [programming] language design concerns what is to be left out." -- Niklaus Wirth From mehulc87 at gmail.com Fri Jan 23 07:55:34 2009 From: mehulc87 at gmail.com (Mehul Chadha) Date: Fri Jan 23 07:55:43 2009 Subject: doubts regarding System Initialization working (SYSINIT) Message-ID: <251d650c0901230755n769de861u1fe2e76dd28bbde8@mail.gmail.com> Hello all, I have been browsing through the FreeBSD kernel's source code trying to understand its working . In the mi_startup() in /sys/kern/init_main.c all the SYSINIT objects are sorted using bubble sort and then they are executed in order. My doubt is that we have declared the pointer to the struct sysinit as const pointer to a const in the macro definition of SYSINIT ie when the macro SYSINIT(kmem, SI_SUB_KMEM, SI_ORDER_FIRST, kmeminit, NULL) is expanded completely we get the following static struct sysinit kmem_sys_init = { SI_SUB_KMEM, SI_ORDER_FIRST, (sysinit_cfunc_t)(sysinit_ nfunc_t)kmeminit, ((void *)(((void *)0))) }; static void const * const __set_sysinit_set_sym_kmem_sys_init __attribute__((__section__("set_" "sysinit_set"))) __attribute__((__used__)) = &kmem_sys_init; Here we see that the pointer is of type const and to a const but when we sort and swap using *sipp=*xipp; We are trying to change the address of const pointer to a new address in which case it should segfault but it works fine. Why does it not segfault it seems I have not understood the concept behind using const *const... I will be very thankful if you can help me with it. Regards, Mehul From dougb at FreeBSD.org Fri Jan 23 11:34:42 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jan 23 11:34:49 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <200901231109.n0NB933k069163@lurza.secnetix.de> References: <200901231109.n0NB933k069163@lurza.secnetix.de> Message-ID: <497A1BEE.7070709@FreeBSD.org> Oliver Fromme wrote: > Yoshihiro Ota wrote: > > Oliver Fromme wrote: > > > It would be much better to generate two lists: > > > - The list of hashes, as already done ("filelist") > > > - A list of gzipped files present, stripped to the hash: > > > > > > (cd files; echo *.gz) | > > > tr ' ' '\n' | > > > sed 's/\.gz$//' > filespresent > > > > > > Note we use "echo" instead of "ls", in order to avoid the > > > kern.argmax limit. 64000 files would certainly exceed that > > > limit. Also note that the output is already sorted because > > > the shell sorts wildcard expansions. > > > > > > Now that we have those two files, we can use comm(1) to > > > find out whether there are any hashes in filelist that are > > > not in filespresent: > > > > > > if [ -n "$(comm -23 filelist filespresent)" ]; then > > > echo -n "Update files missing -- " > > > ... > > > fi > > > > > > That solution scales much better because no shell loop is > > > required at all. > > > > This will probably be the fastest. > > Are you sure? I'm not. I'd put money on this being faster for a lot of reasons. test is a builtin in our /bin/sh, so there is no exec involved for 'test -f', but going out to disk for 64k files on an individual basis should definitely be slower than getting the file list in one shot. There's no doubt that the current routine is not efficient. The cat should be eliminated, the following is equivalent: cut -f 2,7 -d '|' $@ | (quoting the $@ won't make a difference here). I haven't seen the files we're talking about, but I can't help thinking that cut | grep | cut could be streamlined. > Only a benchmark can answer that. Agreed, when making changes like this you should always benchmark them. I did a lot of that when working on portmaster 2.0 which is why I have some familiarity with this issue. > > awk -F "|" ' > > $2 ~ /^f/{required[$7]=$7; count++} > > END{FS="[/.]"; > > while("find files -name *.gz" | getline>0) > > if($2 in required) > > if(--count<=0) > > exit(0); > > exit(count)}' "$@" > > I think this awk solution is more difficult to read and > understand, which means that it is also more prone to > introduce errors. I agree, but I have only passing familiarity with awk, so to someone who knows awk this might look like "hello world." :) Doug -- This .signature sanitized for your protection From olli at lurza.secnetix.de Fri Jan 23 12:06:29 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Jan 23 12:06:37 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <497A1BEE.7070709@FreeBSD.org> Message-ID: <200901232006.n0NK6M1B092584@lurza.secnetix.de> Doug Barton wrote: > Oliver Fromme wrote: > > Yoshihiro Ota wrote: > > > Oliver Fromme wrote: > > > > It would be much better to generate two lists: > > > > - The list of hashes, as already done ("filelist") > > > > - A list of gzipped files present, stripped to the hash: > > > > > > > > (cd files; echo *.gz) | > > > > tr ' ' '\n' | > > > > sed 's/\.gz$//' > filespresent > > > > > > > > Note we use "echo" instead of "ls", in order to avoid the > > > > kern.argmax limit. 64000 files would certainly exceed that > > > > limit. Also note that the output is already sorted because > > > > the shell sorts wildcard expansions. > > > > > > > > Now that we have those two files, we can use comm(1) to > > > > find out whether there are any hashes in filelist that are > > > > not in filespresent: > > > > > > > > if [ -n "$(comm -23 filelist filespresent)" ]; then > > > > echo -n "Update files missing -- " > > > > ... > > > > fi > > > > > > > > That solution scales much better because no shell loop is > > > > required at all. > > > > > > This will probably be the fastest. > > > > Are you sure? I'm not. > > I'd put money on this being faster for a lot of reasons. I assume, with "this" you mean my solution to the slow shell loop problem (not quoted above), not Yoshihiro Ota's awk proposal? > test is a > builtin in our /bin/sh, so there is no exec involved for 'test -f', > but going out to disk for 64k files on an individual basis should > definitely be slower than getting the file list in one shot. Correct. > There's no doubt that the current routine is not efficient. The cat > should be eliminated, the following is equivalent: > > cut -f 2,7 -d '|' $@ | > > (quoting the $@ won't make a difference here). Right, technically it doesn't make a difference because the file names are fixed and don't contain spaces. *But* then it is better to use $*. Every time I see $@ without double quotes I wonder if the author forgot to add them. It always smells like a bug. Using $@ without quotes is pointless because then it behaves exactly the same as $*. > I haven't seen the files we're talking about, but I can't help > thinking that cut | grep | cut could be streamlined. Yes, it can. I already explained pretty much all of that (useless cat etc.) in my first post in this thread. Did you read it? My suggestion (after a small correction by Christoph Mallon) was to replace the cat|cut|grep|cut sequence with this single awk command: awk -F "|" '$2 ~ /^f/ {print $7}' "$@" For those not fluent with awk, it means this: - Treat "|" as field separator. - Search for lines where the second field matches ^f (i.e. it starts with an "f"). - Print the 7th field of those matching lines. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd In my experience the term "transparent proxy" is an oxymoron (like jumbo shrimp). "Transparent" proxies seem to vary from the distortions of a funhouse mirror to barely translucent. I really, really dislike them when trying to figure out the corrective lenses needed with each of them. -- R. Kevin Oberman, Network Engineer From dougb at FreeBSD.org Fri Jan 23 12:36:56 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jan 23 12:37:02 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <200901232006.n0NK6M1B092584@lurza.secnetix.de> References: <200901232006.n0NK6M1B092584@lurza.secnetix.de> Message-ID: <497A2A83.9010606@FreeBSD.org> Oliver Fromme wrote: > I assume, with "this" you mean my solution to the slow > shell loop problem (not quoted above), not Yoshihiro Ota's > awk proposal? I meant the solution using comm, sorry. (I forgot to mention that I would probably use cmp here, but that's a personal preference.) > Yes, it can. I already explained pretty much all of that > (useless cat etc.) in my first post in this thread. Did > you read it? Yes, I was attempting to agree with you. :) > My suggestion (after a small correction by > Christoph Mallon) was to replace the cat|cut|grep|cut > sequence with this single awk command: > > awk -F "|" '$2 ~ /^f/ {print $7}' "$@" > > For those not fluent with awk, it means this: > - Treat "|" as field separator. > - Search for lines where the second field matches ^f > (i.e. it starts with an "f"). > - Print the 7th field of those matching lines. Like I said, I haven't seen the files, but this looks good at first blush. That said, the generation of the hash list file is just a drop in the bucket. The real inefficiency in this function is the test -f for 64k files, one at a time. Doug -- This .signature sanitized for your protection From olli at lurza.secnetix.de Fri Jan 23 14:22:15 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Jan 23 14:22:23 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <497A2A83.9010606@FreeBSD.org> Message-ID: <200901232222.n0NMMAcS097663@lurza.secnetix.de> Doug Barton wrote: > Oliver Fromme wrote: > > I assume, with "this" you mean my solution to the slow > > shell loop problem (not quoted above), not Yoshihiro Ota's > > awk proposal? > > I meant the solution using comm, sorry. (I forgot to mention that I > would probably use cmp here, but that's a personal preference.) I see. No problem. However, I think cmp wouldn't work here, because cmp only detects whether there is a difference between two files. In this case we need to know if one file is a subset of the other: For every hash there must be a .gz file, but it doesn't hurt if there are more files. So the list of hashes can be a subset of the list of .gz files, they don't have to be equal. While I were at it, I skimmed through the cmp source and found a bug (or inefficiency): When the -s option is specified (i.e. silent, exit code only), it would be sufficient to terminate when the first difference is encountered. But it always compares the whole files. I'll try to make a patch to improve this. > > Yes, it can. I already explained pretty much all of that > > (useless cat etc.) in my first post in this thread. Did > > you read it? > > Yes, I was attempting to agree with you. :) OK, sorry. I misunderstood. :) > > My suggestion (after a small correction by > > Christoph Mallon) was to replace the cat|cut|grep|cut > > sequence with this single awk command: > > > > awk -F "|" '$2 ~ /^f/ {print $7}' "$@" > > > > For those not fluent with awk, it means this: > > - Treat "|" as field separator. > > - Search for lines where the second field matches ^f > > (i.e. it starts with an "f"). > > - Print the 7th field of those matching lines. > > Like I said, I haven't seen the files, but this looks good at first > blush. That said, the generation of the hash list file is just a drop > in the bucket. The real inefficiency in this function is the test -f > for 64k files, one at a time. Yes, definitely. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We will perhaps eventually be writing only small modules which are identi- fied by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." -- Donald E. Knuth, 1974 From jhb at freebsd.org Fri Jan 23 14:57:57 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Jan 23 14:58:09 2009 Subject: doubts regarding System Initialization working (SYSINIT) In-Reply-To: <251d650c0901230755n769de861u1fe2e76dd28bbde8@mail.gmail.com> References: <251d650c0901230755n769de861u1fe2e76dd28bbde8@mail.gmail.com> Message-ID: <200901231755.15548.jhb@freebsd.org> On Friday 23 January 2009 10:55:32 am Mehul Chadha wrote: > Hello all, > I have been browsing through the FreeBSD kernel's > source code trying to understand its working . > > In the mi_startup() in /sys/kern/init_main.c all the SYSINIT objects > are sorted using bubble sort and then they are executed in order. > > My doubt is that we have declared the pointer to the struct sysinit as > const pointer to a const in the macro definition of SYSINIT ie when > the macro > > SYSINIT(kmem, SI_SUB_KMEM, SI_ORDER_FIRST, kmeminit, NULL) is > expanded completely we get the following > > static struct sysinit kmem_sys_init = { SI_SUB_KMEM, SI_ORDER_FIRST, > (sysinit_cfunc_t)(sysinit_ > nfunc_t)kmeminit, ((void *)(((void *)0))) }; static void const * const > __set_sysinit_set_sym_kmem_sys_init __attribute__((__section__("set_" > "sysinit_set"))) __attribute__((__used__)) = &kmem_sys_init; > > Here we see that the pointer is of type const and to a const but when we sort > and swap using > *sipp=*xipp; > > We are trying to change the address of const pointer to a new address > in which case it should segfault but it works fine. > > Why does it not segfault it seems I have not understood the concept > behind using const *const... I will be very thankful if you can help > me with it. I'm guessing the startup code doesn't map the SYSINIT pages read only because it is not smart enough to honor that request perhaps. That is, I wouldn't be surprised if all of .rodata in the kernel was mapped as R/W instead of R/O. -- John Baldwin From sam at freebsd.org Fri Jan 23 15:21:49 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri Jan 23 15:21:57 2009 Subject: doubts regarding System Initialization working (SYSINIT) In-Reply-To: <200901231755.15548.jhb@freebsd.org> References: <251d650c0901230755n769de861u1fe2e76dd28bbde8@mail.gmail.com> <200901231755.15548.jhb@freebsd.org> Message-ID: <497A510C.3030106@freebsd.org> John Baldwin wrote: > On Friday 23 January 2009 10:55:32 am Mehul Chadha wrote: > >> Hello all, >> I have been browsing through the FreeBSD kernel's >> source code trying to understand its working . >> >> In the mi_startup() in /sys/kern/init_main.c all the SYSINIT objects >> are sorted using bubble sort and then they are executed in order. >> >> My doubt is that we have declared the pointer to the struct sysinit as >> const pointer to a const in the macro definition of SYSINIT ie when >> the macro >> >> SYSINIT(kmem, SI_SUB_KMEM, SI_ORDER_FIRST, kmeminit, NULL) is >> expanded completely we get the following >> >> static struct sysinit kmem_sys_init = { SI_SUB_KMEM, SI_ORDER_FIRST, >> (sysinit_cfunc_t)(sysinit_ >> nfunc_t)kmeminit, ((void *)(((void *)0))) }; static void const * const >> __set_sysinit_set_sym_kmem_sys_init __attribute__((__section__("set_" >> "sysinit_set"))) __attribute__((__used__)) = &kmem_sys_init; >> >> Here we see that the pointer is of type const and to a const but when we >> > sort > >> and swap using >> *sipp=*xipp; >> >> We are trying to change the address of const pointer to a new address >> in which case it should segfault but it works fine. >> >> Why does it not segfault it seems I have not understood the concept >> behind using const *const... I will be very thankful if you can help >> me with it. >> > > I'm guessing the startup code doesn't map the SYSINIT pages read only because > it is not smart enough to honor that request perhaps. That is, I wouldn't be > surprised if all of .rodata in the kernel was mapped as R/W instead of R/O. > > I think I have an ancient patch from someone to fix the code to not do this; let me dig for it. Sam From ota at j.email.ne.jp Fri Jan 23 19:09:39 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Fri Jan 23 19:09:47 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <200901231109.n0NB933k069163@lurza.secnetix.de> References: <20090122203819.585fb35f.ota@j.email.ne.jp> <200901231109.n0NB933k069163@lurza.secnetix.de> Message-ID: <20090123220840.2e1b25bc.ota@j.email.ne.jp> Oliver, You are making a good point but connecting two different subjects. The algorithm with awk is still the fastest in theory. It uses a hash table which runs at O(c) for each comparison ASSUMING you have a good hash function that yields such result. The total number of comparison is O(n) or O(C1 * n) where C1 is some constant number based on the hash function performance. On the other hand, comparison sorts are in O(n * log(n)) comparison. The 2nd comparison of two files are at O(n). So, total comparison is still O(n * log(n)) or O(C2 * n * log(n)) where C2 is some constant based on the algorithm and implementation. That is in theory. In reality or practice, it may not be true because you could have poor C1 such that the comparison solution becomes better or because n is small enough so that it doesn't matter which solution to take. In fact, awk implementation was poor and resulted large C1 as well as slower than sort(1). Experiment is yet important so that you can determine the best algorithm in your TEST environment. This is where you are making a point. If you have control over these conditions, you can not to choose the theoretically best algorithm. I agree and had indeed expected your outcome as awk is actually known to inefficiency in its implementations. In that regard, in the practical point of view, the original implementation by cperciva@ was good enough such that searching for faster algorithms was not necessary for all people except Bert. At the end, it is up to the implementer to pick up the solution. Regards, Hiro On Fri, 23 Jan 2009 12:09:03 +0100 (CET) Oliver Fromme wrote: > > Yoshihiro Ota wrote: > > Oliver Fromme wrote: > > > It would be much better to generate two lists: > > > - The list of hashes, as already done ("filelist") > > > - A list of gzipped files present, stripped to the hash: > > > > > > (cd files; echo *.gz) | > > > tr ' ' '\n' | > > > sed 's/\.gz$//' > filespresent > > > > > > Note we use "echo" instead of "ls", in order to avoid the > > > kern.argmax limit. 64000 files would certainly exceed that > > > limit. Also note that the output is already sorted because > > > the shell sorts wildcard expansions. > > > > > > Now that we have those two files, we can use comm(1) to > > > find out whether there are any hashes in filelist that are > > > not in filespresent: > > > > > > if [ -n "$(comm -23 filelist filespresent)" ]; then > > > echo -n "Update files missing -- " > > > ... > > > fi > > > > > > That solution scales much better because no shell loop is > > > required at all. > > > > This will probably be the fastest. > > Are you sure? I'm not. > Only a benchmark can answer that. See below. > > > awk -F "|" ' > > $2 ~ /^f/{required[$7]=$7; count++} > > END{FS="[/.]"; > > while("find files -name *.gz" | getline>0) > > if($2 in required) > > if(--count<=0) > > exit(0); > > exit(count)}' "$@" > > I think this awk solution is more difficult to read and > understand, which means that it is also more prone to > introduce errors. In fact, there are several problems > already: > > First, you didn't quote the *.gz wildcard, so it will > fail if there happens to be a file "*.gz" in the current > directory. > > Second, the script makes assumptions about the format of > the hash strings, e.g. that they don't contain dots. > (Currently they only contain hex digits, AFAICT, but what > if the format changes in the future.) > > Third, exit(count) is a bad idea, because exit codes are > truncated to 8 bits. If 256 files happen to be missing, > the script will seem to exit successfully. > > All these flaws could be fixed, of course, but it will > introduce more complexity. The shell code using sort(1) > and comm(1) doesn't have those flaws and appears more > robust. > > > It verifies entries using hashtable instead of sort. > > Therefore, it is O(n+m) instead of O(n*log(n))+O(m*log(m)) in theory. > > I am not well aware how good awk's associate array is, though. > > It is pretty simple. It's a hash list that starts with > 50 buckets. The number of buckets is doubled (and all > entries re-hashed!) when the average number of elements > per bucket exceeds 2. The hash function is very simple, > it's just "hash = hash * 31 + c" for every character c > in the string, the result is modulo the current number > of buckets. Note that freebsd-update uses SHA256 hashes > which are fairly long (64 characters). > > BTW, you can easily make benchmarks. The following command > will create 64000 files of the format "%64x.gz". Be sure > to have enough free inodes on your file system ("df -i"). > > jot -rw "%08x" 64000 0 2000000000 | sed 's/.*/&&&&&&&&.gz/' | xargs touch > > This took 2 minutes on my notebook (3 years old). I also > noticed that the first 47000 inodes were created very > quickly (about 5 seconds), but then the speed dropped down > suddenly to about 150 inodes per second for the rest of > the two minutes. CPU was 100% system according to top. > Removing the files is equally slow. > > So there seems to be a limit of about 47000 inodes per > directory -- any more than that and it gets horribly > inefficient. Therefore it would probably be a good idea > to change freebsd-update to create subdirectories and > distribute the files among them. For example, make 16 > subdirectories [0-9a-f] and put the files into them > according to the first digit of the hash. This will > probably boost performance noticeably. > > Sorting those 64000 files is really *not* an issue. The > difference between "ls" and "ls -f" is only 0.2 seconds on > my notebook. When using "ls -f | sort", sort(1) uses only > 0.12 seconds of CPU time. This is negligible. > > Next I made a simple test with awk within that directory: > > awk 'BEGIN{while("find . -name \\*.gz" | getline>0)required[$1]=$1}' > > That script (which does only half of the required work) > takes 4 seconds, reproducible. So I didn't bother to > write and test the full awk solution. > > Bottom line: The awk solution is less robust, less readable, > and much slower. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "The most important decision in [programming] language design > concerns what is to be left out." -- Niklaus Wirth From dougb at FreeBSD.org Sat Jan 24 14:33:15 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Jan 24 14:33:27 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <200901232222.n0NMMAcS097663@lurza.secnetix.de> References: <200901232222.n0NMMAcS097663@lurza.secnetix.de> Message-ID: <497B9743.6080109@FreeBSD.org> Oliver Fromme wrote: > Doug Barton wrote: > > Oliver Fromme wrote: > > > I assume, with "this" you mean my solution to the slow > > > shell loop problem (not quoted above), not Yoshihiro Ota's > > > awk proposal? > > > > I meant the solution using comm, sorry. (I forgot to mention that I > > would probably use cmp here, but that's a personal preference.) > > I see. No problem. > > However, I think cmp wouldn't work here, because cmp only > detects whether there is a difference between two files. > > In this case we need to know if one file is a subset of > the other: For every hash there must be a .gz file, but > it doesn't hurt if there are more files. So the list of > hashes can be a subset of the list of .gz files, they > don't have to be equal. Hrrmmm, that doesn't sound like a good thing to me. I would think that the hash list is pretty useless if it doesn't cover all the files. > While I were at it, I skimmed through the cmp source and > found a bug (or inefficiency): When the -s option is > specified (i.e. silent, exit code only), it would be > sufficient to terminate when the first difference is > encountered. But it always compares the whole files. > I'll try to make a patch to improve this. That would definitely be appreciated, I use cmp -s in several places in portmaster where that speed-up would make a non-trivial difference. If there is anything I can do to help please let me know. Doug -- This .signature sanitized for your protection From webmaster at kibab.com Sun Jan 25 00:59:51 2009 From: webmaster at kibab.com (Ilya Bakulin) Date: Sun Jan 25 04:28:09 2009 Subject: ACPI AE_NO_HARDWARE_RESPONSE workaround Message-ID: <1232873276.3689.2.camel@kibab-nb.kibab.com> Skipped content of type multipart/signed-------------- next part -------------- !DSPAM:497c2736967001885613896! From lvj at nietykalni.org Mon Jan 26 01:52:04 2009 From: lvj at nietykalni.org (Lukasz Jaroszewski) Date: Mon Jan 26 01:52:11 2009 Subject: write(2) to /dev/ad4 = EINVAL Message-ID: <3930e0780901260135j1428e77fmfe7392770fcd31fc@mail.gmail.com> Hi, after opening /dev/ad4 with success for O_RDWR, I am getting [EINVAL] from write(2), which according to man 2 write, means `` [EINVAL] The pointer associated with d was negative.'', as you can see below it is not true, I have tried different block sizes, with same result. How can I write one byte to /dev/adN ? 1361 ow CALL open(0x80485e3,O_RDWR,0xbfbfecc8) 1361 ow NAMI "/dev/ad4" ;/dev/ad4 is DOS FAT formatted CF Card. 1361 ow RET open 3 1361 ow CALL write(0x3,0xbfbfecb8,0x8) 1361 ow RET write -1 errno 22 Invalid argument root@~(0) uname -r 7.0-STABLE ----------- Best Regards Lukasz. From hselasky at c2i.net Mon Jan 26 02:07:22 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jan 26 02:07:30 2009 Subject: write(2) to /dev/ad4 = EINVAL In-Reply-To: <3930e0780901260135j1428e77fmfe7392770fcd31fc@mail.gmail.com> References: <3930e0780901260135j1428e77fmfe7392770fcd31fc@mail.gmail.com> Message-ID: <200901261109.43376.hselasky@c2i.net> On Monday 26 January 2009, Lukasz Jaroszewski wrote: > Hi, > after opening /dev/ad4 with success for O_RDWR, I am getting [EINVAL] > from write(2), which according to man 2 write, means > `` [EINVAL] The pointer associated with d was > negative.'', as you can see below it is not true, I have tried > different block sizes, with same result. > > How can I write one byte to /dev/adN ? Hi, You cannot write one byte to /dev/adN, I think. Harddisks are block based. Please see: diskinfo -v ad4 And especially the "sector size". When you seek and transfer data the offset and length must be a factor of the "sector size" or "block size". See also LBA, logical block address. --HPS > > > 1361 ow CALL open(0x80485e3,O_RDWR,0xbfbfecc8) > 1361 ow NAMI "/dev/ad4" > ;/dev/ad4 is DOS FAT formatted CF Card. > 1361 ow RET open 3 > > 1361 ow CALL write(0x3,0xbfbfecb8,0x8) > 1361 ow RET write -1 errno 22 Invalid argument > > root@~(0) uname -r > 7.0-STABLE > ----------- > Best Regards > Lukasz. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From lvj at nietykalni.org Mon Jan 26 02:24:50 2009 From: lvj at nietykalni.org (Lukasz Jaroszewski) Date: Mon Jan 26 02:24:56 2009 Subject: write(2) to /dev/ad4 = EINVAL In-Reply-To: <200901261109.43376.hselasky@c2i.net> References: <3930e0780901260135j1428e77fmfe7392770fcd31fc@mail.gmail.com> <200901261109.43376.hselasky@c2i.net> Message-ID: <3930e0780901260224ye4acbabx7a629ec8da195138@mail.gmail.com> 2009/1/26 Hans Petter Selasky : > On Monday 26 January 2009, Lukasz Jaroszewski wrote: >> Hi, >> after opening /dev/ad4 with success for O_RDWR, I am getting [EINVAL] >> from write(2), which according to man 2 write, means >> `` [EINVAL] The pointer associated with d was >> negative.'', as you can see below it is not true, I have tried >> different block sizes, with same result. >> >> How can I write one byte to /dev/adN ? > > Hi, > > You cannot write one byte to /dev/adN, I think. Harddisks are block based. > Please see: > > diskinfo -v ad4 > > And especially the "sector size". When you seek and transfer data the offset > and length must be a factor of the "sector size" or "block size". See also > LBA, logical block address. Yes, I have tried with bs=512 and multiplies, no luck. root@~(0) diskinfo -v ad4 ad4 512 # sectorsize 2029805568 # mediasize in bytes (1.9G) 3964464 # mediasize in sectors 3933 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. ad:CFx20CARDx200000190C # Disk ident. ------------ Best Regards Lukasz. > > --HPS > > >> >> >> 1361 ow CALL open(0x80485e3,O_RDWR,0xbfbfecc8) >> 1361 ow NAMI "/dev/ad4" >> ;/dev/ad4 is DOS FAT formatted CF Card. >> 1361 ow RET open 3 >> >> 1361 ow CALL write(0x3,0xbfbfecb8,0x8) >> 1361 ow RET write -1 errno 22 Invalid argument >> >> root@~(0) uname -r >> 7.0-STABLE >> ----------- >> Best Regards >> Lukasz. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > From hselasky at c2i.net Mon Jan 26 02:31:29 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jan 26 02:31:36 2009 Subject: write(2) to /dev/ad4 = EINVAL In-Reply-To: <3930e0780901260224ye4acbabx7a629ec8da195138@mail.gmail.com> References: <3930e0780901260135j1428e77fmfe7392770fcd31fc@mail.gmail.com> <200901261109.43376.hselasky@c2i.net> <3930e0780901260224ye4acbabx7a629ec8da195138@mail.gmail.com> Message-ID: <200901261133.51924.hselasky@c2i.net> On Monday 26 January 2009, Lukasz Jaroszewski wrote: > 2009/1/26 Hans Petter Selasky : > > On Monday 26 January 2009, Lukasz Jaroszewski wrote: > >> Hi, > >> after opening /dev/ad4 with success for O_RDWR, I am getting [EINVAL] > >> from write(2), which according to man 2 write, means > >> `` [EINVAL] The pointer associated with d was > >> negative.'', as you can see below it is not true, I have tried > >> different block sizes, with same result. > >> > >> How can I write one byte to /dev/adN ? > > > > Hi, > > > > You cannot write one byte to /dev/adN, I think. Harddisks are block > > based. Please see: > > > > diskinfo -v ad4 > > > > And especially the "sector size". When you seek and transfer data the > > offset and length must be a factor of the "sector size" or "block size". > > See also LBA, logical block address. > > Yes, I have tried with bs=512 and multiplies, no luck. > > root@~(0) diskinfo -v ad4 > ad4 > 512 # sectorsize > 2029805568 # mediasize in bytes (1.9G) > 3964464 # mediasize in sectors > 3933 # Cylinders according to firmware. > 16 # Heads according to firmware. > 63 # Sectors according to firmware. > ad:CFx20CARDx200000190C # Disk ident. > And if you add a "lseek(f, 0, SEEK_SET);" after open? --HPS From christoph.mallon at gmx.de Mon Jan 26 02:31:54 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Mon Jan 26 02:32:02 2009 Subject: write(2) to /dev/ad4 = EINVAL In-Reply-To: <3930e0780901260224ye4acbabx7a629ec8da195138@mail.gmail.com> References: <3930e0780901260135j1428e77fmfe7392770fcd31fc@mail.gmail.com> <200901261109.43376.hselasky@c2i.net> <3930e0780901260224ye4acbabx7a629ec8da195138@mail.gmail.com> Message-ID: <497D9116.1040408@gmx.de> Lukasz Jaroszewski schrieb: > 2009/1/26 Hans Petter Selasky : >> On Monday 26 January 2009, Lukasz Jaroszewski wrote: >>> Hi, >>> after opening /dev/ad4 with success for O_RDWR, I am getting [EINVAL] >>> from write(2), which according to man 2 write, means >>> `` [EINVAL] The pointer associated with d was >>> negative.'', as you can see below it is not true, I have tried >>> different block sizes, with same result. >>> >>> How can I write one byte to /dev/adN ? >> Hi, >> >> You cannot write one byte to /dev/adN, I think. Harddisks are block based. >> Please see: >> >> diskinfo -v ad4 >> >> And especially the "sector size". When you seek and transfer data the offset >> and length must be a factor of the "sector size" or "block size". See also >> LBA, logical block address. > > > Yes, I have tried with bs=512 and multiplies, no luck. > > root@~(0) diskinfo -v ad4 > ad4 > 512 # sectorsize > 2029805568 # mediasize in bytes (1.9G) > 3964464 # mediasize in sectors > 3933 # Cylinders according to firmware. > 16 # Heads according to firmware. > 63 # Sectors according to firmware. > ad:CFx20CARDx200000190C # Disk ident. It would be helpful, if you showed the actual code, instead of letting us guess what you are doing. From lvj at nietykalni.org Mon Jan 26 05:04:29 2009 From: lvj at nietykalni.org (Lukasz Jaroszewski) Date: Mon Jan 26 05:05:26 2009 Subject: write(2) to /dev/ad4 = EINVAL In-Reply-To: <497D9116.1040408@gmx.de> References: <3930e0780901260135j1428e77fmfe7392770fcd31fc@mail.gmail.com> <200901261109.43376.hselasky@c2i.net> <3930e0780901260224ye4acbabx7a629ec8da195138@mail.gmail.com> <497D9116.1040408@gmx.de> Message-ID: <3930e0780901260504m44f43958m82f2ba8902558906@mail.gmail.com> 2009/1/26 Christoph Mallon : > Lukasz Jaroszewski schrieb: >> >> 2009/1/26 Hans Petter Selasky : >>> >>> On Monday 26 January 2009, Lukasz Jaroszewski wrote: >>>> >>>> Hi, >>>> after opening /dev/ad4 with success for O_RDWR, I am getting [EINVAL] >>>> from write(2), which according to man 2 write, means >>>> `` [EINVAL] The pointer associated with d was >>>> negative.'', as you can see below it is not true, I have tried >>>> different block sizes, with same result. >>>> >>>> How can I write one byte to /dev/adN ? >>> >>> Hi, >>> >>> You cannot write one byte to /dev/adN, I think. Harddisks are block >>> based. >>> Please see: >>> >>> diskinfo -v ad4 >>> >>> And especially the "sector size". When you seek and transfer data the >>> offset >>> and length must be a factor of the "sector size" or "block size". See >>> also >>> LBA, logical block address. >> >> >> Yes, I have tried with bs=512 and multiplies, no luck. >> >> root@~(0) diskinfo -v ad4 >> ad4 >> 512 # sectorsize >> 2029805568 # mediasize in bytes (1.9G) >> 3964464 # mediasize in sectors >> 3933 # Cylinders according to firmware. >> 16 # Heads according to firmware. >> 63 # Sectors according to firmware. >> ad:CFx20CARDx200000190C # Disk ident. > > It would be helpful, if you showed the actual code, instead of letting us > guess what you are doing. Ok, I solved that, I were trying to dd with bs correctly set, tho if=./s wasn't big enough plus I had code like below, where I didn't check write for errors, just called perror, which gave me wrong errno. So to change one byte, I need to read it, change it, and write it in 512 chunks? or play with kernel and add smth like ``write_byte'' to ata? I am sorry for bothering with my silly errors. #define S 0x200 int main(int argc, char **argv){ int fd,i=0; char *s; s = malloc(S); for(i=0;i From olli at lurza.secnetix.de Mon Jan 26 05:08:36 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Jan 26 05:08:48 2009 Subject: freebsd-update's install_verify routine excessive stating In-Reply-To: <497B9743.6080109@FreeBSD.org> Message-ID: <200901261308.n0QD8WwD058156@lurza.secnetix.de> Doug Barton wrote: > Oliver Fromme wrote: > > However, I think cmp wouldn't work here, because cmp only > > detects whether there is a difference between two files. > > > > In this case we need to know if one file is a subset of > > the other: For every hash there must be a .gz file, but > > it doesn't hurt if there are more files. So the list of > > hashes can be a subset of the list of .gz files, they > > don't have to be equal. > > Hrrmmm, that doesn't sound like a good thing to me. I would think that > the hash list is pretty useless if it doesn't cover all the files. Right, that's why there should be a file for every entry in the hash list -- but not necessarily the other way around. I.e. I think freebsd-update should not abort if there are superfluous files. > > While I were at it, I skimmed through the cmp source and > > found a bug (or inefficiency): When the -s option is > > specified (i.e. silent, exit code only), it would be > > sufficient to terminate when the first difference is > > encountered. But it always compares the whole files. > > I'll try to make a patch to improve this. > > That would definitely be appreciated, I use cmp -s in several places > in portmaster where that speed-up would make a non-trivial difference. > If there is anything I can do to help please let me know. I was wrong, the -s option behaves correctly. Sorry for the confusion. I ended up in the wrong code path in the source (I was confused by the fact that the diffmsg() function never returns). Indeed, cmp(1) stops comparing the files as son as it finds the first differing byte, unless you use the -l or -x option. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From hselasky at c2i.net Mon Jan 26 09:08:03 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jan 26 09:08:09 2009 Subject: write(2) to /dev/ad4 = EINVAL In-Reply-To: <3930e0780901260504m44f43958m82f2ba8902558906@mail.gmail.com> References: <3930e0780901260135j1428e77fmfe7392770fcd31fc@mail.gmail.com> <497D9116.1040408@gmx.de> <3930e0780901260504m44f43958m82f2ba8902558906@mail.gmail.com> Message-ID: <200901261510.25074.hselasky@c2i.net> On Monday 26 January 2009, Lukasz Jaroszewski wrote: > 2009/1/26 Christoph Mallon : > > Lukasz Jaroszewski schrieb: > >> 2009/1/26 Hans Petter Selasky : > >>> On Monday 26 January 2009, Lukasz Jaroszewski wrote: Hi, > > It would be helpful, if you showed the actual code, instead of letting us > > guess what you are doing. > > Ok, I solved that, I were trying to dd with bs correctly set, tho > if=./s wasn't big enough plus I had code like below, where I didn't > check write for errors, just called perror, which gave me wrong errno. > > So to change one byte, I need to read it, change it, and write it in > 512 chunks? Yes! Maybe you should not write single bytes at a time in your design. > or play with kernel and add smth like ``write_byte'' to > ata? From my knowledge there is no standard harddisk command or SCSI command that can change only one byte at a time of the disk. It is all block based. And note that the block size can be different from 512 bytes. --HPS From green at freebsd.org Mon Jan 26 10:41:32 2009 From: green at freebsd.org (Brian Fundakowski Feldman) Date: Mon Jan 26 10:41:39 2009 Subject: threaded, forked, rethreaded processes will deadlock In-Reply-To: References: <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> <20090122045637.GA61058@zim.MIT.EDU> Message-ID: <20090126184126.GA3712@green.homeunix.org> On Thu, Jan 22, 2009 at 12:42:56AM -0500, Daniel Eischen wrote: > On Wed, 21 Jan 2009, David Schultz wrote: > >> I think there *is* a real bug here, but there's two distinct ways >> to fix it. When a threaded process forks, malloc acquires all its >> locks so that its state is consistent after a fork. However, the >> post-fork hook that's supposed to release these locks fails to do >> so in the child because the child process isn't threaded, and >> malloc_mutex_unlock() is optimized to be a no-op in >> single-threaded processes. If the child *stays* single-threaded, >> malloc() works by accident even with all the locks held because >> malloc_mutex_lock() is also a no-op in single-threaded processes. >> But if the child goes multi-threaded, then things break. >> >> Solution 1 is to actually unlock the locks in the child process, >> which is what Brian is proposing. >> >> Solution 2 is to take the position that all of this pre- and >> post-fork bloat in the fork() path is gratuitous and should be >> removed. The rationale here is that if you fork with multiple >> running threads, there's scads of ways in which the child's heap >> could be inconsistent; fork hooks would be needed not just in >> malloc(), but in stdio, third party libraries, etc. Why should >> malloc() be special? It's the programmer's job to quiesce all the >> threads before calling fork(), and if the programmer doesn't do >> this, then POSIX only guarantees that async-signal-safe functions >> will work. >> >> Note that Solution 2 also fixes Brian's problem if he quiesces all >> of his worker threads before forking (as he should!) With the >> pre-fork hook removed, all the locks will start out free in the >> child. So that's what I vote for... > > The problem is that our own libraries (libthr included) > need to malloc() for themselves, even after a fork() in > the child. After a fork(), the malloc locks should be > reinitialized in the child if it was threaded, so that > our implementation actually works for all the async > signal calls, fork(), exec(), etc. I forget the exact > failure modes for very common cases, but if you remove > the re-initialization of the malloc locks, I'm sure > you will have problems. > > Perhaps much of this malloc() stuff goes away when we > move to pthread locks that are not pointers to allocated > objects, but instead are actual objects/structures. > This needs to be done in order for mutexes/CVs/etc > to be PTHREAD_PROCESS_SHARED (placed in shared memory > and used by multiple processes). In other words, > pthread_mutex_t goes from this: > > typedef struct pthread_mutex *pthread_mutex_t; > > to something like this: > > struct __pthread_mutex { > uint32_t lock; > ... > } > typedef struct __pthread_mutex pthread_mutex_t; > > Same thing for CVs, and we probably should convert any other > locks used internally by libc/libpthread (spinlocks). > > So after a fork(), there is no need to reallocate anything, > it can just be reinitialized if necessary. In this case it's not a matter of locks needing to be again initialized -- the mutexes are fine -- they just need to be relinquished, which never occurs for the child now, but used to work fine in 7.0. What is truly broken about the current behavior module the bug I'm trying to fix? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From sos at deepcore.dk Mon Jan 26 12:55:35 2009 From: sos at deepcore.dk (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Mon Jan 26 12:55:42 2009 Subject: WANTED! board models with Marvell 61XX chips Message-ID: Hi there! I thought I finally had a motherboard using one of the Marvell SATA/ PATA chips coming in, but unfortunately the delivery has been postponed to some unspecified date, oh well.. Thats where you come into the picture as I'd like to get another one, but finding boards that uses these is a bit tricky as most vendors doesn't write such unimportant stuff on their web pages (hell it works in windows!). If you have a motherboard using one of the following Marvell chips, or know for certain a model that does, please send me a private mail with make and model as there is no need to pollute the lists (which I dont follow closely for the time being btw). The chips in question are: Marvell 6111, 6121, 6141 or 6145 It is also important that there is physical access to both the SATA and the PATA port(s) as some boards only utilize one or the other. I know of one PCI-express add-in board that uses the 6145, so if anybody knows how to get ahold of one, that would be very welcomed as well. The board in question is this: http://www.sunix.com.tw/it/en/Product_Detail.php?cate=2&class_a_id=35&sid=538 So far I've only found shops in South Africa that has it available, but none of them ships outside the country. So if you have any useful info on this topic please get in touch with me, thanks! -S?ren -- From jhb at freebsd.org Mon Jan 26 13:57:46 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jan 26 13:57:53 2009 Subject: critical floating point incompatibility In-Reply-To: <20071221201633.GM57756@deviant.kiev.zoral.com.ua> References: <20071220093950.GA79196@server.vk2pj.dyndns.org> <20071221181125.0B6F25B42@mail.bitblocks.com> <20071221201633.GM57756@deviant.kiev.zoral.com.ua> Message-ID: <200901261651.29116.jhb@freebsd.org> On Friday 21 December 2007 3:16:33 pm Kostik Belousov wrote: > On Fri, Dec 21, 2007 at 10:11:24AM -0800, Bakul Shah wrote: > > Peter Jeremy wrote: > > > On Wed, Dec 19, 2007 at 09:40:34PM -0800, Carl Shapiro wrote: > > > >The default setting of the x87 floating point control word on the i386 > > > >port is 0x127F. Among other things, this value sets the precision > > > >control to double precision. The default setting of the x87 floating > > > >point control word on the AMD64 is 0x37F. > > > ... > > > >It seems clear that the right thing to do is to set the floating point > > > >environment to the i386 default for i386 binaries. Is the current > > > >behavior intended? > > > > > > I believe this is an oversight. See the thread beginning > > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html > > > > >From reading Bruce's last message in that thread, seems to me > > may be default for 64bit binaries should be the same as on > > i386. Anyone wanting different behavior can always call > > fpsetprec() etc. > > > > I think the fix is to change __INITIAL_FPUCW__ in > > /sys/amd64/include/fpu.h to 0x127F like on i386. > I think this shall be done for 32-bit processes only, or we get into > another ABI breaking nightmare. How about something like this: (Carl, can you please test this?) http://www.FreeBSD.org/~jhb/patches/amd64_fpu_i386.patch --- //depot/vendor/freebsd/src/sys/amd64/amd64/fpu.c 2006/06/19 22:39:16 +++ //depot/user/jhb/acpipci/amd64/amd64/fpu.c 2009/01/26 21:47:49 @@ -391,6 +391,7 @@ { struct pcb *pcb; register_t s; + u_short control; if (PCPU_GET(fpcurthread) == curthread) { printf("fpudna: fpcurthread == curthread %d times\n", @@ -421,6 +422,10 @@ * explicitly load sanitized registers. */ fxrstor(&fpu_cleanstate); + if (pcb->pcb_flags & PCB_32BIT) { + control = __INITIAL_FPUCW_I386__; + fldcw(&control); + } pcb->pcb_flags |= PCB_FPUINITDONE; } else fxrstor(&pcb->pcb_save); --- //depot/vendor/freebsd/src/sys/amd64/include/fpu.h 2004/04/05 21:30:47 +++ //depot/user/jhb/acpipci/amd64/include/fpu.h 2009/01/26 21:47:49 @@ -92,6 +92,7 @@ * SSE2 based math. For FreeBSD/amd64, we go with the default settings. */ #define __INITIAL_FPUCW__ 0x037F +#define __INITIAL_FPUCW_I386__ 0x127F #define __INITIAL_MXCSR__ 0x1F80 #define __INITIAL_MXCSR_MASK__ 0xFFBF -- John Baldwin From mike at reifenberger.com Tue Jan 27 01:42:59 2009 From: mike at reifenberger.com (Michael Reifenberger) Date: Tue Jan 27 01:43:14 2009 Subject: WANTED! board models with Marvell 61XX chips In-Reply-To: References: Message-ID: On Mon, 26 Jan 2009, S?ren Schmidt wrote: > Date: Mon, 26 Jan 2009 21:22:36 +0100 > From: S?ren Schmidt > To: current , hackers@freebsd.org > Subject: WANTED! board models with Marvell 61XX chips > > Hi there! > > I thought I finally had a motherboard using one of the Marvell SATA/PATA > chips coming in, but unfortunately the delivery has been postponed to some > unspecified date, oh well.. > > Thats where you come into the picture as I'd like to get another one, but > finding boards that uses these is a bit tricky as most vendors doesn't write > such unimportant stuff on their web pages (hell it works in windows!). > > If you have a motherboard using one of the following Marvell chips, or know > for certain a model that does, please send me a private mail with make and > model as there is no need to pollute the lists (which I dont follow closely > for the time being btw). > > The chips in question are: > > Marvell 6111, 6121, 6141 or 6145 > I have an ASUS M2N32 WS Professional which has an 6141 onboard. Both SATA and PATA are accessable. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From patfbsd at davenulle.org Tue Jan 27 03:41:43 2009 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Tue Jan 27 03:41:50 2009 Subject: Mackbook pro nvidia based video backlight Message-ID: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> Hello, I've made a small driver to set the backlight level on Apple MacBook Pro, for the models based on the Nvida video card (model 3,1 and 3,2). (if it works on other models please tell me) At the moment this is a quick and dirty hack, but you don't need to wear a pair of sunglasses anymore! Module (FreeBSD 7.1): http://user.lamaiziere.net/patrick/ambnb-270109.tar.gz The driver does not check if the hardware is a suitable Macbook Pro (TODO!), so use with care. You can check the model of your Mac with dmidecode: Handle 0x0011, DMI type 1, 27 bytes System Information Manufacturer: Apple Inc. Product Name: MacBookPro3,1 Version: 1.0 There is a sysctl hw.ambnb.level to set the level of the backlight (0 <= level <= 15). I don't have the time for the moment, but i will try to improve it a bit. I'm asking which method will be the best to interface the driver with userland applications? Regards. From oliver.pntr at gmail.com Tue Jan 27 06:32:32 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Tue Jan 27 08:13:49 2009 Subject: WANTED! board models with Marvell 61XX chips In-Reply-To: References: Message-ID: <6101e8c40901270607i73baea4bxf903a6aab95afc29@mail.gmail.com> Hi ASUS P5Q-E has 88SE6121 On 1/26/09, S?ren Schmidt wrote: > Hi there! > > I thought I finally had a motherboard using one of the Marvell SATA/ > PATA chips coming in, but unfortunately the delivery has been > postponed to some unspecified date, oh well.. > > Thats where you come into the picture as I'd like to get another one, > but finding boards that uses these is a bit tricky as most vendors > doesn't write such unimportant stuff on their web pages (hell it works > in windows!). > > If you have a motherboard using one of the following Marvell chips, or > know for certain a model that does, please send me a private mail with > make and model as there is no need to pollute the lists (which I dont > follow closely for the time being btw). > > The chips in question are: > > Marvell 6111, 6121, 6141 or 6145 > > It is also important that there is physical access to both the SATA > and the PATA port(s) as some boards only utilize one or the other. > > I know of one PCI-express add-in board that uses the 6145, so if > anybody knows how to get ahold of one, that would be very welcomed as > well. The board in question is this: > http://www.sunix.com.tw/it/en/Product_Detail.php?cate=2&class_a_id=35&sid=538 > So far I've only found shops in South Africa that has it available, > but none of them ships outside the country. > > So if you have any useful info on this topic please get in touch with > me, thanks! > > > -S?ren > -- > > > > > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From op at trekdanne.se Tue Jan 27 09:02:17 2009 From: op at trekdanne.se (Daniel Lannstrom) Date: Tue Jan 27 09:02:25 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> Message-ID: <20090127150040.GA4333@haruhi> > I'm asking which method will be the best to interface the driver with > userland applications? You might want to make it a character device driver. And write a small userland control program. Sysctl isn't really made for this kind of functionality. From yanefbsd at gmail.com Tue Jan 27 09:55:40 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Tue Jan 27 09:55:52 2009 Subject: WANTED! board models with Marvell 61XX chips In-Reply-To: <6101e8c40901270607i73baea4bxf903a6aab95afc29@mail.gmail.com> References: <6101e8c40901270607i73baea4bxf903a6aab95afc29@mail.gmail.com> Message-ID: <92231DDF-6ACE-467D-AD8F-CF31740F365F@gmail.com> On Jan 27, 2009, at 6:07 AM, Oliver Pinter wrote: > Hi ASUS P5Q-E has 88SE6121 > > On 1/26/09, S?ren Schmidt wrote: >> Hi there! >> >> I thought I finally had a motherboard using one of the Marvell SATA/ >> PATA chips coming in, but unfortunately the delivery has been >> postponed to some unspecified date, oh well.. >> >> Thats where you come into the picture as I'd like to get another one, >> but finding boards that uses these is a bit tricky as most vendors >> doesn't write such unimportant stuff on their web pages (hell it >> works >> in windows!). >> >> If you have a motherboard using one of the following Marvell chips, >> or >> know for certain a model that does, please send me a private mail >> with >> make and model as there is no need to pollute the lists (which I dont >> follow closely for the time being btw). >> >> The chips in question are: >> >> Marvell 6111, 6121, 6141 or 6145 >> >> It is also important that there is physical access to both the SATA >> and the PATA port(s) as some boards only utilize one or the other. >> >> I know of one PCI-express add-in board that uses the 6145, so if >> anybody knows how to get ahold of one, that would be very welcomed as >> well. The board in question is this: >> http://www.sunix.com.tw/it/en/Product_Detail.php?cate=2&class_a_id=35&sid=538 >> So far I've only found shops in South Africa that has it available, >> but none of them ships outside the country. >> >> So if you have any useful info on this topic please get in touch with >> me, thanks! ASUS M3N-HT has a 6111 chipset hooked up to the e-SATA. Is that sufficient for your testing? Let me know and I'll help round up some parts for you... Cheers, -Garrett From rpaulo at freebsd.org Tue Jan 27 14:32:37 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Tue Jan 27 14:32:44 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090127150040.GA4333@haruhi> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> Message-ID: <4AB80C23-53E2-4413-B680-1B26BD46E886@freebsd.org> On 27 Jan 2009, at 15:00, Daniel Lannstrom wrote: >> I'm asking which method will be the best to interface the driver with >> userland applications? > > You might want to make it a character device driver. And write a small > userland control program. Sysctl isn't really made for this kind of > functionality. Why not? Sysctl seems perfect to handle this. -- Rui Paulo From sos at deepcore.dk Tue Jan 27 14:36:30 2009 From: sos at deepcore.dk (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Tue Jan 27 14:37:03 2009 Subject: WANTED! board models with Marvell 61XX chips Message-ID: Hi there! I thought I finally had a motherboard using one of the Marvell SATA/ PATA chips coming in, but unfortunately the delivery has been postponed to some unspecified date, oh well.. Thats where you come into the picture as I'd like to get another one, but finding boards that uses these is a bit tricky as most vendors doesn't write such unimportant stuff on their web pages (hell it works in windows!). If you have a motherboard using one of the following Marvell chips, or know for certain a model that does, please send me a private mail with make and model as there is no need to pollute the lists (which I dont follow closely for the time being btw). The chips in question are: Marvell 6111, 6121, 6141 or 6145 It is also important that there is physical access to both the SATA and the PATA port(s) as some boards only utilize one or the other. I know of one PCI-express add-in board that uses the 6145, so if anybody knows how to get ahold of one, that would be very welcomed as well. The board in question is this: http://www.sunix.com.tw/it/en/Product_Detail.php?cate=2&class_a_id=35&sid=538 So far I've only found shops in South Africa that has it available, but none of them ships outside the country. So if you have any useful info on this topic please get in touch with me, thanks! -S?ren -- _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From yanefbsd at gmail.com Tue Jan 27 14:37:23 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Tue Jan 27 14:39:53 2009 Subject: WANTED! board models with Marvell 61XX chips In-Reply-To: <6101e8c40901270607i73baea4bxf903a6aab95afc29@mail.gmail.com> References: <6101e8c40901270607i73baea4bxf903a6aab95afc29@mail.gmail.com> Message-ID: <92231DDF-6ACE-467D-AD8F-CF31740F365F@gmail.com> On Jan 27, 2009, at 6:07 AM, Oliver Pinter wrote: > Hi ASUS P5Q-E has 88SE6121 > > On 1/26/09, S?ren Schmidt wrote: >> Hi there! >> >> I thought I finally had a motherboard using one of the Marvell SATA/ >> PATA chips coming in, but unfortunately the delivery has been >> postponed to some unspecified date, oh well.. >> >> Thats where you come into the picture as I'd like to get another one, >> but finding boards that uses these is a bit tricky as most vendors >> doesn't write such unimportant stuff on their web pages (hell it >> works >> in windows!). >> >> If you have a motherboard using one of the following Marvell chips, >> or >> know for certain a model that does, please send me a private mail >> with >> make and model as there is no need to pollute the lists (which I dont >> follow closely for the time being btw). >> >> The chips in question are: >> >> Marvell 6111, 6121, 6141 or 6145 >> >> It is also important that there is physical access to both the SATA >> and the PATA port(s) as some boards only utilize one or the other. >> >> I know of one PCI-express add-in board that uses the 6145, so if >> anybody knows how to get ahold of one, that would be very welcomed as >> well. The board in question is this: >> http://www.sunix.com.tw/it/en/Product_Detail.php?cate=2&class_a_id=35&sid=538 >> So far I've only found shops in South Africa that has it available, >> but none of them ships outside the country. >> >> So if you have any useful info on this topic please get in touch with >> me, thanks! ASUS M3N-HT has a 6111 chipset hooked up to the e-SATA. Is that sufficient for your testing? Let me know and I'll help round up some parts for you... Cheers, -Garrett_______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From mike at reifenberger.com Tue Jan 27 14:51:04 2009 From: mike at reifenberger.com (Michael Reifenberger) Date: Tue Jan 27 14:51:11 2009 Subject: WANTED! board models with Marvell 61XX chips In-Reply-To: References: Message-ID: On Mon, 26 Jan 2009, S?ren Schmidt wrote: > Date: Mon, 26 Jan 2009 21:22:36 +0100 > From: S?ren Schmidt > To: current , hackers@freebsd.org > Subject: WANTED! board models with Marvell 61XX chips > > Hi there! > > I thought I finally had a motherboard using one of the Marvell SATA/PATA > chips coming in, but unfortunately the delivery has been postponed to some > unspecified date, oh well.. > > Thats where you come into the picture as I'd like to get another one, but > finding boards that uses these is a bit tricky as most vendors doesn't write > such unimportant stuff on their web pages (hell it works in windows!). > > If you have a motherboard using one of the following Marvell chips, or know > for certain a model that does, please send me a private mail with make and > model as there is no need to pollute the lists (which I dont follow closely > for the time being btw). > > The chips in question are: > > Marvell 6111, 6121, 6141 or 6145 > I have an ASUS M2N32 WS Professional which has an 6141 onboard. Both SATA and PATA are accessable. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com -------------- next part -------------- _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From oliver.pntr at gmail.com Tue Jan 27 14:37:26 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Tue Jan 27 15:20:02 2009 Subject: WANTED! board models with Marvell 61XX chips In-Reply-To: References: Message-ID: <6101e8c40901270607i73baea4bxf903a6aab95afc29@mail.gmail.com> Hi ASUS P5Q-E has 88SE6121 On 1/26/09, S?ren Schmidt wrote: > Hi there! > > I thought I finally had a motherboard using one of the Marvell SATA/ > PATA chips coming in, but unfortunately the delivery has been > postponed to some unspecified date, oh well.. > > Thats where you come into the picture as I'd like to get another one, > but finding boards that uses these is a bit tricky as most vendors > doesn't write such unimportant stuff on their web pages (hell it works > in windows!). > > If you have a motherboard using one of the following Marvell chips, or > know for certain a model that does, please send me a private mail with > make and model as there is no need to pollute the lists (which I dont > follow closely for the time being btw). > > The chips in question are: > > Marvell 6111, 6121, 6141 or 6145 > > It is also important that there is physical access to both the SATA > and the PATA port(s) as some boards only utilize one or the other. > > I know of one PCI-express add-in board that uses the 6145, so if > anybody knows how to get ahold of one, that would be very welcomed as > well. The board in question is this: > http://www.sunix.com.tw/it/en/Product_Detail.php?cate=2&class_a_id=35&sid=538 > So far I've only found shops in South Africa that has it available, > but none of them ships outside the country. > > So if you have any useful info on this topic please get in touch with > me, thanks! > > > -S?ren > -- > > > > > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From imp at bsdimp.com Wed Jan 28 01:11:57 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 28 01:12:03 2009 Subject: Code review request: cdcontrol status label additon Message-ID: <20090128.020950.-1962670362.imp@bsdimp.com> Please find enclosed patches to enable printing of the ISO-9660 Volume label, if present, for a CD. I've connected this to the 'status label' command. Please comment. Warner -------------- next part -------------- Index: cdcontrol.1 =================================================================== --- cdcontrol.1 (revision 187760) +++ cdcontrol.1 (working copy) @@ -156,12 +156,14 @@ Play the right subtrack on both left and right channels. .It Ic info Print the table of contents. -.It Ic status Op Cm audio | media | volume +.It Ic status Op Cm audio | label | media | volume Print the information about the disc: .Pp .Bl -tag -width ".Cm volume" -compact .It Cm audio the current playing status and position +.It Cm label +the current ISO 9660 volume label, if present .It Cm media the current media catalog status .It Cm volume Index: cdcontrol.c =================================================================== --- cdcontrol.c (revision 187760) +++ cdcontrol.c (working copy) @@ -86,6 +86,7 @@ #define STATUS_AUDIO 0x1 #define STATUS_MEDIA 0x2 #define STATUS_VOLUME 0x4 +#define STATUS_LABEL 0x8 struct cmdtab { int command; @@ -801,6 +802,8 @@ what |= STATUS_MEDIA; else if (!strncasecmp(p, "volume", strlen(p))) what |= STATUS_VOLUME; + else if (!strncasecmp(p, "label", strlen(p))) + what |= STATUS_LABEL; else { warnx("invalid command arguments"); return 0; @@ -851,6 +854,32 @@ else printf ("No volume level info available\n"); } + if (what & STATUS_LABEL) { +#define ISO9660_MAGIC "\x01" "CD001" "\x01\x00" +#define ISO9660_OFFSET 0x8000 +#define VOLUME_LEN 32 +#define CD_SECTOR_LEN 2048 +#define LABEL_NAME_OFF 0x28 +#define LABEL_NAME_LEN 32 + char *sp, *ep, buffer[CD_SECTOR_LEN]; + + lseek(fd, ISO9660_OFFSET, SEEK_SET); + rc = read (fd, buffer, CD_SECTOR_LEN); + if (rc == CD_SECTOR_LEN && + memcmp(buffer, ISO9660_MAGIC, sizeof(ISO9660_MAGIC) - 1) == 0) { + sp = buffer + LABEL_NAME_OFF; + ep = sp + LABEL_NAME_LEN - 1; + while (*ep == ' ' && ep >= sp) + *ep-- = '\0'; + if (verbose) + printf("ISO 9660 Label is: %s\n", sp); + else + printf("%s\n", sp); + } + else + printf("No ISO 9660 label found\n"); + } + return(0); } From keramida at freebsd.org Wed Jan 28 02:16:37 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Wed Jan 28 02:16:44 2009 Subject: Code review request: cdcontrol status label additon In-Reply-To: <20090128.020950.-1962670362.imp@bsdimp.com> (M. Warner Losh's message of "Wed, 28 Jan 2009 02:09:50 -0700 (MST)") References: <20090128.020950.-1962670362.imp@bsdimp.com> Message-ID: <87k58f7npu.fsf@kobe.laptop> On Wed, 28 Jan 2009 02:09:50 -0700 (MST), "M. Warner Losh" wrote: > Please find enclosed patches to enable printing of the ISO-9660 Volume > label, if present, for a CD. I've connected this to the 'status > label' command. Please comment. The style looks ok, but this didn't work for a Fedora Core 10 disk I have around. glabel on the other hand detected the label fine: [ /var/log/messages ] Jan 28 11:59:00 kobe kernel: GEOM_LABEL: Label for provider acd0t01 is iso9660/F10-i686-Live. Running `status label' on the same disk didn't find one: # ./cdcontrol status label No ISO 9660 label found # ./cdcontrol -f /dev/acd0t01 status label No ISO 9660 label found Maybe it would be better to hook into glabel (when available) or use a userland copy of the same code? From pluknet at gmail.com Wed Jan 28 02:55:45 2009 From: pluknet at gmail.com (pluknet) Date: Wed Jan 28 02:55:52 2009 Subject: dublicated vm stats in sysctl Message-ID: Hi. What is a purpose of some dublicated vm stuff in vm. and vm.stats. branches? vm.v_free_min: 6392 vm.stats.vm.v_free_min: 6392 vm.v_cache_min: 26928 vm.v_cache_max: 53856 vm.stats.vm.v_cache_max: 53856 vm.stats.vm.v_cache_min: 26928 and so on.. I see some relevance in vm/vm_meter.c#rev1.62 but cannot understand it. -- wbr, pluknet From ed at 80386.nl Wed Jan 28 05:43:11 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Jan 28 05:43:18 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090127150040.GA4333@haruhi> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> Message-ID: <20090128134309.GN17198@hoeg.nl> * Daniel Lannstrom wrote: > > I'm asking which method will be the best to interface the driver with > > userland applications? > > You might want to make it a character device driver. And write a small > userland control program. Sysctl isn't really made for this kind of > functionality. No. sysctl is good for doing stuff like this. An even better approach would be to integrate it to the X11 driver, but I guess it will be cold day in hell when this happens. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090128/7bbec7d2/attachment.pgp From rpaulo at freebsd.org Wed Jan 28 06:30:02 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Wed Jan 28 06:30:08 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090128134309.GN17198@hoeg.nl> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> Message-ID: <71915973-47E0-4F38-AC20-221817A19C11@freebsd.org> On 28 Jan 2009, at 13:43, Ed Schouten wrote: > * Daniel Lannstrom wrote: >>> I'm asking which method will be the best to interface the driver >>> with >>> userland applications? >> >> You might want to make it a character device driver. And write a >> small >> userland control program. Sysctl isn't really made for this kind of >> functionality. > > No. sysctl is good for doing stuff like this. An even better approach > would be to integrate it to the X11 driver, but I guess it will be > cold > day in hell when this happens. Not really. The xorg intel driver is already able to deal with this. I don't know about NVIDIA. -- Rui Paulo From rpaulo at gmail.com Wed Jan 28 06:29:06 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Wed Jan 28 06:47:20 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090128134309.GN17198@hoeg.nl> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> Message-ID: <224440FC-D2A2-4EE6-A4DB-CCB43F1DCDB4@gmail.com> On 28 Jan 2009, at 13:43, Ed Schouten wrote: > * Daniel Lannstrom wrote: >>> I'm asking which method will be the best to interface the driver >>> with >>> userland applications? >> >> You might want to make it a character device driver. And write a >> small >> userland control program. Sysctl isn't really made for this kind of >> functionality. > > No. sysctl is good for doing stuff like this. An even better approach > would be to integrate it to the X11 driver, but I guess it will be > cold > day in hell when this happens. Not really. The xorg intel driver is already able to deal with this. I don't know about NVIDIA. -- Rui Paulo From brampton+freebsd-hackers at gmail.com Wed Jan 28 07:12:35 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Wed Jan 28 07:12:42 2009 Subject: Mutually exclusive kernel modules Message-ID: Hi, I'm writing a new kernel module which can not be run with another module. If both run then bad things will happen and the kernel will fall over. Fixing the modules so they can be run together is not a option, so I wanted to code something in this new module which would A) Check if the other module is already running and thus refuse to start. and B) Stop the other module from loading in the future. So is there a way to do this? thanks Andrew From assaulter0x80 at gmail.com Wed Jan 28 07:40:22 2009 From: assaulter0x80 at gmail.com (Jacky Oh) Date: Wed Jan 28 07:40:30 2009 Subject: Fwd: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: References: <20090120.131627.-1717264382.imp@bsdimp.com> Message-ID: hi everyone, the main goal of KLD are load code for executing as part of kernel at run-time, so, i don't think that rebuild the kernel are a good solution.. In other way a try to load any dev/syscall example at /usr/share/examples/kld the result was the same.. When i was thinking in S. Sedov reply about the undefined symbols i go to run objdump for my syscall.ko and i can find the following: # objdump -x syscall.ko ... 000019d4 l O .data 00000010 M_DIRP2_uninit_sys_uninit 0000094c l O set_sysinit_set 00000004 __set_sysinit_set_sym_M_DIRP2_init_sys_init 000019e4 l O .data 00000010 M_DIRP2_init_sys_init 000019f4 l O .data 0000000c syscall_mod 00001a00 l O .data 0000000c _syscall_depend_on_kernel <------ 00001a20 l O .data 00000028 syscall_syscall_mod 00001a48 l O .data 00000004 offset ... The result whit the examples also shows the same symbol (_syscall_depend_on_kernel), so, y disassemble this function: 00001a00 <_syscall_depend_on_kernel>: 1a00: 3c 35 cmp $0x35,%al 1a02: 0c 00 or $0x0,%al 1a04: 3c 35 cmp $0x35,%al 1a06: 0c 00 or $0x0,%al 1a08: 9f lahf 1a09: bb 0d 00 00 00 mov $0xd,%ebx ... lahf == load status flags (EFLAGS) on ah register so, my question is, why precompiled modules (as if_ipw.ko, for example) don't show this function? Thanks to all, jacky. From rnoland at FreeBSD.org Wed Jan 28 08:10:21 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Jan 28 08:10:27 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <224440FC-D2A2-4EE6-A4DB-CCB43F1DCDB4@gmail.com> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> <224440FC-D2A2-4EE6-A4DB-CCB43F1DCDB4@gmail.com> Message-ID: <1233157825.1733.5.camel@wombat.2hip.net> On Wed, 2009-01-28 at 14:29 +0000, Rui Paulo wrote: > On 28 Jan 2009, at 13:43, Ed Schouten wrote: > > > * Daniel Lannstrom wrote: > >>> I'm asking which method will be the best to interface the driver > >>> with > >>> userland applications? > >> > >> You might want to make it a character device driver. And write a > >> small > >> userland control program. Sysctl isn't really made for this kind of > >> functionality. > > > > No. sysctl is good for doing stuff like this. An even better approach > > would be to integrate it to the X11 driver, but I guess it will be > > cold > > day in hell when this happens. > > Not really. The xorg intel driver is already able to deal with this. > I don't know about NVIDIA. The intel ddx driver doesn't really deal with it. On linux the drm has code that interfaces with acpi to deal with backlight management. For us, afaik we handle it in acpi_video. I've not tried to port that part of the drm code. I'm not certain where the best place for this function to live is really, but for Nvidia's proprietary driver, the only option is a seperate kernel driver. robert. > -- > Rui Paulo > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090128/237d8bfd/attachment.pgp From imp at bsdimp.com Wed Jan 28 08:21:06 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 28 08:21:14 2009 Subject: Code review request: cdcontrol status label additon In-Reply-To: <87k58f7npu.fsf@kobe.laptop> References: <20090128.020950.-1962670362.imp@bsdimp.com> <87k58f7npu.fsf@kobe.laptop> Message-ID: <20090128.092046.84362525.imp@bsdimp.com> In message: <87k58f7npu.fsf@kobe.laptop> Giorgos Keramidas writes: : On Wed, 28 Jan 2009 02:09:50 -0700 (MST), "M. Warner Losh" wrote: : > Please find enclosed patches to enable printing of the ISO-9660 Volume : > label, if present, for a CD. I've connected this to the 'status : > label' command. Please comment. : : The style looks ok, but this didn't work for a Fedora Core 10 disk I : have around. glabel on the other hand detected the label fine: : : [ /var/log/messages ] : Jan 28 11:59:00 kobe kernel: GEOM_LABEL: Label for provider acd0t01 is iso9660/F10-i686-Live. : : Running `status label' on the same disk didn't find one: : : # ./cdcontrol status label : No ISO 9660 label found : # ./cdcontrol -f /dev/acd0t01 status label : No ISO 9660 label found : : Maybe it would be better to hook into glabel (when available) or use a : userland copy of the same code? Not going to look at glabel for this. I lifted the code from glable, but must have done it badly. I'll grab a core 10 cd and see what's up. Warner From keramida at freebsd.org Wed Jan 28 08:29:31 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Wed Jan 28 08:29:38 2009 Subject: Code review request: cdcontrol status label additon In-Reply-To: <20090128.092046.84362525.imp@bsdimp.com> (M. Warner Losh's message of "Wed, 28 Jan 2009 09:20:46 -0700 (MST)") References: <20090128.020950.-1962670362.imp@bsdimp.com> <87k58f7npu.fsf@kobe.laptop> <20090128.092046.84362525.imp@bsdimp.com> Message-ID: <87mydbiecp.fsf@kobe.laptop> On Wed, 28 Jan 2009 09:20:46 -0700 (MST), "M. Warner Losh" wrote: > Not going to look at glabel for this. I lifted the code from glable, > but must have done it badly. I'll grab a core 10 cd and see what's up. It may not be Fedora specific. I just happened to have it handy... Sorry for creating *more* work for you. I'll see if I can hack at cdcontrol too, and provide more useful input :) From ed at 80386.nl Wed Jan 28 08:33:30 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Jan 28 08:33:37 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <71915973-47E0-4F38-AC20-221817A19C11@freebsd.org> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> <71915973-47E0-4F38-AC20-221817A19C11@freebsd.org> Message-ID: <20090128163328.GS17198@hoeg.nl> * Rui Paulo wrote: > Not really. The xorg intel driver is already able to deal with this. > I don't know about NVIDIA. Yes, but that's what I mean. It will be a cold day in hell when "nv" supports this. As far as I can tell, it's just a pile of obfuscated C code. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090128/50662cdd/attachment.pgp From imp at bsdimp.com Wed Jan 28 09:00:57 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 28 09:01:14 2009 Subject: Code review request: cdcontrol status label additon In-Reply-To: <87mydbiecp.fsf@kobe.laptop> References: <87k58f7npu.fsf@kobe.laptop> <20090128.092046.84362525.imp@bsdimp.com> <87mydbiecp.fsf@kobe.laptop> Message-ID: <20090128.095720.1650439658.imp@bsdimp.com> In message: <87mydbiecp.fsf@kobe.laptop> Giorgos Keramidas writes: : On Wed, 28 Jan 2009 09:20:46 -0700 (MST), "M. Warner Losh" wrote: : > Not going to look at glabel for this. I lifted the code from glable, : > but must have done it badly. I'll grab a core 10 cd and see what's up. : : It may not be Fedora specific. I just happened to have it handy... : : Sorry for creating *more* work for you. I'll see if I can hack at : cdcontrol too, and provide more useful input :) I was actually thinking of moving this from status to its own command because the label isn't the only thing from the master header that I want to display. Warner From keramida at ceid.upatras.gr Wed Jan 28 09:16:38 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Wed Jan 28 09:16:46 2009 Subject: Code review request: cdcontrol status label additon In-Reply-To: <87mydbiecp.fsf@kobe.laptop> (Giorgos Keramidas's message of "Wed, 28 Jan 2009 18:29:10 +0200") References: <20090128.020950.-1962670362.imp@bsdimp.com> <87k58f7npu.fsf@kobe.laptop> <20090128.092046.84362525.imp@bsdimp.com> <87mydbiecp.fsf@kobe.laptop> Message-ID: <87d4e7e4y0.fsf@kobe.laptop> On Wed, 28 Jan 2009 18:29:10 +0200, Giorgos Keramidas wrote: > On Wed, 28 Jan 2009 09:20:46 -0700 (MST), "M. Warner Losh" wrote: >> Not going to look at glabel for this. I lifted the code from glable, >> but must have done it badly. I'll grab a core 10 cd and see what's up. > > It may not be Fedora specific. I just happened to have it handy... > > Sorry for creating *more* work for you. I'll see if I can hack at > cdcontrol too, and provide more useful input :) If it helps at all, I added this: lseek(fd, ISO9660_OFFSET, SEEK_SET); rc = read (fd, buffer, CD_SECTOR_LEN); + if (rc == -1) + err(1, "read"); if (rc == CD_SECTOR_LEN && memcmp(buffer, ISO9660_MAGIC, sizeof(ISO9660_MAGIC) - 1) == 0) { and it seems that read() fails with EIO: lseek(3,0x8000,SEEK_SET) = 32768 (0x8000) read(3,0xbfbfe3a3,2048) ERR#5 'Input/output error' My `/var/log/messages' shows at the same time: Jan 28 19:01:52 kobe kernel: acd0: FAILURE - non aligned DMA transfer attempted Jan 28 19:01:52 kobe kernel: acd0: setting up DMA failed This is with a FreeBSD 8.0-CURRENT kernel from svn /head @ 187792. So it may not really be a problem with the patch itself... From imp at bsdimp.com Wed Jan 28 09:21:23 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 28 09:21:30 2009 Subject: Code review request: cdcontrol status label additon In-Reply-To: <87d4e7e4y0.fsf@kobe.laptop> References: <20090128.092046.84362525.imp@bsdimp.com> <87mydbiecp.fsf@kobe.laptop> <87d4e7e4y0.fsf@kobe.laptop> Message-ID: <20090128.101900.1355775961.imp@bsdimp.com> In message: <87d4e7e4y0.fsf@kobe.laptop> Giorgos Keramidas writes: : On Wed, 28 Jan 2009 18:29:10 +0200, Giorgos Keramidas wrote: : > On Wed, 28 Jan 2009 09:20:46 -0700 (MST), "M. Warner Losh" wrote: : >> Not going to look at glabel for this. I lifted the code from glable, : >> but must have done it badly. I'll grab a core 10 cd and see what's up. : > : > It may not be Fedora specific. I just happened to have it handy... : > : > Sorry for creating *more* work for you. I'll see if I can hack at : > cdcontrol too, and provide more useful input :) : : If it helps at all, I added this: : : lseek(fd, ISO9660_OFFSET, SEEK_SET); : rc = read (fd, buffer, CD_SECTOR_LEN); : + if (rc == -1) : + err(1, "read"); : if (rc == CD_SECTOR_LEN && : memcmp(buffer, ISO9660_MAGIC, sizeof(ISO9660_MAGIC) - 1) == 0) { : : and it seems that read() fails with EIO: : : lseek(3,0x8000,SEEK_SET) = 32768 (0x8000) : read(3,0xbfbfe3a3,2048) ERR#5 'Input/output error' OK. That's definitely not page aligned. : My `/var/log/messages' shows at the same time: : : Jan 28 19:01:52 kobe kernel: acd0: FAILURE - non aligned DMA transfer attempted : Jan 28 19:01:52 kobe kernel: acd0: setting up DMA failed ???? I have no clue what this means. I'll have to investigate. Chances are that your hardware has limitations on where DMA can come from and no provisions in the acd driver to bounce them (likely a reasonable performance thing). This likely means that I'll have to malloc the buffer to get it page aligned... Warner From keramida at freebsd.org Wed Jan 28 09:35:18 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Wed Jan 28 09:35:25 2009 Subject: Code review request: cdcontrol status label additon In-Reply-To: <20090128.101900.1355775961.imp@bsdimp.com> (M. Warner Losh's message of "Wed, 28 Jan 2009 10:19:00 -0700 (MST)") References: <20090128.092046.84362525.imp@bsdimp.com> <87mydbiecp.fsf@kobe.laptop> <87d4e7e4y0.fsf@kobe.laptop> <20090128.101900.1355775961.imp@bsdimp.com> Message-ID: <87zlhb49ml.fsf@kobe.laptop> On Wed, 28 Jan 2009 10:19:00 -0700 (MST), "M. Warner Losh" wrote: > : lseek(3,0x8000,SEEK_SET) = 32768 (0x8000) > : read(3,0xbfbfe3a3,2048) ERR#5 'Input/output error' > > OK. That's definitely not page aligned. Slightly modified to force the alignment. Thanks for the tip about the address, which I failed to notice in truss output :) %%% diff -r 0c625c73ecc0 usr.sbin/cdcontrol/cdcontrol.1 --- a/usr.sbin/cdcontrol/cdcontrol.1 Wed Jan 28 18:38:39 2009 +0200 +++ b/usr.sbin/cdcontrol/cdcontrol.1 Wed Jan 28 19:34:15 2009 +0200 @@ -156,12 +156,14 @@ Play the right subtrack on both left and right channels. .It Ic info Print the table of contents. -.It Ic status Op Cm audio | media | volume +.It Ic status Op Cm audio | label | media | volume Print the information about the disc: .Pp .Bl -tag -width ".Cm volume" -compact .It Cm audio the current playing status and position +.It Cm label +the current ISO 9660 volume label, if present .It Cm media the current media catalog status .It Cm volume diff -r 0c625c73ecc0 usr.sbin/cdcontrol/cdcontrol.c --- a/usr.sbin/cdcontrol/cdcontrol.c Wed Jan 28 18:38:39 2009 +0200 +++ b/usr.sbin/cdcontrol/cdcontrol.c Wed Jan 28 19:34:15 2009 +0200 @@ -86,6 +86,7 @@ #define STATUS_AUDIO 0x1 #define STATUS_MEDIA 0x2 #define STATUS_VOLUME 0x4 +#define STATUS_LABEL 0x8 struct cmdtab { int command; @@ -801,6 +802,8 @@ what |= STATUS_MEDIA; else if (!strncasecmp(p, "volume", strlen(p))) what |= STATUS_VOLUME; + else if (!strncasecmp(p, "label", strlen(p))) + what |= STATUS_LABEL; else { warnx("invalid command arguments"); return 0; @@ -851,6 +854,32 @@ else printf ("No volume level info available\n"); } + if (what & STATUS_LABEL) { +#define ISO9660_MAGIC "\x01" "CD001" "\x01\x00" +#define ISO9660_OFFSET 0x8000 +#define VOLUME_LEN 32 +#define CD_SECTOR_LEN 2048 +#define LABEL_NAME_OFF 0x28 +#define LABEL_NAME_LEN 32 + uint32_t buffer[CD_SECTOR_LEN / sizeof(uint32_t)]; + char *sp, *ep; + + lseek(fd, ISO9660_OFFSET, SEEK_SET); + rc = read (fd, buffer, CD_SECTOR_LEN); + if (rc == CD_SECTOR_LEN && + memcmp(buffer, ISO9660_MAGIC, sizeof(ISO9660_MAGIC) - 1) == 0) { + sp = (void *)buffer + LABEL_NAME_OFF; + ep = sp + LABEL_NAME_LEN - 1; + while (*ep == ' ' && ep >= sp) + *ep-- = '\0'; + if (verbose) + printf("ISO 9660 Label is: %s\n", sp); + else + printf("%s\n", sp); + } + else + printf("No ISO 9660 label found\n"); + } return(0); } %%% From bakul at bitblocks.com Wed Jan 28 11:24:25 2009 From: bakul at bitblocks.com (Bakul Shah) Date: Wed Jan 28 11:24:32 2009 Subject: critical floating point incompatibility In-Reply-To: Your message of "Mon, 26 Jan 2009 16:51:28 EST." <200901261651.29116.jhb@freebsd.org> References: <20071220093950.GA79196@server.vk2pj.dyndns.org> <20071221181125.0B6F25B42@mail.bitblocks.com> <20071221201633.GM57756@deviant.kiev.zoral.com.ua> <200901261651.29116.jhb@freebsd.org> Message-ID: <20090128192421.C9E3D5B13@mail.bitblocks.com> On Mon, 26 Jan 2009 16:51:28 EST John Baldwin wrote: > On Friday 21 December 2007 3:16:33 pm Kostik Belousov wrote: > > On Fri, Dec 21, 2007 at 10:11:24AM -0800, Bakul Shah wrote: > > > Peter Jeremy wrote: > > > > On Wed, Dec 19, 2007 at 09:40:34PM -0800, Carl Shapiro wrote: > > > > >The default setting of the x87 floating point control word on the i386 > > > > >port is 0x127F. Among other things, this value sets the precision > > > > >control to double precision. The default setting of the x87 floating > > > > >point control word on the AMD64 is 0x37F. > > > > ... > > > > >It seems clear that the right thing to do is to set the floating point > > > > >environment to the i386 default for i386 binaries. Is the current > > > > >behavior intended? > > > > > > > > I believe this is an oversight. See the thread beginning > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html > > > > > > >From reading Bruce's last message in that thread, seems to me > > > may be default for 64bit binaries should be the same as on > > > i386. Anyone wanting different behavior can always call > > > fpsetprec() etc. > > > > > > I think the fix is to change __INITIAL_FPUCW__ in > > > /sys/amd64/include/fpu.h to 0x127F like on i386. > > I think this shall be done for 32-bit processes only, or we get into > > another ABI breaking nightmare. > > How about something like this: (Carl, can you please test this?) Your patch works fine on a recent -current. Here is a program Carl had sent me more than a year ago for testing this. May be some varition of it can be added to compatibility tests. #include int main(void) { unsigned short cw; __asm__ __volatile__ ("fnstcw %0":"=m"(*&cw)); printf("cw=%#x\n", cw); return 0; } -- bakul PS: On a mac, cc -m64 builds 64 bit binaries and cc -m32 builds 32 bit binaries. The following script makes it as easy to do so on a 64 bit FreeBSD -- at least on the few programs I tried. Ideally the right magic needs to be folded in gcc's builtin "specs". #!/bin/sh args=/usr/bin/cc while [ ".$1" != . ] do a=$1; shift case $a in -m32) args="$args -B/usr/lib32 -I/usr/include32 -m32";; *) args="$args $a";; esac done $args Ideally x86_64 platforms run *all* i386 programs (that don't depend on a 32 bit kernel). From jhb at freebsd.org Wed Jan 28 12:41:04 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jan 28 12:41:11 2009 Subject: Fwd: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: References: Message-ID: <200901281406.53033.jhb@freebsd.org> On Wednesday 28 January 2009 10:40:20 am Jacky Oh wrote: > hi everyone, > > the main goal of KLD are load code for executing as part of kernel at > run-time, so, i don't think that rebuild the kernel are a good solution.. > In other way a try to load any dev/syscall example at > /usr/share/examples/kld the result was the same.. > When i was thinking in S. Sedov reply about the undefined symbols i go to > run objdump for my syscall.ko and i can find the following: > # objdump -x syscall.ko > ... > 000019d4 l O .data 00000010 M_DIRP2_uninit_sys_uninit > 0000094c l O set_sysinit_set 00000004 > __set_sysinit_set_sym_M_DIRP2_init_sys_init > 000019e4 l O .data 00000010 M_DIRP2_init_sys_init > 000019f4 l O .data 0000000c syscall_mod > 00001a00 l O .data 0000000c _syscall_depend_on_kernel <------ > 00001a20 l O .data 00000028 syscall_syscall_mod > 00001a48 l O .data 00000004 offset > ... > The result whit the examples also shows the same symbol > (_syscall_depend_on_kernel), so, y disassemble this function: > > 00001a00 <_syscall_depend_on_kernel>: > 1a00: 3c 35 cmp $0x35,%al > 1a02: 0c 00 or $0x0,%al > 1a04: 3c 35 cmp $0x35,%al > 1a06: 0c 00 or $0x0,%al > 1a08: 9f lahf > 1a09: bb 0d 00 00 00 mov $0xd,%ebx > ... > > lahf == load status flags (EFLAGS) on ah register > > so, my question is, why precompiled modules (as if_ipw.ko, for example) > don't show this function? That is a MODULE_DEPEND() data structure, not a function. -- John Baldwin From jhb at freebsd.org Wed Jan 28 12:41:31 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jan 28 12:41:54 2009 Subject: critical floating point incompatibility In-Reply-To: <20090128192421.C9E3D5B13@mail.bitblocks.com> References: <20071220093950.GA79196@server.vk2pj.dyndns.org> <200901261651.29116.jhb@freebsd.org> <20090128192421.C9E3D5B13@mail.bitblocks.com> Message-ID: <200901281535.31501.jhb@freebsd.org> On Wednesday 28 January 2009 2:24:21 pm Bakul Shah wrote: > On Mon, 26 Jan 2009 16:51:28 EST John Baldwin wrote: > > On Friday 21 December 2007 3:16:33 pm Kostik Belousov wrote: > > > On Fri, Dec 21, 2007 at 10:11:24AM -0800, Bakul Shah wrote: > > > > Peter Jeremy wrote: > > > > > On Wed, Dec 19, 2007 at 09:40:34PM -0800, Carl Shapiro wrote: > > > > > >The default setting of the x87 floating point control word on the i386 > > > > > >port is 0x127F. Among other things, this value sets the precision > > > > > >control to double precision. The default setting of the x87 floating > > > > > >point control word on the AMD64 is 0x37F. > > > > > ... > > > > > >It seems clear that the right thing to do is to set the floating point > > > > > >environment to the i386 default for i386 binaries. Is the current > > > > > >behavior intended? > > > > > > > > > > I believe this is an oversight. See the thread beginning > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/037947.html > > > > > > > > >From reading Bruce's last message in that thread, seems to me > > > > may be default for 64bit binaries should be the same as on > > > > i386. Anyone wanting different behavior can always call > > > > fpsetprec() etc. > > > > > > > > I think the fix is to change __INITIAL_FPUCW__ in > > > > /sys/amd64/include/fpu.h to 0x127F like on i386. > > > I think this shall be done for 32-bit processes only, or we get into > > > another ABI breaking nightmare. > > > > How about something like this: (Carl, can you please test this?) > > Your patch works fine on a recent -current. Here is a > program Carl had sent me more than a year ago for testing > this. May be some varition of it can be added to > compatibility tests. > > #include > int main(void) > { > unsigned short cw; > __asm__ __volatile__ ("fnstcw %0":"=m"(*&cw)); > printf("cw=%#x\n", cw); > return 0; > } > > -- bakul Cool, thanks for testing! -- John Baldwin From patfbsd at davenulle.org Wed Jan 28 14:01:20 2009 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Wed Jan 28 14:01:26 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090128163328.GS17198@hoeg.nl> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> <71915973-47E0-4F38-AC20-221817A19C11@freebsd.org> <20090128163328.GS17198@hoeg.nl> Message-ID: <20090128230115.3a1e2871@baby-jane.lamaiziere.net> Le Wed, 28 Jan 2009 17:33:28 +0100, Ed Schouten : > > Not really. The xorg intel driver is already able to deal with this. > > I don't know about NVIDIA. > > Yes, but that's what I mean. It will be a cold day in hell when "nv" > supports this. As far as I can tell, it's just a pile of obfuscated C > code. Anyway the backlight is very very high even in the console, I don't want to use X for this, i will not be able to set it at boot-time. Thanks for your replies, i will use both sysctl and a character device. Regards. From bsd.quest at googlemail.com Wed Jan 28 20:53:35 2009 From: bsd.quest at googlemail.com (Alexej Sokolov) Date: Wed Jan 28 20:53:42 2009 Subject: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: References: Message-ID: <20090129045304.GA18493@debian.samsung.router> Can you paste please the dmesg after KLDloading ? Sometimes there are in /var/log/messages more helpful information. And I would like to look your syscall code if it possible. Alexej On Tue, Jan 20, 2009 at 05:21:02PM +0100, Jacky Oh wrote: > Hi, > > I'm writing a syscall module and he compiles well but at load time, kldload > shows: > > KLD: program.ko: depends of kernel - no avaiable > > anyone know something about this? > > Thanks! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Alexej Sokolov From imp at bsdimp.com Wed Jan 28 21:36:16 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 28 21:36:23 2009 Subject: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: <20090129045304.GA18493@debian.samsung.router> References: <20090129045304.GA18493@debian.samsung.router> Message-ID: <20090128.223315.1447365184.imp@bsdimp.com> In message: <20090129045304.GA18493@debian.samsung.router> Alexej Sokolov writes: : Can you paste please the dmesg after KLDloading ? Sometimes there are : in /var/log/messages more helpful information. And I would like to look : your syscall code if it possible. : : Alexej : : On Tue, Jan 20, 2009 at 05:21:02PM +0100, Jacky Oh wrote: : > Hi, : > : > I'm writing a syscall module and he compiles well but at load time, kldload : > shows: : > : > KLD: program.ko: depends of kernel - no avaiable : > : > anyone know something about this? The problem here is that the kernel _FreeBSD_version was bumped and no longer matches. Jacky installed the kernel with version, say 800060, and then updated the source bases where it changed to 800061, built modules and tried to load them. Warner From avg at icyb.net.ua Thu Jan 29 03:47:41 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jan 29 03:47:49 2009 Subject: INTR_FILTER? Message-ID: <49819757.2010002@icyb.net.ua> INTR_FILTER - what does it do? It doesn't seem to be documented anywhere, but seems to affect interrupt code. -- Andriy Gapon From ed at 80386.nl Thu Jan 29 04:55:07 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Jan 29 04:55:14 2009 Subject: INTR_FILTER? In-Reply-To: <49819757.2010002@icyb.net.ua> References: <49819757.2010002@icyb.net.ua> Message-ID: <20090129125505.GA17198@hoeg.nl> * Andriy Gapon wrote: > INTR_FILTER - what does it do? > It doesn't seem to be documented anywhere, but seems to affect interrupt > code. Not sure, but I think I was once told that FreeBSD has a `two level' interrupt handling scheme, where the filter is invoked directly to only figure out whether the interrupt is spurious or not. After it has been determined it is not, an interrupt thread is scheduled to handle the interrupt. But as I said, I'm not sure. :-) -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090129/0229c8aa/attachment.pgp From avg at icyb.net.ua Thu Jan 29 04:58:47 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jan 29 04:58:53 2009 Subject: INTR_FILTER? In-Reply-To: <20090129125505.GA17198@hoeg.nl> References: <49819757.2010002@icyb.net.ua> <20090129125505.GA17198@hoeg.nl> Message-ID: <4981A7F1.1050709@icyb.net.ua> on 29/01/2009 14:55 Ed Schouten said the following: > * Andriy Gapon wrote: >> INTR_FILTER - what does it do? >> It doesn't seem to be documented anywhere, but seems to affect interrupt >> code. > > Not sure, but I think I was once told that FreeBSD has a `two level' > interrupt handling scheme, where the filter is invoked directly to only > figure out whether the interrupt is spurious or not. After it has been > determined it is not, an interrupt thread is scheduled to handle the > interrupt. > > But as I said, I'm not sure. :-) > This is true and is documented in bus_setup_intr(9). But INTR_FILTER is a compile-time kernel option. -- Andriy Gapon From ed at 80386.nl Thu Jan 29 06:36:07 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Jan 29 06:36:14 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090129151021.14131so3ozumpfj4@webmail.leidinger.net> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> <20090129151021.14131so3ozumpfj4@webmail.leidinger.net> Message-ID: <20090129143606.GC17198@hoeg.nl> * Alexander Leidinger wrote: > So you want that either > - a daemon running as root is written which listens to user > requests to set the backlight via sysctl > or > - a SUID root program is written that sets the backlight > via sysctl > instead of > - a character device with appropriate filesystem permissions > which allows to not go the SUID root or daemon running as > root way > ? Yes. The primary reason is that it is more consistent with the rest of the operating system. powerd also uses sysctl's instead of a character device, for example. The ideal solution would be to integrate it into vidcontrol, calling some kind of ioctl on the TTY/consolectl, but syscons is too brainless to know anything about hardware specific features. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090129/24a9e37d/attachment.pgp From Alexander at Leidinger.net Thu Jan 29 06:10:31 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Jan 29 06:36:51 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090128134309.GN17198@hoeg.nl> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> Message-ID: <20090129151021.14131so3ozumpfj4@webmail.leidinger.net> Quoting Ed Schouten (from Wed, 28 Jan 2009 14:43:09 +0100): > * Daniel Lannstrom wrote: >> > I'm asking which method will be the best to interface the driver with >> > userland applications? >> >> You might want to make it a character device driver. And write a small >> userland control program. Sysctl isn't really made for this kind of >> functionality. > > No. sysctl is good for doing stuff like this. An even better approach So you want that either - a daemon running as root is written which listens to user requests to set the backlight via sysctl or - a SUID root program is written that sets the backlight via sysctl instead of - a character device with appropriate filesystem permissions which allows to not go the SUID root or daemon running as root way ? Bye, Alexander. -- E.T. GO HOME!!! (And take your Smurfs with you.) http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From rpaulo at freebsd.org Thu Jan 29 09:17:30 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Thu Jan 29 09:17:37 2009 Subject: INTR_FILTER? In-Reply-To: <49819757.2010002@icyb.net.ua> References: <49819757.2010002@icyb.net.ua> Message-ID: <8F669786-30A2-458C-8A6B-3272297ADE14@freebsd.org> On 29 Jan 2009, at 11:47, Andriy Gapon wrote: > INTR_FILTER - what does it do? > It doesn't seem to be documented anywhere, but seems to affect > interrupt > code. INTR_FILTER allows you to skip the FILTER+ITHREAD headache. See dev/asmc/asmc.c for an example. -- Rui Paulo From avg at icyb.net.ua Thu Jan 29 09:51:21 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jan 29 09:51:28 2009 Subject: INTR_FILTER? In-Reply-To: <8F669786-30A2-458C-8A6B-3272297ADE14@freebsd.org> References: <49819757.2010002@icyb.net.ua> <8F669786-30A2-458C-8A6B-3272297ADE14@freebsd.org> Message-ID: <4981EC95.1090002@icyb.net.ua> on 29/01/2009 19:17 Rui Paulo said the following: > > On 29 Jan 2009, at 11:47, Andriy Gapon wrote: > >> INTR_FILTER - what does it do? >> It doesn't seem to be documented anywhere, but seems to affect interrupt >> code. > > INTR_FILTER allows you to skip the FILTER+ITHREAD headache. Could you please explain a little bit what is this headache? I thought, similarly to what Ed said, that in filter one could quickly check for a stray interrupt (or shared interrupt from other device) and in ithread one could perform meaningful work. But I also had some doubts about what is legal and what is illegal in ithread. E.g. could I take a non-spin mutex or wait on a condvar? I guess not - because in the case of shared interrupts the same ithread is used to handle everything. > See dev/asmc/asmc.c for an example. Thank you, the example is enlightening. But also one has to look into how "the framework" works (or just know it) to understand why things are done this way but not the other. E.g. why you have to use a taskqueue in non-INTR_FILTER case. BTW, INTR_FILTER seems quite useful. Why, then, it is not the default? -- Andriy Gapon From peterjeremy at optushome.com.au Thu Jan 29 10:44:08 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Jan 29 10:44:17 2009 Subject: critical floating point incompatibility In-Reply-To: <20090128192421.C9E3D5B13@mail.bitblocks.com> References: <20071220093950.GA79196@server.vk2pj.dyndns.org> <20071221181125.0B6F25B42@mail.bitblocks.com> <20071221201633.GM57756@deviant.kiev.zoral.com.ua> <200901261651.29116.jhb@freebsd.org> <20090128192421.C9E3D5B13@mail.bitblocks.com> Message-ID: <20090129184400.GI1755@server.vk2pj.dyndns.org> On 2009-Jan-28 11:24:21 -0800, Bakul Shah wrote: >On a mac, cc -m64 builds 64 bit binaries and cc -m32 builds >32 bit binaries. The following script makes it as easy to do >so on a 64 bit FreeBSD -- at least on the few programs I >tried. Ideally the right magic needs to be folded in gcc's >builtin "specs". > >#!/bin/sh >args=/usr/bin/cc >while [ ".$1" != . ] >do > a=$1; shift > case $a in > -m32) args="$args -B/usr/lib32 -I/usr/include32 -m32";; > *) args="$args $a";; > esac >done >$args You also need to manually populate /usr/include32 since it doesn't exist by default and may still get bitten by stuff in /usr/local/include. Do you have a script (or installworld patches) to do this? amd64/112215 includes a first attempt at updating the gcc specs (though it's missing the include handling), as well as some of the remaining problems. >Ideally x86_64 platforms run *all* i386 programs (that don't >depend on a 32 bit kernel). Agreed. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090129/e67c5450/attachment.pgp From rpaulo at gmail.com Thu Jan 29 09:16:36 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Thu Jan 29 11:19:03 2009 Subject: INTR_FILTER? In-Reply-To: <49819757.2010002@icyb.net.ua> References: <49819757.2010002@icyb.net.ua> Message-ID: On 29 Jan 2009, at 11:47, Andriy Gapon wrote: > INTR_FILTER - what does it do? > It doesn't seem to be documented anywhere, but seems to affect > interrupt > code. INTR_FILTER allows you to skip the FILTER+ITHREAD headache. See dev/asmc/asmc.c for an example. -- Rui Paulo From bakul at bitblocks.com Thu Jan 29 14:11:35 2009 From: bakul at bitblocks.com (Bakul Shah) Date: Thu Jan 29 14:11:42 2009 Subject: cc -m32 (was Re: critical floating point incompatibility In-Reply-To: Your message of "Fri, 30 Jan 2009 05:44:00 +1100." <20090129184400.GI1755@server.vk2pj.dyndns.org> References: <20071220093950.GA79196@server.vk2pj.dyndns.org> <20071221181125.0B6F25B42@mail.bitblocks.com> <20071221201633.GM57756@deviant.kiev.zoral.com.ua> <200901261651.29116.jhb@freebsd.org> <20090128192421.C9E3D5B13@mail.bitblocks.com> <20090129184400.GI1755@server.vk2pj.dyndns.org> Message-ID: <20090129221134.0EAA35B21@mail.bitblocks.com> On Fri, 30 Jan 2009 05:44:00 +1100 Peter Jeremy wrote: > > On 2009-Jan-28 11:24:21 -0800, Bakul Shah wrote: > >On a mac, cc -m64 builds 64 bit binaries and cc -m32 builds > >32 bit binaries. The following script makes it as easy to do > >so on a 64 bit FreeBSD -- at least on the few programs I > >tried. Ideally the right magic needs to be folded in gcc's > >builtin "specs". > > > >#!/bin/sh > >args=3D/usr/bin/cc > >while [ ".$1" !=3D . ] > >do > > a=3D$1; shift > > case $a in > > -m32) args=3D"$args -B/usr/lib32 -I/usr/include32 -m32";; > > *) args=3D"$args $a";; > > esac > >done > >$args > > You also need to manually populate /usr/include32 since it doesn't > exist by default and may still get bitten by stuff in > /usr/local/include. Do you have a script (or installworld patches) to > do this? Yes, includes for native programs will may cause trouble -- but you can't use -nostdinc (as that would take away that feature from a user), which is why this needs to be in the gcc specs. I don't have a script as I just copied include directories from a i386 system. But a script would be better. This script was an initial stab at proper -m32 support and needs more work. I will be happy to work with you or anyone else to make this happen. From rpaulo at freebsd.org Thu Jan 29 14:30:34 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Thu Jan 29 14:31:17 2009 Subject: INTR_FILTER? In-Reply-To: <4981EC95.1090002@icyb.net.ua> References: <49819757.2010002@icyb.net.ua> <8F669786-30A2-458C-8A6B-3272297ADE14@freebsd.org> <4981EC95.1090002@icyb.net.ua> Message-ID: On 29 Jan 2009, at 17:51, Andriy Gapon wrote: > on 29/01/2009 19:17 Rui Paulo said the following: >> >> On 29 Jan 2009, at 11:47, Andriy Gapon wrote: >> >>> INTR_FILTER - what does it do? >>> It doesn't seem to be documented anywhere, but seems to affect >>> interrupt >>> code. >> >> INTR_FILTER allows you to skip the FILTER+ITHREAD headache. > > Could you please explain a little bit what is this headache? Basically, you use filter + ithread (intr_filter) when you want to do more than basic things in your interrupt handler routine. For example, allocating memory must be done in a ithread, it can't be done on the interrupt routine. > I thought, similarly to what Ed said, that in filter one could quickly > check for a stray interrupt (or shared interrupt from other device) > and > in ithread one could perform meaningful work. That's right. But INTR_FILTER does all the filter + ithread setup for you via FILTER_SCHEDULE_THREAD. > But I also had some doubts about what is legal and what is illegal in > ithread. E.g. could I take a non-spin mutex or wait on a condvar? I > guess not - because in the case of shared interrupts the same > ithread is > used to handle everything. > >> See dev/asmc/asmc.c for an example. > > Thank you, the example is enlightening. But also one has to look into > how "the framework" works (or just know it) to understand why things > are > done this way but not the other. E.g. why you have to use a > taskqueue in > non-INTR_FILTER case. I needed a taskqueue because devctl_notify() calls malloc and you can't call malloc (which holds some type of lock, I can't remember) from an interrupt context (asmc_sms_intrfast()) > BTW, INTR_FILTER seems quite useful. Why, then, it is not the default? The drivers would have to be ported to INTR_FILTER. Right now, only asmc is using INTR_FILTER, so I don't think there is much gain in making it the default. -- Rui Paulo From ed at 80386.nl Fri Jan 30 00:44:23 2009 From: ed at 80386.nl (Ed Schouten) Date: Fri Jan 30 00:44:30 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090130085227.957230z897u8viww@webmail.leidinger.net> References: <20090130085227.957230z897u8viww@webmail.leidinger.net> Message-ID: <20090130084421.GO17198@hoeg.nl> * Alexander Leidinger wrote: >> The ideal solution would be to integrate it into vidcontrol, calling >> some kind of ioctl on the TTY/consolectl, but syscons is too brainless >> to know anything about hardware specific features. > > Here we are back to what was proposed instead of sysctl. I have to admin > that I'm confused now about what you propose as a good solution. Well, I wouldn't like it if we create character devices, just to let it implement a single ioctl() ("/dev/backlight", for example). There is only 1 parameter that's adjustable, namely the backlight intensity. A sysctl is a good place to store such things. In my opinion we should only use character devices for devices that have the semantics of a file descriptor, namely to read/write data to it, perform select(), etc. Saying sysctl is bad, because it doesn't allow any permissions should be considered to be a defect of sysctl, not an advantage of devfs. The reason why I prefer consolectl, is because it already exists and allows related graphics parameters to be configured. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090130/f6f5ed34/attachment.pgp From julian at elischer.org Fri Jan 30 01:53:49 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Jan 30 01:53:57 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090130084421.GO17198@hoeg.nl> References: <20090130085227.957230z897u8viww@webmail.leidinger.net> <20090130084421.GO17198@hoeg.nl> Message-ID: <4982C777.9030700@elischer.org> Ed Schouten wrote: > * Alexander Leidinger wrote: >>> The ideal solution would be to integrate it into vidcontrol, calling >>> some kind of ioctl on the TTY/consolectl, but syscons is too brainless >>> to know anything about hardware specific features. >> Here we are back to what was proposed instead of sysctl. I have to admin >> that I'm confused now about what you propose as a good solution. > > Well, I wouldn't like it if we create character devices, just to let it > implement a single ioctl() ("/dev/backlight", for example). There is > only 1 parameter that's adjustable, namely the backlight intensity. A > sysctl is a good place to store such things. I don't know.... you could flash morse code in response to a write. > > In my opinion we should only use character devices for devices that > have the semantics of a file descriptor, namely to read/write data to > it, perform select(), etc. Saying sysctl is bad, because it doesn't > allow any permissions should be considered to be a defect of sysctl, not > an advantage of devfs. > > The reason why I prefer consolectl, is because it already exists and > allows related graphics parameters to be configured. > From vasanth.raonaik at gmail.com Fri Jan 30 02:28:23 2009 From: vasanth.raonaik at gmail.com (vasanth raonaik) Date: Fri Jan 30 02:28:30 2009 Subject: telnetd[20170]: ttloop: peer died: Resource temporarily unavailable Message-ID: Hello Hackers, I am seeing this message continuously in syslog for every 60 secs. what could be the possible reasons for this error messages. Thanks, Vasanth From Alexander at Leidinger.net Thu Jan 29 23:52:46 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Jan 30 04:14:07 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090129143606.GC17198@hoeg.nl> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> <20090129151021.14131so3ozumpfj4@webmail.leidinger.net> <20090129143606.GC17198@hoeg.nl> Message-ID: <20090130085227.957230z897u8viww@webmail.leidinger.net> Quoting Ed Schouten (from Thu, 29 Jan 2009 15:36:06 +0100): > * Alexander Leidinger wrote: >> So you want that either >> - a daemon running as root is written which listens to user >> requests to set the backlight via sysctl >> or >> - a SUID root program is written that sets the backlight >> via sysctl >> instead of >> - a character device with appropriate filesystem permissions >> which allows to not go the SUID root or daemon running as >> root way >> ? > > Yes. The primary reason is that it is more consistent with the rest of > the operating system. powerd also uses sysctl's instead of a character > device, for example. Powerd does not interact with the user, it is doing automatic power management. A backlight on the other hand needs to be adjustable by the user. Normally I would expect some keys on the keyboard to handle this, so there should be no need to have some userland stuff, but as I don't know about how Apple is doing this, I assume there's some valid reason to handle it from userland. But then there needs to be some easy way to let an user handle it, even if you are on the console. A separate daemon or a SUID root program to control the backlight sounds like overkill to me. > The ideal solution would be to integrate it into vidcontrol, calling > some kind of ioctl on the TTY/consolectl, but syscons is too brainless > to know anything about hardware specific features. Here we are back to what was proposed instead of sysctl. I have to admin that I'm confused now about what you propose as a good solution. Bye, Alexander. -- If I had any humility I would be perfect. -- Ted Turner http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From p.pisati at oltrelinux.com Fri Jan 30 05:26:00 2009 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Fri Jan 30 05:26:06 2009 Subject: INTR_FILTER? In-Reply-To: <49819757.2010002@icyb.net.ua> References: <49819757.2010002@icyb.net.ua> Message-ID: <4982FBC7.1080100@oltrelinux.com> Andriy Gapon wrote: > INTR_FILTER - what does it do? > It doesn't seem to be documented anywhere, but seems to affect interrupt > code. > > for a bit more information about interrupt filtering, see here: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019704.html -- bye, P. From laladelausanne at gmail.com Fri Jan 30 09:11:58 2009 From: laladelausanne at gmail.com (=?UTF-8?Q?Nikola_Kne=C5=BEevi=C4=87?=) Date: Fri Jan 30 09:12:05 2009 Subject: blockable sleep lock (sleep mutex) 16 Message-ID: <02026848-7F83-405C-B4F3-EDD8B47DA294@gmail.com> Hi, I'm trying to port Click modular router to FreeBSD 7.1, but with a twist. Instead of letting Click run in netisr (as it used to run in FreeBSD 4), I want to have it running in a kthread. I managed to get it running this way, but when I turn on INVARIANTS and WITNESS (along with WITNESS_SKIPSPIN), I get coredumps when I'm trying to install a new configuration... Here is the trace: ---8<--- (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xffffffff8049ef98 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:418 #2 0xffffffff8049f429 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xffffffff804d941c in witness_checkorder (lock=0xffffff0007fdfc50, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/subr_witness.c:877 #4 0xffffffff80493769 in _mtx_lock_flags (m=0xffffff0007fdfc50, opts=0, file=0xffffffff8085536f "/usr/src/sys/vm/uma_core.c", line=1834) at /usr/src/sys/kern/kern_mutex.c:183 #5 0xffffffff806a6aab in uma_zalloc_arg (zone=0xffffff0007fde9c0, udata=0x0, flags=2) at /usr/src/sys/vm/uma_core.c:1834 #6 0xffffffff804908c6 in malloc (size=Variable "size" is not available. ) at uma.h:277 #7 0xffffffff877579bd in operator new[] (sz=Variable "sz" is not available. ) at /home/knl/work/mx/click/bsdmodule/..//lib/glue.cc:285 #8 0xffffffff877856d3 in ?? () #9 0xffffffff8785d540 in ?? () #10 0xffffffff8785d610 in ?? () #11 0x0000000000000000 in ?? () #12 0xffffff0001353300 in ?? () #13 0xffffffff8785d580 in ?? () #14 0xffffffff87777afa in Click::ClickInstance::element_hindexes (this=0x4, result=@0xffffffff8785d610) at vector.hh:96 Previous frame identical to this frame (corrupt stack?) --->8--- This is the message buffer: Unread portion of the kernel message buffer: panic: blockable sleep lock (sleep mutex) 16 @ /usr/src/sys/vm/ uma_core.c:1834 cpuid = 0 Uptime: 24m35s Physical memory: 114 MB Dumping 42 MB: 27 11 Any hints where I should search for the cause? I'm using MTX_DEF mutexes to protect data structures. Click exports its own FS, where each element (part of the router) has its own files. Each file has coresponding function which is responsible for input/ output of the data. So, when I want to create a new router, I write to file named "config". Then, function named write_config takes over, starts the Lexer, which in turns produces elements, which then export their representations in the VFS. All of this happens in the clickfs_close (creation starts when file is closed). If I read the code correctly, vn_closefile locks the Giant, so that may cause problems... Cheers, N. From matthew.fleming at isilon.com Fri Jan 30 09:53:50 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Fri Jan 30 10:08:34 2009 Subject: Dynamic ddb commands Message-ID: <1233337318.13748.101.camel@amaretto> I'm working on BSD 6.x and of course the set of ddb commands is static to whatever is in the kernel at compile. I see that BSD 7.1 has dynamic commands using sysinits and sysuninit's to call a new db_[un]register_cmd. I see this, though, only after I have spent a day or so adding a linker_file_[un]register_ddb() that works similarly to how sysinits are merged for the boot-time modules (malloc and copy pointers). It seems to me that this solution (have the linker look for db_set and db_cmd_set and, if there are any entries, malloc and save pointers to commands) is more efficient in terms of space than adding a LIST to the command structure and then forcing sysinits to run. I'm curious as to why the current method was chosen when something lighter-weight was available... or so it seems from my perspective looking at the 6.x code base. As another side note, lexicographic order for the commands doesn't seem to add anything, except that command insert/delete are O(n/2) instead of O(n). It can make it harder to use ddb to debug ddb, though. If, e.g. there's a pointer problem somewhere in the command list, if the most basic commands are up front like examine and write, then at least those can be used to possibly repair ddb so a debug session can continue. Just wondering things. Thanks, matthew From matthew.fleming at isilon.com Fri Jan 30 10:24:49 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Fri Jan 30 10:24:56 2009 Subject: Dynamic ddb commands In-Reply-To: <1233337318.13748.101.camel@amaretto> References: <1233337318.13748.101.camel@amaretto> Message-ID: <1233339897.13748.106.camel@amaretto> Just an addenda: > I see that BSD 7.1 has dynamic commands using sysinits and sysuninit's to call a new > db_[un]register_cmd. I was looking at HEAD, not RELENG_7_1. The remainder of my questions as to why this mechanism are the same, though. Thanks, matthew From sam at freebsd.org Fri Jan 30 10:29:37 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri Jan 30 10:29:48 2009 Subject: Dynamic ddb commands In-Reply-To: <1233337318.13748.101.camel@amaretto> References: <1233337318.13748.101.camel@amaretto> Message-ID: <49834710.9070908@freebsd.org> Matthew Fleming wrote: > I'm working on BSD 6.x and of course the set of ddb commands is static > to whatever is in the kernel at compile. I see that BSD 7.1 has dynamic > commands using sysinits and sysuninit's to call a new > db_[un]register_cmd. > > I see this, though, only after I have spent a day or so adding a > linker_file_[un]register_ddb() that works similarly to how sysinits are > merged for the boot-time modules (malloc and copy pointers). It seems > to me that this solution (have the linker look for db_set and db_cmd_set > and, if there are any entries, malloc and save pointers to commands) is > more efficient in terms of space than adding a LIST to the command > structure and then forcing sysinits to run. > I haven't looked at your approach so not sure how to respond. The existing code was simple. > I'm curious as to why the current method was chosen when something > lighter-weight was available... or so it seems from my perspective > looking at the 6.x code base. > > As another side note, lexicographic order for the commands doesn't seem > to add anything, except that command insert/delete are O(n/2) instead of > O(n). It can make it harder to use ddb to debug ddb, though. If, e.g. > there's a pointer problem somewhere in the command list, if the most > basic commands are up front like examine and write, then at least those > can be used to possibly repair ddb so a debug session can continue. > > If I recall it was painful to find entries in the help listing w/o sorting. Feel free to propose an alternative implementation; noone's wed to what's in the tree. Sam From assaulter0x80 at gmail.com Fri Jan 30 11:25:35 2009 From: assaulter0x80 at gmail.com (Jacky Oh) Date: Fri Jan 30 11:25:42 2009 Subject: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: <20090128.223315.1447365184.imp@bsdimp.com> References: <20090129045304.GA18493@debian.samsung.router> <20090128.223315.1447365184.imp@bsdimp.com> Message-ID: Hi Warner.. Can the solution become the source tree updates to the same version of my installed kernel? Sorry for my irregular-time questions and responses but currently i cannot access to inet.. It's really difficult for me becouse I don't put instant solution for my systems and my case of study problems...I try to resolve the problem if the source tree is it fails.. anyway, thanks very much.. From imp at bsdimp.com Fri Jan 30 11:36:16 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 30 11:36:22 2009 Subject: KLD: program.ko: depends of kernel - no avaiable In-Reply-To: References: <20090129045304.GA18493@debian.samsung.router> <20090128.223315.1447365184.imp@bsdimp.com> Message-ID: <20090130.123330.2025563190.imp@bsdimp.com> In message: Jacky Oh writes: : Can the solution become the source tree updates to the same version of my : installed kernel? Sorry for my irregular-time questions and responses but : currently i cannot access to inet.. It's really difficult for me becouse I : don't put instant solution for my systems and my case of study problems...I : try to resolve the problem if the source tree is it fails.. The solution is to rebuild the kernel and the modules, install them and reboot. Warner From matthew.fleming at isilon.com Fri Jan 30 11:44:15 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Fri Jan 30 11:44:35 2009 Subject: Dynamic ddb commands In-Reply-To: <49834710.9070908@freebsd.org> References: <1233337318.13748.101.camel@amaretto> <49834710.9070908@freebsd.org> Message-ID: <1233344663.13748.120.camel@amaretto> > If I recall it was painful to find entries in the help listing w/o sorting. So it's a human reading problem, where ddb spat out the command names in order that they were in the in-memory struct, and if I wanted to look over the listing I had to visually scan every one since they weren't in order? > Feel free to propose an alternative implementation; noone's wed to > what's in the tree. Here's a patch for 6.x. The display order for the commands is an interesting issue; it would also make sense to group commands (perhaps alphabetically) by the module that defined them, so that when I added a module all my ddb commands stayed together. The patch I have here will leave commands grouped by module, so it would be relatively trivial to have linker_file_register_ddb add a new kind of dummy command that specifies the module name for the following set of commands. N.B. It appears from the FAQ that attachments are acceptable so I'm sending the patch as an attachment. Apologies if this is incorrect. Thanks, matthew -------------- next part -------------- A non-text attachment was scrubbed... Name: ddb.diff Type: text/x-patch Size: 16946 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090130/c12eec04/ddb.bin From rpaulo at freebsd.org Sat Jan 31 08:31:44 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Sat Jan 31 08:31:52 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090130085227.957230z897u8viww@webmail.leidinger.net> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> <20090129151021.14131so3ozumpfj4@webmail.leidinger.net> <20090129143606.GC17198@hoeg.nl> <20090130085227.957230z897u8viww@webmail.leidinger.net> Message-ID: <508FD1E6-8281-4C9E-A495-AE435447C636@freebsd.org> On 30 Jan 2009, at 07:52, Alexander Leidinger wrote: > Quoting Ed Schouten (from Thu, 29 Jan 2009 15:36:06 > +0100): > >> * Alexander Leidinger wrote: >>> So you want that either >>> - a daemon running as root is written which listens to user >>> requests to set the backlight via sysctl >>> or >>> - a SUID root program is written that sets the backlight >>> via sysctl >>> instead of >>> - a character device with appropriate filesystem permissions >>> which allows to not go the SUID root or daemon running as >>> root way >>> ? >> >> Yes. The primary reason is that it is more consistent with the rest >> of >> the operating system. powerd also uses sysctl's instead of a >> character >> device, for example. > > Powerd does not interact with the user, it is doing automatic power > management. A backlight on the other hand needs to be adjustable by > the user. > > Normally I would expect some keys on the keyboard to handle this, so > there should be no need to have some userland stuff, but as I don't > know about how Apple is doing this, I assume there's some valid > reason to handle it from userland. But then there needs to be some > easy way to let an user handle it, even if you are on the console. A > separate daemon or a SUID root program to control the backlight > sounds like overkill to me. Well, easy: only let the operator group change the sysctl and add your appropriate user accounts to the operator group. No daemon is needed. This is what I thought about when doing the Intel backlight driver, but I never actually did it. Regards, -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090131/952237fe/PGP.pgp From rpaulo at gmail.com Sat Jan 31 08:31:00 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Sat Jan 31 08:36:19 2009 Subject: Mackbook pro nvidia based video backlight In-Reply-To: <20090130085227.957230z897u8viww@webmail.leidinger.net> References: <20090127124137.46fcfac5@baby-jane.lamaiziere.net> <20090127150040.GA4333@haruhi> <20090128134309.GN17198@hoeg.nl> <20090129151021.14131so3ozumpfj4@webmail.leidinger.net> <20090129143606.GC17198@hoeg.nl> <20090130085227.957230z897u8viww@webmail.leidinger.net> Message-ID: <76ADC89F-EFAC-4F45-A0B7-FA58470018DF@gmail.com> On 30 Jan 2009, at 07:52, Alexander Leidinger wrote: > Quoting Ed Schouten (from Thu, 29 Jan 2009 15:36:06 > +0100): > >> * Alexander Leidinger wrote: >>> So you want that either >>> - a daemon running as root is written which listens to user >>> requests to set the backlight via sysctl >>> or >>> - a SUID root program is written that sets the backlight >>> via sysctl >>> instead of >>> - a character device with appropriate filesystem permissions >>> which allows to not go the SUID root or daemon running as >>> root way >>> ? >> >> Yes. The primary reason is that it is more consistent with the rest >> of >> the operating system. powerd also uses sysctl's instead of a >> character >> device, for example. > > Powerd does not interact with the user, it is doing automatic power > management. A backlight on the other hand needs to be adjustable by > the user. > > Normally I would expect some keys on the keyboard to handle this, so > there should be no need to have some userland stuff, but as I don't > know about how Apple is doing this, I assume there's some valid > reason to handle it from userland. But then there needs to be some > easy way to let an user handle it, even if you are on the console. A > separate daemon or a SUID root program to control the backlight > sounds like overkill to me. Well, easy: only let the operator group change the sysctl and add your appropriate user accounts to the operator group. No daemon is needed. This is what I thought about when doing the Intel backlight driver, but I never actually did it. Regards, -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090131/b42aef0d/PGP.pgp