Re: Writing a (BSD like) Operating Systems From Scratch
On 05/25/13 06:44, Welcome, Traiano wrote: a) What kind of hardware (processor) would I use as a development platform, given the requirements of cheap, well documented, easily obtainable, easy to debug etc ... I believe the hardware platform chosen should satisfy the following requirements: any except PCs unless you will like to deal with CPU and other (over)complexity. Exactly my thinking. Most of the online links to operating system development involve x86 hardware, although more and more Microcontrollers are appearing for embedded market with features that previously only existed in mainstream microprocessors. Ideally, the platform I'd choose would have a small enough instruction set to learn (small relative to Intel's mainstream processors), maybe something like the ARM processor used on Raspberry Pi, or Zilog's ez80 Acclaim series. In that case, why not look at some of the Microchip's PIC32 development suites. There are quite a few options from Microchip, their dev hardware is not that expensive and could prove as a good starting point Looking at their site, dev kit DM320015 has a microcontroller, 4.3" WQVGA screen, capacitive touch screen and USB OTG all built on one unit Or maybe DM320004 + DM320002 + other modules would give a nice platform (microcontroller, serial, ethernet, SD socket, wireless interface etc) (as a side note) I have the DM320004 (uC board), DM320002 (backplane), AC164122 (SD card adapter), AC164129 (Audio adapter) and AC164126 (breadboards) They have loads of source code available, so you could use that as a starting point, then go on to writing everything your self, including a kernel with a full GUI and touchscreen control if you so wish. Or, why not try a MaxiMite unit (http://geoffg.net/maximite.html). The schematics are available on the website and the PCBs should be available (with all combinations from blank PCB to fully populated) But remember, there are a thousand ways to skin a cat and this is just one... Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
GSoC proposal review
Hi, Can somebody review my proposal here and see if it can be further improved? http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/rushilpaul/12001 -- Regards, Rushil ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: considering i386 as a tier 1 architecture
On Tue, Apr 02, 2013 at 10:22:20AM +, Ruben de Groot wrote: > On Tue, Apr 02, 2013 at 03:10:56AM -0700, Mehmet Erol Sanliturk typed: > > On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm??rgrav wrote: > > > > > Wojciech Puchar writes: > > > > Lev Serebryakov writes: > > > > > It is not exact so. Some Atoms on some motherboards with some > > > > > firmwares are 64-bit CPU. > > > > don't know of any now in shops that are not > > > > > > http://soekris.com/products/net5501.html > > > http://soekris.com/products/net6501.html > > > > > > DES > > > -- > > > Dag-Erling Sm??rgrav - d...@des.no > > > > > > > > > I am NOT able to understand the merit of these products with respect to > > their features and PRICES . > > They are extremely stable and robust. > > > It is possible to assemble much more cheaper full featured PC like systems > > ( DDR3 memory , 64-bit capable processors , with a disadvantage about power > > requirements ) . > > You can also get much bigger portions at MacDonald than what you get in a > five star restaurant. Soekris boards are perhaps not five star boards but at least they have four :) Although the thread started as an april fools day prank, it's getting serious now about the value of having i386 next to amd64. I'm using quite a number of net4501/net4801/net5501/net6501 in many places just because I haven't found anything that can to the same job with the same reliability at the same low power diet for a reasonable price. For people on a tight budget with lower reliability expectations there are the PC-engines Alix boards. Except for the net6501, none of these can run amd64. Even though the net6501 can run amd64, I prefer running i386 on them (and other boards where I do not need >= 4GB of RAM or the large address space) instead of amd64 just because the system image is so much smaller, requiring less storage on your filesystem (often a small flash device), less time to upload changes over the Internet when doing remote upgrades and they are more efficient with virtual memory. Running amd64 when not really needed is just a waste of resources. There have been discussions in the past whether is would make sense to run a 32-bit userland on top of a amd64 kernel sou you can have >4GB of RAM but keep your userland relatively small. There are only few applications that really benefit from 64 bit address space, others could well be 32 bit apps. Just some random numbers to illustrate my point: i386$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc textdata bss dec hex filename 11153310487460 120041 1d4e9 /bin/sh 22808 572 396 237765ce0 /bin/ls 33098 7603392 372509182 /usr/bin/find 3148419376 18204 342421 53995 /usr/bin/cc amd64$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc textdata bss dec hex filename 1293711992 10272 141635 22943 /bin/sh 262551144 536 279356d1f /bin/ls 4346413524680 49496c158 /usr/bin/find 383330 15296 58664 457290 6fa4a /usr/bin/cc Kind regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
syscalls per process ?
Hi,
At the start of all our programs, we set up a SIGALRM signal handler
to retrieve rusage stats each second and log this info for analysis.
It is useful for long running programs. One of the things we
would really really like to get is the number of system calls the
process has performed.
Is there a simple way for a process to retrieve its own number of
syscalls it has performed ? Pity it's not available via getrusage().
We don't want to run an external program (eg. truss/dtrace) on each
program.
Paul.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
IPMI console [Re: Chicken and egg, encrypted root FS on remote server]
Hi Daniel, On Wed, Feb 20, 2013 at 10:55:47PM +1030, Daniel O'Connor wrote: > > On 20/02/2013, at 21:43, Paul Schenkeveld wrote: > >> What about getting a remote console like HP's ILO or Dell's DRAC ? > >> > >> You get to login remotely, you can use some degree of access control... > >> you can even remote boot. > > > > For new hardware I could indeed use this, the current hardware does not > > support remote console. > > > > I don't have experience with ILO nor DRAC but I do have experience with > > SuperMicro's KVM over LAN which does need a java client to run. If I can > > enter the passphrase over ssh that would be better as I can use any device > > including a smartphone to dial in and enter the passphrase. > > > If you setup a serial console you don't need Java if you use ipmitool, eg > ipmitool -H remoteip -U ADMIN -I lanplus sol activate Tried that with some Supermicro servers, the serial console allows me to get into BIOS config and shows boot messages up to starting the kernel, once the kernel starts output stops. In the BIOS setup, console redirect defaults to com2 port which explains why output stops after the loader passes control to the kernel. BTW, ipmitool always gives me "Info: cannot activate SOL payload with encryption" but ipmi-console (sysutils/freeipmi) works. If I change the console redirect to com1, my screen stays blank. Would you perhaps know how to use com1 for redirect and connect to it using ipmi-console (or ipmi-tool)? Thanks, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Chicken and egg, encrypted root FS on remote server
On Wed, Feb 20, 2013 at 09:47:36AM +0100, Damien Fleuriot wrote: > > On 20 Feb 2013, at 08:46, Paul Schenkeveld wrote: > > > On Wed, Feb 20, 2013 at 02:42:57AM -0500, Jason Hellenthal wrote: > >> Just a thought with no working example but⦠> >> > >> bootp / tftp - from a remote secured management frame to TX a key > >> filesytem to unlock your rootfs. > >> > >> Could be something as simple as a remote wireless adhoc server with a 64GB > >> thumbdrive to hold your data or just enough to tell the system where to > >> get it. > >> > >> Considering a key can be any length string of a sort just to say but... > >> Serve the rootfs key directly from a TXT out of a secured DNS zone only > >> visible to so said machines. > > > > Thank you but manual entry of the passprase is a prerequisite here so > > serving the key automatically is not an option. > > > > With kind regards, > > > > Paul Schenkeveld > > > > What about getting a remote console like HP's ILO or Dell's DRAC ? > > You get to login remotely, you can use some degree of access control... you > can even remote boot. For new hardware I could indeed use this, the current hardware does not support remote console. I don't have experience with ILO nor DRAC but I do have experience with SuperMicro's KVM over LAN which does need a java client to run. If I can enter the passphrase over ssh that would be better as I can use any device including a smartphone to dial in and enter the passphrase. Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Chicken and egg, encrypted root FS on remote server
On Wed, Feb 20, 2013 at 07:58:10AM +0100, Paul Schenkeveld wrote: > Hi, > > I've been trying to find a solution for this chicken and egg problem, > how to have an encrypted root filesystem on a remote server. > > Geli can ask for a root password at the console to unlock the root fs > but that of course won't work for a remote server. > > Ideally I'd like the server to start, do minimal network config, run > a minimal ssh client (dropbear?) and wait for someone to log in, > provide the passphrase to unlock the root filesystem and then mount > the root filesystem and do a normal startup. > > I read about a pivotroot call in other OS-es, that would allow for a > very small unencrypted root filesystem to be mounted temporarily until > the passphrase has been entered and then swap that for a real, encrypted > root filesystem. But AFAIK we don't have pivotroot. > > The problem could also be solved if the real root fs could be union > mounted over the small unencrypted one but unionfs won't mount over /. Why is it that I cannot union mount anything over /, is there a technical reason for that or is it because of security concerns? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Chicken and egg, encrypted root FS on remote server
On Wed, Feb 20, 2013 at 02:42:57AM -0500, Jason Hellenthal wrote: > Just a thought with no working example but⦠> > bootp / tftp - from a remote secured management frame to TX a key filesytem > to unlock your rootfs. > > Could be something as simple as a remote wireless adhoc server with a 64GB > thumbdrive to hold your data or just enough to tell the system where to get > it. > > Considering a key can be any length string of a sort just to say but... Serve > the rootfs key directly from a TXT out of a secured DNS zone only visible to > so said machines. Thank you but manual entry of the passprase is a prerequisite here so serving the key automatically is not an option. With kind regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Chicken and egg, encrypted root FS on remote server
On Wed, Feb 20, 2013 at 09:14:22AM +0200, Alexander Yerenkow wrote: > 2013/2/20 Paul Schenkeveld > > > Hi, > > > > I've been trying to find a solution for this chicken and egg problem, > > how to have an encrypted root filesystem on a remote server. > > > > Geli can ask for a root password at the console to unlock the root fs > > but that of course won't work for a remote server. > > > > Ideally I'd like the server to start, do minimal network config, run > > a minimal ssh client (dropbear?) and wait for someone to log in, > > provide the passphrase to unlock the root filesystem and then mount > > the root filesystem and do a normal startup. > > > > I read about a pivotroot call in other OS-es, that would allow for a > > very small unencrypted root filesystem to be mounted temporarily until > > the passphrase has been entered and then swap that for a real, encrypted > > root filesystem. But AFAIK we don't have pivotroot. > > > > The problem could also be solved if the real root fs could be union > > mounted over the small unencrypted one but unionfs won't mount over /. > > > > I found out that a ZFS pool where a specific dataset has the > > mountpoint=/ option set can be used to 'buri' the unencrypted root under > > the real root but that would render the unencrypted one unchangable > > after the real one is mounted (prohibiting sysadmin to change the ssh > > credentials or network config there). It would also make maintenance > > a bit more difficult because an import of the zpool would automatically > > remount /, even when running from a cd-rom or USB stick. And of course > > this approach would not work in non-zfs environments (like very small > > systems). > > > > Looking at sys/kern/init_main.c and sys/kern/vfs_mount.c I could > > imagine having a kind of "pre root environment", an unencrypted root > > that gets mounted first (along with a devfs) and a /sbin/init that > > sets up minimal networking and runs sshd. Aftre that one dies the > > unencrypted root and devfs would be unmounted, the real root mounted > > and the real /sbin/init started. But this may be a considered a dirty > > approach. > > > > Did I miss the obvious and easy solution? Any ideas? > > > > I'd like to propose you to see my similar setup - it's used for VMs. > Idea is to have base OS in little partition, and use it only in RO. > All data, and configs goes in different partitions, which could be > connected manually or automatically. So far, I've done something similar using the nanobsd(8) framework. Disadvantage is that usually /etc is either part of the root filesystem or a md(4) filesystem (like the diskless framework and nanobsd use). Another disadvantage is that upgrades to the root filesystem (installworld, installkernel) do not work out of the box. I was hoping to get closer to a 'normal' installation for certain servers I maintain. My ramblings about using nanobsd for servers can be found here: http://www.psconsult.nl/talks/AsiaBSDcon2010-Servers/ > What you need is to specify in loader.conf > init_script="/etc/find-rwfs.sh" Hey, this one is new to me. Very interesting, won't solve this problem but would allow things like having /etc on a separate filesystem and things like that. > My example: > https://github.com/yerenkow/freebsd-vm-image/blob/master/freebsd-firmware/find-rwfs.sh Interesting. > In this way, you can get RO booted OS, just waited for you to login and > mount all required data. > > Also, you could contact Andriy Gapon, he managed to do other trick - boot > from RO media such as CD, and run all OS as chroot, all transparently. Thought about the chroot trick too but prefer to stay away from chroot if possible. > Hope this helps! With kind regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Chicken and egg, encrypted root FS on remote server
Hi, I've been trying to find a solution for this chicken and egg problem, how to have an encrypted root filesystem on a remote server. Geli can ask for a root password at the console to unlock the root fs but that of course won't work for a remote server. Ideally I'd like the server to start, do minimal network config, run a minimal ssh client (dropbear?) and wait for someone to log in, provide the passphrase to unlock the root filesystem and then mount the root filesystem and do a normal startup. I read about a pivotroot call in other OS-es, that would allow for a very small unencrypted root filesystem to be mounted temporarily until the passphrase has been entered and then swap that for a real, encrypted root filesystem. But AFAIK we don't have pivotroot. The problem could also be solved if the real root fs could be union mounted over the small unencrypted one but unionfs won't mount over /. I found out that a ZFS pool where a specific dataset has the mountpoint=/ option set can be used to 'buri' the unencrypted root under the real root but that would render the unencrypted one unchangable after the real one is mounted (prohibiting sysadmin to change the ssh credentials or network config there). It would also make maintenance a bit more difficult because an import of the zpool would automatically remount /, even when running from a cd-rom or USB stick. And of course this approach would not work in non-zfs environments (like very small systems). Looking at sys/kern/init_main.c and sys/kern/vfs_mount.c I could imagine having a kind of "pre root environment", an unencrypted root that gets mounted first (along with a devfs) and a /sbin/init that sets up minimal networking and runs sshd. Aftre that one dies the unencrypted root and devfs would be unmounted, the real root mounted and the real /sbin/init started. But this may be a considered a dirty approach. Did I miss the obvious and easy solution? Any ideas? With kind regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS1 vs UFS2
On Sun, Dec 30, 2012 at 09:29:27PM +0100, Wojciech Puchar wrote: > > > > I don't think performance will be much different but if so, UFS1 would > > be (sightly) faster than UFS2 because one page read will get more inodes > > from disk and 32 bit (UFS1) arithmetic may be slightly faster than 64 bit > > (UFS2). > > thanks for answer i was looking for! i will rebuild FS to UFS1, saving ca > 1GB for inodes. Also, look at the -i option of newfs, for many purposes the default number of inodes it allocates is far more than sufficient > > If performance is an issue, consider turning off atime updates or even > > mount the filesystem read-only if possible. > i always turn off atime and use softupdates. > > it cannot be readonly. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS1 vs UFS2
On Sun, Dec 30, 2012 at 08:42:27PM +0100, Wojciech Puchar wrote: > > It makes perfect sense to use UFS1 on systems where space savings matter > > unless your application requires any of the new features that are not > > present in UFS1. > > > > Nanobsd(8) for example uses UFS1 by default too. > thank you for answering. i don't need any new extra features, just plain > filesystem on 60GB filesystem. But question is - will performance be the > same, slower or faster? I don't think performance will be much different but if so, UFS1 would be (sightly) faster than UFS2 because one page read will get more inodes from disk and 32 bit (UFS1) arithmetic may be slightly faster than 64 bit (UFS2). If performance is an issue, consider turning off atime updates or even mount the filesystem read-only if possible. HTH Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UFS1 vs UFS2
On Sun, Dec 30, 2012 at 02:21:26PM +0100, Wojciech Puchar wrote: > OpenBSD by default use UFS1 for partitions smaller than 1TB. > > FreeBSD use always UFS2. UFS2 uses double the amount of space for inodes. > basic operation seems the same. > > Does it make sense to use UFS1 for small filesystem (on SSD) that would > have few millions of files. It will take less space for inodes, but how > about performance? UFS2 became necessary when disk got bigger and sizes and block pointers in metadata on UFS1 became too small to fully utilize the larger disks. Because of the larger sizes and pointers UFS2 broke binary compatibility with UFS1 unavoidably, the switch to UFS2 opened the way for other binary incompatilble enhancements to the file system like inode birth times and extended attributes (used by ACL's for example). It makes perfect sense to use UFS1 on systems where space savings matter unless your application requires any of the new features that are not present in UFS1. Nanobsd(8) for example uses UFS1 by default too. HTH Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD Kernel Internals, lecture video
On Mon, Aug 27, 2012 at 09:49:58AM +0200, Matthias Apitz wrote: > El día Sunday, August 26, 2012 a las 02:25:57PM +0100, Chris Rees escribió: > > > On 26 Aug 2012 13:15, "Wojciech Puchar" > > wrote: > > > > > > very expensive.. > > > > Training and education generally are. > > Agreed, if the goal is commercial. But I do not know if this price > invites are people who want to start digging into the FreeBSD kernel to > take over volunteer work there and help FreeBSD growing. Kirk often teaches 1-day or 2-day courses at BSD conferences at a very reasonable price, especially for people working or wanting to work as volunteers for FreeBSD, NetBSD and OpenBSD. Your next opportunity is the EuroBSDcon 2012 conference in Warsaw, Poland where Kirk teaches on friday October 19, 2012: http://www.eurobsdcon.org/ > matthias With kind regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Kernel thread stack size
Could you be more specific about "inefficient"？ 在 2012-7-25 上午11:22，"Warner Losh" 写道： > > > On Jul 24, 2012, at 6:40 PM, Paul Ambrose wrote: > > > #define PAGE_SHIFT 12 > > #define PAGE_SIZE (1< > > > #define KSTACK_PAGES 2 > > #define KSTACK_GUARD_PAGES 2 > > > > I had a MIPS machine (Loongson 3A) with page size 16KB( could be 4KB, but > > had to handle cache alias in OS), IMHO, define KSTACK_PAGE to 1 is enough, > > what is your opinion? > > Well, the PTE has two entries, so having just one page would be inefficient. > > Warner > > > 2012/7/23 Konstantin Belousov > > > >> On Mon, Jul 23, 2012 at 02:54:30AM -0400, Richard Yao wrote: > >>> What is the default kernel thread stack size on FreeBSD? I am > >>> particularly interested in knowing about i386 and amd64, but knowing > >>> this for other architectures (such as MIPS) would also be useful. > >>> > >> > >> Look for the KSTACK_PAGES symbol defined in sys//include/param.h. > >> It defines _default_ number of pages allocated for kernel stack of > >> new thread. > >> > >> We have 4 pages for amd64, and 2 pages for i386, AFAIR. Look up the MIPS > >> yourself. > >> > > ___ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " freebsd-hackers-unsubscr...@freebsd.org" > could you be more specific about "inefficient"？ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Kernel thread stack size
#define PAGE_SHIFT 12 #define PAGE_SIZE (1< > On Mon, Jul 23, 2012 at 02:54:30AM -0400, Richard Yao wrote: > > What is the default kernel thread stack size on FreeBSD? I am > > particularly interested in knowing about i386 and amd64, but knowing > > this for other architectures (such as MIPS) would also be useful. > > > > Look for the KSTACK_PAGES symbol defined in sys//include/param.h. > It defines _default_ number of pages allocated for kernel stack of > new thread. > > We have 4 pages for amd64, and 2 pages for i386, AFAIR. Look up the MIPS > yourself. > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kqueue periodic timer confusion
On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
> > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
> >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> >> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> >> >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> >> >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> >> >> > > > Hi,
> >> >> > > >
> >> >> > > > Sorry about this repost but I'm confused about the responses I
> >> >> > > > received
> >> >> > > > in my last post so I'm looking for some clarification.
> >> >> > > >
> >> >> > > > Specifically, I though I could use the kqueue timer as
> >> >> > > > essentially a
> >> >> > > > "drop in" replacement for linuxfd_create/read, but was surprised
> >> >> > > > that
> >> >> > > > the accuracy of the kqueue timer is much less than what I need
> >> >> > > > for my
> >> >> > > > application.
> >> >> > > >
> >> >> > > > So my confusion at this point is whether this is consider to be a
> >> >> > > > bug or
> >> >> > > > "feature"?
> >> >> > > >
> >> >> > > > Here's some test code if you want to verify the problem:
> >> >> > > >
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > >
> >> >> > > > int
> >> >> > > > main(void)
> >> >> > > > {
> >> >> > > > int i,msec;
> >> >> > > > int kq,nev;
> >> >> > > > struct kevent inqueue;
> >> >> > > > struct kevent outqueue;
> >> >> > > > struct timeval start,end;
> >> >> > > >
> >> >> > > > if ((kq = kqueue()) == -1) {
> >> >> > > > fprintf(stderr, "kqueue error!? errno = %s",
> >> >> > strerror(errno));
> >> >> > > > exit(EXIT_FAILURE);
> >> >> > > > }
> >> >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0,
> >> >> > > > 20, 0);
> >> >> > > >
> >> >> > > > gettimeofday(&start, 0);
> >> >> > > > for (i = 0; i < 50; i++) {
> >> >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1,
> >> >> > > > NULL)) ==
> >> >> > -1) {
> >> >> > > > fprintf(stderr, "kevent error!? errno =
> >> >> > > > %s",
> >> >> > strerror(errno));
> >> >> > > > exit(EXIT_FAILURE);
> >> >> > > > } else if (outqueue.flags & EV_ERROR) {
> >> >> > > > fprintf(stderr, "EV_ERROR: %s\n",
> >> >> > strerror(outqueue.data));
> >> >> > > > exit(EXIT_FAILURE);
> >> >> > > > }
> >> >> > > > }
> >> >> > > > gettimeofday(&end, 0);
> >> >> > > >
> >> >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 +
> >> >> > end.tv_usec - start.tv_usec) / 1000) - 1000);
> >> >> > > >
> >> >> > > > printf("msec = %d\n", msec);
> >> >> > > >
> >> >> > > > close(kq);
> >> >> > > > return EXIT_SUCCESS;
> &g
Re: kqueue periodic timer confusion
On Thu, 2012-07-12 at 10:40 -0500, Ian Lepore wrote:
> On Thu, 2012-07-12 at 17:08 +0200, Davide Italiano wrote:
> > On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> > > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> > >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> > >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> > >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> > >> > > > Hi,
> > >> > > >
> > >> > > > Sorry about this repost but I'm confused about the responses I
> > >> > > > received
> > >> > > > in my last post so I'm looking for some clarification.
> > >> > > >
> > >> > > > Specifically, I though I could use the kqueue timer as essentially
> > >> > > > a
> > >> > > > "drop in" replacement for linuxfd_create/read, but was surprised
> > >> > > > that
> > >> > > > the accuracy of the kqueue timer is much less than what I need for
> > >> > > > my
> > >> > > > application.
> > >> > > >
> > >> > > > So my confusion at this point is whether this is consider to be a
> > >> > > > bug or
> > >> > > > "feature"?
> > >> > > >
> > >> > > > Here's some test code if you want to verify the problem:
> > >> > > >
> > >> > > > #include
> > >> > > > #include
> > >> > > > #include
> > >> > > > #include
> > >> > > > #include
> > >> > > > #include
> > >> > > > #include
> > >> > > > #include
> > >> > > >
> > >> > > > int
> > >> > > > main(void)
> > >> > > > {
> > >> > > > int i,msec;
> > >> > > > int kq,nev;
> > >> > > > struct kevent inqueue;
> > >> > > > struct kevent outqueue;
> > >> > > > struct timeval start,end;
> > >> > > >
> > >> > > > if ((kq = kqueue()) == -1) {
> > >> > > > fprintf(stderr, "kqueue error!? errno = %s",
> > >> > strerror(errno));
> > >> > > > exit(EXIT_FAILURE);
> > >> > > > }
> > >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0,
> > >> > > > 20, 0);
> > >> > > >
> > >> > > > gettimeofday(&start, 0);
> > >> > > > for (i = 0; i < 50; i++) {
> > >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1,
> > >> > > > NULL)) ==
> > >> > -1) {
> > >> > > > fprintf(stderr, "kevent error!? errno =
> > >> > > > %s",
> > >> > strerror(errno));
> > >> > > > exit(EXIT_FAILURE);
> > >> > > > } else if (outqueue.flags & EV_ERROR) {
> > >> > > > fprintf(stderr, "EV_ERROR: %s\n",
> > >> > strerror(outqueue.data));
> > >> > > > exit(EXIT_FAILURE);
> > >> > > > }
> > >> > > > }
> > >> > > > gettimeofday(&end, 0);
> > >> > > >
> > >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 +
> > >> > end.tv_usec - start.tv_usec) / 1000) - 1000);
> > >> > > >
> > >> > > > printf("msec = %d\n", msec);
> > >> > > >
> > >> > > > close(kq);
> > >> > > > return EXIT_SUCCESS;
> > >> > > > }
> > >> > > >
> > >> > > >
> > >> > >
> > >> > > What you are seeing is "just the way FreeBSD currently works."
> > >> > >
> > >> > > Sleeping (in most all of its various forms, and I've just looked at
> > >
Re: kqueue periodic timer confusion
On Thu, 2012-07-12 at 09:26 -0500, John Baldwin wrote:
> On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> > On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> > > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> > > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> > > > > Hi,
> > > > >
> > > > > Sorry about this repost but I'm confused about the responses I
> > > > > received
> > > > > in my last post so I'm looking for some clarification.
> > > > >
> > > > > Specifically, I though I could use the kqueue timer as essentially a
> > > > > "drop in" replacement for linuxfd_create/read, but was surprised that
> > > > > the accuracy of the kqueue timer is much less than what I need for my
> > > > > application.
> > > > >
> > > > > So my confusion at this point is whether this is consider to be a bug
> > > > > or
> > > > > "feature"?
> > > > >
> > > > > Here's some test code if you want to verify the problem:
> > > > >
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > >
> > > > > int
> > > > > main(void)
> > > > > {
> > > > > int i,msec;
> > > > > int kq,nev;
> > > > > struct kevent inqueue;
> > > > > struct kevent outqueue;
> > > > > struct timeval start,end;
> > > > >
> > > > > if ((kq = kqueue()) == -1) {
> > > > > fprintf(stderr, "kqueue error!? errno = %s",
> > > strerror(errno));
> > > > > exit(EXIT_FAILURE);
> > > > > }
> > > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20,
> > > > > 0);
> > > > >
> > > > > gettimeofday(&start, 0);
> > > > > for (i = 0; i < 50; i++) {
> > > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1,
> > > > > NULL)) ==
> > > -1) {
> > > > > fprintf(stderr, "kevent error!? errno = %s",
> > > strerror(errno));
> > > > > exit(EXIT_FAILURE);
> > > > > } else if (outqueue.flags & EV_ERROR) {
> > > > > fprintf(stderr, "EV_ERROR: %s\n",
> > > strerror(outqueue.data));
> > > > > exit(EXIT_FAILURE);
> > > > > }
> > > > > }
> > > > > gettimeofday(&end, 0);
> > > > >
> > > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 +
> > > end.tv_usec - start.tv_usec) / 1000) - 1000);
> > > > >
> > > > > printf("msec = %d\n", msec);
> > > > >
> > > > > close(kq);
> > > > > return EXIT_SUCCESS;
> > > > > }
> > > > >
> > > > >
> > > >
> > > > What you are seeing is "just the way FreeBSD currently works."
> > > >
> > > > Sleeping (in most all of its various forms, and I've just looked at the
> > > > kevent code to verify this is true there) is handled by converting the
> > > > amount of time to sleep (usually specified in a timeval or timespec
> > > > struct) to a count of timer ticks, using an internal routine called
> > > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to
> > > > account for the current tick. Whether that's a good idea or not (it
> > > > probably was once, and probably not anymore) it's how things currently
> > > > work, and could explain the fairly consistant +1ms you're seeing.
> > >
> > > This is all true, but mostly irrelevant for his case. EVFILT_TIMER
> > > installs a periodic callout that executes KNOTE() and then resets itself
> > > (via
> > > callout_reset()) each time it runs. This should generally be closer to
> > >
kqueue periodic timer confusion
Hi,
Sorry about this repost but I'm confused about the responses I received
in my last post so I'm looking for some clarification.
Specifically, I though I could use the kqueue timer as essentially a
"drop in" replacement for linuxfd_create/read, but was surprised that
the accuracy of the kqueue timer is much less than what I need for my
application.
So my confusion at this point is whether this is consider to be a bug or
"feature"?
Here's some test code if you want to verify the problem:
#include
#include
#include
#include
#include
#include
#include
#include
int
main(void)
{
int i,msec;
int kq,nev;
struct kevent inqueue;
struct kevent outqueue;
struct timeval start,end;
if ((kq = kqueue()) == -1) {
fprintf(stderr, "kqueue error!? errno = %s", strerror(errno));
exit(EXIT_FAILURE);
}
EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0);
gettimeofday(&start, 0);
for (i = 0; i < 50; i++) {
if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == -1) {
fprintf(stderr, "kevent error!? errno = %s",
strerror(errno));
exit(EXIT_FAILURE);
} else if (outqueue.flags & EV_ERROR) {
fprintf(stderr, "EV_ERROR: %s\n",
strerror(outqueue.data));
exit(EXIT_FAILURE);
}
}
gettimeofday(&end, 0);
msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 + end.tv_usec
- start.tv_usec) / 1000) - 1000);
printf("msec = %d\n", msec);
close(kq);
return EXIT_SUCCESS;
}
--
Paul Albrecht
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [[SPAM]] Re: kqueue timer timeout period
On Wed, 2012-07-11 at 04:42 -0500, Alexander Motin wrote: > Hi. > > Historically FreeBSD used completely different hardware time sources for > time keeping and time events. Not sure about 5%, but the last could be > less precise in some cases. FreeBSD 9.0, depending on hardware, can be > more precise because of using same time source in both cases. Also there > is ongoing GSoC project now by Davide Italiano to handle sub-HZ > resolution for time events. Present tests show reaching 20 microseconds > precision; and I think it can be improved further. > I'm definitely not getting getting 20 millisecond timing with freebsd kqueue which surprised me because I get it with linux linuxfd_create/read using the same hardware. -- Paul Albrecht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kqueue timer timeout period
On Wed, 2012-07-11 at 03:36 -0500, Harti Brandt wrote: > On Wed, 11 Jul 2012, Peter Jeremy wrote: > > PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote: > PJ>>I have a question about the kqueue timer timeout period ... what's data > PJ>>supposed to be? I thought it was supposed to be the period in > PJ>>milliseconds, but I seem to off by one. > PJ>> > PJ>>For example, if I set date (the timeout period) to 20 milliseconds, I > PJ>>often wait 21 milliseconds which is very undesirable for my application. > PJ> > PJ>FreeBSD is not a real-time OS. The timeouts specified in various > PJ>syscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) > PJ>specify minimum timeouts. Once the timeout (rounded up to the next > PJ>tick) has expired, the process will be placed back into the queue > PJ>of processes eligible to be run by the scheduler - which may impose > PJ>a further arbitrary delay. > PJ> > PJ>Periodic timers are somewhat better behaved: Scheduler delays only > PJ>impact process scheduling after the timeout expires and the average > PJ>rate should be very close to that requested. > > While it is certainly true that FreeBSD is not a real-time OS, this does > not explain the timer problems. 2 or 3 month ago I did a simple test with > select and poll: I observed a systematic error of about 3-5% of the > waiting time. So when you wait for 20ms, you may get 21ms (if running with > a low HZ value) because of rounding. But if you wait for 100s, you get 103 > or even 105s on a completly idle machine (all services disabled). > > I think that this is not a problem with beeing non-realtime, but a problem > with time-keeping. Shouldn't it be possible to do this better? > I don't think it has anything to do with realtime either. I've been using gentoo linux to run my application using timerfd_create/read for 20 millisecond timing without any problems. > harti -- Paul Albrecht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kqueue timer timeout period
Hi, I have a question about the kqueue timer timeout period ... what's data supposed to be? I thought it was supposed to be the period in milliseconds, but I seem to off by one. For example, if I set date (the timeout period) to 20 milliseconds, I often wait 21 milliseconds which is very undesirable for my application. -- Paul Albrecht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Reprobing of devices after module load?
On 11/21/11, John Baldwin wrote: > On Friday, November 18, 2011 11:48:20 am Paul B. Mahol wrote: >> Hi, >> >> Is there nice way in FreeBSD to force reprobe of devices for specific >> driver like it is done when kernel module is loaded (via >> DRIVER_MODULE(...) stuff)? > > Note that those probes happen for specific buses rather than for specific > drivers. The routine that does this currently is static > (devclass_driver_added() in sys/kern/subr_bus.c). What specific problem are > you trying to solve? You might be able to use BUS_DRIVER_ADDED() or > device_probe_and_attach() to achieve what you are trying to do. I have changed NDISulator to load 3rd party *.SYS from userspace via ioctl on /dev/ndis. For now i can do reprobe by reloading if_ndis.ko module. Loading if_ndis.ko ideally should not cause reprobe but reprobe should be done after ioctl on /dev/ndis. Perhaps devclass_add_driver from sys/kern/subr_bus can do this? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Reprobing of devices after module load?
Hi, Is there nice way in FreeBSD to force reprobe of devices for specific driver like it is done when kernel module is loaded (via DRIVER_MODULE(...) stuff)? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is there a step by step howto for dtrace on 9.0 ?
the wiki DTrace (http://wiki.freebsd.org/DTrace) is available and enough for being a HOWTO. 2011/10/9 Adrian Chadd > > Hi, > > the subject says it all - does anyone have a step by step howto for > doing userland and kernel dtrace on 9.0? > > Thanks, > > > Adrian > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: excessive use of gettimeofday(2) and other syscalls
Sorry, my previous test is not accurate. I use both firefox and chromium to
open 13 same web pages( two of them are from www.sina.com.cn, other from
groups.google.com, wiki.sun.com and freebsd.org, both web browsers use
libcrossflash to drive linux flash plugin, not linuxulator on my amd64
8.2-stable , sorry I can not have access to youtube.com or facebook.com, I'm
in china),
and this is the result:
...
[root@lateaxfreebsd sys]# dtrace -n 'syscall::gettimeofday:entry / execname
== "chrome" || execname == "firefox-bin"|| execname == "plugin-container" /
{ @[execname] = count() } profile:::tick-1 { exit(0); } '
dtrace: description 'syscall::gettimeofday:entry ' matched 2 probes
CPU ID FUNCTION:NAME
1 97 :tick-1
plugin-container 7802
chrome 8403
firefox-bin 215777
if I close the two sina.com.cn tab( the big page), then
.
[root@lateaxfreebsd sys]# dtrace -n 'syscall::gettimeofday:entry / execname
== "chrome" || execname == "firefox-bin"|| execname == "plugin-container" /
{ @[execname] = count() } profile:::tick-1 { exit(0); } '
dtrace: description 'syscall::gettimeofday:entry ' matched 2 probes
CPU ID FUNCTION:NAME
1 97 :tick-1
chrome 65
plugin-container 2145
firefox-bin 268932
I think I can drive conclusion that chromium is much better than firefox
when rendering same page set, especially on static pages only 65 per second.
If we add opera to the list( opera not using flash plugin), it seems
opera does NOT use gettimeofday
.
[root@lateaxfreebsd sys]# dtrace -n 'syscall::gettimeofday:entry / execname
== "chrome" || execname == "firefox-bin"|| execname == "plugin-container" ||
execname == "opera" / { @[execname, probefunc] = count() } profile:::tick-1
{ exit(0); } '
dtrace: description 'syscall::gettimeofday:entry ' matched 2 probes
CPU ID FUNCTION:NAME
0 97 :tick-1
chrome gettimeofday 7632
plugin-container gettimeofday 8107
firefox-bin gettimeofday 232142
but it use more clock_gettime
.
[root@lateaxfreebsd sys]# dtrace -n 'syscall::clock_gettime:entry / execname
== "chrome" || execname == "firefox-bin"|| execname == "plugin-container" ||
execname == "opera" / { @[execname, probefunc] = count() } profile:::tick-1
{ exit(0); } '
dtrace: description 'syscall::clock_gettime:entry ' matched 2 probes
CPU ID FUNCTION:NAME
1 97 :tick-1
firefox-bin clock_gettime 634
chrome clock_gettime 839
plugin-container clock_gettime 1040
opera clock_gettime 14978
2011/9/10 Alexander Best
> On Fri Sep 9 11, Alexander Best wrote:
> > On Fri Sep 9 11, Dieter BSD wrote:
> > > >> Firefox 5 and 6 has more gettimeofday call than 2 per second on
> my
> > > >> amd64-8.2-stable box.
> > >
> > > > i don't see why chromium needs
> > > > to call gettimeofday(2) or any library function that triggers it more
> > > > than 3000 times a second.
> > >
> > > What the are web browsers doing that they "need" the clock
> > > so often?
> > >
> > > I suspect the answer is the same as why firefox uses significant
> amounts
> > > of CPU when it should be idle, why it uses memory without bound
> > > (I actually had to add ulimit to my shell's rc file :-( ), and
> > > so on.
> > >
> > > Using "links -g",
> > > "ktrace -di -tc -p6951; sleep 1; ktrace -C; kdump|wc -l"
> > > gives a typical count of 300-400, highest count seen: 1454.
> >
> > well that measurement is probably unfair. my measurements included all
> opened
> > tabs (~ 15), running plugins and extensions. if i disable all of those
> extra
> > stuff and use only a single tab, chromium produces less syscalls than
> links:
> >
> > 270
>
> ...however sites such as facebook produce a much higher syscall peek under
> chromium. with only one tab opened with youtube.com in it, chromium has a
> typical syscall count of 700-2000. i guess this is due to stuff like js,
> html5
> and friends.
>
> if i enable the flash plugins with only 1 single tab (youtube.com), the
> syscall
> count climbs to ~ 8000 with a peak at 19000 when youtube.com wasn't
> completely
> loaded. so the high syscall count is not only chromiums fault, but a
> combination of chromium, flash and the linuxulator.
>
> i believe further linuxulator improvements might reduce syscalls in this
> scenario.
>
> also with chromium 15, the syscall count is supposed to drop quite
> noticably
> (as mentioned in a previous message).
>
> cheers.
> alex
>
> >
> > cheers.
> > alex
> >
> > >
> > > What we need, is a sanely written web browser that has the
> > > features we need. Unfortunately the last time I checked,
> > > links and dillo both lacked features needed for online
> > > shopping/banking.
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
__
Re: excessive use of gettimeofday(2) and other syscalls
what version of chromium are you using? I use chromium-13.0.782.215 on amd64 8.2-stable, the gettimeofday call is far less than 2 per second, about 20 per second, but I notice old version has this bug, but latest version has fixed it. Maybe you should update your chromium and try again. Firefox 5 and 6 has more gettimeofday call than 2 per second on my amd64-8.2-stable box. 2011/9/7 Alexander Best > On Wed Sep 7 11, Peter Jeremy wrote: > > On 2011-Sep-06 16:44:48 -0600, Manish Vachharajani < > mani...@lineratesystems.com> wrote: > > >Under 7.3 (haven't checked 8 or 9) this issue crops up because the > > >time system call calls gettimeofday under the hood (see > > >lib/libc/gen/time.c). As a result, the kernel tries to get an > > >accurate subsecond resolution time that simply gets chopped to the > > >nearest second. > > > > Under 8.x and later, time(3) uses clock_gettime(CLOCK_SECOND,...) > > rather than gettimeofday(). This is intended to be much cheaper > > than gettimeofday(). > > > > On 2011-Sep-06 21:15:55 -0400, Rayson Ho wrote: > > >IMO, the time returned by gettimeofday does not need to be high > > >precision. There are higher resolution time APIs on Linux and I > > >believe the application programmers know when to use the slower but > > >more accurate clock API. > > > > There are 3 standard APIs for returning time of day: > > time(3) provides second precision > > gettimeofday(2) provides microsecond precision > > clock_gettime(2) provides nanosecond precision > > > > By default, FreeBSD attempts to provide resolution as close as > > possible to the precision - which makes the 2 system calls fairly > > expensive. In order to reduce the cost where the resolution isn't > > important, FreeBSD provides several non-standard clock types for > > clock_gettime(2). This approach differs from Linux - and it seems > > that there is a non-trivial body of code that assumes that calling > > gettimeofday() is very cheap. > > > > There is probably a good case for an API that provides a resolution > > of the order of a tick but there is no standard for this. > > chromium is triggering ~20.000 gettimeofday(2) calls per second on my > machine. > i'm running CURRENT on amd64. > > cheers. > alex > > > > > -- > > Peter Jeremy > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Automatic per-site configuration
Hi, There must be many others like me who carry a laptop from one site to another every week. Currently I have to work at four different sites. I'd like my FreeBSD 8.2 laptop to automatically start stuff depending on where I boot it and also my personal login environment depends on where I am (PRINTER setting in .profile, clients to automatically start and DISPLAY setting in .xsession, key bindings in .ctwmrc etc.) Until recently I could look at the fully qualified hostname I got from DHCP as all DHCP servers gave me a usable hostname but now I also have to work at various sites where DHCP does not give me a hostname at all. Getting no hostname from DHCP confuses xdm which defaults to "1" requiring me to switch to another virtual console and manually set the hostname to "localhost" or something. The hostname="foo.bar.tld" in rc.conf is absolute, when set the hostname obtained from DHCP is ignored. How do other people solve this? I'd prefer to to be prompted during boot and during login for the site I want to configure for. Kind regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Add SUM sysctl
On Mon, Apr 18, 2011 at 01:52:15PM +0200, rank1see...@gmail.com wrote:
>
> There are 2 ways of going into SUM (Single user mode)
> 1) Rebooting into it
> 2) Drop from MUM
>
> My solution MUST cover both cases, of entering into SUM.
>
> Once I enter SUM, I set it up, via 1 script, which enables deamons and other
> stuff, that I need, for certain task. (i.e; I wana use mouse, so I activate
> moused ...)
> Now, after those steps, if that machine is web server, which serves only
> static content, then enabling apache, makes it fully functional server, in
> SUM!
> I see now, that both SUM and MUM define BOOTED/STARTED/RUNNING FreeBSD. ->
> Thx, to Daniel O'Connor, for pointing into this direction.
> So SUM defines basic functionality and MUM ...
> So where is a BORDER of SUM and MUM. How many "stuff" has to be
> enabled/activated to decalre it as MUM, instead of SUM?
> Where does exactly SUM, becomes MUM. As long as kernel is being asked, it
> doesn't differentiate between SUM and MUM.
> Kernel "sees" amonut of "pressure" induced by deamones, users, processes.
>
> Now to cut that chatter short, to solution ...
>
> I've tried by looking at init state:
> # ps -U root | grep 'init -s'
> BUT, after exiting into MUM, from SUM:
> SUM->MUM (/sbin/init -s) 'init -s' remained.
> If sys booted directly into MUM, I see (/sbin/init --), which also remains
> upon drop to SUM.
> So init state can only be used, to determine, how sys has been booted/started.
>
> To cut it even shorter (skipping tried sysctl vars, env, etc ...)
>
>
> Solution, which passed my requirement, was one from J. Hellenthal's advice.
> Thx!
> It works, with both cases of entering into SUM.
> Also covers case, where I enable stuff, that I need in SUM and which could
> confuse function, into thinking it is in MUM.
>
>
> Here is an resulting function: (/bin/sh)
> --
> # Are we in a SUM
> in_sum ()
> {
> if [ "`/bin/pgrep -x getty`" ]; then
> return 1
> else
> return 0
> fi
> }
> --
Which works in most cases except:
1. You have disable getty in /etc/ttys because the system is headless.
2. You have logged in to all virtual consoles so all getty processes
have been replaced by login shells.
My personal conclusion after 25+ years of UNIX system administration is
that:
1. System V supports runlevels to distinguish between SUM and various
levels of MUM but that is not waterproof. Linux supposedly have
adopted the System V runlevel concept.
2. BSDs traditionally do not have a clear line between SUM and MUM, for
example, when going back from MUM to SUM, some processes that
were started in MUM keep running, filesystems are still mounted
and things configured for MUM are not de-configured. Also during
transition from SUM to MUM, when rc encounters an error, it
will drop into a "twilight zone" kind of SUM where some MUM
initialisation is completed but not all of it.
3. To be really safe, you should check for everything that should not
be running/mounted/configured before doing "dangerous stuff" (TM)
and not rely on a single test that may result in false positives or
false negatives.
Personally I seldomly drop into SUM via shutdown but prefer to reboot
into SUM.
My $0.02
Regards,
Paul Schenkeveld
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ifconfig output: ipv4 netmask format
On Fri, Apr 08, 2011 at 01:16:17PM -0600, Warner Losh wrote: > > On Apr 8, 2011, at 1:00 PM, Sergey Vinogradov wrote: > > > 08.04.2011 19:55, Mike Bristow пиÑеÑ: > >> On Fri, Apr 08, 2011 at 07:40:56PM +0400, Sergey Vinogradov wrote: > >>> On 08.04.2011 19:23, Warner Losh wrote: > >>>> On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: > >>>> If we really wanted to make it human readable, we'd output 10.2.3.4/24 > >>> > >>> So, maybe, while following the POLA, we should add an option, as Daniel > >>> mentioned above? To output the CIDR? > >> > >> Non-contigous netmasks are legal in IPv4. What do you do if someone adds > >> the CIDR flag but the netmask cannot be represented in CIDR notation? > > > > And boom goes the dynamite. Reverting to my first proposal about changing > > only netmask notation. > > Non-contiguous netmasks are *not* legal anymore in IPv4. They have gone the > way of the dodo. While some stacks still support it, a growing number of an > interesting number of bugs with them that actual deployments with > non-contiguous submasks becomes more hassle than it is worth. Although non-contiguous netmasks are not legal anymore in IPv4, our ifconfig still allows to do something like: # ifconfig em0 inet 10.0.5.2 netmask 255.0.255.0 # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=219b ether xx:xx:xx:xx:xx:xx inet 10.0.5.2 netmask 0xff00ff00 broadcast 10.255.5.255 media: Ethernet autoselect (1000baseT ) status: active If we allow ifconfig to set non-contiguous netmasks, it cannot be output in CIDR notation. Perhaps a compromise could be: -t Prefer dotted decimal over hex. -c If the netmask is contiguous, print it in CIDR, otherwise in hex (without -d) or dotted decimal (with -d). -d is already in use, hence -t although -D is also available. Does this make everyone happy? > Warner Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: looking for error codes
On Sat, Apr 02, 2011 at 12:50:29AM -0700, per...@pluto.rain.com wrote: > Mehmet Erol Sanliturk wrote: > > > For a long time I am thinking to obtain a physically ( not only > > software ) based [read-only] FreeBSD edition by re-arranging some > > parts of it , but I do not know how to do it ... > > > After some years , MFM hard disks abandoned in favor of IDE > > ( Integrated Drive Electronics ) hard disks by moving controller > > to hard disk and eliminating use of add-on cards with a very > > unfortunate design decision as ( a write protect mechanism by > > a switch on the hard disks are not implemented ) . > > At least some IDE drives have write-protect jumpers, which could > presumably be replaced with connections to switches. > > > With respect to my knowledge , no one of the operating systems > > has a facility to separate read-only and modifiable parts ... > > SunOS 4 had a partial solution to this, by rearranging the FS layout > so that /usr could be mounted read-only (and often, from a server -- > IIRC a single /usr could be shared among multiple diskless clients). > They used quite a few symlinks so that things could be found in > their accustomed places although actually located elsewhere. The > scheme was fairly well described in the SunOS 4 manual set; granted > _finding_ a SunOS 4 manual set these days may be a challenge :) In fact, FreeBSD is very similar, /etc and /usr/local/etc may be written to for configuration purposes after building your system, /tmp and /var should really be writable (temp files, log files, sockets etc.) /home other application directories of course depend on the particular application and the rest can be r/o. Embedded systems (please read the freebsd-embedded mailing list) deal with similar issues and that's what nanobsd(8) was written for. Read http://www.psconsult.nl/talks/AsiaBSDcon2010-Servers if you want to see that similar techniques can also be applied to servers. Regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: New Boot-Loader
On Sun, Mar 27, 2011 at 09:48:03PM -0700, Devin Teske wrote: > Hi fellow hackers, > > I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel > that the existing options in the boot-loader menu today can be whittled down > significantly with a stateful menu system rather than a single-action item > menu system. > > In designing the new menu, I'd like to get your opinions. From old: > > FreeBSD 8.1-RELEASE: twitpic.com/4e485w > > to new: > > Replacement Boot-Loader: twitpic.com/4e46ol Very nice! Could you consider changing the number options to letters: v=verbose, a=acpi, s=single ... Having many (hundreds) of machines to manage it's confusing to need 6 for boot prompt on older versions and 5 on the newer where 6 on the newer reboots. Moving from digits to letters with digits resulting in either a beep or a pause saves a lot of frustration for sysadmins already annoyed by the ever increasing POST delay rapidly pressing 6 when the boot0 menu appears. Thanks for your work! Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: > On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan wrote: > >> Among *all* the GNU/Linux distributions I used, they include a vim > >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, > >> in their base systems. A vim.tiny contains much more features compared > >> with nvi, but it's not compatible with POSIX vi. > >> > > Let's compare the comparable, I don't really care if PCbsd ship vim as > > its default, but FreeBSD as the base is not only aimed at desktop > > specifically. So you should take into account that I may want to run > > FreeBSD on an adm5120 board with 32MB of RAM, without having a text > > editor consuming too much disk-space/ram. > > > > Â - Arnaud > > > > If you really want to use vi in a 32MB mem environment, the ex-vi may > make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note > that the ee editor uses same amount memory as ex-vi. > > So basically, if no one disagree that we can drop the infinite undo, > multiple buffer, multiple window and some other potential missing > features, we can replace the nvi in the base system with ex-vi. I like the idea of adding Unicode support to nvi but I hate the idea of replacing nvi in the base system by something else. I've been there before, when administering a heterogenous environment with Unix, BSD and Linux systems, being a heavy user of vi, it's frustrating if commands in various versions of vi do not behave *exactly* the same, e.g. different versions of vi leave the cursor in different places after undo, the effect of the repeat command (.) after an undo command, the availability or not to do something like /pattern/z. to find and position the found text in the middle of the screen so you can immediately see the context. Administering hundreds of FreeBSD systems at various sites would become a nightmare if frequently used utilities in the base system do not behave exactly the same between different builds, a true POLA violation I think. I truly hope that adding unicode to nvi doesn't change the behaviour of nvi, at least not when not using actually Unicode. I think it makes more sense to grow a WITHOUT_NVI knob in buildworld so that people building for embedded systems can exclude nvi and include another version of vi when really pressed for space, like we can replace the base systems sendmail by sendmail from ports or another MTA. Regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
rc.d/jail issues
Hi,
The order in which jails are started by rc.d/jail is the order in which
jails are listed in $jail_list which is fine. On shutdown, jails are
stopped in the same order they were started which in some cases is not
fine. If jail B depends on functionality provided by jail A, one would
like to start A before B but shutdown B before A. Would it make sense
to reverse the order in which jails are stopped during shutdown by
reversing the nales in $jail_list?
The attached patch reverses $jail_list during shutdown.
Regards,
Paul Schenkeveld
--- etc/rc.d/jail.orig 2009-08-15 14:00:54.0 +0200
+++ etc/rc.d/jail 2011-01-27 13:03:17.0 +0100
@@ -678,7 +678,7 @@
jail_stop()
{
echo -n 'Stopping jails:'
- for _jail in ${jail_list}
+ for _jail in `reverse_list ${jail_list}`
do
if [ -f "/var/run/jail_${_jail}.id" ]; then
_jail_id=$(cat /var/run/jail_${_jail}.id)
--- etc/rc.d/jail.orig 2009-08-15 14:00:54.0 +0200
+++ etc/rc.d/jail 2011-01-27 13:03:17.0 +0100
@@ -678,7 +678,7 @@
jail_stop()
{
echo -n 'Stopping jails:'
- for _jail in ${jail_list}
+ for _jail in `reverse_list ${jail_list}`
do
if [ -f "/var/run/jail_${_jail}.id" ]; then
_jail_id=$(cat /var/run/jail_${_jail}.id)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Remove printf in acpi_tz_sanity()
On 11/22/10, Andriy Gapon wrote: > on 22/11/2010 01:18 Paul B Mahol said the following: >> On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote: >>> As is - this is a perfect candidate for a "local only" patch. >>> To be included into the tree - this, most probably, has to be controlled >>> by a >>> tunable/sysctl. >> >> So solution for useless console spamming is to add useless sysctl. > > Are you absolutely sure that they both are/would be useless? > For all uses of acpi_tz_sanity()? > E.g. if some system has never produced those messages in years and then > suddenly > starts spewing them out, would that be useless information? Linux, OpenBSD are missing this killer feature. > >> For -1 values, sane default values should be picked up. > > For current temperature too? > >> Anyway only _CRT is showing on console, and _PSV & _HOT are both -1 for >> tz0. > > On your system. > >> I'm not first one mentioning this and issue is old several years. > > OK. Sorry. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Remove printf in acpi_tz_sanity()
On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote:
> on 21/11/2010 13:07 Paul B Mahol said the following:
>> This patch removes printf which spams console whenever thermal state
>> is changed in laptop. Source of problem is in buggy BIOS.
>>
>> diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c
>> index 515a742..00866b2 100644
>> --- a/sys/dev/acpica/acpi_thermal.c
>> +++ b/sys/dev/acpica/acpi_thermal.c
>> @@ -697,11 +697,8 @@ acpi_tz_getparam(struct acpi_tz_softc *sc, char
>> *node, int *data)
>> static void
>> acpi_tz_sanity(struct acpi_tz_softc *sc, int *val, char *what)
>> {
>> - if (*val != -1 && (*val < TZ_ZEROC || *val > TZ_ZEROC + 2000)) {
>> - device_printf(sc->tz_dev, "%s value is absurd, ignored (%d.%dC)\n",
>> - what, TZ_KELVTOC(*val));
>> + if (*val != -1 && (*val < TZ_ZEROC || *val > TZ_ZEROC + 2000))
>> *val = -1;
>> - }
>> }
>
> As is - this is a perfect candidate for a "local only" patch.
> To be included into the tree - this, most probably, has to be controlled by a
> tunable/sysctl.
So solution for useless console spamming is to add useless sysctl.
For -1 values, sane default values should be picked up.
Anyway only _CRT is showing on console, and _PSV & _HOT are both -1 for tz0.
I'm not first one mentioning this and issue is old several years.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Remove printf in acpi_tz_sanity()
This patch removes printf which spams console whenever thermal state
is changed in laptop. Source of problem is in buggy BIOS.
diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c
index 515a742..00866b2 100644
--- a/sys/dev/acpica/acpi_thermal.c
+++ b/sys/dev/acpica/acpi_thermal.c
@@ -697,11 +697,8 @@ acpi_tz_getparam(struct acpi_tz_softc *sc, char
*node, int *data)
static void
acpi_tz_sanity(struct acpi_tz_softc *sc, int *val, char *what)
{
-if (*val != -1 && (*val < TZ_ZEROC || *val > TZ_ZEROC + 2000)) {
- device_printf(sc->tz_dev, "%s value is absurd, ignored (%d.%dC)\n",
- what, TZ_KELVTOC(*val));
+if (*val != -1 && (*val < TZ_ZEROC || *val > TZ_ZEROC + 2000))
*val = -1;
-}
}
/*
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Managing userland data pointers in kqueue/kevent
On Mon, Nov 15, 2010 at 12:51:57PM -0800, Julian Elischer wrote:
> "keep more information associated with each kevent and use the user
> cookie to
> match them" this is what it was for.
> it's a tool, not an answer. Given this tool you should be able to
> get what you want.
> how you do it is your job.
OK. Then I am not seeing it. I would love to seen an example, if you
or anyone else could provide me one, on how I am supposed to use this
feature. That would be great... but please read below first.
> It's not the kernel's job to keep application specific data for
> you.. but it gives you a way
> to do it yourself and keep track of it trivially.
> It's expected that for every event the user gives to the kernel, he
> has some matching
> information about that event in userland.
Sure. The information I keep in userland is in the structure at the end
of that udata pointer.
Since you claim it to be so trivial then, I would like to ask you to
explain it. It should be quite a simple task:
---
Demonstrate me a program that, on receipt of -any- event out of the
kqueue file descriptor, can print the word "FREE\n" when the kernel
has now dropped its side of the watcher, for this event.
Specifically, it has to print "FREE\n" in any of the following four
conditions:
1. After a final event, such as EVFILT_PROC,NOTE_EXIT
2. After any event that had been registered with EV_ONESHOT
3. After the user has called EV_SET(..., EV_DELETE,...) on it
4. After calling close(fd) on a filehandle that has been registered
under EVFILT_READ or EVFILT_WRITE
---
I am claiming that such a program cannot be written, using the current
kqueue interface, and simply allowing the user code to call EV_SET
however they like and put their own pointers in it. If I read your
assertion of triviallity correctly, then you are claiming that such a
program is indeed possible. I would therefore invite you to demonstrate
for me such a program.
If perhaps this does indeed prove to be impossible, I would like instead
you to demonstate a program having all the above properties, but
allowing you to arbitrarily wrap the kqueue API; store extra data in my
structures, or hook extra information around EV_SET calls.
I have already demonstrated -a- way to solve this, by storing data in
the event udata structure to answer 2, and storing a full mapping from
ident+filter to udata pointer, to answer 3. I declare 1 trivial by
inspection of the results in the returned kevent. I declare 4 to be
impossible short of such hackery as LD_PRELOAD around the actual close()
libc function.
In short, I claim that a solution to all parts 1-4 is impossible. It is
possible to solve 1-3 only, by storing a full mapping from ident+filter
to udata pointer, in userland. But then by doing that why bother giving
the pointer to the kernel in the first place?
There comes a further complication for a wrapping library that tries to
provide a generic interface around kqueue, for problem 1 however. Right
now, the following function could be said to implement problem 1:
int is_final(struct kevent *ev)
{
switch(ev->filter) {
case EVFILT_READ:
case EVFILT_WRITE:
return ev->flags & EV_EOF;
case EVFILT_VNODE:
return ev->fflags & (NOTE_DELETE|NOTE_REVOKE);
/* I'm only guessing on this one from reading the docs, I'm not
* 100% sure */
case EVFILT_PROC:
return ev->fflags & NOTE_EXIT;
default:
return 0;
}
}
And in fact even this code isn't perfect, because the kqueue(2) manpage
does also point out that EV_EOF on a pipe/fifo isn't final, because you
can EV_CLEAR to reset the EOF condition and wait again. So maybe this
code ought to read:
case EVFILT_READ:
case EVFILT_WRITE:
{
struct stat st;
fstat(ev->ident, &st);
return (ev->flags & EV_EOF) && !(S_ISFIFO(st.st_mode));
}
And so now we suddenly have to make an fstat() call -every- time we
receive an event on a read/write filter?
OK well clearly not, we'd in fact do that once at EV_ADD time, and store
whether it's a FIFO in our extended udata structure, so as to know if
EV_EOF is final. But then we're having to use that udata structure to
store data internal to the purposes of this kqueue interface, and not
the overall user data.
Are you still now going to claim to me this is trivial?
Please compare this solution to:
if(ev->flags & EV_FREEWATCH)
free(ev->udata);
I would call that solution "trivial". And I claim it fairly easy to
implement.
--
Paul "LeoNerd" Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: Managing userland data pointers in kqueue/kevent
On Mon, Nov 15, 2010 at 11:37:23AM -0800, Julian Elischer wrote: > I don't think it was thought of in the context of reference counted items. This problem has nothing to do with reference counting, and all to do with resource ownership. Consider in the totally C-based world, no refcounts, just malloc() and free(). You malloc() some event structure, put it in the udata field to the kernel, then return to the main run loop. You've dropped every reference to this malloc()ed memory, because hey, kernel has it. Later, event fires, kernel gives you back that pointer. Great. Lets use it. Was it a PROC|EXIT event? Lets free() the data. Was it an event that had been registered as EV_ONESHOT? Oops. We can't remember because kernel didn't tell us. Want to EV_DELETE it now? Can't, lost the pointer, can't ask kernel for it back. Want to close() the filehandle associated? Can't, because kernel has pointer that it'll drop. In all these cases we'll memory leak the malloc()ed data. The only solution here is to keep another copy somewhere up in userland. This copy has to be associated with the original filter specification, so that on EV_DELETE we know the pointer so can free() it. But, as I said, if we're going to keep that mapping, why does the kernel even give us this udata ability in the first place? We might as well not bother and use the mapping all the time. Maybe this just is what people do? That was the thrust of my first question - _is_ this what people do? I'm not experienced enough with kqueue to know what is best practice here, and the documentation gives no guidance. Can someone advise me? --- Totally separate to that, if nobody has really thought of a solution to this before, what are anyone's thoughts on my suggestion of the EV_FREEWATCH flag? Get the kernel always to tell userland that it has dropped a watch, and return the pointer back, so userland can do whatever it wants by way of resource reclaimation. > you could use an ever increasing number that you hash on a hash table. > if the kernel returns a number that is out of date you won't find it > and you > can ignore it. If the kernel returns a number you are currently tracking. > then you use the item associated with that entry. I'm really not sure I understand where this is going, or how it helps me... -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Managing userland data pointers in kqueue/kevent
On Mon, Nov 15, 2010 at 02:10:45PM -0500, John Baldwin wrote:
> On Monday, November 15, 2010 1:12:11 pm Paul LeoNerd Evans wrote:
> > On Mon, Nov 15, 2010 at 11:25:42AM -0500, John Baldwin wrote:
> > > I think the assumption is that userland actually maintains a reference on
> > > the
> > > specified object (e.g. a file descriptor) and will know to drop the
> > > associated
> > > data when the file descriptor is closed. That is, think of the kevent as
> > > a
> > > member of an eventable object rather than a separate object that has a
> > > reference to the eventable object. When the eventable object's reference
> > > count drops to zero in userland, then the kevent should be deleted,
> > > either via
> > > EV_DELETE, or implicitly (e.g. by closing the associated file descriptor).
> >
> > Ah. Well, that could be considered a bit more awkward for the use case I
> > wanted to apply. The idea was that the udata would refer effectively
> > to a closure, to invoke when the event happens. The idea being you can
> > just add an event watcher by, say:
> >
> > $ev->EV_SET( $pid, EVFILT_PROC, 0, NOTE_EXIT, 0, sub {
> > print STDERR "The child process $pid has now exited\n";
> > } );
> >
> > So, the kernel's udata pointer effectively holds the only reference to
> > this anonymous closure. It's much more flexible this way, especially for
> > oneshot events like that.
> >
> > The beauty is also that the kevents() loop can simply know that the
> > udata is always a code reference so just has to invoke it to do whatever
> > the original caller wanted to do.
> >
> > Keep in mind my use-case here; I'm not trying to be one specific
> > application, it's a general-purpose kevent-wrapping library.
>
> So is GCD (Apple's libdispatch). It also implements closures on top of
> kevent. However, the way it works is that it doesn't expose kevent()
> directly, instead it uses kevent to implement asynchronous I/O on a
> socket for example, and since it is logically managing the life cycle
> of a socket, it knows when the socket is closed and cleans up then.
Well, the principle item of work here is a direct API reimplementation
in IO::KQueue on CPAN. I'm trying to simply expose the API of storing an
arbitrary Perl scalar in the udata field. It -could- be a closure, but
of course it doesn't have to. Maybe the using code wants to keep a HASH
ref of some pseudo-structure, or whatever...
> For the above case, if you know an event is one shot, you should either
> use EV_ONESHOT, or use a wrapper around the closure that clears the event
> after the closure runs (or possibly before the closure runs?)
I don't see how passing EV_ONESHOT at all helps here. If it's oneshot by
nature (child process exit), it'll be oneshot whatever happens. I've
already observed that the EV_ONESHOT flag does not get re-emitted by the
kernel anyway, so I'd have to track that one separately somehow.
> Your use case is rare. Almost all consumers of kevent() that I've seen
> use kevent() as one part of a system that maintain the lifecycle of objects.
> Those objects are only accessed within the system, so the system knows when
> an object is closed and can release the resources at the same time.
OK. I'm prepared to accept this. It may be that nobody's really tried to
provide a simple kqueue/kevent API wrapping for a high-level language,
that could nicely take advantage of memory management in the language,
rather than at the low C level of explicit malloc+free.
Could we perhaps address the second part of my question for a moment? If
there really isn't a general solution here, could my EV_FREEWATCH flag
be added? It's a single extra flag to export in the API .h file,
completely backward-compatible. Surely quite simple to implement in the
kernel too, because it already knows how to free() its own internal
structures anyway; so just before it does that when it deletes an event
for whatever reason, it could just fire that event back up to userland
to say "I've dropped this, and here have your pointer back". Userland
catches it, SvRECFNT_dec()s or whatever, problem solved.
Is that an API extension anyone would consider accepting? I for one
would use it.
--
Paul "LeoNerd" Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: Managing userland data pointers in kqueue/kevent
On Mon, Nov 15, 2010 at 10:33:25AM -0800, Julian Elischer wrote: > it was provided for pretty much what you are using it for, so that > the userland caller could > easily associate the returning event with some private information > about the event. This was indeed the impression I got. With reference to my original questions regarding its use, perhaps you could suggest some way to actually use this API then, in order to solve my problem? Unless there's some subtle detail or trick I have misunderstood, it doesn't appear to be easily possible in this manner. How would you suggest I manage these pointers and data structures? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Managing userland data pointers in kqueue/kevent
On Mon, Nov 15, 2010 at 11:25:42AM -0500, John Baldwin wrote:
> I think the assumption is that userland actually maintains a reference on the
> specified object (e.g. a file descriptor) and will know to drop the
> associated
> data when the file descriptor is closed. That is, think of the kevent as a
> member of an eventable object rather than a separate object that has a
> reference to the eventable object. When the eventable object's reference
> count drops to zero in userland, then the kevent should be deleted, either
> via
> EV_DELETE, or implicitly (e.g. by closing the associated file descriptor).
Ah. Well, that could be considered a bit more awkward for the use case I
wanted to apply. The idea was that the udata would refer effectively
to a closure, to invoke when the event happens. The idea being you can
just add an event watcher by, say:
$ev->EV_SET( $pid, EVFILT_PROC, 0, NOTE_EXIT, 0, sub {
print STDERR "The child process $pid has now exited\n";
} );
So, the kernel's udata pointer effectively holds the only reference to
this anonymous closure. It's much more flexible this way, especially for
oneshot events like that.
The beauty is also that the kevents() loop can simply know that the
udata is always a code reference so just has to invoke it to do whatever
the original caller wanted to do.
Keep in mind my use-case here; I'm not trying to be one specific
application, it's a general-purpose kevent-wrapping library.
> I think in your case you should not give the kevent a reference to your
> object, but instead remove the associated event for a given object when an
> object's refcount drops to zero.
Well that's certainly doable in longrunning watches, but I don't think
it sounds very convenient for a oneshot event; see the above example for
justification.
Also it again begs my question, worth repeating here:
On Friday, November 12, 2010 1:40:00 pm Paul LeoNerd Evans wrote:
> I had
> thought the point of kqueue/kevent is the O(1) nature of it, which is
> among why the kernel is storing that void *udata pointer in the first
> place. If I have to store a mapping from every filter+identity back to
> my data pointer, why does the kernel store one at all? I could just
> ignore the udata field and use my mapping for my own purposes.
If you're saying that in my not-so-rare use case, I don't want to be
using udata, and instead keeping my own mapping, why does the kernel
provide this udata field at all?
--
Paul "LeoNerd" Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Managing userland data pointers in kqueue/kevent
I'm trying to build a high-level language wrapper around kqueue/kevent, specifically, a Perl wrapper. (In fact I am trying to fix this bug: http://rt.cpan.org/Public/Bug/Display.html?id=61481 ) My plan is to use the void *udata field of a kevent watcher to store a pointer to some user-provided Perl data structure (an SV*), to associate with the event. Typically this could be a code reference for an event callback or similar, but the exact nature doesn't matter. It's a pointer to a reference-counted data structure. SvREFCNT_dec(sv) is the function used to decrement the reference counter. To account for the fact that the kernel stores a pointer here, I'm artificially increasing the reference count on the object, so that it still remains alive even if the rest of the Perl code drops it, to rely on getting it back out of the kernel in an individual kevent. At some point when the kernel has finished looking after the event, this count needs to be decreased again, so the structure can be freed. I am having trouble trying to work out how to do this, or rather, when. I have the following problems: * If the event was registered using EV_ONESHOT, when it gets fired the flags that come back in the event stucture do not include EV_ONESHOT. * Some events can only happen once, such as watching for EVFILT_PROC NOTE_EXIT events. * The kernel can silently drop watches, such as when the process calls close() on a filehandl with an EVFILT_READ or EVFILT_WRITE watch. * There doesn't seem to be a way to query that pointer back out of the kernel, in case the user code wants to EV_DELETE the watch. These problems all mean that I never quite know when I ought to call SvREFCNT_dec() on that pointer. My current best-attack plan looks like the following: a) Store a structure in the void *udata that contains the actual SV* pointer and a flag to remember if the event had been installed as EV_ONESHOT (or remember if it was one of the event types that is oneshot anyway) b) Store an entire mapping in userland from filter+identity to pointer, so that if userland wants to EV_DELETE the watch early, it has the pointer to be able to drop it. I can't think of a solution to the close() problem at all, though. Part a of my solution seems OK (though I'd wonder why the flags back from the kernel don't contain EV_ONESHOT), but part b confuses me. I had thought the point of kqueue/kevent is the O(1) nature of it, which is among why the kernel is storing that void *udata pointer in the first place. If I have to store a mapping from every filter+identity back to my data pointer, why does the kernel store one at all? I could just ignore the udata field and use my mapping for my own purposes. Have I missed something here, then? I was hoping there'd be a nice way for kernel to give me back those pointers so I can just decrement a refcount on it, and have it reclaimed. - I have an idea on a small addition to the kernel API that would make this issue much simpler to manage, if there is nothing else. By the addition of a new event flag, called something like EV_FREEWATCH, the kernel can be told "tell userland whenever I am about to drop this event watcher". So now, after a EV_ONESHOT or any of the single events are fired, or when it gets EV_DELETEed, or when the kernel itself drops because of a close() on a filehandle, it can fire an event back up to userland with this flag, passing up the pointer. Now, all userland has to do to correctly manage the memory is to always set that flag on EV_ADD, and if the flag ever comes back in an event out of the kernel, it can SvREFCNT_dec(ev->udata); -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Summary: Re: Spin down HDD after disk sync or before power off
On 10/21/10 15:20, Dag-Erling Smørgrav wrote: Bruce Cran writes: The Ubuntu issue was what I was thinking of - I got that mixed up with the aggressive power management of the WD EARS drives. The entire Green series, actually, which includes models such as the EADS, AARS etc., but there's more to them than that - the central feature is their dynamically adjusted rotational speed, which allows them to conserve power without spinning all the way down. DES Actually, the green series does spin all the way down, well at least the drive I have does. Here is the output from one of my drives, that I do not think has long left to live. === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Green family Device Model: WDC WD5000AADS-00M2B0 Serial Number:WD-WMAV51882791 Firmware Version: 01.00A01 User Capacity:500,107,862,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Thu Oct 21 23:31:35 2010 BST SMART support is: Available - device has SMART capability. SMART support is: Enabled SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051Pre-fail Always - 0 3 Spin_Up_Time0x0027 111 104 021Pre-fail Always - 7425 4 Start_Stop_Count0x0032 100 100 000Old_age Always - 98 5 Reallocated_Sector_Ct 0x0033 200 200 140Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 100 253 000Old_age Always - 0 9 Power_On_Hours 0x0032 093 093 000Old_age Always - 5295 10 Spin_Retry_Count0x0032 100 253 000Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always - 96 192 Power-Off_Retract_Count 0x0032 200 200 000Old_age Always - 95 193 Load_Cycle_Count0x0032 001 001 000Old_age Always - 781014 194 Temperature_Celsius 0x0022 120 102 000Old_age Always - 27 196 Reallocated_Event_Count 0x0032 200 200 000Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x0032 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000Old_age Offline - 0 The datasheet for these drive <http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf>http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf says "Reliability/Data Integrity Load/unload cycles (3) 300,000 Limited Warranty (years) (4) (3) Controlled unload at ambient condition (4) The term of the limited warranty my vary by region" Also http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=5357 "(drive has been validated to 1 million load/unload cycles without issue)" Im already at 781014 load cycles, yet the drive is only about 7 months old. Doing the math, I am getting a load/unload cycle about every 24.5 seconds Another 2 months and I will be knocking on for 1 million load/unload cycles As DES has already said, for most people the extra load/unload cycles when rebooting a computer will not be an issue at all and is far more desirable than an emergency park when powering down Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kmod if_alc in 8-CURRENT
On 10/21/10, Matthias Apitz wrote: > El dia Thursday, October 21, 2010 a las 08:35:09PM +0200, Paul B Mahol > escribio: > >> > # cd /usr/src >> > # make buildkernel KERNCONF=GENERIC >> > >> > does not build the module if_alc.ko >> > >> > What I'm missing? Or what is the correct way to get this module for my >> > kernel level? >> >> /sys/modules/alc > > Yes, thanks. I realized this some hours ago and CVS up this too, but > the module does not get build. Because you did not have Makefiles of higher directories. Anyway: # cd /sys/modules/alc && make install clean Should do it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kmod if_alc in 8-CURRENT
On 10/21/10, Matthias Apitz wrote: > > Hello, > > I have on my laptop a kernel based on CVS from May 2009, i.e. 8-CURRENT > at this time. > > I now need support for Atheros AR813x/AR815x PCIe > Ethernet, the kmod if_alc.ko. That's why I did: > > # cd /usr/src/sys/dev > # cvs update -d -r RELENG_8_0_0_RELEASE alc > > and have now: > > # ls -l alc > total 142 > drwxr-xr-x 2 root wheel 512 21 oct 15:30 CVS > -rw-r--r-- 1 root wheel 103832 21 oct 15:30 if_alc.c > -rw-r--r-- 1 root wheel 29084 21 oct 15:30 if_alcreg.h > -rw-r--r-- 1 root wheel8119 21 oct 15:30 if_alcvar.h > > but a > > # cd /usr/src > # make buildkernel KERNCONF=GENERIC > > does not build the module if_alc.ko > > What I'm missing? Or what is the correct way to get this module for my > kernel level? /sys/modules/alc > > Thanks > > matthias > > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Improve OptionalObsoleteFiles.inc
On 10/4/10, Peter Pentchev wrote:
> On Mon, Oct 04, 2010 at 11:01:45AM +0000, Paul B Mahol wrote:
>> On 10/4/10, Alexander Leidinger wrote:
>> > Quoting Paul B Mahol (from Sun, 3 Oct 2010 13:53:26
>> > +):
>> >
>> >> Hi,
>> >>
>> >>
>> >> diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
>> >> b/tools/build/mk/OptionalObsoleteFiles.inc
>> >> index d3aa4b2..2123107 100644
>> >> --- a/tools/build/mk/OptionalObsoleteFiles.inc
>> >> +++ b/tools/build/mk/OptionalObsoleteFiles.inc
>> >> @@ -141,6 +141,7 @@ OLD_FILES+=usr/share/man/man8/authpf.8.gz
>> >> .endif
>> >>
>> >> .if ${MK_BIND} == no
>> >> +OLD_FILES+=etc/periodic/daily/470.status-named
>> >
>> > If bind is installed from ports instead, this file could be useful,
>> > isn't
>> > it?
>> >
>> >> OLD_FILES+=usr/bin/dig
>> >> OLD_FILES+=usr/bin/host
>> >> OLD_FILES+=usr/bin/nslookup
>> >
>> > [...]
>> >
>> >> @@ -1976,6 +1998,11 @@ OLD_FILES+=usr/share/man/man8/rtquery.8.gz
>> >> .endif
>> >>
>> >> .if ${MK_SENDMAIL} == no
>> >> +OLD_FILES+=etc/periodic/daily/150.clean-hoststat
>> >> +OLD_FILES+=etc/periodic/daily/210.backup-aliases
>> >> +OLD_FILES+=etc/periodic/daily/440.status-mailq
>> >> +OLD_FILES+=etc/periodic/daily/460.status-mail-rejects
>> >> +OLD_FILES+=etc/periodic/daily/500.queuerun
>> >> OLD_FILES+=bin/rmail
>> >> OLD_FILES+=usr/bin/vacation
>> >> OLD_FILES+=usr/include/libmilter/mfapi.h
>> >
>> > At least status-mailq is still useful with other MTAs, e.g. if you use
>> > postfix (and assuming the mailwrapper is configured correctly), this
>> > should still work. Depending on the setup of the aliases,
>> > backup-aliases will still work too. I haven't checked for the other
>> > ones.
>>
>> If you want to keep some "old" files, you just need to press `n' instead
>> of `y'
>> when deleting files. You are not forced to run make delete-old at all.
>
> On the other hand, doing this (skipping those files) on each and every
> system
> update (say, on a development or testing machine) could get a bit... boring
> -
> not to mention that at some point you'll learn to "oh, just say no", and
> then
> forget to remove something important.
Oh! I see... I want it in black.
>
> G'luck,
> Peter
>
> --
> Peter Pentchevr...@space.bgr...@ringlet.netr...@freebsd.org
> PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
> Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
> Do you think anybody has ever had *precisely this thought* before?
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Improve OptionalObsoleteFiles.inc
On 10/4/10, Alexander Leidinger wrote:
> Quoting Paul B Mahol (from Sun, 3 Oct 2010 13:53:26
> +):
>
>> Hi,
>>
>>
>> diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
>> b/tools/build/mk/OptionalObsoleteFiles.inc
>> index d3aa4b2..2123107 100644
>> --- a/tools/build/mk/OptionalObsoleteFiles.inc
>> +++ b/tools/build/mk/OptionalObsoleteFiles.inc
>> @@ -141,6 +141,7 @@ OLD_FILES+=usr/share/man/man8/authpf.8.gz
>> .endif
>>
>> .if ${MK_BIND} == no
>> +OLD_FILES+=etc/periodic/daily/470.status-named
>
> If bind is installed from ports instead, this file could be useful, isn't
> it?
>
>> OLD_FILES+=usr/bin/dig
>> OLD_FILES+=usr/bin/host
>> OLD_FILES+=usr/bin/nslookup
>
> [...]
>
>> @@ -1976,6 +1998,11 @@ OLD_FILES+=usr/share/man/man8/rtquery.8.gz
>> .endif
>>
>> .if ${MK_SENDMAIL} == no
>> +OLD_FILES+=etc/periodic/daily/150.clean-hoststat
>> +OLD_FILES+=etc/periodic/daily/210.backup-aliases
>> +OLD_FILES+=etc/periodic/daily/440.status-mailq
>> +OLD_FILES+=etc/periodic/daily/460.status-mail-rejects
>> +OLD_FILES+=etc/periodic/daily/500.queuerun
>> OLD_FILES+=bin/rmail
>> OLD_FILES+=usr/bin/vacation
>> OLD_FILES+=usr/include/libmilter/mfapi.h
>
> At least status-mailq is still useful with other MTAs, e.g. if you use
> postfix (and assuming the mailwrapper is configured correctly), this
> should still work. Depending on the setup of the aliases,
> backup-aliases will still work too. I haven't checked for the other
> ones.
If you want to keep some "old" files, you just need to press `n' instead of `y'
when deleting files. You are not forced to run make delete-old at all.
When installing world in new environment such files are not installed anyway.
>
> In general: please submit via send-pr (or similar) to GNATS. This way
> the patch should not be lost.
>
> Bye,
> Alexander.
>
> --
> There are two ways of disliking art.
> One is to dislike it.
> The other is to like it rationally.
> -- Oscar Wilde
>
> http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
> http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Improve OptionalObsoleteFiles.inc
Hi,
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
b/tools/build/mk/OptionalObsoleteFiles.inc
index d3aa4b2..2123107 100644
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/tools/build/mk/OptionalObsoleteFiles.inc
@@ -141,6 +141,7 @@ OLD_FILES+=usr/share/man/man8/authpf.8.gz
.endif
.if ${MK_BIND} == no
+OLD_FILES+=etc/periodic/daily/470.status-named
OLD_FILES+=usr/bin/dig
OLD_FILES+=usr/bin/host
OLD_FILES+=usr/bin/nslookup
@@ -943,6 +944,7 @@ OLD_FILES+=rescue/ping6
#.endif
.if ${MK_IPFILTER} == no
+OLD_FILES+=etc/periodic/security/510.ipfdenied
OLD_FILES+=rescue/ipf
OLD_FILES+=sbin/ipf
OLD_FILES+=sbin/ipfs
@@ -1517,6 +1519,20 @@ OLD_FILES+=usr/share/man/man8/verify_krb5_conf.8.gz
# to be filled in
#.endif
+.if ${MK_LOCATE} == no
+OLD_FILES+=etc/locate.rc
+OLD_FILES+=etc/periodic/weekly/310.locate
+OLD_FILES+=usr/bin/locate
+OLD_FILES+=usr/libexec/locate.bigram
+OLD_FILES+=usr/libexec/locate.code
+OLD_FILES+=usr/libexec/locate.concatdb
+OLD_FILES+=usr/libexec/locate.mklocatedb
+OLD_FILES+=usr/libexec/locate.updatedb
+OLD_FILES+=usr/share/man/man1/locate.1.gz
+OLD_FILES+=usr/share/man/man8/locate.updatedb.8.gz
+OLD_FILES+=usr/share/man/man8/updatedb.8.gz
+.endif
+
.if ${MK_LPR} == no
OLD_FILES+=etc/hosts.lpd
OLD_FILES+=etc/printcap
@@ -1549,6 +1565,7 @@ OLD_FILES+=usr/share/man/man8/pac.8.gz
.endif
.if ${MK_MAIL} == no
+OLD_FILES+=etc/periodic/daily/130.clean-msgs
OLD_FILES+=usr/bin/Mail
OLD_FILES+=usr/bin/biff
OLD_FILES+=usr/bin/from
@@ -1772,7 +1789,12 @@ OLD_FILES+=usr/share/man/man8/tftp-proxy.8.gz
.endif
.if ${MK_PKGTOOLS} == no
+OLD_FILES+=etc/periodic/daily/490.status-pkg-changes
OLD_FILES+=etc/periodic/weekly/400.status-pkg
+OLD_FILES+=usr/include/pkg.h
+OLD_FILES+=usr/lib/libpkg.a
+OLD_FILES+=usr/lib/libpkg.so
+OLD_LIBS+=usr/lib/libpkg.so.0
OLD_FILES+=usr/sbin/pkg_add
OLD_FILES+=usr/sbin/pkg_create
OLD_FILES+=usr/sbin/pkg_delete
@@ -1976,6 +1998,11 @@ OLD_FILES+=usr/share/man/man8/rtquery.8.gz
.endif
.if ${MK_SENDMAIL} == no
+OLD_FILES+=etc/periodic/daily/150.clean-hoststat
+OLD_FILES+=etc/periodic/daily/210.backup-aliases
+OLD_FILES+=etc/periodic/daily/440.status-mailq
+OLD_FILES+=etc/periodic/daily/460.status-mail-rejects
+OLD_FILES+=etc/periodic/daily/500.queuerun
OLD_FILES+=bin/rmail
OLD_FILES+=usr/bin/vacation
OLD_FILES+=usr/include/libmilter/mfapi.h
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: little mistake in rc.subr?
On Mon, Sep 27, 2010 at 02:01:29PM +0200, Lars Engels wrote: > On Mon, Sep 27, 2010 at 03:04:21PM +0400, Dmitry Banshchikov wrote: > > Hello, > > > > In /etc/rc.subr, at line 231, there is: > > > > if [ ! -f $_pidfile ]; then > > debug "pid file ($_pidfile): not readable." > > return > > fi > > > > Is check "[ ! -r $_pidfile ]" more correct? > > There's pratically no difference. rc stuff is run as root, so if there's > a file, it's readable, if there's no file, then the debug message is > printed. And -f also checks that it is a regular file (or symlink to a regular file). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Crash dump on HP Proliant G6 broken as of V8.0
ALL, The crash dump worked fine in V7.3. I am debugging crash dump problem on a HP Proliant G6 which uses a SATA drive connected to a CISS Raid Controller. I have tried this on a x86 box using a non-raid ATA/SATA disk controller and it works well. I noticed that in V8.0 there is a new SCSI operating method. In the v7.3 version there was only CISS_TRANSPORT_METHOD_SIMPLE, but in v8.0 there has been CISS_TRANSPORT_METHOD_PERF method added. These methods have different function calls in ciss_poll_request. The dump comand starts with a call to dadump. This function will setup a struct ccb_scsiio structure. This is done by calling scsi_read_write. Then the meat of dump happens when it calls xpt_polled_action, which manages and simualtes interrupt functionality that is working fine. The disk operations work fine except during a crash dump. I have turned debug on for CISS and CAMDEBUG to debug this problem. In xpt_polled_action (cam_xpt.c) we get past the first polling loop at line 3013, as both devq->send_opening and dev->ccbq.dev_openings are > 0 ( 256 and 254 ). But we do get stuck in the second one at line 3025. We eventually time out setting start_ccb->ccb_h.status to CAM_CMD_TIMEOUT. The timeout is set with DA_DEFAULT_TIMEOUT (scsi_da.c) which is set to 60, and is used in the call to scsi_read_write. Here is the debug trace: Dumping 1240 MB: ciss_cam_action_io: XPT_SCSI_IO 0:0:0 ciss_get_request: called ciss_start: post command 150 tag 600 ciss_map_request: called ciss_request_map_helper: called ciss_cam_poll: called ciss_perf_done: completed command 150 ciss_perf_done: completed command 150 ciss_complete: called ciss_unmap_request: called ciss_cam_complete: called _ciss_report_request: called ciss_cam_complete: SCSI_STATUS_OK ciss_release_request: called ciss_complete: called ciss_unmap_request: called ciss0: WARNING: completing non-busy request ciss_cam_complete: called _ciss_report_request: called ciss_cam_complete: SCSI_STATUS_OK . . . . after about 60 seconds ciss0: WARNING: completing non-busy request ciss0: WARNING: completed command with no submitter ciss_unmap_request: called . . . This goes on forever Thanks Paul Paul Heyman phey...@adaranetworks.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Problem detecting and reacting to serial break
Paul Thornton wrote: > Ed Schouten wrote: >> * Paul Thornton wrote: >>> I'm using 8.0-RELEASE with uftdi and ucom driving the serial port. >> Somewhat unrelated question: have you ever tried running the this code >> on 7.x? If so, did it work? > > I've just tried this on 7.2-RELEASE (that was the only 7.x CD I could > find lurking about my desk). I've been looking into this a bit deeper, both with 7.2 and on a Linux box I had to hand. I'm using a baud rate of 25 - which of course is non-standard; although the FTDI chip is more than capable of doing it. The tcsetattr does not like setting the baud rate to this - which works without complaint under 8 (I'm guessing this is one of the enhancements). This lack of tcsetattr success is, I suspect, causing my block on the read() call. When I set the rate to 9600, the tcsetattr succeeds, and I do get data coming back from the read - albeit baud barf. I made a quick hack to uftdireg.h and uftdi.c to add a rate of 25 with a divisor of 12 - which results in my tcsetattr now succeeding, and the data read looking more correct. However I'm now back to the same problem as under 8.0 - the break has no effect and the position of data byte 1 wanders around the buffer. With Linux, it all works as expected - but the linux tcsetattr doesn't like the nonstandard baud rate either. However, in linux I used setserial to set a base baud rate of 2400 and a divisor of 96 to get 250k baud rate. When I run, I have a stable buffer dump displayed which always starts with byte 1; so I'm happy that in theory my code is correct and the hardware is behaving as expected. So it seems that the answer is that I get the same behaviour with 7.2 as I did with 8.0. Paul. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Problem detecting and reacting to serial break
Daniel O'Connor wrote: > On 15/08/2010, at 3:00, Paul Thornton wrote: >> So according to the documentation, the effect of the break should be to >> flush the input and output buffers, and send a SIGINT to my process. The >> buffer doesn't seem to get flushed, and I don't get sent the SIGINT. > > It does sounds like it's ignoring your request :( > > However you won't get a SIGINT unless the serial port is the controlling > terminal of your process (which it won't be if you just open()'d it) I realised that about 10 minutes after posting the original mail when re-reading the documentation on termios, thanks for the confirmation though. Part of the problem I'm having is that whenever you try and search for information/docs about this sort of thing, you're transported back in a time warp to the 1980s where people used serial terminals as the norm for access and everything seems to be written from that standpoint - not from a "I'd like to use the serial port for binary data that has nothing to do with interactive login please" perspective... Paul. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Problem detecting and reacting to serial break
Ed Schouten wrote: > * Paul Thornton wrote: >> I'm using 8.0-RELEASE with uftdi and ucom driving the serial port. > > Somewhat unrelated question: have you ever tried running the this code > on 7.x? If so, did it work? I've just tried this on 7.2-RELEASE (that was the only 7.x CD I could find lurking about my desk). Something is clearly quite different between 7 and 8 here: On 7.2, it doesn't like my tcsetattr: [r...@test1 /usr/local/src]# ./dmxrx2 Opened /dev/cuaU0 on file handle 3 before: c_iflag=2106 c_oflag=3 c_cflag=cf00 c_lflag=400 tcsetattr: Invalid argument No amount of fiddling with the options would make it work, so I used stty to set the paramaters of /dev/cuaU0.init to what I wanted: stty -f /dev/cuaU0.init speed 25 -icanon -isig -echo cs8 clocal cstopb cread ignpar -ixany -ixon -ixoff -ignbrk brkint -imaxbel -icrnl ... and re-ran with some more debug ... [r...@test1 /usr/local/src]# ./dmxrx2 Opened /dev/cuaU0 on file handle 3 before: c_iflag=6 c_oflag=3 c_cflag=cf00 c_lflag=400 tcsetattr: Invalid argument after: c_iflag=6 c_oflag=3 c_cflag=8f00 c_lflag=400 calling read with 513 bytes to go ^CCaught a signal: 2 So I now hang in a blocked read(). A quick and dirty test of "hd /dev/cuaU0" gives one line of zeros and then hangs. Under 8.0, this continually dumps the data coming in as you might expect it to. Were there any significant serial changes between 7.x and 8.0 which might explain this? I don't have enough understanding of how FreeBSD's serial internals should work to debug this on my own, but am more than happy to try all suggestions made. Paul. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Problem detecting and reacting to serial break
Hi,
I'm working on a small piece of code that reads a data stream from the
serial port, putting it into a buffer for processing later - for those
interested, it is receiving DMX512 lighting control data - but I'm
having trouble with the detection of a break condition on the serial
line. I'd appreciate any suggestions from anyone.
I'm using 8.0-RELEASE with uftdi and ucom driving the serial port.
The format of this data is very simple - a break is sent, followed by
513 bytes of useful information; then after some arbitrary delay another
break, and the next 513 bytes. So, I think, easy to do this - just wait
for a break and read away.
My problem is that despite setting the port up (as I think) correctly,
the break seems to be ignored at a driver level and it appears as data
byte of 0x00 (what I'd expect to see if IGNBRK was set). This is no
good as I have no way to know where I am in the chunk of 513 bytes of
data, so can't synchronize at all.
I have the following code setting up my serial port:
tcgetattr(fd, &options);
printf("before: c_iflag=%x c_oflag=%x c_cflag=%x c_lflag=%x\n",
options.c_iflag, options.c_oflag,
options.c_cflag, options.c_lflag);
options.c_iflag = (BRKINT | IGNPAR);
options.c_oflag = 0;
options.c_cflag = (CLOCAL | CREAD | CS8 | CSTOPB);
options.c_lflag = 0;
options.c_cc[VMIN] = 513;
options.c_cc[VTIME] = 0;
if (cfsetispeed(&options, BAUDRATE) < 0) {
perror("cfsetispeed");
exit(1);
}
if (cfsetospeed(&options, BAUDRATE) < 0) {
perror("cfsetospeed");
exit(1);
}
if (tcsetattr(fd, TCSANOW, &options) < 0) {
perror("tcsetattr");
exit(1);
}
/* debug test - did anything change? */
tcgetattr(fd, &options);
printf("after: c_iflag=%x c_oflag=%x c_cflag=%x c_lflag=%x\n",
options.c_iflag, options.c_oflag,
options.c_cflag, options.c_lflag);
The debug output shows my set is doing what I expect it to:
before: c_iflag=2005 c_oflag=3 c_cflag=cf00 c_lflag=443
after: c_iflag=6 c_oflag=0 c_cflag=8f00 c_lflag=0
So according to the documentation, the effect of the break should be to
flush the input and output buffers, and send a SIGINT to my process. The
buffer doesn't seem to get flushed, and I don't get sent the SIGINT.
The data I'm getting in my buffer is valid, apart from the fact that I
can't tell where byte 1 is - and every time I run the test program the
location of byte 1 changes arbitrarily depending on what was in the
receive buffer.
Have I missed something here, or is there any other way that I can
detect the presence of the break out-of-band? I cannot make any
assumptions about the 513 bytes that I'm receiving and any combination
of data may be present in there.
Many thanks,
Paul.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Panic: sleeping thread
-- Forwarded message -- From: Paul Halliday Date: Thu, Apr 1, 2010 at 8:38 AM Subject: Re: panic: sleeping thread To: questi...@freebsd.org On Mon, Mar 22, 2010 at 9:28 AM, Paul Halliday wrote: > I have a couple VM's that randomly halt with this error: > > Sleeping thread (tid 10018, pid 1058) owns a non-sleepable lock > panic: sleeping thread > cpuid = 0 > Uptime 11h14m31s > Cannot dump. Device not defined or unavailable. > > FreeBSD 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC > 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > amd64 > > These systems run nightly Nessus scans and these halts are very > sporadic; I can go a week w/o seeing one. > > What should I do to start to troubleshoot this? > > Thanks. > >> There was another panic this morning, different message this time though: >> panic: vm_fault_copy_wired: page missing >> cpuid = 1 >> Uptime: 9d16h58m29s >> Cannot dump. Device not defined or unavailable. Any suggestions? Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
Julian H. Stacey wrote: I really wanted to use Sendmail as a friend knows Sendmail fairly well and I have a Sendmail book, but what I am wanting is the ability to have mail for virtual users, ie I might have 4 admin accounts, ad...@domain1.com ad...@domain2.com ad...@domain3.com and ad...@domain4.com and want all the accounts to be independent of each other and not necessarily have a real UNIX user account. I know I can create 4 different admin accounts say admin1, admin2, admin3, admin4 and then use the "virtual users" table, but I can see that getting a little messy and from the end user's point they are going to have unusual login names. I know I can do this in Postfix, but is it possible in Sendmail? Yes its possible. I do that with sendmail for a friend's domain I host Here's an anonymised real operational sample from my server with comment added ... PS I skimmed but didnt really understand Matthew's posting, (not saying its right or wrong, just didnt grasp it), but I have sendmail working fine for my @berklix.org & for a friend's @surfacevision.com So Paul, you can use sendmail for this if you want. Cheers, Julian Thanks but unfortunately this really wont help me too much. My fault for not posting it before, but I currently have 9 domains (with a likely hood of another couple more being added), with an range from 5 to 15 different email accounts per domain, hence me thinking it might get a little messy with all the UNIX accounts and virtual user table. Cheers Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: To sendmail or to postfix that is the question?
Steven Hartland wrote: Ok so I'm looking to replace our current windows mail server using mdaemon with a FreeBSD solution, having looked around there seems to be differing opinions of which is the best option to go with between sendmail and postfix. ... Any advice, opinions on a full mail solution on FreeBSD would be appreciated. Regards Steve Sorry to hi-jack your thread, but this is also something I am currently looking in to I really wanted to use Sendmail as a friend knows Sendmail fairly well and I have a Sendmail book, but what I am wanting is the ability to have mail for virtual users, ie I might have 4 admin accounts, ad...@domain1.com ad...@domain2.com ad...@domain3.com and ad...@domain4.com and want all the accounts to be independent of each other and not necessarily have a real UNIX user account. I know I can create 4 different admin accounts say admin1, admin2, admin3, admin4 and then use the "virtual users" table, but I can see that getting a little messy and from the end user's point they are going to have unusual login names. I know I can do this in Postfix, but is it possible in Sendmail? Cheers Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: yarrow random generator
Dont these lines (random_yarrow_init function) make it available to set
"seeded" to zero?
SYSCTL_ADD_PROC(&random_clist,
SYSCTL_CHILDREN(random_sys_o),
OID_AUTO, "seeded", CTLTYPE_INT | CTLFLAG_RW,
&random_systat.seeded, 1, random_check_boolean, "I",
"Seeded State");
And also according to Schneier it is a good idea to save state of the PRNG
and restore it on boot to make it
"more seeded".
2009/12/24 Colin Percival
> Hi all,
>
> Looks like there's a bug here, but it doesn't matter since this is dead
> code: .seeded is initialized to 1 and never modified, so we will never
> call into random_yarrow_block.
>
> IIRC this is because there are some places which ask for entropy before
> yarrow is seeded but don't actually need *cryptographic* entropy.
>
> > Thu, Dec 24, 2009 at 03:45:15PM +0300, Paul Graphov wrote:
> >> I've looked at FreeBSD 8.0 cryptographically secure pseudorandom
> >> numbers generator and have a question. It looks like a bug but I'am
> >> not sure.
> >>
> >> In file sys/dev/randomdev.c, function random_read:
> >>
> >> if (!random_systat.seeded)
> >> error = (*random_systat.block)(flag);
> >>
> >> It blocks until PRNG is seeded. For software random generator
> implementation
> >> block method looks as follows, sys/dev/randomdev_soft.c:
> >>
> >> random_yarrow_block(int flag)
> >> {
> >> int error = 0;
> >>
> >> mtx_lock(&random_reseed_mtx);
> >>
> >> /* Blocking logic */
> >> while (random_systat.seeded && !error) {
> >> if (flag & O_NONBLOCK)
> >> error = EWOULDBLOCK;
> >> else {
> >> printf("Entropy device is blocking.\n");
> >> error = msleep(&random_systat,
> >> &random_reseed_mtx,
> >> PUSER | PCATCH, "block", 0);
> >> }
> >> }
> >> mtx_unlock(&random_reseed_mtx);
> >>
> >> return error;
> >> }
> >>
> >> It seems that random_systat.seeded in "while" condition should be
> negated.
> >> Or it will never block actually, or block erroneously until next reseed
> >> (under very rare
> >> conditions)
>
> --
> Colin Percival
> Security Officer, FreeBSD | freebsd.org | The power to serve
> Founder / author, Tarsnap | tarsnap.com | Online backups for the truly
> paranoid
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: yarrow random generator
random_systat.seeded is exported to sysctl? isn't it? In this case If somebody resets it to zero, some "read" goest to "block" and before acquiring mutex it is reseeded, setting it to true, block will never leave the cycle. 2009/12/24 RW > On Thu, 24 Dec 2009 15:45:15 +0300 > Paul Graphov wrote: > > > Hello guys, > > > > I've looked at FreeBSD 8.0 cryptographically secure pseudorandom > > numbers generator and have a question. It looks like a bug but I'am > > not sure. > > > > In file sys/dev/randomdev.c, function random_read: > > > > if (!random_systat.seeded) > > error = (*random_systat.block)(flag); > > > > It blocks until PRNG is seeded. > > random_systat.seeded is initialized to 1 and it's never set to anything > other than 1 > > I got impression that blocking was something that seemed like a good > idea at the time, but fell-off half-way through coding. It's not a > good idea to block /dev/random, without a separate urandom. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
yarrow random generator
Hello guys,
I've looked at FreeBSD 8.0 cryptographically secure pseudorandom
numbers generator and have a question. It looks like a bug but I'am
not sure.
In file sys/dev/randomdev.c, function random_read:
if (!random_systat.seeded)
error = (*random_systat.block)(flag);
It blocks until PRNG is seeded. For software random generator implementation
block method looks as follows, sys/dev/randomdev_soft.c:
random_yarrow_block(int flag)
{
int error = 0;
mtx_lock(&random_reseed_mtx);
/* Blocking logic */
while (random_systat.seeded && !error) {
if (flag & O_NONBLOCK)
error = EWOULDBLOCK;
else {
printf("Entropy device is blocking.\n");
error = msleep(&random_systat,
&random_reseed_mtx,
PUSER | PCATCH, "block", 0);
}
}
mtx_unlock(&random_reseed_mtx);
return error;
}
It seems that random_systat.seeded in "while" condition should be negated.
Or it will never block actually, or block erroneously until next reseed
(under very rare
conditions)
Am I right?
Thanks.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
On 10/23/09, Alexander Best wrote: > Nate Eldredge schrieb am 2009-10-23: >> On Fri, 23 Oct 2009, Antony Mawer wrote: > >> >On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best >> > wrote: >> >>hi everyone, > >> >>together with hugh mahon (the author of ee) i've been trying to >> >>fix a nasty >> >>bug in ee. for some reason ee exits (not crashes) and leaves the >> >>console >> >>corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should >> >>exit all >> >>running ee instances). > >> >I noticed this the other day when working on a new 8.0-RC1 system... >> >in my case I was using putty (Windows ssh client) to access the >> >system >> >and maximised the window I had ee running in, and noticed ee just >> >dumped me straight to the prompt. > >> Seems a good start might be to compile ncurses with -g, link ee >> against it, put a breakpoint on the SIGWINCH handler, and start >> single stepping... > >> -- > >> Nate Eldredge >> n...@thatsmathematics.com > > it seems ncurses registers a standard libc function with SIGWINCH. i started > gdb, loaded ee and did "handle SIGWINCH stop" > > when i do "run" and issue a SIGWINCH to ee this is the output: > > Program received signal SIGWINCH, Window size changed. > 0x281a4063 in read () from /lib/libc.so.7 > > (gdb) nexti > 0x281a4048 in write () from /lib/libc.so.7 > (gdb) nexti > 0x281a4049 in write () from /lib/libc.so.7 > (gdb) nexti > 0x281a404e in write () from /lib/libc.so.7 > (gdb) nexti > 0x281a404f in write () from /lib/libc.so.7 > (gdb) nexti > 0x281a4055 in write () from /lib/libc.so.7 > (gdb) nexti > > Program exited normally. > > so i guess ee calls some ncurses function right at the beginning. that > ncurses > function registers a new function to be called upon SIGWINCH (maybe > exit(3)). Hmm, from my little experience with ncurses, there is no such function bind to SIGWINCH. Even if exit() is called from ncurses that's because ncurses can not handle current state in any reasonable way so exiting is only possible solution, but in such case something should be printed and program should not exit normally. If you start another shell command from ee, and let it be for example vim, once you resize xterm window, vim will still work but ee will start to consume CPU time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysinstall colours
On 10/9/09, Alexander Best wrote: > hi there, > > sysinstall is probably one of those ancient relics everybody tries to avoid > dealing with from a developers point of view but i just found this beautiful > screenie of a (probably) ncurse-based installer: > > http://www.phoronix.net/image.php?id=yoper_2009_beta&image=yoper_dresden_7_lrg > > i was surprised how much better it looks with those nice colours compared to > sysinstall. > > is there any way the sysinstall colours could be adjusted (without a lot of > work) to also feature such beautiful colours? i had a quick look at the > sysinstall, libdialog and ncurses sources and to me it seems that to change > sysinstall's colours the hardcoded values of > > COLOR_BLACK > COLOR_RED > COLOR_GREEN > COLOR_YELLOW > COLOR_BLUE > COLOR_MAGENTA > COLOR_CYAN > COLOR_WHITE > > have to be changed in contrib/ncurses/ncurses/base/lib_color.c or is there > an > easier way? because this would of course affect all apps that are linked to > ncurses. This have nothing to do with ncurses, colors you like simple can not be displayed in current syscons(4) and making support for 256 colors or even true bit color in sysinstall(so that it looks amazing in konsole) is waste of time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Zero-length allocation with posix_memalign()
On 7/5/09, Fabian Keil wrote:
> I recently submitted a patch to the vlc developers that prevents
> a crash on FreeBSD 8.0 by not calling posix_memalign() with a
> size argument of zero.
>
> A simplified test case would be:
>
> #include
> int main(int argc, char **argv) {
> void *ptr;
> posix_memalign(&ptr, 16, 0);
> return (0);
> }
>
> which triggers:
> Assertion failed: (size != 0), function arena_malloc, file
> /usr/src/lib/libc/stdlib/malloc.c, line 3349.
Actually that assertion is triggered only if MALLOC_PRODUCTION is undefined.
(when it is undefined it considerably slows thing down)
'a' flag for malloc.conf looks broken for me
>
> Remi Denis-Courmont, one of the vlc developers, pointed out
> that passing a zero size to posix_memalign() should actually
> work, though:
>
> | In principle, while useless, there is no reason why allocating an empty
> | picture should not be possible. posix_memalign() does support zero-length
> | allocation anyway:
> |
> http://www.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html
> | | If the size of the space requested is 0, the behavior is
> | | implementation-defined; the value returned in memptr shall be either a
> | | null pointer or a unique pointer.
> http://mailman.videolan.org/pipermail/vlc-devel/2009-July/062299.html
>
> I get the impression that this deviation from the standard could be
> easily fixed with something similar to the following, which is mostly
> copy and pasted from malloc():
>
> index 5404798..a078d07 100644
> --- a/malloc.c
> +++ b/malloc.c
> @@ -5303,6 +5303,15 @@ posix_memalign(void **memptr, size_t alignment,
> size_t size)
> int ret;
> void *result;
>
> + if (size == 0) {
> + if (opt_sysv == false)
> + size = 1;
> + else {
> + ret = 0;
> + *memptr = result = NULL;
> + goto RETURN;
> + }
> + }
> if (malloc_init())
> result = NULL;
> else {
>
> I assume the "goto RETURN" isn't entirely compliant either as
> it skips the alignment check, but so does the malloc_init()
> failure branch.
>
> Fabian
>
--
Paul
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: mmap/munmap with zero length
On 7/4/09, Alexander Best wrote: > i'm wondering why mmap and munmap behave differently when it comes to a > length > argument of zero. allocating memory with mmap for a zero length file returns > a > valid pointer to the mapped region. there is V flag for malloc.conf > > munmap however isn't able to remove a mapping with no length. > > wouldn't it be better to either forbid this in mmap or to allow it in > munmap? It wouldn't improve badly written program. -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 7.2-PRERELEASE hangs every time after running airodump-ng on ath0 for a few hours
On 6/10/09, Yuri wrote: > I got this hang twice in the last day. After 2-3 hours of continuously > run airodiump-ng (from net-mgmt/aircrack-ng) system stops responding > to any mouse/keyboard clicks. > > Why would aircrack-ng hang the system? Bugs in ath(4) and device itself can hang system. -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Getting rid of pxeboot loader requests for .gz an .bz2 files
On 5/31/09, Jedrzej Kalinowski wrote: > Hello, > > I've got a FreeBSD CURRENT diskless boot set up. > > In the logs of tftpd-hpa I can see that every and each file from > boot.4th to kernel modules is tried to be fetched in compressed format > (.gz, .bz2) before it is loaded in its pure form by the pxe-enabled loader. > > So the sequence is: file.gz->file.bz2->file. > > I don't have compressed versions of these files in my environment, so I > would like to get rid of these requests. Just to make my boot lighter - > thus faster. > > I'm looking for some hints on how to do it in the sources and I only > found it on lines 88 - 93 of /usr/src/sys/boot/i386/loader/conf.c, namely: > > #ifdef LOADER_GZIP_SUPPORT > &gzipfs_fsops, > #endif > #ifdef LOADER_BZIP2_SUPPORT > &bzipfs_fsops, > #endif > > Is it the correct idea to: > make -C /usr/src/sys/boot -DLOADER_NO_GZIP_SUPPORT > -DLOADER_NO_BZIP2_SUPPORT ? > > Or is it the other place I should look for? /etc/make.conf ? -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: diagnosing freezes (DRI?)
On 4/11/09, xorquew...@googlemail.com wrote: > On 2009-04-11 02:30:40, Paul B. Mahol wrote: >> >> If it locks under X11 then use debug.debugger_on_panic=0 sysctl. >> Not doing this will increase drasticaly chances of locking whole system >> and not providing any debug data. > > I don't seem to have that sysctl. > > You sure that's the correct name? Well if you dont have it, capturing cores should generaly still work. But in this case some kind of serial console is only remaining option. -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: diagnosing freezes (DRI?)
On 4/10/09, xorquew...@googlemail.com wrote: > On 2009-04-10 13:31:33, Robert Noland wrote: >> >> If it is locking the whole system, then a core is really our best shot. >> If you can extract anything useful from xorg.log or setting >> hw.dri.0.debug that also might be of use. >> >> I'm running on 2 cores, but it is possible that some locking issue >> exists. All of the driver specific ioctls are run under a lock though. >> >> robert. > > Ok. I've re-enabled drm.ko and radeon.ko and am running X. I'll leave > the system under load and let you know when it inevitably locks up... > > cheers, If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CURRENT sees only /dev/ad2s1a, but not /dev/ad3s1a
On 4/2/09, Matthias Apitz wrote: > El día Friday, March 27, 2009 a las 05:52:40PM +0100, Paul B. Mahol > escribió: > >> On 3/27/09, Matthias Apitz wrote: >> > >> > Hello, >> > >> > When I boot my EeePC from USB key (/dev/da0s1a) -CURRENT it sees the two >> > SSD >> > only >> > as >> > >> > $ ls -l /dev/ad* >> > /dev/ad2 >> > /dev/ad2s1 >> > /dev/ad2s1a >> > /dev/ad3 >> > /dev/ad3a >> > >> > I can mount /dev/ad2s1a but ofc not /dev/ad3s1a; >> > >> > when I'm booting the RELENG_7 from /dev/ad2s1a itself it looks like >> > this: >> > >> > $ mount >> > /dev/ad2s1a on / (ufs, local, noatime) >> > /dev/ad3s1a on /usr/home (ufs, local, noatime) >> >> CURRENT have replaced geom_bsd with geom_part_bsd >> and that can cause various problems, search current archives for more >> info. > > When I will update the EeePC from USB key (/dev/da0s1a) to CURRENT I > will install into /dev/ad2s1a (with make installworld/installkernel ...) > and I want to keep the partition /dev/ad3s1a as it is; would it be > enough to just do: > > # bsdlabel -w ad3s1 auto > > from CURRENT booted? When you do that, make backups anyway. I dont use bsdlabel/fdisk/sade any more, I use gpart(8) instead. I actually wiped completely old crappy parttion table and replaced it with gpart one, and now I'm using more than 8 labels. -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to increase the max pty's on Freebsd 7.0?
On Wed, Apr 01, 2009 at 11:08:35PM +0200, Ed Schouten wrote: > Hi Kostik, > > * Kostik Belousov wrote: > > Can we switch to %x ? Or even, use some radix encoding of the number, > > to allow alphabetical symbols too ? > > I guess that would break a lot of existing libraries. For example: older > RELENG_7/CURRENT libcs might still use TIOCGPTN. This ioctl just returns > a number that is just printed into a device name using "/dev/pts/%u" as > a format. I also suspect a lot of Linux/Solaris-minded software expects > the names to be in decimal form. Or change 'pts' to, for example, 'pt' so without changing utmp and related stuff we'll have space for a four digit pty number. -- Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CURRENT sees only /dev/ad2s1a, but not /dev/ad3s1a
On 3/27/09, Matthias Apitz wrote: > > Hello, > > When I boot my EeePC from USB key (/dev/da0s1a) -CURRENT it sees the two SSD > only > as > > $ ls -l /dev/ad* > /dev/ad2 > /dev/ad2s1 > /dev/ad2s1a > /dev/ad3 > /dev/ad3a > > I can mount /dev/ad2s1a but ofc not /dev/ad3s1a; > > when I'm booting the RELENG_7 from /dev/ad2s1a itself it looks like this: > > $ mount > /dev/ad2s1a on / (ufs, local, noatime) > /dev/ad3s1a on /usr/home (ufs, local, noatime) CURRENT have replaced geom_bsd with geom_part_bsd and that can cause various problems, search current archives for more info. -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Atheros wireless card keeps losing signal when signal is too weak
On 3/26/09, Yuri wrote: > Sam Leffler wrote: >> Those parameters control the roaming algorithm. The OP didn't >> identify their card, freebsd version, or provide any info about their >> setup or why ifconfig reports "no carrier". It just sounds like >> there's a loss in the signal and freebsd gets a beacon miss and tries >> to reconnect while linux does not. Once the rssi drops to "10" >> (presumably 5dBm) minor variations in the environment can become >> significant (e.g. orientation of a laptop, obstructions, antenna >> quality) and it's impossible to comment on what's happening w/o >> detailed information such as provided by athstats. >> >> FWIW cardbus cards that follow the reference design closely typically >> work pretty well and don't benefit from an external antenna. Vendors >> of cheap designs often scrimp when it comes to the antenna. When >> wireless is inside a case (e.g. a PCI card) then it's worth remoting >> the antenna but you need to be careful about routing the pigtail(s) >> and I can't count the number of times I've tracked problems down to >> faulty cables and/or connections. >> > > I did identify my FreeBSD version and card in my original post, but here > they are again: > 7.1-STABLE > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xcffe-0xcffe irq 16 at device 5.0 on pci0 > > One way or another little cheap laptop card with ndis driver delivers > more steady connection then atheros pci card connected to freebsd. > Maybe like you mentioned Linux has higher tolerance to missing beacons. > Does it make sense to have a parameter "lost beakon tolerance"? Perhaps this is what are you looking for: bmissthreshold count Set the number of consecutive missed beacons at which the station will attempt to roam (i.e., search for a new access point). The count parameter must be in the range 1 to 255; though the upper bound may be reduced according to device capabilities. The default threshold is 7 consecutive missed beacons; but this may be overridden by the device driver. Another name for the bmissthreshold parameter is bmiss. -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Atheros wireless card keeps losing signal when signal is too weak
On 3/25/09, Yuri wrote: > I have Linux box sitting next to FreeBSD box that has a very cheap > Airlink 101 card but it has no problems connecting to my WiFi network. > > Every time when Linux box says that quality of connection drops below > 10/100 FreeBSD box shows "status: no carrier". > Linux connections still function ok. > > I even bought a large WiFi antenna for FreeBSD box but still have this > problem. > > Is there some 'sensitivity' parameter that driver may be setting too low > on the card? I'm only aware of roam:rssi & roam:rate -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to troubleshoot why ath0 can't connect to a passwordless wireless network?
On 2/10/09, Yuri wrote: > Quoting "Sam Leffler" : > >> You seem to say your network is open (no security). If not you need >> to show your network configuration. > > That's right, network is open (no security). > >> tcpdump can be used to tap traffic at 3 layers: 802.3, 802.11, and >> driver. It can be used to identify where packets are lost in the >> hierarchy (if at all). > > 'tcpdump -vv -i ath0' shows nothing when I run 'dhclient ath0' or > 'dhcping -s 255.255.255.255'. dhclient always fails, dhcping > says "no answer". > But tcpdump shows traffic between other hosts on the same network. > >> Assuming packets are going out but not coming back you can sniff >> from a 3rd station to look for traffic in the air but not received. > > No, now packets don't seem to go out at all. I said before that packets > went out when interface in fact was in 'monitor' mode. Really? Try wlandebug(8) to see what 802.11 code is doing vs ath driver. >> Given how little info you posted it's virtually impossible to advise >> you what is wrong. When in doubt c&p real output; describing a >> problem often causes useful info to be left out. > > There is no "real output" from tcpdump, this is a problem. > > How to find out for example why 'sendto' call from dhcping doesn't > result in any packets on ath0 interface which is 'UP' and 'associated'? > > I used this same system to connect to other open WiFi networks without > the problem. So it seems to be network-specific. And it fails only for > certain networks. > > Yuri > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: ZFS and Graphics support for /boot/loader
Hi Oliver, This doesnt work for me. I am booting off a ZFS mirror with GPT partitions (built from current on an amd64). Is there any change of a version of gloader but with ZFS support? Cheers Paul -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Oliver Fromme Sent: 05 February 2009 22:19 To: freebsd-hackers@freebsd.org; freebsd-curr...@freebsd.org Subject: CFT: Graphics support for /boot/loader Hello fellow hackers, Some of you might remember that I'm working on graphics support for our /boot/loader. Unfortunately, progress has been rather slow because of non-FreeBSD-related activity. Anyway, I have now prepared a tarball containing a loader binary for public testing. If you are eager to give it a try, please feel free to do so. It should work with any FreeBSD version on i386 and amd64 platforms. I have posted detailed instructions on the FreeBSD wiki: http://wiki.freebsd.org/OliverFromme/BootLoaderTest Any kind of feedback is welcome. 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 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: KLD: program.ko: depends of kernel - no avaiable
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-unsubscr...@freebsd.org" > -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PRINTF_BUFR_SIZE in freebsd6
On 12/17/08, pluknet wrote: > 2008/12/17 Paul B. Mahol : >> On 12/17/08, 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: >> >> And how big is PRINTF_BUFR_SIZE ? > > Hi. > > I set options PRINTF_BUFR_SIZE=128 > > And maybe it's not enough (?) because I stress-tested server triggering > to appear many kernel messages simultaneously. > I don't know coherence between buffer size and this panic though. How long such kernel messages are? -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PRINTF_BUFR_SIZE in freebsd6
On 12/17/08, 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: And how big is PRINTF_BUFR_SIZE ? -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: Problems with zfsboot loader if raidz present on any drive
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Pegasus Mc >Cleaft >Sent: 07 December 2008 12:17 > To: Doug Rabson > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Problems with zfsboot loader if raidz present on any >drive > > On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: > On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > > > Hello Hackers, > > > > > > Recently and friend and I have been trying to get the new > > > gptzfsboot working on our machines and ran into a interesting > > > problem. > > > > > > Initially I was building the world without the environment > > > variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of > > > course, didnt work very well. Every time the machine booted, it > > > would throw 2 lines after the pin-wheel and then reboot. I > > > couldent read what the lines were it went so fast. > > > > > > My friend had a bit more luck and got his machine working OK with > > > a single drive and later a mirror drive added. > > > > > > I added the environment variable and rebuilt everything and > > > installed. This time, I could see the bios drives and a further 2 > > > lines of ZFS something and a reboot... > > > > > > No matter what I tried, I couldent get the machine to boot up to > > > a point where I could try and fix the problem, so I started > > > pulling devices out and found the following: If there is a raidz > > > pool on any drive (not necessarily the one that you are trying to > > > boot from) the loader dies and reboots the machine. My friend, as > > > an experiment created 3 gpt partitions (in addition to the single > > > partition that he had been previously booted from) on his single > > > drive and made a raidz pool for testing. His machine showed the > > > same condition as mine, however he was able to capture the message > > > before the machine > > > rebooted: > > > > > > > > > ZFS: can only boot from disk or mirror vdevs > > > > > > ZFS: inconsistent nvlist contents > > > > The zfsboot code in current doesn't support raidz or raidz2. I have > > been working on adding that support but its not ready yet. The code > > works in my test harness but crashes instantly when I put it in the > > boot code :(. I should have time to finish debugging it soon. > > Hi Doug, > > In my haste to put a message to the group, I didnt do a very good job > of explaining or give what platform I was working with. > > I set up a single disk pool with the gptzfsboot code on it as a boot drive. > My idea was to have a single disk boot (and after it boots and I can > kill the UFS drive I am currently booting from) convert it to a > mirror. But I have 6 other drives in the machine that I have as a raidz for my /usr/home, et al. > > If the 6 raidz drives are present at boot time, the machine starts to > cyclic reboot just after the pin-wheel. > > The machine I am working on is running FBSD8.0-Current as of midnight > 7/12/2008 and the platform is AMD64. > > If I can help test in any way I would be more than happy to try, or > provide any information necessary.. > > ~Peg Hi Doug, I was working with Peg on this over the weekend. I think I have a patch for this - see http://www.freebsd.org/cgi/query-pr.cgi?pr=129539 The problem was that we were not checking the return code from vdev_init_from_nvlist() on line 726 in /usr/src/sys/boot/zfs/zfsimpl.c Joao, Do you want to try the attached patch? It seems to have fixed the problem, at least on mine and Peg's machine. Cheers Paul zfsimpl.c.patch Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mounting Mac OS .dmg files?
On 11/22/08, Christoph Kukulies <[EMAIL PROTECTED]> wrote: > Since the underlying OS of Mac OS is FreeBSD Wrong. > I'm wondering whether itr is possible to mount a > .dmg file as it is used in Apple software distribution for the Mac OS. I > would like to install an > Apple iPhone configuration utility on my FreeBSD box > (iPhoneConfigurationUtility.dmg). It consists of a > web application that is supposedly capable of doing updates of Apple > iPhones through a web service. > (good for company wide distribution of address book information and > other data that iPhones can hold). Currently not always possible - depends which actual fs is stored in .dmg file. Some time ago there was utility in development which allowed mounting of hfs+ on FreeBSD. There is dmg2iso (but it is not in ports ) -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to troubleshoot wireless problem?
On 11/3/08, Yuri <[EMAIL PROTECTED]> wrote: > My FreeBSD is able to connect to WiFi WEP network 95% of time. > But 5% of time either ifconfig shown "not associated" status or dhclient > fails to get IP address or name resolution isn't functioning > after DHCP exchange is complete. Signal strength is -80:-95. > After a while I am able to connect again. > This happens with both ath0 and ral0 devices. > > In the meantime Linux box sitting next to FreeBSD box has > no problem connecting to the same WiFi network at all times. > > This makes me think that something in FreeBSD isn't working right. > > How can I troubleshoot this problem? > How stable is support for wireless networking in FreeBSD? > > I use this command line: > ifconfig wepmode on ssid my-ssid weptxkey 1 wepkey 0xMYKEY dhcp > on 7.1-PRERELEASE In wlan(4) it is explained in detail how to enable debuging. Also every driver have its own ways to toggle debug options. Note that wlan and driver modules must be compiled with debug enabled(at least it works in that way on CURRENT). Look in NOTES for explanation. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: open(2) and O_NOATIME
On Fri, Oct 31, 2008 at 08:04:48AM +, Igor Mozolevsky wrote: > 2008/10/31 Jeremy Chadwick <[EMAIL PROTECTED]>: > > > ... If that's what you were referring to, then possibly making O_NOATIME > > only to root would be a suitable compromise. > > And no systems are compromised with rootkits?.. utimes(2) allows non-root users to (re)set atime provided they own the file or have write permission. Having O_NOATIME follow the same rules would not break any assumed security any further than utimes(2) already does but greatfully benefit all kind of backup programs. So I'd be more than happy to see O_NOATIME be implemented as I'm currently experimenting with backups to detachable harddisks using rsync and not having a way to reset atime is my one big reason for not deploying this kind of backups with more servers. If you wonder why I'm using rsyng instead of dump or tar, here are two reasons: first the detachable disks are much slower than the systems disks so rsync saves a lot of time and secondly a file-by-file-only-if-changed scheme allows me to efficiently use snapshots on the backup medium. Patching rsync to implement the kind of reset atime as i.e. cpio does looks far more complex than adding O_NOATIME to rsync. My $0.02 Regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Spam ? - Re: Increasing partition size by removing partitions
I dont know if it going to be of any use, but in the past, I have used a free but very low level partition editing tool called Ranish http://www.ranish.com/part/ It does allow for moving of any partitions (or slices in BSD terms) Watch out though, as there is no real checks done against commands you issue (It WILL do exactly what you ask - be it right or wrong) I have used it (v2.44 - the lastest beta version) in the past for moving, growing and shrinking of NTFS and FAT32 partitions with a FreeBSD slice on the drive, just never tried changing a BSD slice it self If I remember right, if you try to run the editor under windows 2000 or XP, it will try to create a bootable floppy disk which might be more useful to FreeBSD users Like I said, it might not be any use in this instance, but probably still worth a look, just incase Paul On Sunday 28 September 2008 02:38:14 Maxim Khitrov wrote: > On Sat, Sep 27, 2008 at 7:22 PM, Aryeh M. Friedman > > <[EMAIL PROTECTED]> wrote: > > I have a disk that is laid out with partion 0 being NTFS and 1 being > > FreeBSD. I want to remove the NTFS partition and grow the FreeBSD one > > but all the docs I have seen only talk about how to do this if the new > > part of the partition is at the end of the partition you wish to grow. > > How do I go about this? > > Assuming that there is no (free) software that will do it for you, and > you are unable for some reason to move the data to another place and > repartition the drive, you have to manually move your FreeBSD > partition back and then extend it. I've never done this before, but if > I had to try it the first time I would do the following: > > 1. Try very hard to find some other hard drive where I can just dump > the data and avoid this whole thing to begin with. :) > 2. Boot from a FreeBSD livecd, attach a usb drive for storing some > temporary files and mount it under /mnt. > 3. Create a back-up of your master boot record (dd if=/dev/ad0 > of=/mnt/mbr-backup bs=512 count=1). Assuming here that your drive is > ad0. > 4. Use fdisk to get the start and size values of your two partitions > (in sectors). > 5. Erase the ntfs partition (dd if=/dev/zero of=/dev/ad0s1 bs=2m). > 6. Copy your FreeBSD partition to the former start location of ntfs > (dd if=/dev/ad0 of=/dev/ad0 bs=512 iseek= > oseek= count=). Using > bs=512 is slow, but it makes it easier for you to just take the > numbers that fdisk gives you and plug them in. > 7. Once this is done you will need to edit your mbr sector to > overwrite the first partition entry with the second, but certain > fields will need to be updated... > > I recommend you use a hex editor and work on the file that you saved > in step 3. You can try the same thing with a partition editor, but you > may not get the desired results. > > For the manual (and more fun) method, the partition table begins at > offset 0x01BE, and each entry is 16 bytes long. That means that you > need to copy 16 bytes starting at address 0x01CE to address 0x01BE. > However, before you do this, you need to set the correct values for > cylinder-head-sector of first and last sectors in the FreeBSD > partition, as well as the logical address of the first sector. > > First, take 3 bytes starting at address 0x01BF and copy them to > 0x01CF. This takes care of CHS start, which is unchanged. Next, take 4 > bytes at address 0x01C6 and copy them to 0x01D6. This is the logical > sector start. The tricky bit is the CHS last sector value. If your two > partitions were of identical size, then you can copy 3 bytes from > 0x01C3 to 0x01D3. Otherwise, you'll need to calculate the new values > by hand. If your NTFS partition was marked as active before, then set > byte 0x01CE to be 0x80. > > One this is done, copy that second record over the first and zero-out > the 16 bytes at 0x01CE. Use dd again to copy the updated mbr sector to > your drive. At this point your master boot record will have the > correct entry for your FreeBSD partition, which was moved over the > NTFS one. See if you can mount /dev/ad0s1a while still in the livecd > environment (actually, you will need to reboot first). If ad0s1a is > under /dev and you can mount it, then your mbr is fine. Use growfs > from here and then boot from the hard drive. > > As you can see, it's not a trivial thing to do, but it's possible if > you are careful. Once again, I've never done this and am basing the > whole thing on some of my previous experience in messing with the > master boot record. There may be some other things that I missed. I > also don't know if there is existing software that might make this > whole process much easier, the directions here are a worst-case >
Re: Increasing partition size by removing partitions
On Sat, Sep 27, 2008 at 07:22:20PM -0400, Aryeh M. Friedman wrote: > I have a disk that is laid out with partion 0 being NTFS and 1 being > FreeBSD. I want to remove the NTFS partition and grow the FreeBSD one but > all the docs I have seen only talk about how to do this if the new part of > the partition is at the end of the partition you wish to grow. How do I > go about this? For clarity, let's use the FreeBSD terminology and call these slices, one NTFS slice and one FreeBSD slice. Partitions are what go in the FreeBSD slice (your root, swap, var and usr aprtitions). Do you really need one big FreeBSD slice? You could remove the NTFS slice and create another FreeBSD slice in that place. To make things workable, be sure to have a standard FreeBSD boot manager in the MBR block by doing something like: # fdisk -B -b /boot/boot0 ad0 Then you can create a disklabel in the new slice holding one or more FreeBSD partitions. Next newfs them and add them to /etc/fstab and mount them. All these steps could be done from the Configure submenu of sysinstall if you're not familiar with the fdisk, bsdlabel and newfs commands. The very brave among us could copy the existing FreeBSD partitions from slice 2 to slice 1, enlarging them if needed and using fdisk and bsdlabel to combine the two slices into one, all depending on the size of the slices. The big issue here is to be aware not to overwrite anything before copying it into its final place. Regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
On 7/4/08, Randy Bush <[EMAIL PROTECTED]> wrote: >> This is why there are precompiled packages on ftp.freebsd.org which you >> can install with 'pkg_add -r'. You can install them from any FTP >> mirror, actually; just point PACKAGEROOT at the mirror: > > why isn't this stuff in the docs? oh, it is! silly me. is the problem > that there are just too much doc or two little reading? > > It is in pkg_add(1), If you are talking about handbook only PACKAGESITE is documented: should get fixed. > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Fwd: Re: Problems with ieee80211 dependencies...]
I dont have such problem with CURRENT; all ieee80211 stuff are build as modules for me, but my conf is different, firewalls and dummynet are build as modules. But I was able to reproduce problem with your config file. Probably conflict arise somewhere within your last 4 lines in conf file. On 6/28/08, Martes Wigglesworth <[EMAIL PROTECTED]> wrote: > > I had to wait for the rebuild process to error out again, however, here > is the resulting segment of output. > > I included the parts that begin to indicates an error. > > > kdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq > -I/usr/src/sys/i386/compile/DATASERVER > /usr/src/sys/modules/zyd/../../dev/usb/if_zyd.c > linking kernel.debug > if_dc.o(.text+0x955): In function `dc_mchash_le': > ../../../dev/dc/if_dc.c:1019: undefined reference to `ether_crc32_le' > if_dc.o(.text+0x9f2): In function `dc_mchash_be': > ../../../dev/dc/if_dc.c:1054: undefined reference to `ether_crc32_be' > if_dc.o(.text+0x1df5): In function `dc_detach': > ../../../dev/dc/if_dc.c:2320: undefined reference to `ether_ifdetach' > if_dc.o(.text+0x42d7): In function `dc_ioctl': > ../../../dev/dc/if_dc.c:3632: undefined reference to `ether_ioctl' > if_dc.o(.text+0x65a5): In function `dc_attach': > ../../../dev/dc/if_dc.c:2270: undefined reference to `ether_ifattach' > if_dc.o(.text+0x65fc):../../../dev/dc/if_dc.c:2278: undefined reference > to `ether_ifdetach' > if_fxp.o(.text+0x2086): In function `fxp_detach': > ../../../dev/fxp/if_fxp.c:919: undefined reference to `ether_ifdetach' > if_fxp.o(.text+0x2402): In function `fxp_ioctl': > ../../../dev/fxp/if_fxp.c:2467: undefined reference to `ether_ioctl' > if_fxp.o(.text+0x429f): In function `fxp_attach': > ../../../dev/fxp/if_fxp.c:789: undefined reference to `ether_ifattach' > if_fxp.o(.text+0x431b):../../../dev/fxp/if_fxp.c:815: undefined > reference to `ether_ifdetach' > if.o(.text+0x1027): In function `if_setlladdr': > ../../../net/if.c:2646: undefined reference to `arp_ifinit' > if_gif.o(.text+0x941): In function `gif_input': > ../../../net/if_gif.c:560: undefined reference to `bridge_input_p' > if_gif.o(.text+0x95b):../../../net/if_gif.c:567: undefined reference to > `ether_demux' > ip_dummynet.o(.text+0x14db): In function `dummynet_send': > ../../../netinet/ip_dummynet.c:908: undefined reference to `bridge_dn_p' > ip_dummynet.o(.text+0x153b):../../../netinet/ip_dummynet.c:926: > undefined reference to `ether_demux' > ip_dummynet.o(.text+0x154c):../../../netinet/ip_dummynet.c:929: > undefined reference to `ether_output_frame' > if_xl.o(.text+0x2078): In function `xl_setmulti_hash': > ../../../pci/if_xl.c:789: undefined reference to `ether_crc32_be' > if_xl.o(.text+0x38f6): In function `xl_detach': > ../../../pci/if_xl.c:1674: undefined reference to `ether_ifdetach' > if_xl.o(.text+0x4712): In function `xl_ioctl': > ../../../pci/if_xl.c:3203: undefined reference to `ether_ioctl' > if_xl.o(.text+0x591d): In function `xl_attach': > ../../../pci/if_xl.c:1564: undefined reference to `ether_ifattach' > if_xl.o(.text+0x5970):../../../pci/if_xl.c:1570: undefined reference to > `ether_ifdetach' > *** Error code 1 > > Stop in /usr/src/sys/i386/compile/DATASERVER. > > >>Nothing jumps out at me, can you send the output of the build failure? >> >>-Kip >> >>On Fri, Jun 27, 2008 at 4:29 PM, Martes Wigglesworth >><[EMAIL PROTECTED]> wrote: >> I am having a hard time compiling a new kernel when I remove the >> wireless aspects of the config file. I have removed all > options/devices >> that seem to still require ieee80211 however, I still find that the >> network section of the compile do not work. I.E. that is where the >> compile stops, and indicates that an unknown reference to ieee80211 >> functions... >> >> What in the GENERIC config file requires ieee80211? I have included my >> config file below: >> >> cpu I686_CPU >> ident DATASERVER >> >> # To statically compile in device wiring instead of /boot/device.hints >> #hints "GENERIC.hints" # Default places to look for >> devices. >> >> makeoptions DEBUG=-g# Build kernel with gdb(1) >> >> options SCHED_ULE # ULE scheduler >> options PREEMPTION # Enable kernel thread >> preemption >> options INET# InterNETworking >> options INET6 # IPv6 communications > protocols >> options SCTP# Stream Control Transmission >> options FFS # Berkeley Fast Filesystem >> options SOFTUPDATES # Enable FFS soft updates >> options UFS_ACL # Support for access control >> options UFS_DIRHASH # Improve performance on big >> options UFS_GJOURNAL# >> options MD_ROOT # MD is a potential root > device >> options PROCFS # Process f
Re: command-line bittorrent utility
On 6/27/08, Kris Kennaway <[EMAIL PROTECTED]> wrote: > Jille Timmermans wrote: >> (enhanced) ctorrent > > Seems to fail requirement a). Am I wrong? > > Kris > enhanced ctorrent is actual ctorrent from ports. it doesnt use ncurses. ldd /usr/local/bin/ctorrent /usr/local/bin/ctorrent: libssl.so.5 => /usr/lib/libssl.so.5 (0x280a7000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280e8000) libm.so.5 => /lib/libm.so.5 (0x281db000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281f4000) libc.so.7 => /lib/libc.so.7 (0x281ff000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x28306000) transmission also doesnt use ncurses. the only one I'm aware of that use ncurses is rtorrent. >> >> Kris Kennaway schreef: >>> I am looking for a command-line utility that can fetch via bittorrent >>> that >>> >>> a) doesn't use curses. It must be usable in a script and without a tty! >>> >>> b) doesn't use X11. Must be a command-line utility! >>> >>> c) Must be able to inform the script when the transfer is complete. A >>> callback mechanism of some kind is fine as long as it doesn't require >>> polling. >>> >>> This is for distribution of files within a LAN and WAN: I have some >>> large files that I need to distribute to many machines, and pushing >>> them all out multiple times from the server is inefficient. >>> >>> Things that come close: >>> >>> * The python implementation, but it doesn't seem to work very >>> reliably. I get errors and exceptions from both the client and server >>> when transferring a file with only two machines participating. >>> >>> * http://www.murmeldjur.se/btpd/ is a daemon with command line client. >>> It doesn't provide for c), and it also doesn't work reliably. >>> >>> * Not much else. >>> >>> Surely I am not the first person to want to use bittorrent in a script? >>> >>> Kris >>> >>> ___ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "[EMAIL PROTECTED]" >> >> > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mplayer pauses when holding a window
I could not reproduce this with fvwm and mplayer (without esoud). But I am aware of following (fv)wm/Xorg issue/bug/feature: if you configured your window manager to not display window when moving it (instead wm display frame) all Xorg windows will be put in suspend state (music will stop playing, and such ...) On 6/5/08, Rui Paulo <[EMAIL PROTECTED]> wrote: > On Thu, Jun 05, 2008 at 09:49:12AM +0200, Harald Servat wrote: >> Hello, >> >> today I was running mplayer playing an streaming url (just audio). There >> was a moment that I holded a(ny) window (i.e., click to move) for a long >> time (about 10-15s) and mplayer paused. >> Have anyone experienced this issue? >> >> I'm running mplayer-0.99.11_4 (I configured it to use esound), >> gnome2-lite-2.22.0, xorg 7.3 on FreeBSD 7.0 (ULE)/ia32. > > This is normal behavior and I think this is a Window Manager issue, not > a FreeBSD issue. > > Regards, > -- > Rui Paulo > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Failure to Project OOImpress
On 3/15/08, KAYVEN RIESE <[EMAIL PROTECTED]> wrote: > On Sat, 15 Mar 2008, Paul B. Mahol wrote: > > > Was it connected prior or after Xorg startup? > > I think we connected prior. Should we have? I had my > computer turned off, and I booted it up. The projector > was on during boot. I thought the boot process would > take care of it but it didn't. > It should not be directly related to system in any way. Googling around, I found that Xorg resolutions and modelines must be configured for projectors in the same way as with second monitors ie creating another display or screen layout in xorg.conf. But is should work "out of box way" if for example projector/monitor support current Xorg resolution. Also there are some problems (found by googling) with gdm and projectors in linux environment (no reasons why it should not happen in freebsd also). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Failure to Project OOImpress
Dont hold me for this: but I remmeber that I read somewhere that if projector is connected before Xorg starts available resolutions to projector would be limited. So best is to disconnect and connect it again when Xorg is already running. Beware: I dont have experience with projectors with Xorg, only with seconds monitors but that is different story. I hope that there are somebody over there with more experience with projectors than me. On 3/15/08, KAYVEN RIESE <[EMAIL PROTECTED]> wrote: > On Sat, 15 Mar 2008, Paul B. Mahol wrote: > > > Was it connected prior or after Xorg startup? > > I think we connected prior. Should we have? I had my > computer turned off, and I booted it up. The projector > was on during boot. I thought the boot process would > take care of it but it didn't. > > > > > On 3/14/08, KAYVEN RIESE <[EMAIL PROTECTED]> wrote: > >> > >> > >> Couldn't connect to projector for presentation. > >> > >> I was supposed to give a class presentation and we tried to hook > >> my computer into the 15 pin female joint (sorry I forget what it is > >> called three rows of 5 pins each on the computer, hooking to 15 pins > >> on the wire) that I guess is usually a monitor connector. The professor > >> kept saying "hit function-f8" but that didn't go. > >> > >> I am running gnome on freeBSD > >> > >> [EMAIL PROTECTED] ~]$ uname -a > >> FreeBSD kv_bsd 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 > UTC > >> 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > >> [EMAIL PROTECTED] ~]$ > >> > >> > >> He said it was all about BIOS, but we were trying to hit func-f8 during > >> gnome running, so I thought > >> I would get a second opinion. > >> > >> Here is a link with pictures of the model decal: > >> > >> http://www.monkeyview.net/id/965/fsck/dmesg/index.vhtml > >> > >> *--* > >>Kayven Riese, BSCS, MS (Physiology and Biophysics) > >>(415) 902 5513 cellular > >>http://kayve.net > >>Webmaster http://ChessYoga.org > >> *--* > >> ___ > >> freebsd-hackers@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > >> > > > > *--* >Kayven Riese, BSCS, MS (Physiology and Biophysics) >(415) 902 5513 cellular >http://kayve.net >Webmaster http://ChessYoga.org > *--* > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Failure to Project OOImpress
Was it connected prior or after Xorg startup? On 3/14/08, KAYVEN RIESE <[EMAIL PROTECTED]> wrote: > > > Couldn't connect to projector for presentation. > > I was supposed to give a class presentation and we tried to hook > my computer into the 15 pin female joint (sorry I forget what it is > called three rows of 5 pins each on the computer, hooking to 15 pins > on the wire) that I guess is usually a monitor connector. The professor > kept saying "hit function-f8" but that didn't go. > > I am running gnome on freeBSD > > [EMAIL PROTECTED] ~]$ uname -a > FreeBSD kv_bsd 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC > 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > [EMAIL PROTECTED] ~]$ > > > He said it was all about BIOS, but we were trying to hit func-f8 during > gnome running, so I thought > I would get a second opinion. > > Here is a link with pictures of the model decal: > > http://www.monkeyview.net/id/965/fsck/dmesg/index.vhtml > > *--* >Kayven Riese, BSCS, MS (Physiology and Biophysics) >(415) 902 5513 cellular >http://kayve.net >Webmaster http://ChessYoga.org > *--* > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Any progress on FreeBSD/xen port?
Hi, For a large project involving virtual servers under Xen I've been asked to advice on using BSD for some services instead of Linux. In the Q2/2007 FreeBSD Status Report work on the FreeBSD/xen port is mentioned but the last report which came in yesterday does not mention Xen at all. Is someone still working on FreeBSD/xen or has work on the project stalled? Is there anything usable, even beta, around which I can use to get a feeling of what's involved in running FreeBSD under Xen? Thanks. Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Tar output mode for installworld
On Sat, Jul 14, 2007 at 11:28:05PM -0700, Tim Kientzle wrote: > >>>This is easy to implement ... just build > >>>a description of the final archive in a nice verbose > >>>text format such as: > >> > >>...which is done by NetBSD for the unprivileged release building via > >>build.sh. Anyone interested in working on this should possibly have a > >>look there. > > Here's a rough implementation of my core idea. Add the > attached archive_read_support_format_ntree.c to libarchive > and patch archive_read_support_format_all.c, then > rebuild libarchive and bsdtar. You'll then be able > to read, extract, etc, a format I'm calling "ntree" > for now. This similar to NetBSD's "metalog" format, except: > > 1) First line must be "#%ntree". This is used as a file signature. > > 2) Blank lines and lines beginning with '#' are ignored. > > 3) All other lines have the following format: > > = = ... > > Where key is one of: > time: decimal seconds since beginning of epoch > gid,uid: decimal group/user ID > gname,uname: textual group/user name > mode: octal > type: as in mtree, defaults to 'file' > content: name of a file on disk Great! This is exactly the next BIG step in (Free)BSD build/distribute/install that I have been waiting for. In the mean time I've been playing a lot with automating and customizing the build/distribute/install process of FreeBSD, partly inspired by nanobsd. Basically the process is something like: __MAKE_CONF=my_make.conf make buildworld __MAKE_CONF=my_make.conf make installworld DESTDIR=/some/place $CUSTOMIZATIONS /some/place tar czf tarball.tgz -C /some/place # Find a way to get the tarball.tgz to its destination tar xpf tarball.tgz# at the destination For the $CUSTOMIZATIONS to work it would be very nice to extend your proposal with the following features: - Allow scattered lines describing attributes of the same file but retain the order in which they appear so that $CUSTOMIZATIONS can override attributes set by make installworld. - Implement something like: remove to undo the installation of files (embedded systems hardly ever need stuff like documentation, NLS and so on but the make.conf and src.conf knobs are not fine-grained enough for all situations) - Implement something like: move= to allow $CUSTOMIZATIONS to move things around. A special case here should be observed: /bin/foo ... ... /bin/foo move=/bin/foo.orig /bin/foo ... here the $CUSTOMIZATIONS move some file so another place and installs a wrapper. Probably a sorting algorithm that retains the order in which /bin/foo lines appear does half the trick and libarchive should collect and accumulate lines with the same filename and only emit or extract a file after the last line with the same name OR when an move= key appears and reset file info immediately after this line. Having a file describing everything that gets installed would also benefit later upgrades to a system. In my experiments I've implemented a manifest that gets shipped with the tarball.tgs (still mean to put it inside but got some ENOTIME errors). My manifest also includes md5 and/or sha256 checksums for each file so the upgrade tool can easily detect which files were altered/moved/removed by the sysadmin an sensibly act accordingly. Again ENOTIME prevented me so far from writing the update tool but I can certainly help out here. If all works out well, this could also benefit ports where a package could be created without installing the port on the build system. Many hurdles to take, I know but certainly a goal to consider. -- Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: exporting subr_param values as sysctls
Alfred Perlstein wrote:
I would like to export the various parameters from subr_param.c
into sysctl, these nodes would include the names from the following
tunables as well as others in these files.
TUNABLE_ULONG_FETCH("kern.maxtsiz", &maxtsiz);
dfldsiz = DFLDSIZ;
TUNABLE_ULONG_FETCH("kern.dfldsiz", &dfldsiz);
maxdsiz = MAXDSIZ;
TUNABLE_ULONG_FETCH("kern.maxdsiz", &maxdsiz);
dflssiz = DFLSSIZ;
TUNABLE_ULONG_FETCH("kern.dflssiz", &dflssiz);
maxssiz = MAXSSIZ;
TUNABLE_ULONG_FETCH("kern.maxssiz", &maxssiz);
sgrowsiz = SGROWSIZ;
TUNABLE_ULONG_FETCH("kern.sgrowsiz", &sgrowsiz);
any objections?
I don't see any obvious way to get at these values on a running
system.
Do it, but you can get them via kenv.. ;)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipv6 connection hash function wanted ...
On Tue, 14 Nov 2006, Max Laier wrote: > this one is something for people who know their math. > > Input: 2x128bit of address (lower ~80bit selectable by user) and 2x16bit > of ports (more or less selectable by user). Note that the "flow_id" is > not useable as several broken stack implementations do not set it > consistently - and it is user settable as well. > Output: "int" hash value - by default we use the lower 8bit of it. > > Problems: Most of the input can be selected by a user meaning it is easy > to produce collisions. For legal connections, the lower 64bit are the > one with the highest entropy - in fact the upper 64bit might be the same > for many connections coming from/going to the same subnet. This function > will be used for every packet that is passed to a dynamic IPFW rule, so > efficiency is a concern. > > Any ideas? Any papers that deal with this problem? > > ref: sys/netinet/ip_fw2.c::hash_packet6 If you are worried about users controlling which values their packets hash to you might want to look at universal hashing. People who are worried about algorithmic denial of service attacks face similar problems. A good place to start would probably be: http://www.cs.rice.edu/~scrosby/hash Paul Twohey [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: VIA Sata Problem maybe?
Hello, thanks for the reply. > You mentioned softupdates. Try disabling softupdates on the file > system. I've had to do this in the past with a sata raid 1 setup or > the system would reboot every few days. I tried that earlier, and it didnt help at all, i got a crash in the minutes after rebooting during fsck. > Also verify the "speed" of > the drives. I had a problem with freebsd 5.3 where it would set my > sata drives as udma33 which caused quite a few problems. How do i check the speed?(although i think it's not linked to that) You may > want to check if there are any updates in stable for the driver you > are using. 6.2 is close to release and while there are several > outstanding issues, it may improve your situation. where can i find a list of the drivers updates? I downloaded the latest HEAD kernel source, but from looking into the GENERIC configuration file, i didnt see anything for a VIA ATA chipset, or is there more than what is in the GENERIC file? Best Regards, Paul-Kenji Cahier >> Hello, >> I am currently experiencing some technical problems with one of my >> remote servers running 6.1-RELEASE(#0: Sun May 7 04:32:43 UTC >> 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC >> i386) with the default kernel. >> Configuration is the following: http://83.149.102.206/lspci.txt >> The problem is basically the following: >> Every few days, the server crashes. Sometimes it reboots, sometimes >> it doesnt. In all cases, there's not a single trace of anything in >> logs(not even a single word in /var/log/messages). >> The problem usually worsens after it auto-reboots itself as it runs >> an fsck at the end of the boot time. That fsck runs, and most of >> the time it crashes again, causing a reboot or a complete freeze, >> then another reboot, etc. Once the system freezes, my only option >> is(since i dont have local access to the server) to remote reboot >> on a rescue os that allows me to set my rescue freebsd partition as >> main, and get a rescue freebsd. Once in, i just fsck the file >> system until it is marked clean and reboot. And everything goes >> fine... >> for a few days. >> Now what i tried was, after an unwanted reboot, to monitor the logs >> of fsck running to see what made it crash. >> Here is what i got from tail -f /var/log/messages(ad4s2f is the / >> usr partition that has most of the data): >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=2615093 (20 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=2615094 (20 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=2615095 (20 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=2615096 (20 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=2615097 (20 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=2615098 (20 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=2615099 (20 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=2615100 (16 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=3674361 (12 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=14994399 (4 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=16016109 (6624 should be 320) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=16016110 (12 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=16016111 (4352 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: INCORRECT BLOCK COUNT >> I=16016112 (8 should be 0) (CORRECTED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: UNREF FILE I=6 >> OWNER=root MODE=100400 >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: SIZE=151445575864 >> MTIME=Sep 29 19:02 2006 (CLEARED) >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: ALLOCATED FRAGS >> 431136-431167 MARKED FREE >> Sep 29 19:31:54 arcueid fsck: >> Sep 29 19:31:54 arcueid fsck: /dev/ad4s2f: UNEXPECTED SOFT UPDATE >> INCONSISTENCY; RUN fsck MANUALLY. >> And then the server went more or less haywire and crashed(no other >> input in /var/log/messages though) &g
VIA Sata Problem maybe?
fine too, with no particular events. The hard drive itself was tested extensively using both smart values and writing/reading from a linux setup and had not a single fault or alarming value. Another quite surprising event is the following: After a crash, i went into the rescue freebsd and as usual started an fsck. Result was: arcueid-rescue# fsck -y /dev/ad4s2f ** /dev/ad4s2f ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1362084 files, 47944480 used, 23676944 free (1752392 frags, 2740569 blocks, 2.4% fragmentation) * FILE SYSTEM MARKED CLEAN * Just for the fun i ran it a second time just after: arcueid-rescue# fsck -y /dev/ad4s2f ** /dev/ad4s2f ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes CANNOT READ BLK: 190083360 UNEXPECTED SOFT UPDATE INCONSISTENCY CONTINUE? yes THE FOLLOWING DISK SECTORS COULD NOT BE READ: 190083360, 190083361, 190083362, 190083363, 190083364, 190083365, 190083366, 190083367, 190083368, 190083369, 190083370, 190083371, 190083372, 190083373, 190083374, 190083375, 190083376, 190083377, 190083378, 190083379, 190083380, 190083381, 190083382, 190083383, 190083384, 190083385, 190083386, 190083387, 190083388, 190083389, 190083390, 190083391, INCORRECT BLOCK COUNT I=18375172 (640 should be 416) CORRECT? yes CANNOT READ BLK: 293557088 UNEXPECTED SOFT UPDATE INCONSISTENCY CONTINUE? yes THE FOLLOWING DISK SECTORS COULD NOT BE READ: 293557088, 293557089, 293557090, 293557091, 293557092, 293557093, 293557094, 293557095, 293557096, 293557097, 293557098, 293557099, 293557100, 293557101, 293557102, 293557103, 293557104, 293557105, 293557106, 293557107, 293557108, 293557109, 293557110, 293557111, 293557112, 293557113, 293557114, 293557115, 293557116, 293557117, 293557118, 293557119, CANNOT READ BLK: 190090784 UNEXPECTED SOFT UPDATE INCONSISTENCY CONTINUE? yes THE FOLLOWING DISK SECTORS COULD NOT BE READ: 190090784, 190090785, 190090786, 190090787, 190090788, 190090789, 190090790, 190090791, 190090792, 190090793, 190090794, 190090795, 190090796, 190090797, 190090798, 190090799, 190090800, 190090801, 190090802, 190090803, 190090804, 190090805, 190090806, 190090807, 190090808, 190090809, 190090810, 190090811, 190090812, 190090813, 190090814, 190090815, INCORRECT BLOCK COUNT I=18375174 (480 should be 416) CORRECT? yes CANNOT READ BLK: 190122624 UNEXPECTED SOFT UPDATE INCONSISTENCY CONTINUE? yes THE FOLLOWING DISK SECTORS COULD NOT BE READ: 190122624, 190122625, 190122626, 190122627, 190122628, 190122629, 190122630, 190122631, 190122632, 190122633, 190122634, 190122635, 190122636, 190122637, 190122638, 190122639, 190122640, 190122641, 190122642, 190122643, 190122644, 190122645, 190122646, 190122647, 190122648, 190122649, 190122650, 190122651, 190122652, 190122653, 190122654, 190122655, INCORRECT BLOCK COUNT I=18375178 (512 should be 416) CORRECT? yes CANNOT READ BLK: 190422528 UNEXPECTED SOFT UPDATE INCONSISTENCY CONTINUE? yes [etc] And then it crashed Again i did the sata tests numerous times and the drive seems perfectly healthy... So i have to think it might be driver related rather than hardware related. Any help would be appreciated, -- Best regards, Paul-Kenji ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Question regarding bus_dma_tag_create().
I posted this onto freebsd-questions a couple of days
ago but received no reply. Hopefully this is a more
appropriate audience.
The man page for bus_dma_map_create() says this about
the "nsegments" parameter:
Number of discontinuities (scatter/gather seg-
ments) allowed in a DMA mapped region. If there
is no restriction, BUS_SPACE_UNRESTRICTED may be
specified.
BUS_SPACE_UNRESTRICTED is #defined as (~0).
Then, in busdma_map_create() and busdma_mem_alloc():
if (dmat->segments == NULL) {
dmat->segments = (bus_dma_segment_t *)malloc(
sizeof(bus_dma_segment_t) * dmat->nsegments,
M_DEVBUF,
M_NOWAIT);
...
}
I don't understand how this works when
BUS_SPACE_UNRESTRICTED is specified. The malloc will
be fed a -8 (or -12 with PAE) on i386.
I'm reviewing a driver at work that specifies
nsegments = 0, which I think is invalid, but in
reading the man page I came across this ~0 option,
which I've also seen in other FreeBSD drivers and I
just don't get it.
I hope someone can clue me in.
Thanks,
Paul.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
