Re: limits for run away Firefox ?
On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: > On 01/18/10 11:29, Oliver Fromme wrote: > > Doug Barton wrote: > > > On 01/17/10 17:07, Julian H. Stacey wrote: > > > > Hi hackers > > > > I'm tired of my X server occasionaly freezing, swap thrasing, & > > firefox dumps: > > > > 4,346,937,344 ~/firefox-bin.core > > > > so as a temporary cludge I ran > > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > > > > > > Sorry I don't have a solution to your actual problem, but a better way > > > to deal with this is to do: ln -s /dev/null ~/firefox-bin.core > > > > I think not generating a core dump at all is better than > > writing 4 GB to /dev/null. > > A) The method I proposed is useful for other things too, and as you > pointed out it can sometimes be difficult to track down all the ways a > given thing is started. What about just adding the limit command to the /usr/local/bin/firefox script? That would guarantee any instantiation of firefox wouldn't dump core. > B) If we're going to be snarky, it would be far better if it didn't need > to dump core in the first place. :) I don't think that Oliver was at all snarky. He was merely suggesting a solution which would prevent the core file from being generated at all; the OP was tired of the extra time spent and Oliver's suggestion would certainly reduce this time. The symlink seems to hackish to me, although I've had to use it often in other situations. And in some cases the culprit would unlink(2) it first, so I've had to "chflags noschg" it, which works better than "chmod 000" (if the FS supports it). But I agree that it would be nice to prevent ffox from segfaulting; unfortunately this is one of those apps which segfaults a lot (for me at least). =) Cheers, -- Rick C. Petty ___ 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: Deprecating ps(1)s -w switch
On Tue, Aug 25, 2009 at 04:09:09PM +0200, Jonathan McKeown wrote: > > I usually want to see ps(1) output in easily-read columns. Without width > limits, this can't be guaranteed. > > I would strongly object to the complete removal of any option to limit the > output width of ps(1) and make it easily human-readable. > > I'm also astonished at the suggestion that not using -ww is ``a mistake''. I > very seldom need to see the whole commandline for every process. Then you must not use Java much. I almost always need the -ww option. I'm fine with the default being "fit into my terminal width", but I'd be for one option to specify limited width and another option (-w) to specify "as wide as possible". -- Rick C. Petty ___ 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: c question: *printf'ing arrays
On Tue, Jun 30, 2009 at 08:21:03PM +0200, Alexander Best wrote:
> thanks. now the output gets redirected using >. i'm quite new to programming
> under unix. sorry for the inconvenience.
No problem; we all had to learn sometime. But what I suggested should
work for every platform that adheres to POSIX. If you were using
fprintf/fwrite, then it would work on anything that's standard C. As for
redirection, windows command line allows the same type of redirection.
> so i guess there is no really easy way to output an inhomogeneous struct to
> stdout without using a loop to output each array contained in the struct.
That's not something C would ever provide easily. You may want to use a
different high-level language. However, I often use macros for printing
pieces of structures, for example I used this to print out sizes of kernel
structures:
#define SIZE(astruct, member) \
printf("%d\t\t.%s\n", sizeof(astruct.member), #member)
#include
...
struct ktr_header header;
struct ktr_genio genio;
printf("%d\tktr_header:\n", sizeof(header));
SIZE(header, ktr_len);
SIZE(header, ktr_type);
SIZE(header, ktr_pid);
SIZE(header, ktr_comm);
SIZE(header, ktr_time);
SIZE(header, ktr_time.tv_sec);
SIZE(header, ktr_time.tv_sec);
SIZE(header, ktr_tid);
printf("\n%d\tktr_genio:\n", sizeof(genio));
SIZE(genio, ktr_fd);
SIZE(genio, ktr_rw);
In your case, you could make a macro for each type. Without an example of
how you want the output to look, it's hard for us to show you code that
will produce such output.
-- Rick C. Petty
___
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: c question: *printf'ing arrays
On Tue, Jun 30, 2009 at 08:03:21PM +0200, Alexander Best wrote:
> should be stdout.
>
>
> struct Header *hdr = rom;
>
> int new_fd = open("/dev/stdout", O_RDWR);
> printf("SIZE: %d\n",sizeof(*hdr));
> write(new_fd, hdr, sizeof(*hdr));
> close(new_fd);
Why are you reopening stdout? It should already be open, so use
"fileno(stdout)" or just plain "STDOUT_FILENO" instead of "new_fd".
-- Rick C. Petty
___
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: dd copy of FreeBSD-7.2 won't boot
On Wed, Jun 24, 2009 at 11:11:21PM +0100, krad wrote: > Personally id stay away from dd. Create the partitions and file systems > manually, and install the boot loader, then rsync the data across. It will > be a lot faster in most cases, as unlike dd you wont be copying unused > space. Something like this should do the job I wouldn't say rsync is faster than dd, unless you have a lot of empty space or are migrating across a network. The nice thing about rsync is it if you restart it, it picks up where it left off so to speak. With dd you have to add two arguments. > Rsync -aPH --exclude=/mnt/** / /mnt ^ I often use: rsync -avHSPx / /mnt The "x" means don't cross file system boundaries, which is generally what you want when migrating file systems. > I'm assuming you weren't migrating due to a bad disk Actually using rsync to migrate a bad disk is preferrable over dd (presuming you have no backup), since rsync will skip and warn you aboud bad files, but "dd conv=noerror" could leave you in a bad situation if it skips over critical metadata blocks. I always try rsync first, with the source filesystem mounted read-only, and if that fails I'll fall back to dd. Actually if you have the space and it was a bad disk, I'd probably dd to a new disk or file, then mount that disk or file read-only, and then use rsync. -- Rick C. Petty ___ 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: Loader reading FAT
On Tue, Jun 16, 2009 at 11:50:38PM +0930, Daniel O'Connor wrote: > > Unfortunately I can't get the loader to read a FAT partition which > surprises me because I think it should be able to.. I believe that > libstand can do it (I can see the code :) however when I list the USB > stick device I get an empty directory listing. I read somewhere that there isn't enough space in the boot2 loader to put such logic. You're only guaranteed 15 512-byte sectors or 7680 bytes, if you use any UFS partition. It's pretty tight; I think you will find it difficult to insert another file system in there, especially one as complicated as msdos. libstand is 223 KB, so it's not as trivial as you think. Theoretically it would be possible: for example, if you're willing to set aside a separate partition you would have as much room as you want. Or if you put it at the front of a UFS partition, you have just under 256 KB of room since our UFS code will search for the superblock at a byte offset of 262144, but there aren't any knobs to newfs so you'd have to hack it together. Take a look at /usr/src/sys/boot/i386/boot2/ for starters. -- Rick C. Petty ___ 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: In search of a video card
On Thu, May 14, 2009 at 04:10:07PM +0930, Daniel O'Connor wrote: > > Depends how unaccelerated it is. > > VESA is pretty damn slow, but even minimal radeon/radeonhd support is > fast enough for desktop use. VESA doesn't support dual-head, if that's something you're looking for. And I agree that it's particularly slow even in 2d. -- Rick C. Petty ___ 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: In search of a video card
On Thu, May 14, 2009 at 01:42:20PM +0800, Adrian Chadd wrote: > > I've experienced no-acceleration radeon driver "desktop" under Ubuntu > and FreeBSD; let me please point out how sluggish and horribly slow it > is. > > I gave up trying to get accelerated 3d + dualhead support on the > card(s) I was using - apparently the hardware just didn't do a single > viewport span across 2 1280x1024 screens :( > (The max viewport width was 2048 pixels..) With the nvidia driver I've seen great 3d acceleration work on both heads without using twinview (because I want different resolutions on each head). Perhaps the ATI hardware isn't capable of this, but nvidia's cards seem to be. It's too bad the open source drivers haven't made enough progress in this area yet. -- Rick C. Petty ___ 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: In search of a video card
On Wed, May 13, 2009 at 08:06:34PM -0700, Josef Grosch wrote: > > So, can any one recommend a good video card? What I'm looking for is > > * Works with amd64 FreeBSD 7.2 > * DVI > * PCI-E x16 > * 512 MB or more > * Not going to cost an arm and a leg I just bought an nVidia and an ATI on newegg for under $30 each (plus mail-in rebates), buth PCI x16, DVI+VGA, 512MB. I have tried them both on amd64 and this is what I've discovered: - The ATI is quite fast for xvideo (via mplayer) and somewhat fast on 3D, there seems to be some cursor-related artifacts (I've tried a number of cards with the same results). - The nVidia card required Robert Noland's patches applied against RELENG_7, and the latest git checkouts of the nouveau driver and the libdrm code. I forcibly installed xf86-video-nouveau and then "gmake install"'d the nouveau build on top of it. I did the same for libdrm. It was very slow for xvideo (mplayer) and 3D acceleration was nonexistent. I could not get the "nv" driver to work in dual-head mode nor in single-head mode. Nouveau didn't support my onboard card either. Neither of these drivers comes remotely close to the performance of the same cards using the nvidia driver (on i386). I tried ati and nouveau on i386 for comparisons. The nvidia driver did support my onboard video. I ran these tests on a couple of ATI cards and various nvidia cards. It was very frustrating. I'm using the ati/radeon driver currently on amd64 until nvidia finishes their 64-bit driver. YMMV, -- Rick C. Petty ___ 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: C99: Suggestions for style(9)
On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote: > > This is the biggest one, and I think it may be too soon. Also, we > need to be careful on the initialization side of things because we > currently have a lot of code that looks like: > > > struct foo *fp; > struct bar *bp; > > fp = get_foo(); > if (!fp) return; > bp = fp->bp; > > this can't easily be translated to the more natural: > > struct foo *fp = get_foo(); > struct bar *bp = fp->bp; > > since really you'd want to write: > > struct foo *fp = get_foo(); > if (!fp) return; > struct bar *bp = fp->bp; > > which isn't legal in 'C'. I thought we were talking about C99, in which case this is perfectly legal. I certainly use it all the time in my C99 code. And I thought this was the point of this discussion, to be able to declare variables when you first use them. -- Rick C. Petty ___ 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: Spin down HDD after disk sync or before power off
On Sun, Mar 08, 2009 at 01:36:09PM +0100, Bernd Walter wrote: > On Fri, Mar 06, 2009 at 03:47:38PM -0600, Rick C. Petty wrote: > > On Fri, Mar 06, 2009 at 03:30:14PM -0600, Octavian Covalschi wrote: > > > Why is spinning down is bad for HDD ? I believe it's better to spindown a > > > drive, > > > instead of cutting power too sudden. > > > > Comparing those two, I'd say it shouldn't matter (although probably a > > forced spindown may be better). But pulling power from a drive does not > > mean the drive immediately stops doing stuff. > > My understanding is that without power the heads just slamm into > landing zone, while it can be done in a controlled smooth way with > power. Nope, according to a coworker (whose wife works for an HDD manufacturer), the spindle motor is shunted and the generated electricity is used to properly land the head. My coworker also tells me that some new drives are actually parking the heads off the disk, which as I understand is a much more difficult task since you have to worry about vertical separation when you bring the heads back between the platters. > > I was just saying spindown on disks is bad in the first place. Sure, you > > might save some wear and tear on the bearings, but you risk problems with > > the heads on both spindown and spinup. In other words, if you can avoid > > power-cycling your drives, they should last longer (in that you're less > > likely to destroy the heads). > > This depends on the disks. > Desktop and especially mobile drives are designed to sustain more > spin downs, but are not designed for rotating a long time. > But of course if you intend to spin up directly after spin down it > might be bad for them as well, since it isn't really saving spinning > time. That may be; I know nothing about differences with mobile drives. If this is true, I'd like to find some replacement 2.5" drives which are intended for continuous spinning. > This is nothing, which should be done on reboot, but for halts it > might be reasonable to do. Not sure what you're trying to say here, but I am for the idea of issuing a spindown request if we know the power is to be cycled. If spindown are issued for all halts, I hope someone makes that a kernel tunable. What I was hoping is that someone could point me to the "spinup" command as I have a drive which does not spin up until it receives this command. Any takers? -- Rick C. Petty ___ 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: Spin down HDD after disk sync or before power off
On Fri, Mar 06, 2009 at 03:30:14PM -0600, Octavian Covalschi wrote: > Why is spinning down is bad for HDD ? I believe it's better to spindown a > drive, > instead of cutting power too sudden. Comparing those two, I'd say it shouldn't matter (although probably a forced spindown may be better). But pulling power from a drive does not mean the drive immediately stops doing stuff. I was just saying spindown on disks is bad in the first place. Sure, you might save some wear and tear on the bearings, but you risk problems with the heads on both spindown and spinup. In other words, if you can avoid power-cycling your drives, they should last longer (in that you're less likely to destroy the heads). -- Rick C. Petty ___ 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: Spin down HDD after disk sync or before power off
On Wed, Mar 04, 2009 at 08:56:14PM +0100, Joerg Sonnenberger wrote: > On Wed, Mar 04, 2009 at 08:38:52PM +0100, Oliver Fromme wrote: > > Octavian Covalschi wrote: > > > I'm looking a way to spin down HDD just right before power off. Why? > > > > > > Because currently when I call "shutdown -p now", HDD is powered off at > > it's > > > full speed (7200.4) and as a result > > > I hear a noise of stopping/spinning down of HDD, and _this_ concerns me > > as > > > I'm afraid it can damage HDD. > > > > You don't have to spin down a disk before powering it off. > > The noise you hear is probably caused by the "autopark" > > feature of the drive. It is harmless. > > This is not true. Many hard disks don't like having to do an emergency > shutdown as it affects the disk life time negatively. That's what > happens if you poweroff the machine when the disks are still spinning. I believe you are incorrect. Most hard drives do an "autopark" of the head into the landing zone (which is near the spindle) when power is lost. My understanding is that because it is spinning so fast, the heads can fly for quite a long time so the HDD has enough time to autopark and such an operation does not consume much power. Thus the operation can be performed with a little capacitance or by using some of the mechanical energy in the spindle. If drives did not auto, there would be orders of magnitude more failures due to head crashes. The heads absolutely have to be retracted into the landing zone if the spindle speed is too low or the drive will fail. What's actually bad for the drives is the actual spinup and spindowns, which require the head to sit in the very bumpy landing zone until the drive reaches optimal spindle speed and thus enough airflow to safely move the heads around the platter without contact. Strangely, atacontrol(8) has a command for spindown (which is inherently bad for drives yet still a reasonable feature) but there is no command for spinup. I wish there was a spinup command because I've seen drives that won't do a spinup until they receive a special ATA command. I was never able to find any docs, so if anyone knows the command I'd be willing to write a patch against atacontrol! -- Rick C. Petty ___ 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: /dev/dsp* & /dev/audio* devices not present
ou argue for precedence. > actually has that device attached. Why would we want to trash that > concept by allowing the existence of phantom drivers, which have no > presence in /dev unless/until they have been opened? The drivers aren't phantom-- their instances are. > > Why is it suboptimal? > > As in the case of the OP, it is suboptimal from the standpoint of > a human who wants to know what devices and drivers exist in the > system You mean a human who does not understand enough about devfs to know its design quirks? This same human who does not care to look in /var/run/dmesg.boot? This same human who expects FreeBSD to behave as any other OS when it comes to device drivers and doesn't know to check /dev/sndstat? That's not what I think about when I hear the word "suboptimal". I think you're trying to argue that certain devfs semantics are confusing to beginners. I would call that perhaps "confusing" or perhaps "misleading" (which is a stretch). > -- AFAIK the output of ls(1) is intended primarily for human > consumption. Of course, for ls(1) to do its job, readdir(2) has to > provide the data. ls(1) is doing its job. Perhaps your argument for having one non-phantom device node appear for each driver is useful, but don't discount the utility and flexibility of phantom nodes in other cases. I agree that better documentation would also help. So I look forward to your patches for either of these areas. > > I think you have that backwards-- it's more optimal not to have to > > create superfluous device nodes when they are not needed, at least > > from the kernel efficiency perspective. > > If /dev/tun does not exist, how does an open on it succeed? Who says it doesn't exist? The open succeeds so it apparently does exist. In unix, there's never been a guarantee that after you readdir that an open will succeed, nor that a subsequent readdir will show the file you've opened. > Either there is special-case code that somehow scans the list of > installed drivers in addition to examining the contents of /dev, or > the node actually exists but readdir avoids reporting its existence. I don't think you understand how devices work (specifically, pseudo devices). You may wish to look at make_dev(9) and maybe source code for a device driver. > Either way, the kernel is having to do extra work to maintain the > disagreement between the contents of the directory as reported by > readdir and the list of names that are known to open. No, I believe it's less work this way, but I'm no expert here. I did not design devfs nor did I like it myself initially, but after time I grew to prefer it and its behavior. This issue about invisible device nodes has come up numerous times in the past and I believe its proponents and opponents have argued it to death which is why no one else is speaking up now. I encourage you to submit patches. Either you will find it more difficult your way or you may have a difficult time convincing others of its necessity. Just disagreeing with me will not change anything. -- Rick C. Petty ___ 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: /dev/dsp* & /dev/audio* devices not present
On Sat, Jan 10, 2009 at 04:20:58AM -0800, per...@pluto.rain.com wrote: > "Rick C. Petty" wrote: > > > > That's not how devfs works. It's actually a feature > > that devfs doesn't list everything ever possible > > http://storage9.myopera.com/freejerk/files/bug-feature.jpg Funny. But this isn't a bug disguised as a feature. It's a feature that you believe is a bug. > > I'd rather be able to list to see things that are in use, although > > at first glance I didn't like devfs hidden nodes. Otherwise you'd > > be stuck printing tunXXX through infinity instead of this: > > > > % ls /dev/tun* > > /dev/tun0 /dev/tun115 /dev/tun194 > > In any other part of the directory tree we expect ls to provide > a list of names that are available to be opened (subject to > permissions). Why should /dev be any different? Because it's a special filesystem. > Since you aren't supposed to open (say) /dev/tun85, but only > /dev/tun0, correspondence between readdir and open would not demand What? Why aren't you supposed to open tun85? I use this behavior all the time and have for years. It helps keep track of things. Otherwise I would have to keep my natd configuration, firewall rules, and openvpn configuration all in sync. Please provide a reference describing you're not "supposed to" open any arbitrary tunnelling device. > that readdir return the (large, if not infinite) list of potential > instances. It would however seem reasonable for that ls command to > show /dev/tun0 if its driver is loaded, even if the device has not > been instantiated because the node has never been opened. I don't buy that argument at all. If anything it should show "/dev/tun", but why create device nodes when they aren't necessary, as you have to clone the nodes (or create new ones) when an actual open(2) occurs? > > This is not a bug, it is designed behavior. It was intentionally > > written to dynamically create device nodes when needed. > > That the code faithfully adheres to the design does not guarantee > that the design is flawless. IMO it violates POLA, if not POSIX, Please provide the reference where it violates POSIX. > for open(2) to succeed when applied to a name which, according to > readdir(2), does not exist; What? This can happen already-- there is no atomicity between a readdir and an open. And what about msdosfs and case-insensitivity? You can certainly open files that weren't a part of your readdir. Also no one in their right mind would be coding a readdir/open solution against a filesystem known to be completely dynamic and especially against devfs. You would want to tie in directly to devctl, sysctl, or syscall. > and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. Why is it suboptimal? I think you have that backwards-- it's more optimal not to have to create superfluous device nodes when they are not needed, at least from the kernel efficiency perspective. -- Rick C. Petty ___ 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: /dev/dsp* & /dev/audio* devices not present
On Thu, Jan 08, 2009 at 09:50:47PM -0800, per...@pluto.rain.com wrote: > > In principle, everything that would be successfully created if > open(2)'ed. It doesn't necessarily need to actually create them, > but the results from readdir(2) should be as if they had been > created. The whole point of things like ls(1) and readdir(2) is > to find out what-all is available to be opened, without having to > already know the answer. That's not how devfs works. It's actually a feature that devfs doesn't list everything ever possible (things looked terrible back in the old MAKEDEV days with all those polluted names). I'd rather be able to list to see things that are in use, although at first glance I didn't like devfs hidden nodes. Otherwise you'd be stuck printing tunXXX through infinity instead of this: % ls /dev/tun* /dev/tun0 /dev/tun115 /dev/tun194 Maybe you could argue that dsp should work differently, but some sound cards and configurations would give you infinite (within reason) device nodes, IIRC. > > This is a FAQ really. > > It may be an FAQ, but it is also a bug, granted one that may not be > easy to fix. This is not a bug, it is designed behavior. It was intentionally written to dynamically create device nodes when needed. -- Rick C. Petty ___ 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: missing mount_devfs
On Thu, Dec 18, 2008 at 12:18:14AM +0100, oxy wrote: > > I installed 7.0-RELEASE/amd64 and tried to create a jail with jailctl. > after a couple errors i noticed that mount_devfs is missing! > is there any other way to create devfs in order to make jails? > thank you! What about: "mount -t devfs devfs /dev" I believe I saw recently that devfs mounts were merged into standard mount code. -- Rick C. Petty ___ 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: Strange "changed paths" in svn commits
On Fri, Dec 12, 2008 at 08:21:25AM -0800, Tim Kientzle wrote: > Rick C. Petty wrote: > >On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote: > > > >I suspect you've run into a well-known svn bug that affects "svn merge". I > >thought they had fixed it with subversion 1.5.4, but apparently it's still > >around. When doing a merge, it seems to randomly touch a bunch of files.. > >it only updates the svn:mergeinfo property on those files ... > > I've seen this happen only once and eventually figured > out that I had a partial checkout underneath the merge point. > It was especially confusing in my case because I actually > had a complete checkout---nothing was missing---but > one of the directories was marked "depth=immediates" > so it was treated as a partial checkout. > > If the svn:mergeinfo has asterisks in it, this is why. In my case, I had a fresh copy that I merged a single file into, but it touched 5 other random files; files I had never seen, much less ever edited. We've seen this behavior for weeks, but the rate of occurances dropped significantly with svn 1.5.4-- dropped, not disappeared completely. -- Rick C. Petty ___ 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: Strange "changed paths" in svn commits
On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote: > Hi, > > Is it how merging works or I'm missing something? I suspect you've run into a well-known svn bug that affects "svn merge". I thought they had fixed it with subversion 1.5.4, but apparently it's still around. When doing a merge, it seems to randomly touch a bunch of files.. it only updates the svn:mergeinfo property on those files, but it's still annoying. Whenever I do a merge, I always merge into a working copy, then double-check the work with "svn diff" before committing. When I see it bring in extra files, I just do a revert on those, then the commit is clean. I'm hoping the tigris folks are working on this issue. -- Rick C. Petty ___ 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 boot menu is missing
On Thu, Nov 27, 2008 at 11:45:10AM +0100, Dag-Erling Smørgrav wrote: > > Just make sure you leave a few unallocated blocks at the end of the disk > (for gmirror metadata). In most cases, this happens automatically, Well, you only need to leave room for 512 bytes or one hard drive sector, in the case of gmirror. I've never seen a drive that ends exactly on a cylinder boundary; hardware RAID assumes this too. I would like to hear of a drive which is an exact cylinder multiple and how hardware RAID handles those situations. I always just assume there's extra space that's not consumed. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: local network throughput issues
On Sat, Aug 16, 2008 at 03:15:35PM -0700, Jeremy Chadwick wrote: > > 1) Please provide netstat -in output. NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll nfe0 1500 00:15:f2:17:0c:20 14714298 0 14821857 0 0 nfe0 1500 172.23.20.0/2 172.23.20.12144815 - 12438012 - - nfe0 1500 192.168.0.0/2 192.168.0.39502416 - 2357751 - - lo0 1638431707 031707 0 0 lo0 16384 fe80:2::1/64 fe80:2::10 -0 - - lo0 16384 ::1/128 ::1 6 -6 - - lo0 16384 127.0.0.0/8 127.0.0.131588 -31588 - - tun11 1500 985877 0 890589 0 0 tun11 1500 172.23.23.20/ 172.23.23.20714240 - 713237 - - tun0 150022456 021872 0 0 tun0 1500 172.16.1.0/32 172.16.1.0 0 -0 - - > 2) NFS (unless you're explicitly disabling it) is UDP-based, while SSH > and Samba are TCP-based. Your nfe0 device has TSO4 enabled on it, so > I'm left wondering if the TCP offloading support for your nfe(4) device > is broken. > > Can you try disabling it by adding -tso to your ifconfig_nfe0 line in > /etc/rc.conf? If you're using DHCP on that interface, that may pose > somewhat of a problem. Yes, that seems to have made all the difference in the world: % ssh gateway cat /dev/zero | dd of=/dev/null load: 0.08 cmd: ssh 68698 [runnable] 1.20u 0.25s 11% 3020k 94384+0 records in 94384+0 records out 48324608 bytes transferred in 5.314707 secs (9092619 bytes/sec) load: 0.08 cmd: ssh 68698 [runnable] 1.81u 0.33s 15% 3020k 147664+0 records in 147664+0 records out 75603968 bytes transferred in 7.652768 secs (9879297 bytes/sec) So I'm thinking TSO wasn't an option in the older 7-stable I was running and now it is, but the support for it is broken. Your comment about DHCP, would that affect dhcpd or dhclient? This is my "server" machine so I don't run dhclient on it. I hardcode the IP connecting to the DSL modem. I'm currently hardcoding all the other machines also so I should be okay. > 3) Can you disable the firewall (disable ipfw entirely) and see if the > problem continues? Well the firewall is primarily for NAT and port forwarding. There's nothing special about it. It looks like the TSO disabling fixed my problems. Thank you for the suggestion! -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: local network throughput issues
On Sat, Aug 16, 2008 at 10:31:31PM +0200, [EMAIL PROTECTED] wrote: > > i immediatly think dns issues if samba and ssh are slow. are your > hosts reverse lookup-able? Yes. DNS problems usually affect the time to connect, and those are fast. It's just the throughput I'm seeing a problem with. In fact in each sshd_config, I have: UseDNS no In dnsmasq, I have each host listed in /etc/hosts which is used by dnsmasq for forward and reverse DNS. No this problem started when I updated the OS on my gateway. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
local network throughput issues
Hello. I've been having some serious network throughput issues recently. Prior to these issues, I was running 7.0-STABLE from a few months back. I recently build a world/kernel from csup(1) on 2008-Jul-25 and started noticing the issues. I'm currently on a RELENG_7 from 2008-Aug-02 and am building another one today. The server is running samba, dnsmasq, an NFS server, and is the gateway for a couple of freebsd machines. I first noticed the issue when I was unable to play mp3s served over samba. I was getting a throughput of about 3 KBytes/sec over my gigabit switched network. After a few weeks of trying different versions of samba and watching tcpdump/trafshow, I decided to try another test: % ssh gateway cat /dev/zero | dd of=/dev/null load: 0.00 cmd: dd 68286 [runnable] 0.00u 0.00s 0% 844k 3680+0 records in 3680+0 records out 1884160 bytes transferred in 512.856684 secs (3674 bytes/sec) ^C3680+0 records in 3680+0 records out 1884160 bytes transferred in 513.392858 secs (3670 bytes/sec) Killed by signal 2. Again, not even 4 KB/s throughput over ssh. What's weird is that not all network traffic is slow. I'm able to download at almost my full DSL speed (7168 Kbps) and here's the strange bit: NFS is fast! From the same machine as above, I have an NFS mountpoint: % dd if=/nfs/some_large_file of=/dev/null 55980+0 records in 55980+0 records out 28661760 bytes transferred in 0.147159 secs (194767476 bytes/sec) Which is what I would expect for a gigabit network. Even if I perform the same test over ssh: % ssh workstation cat /nfs/some_large_file | dd of=/dev/null 55980+0 records in 55980+0 records out 28661760 bytes transferred in 2.791392 secs (10267909 bytes/sec) This is reasonable considering ssh overhead. The kernel config for the server contains: include GENERIC ident DDB options KDB options KDB_TRACE options DDB options DDB_NUMSYM My internal network is on 172.23.20.x and the DSL modem is connected to the same NIC on 192.168.0.1: # ifconfig nfe0 nfe0: flags=8843 metric 0 mtu 1500 options=10b ether 00:15:f2:17:0c:20 inet 172.23.20.1 netmask 0xff00 broadcast 172.23.20.255 inet 192.168.0.3 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseTX ) status: active # ipfw show 0010062968 8170100 allow ip from any to any via lo0 001100 0 deny ip from any to 127.0.0.0/8 001200 0 deny ip from 127.0.0.0/8 to any 00130 25444031 23419621364 divert 8668 ip from any to any via 192.168.0.3 001400 0 deny ip from not 172.23.20.0/24 to 172.23.20.0/24 dst-port 137-149,445 00150 20639141 15067620538 allow tcp from any to any established 00160 21 10683 allow ip from any to any frag 0017079791 4696696 allow tcp from any to any setup 65530 5713367 8864760207 allow ip from any to any 655350 0 deny ip from any to any Other than that, I'm not doing anything out of the ordinary. Why is NFS behaving correctly and why are ssh/smbd connections so slow? I've pasted my dmesg output below. I've used this configuration for years and it wasn't until a recent RELENG_7 upgrade that I've had any problems. The box was 99-100% idle during those tests and I don't see an interrupt storm or anything funny like that. Any ideas? -- Rick C. Petty >From /var/run/dmesg.boot: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #5: Sat Aug 2 19:43:25 CDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DDB module_register: module sk/miibus already exists! Module sk/miibus failed to register: 17 module_register: module skc/sk already exists! Module skc/sk failed to register: 17 module_register: module pci/skc already exists! Module pci/skc failed to register: 17 module_register: module rl/miibus already exists! Module rl/miibus failed to register: 17 module_register: module cardbus/rl already exists! Module cardbus/rl failed to register: 17 module_register: module pci/rl already exists! Module pci/rl failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (2211.34-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 real memory = 1073676288 (1023 MB) avail memory = 1037037568 (988 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF24
Re: list blocklist from inode
On Tue, Jul 15, 2008 at 06:51:28AM +0200, Matthias Apitz wrote: > > Is there a way (without using fsdb(8)) to list the block list from a > given inode? thx ffsinfo -i -l 0x230 -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Glaring 64 bit omission
On Wed, Jul 09, 2008 at 02:46:00PM -0400, Zaphod Beeblebrox wrote: > > While I don't follow freebsd-chat with any regularity, My point was that the > wiki didn't reverence any conversations newer than 8 months old still > stands. That conversation is not referenced by the wiki. It may be an > example of someone bringing up the question without doing research, but that > is not the case here, either. So go learn how to use a wiki, request a wiki.freebsd account, and make a contribution by fixing the wiki. That would be something constructive to do. Complaining on these lists, without using your real name, just makes people believe that you are a troll. It is obviously not constructive since the problems are known and (supposedly) are being worked on. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Sysinstall is still inadequate after all of these years
On Mon, Jul 07, 2008 at 11:55:41AM -0700, Freddie Cash wrote: > > IMO, the installer should allow you to partition the disk(s), format > the partition(s), install the OS, configure a user, and reboot the > system. Anything beyond that should be handled by the OS tools, from > within the installed and running OS. It already does all of that, but why reboot right away? The first thing I do while the system is installing is run csup(1) to get the latest source, build and install world/kernel, and build all my ports. I also setup my gmirror and do all my configuration. The only reason I reboot is to use the latest kernel and mount from the mirror. I'd like to see other OSes do all of that. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: temporary freezes when pressing capslock / numlock
On Tue, May 27, 2008 at 02:28:26PM -0700, Maksim Yevmenkin wrote: > > well, i just took a brief look at atkbd(4). specifically one function > - wait_while_controller_busy(). this function polls status every > KBDC_DELAYTIME (20) usec with retry count of 5000. so, just this > function alone can give up to 100 msec delay. keep in mind that > wait_while_controller_busy() is apparently called every time driver > need to talk to the hardware. i can see how we could delay kernel for > 400 msec or even more. I'm not sure why we retry 5000 times. 100ms seems like a long time to block the entire kernel. Is there any reason we can't spawn a kernel thread to deal with the waits? I recommend that we also reduce the timeouts to at most twice what the spec states. How come this doesn't happen when other keys are pressed? Just when the console is flipped. Perhaps because it tries to set the LEDs first? -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: temporary freezes when pressing capslock / numlock
On Tue, May 27, 2008 at 01:32:10PM -0700, Maksim Yevmenkin wrote: > > right, which (to me) seems to indicate that something is going wrong > when kbdmux is trying to work on two keyboards (i.e. ukbd and atkbd) > and one of them (i.e. atkbd) is "not present". the problem, as i see > it, is that atkbd keyboard is always present even if no physical ps2 > keyboard is connected to the ps2 port. That's precisely how I see it. > i understand that people are > doing this in order to be able to "hot plug" ps2 keyboard (which is a > bad idea as ps2 port was never designed to be "hot pluggable", imo). Although not designed as hot pluggable, there's nothing in the technical specs which should prevent it. In fact, the specs imply that this is plausible. The only issue I know about is when older hardware didn't have TVS or line driver protection which could blow the serial driver chips (on either side) for example when both the keyboard and host try to drive the clock at the same time, but I doubt is a problem with modern hardware. Also, I believe the spec specifies the proper use of pullup resistors, so this shouldn't be a problem. A common complaint I've heard is that some (cheap) keyboards don't respond with a power-on self test completed (0xAA) when they are initially plugged in until they receive an initial command from the host. I've never seen such a keyboard; most keyboards send 0xAA immediately after power on, IIRC. > i suspect that because physical ps2 keyboard is not actually > present, the atkbd driver will have to timeout while talking to > non-present hardware. Sure, but this timeout shouldn't be ~0.4 seconds. I believe the spec says the maximum wait period to tell if the device is nonresponsive is around or less than 20ms. Certainly, blocking the entire kernel for the timeout is a bad thing, especially since the driver should make full use of the asynchronous onboard keyboard controller. > so, as a suggestion, please try to specify 0x1 flag to atkbd, i.e. from > atkbd(4) > ... > > and see if this helps. you wont be able to "hot plug" ps2 keyboards, > but i suspect you probably can live without it. I'm almost certain this will help, but I believe this shouldn't be the answer to this problem. There's no reason atkbdc(4) should block the entire kernel for any appreciable amount of time. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: temporary freezes when pressing capslock / numlock
On Tue, May 27, 2008 at 10:34:47AM -0700, Maksim Yevmenkin wrote: > > > > Agreed. I was never able to pinpoint it myself, but it certainly didn't > > show up before kbdmux. > > 1) what keyboards are used? usb only, ps2 only or mix? > > 2) what mice are used? usb only, ps2 only or mix? > > if ps2 devices (i.e. keyboard and mouse) are not used at all, does > disabling atkbd(4) and/or psm(4) help? I think I stated this in my original thread but let me restate. I've only noticed the problem when both usbkbd and atkbd are both enabled (as in the GENERIC kernel) and a USB keyboard (only) is attached. Once I plug in the atkbd, the problem goes away. The problem also does not exist if just the atkbd is plugged in with no USB keyboard. I haven't noticed a problem with the mice, but I've not used a PS/2 mouse in almost a decade. I have noticed a problem which has hit me rarely on a 6.x system; perhaps because the problem is not easily reproducable have I never seen it in 7.x. Basically I've seen the kernel get "stuck" and the only way to unstick it was to move the USB mouse. Moving the mouse allowed the interrupt to trigger and things would happen elsewhere in the kernel, but as soon as I stopped moving the mouse everything else stopped (ata reads/writes, graphics updates, etc.). Unplugging the mouse was a bad idea because the plugin event never triggered. I've only witnessed this on post-kbdmux systems but since it wasn't reproducable in any reliable fashion, I couldn't pin the problem down. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feature request
On Tue, Apr 01, 2008 at 10:24:44AM -0700, Patrick Dung wrote: > > I think Gvinum more like software raid then LVM (allocate/resize > Logical Volume on the fly). vinum *is* a (logical) volume manager. You don't have to use RAID at all, but it's easy enough to do. Resize is currently broken, but lulf@ I think was working on that. There are many things I don't like about LVM at all, particularly in the naming and how impossible it is to setup a root mirror at install (or even mirror whole disks). -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wrapper for Windows-only network card binary drivers on FreeBSD?
On Thu, Jan 24, 2008 at 04:12:00PM -0800, Yuri wrote: > I am curious is there an effort in FreeBSD similar to Linux NDISwrapper? http://www.freebsd.org/cgi/man.cgi?query=ndis&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI dvdreader always fails on a particular DVD movie title
On Thu, Jan 24, 2008 at 11:32:20AM -0800, Yuri wrote: > > CAPOTE (US region) doesn't play with mplayer either. > It begins, shows logo of United Artists and Sony Classics and > just hangs. Mplayer's counter also stops running. I've seen this a lot on some recent DVDs.. All I do is quit mplayer and restart it, skipping the first 10 seconds of video. That workaround has always worked for me. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DIST_SUBDIR not working with MASTER_SITE_OVERRIDE
On Wed, Jan 23, 2008 at 01:06:03PM +0200, [EMAIL PROTECTED] wrote:
> Hi everybody,
>
> I recently wanted to install some gnome stuff from ports. In order to
> boost the download speed, I did something like this:
>
> make MASTER_SITE_OVERRIDE=ftp://ftp1.ro.freebsd.org/pub/FreeBSD/distfiles/
>
> as documented in the Handbook. However, many gnome packages seem to have
> DIST_SUBDIR in their Makefile, but MASTER_SITE_OVERRIDE doesn't care. This
> makes installing ports (with many dependencies) from known non-default
> sources very hard.
I used to do something similar to this by setting it in /etc/make.conf.
The only downside is if DIST_SUBDIR is not set you get paths that don't
look pretty, e.g.:
ftp://ftp5.freebsd.org/pub/FreeBSD/distfiles//some_distfile.tgz
Instead, I added something to my /etc/make.conf similar to:
.if defined(DIST_SUBDIR)
DIST_SUBDIR_OVERRIDE=${DIST_SUBDIR}/
.else
DIST_SUBDIR_OVERRIDE=
.endif
MASTER_SITE_OVERRIDE=ftp://ftp5.freebsd.org/pub/FreeBSD/distfiles/${DIST_SUBDIR_OVERRIDE}
-- Rick C. Petty
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: select
On Thu, Jan 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote: > > How select(2) will behave if I give the "utimeout" parameter as > NULL? According to the man page: If timeout is not a null pointer, it specifies the maximum interval to wait for the selection to complete. System activity can lengthen the interval by an indeterminate amount. If timeout is a null pointer, the select blocks indefinitely. To effect a poll, the timeout argument should not be a null pointer, but it should point to a zero-valued timeval structure. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using shell commands versus C equivalents
On Wed, Jun 13, 2007 at 10:23:36AM -0700, [EMAIL PROTECTED] wrote: > On Wed, 13 Jun 2007, Joerg Sonnenberger wrote: > > Should I briefly lock (flock) the file when running open/fstat/fchmod then > to avoid issues? This may become a problem as pkg_*/make becomes more > parallelized (another student's goals for his SoC project). I wouldn't bother. What issue are you trying to avoid? If one process is trying to chmod +x and another is trying to do a chmod -x, it shouldn't matter if you lock between the fstat/fchmod-- someone is going to win anyway. This operation is not something that needs to be thread-safe. > Needless to say, pkg_* is by no means threadsafe in its current form > though. It uses some global vars that are currently not mutex locked, and > this type of file access is another issue (I wonder if spinlocking or > sleeping waiting for flock to finish would be better in this case). Does pkg_* use multiple threads? I was under the impression each pkg tool used a single thread (i.e. no threads) to do its operations and that they wait for system(2)-type calls as needed. Maybe I'm not clear by what you mean when you say "global vars". Now another question is whether the pkg_* tools can handle multiple processes managing the ports at the same time. For the mostpart, this is true. Without looking at the code, I would expect that the only contentions would be when trying to update the +REQUIRED_BY files. Everything else should be just fine; you're not supposed to be installing the same port multiple times at the exact same time, but maybe a lock could be held on the package directory (i.e. /var/db/pkg/$PKG_NAME). Again, I don't believe this is strictly necessary. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using shell commands versus C equivalents
On Wed, Jun 13, 2007 at 08:26:38AM -0700, Garrett Cooper wrote:
>
> vsystem("/bin/chmod +x %s", filename);
>
> and I replaced it with:
>
> chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH ));
Another improvement made by using stat(2)/chmod(2) over chmod(1) using
system(3) variants is the protection against malicious filenames. The
original code should have used fork/execv instead anyway.
But yeah, saving the fork, time to load and execute the shell, and parse
and perform the chmod is probably worth the effort to use the syscalls
directly from C, especially if this operation happens often enough. I
agree with the other poster(s) who said that if it prevents complex code,
it might be worth it. Your case isn't complex enough to warrant the
spawning of a shell process, especially when one of your primary goals is
to reduce total runtime.
-- Rick C. Petty
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for speed increases in "make index" and pkg_version for ports
On Sun, May 27, 2007 at 03:30:48PM -0700, Jeremy Chadwick wrote: > > That said, I'll ask this out in the open: am I the only one who sees the > benefit of GNU make in regards to this? There's a lot of built-in > functions in GNU make which could help in regards to ports. I have no > qualms with PMake per se, but if another tool gives us what we need, > then maybe we should consider the pros and cons of adapting that. > There's also CMake, which is incredibly fast. Yes, you are. What gmake benefits? Gmake does not provide the flexibility and power that pmake provides. Off the top of my head: gmake does not have ".for" loops, variable expansion modifiers, or even the "!=" shell command variable assigment. I use these in almost every Makefile I write, and the ports uses these things quite a bit. Also, gmake syntax is horrendous compared to pmake. People are already complaining about how ugly the ports makefiles are-- they'd be worse under gmake. Might as well rewrite the whole infrastructure in /bin/sh ... Also, there's the licensing issues. Remember-- any significant changes to this infrastructure has to work with the core utilities.. this leaves out gmake, python, ruby, etc. I doubt anyone will find anything as powerful as pmake without sacrificing the much-used flexibility it provides. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SoC
On Tue, May 15, 2007 at 01:08:03AM -0700, Garrett Cooper wrote: > > Sorry for all you Java lovers out there.. it's just that from where I'm > at I don't see anyone using it in the workplace (Intel). We're all using > C/C++/Perl, with occasional spots of Ruby/Python. We use Java almost exclusively (Oracle), although scattered bits of Python and occasional C/C++ thru JNI. Not to start a flame war, but I much prefer Java and I know a lot of other corporations are using it as well (just do a search for "software engineer" on any job site, and count the Java hits vs. C++). Also, Java outperforms Python/Ruby/Perl on all string manipulations from our extensive tests. However, my group likes the philosophies behind Ruby and likes the rapid development of Python when we need a scripting language. Use the Right Tool for the problem; just because you like using a hammer doesn't mean all screwdrivers are stupid. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DPS Initial Ideas
On Mon, May 14, 2007 at 06:06:37PM -0400, Kris Kennaway wrote: > > Some of the fields can (and do) have unbounded length. > > Kris Where is that specified in the SQL spec? Or are you just saying that SQLite provides this flexibility? -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DPS Initial Ideas
On Mon, May 14, 2007 at 10:25:12AM +0200, 'Michel Talon' wrote: > > niobe% sqlite3 index.db > sqlite> CREATE TABLE index6 ( > pkgname varchar(1), > path varchar(1), > prefix varchar(1), > comment varchar(1), > descr varchar(1), > maintainer varchar(1), > categories varchar(1), > build_deps varchar(1), > run_deps varchar(1), > website varchar(1), > extract_deps varchar(1), > patch_deps varchar(1), > fetch_deps varchar(1)); > sqlite> .import INDEX-6 index6 > ... completes in less than 2 seconds > sqlite> select * from index6 where path = "/usr/ports/accessibility/atk"; > atk-1.12.4|/usr/ports/accessibility/atk|/usr/local|A GNOME accessibility > toolkit > (ATK)|/usr/ports/accessibility/atk/pkg-descr|[EMAIL PROTECTED]|accessibility > devel|gettext-0.14.5_2 glib-2.12.9 libiconv-1.9.2_2 libtool-1.5.22_3 > perl-5.8.8 pkg-config-0.21|gettext-0.14.5_2 glib-2.12.9 libiconv-1.9.2_2 > perl-5.8.8 > pkg-config-0.21|http://developer.gnome.org/projects/gap/||libtool-1.5.22_3| What this shows me is that sqlite doesn't follow SQL92 standards. According to the section 6.1 of the standard[1]: Syntax rule #1 states "VARCHAR is equivalent to CHARACTER VARYING." Syntax rule #9b states "If VARYING is specified in , then the length in characters of the character string is variable, with a minimum length of 0 and a maximum length of the value of ." So your example should have failed to work correctly. You should have used something more appropriate, like VARCHAR(255) instead of VARCHAR(1). If SQLite isn't even standards-compliant, why is anyone considering it? =) Nitpicky, I know, but it makes me wonder what else they don't follow... -- Rick C. Petty [1] http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: High disk load +mount/atacontrol/NFS/SMBFS crashes the system
On Mon, Apr 23, 2007 at 09:58:58PM -0300, Alejandro Pulver wrote: > > In the machine which was recently upgraded to 6.2 using "atacontrol" > when the disk is reading/writing crashes the system half or more of the > times. Which atacontrol command were you doing? Just plain "atacontrol" shouldn't do anything useful. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Discovering list of open files from "kernel level" without using utils like lsof
On Sun, Apr 08, 2007 at 11:05:48AM -0700, Garrett Cooper wrote: > I'm trying to see if there's a simple tool that I could code in C/C++ > if necessary to spin down disks automatically to save power and disk > life. Plus, I think that lsof actually would probe the devices and 'wake > them up' instead of keeping them as-is. However, I could be wrong so if > I am please let me know. I read somewhere once that keeping disks spinning makes them last 10x longer. Personally, I've seen more disk failures on workstations which are power-cycled regularly than on systems which are always running. I've also seen disks work just fine while powered that just plain quit immediately after a power cycle. So you may save power by spinning the disks down, but I doubt you're saving disk life (unless they're powered down for weeks at a time). -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PING: Someone on the core team. (Modem Problem)
On Fri, Feb 09, 2007 at 10:27:07AM -0800, Daniel Rudy wrote: > > The modem is PCI, and there is no facility in the BIOS to display what > cards are in the system. Furthermore, the irq mapping shows irq 3-15, > irq 17, 18, and 19 do not show on the list. Below is the full dmesg > from the boot: What list and what mapping? Here are the relevant lines in your case: > sis0: port 0xd000-0xd0ff mem 0xeb103000-0xeb103fff irq > 19 at device 4.0 on pci0 > sio0: configured irq 19 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: port > 0xdc00-0xdcff,0xe000-0xe0ff,0xe400-0xe407 mem 0xeb107000-0xeb1070ff irq 19 at > device 11.0 on pci0 > sio0: type 16550A > >> I have no idea WHY it's saying IRQ 19 as IRQ 19 is used by sis0. > > > > Interrupts on the PCI bus can be shared and quite often are. Because PCI interrupts have to be mapped to high numbers so they don't interfere with legacy (ISA, etc.) IRQs. The PCI bus handles its own interrupts, so I wouldn't expect to see irq 3, for example. In fact each PCI slot typically maps to a specific IRQ (via the INT mechanism). > And FreeBSD doesn't support shared interrupts, right? (At least that > used to be the case, not sure about now). If it does allow irq sharing, > then why isn't it working? And if it doesn't support irq sharing, then > why is FreeBSD assigning 2 devices to the same irq to begin with? > Its kinda strange though if that was the case, the other cards wouldn't > work then because they would all be sharing the same irq. The 3 network > interfaces are assigned 17, 18, and 19. sis0 is on the mainboard, sis1 > and sis2 are add-in cards on the pci bus. Not strange at all, FreeBSD does support shared IRQs. However, the sio device does NOT support shared IRQs. There was a patch floating around which enabled IRQ sharing for this device, in fact I used it on a number of systems successfully. I'm not sure why it never made it into the base system. Here's something to try, if you don't want to patch your kernel. Find a PCI slot that doesn't share an IRQ with anything else and throw the modem into that slot. If you have an Asus board, the user's manual lists the PCI interrupts and sharing. If not, use trial-and-error. You could probably make an educated guess by looking at which cards are being mapped to which interrupts. Pick a device which has a solitary (unshared) IRQ and swap with the modem. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LDAP integration
On Thu, Jan 11, 2007 at 01:54:46PM -0500, Nathan Vidican wrote: > > Take this idea, and run with it... build a package that installs over > the base installation, bundling the LDAP client libs, new rc structure, > tools, etc all in one shot. Add it to the ports collection and call it > done. I don't like the idea of any ports installing themselves over the base installation. If you do a "make installworld", you'll wipe the port, and a portupgrade will wipe out the base.. We have /usr/local/ for a reason. Having a port install the same libraries as the base is already problematic enough (look at security/heimdal), but at least the separation is manageable. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fscking a partition mounted Read only...
On Tue, Oct 17, 2006 at 10:06:36AM +0200, Oliver Fromme wrote: > Rick C. Petty wrote: > > I doubt you'd get the code to work under 6.x or 5.x even. I'm not sure if > > any GEOM-related stuff ever made it into fsck, but certainly the background > > checking code and softupdates changes were introduced about that time. > > Does 4.x fsck even support UFS2? No it does not, so that would be a problem as well =) -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fscking a partition mounted Read only...
On Mon, Oct 16, 2006 at 09:49:04AM +0200, VANHULLEBUS Yvan wrote: > > Right: I just tried on a FreeBSD 4.11, and I can fsck a partition > which has just been remounted RO. > > Could it be interesting (and quite safe !) to recompile 4.X's fsck > under FreeBSD6 and do the test again on FreeBSD 6 ? I doubt you'd get the code to work under 6.x or 5.x even. I'm not sure if any GEOM-related stuff ever made it into fsck, but certainly the background checking code and softupdates changes were introduced about that time. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fscking a partition mounted Read only...
On Fri, Oct 13, 2006 at 02:16:51PM -0400, John Baldwin wrote: > On Friday 13 October 2006 13:42, Rick C. Petty wrote: > > > > I'm pretty sure that's what he tried (hence "remounted readonly"). I've > > noticed this behavior as well and it is quite frustrating. If you boot > > single-user, / will be mounted read-only and you can fsck it. If you do: > > > > mount -u / > > mount -u -r / > > > > You can no longer fsck it. I've been meaning to track this down and/or > > file a PR. I'm pretty sure this used to work just fine in 3.x and 5.x. > > I think it's broken in 5.x as well. It's fallout from GEOM IIRC, and it is > annoying. Grr, I meant 4.x not 5.x, and I thought the problem started about the time bg fsck was introduced... -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fscking a partition mounted Read only...
On Fri, Oct 13, 2006 at 10:04:07AM +0200, Joerg Sonnenberger wrote: > On Fri, Oct 13, 2006 at 09:41:37AM +0200, VANHULLEBUS Yvan wrote: > > > > Later, if root filesystem is remounted readonly, then fsck is called, > > it will says "NO WRITE ACCESS". > > mount -ur / I'm pretty sure that's what he tried (hence "remounted readonly"). I've noticed this behavior as well and it is quite frustrating. If you boot single-user, / will be mounted read-only and you can fsck it. If you do: mount -u / mount -u -r / You can no longer fsck it. I've been meaning to track this down and/or file a PR. I'm pretty sure this used to work just fine in 3.x and 5.x. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck
On Mon, Sep 25, 2006 at 02:41:18PM -0600, [EMAIL PROTECTED] wrote: > > Maybe I can mount a dirty partition. I just need the data off it... Mount it read-only and get the data off it IMMEDIATELY. I wouldn't try fsck-ing on any disk with even a single read or write error. Fsck will fail if it can't find a real sector to allocate, and I don't think it deals well with bad sectors anyway. Point is: don't let it. "dd" the drive ASAP and cut your losses... -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A handy utility (at least for me)
On Mon, Aug 28, 2006 at 02:18:48PM -0400, Mike Meyer wrote: > > If echo is a shell built in, then it works just fine, and the xargs > insures that you don't try passing to many arguments to rm. Ah! I was mistaken; I didn't think about builtins not requiring argument passing. > > Also I don't see how your example is any more efficient than find-- you're > > just making the shell do the work instead of find. > > Find will check *every file* in *every directory* to see if it's named > "work" or not. The shell version won't make that test on the first two > levels of directories; it just expands them. Forgot about those as well. I retract my previous suggestion, now in favor of: find /usr/ports -depth 3 -prune -o -type d -name work -prune -print -delete This will prevent from going into the files directories. This method doesn't have the extra process overhead. > And now you get into the question of what "efficient" means. Either > process is going to spend most of it's time waiting on the disk. With > the find, nothing else is happening while that's going on. With > multiple processes, there's a possibility that one can be working > while the other is waiting on the disk, so it might take more CPU time > while taking less wall clock time. Which is more efficient? [NB: This > is grossly oversimplified, but you get the general idea.] In general I would agree with you. But in this case, either the shell is doing a loop over readdir() and applying its glob internally or find is doing the loop over readdir() and applying its glob via regexec(3). In either case, the CPU time should be relatively similar. In the find case, a syscall is applied whereas the shell spits this to the xargs process thru a pipe, who has to malloc/memcpy the lines and start at least one other process, which then applies the syscall. To me, this sounds like a lot more CPU time. I'm not convinced find would take any longer wallclock time. It would be interesting to see some stats on both methods, with and without the benefit of FreeBSD's filesystem caching mechanisms. Regardless, the find command is certainly not faster to type for some people, and really what's important is how much operator time is spent. One nice thing about unix is that there's more than one way to skin a cat(1), pardon the pun. So use what you feel more comfortable using! Three cheers for free unix, -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A handy utility (at least for me)
On Mon, Aug 28, 2006 at 06:18:58PM +0200, Oliver Fromme wrote: > Rick C. Petty wrote: > > > > I find that the following command works just fine for me: > > > > find /usr/ports -type d -name work -prune -print -delete > > The following is probably the most efficient solution. > It doesn't run into all subdirectories (and works with > an arbitrary numebr of subdirectories). > > cd /usr/ports; echo */*/work | xargs rm -rf You might as well just do: rm -rf /usr/ports/*/*/work because using xargs doesn't gain you anything in this case. How does your example work with an arbitrary number of subdirectories? Your example does't work if the number of work directories exceeds the maximum number of arguments (4096 IIRC), which can happen amidst 16,000 ports. This bit me once so I use find now (granted this was before I was using portupgrade). Also I don't see how your example is any more efficient than find-- you're just making the shell do the work instead of find. In either case, it's just a sequence of opendir()/readdir(). In fact your example would start secondary processes to do the directory removal; find has this built in and thus doesn't have the overhead of process forking. Perhaps if on an arbitrary directory tree, find may not be as efficient, but the only directories deeper than depth of two (in my example) are work directories, and they would be pruned. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A handy utility (at least for me)
On Sun, Aug 27, 2006 at 01:13:19AM +0200, albi wrote: > > > > I find that the following command works just fine for me: > > > > > > find /usr/ports -type d -name work -prune -print -delete > > > > > A bit rude, but also works > > > > cd /usr/ports && make clean > > guys... please use the official portsclean ! :) > > included in the sysutils/portupgrade I was giving an option that works across every system, I didn't mean to encourage a litany of responses. =) I wouldn't call it "official" unless it's in the base system. Why isn't portupgrade in the base system? Oh right, because it uses ruby. Please shoot me first before throwing ruby in the base distro. :-P -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A handy utility (at least for me)
On Sat, Aug 26, 2006 at 07:19:06PM -0300, Mario Lobo wrote: > > My /usr/ports directory was occuping 24 gigs, of which 20 was just from the > 'work' directories ! > > Removing them one by one was a pain so I wrote this little utility to wipe > them off. I find that the following command works just fine for me: find /usr/ports -type d -name work -prune -print -delete =) -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
momentary system "pauses" when switching VTYs
Hello. I did a stock install of 6.1-RELEASE yesterday and I noticed something weird. Whenever I switched the virtual console to a different screen, it would take almost 2 whole seconds before switching. At first I thought it was IRQ related since it was happening during the heavy disk activity of an install, but I noticed the same behavior after rebooting the machine. I csup'd to RELENG_6 as of last night and that didn't help. One thing I did notice is that the whole kernel seems to "pause" during the two second switching operation-- I noticed this because I switched virtual screens during a bg fsck and each time I switched, the ATA light would turn off during the duration and come back on immediately after the console switched. This behavior is 100% repeatable for me. I looked at "systat -vms" and top(1) but didn't notice anything out of the ordinary. This only seems to affect this one system; my other machines switch virtual screens instantly. This happened both with GENERIC and SMP kernels.. I'll include the latest dmesg below. Nothing else appeared in any logs. I can provide a verbose dmesg if necessary. The only thing I can think of is that I'm using kbdmux with no PS/2 keyboard attached-- but I'm using a similar USB keyboard on another 6.1-STABLE box just fine. Any ideas? -- Rick C. Petty output of dmesg: Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-STABLE #0: Fri Aug 25 01:16:11 CDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC module_register: module uhub/ums already exists! Module uhub/ums failed to register: 17 mptable_probe: MP Config Table has bad signature: 4\^C\^_ ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) 2500+ (1746.83-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0480800 real memory = 1610547200 (1535 MB) avail memory = 1569087488 (1496 MB) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 Correcting nForce2 C1 CPU disconnect hangs agp0: mem 0xc000-0xcfff at device 0.0 on pci0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xde086000-0xde086fff irq 20 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xde081000-0xde081fff irq 21 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xde082000-0xde0820ff irq 22 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered nve0: port 0xe400-0xe407 mem 0xde083000-0xde083fff irq 20 at device 4.0 on pci0 nve0: Ethernet address 00:11:2f:e4:95:b4 miibus0: on nve0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:11:2f:e4:95:b4 pci0: at device 5.0 (no driver attached) pcm0: port 0xd000-0xd0ff,0xd400-0xd47f mem 0xde087000-0xde087fff irq 22 at device 6.0 on pci0 pcm0: pcib1: at device 8.0 on pci0 pci1: on pcib1 skc0: port 0xa000-0xa0ff mem 0xdd00-0xdd003fff irq 17 at device 4.0 on pci1 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:11:2f:e4:85:7e miibus1: on sk0 e1000phy0: on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto pci1: at device 6.0 (no driver attached) pci1: at device 6.1 (no driver attached) atapci0: port 0xa400-0xa407,0xa800-0xa803,0xac00-0xac07,0xb000-0xb003,0xb400-0xb40f mem 0xdd004000-0xdd0041ff irq 18 at device 11.0 on pci1 ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf
Re: [PATCH] adding two new options to 'cp'
On Wed, Aug 02, 2006 at 05:33:40PM +1000, Peter Jeremy wrote: > On Tue, 2006-Aug-01 23:35:03 -0700, Tim Kientzle wrote: > >The "cheap" solution is to handle it purely on > >extract: Detect blocks of zeros when restoring > >files and seek over them. > > The downside is that you wind up with a sparse file whether or not you > wanted one. No, you wind up with a sparse file if you specify the "-S" option to tar. If you didn't want one, don't specify the option. > Actually, the only real solution to copying sparse files is to add > a system call that can return a map of holes. This would neatly > address the "needs two passes" problem with tar. You don't need two passes-- you advance the file pointer whenever you detect a block of zeros. Note: care must be taken to only do this for newly-created or otherwise truncated files, otherwise the skip ahead wouldn't work. > As a general comment (not addressed to Tim): There _is_ a downside > to sparsifying files. If you take a sparse file and start filling > in the holes, the net result will be very badly fragmented and hence > have very poor sequential I/O performance. If you're never going to > update a file then making it sparse makes sense, if you will be > updating it, you will get better performance by making it non-sparse. Agreed, with a minor correction/elaboration. By "updating" you mean specifically "updating but not appending". And another note: a good way to defragment a file is to sequentially copy it. (The "best" way is to copy the file to a new filesystem, that way you guarantee the blocks allocated to the file are contiguous.) -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Tue, Aug 01, 2006 at 08:09:08PM -0400, Garance A Drosehn wrote: > > I had understood this option as a request to "copy all the > existing holes", which is not the same thing. I.e., I > thought we wanted `cp' to create the new file such that it > would take up exactly the same number of disk blocks, and > have the same number of holes (in exactly the same places) > as the original file. Which it currently doesn't, without any sparse option. A copied file will always be larger than the original (in terms of disk blocks) if the original had any sparseness. > I agree that "sparse-ify" should be easy to implement, and > could be useful. I'm not fond of the idea, but I can see > how people might want it. I do would not like it, because > the user will have to know whether it is appropriate to use > on a file-by-file basis. You can't just 'cp -rp' an entire > directory, and feel confident that the "Right Thing(TM)" > will happen for each file that is being copied. So, if I > am copying directories, I'll still have to resort to some > other tool to get the job done "Right(TM)". I don't see why not. If you're mixing sparse and non-sparse files in a tree and wish to duplicate this precisely, you need dump/restore.. oh, and those only work for UFS filesystems. Whatever the Right Thing is, you should have a good idea whether you wish to sparsify or anti-sparsify the files beneath (current cp does the anti-sparsify). If you're doing a directory copy and cannot choose which is the Right Thing for everything within that directory, then cp(1) certainly is not your choice. > In my case, I want zeros on the disk in the destination > wherever there were zeros on the disk in the source. This may be true with cp(1) as it is now, but certainly the converse is not guaranteed to be true. > In some situations, I don't want the number-of-blocks of a > file to increase every time I change a X'00' to a X'01'. Whereas the opposite situation is preferrable? Hmm, I'm using Y bytes of storage within this directory tree, let's move that to another partition. I'll make that partition at least Y bytes big. Recursive copy-- whoa! Out of space? Darn. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Wed, Aug 02, 2006 at 05:04:53AM +1000, Peter Jeremy wrote: > On Tue, 2006-Aug-01 12:51:32 -0500, Eric Anderson wrote: > >string of zeros larger than the block size, or it needs to 'do the right > >thing' and determine if it's sparse or not. > > You can do this by comparing stat.st_size with stat.st_blocks - a > sparse file will have fewer blocks than its size requires. What you > can't do is accurately determine where the holes are. > > Note that st_blksize is not nessarily the allocation blocksize and > therefore is unrelated to the size of holes in the filesystem. Also, > on FreeBSD, the designation of "optimal" is a misnomer and I/O > operations should be much larger than this for optimal efficiency. True, but I've not seen the case where the following is not true: The filesystem's block size (i.e. 8x fragment size) in UFS an integer multiple of st_blksize. My previously-posted example would work just fine. I guess a better solution would be to check every 512-byte chunk and seek if zero. It's up to the underlying filesystem to implement this as a sparse file, if that filesystem supports such a thing. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Tue, Aug 01, 2006 at 02:26:28PM -0400, Mike Meyer wrote: > In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed: > > > Obviously, I didn't add the error checking/handling, but AFAIK this is > > essentially what the -S option to gnu's tar does. > > Yes, but gnu tar doesn't do this accurately, That may be. I haven't looked at their code, I just assumed how they did it. > so you're not doing what > Peter said you couldn't do. You are doing what Ivan asked, though. That depends upon what you mean by "accurately" and what you mean by "sparse". :-P Yes, if you're looking for a block-wise "dump" of a file system's file, you use dump. If you're looking to make a "copy" of a file, optimizing for sparseness, you use rsync. A pretty heavyweight solution when you're trying to copy one file. > I always think of cp as a tool for making *copies of files*, not for > creating an archive of a directory tree. We've got lots of tools that > do the latter. Do we really need another one? I wasn't thinking of the "sparse handling" utility for whole trees, but it would be useful for that also. I'm just looking for a lightweight tool for copying files containing sparse chunks.. Since we switched to bsdtar, the base system has been lacking this feature. To me, this seems more useful (as a base feature) than hard-linking trees. But both have utility. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Tue, Aug 01, 2006 at 12:51:32PM -0500, Eric Anderson wrote: > On 08/01/06 12:40, Rick C. Petty wrote: > > It could possibly be bad if you have a real file (say a 10GB file, > partially filled with zeros - a disk image created with dd for > instance), and you use cp with something like -spR to recursively copy > all files. Your destination disk image would then be a sparse file, so > additional changes and modifications to the file (block allocations) > would fragment the image and make it slower. That would be unexpected > and probably go unnoticed for some time. I do see the usefulness in > this, but I think one needs to be careful to either clearly note in the > man page that it will make sparse files from *any* file containing a > string of zeros larger than the block size, I completely agree. This is why it would not be the default behavior. Also, gnutar provides this option and it just describes it as "handle sparse files efficiently"-- so a rewording of that to say that by "efficient" we mean that the program will allocate as few blocks as possible in the underlying filesystem. I think a clear description in the man page would suffice. > or it needs to 'do the right > thing' and determine if it's sparse or not. Unfortunately that would require knowledge which the POSIX calls have no knowledge of. I don't believe we should roll filesystem-specific knowledge into cp. However, there is utility in performing a "space-saving" copy, just as a hardlink is quite space-saving. =) "-s" or "-S" could refer to sparse, space, squeeze, shrink, or whatever. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Tue, Aug 01, 2006 at 12:27:54PM -0500, Eric Anderson wrote: > > Wouldn't this be incorrect for files that are really full of zeros? It > would turn them in to sparse files when they shouldn't be, correct? Is > that what happens with other tools? Why is this bad? I'm not suggesting that the default implementation should change but that this "-s" option be added to properly optimize for sparse files. A sparse file is one which contains blocks of pure zeros. My example wouldn't vary in how the destination file is read but in how many blocks are allocated in the underlying file system. One of my biggest gripes with cp(1) was how a recursive tree copy was always larger than the source, if the source contained any sparse files. This is similar to your desire to add "-l" for doing hard links. Both have their usefulness. And your "-a" option could be a replacement for "-pRs" if so desired (or "-S", it's all the same to me). While we're at it, I think we should add the -S option to bsdtar. I'm willing to do the work and make patches (to cp & tar), if someone is willing to review and commit them. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Tue, Aug 01, 2006 at 01:06:55PM -0400, Garance A Drosehn wrote: > > The point is not that you need an explicit switch, the > point is that you have to add a lot of code to 'cp' for > 'cp' to do the job correctly. Not really. See my example in a previous post. All you need to do is perform an lseek(2) instead of a write(2) if the block you read is all zero. > You are changing the nature of how the command works. No, you're adding features, not changing the behavior for the default case. > I very much doubt you > can implement that *correctly* in a mere 160 bytes of > additional object code! I'd be willing to bet that my aforementioned example would fit in that space-- because you already do an fstat & the read/write code-- the only thing to add is the zero-checking and seek ahead code. > -r-xr-xr-x 1 root wheel 15348 [date] /bin/cp > -r-xr-xr-x 2 root wheel 44288 [date] /sbin/dump > -r-xr-xr-x 2 root wheel 58736 [date] /sbin/restore dump/restore is significantly different in operation than cp. Both do a lot more than just copy files. Also dump/restore is specific to UFS and my example code would handle sparse files for any filesystem. > I realize a lot of these decisions are somewhat subjective. > "One person's feature is another person's bloat". But in > the case of this specific example, I (personally) would > not want 'cp' to implement every detail which is already > handled by dump/restore. I don't think this is what people are asking for. BTW, does dump/restore handle extended attributes? Last I checked, it didn't. But then again I don't think cp or tar do either. Feel free to enlighten me. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote:
> On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote:
> >I agree with this, and while you're in there, can you add -s to copy
> >sparse files (via the usual "if the buffer is all nulls, seek beyond eof
> >instead of writing" trick)?
>
> Note that it isn's possible to accurately distinguish between a block
> of NULs and a hole in the file through the filesystem. The only way
> to accurately copy a sparse file is with dump/restore.
Sure it is-- in a number of ways. The most useful way is to do something
of the sort:
int sd, dd; // assume these are set to source & dest descriptors
unsigned char* zeros;
unsigned char* buffer;
struct stat st;
size_t bytes, offset;
fstat(sd, &st);
zeros = malloc(st.st_blksize);
bzero(zeros, st.st_blksize);
for (offset = 0; offset < st.st_size; offset += bytes)
{
bytes = st.st_blksize;
if (offset + bytes > st.st_size)
bytes = st.st_size - offset;
read(sd, buffer, bytes);
if (0 == memcmp(buffer, zeros, bytes))
lseek(dd, bytes, SEEK_CUR);
else
write(sd, buffer, bytes);
}
Obviously, I didn't add the error checking/handling, but AFAIK this is
essentially what the -S option to gnu's tar does. In this example, you
may not mimic the allocated blocks of a sparse file, but you would
optimize the copy to use as few filesystem blocks as possible.
-- Rick C. Petty
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Mon, Jul 31, 2006 at 11:01:24PM +0200, Ivan Voras wrote: > Rick C. Petty wrote: > > >"-l" may be a useful option, but at what point is the line drawn between > >bloating our base cp and having a gcp port (or using linux_base)?? > > It's like saying "if you need this option, go to Linux" - it just seems > wrong. Not quite. I'm just saying that the "-l" option would be seldomly-used and chances are that the people who would use it are likely to also have linux_base installed. > With all respect to "series of small utilities" way of doing things, I > think the "whatever is shorter to type" takes precedence :) Ah, so then let's install a binary called "a" which is hard-linked to cp and does the equivalent of "cp -a". While we're at it, let's add a "t" command as a shortcut to "tar -f". [/sarcasm] This is what aliases are for. "cp -a" seems to me to be a silly way to say "cp -pR". Come on, it's only one letter shorter (although you could argue the time it takes to hit the shift key counts as a letter). I would think that more BSD admins are so used to typing "cp -pR" than "cp -a". In any case, it seems pointless to waste a letter when an alias is a more appropriate solution. cp(1) uses getopt(3), so there are only so many letters available. It seems more useful to add other bits of functionality and use up letters. If you really want "-a" then it should copy sparse files correctly, preserve hard links within the copied hierarchy (much like rsync's -H option), and handle extended attributes (e.g. ACLs). If not, then save "-a" for something like ACLs. Does cp(1) properly handle ACLs now anyway? > And it's not like the added code will have to be changed/maintained in > the forseeable future - if the basic implementation is ok, the > underlying structures and ideas will not change while UFS semantics are > in use. Actually I have no gripe against "-l"; I was just making a point. I think this hard-link idea is pretty useful. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Mon, Jul 31, 2006 at 12:42:02PM -0500, Eric Anderson wrote: > On 07/31/06 12:28, Rick C. Petty wrote: > > > >In both cases, why don't you just use: > > > >/usr/compat/linux/bin/cp > > Two reasons - it's not in the base system, so a port has to be installed > - and linux_base is FC3 now, so if you want to talk about bloat... And the "-l" option is needed in single-user mode? I like not having extra bloat around when I don't even have /usr mounted and am trying to fix a disk or misconfiguration. I'm just arguing the usefulness of having it in the base system vs. using linux_base. The argument that our cp should be equivalent to gcp seems silly to me. "-l" may be a useful option, but at what point is the line drawn between bloating our base cp and having a gcp port (or using linux_base)?? "-a" certainly is useless. An alias is far more useful-- even for things in /bin ! I certainly cp and mv mapped to "cp -i" and "mv -i".. one could also argue that the our base versions of these use this option by default. Personally, I prefer to do a post-install patch to add these aliases to /etc/csh.cshrc (actually on my systems: /etc/csh.aliases) and /etc/profile, etc. > Another reason is gcp fails to recursively copy a directory that has > symlinks in it. That sounds like a bug or at least an oversight. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Mon, Jul 31, 2006 at 05:47:09PM +0200, Juan Rodriguez wrote: > > My GNU version of "cp" has more than 18 options, the FreeBSD > version only has 9. > > As I usually work with Linux machines, I'm used to "cp -a" and I have always > hated to have to look up in the FreeBSD's "cp" manual page for the right > options to get the same funtionality. I tend to think > that "-a" is option bloating because it's not really needed, but I see > "-l" as a new feature for "cp" that might be useful. I agree, -a is bloat. However I don't understand why you say: > To sum it up, I think "cp -a" and "cp -l" are both useful, I agree that the "-l" option *may* be useful. > the first one > because of compatibility with the large base of Linux systems out there, and > the second one because I think it's a useful feature for the FreeBSD "cp". In both cases, why don't you just use: /usr/compat/linux/bin/cp If you're not going to add all 18 options to our cp, then -a shouldn't be added at all. It doesn't provide any useful functionality, and the argument to make it more compatible with Linux is silly unless you add the other 9 options. If you want the linux cp, use the linux cp. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fdescfs functional in 6.1?
On Fri, Jul 28, 2006 at 11:16:53PM -0700, Jaye Mathisen wrote: > I guess I just expected it to print all character device entries for the > file descriptors open by my process. It did-- well it printed all the file descriptors open by your process, which in this case was "ls". 0, 1, and 2 are stdin, stdout, and stderr (respectfully) and they point to the device you logged into. Try doing "ls -la /dev/fd | less" and I'll bet 1 will be a pipe? This seems like the correct operation; I'm not sure I understand what you expected and why that's different than what you've observed. > Kind of like the old /dev/fd/1 /dev/fd/2 directories used to be under > MAKEDEV... How is that the same? MAKEDEV was in the day before devfs, so the device entries needed to be created by the underlying filesystem. In devfs, things are only present if they represent an active device. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 09:33:41PM -0400, Mike Meyer wrote: > > "Small disk drive" means "smaller than any drive I can buy at the > local Best Buy/Circuit City/CompUSA/similar". At the time, I needed an > 80GB drive, and paid about $60 for it. Well then your comparison isn't really fair.. Sure, a brand new hard drive from a retail outlet is more expensive than a 10-year-old box (especially if the box is refurbished). No surprise there! I thought we were comparing oranges and oranges. In that case, check out www.geeks.com (the old computergeeks), they have a number of drives for sale under $49.95. > Try http://www.pcretro.com/. Their current special is the Dell > PowerEdge 6350 (dual CPU, 255MB ram, 2 9GB hot swap drives on separate > controllers) for $49.95. The boxes I bought had a mouse and keyboard > included, no monitor or speakers. Not that I cared - I tossed the > mouse and keyboard on the spare parts pile and plugged them into a > KVM. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: >Boxes are cheaper than disk space - my last two low-end boxes cost >less than my last small disk drive, even though I ordered them all >about the same time. If you can afford the disk for some process, then >chances are good you can afford a system instead, or as well. I'm not sure how that's even possible. A quick glance at newegg.com: $17.99 (+$6.13) [recertified] socket A motherboard $39.99 [oem] AMD Duron socket A processor $13.99 (+$4.99) 128MB RAM === $71.97 (+$11.12 shipping) = $83.09. This is assuming you have an extra case, power supply, and video card to throw in it. What do you consider a "small disk drive"? Newegg has a 40G for $39.99 + $5.64 shipping. Yeah, so small disk drives seem to be half the price of the cheapest possible "box". Feel free to enlighten me, I'd love to know where you shop that has a system under US$50 ! -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: > On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: > > > > DragonFly disklabels allow 16 entries by default, FreeBSD still limits > > it to 8. That's why you can't read it directly. > > Are there plans to bump the default up from 8? I'm honestly torn on > this topic whenever I install a new system. On the one hand I like > having a lot of discrete mountpoints to control potential usage. On > the other hand with drive space being so inexpensive I sometimes > wonder if I need to bother and can get away with very few mountpoints. I would think that cheap disk space would mean larger disks which implies more mountpoints ??? > On very large disks (or arrays that appear as a single disk) I have > to create multiple slices in order to get more than 8 mountpoints. Its > an extra hoop to jump through. Use gpt on non boot-disks, or use gvinum if you have lots of storage and like the inherent advantage of named labels, striping, and redundancy. I wasn't very happy with gpt or bsdlabel recently because you aren't allowed to modify the partitions if the gpt/bsdlabel is in use (i.e. one of the other partitions is currently mounted as a filesystem). I hope the GEOM people are working to improve this. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: open ("/dev/lpt0" ...) hangup solved
On Sat, Jul 22, 2006 at 10:03:25AM -0700, [EMAIL PROTECTED] wrote: > > So the real simple fix is to prevent the plip0 interface from coming > up. I thought the simple fix for this was to put: > > ifconfig_plip0="noauto" This is supposed to work? I thought the values to the ifconfig_* variables were passed directly to ifconfig(8).. > into my rc.conf. But it still came up anyway. So I put: > > network_interfaces="sis0 re0 lo0" > > in rc.conf, explicitly excluding plip0. But plip0 still came up! > What am I doing wrong now? > > (When I manually "ifconfig plip0 down", the whole printing problem > is solved.) What's wrong with using: ifconfig_plip0="down" ??? -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/99979: Get Ready for Kernel Module in C++
On Wed, Jul 12, 2006 at 04:10:29PM +0200, [EMAIL PROTECTED] wrote:
>
> C++ is the de-facto standard for OO
That is just sad. So many other languages do a much better job of
implementing OO (Smalltalk, Java, Python, even Scheme). While we're at
it, why not implement a bytecode interpreter for all of these languages
into the kernel? That would be sweet..
I'm being facetious here; OO has some merit but aside from that, there's
very little utility an additional language can provide. Granted, it's
easier (read: lazier) to use:
try {
...
}
catch (...)
...
than it is to do:
error = some_fn_which_could_error();
if (error)
return error;
...
While I haven't looked at kobj, I have seen some good implementations of OO
in plain C (GTK's gobject comes to mind). I believe at least basic OO
framework is available and doesn't require a huge performance hit, as
undoubtedly a C++ solution would provide (at least from my experience).
For all C++ gives you, I believe the potential is there to do the same
things in C.
I'm all for making kernel code free of C++ reserved words (although I'd
recommend changing "new" to "new_obj", etc. instead of "_new" or similar).
This would allow C++ developers to write drivers and such. But I don't
feel there is any benefit to commit C++ code into the "pristine" kernel
source. Also, I thought the C++ "standard" was still being argued about
and thus is incomplete?? (I certainly know there are C-isms which don't
appear in any C++ standard as of yet) Not to pick on the gcc/g++ folks,
but it's difficult to find a decent C++ compiler which implements all/most
of the language standard and also reliably compiles/cross-compiles on
various systems. OTOH, gcc does an excellent job!
For this reason, BSD shouldn't bend over backwards for C++ developers any
more than it should for Python or Ruby developers. The implied stability
and consistency of a finished language is exactly what is needed for a
stable and consistent OS (kernel). Pick a language (let's call it "C")
that isn't likely to evolve any further. Oh wait, we already did :-P
-- Rick C. Petty
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/99979: Get Ready for Kernel Module in C++
On Wed, Jul 12, 2006 at 02:25:21AM +0800, [EMAIL PROTECTED] wrote: > > Matthias Andree wrote: > > Why would people write Windows application with rather MFC/ATL/.NET > Framework than direct Windows API? Because they like buggy code? (Not that the basic API is much better) > Why is gtkmm created for GTK+? Because they enjoy extremely long compile times? And they like wrappers around wrappers around wrappers? > Would you write a X11 application with original X11 API, without QT or > other X11 toolkits? Comparing KDE/Qt to GNOME/GTK+ is comparing C++ to C. I personally prefer the GTK API (GDK is quite similar to the X11 API) over Qt. My preference is mostly due to the overhead and complexity of C++. C++ and Java are great for Applications, not as much so for kernels. I don't mean to drag this into a KDE vs. GNOME flame war. Also this is not a fair comparison because these toolkits augment what X11 provides, much like how userland augments a kernel. Write the front-end in whatever language/toolkit you prefer; you're still calling Xlib to pass packets to/from the X server. > Good packages for various APIs are much easier to learn/debug than those > original APIs. What makes you say that C++ would provide a good API? I think perhaps the problem may be that the current kernel APIs in C are insufficient... but introducing the complexity of C++ both from a language perspective and from a standard library perspective seems silly to me. When on the device driver level, I would rather know precisely when my code is being called and manage my own memory, etc. and other nitty-gritty details. I agree that a good API is crucial! But I also believe that C provides this better than others. You can always write code in C++ which calls C functions, but the converse is quite tricky. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA300 Controllers
On Thu, Jul 06, 2006 at 03:26:17PM -0600, Scott Long wrote: > > > >>Has anyone had success with SATA300 controllers with FreeBSD 6.1? I've > >>been > >>trying Promise and nVidia nForce4 and I'm not having any luck. Using a > >>MSI > >>K8NGM2-L motherboard and others, but 6.1's installation hangs as soon as > >>it > >>sees ad4. I've also tried using an Adaptec 1210SA controller and had zero > > Promise has a good relationship with FreeBSD, I would expect their > controllers to work pretty well. I'm using a few "Promise PDC40718 SATA300 controller" with identical SATA300 drives and it seems to work well. My only gripe is the channels are misnumbered: port #1 maps to channel 3 port #2 maps to channel 1 port #3 maps to channel 0 port #4 maps to channel 2 I had to use the serial numbers to make sure I was writing on the correct drives, so that was annoying. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kldfind, updated for version 0.56
On Sun, May 21, 2006 at 02:28:29PM -0300, Ricardo A. Reis wrote: > > First about exit codes, when program is executed without options, > how this must return ? > kldunload and kldload not return the same exit codes, > >[EMAIL PROTECTED]:~/kldfind] # kldload > usage: kldload [-v] file ... > zsh: 48524 exit 1 kldload > > [EMAIL PROTECTED]:~/kldfind] # kldunload > usage: kldunload [-fv] -i id ... >kldunload [-fv] [-n] name ... > zsh: 48539 exit 64kldunload > > [EMAIL PROTECTED]:~/kldfind] # ./kldfind-v056 > usage: kldfind-v056 [-chqsv] ... > > In kldfind i return 0 See the manpage for sysexits(3). Both should return EX_USAGE (64) in this case. You should only return EX_OK (0) if the command was successful. If you're spitting out usage text, return EX_USAGE. Also by glancing at your usage string, it's not apparent that specifying no options is an invalid usage. Without reading through your script, I'm not sure which options are optional or which are required. I read "[-chqsv]" meaning use any of those options in any combination, or no options whatsoever. Consider something like either: kldfind -c | -s | -h [-qv] modulename ... or a multi-line usage (e.g. something like bsdlabel(1)): kldfind [-qv] -c category ... kldfind [-qv] -s string ... kldfind [-qv] -h Personally, I'd prefer clarity over brevity. Just my 3 cents, -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exiting Xorg panics Core Duo laptop
On Thu, May 11, 2006 at 09:07:03PM -0500, Eric Anderson wrote:
>
> I'd use the nv driver instead, however I'm not sure how to make it work
> with this screen (1920x1200).
This is my entry for my Dell 2405FPW:
Section "Monitor"
Identifier "Monitor1"
DisplaySize 520 330 # yes, I measured it
HorizSync 30.0-81.0
VertRefresh 56.0-76.0
Mode "1920x1200"
DotClock 154.0
HTimings 1920 1968 2000 2080
VTimings 1200 1203 1209 1235
EndMode
Option "DPMS"
EndSection
I can't remember if I needed the frequencies-- I had some initial problems
using the DVI input and nvidia not detecting things correctly, but then I
added this to the Device section:
Option "ConnectedMonitor" "DPF-1"
YMMV,
-- Rick C. Petty
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ordering of ports on Promise PDC40718 SATA300 controller
On Tue, May 09, 2006 at 03:07:57PM +0200, Michal Mertl wrote: > Rick C. Petty wrote: > > What determines the probing order of the ports/channels on the PDC40718 > > (Promise TX4 SATA300 controller)? The SATA ports are labeled "Port 1" > > through "Port 4". I have a total of four of these cards, and all of > > them repeatably probe out of order: > > > > label reported in FreeBSD > > -- --- > > Port 1 > > Port 2 > > Port 3 > > Port 4 > > > > Has anyone else noticed this with these cards? What can I do to fix it? > > I'm running both 6.0-RELEASE and RELENG_6_1 as of 2006-May-07. > > I see that too but I don't care as long as it works :-). Well that's a problem too. I'm not having good luck with this controller on either 6.0 or 6.1 unless I turn both ACPI and PREEMPTION off, and even then sometimes gvinum's raid5 makes the problem even worse... -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ordering of ports on Promise PDC40718 SATA300 controller
What determines the probing order of the ports/channels on the PDC40718 (Promise TX4 SATA300 controller)? The SATA ports are labeled "Port 1" through "Port 4". I have a total of four of these cards, and all of them repeatably probe out of order: label reported in FreeBSD -- --- Port 1 Port 2 Port 3 Port 4 Has anyone else noticed this with these cards? What can I do to fix it? I'm running both 6.0-RELEASE and RELENG_6_1 as of 2006-May-07. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gvinum start volume returns EBUSY
When rebuilding a degraded plex with "gvinum start volume" on a mounted filesystem, gvinum reports "errno: 16" (EBUSY). In the CVS: src/sys/geom/vinum/geom_vinum_init.c, lines 363-364 (of MAIN, added 2005-Oct-09, rev 1.10.2.1) has the check: if (gv_is_open(p->geom)) return (EBUSY); Why is this the case? The log for that change suggests this is to prevent sync operations from starting when they are already in progress, but that really refers to lines 366-367: if (p->flags & GV_PLEX_SYNCING) return (EINPROGRESS); It seems to me that lines 363-364 should be deleted. If you have a degraded volume but need to keep it mounted (such as /usr or /home, etc.), I can't see any reason why you should be forced to unmount the volume before rebuilding (if the volume is RAID5). Maybe this restriction is useful for non-RAID5 configurations, but gv_rebuild_plex is only called in the context of GV_PLEX_RAID5 on degraded plexes. Maybe I'm misunderstanding something. Feel free to enlighten me! :-) -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keyboard Boot Disable
On Tue, Apr 25, 2006 at 06:27:53PM -0400, Lucas Holt wrote: > I worked with someone once that said they blew out the ps/2 port on > the motherboard. As an alternative, maybe you could consider a kvm > switch? Maybe on an ancient motherboard?? Most motherboards have overvoltage/overcurrent protection circuitry. A PS/2 port is just a glorified serial port: 5v signals vs. +/- 7.5v. The only problem I've ever had with hot-swapping PS/2 is tricking the OS to reinitialize the device. FreeBSD seems to handle this better than most. Smart KVMs work much better because they keep the virtual device connected, and they keep keyboard initialization state so they can reinitialize the keyboard when it's plugged in again. Even dumb KVMs seem to handle hot-swapping better; likely the onboard logic behaves better than the onboard keyboard controllers. USB works much better because it guarantees power & ground connection is established before the data pins. Many KVMs buffer the keyboard I/O so it can wait until power & ground are established before trying to send/recv data. I've never blown out a PS/2 port or device, and I hot swap much more than I should... -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: RFC: Adding a ``user'' mount option
On Tue, Apr 04, 2006 at 10:00:00AM -0500, Sergey Babkin wrote: > > Would it make sense to be able to specify a group in fstab? > Then the users can be simply given membership of this > group to mount the devices. Why not just assume allowable users are in the "operator" group. Isn't this what that group was designed for? I certainly setup my boxes to give users permission to access the soundcard and other "operators of this machine" devices... If not operator, then maybe one configurable group, defaulting to operator. Admins who want special circumstances can use devfs rules to set the group for certain devices. This way, we use unix-isms such as: 1). can the user mount filesystems? (vfs.usermount) 2). does the user have permissions to the device? (e.g. group-read/write to said device) 3). does the user have permissions to the mountpoint? (e.g. user read/write/execute) -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programs not accepting input?
On Mon, Mar 27, 2006 at 11:21:53AM +0200, Frank B. Scholl wrote: > > i followed this discussion so far and wondered what your techniques are to > have your running programs accepting input again. in my case, this phenomenon > heavily depends on the windowmanager you chose. when being on fluxbox and > having a running instance of firefox, it every once in a while refuses > keyboard input. i have had this with other gtk apps, too, for example > sylpheed. > > to circumvent the problem and getting your application back to accept further > keyboard input, i just switch workspaces back and forth and thats it, I've tried everything from switching desktops to killing fvwm2. This is how I know it's not window-manager related. As I said before, I can have two rxvts side-by-side. I focus over the left one, type, nothing appears. I focus over the right one, type, keyboard works. Focus back over the left one, nothing. Rinse, repeat. The problem happens more often with GTK apps than a plain rxvt. It's difficult to reproduce the problem, so it's nearly impossible to test. If it were more repeatable, I would have written a test client. Next time it happens, I'll try xev. But I haven't had the problem since I stopped using x11vnc. I only use the nVidia drivers and x.org. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programs not accepting input?
On Sun, Mar 26, 2006 at 07:17:19PM +1100, Peter Jeremy wrote: > > Is the problem that the clients aren't taking focus or have focus > but aren't accepting keyboard input? My problem wasn't about focus. I know the window had input focus (my settings change the border color for focused windows), but the keyboard events weren't accepted by certain clients. > My work system runs separate X servers on two heads (rather than > ximerama) and I have problems with windows occasionally refusing to > accept focus after I move the pointer from screen to screen (though I > can get an alternative window to accept focus and then switch back to > the window I originally wanted). This started after an X.org upgrade > but I'm not sure which one. I've seen that problem also, with and without xinerama enabled (always with dual-head nvidia cards). My keyboard input problem only affected certain clients. Like I said, one rxvt would accept keyboard events and another rxvt right next to it wouldn't. It was an X.org server, I forget the version. I've not noticed the problem recently, but I could try to reproduce the problem if necessary. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programs not accepting input?
[ CC'd to hackers only ] On Sun, Mar 26, 2006 at 05:50:09PM +1030, Greg 'groggy' Lehey wrote: > In the last month or two I've seen increasing occurrences of programs > refusing keyboard input after they've been running for a while > (between hours and days). They still respond to the mouse. At first > I thought it was hardware, but it happens on a number of different > machines, and only with certain programs, all of them X clients. > One thing that the machines have in common is that they all run x2x I noticed very similar problems on both 5.4-stable and 6.0-RELEASE boxes running xorg. I've never used x2x, but I was running x11vnc, which I ended up assuming was the culprit. It's a really strange behavior-- I would have two rxvts side-by-side, one accepting keyboard input and the other I had to cut/paste text using the mouse. It was even more frustrating when it would happen in gaim & mozilla windows! The same gaim process wouldn't accept keyboard input in the conversation window but the buddy window did responded to commands (e.g. control-A brought up the accounts window). I was baffled.. The behavior was unpredictable but sometimes repeatable. Once a window stopped accepting keyboard events, that same window would continue ignoring the keyboard until I restarted that process. At first I thought it just affected GNOME apps, but when it happened to an rxvt, I gave up and recompiled that system and stopped using x11vnc. Sorry I'm no help, but at least I feel sane knowing it wasn't just me... -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-PRE boot locks up, using USB keyboard
On Wed, Mar 15, 2006 at 12:27:08PM -0500, John Baldwin wrote: > On Wednesday 15 March 2006 12:11, Rick C. Petty wrote: > > > > My BIOS (Asus A8N-E rev 1010) has no option for disabling USB keyboard > > support, but I can either disable the USB controller or disable the USB > > legacy support. I doubt either of these is desirable. Fortunately, I > > discovered the problem.. > > The "legacy support" option is the one that makes a USB keyboard look like > a PS/2 keyboard. If I disable legacy support, the USB keyboard is useless until the kernel comes up multi-user and usbd is started, as I expected. Other than that, everything behaves identically. > > Whenever ukbd is loaded by /boot/loader and that > > device already exists in the kernel, the boot locks up after: > > > > atkbdc0: at port 0x60,0x64 on isa0 > > > > when using a USB keyboard. I would think this is a bug. It is 100% > > repeatable for me. If I comment out the line in /boot/loader.conf, the > > system boots nicely. > > Ok. There are several edge cases that can blow up if you kldload a module > or load a module from the loader that is already present in the kernel. I would think the loader or the kernel should be smart enough not to break when loading an already-loaded module. Is there a workaround? If not, all kernels must be compiled with ukbd (if they are to support USB keyboards in single-user mode, e.g.). There should also be a warning "BEWARE: Do not set ukbd_load in your loader.conf" :-P Seriously, though, the kernel should not break when loading an unloaded module. I first noticed this whenever I had umass(4) in the kernel and it wouldn't detect my USB memory stick but then kldload'd it, saw "File exists", but then it would be detected. I remember removing umass from my config and it behaving quite differently. I never had time to pursue that problem. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-PRE boot locks up, using USB keyboard
On Wed, Mar 15, 2006 at 10:46:01AM -0500, John Baldwin wrote:
> > I'm using a USB keyboard, no PS/2. I've tried the hint to disable kbdmux,
> > I've tried with and without selecting the "Boot w/ USB keyboard" and the
> > machine locks up in the same spot no matter what I try. The same hardware
> > boots just fine with 6.0-RELEASE (although I need to choose the USB
> > keyboard option if I plan on typing). Any suggestions?
>
> What if you turn off USB keyboard support in your BIOS?
My BIOS (Asus A8N-E rev 1010) has no option for disabling USB keyboard
support, but I can either disable the USB controller or disable the USB
legacy support. I doubt either of these is desirable. Fortunately, I
discovered the problem..
The ukbd device is compiled into GENERIC. I also had ukbd_load="YES" in my
loader.conf so it would be compatible with a custom kernel. When GENERIC
boots, I get the message that ukbd is already loaded ("file exists"). I
would expect that the kernel just ignores the attempt, but apparently there
is an adverse effect. Whenever ukbd is loaded by /boot/loader and that
device already exists in the kernel, the boot locks up after:
atkbdc0: at port 0x60,0x64 on isa0
when using a USB keyboard. I would think this is a bug. It is 100%
repeatable for me. If I comment out the line in /boot/loader.conf, the
system boots nicely. Perhaps this is related to kbdmux(4), but I'm not
sure. I've also noticed related problems when trying to load umass and ums
through the boot loader and manually (I will try to reproduce these).
Maybe the problem is in the USB layer??
FYI, I tried this on 6.1-BETA4, fresh from the ISOs.
-- Rick C. Petty
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.1-PRE boot locks up, using USB keyboard
Hello. I cvsup'd to 6.1-PRERELEASE today (Mar 14 2006), installed world, and tried booting the GENERIC kernel. My machine hangs after the following messages: pmtimer0 on isa0 orm0: at iomem 0xd-0xd3 on isa0 atkbdc0: at port 0x60,0x64 on isa0 (None of the other visible messages pertain to the keyboard or USB, and I can't scroll back) I'm using a USB keyboard, no PS/2. I've tried the hint to disable kbdmux, I've tried with and without selecting the "Boot w/ USB keyboard" and the machine locks up in the same spot no matter what I try. The same hardware boots just fine with 6.0-RELEASE (although I need to choose the USB keyboard option if I plan on typing). Any suggestions? -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
inode recovery and differences between UFS1/2 & soft updates
Hello. I posted a message to ports yesterday regarding the status of sysutils/ffsrecov, which won't compile with UFS2 headers. I'm in dire need of reconnecting or dumping inodes (well the associated files) because of a pair of crashes causing fsck to fail due to "unreferenced files". A few years back I did a bunch of work with UFS1/FFS including a few personal utilities to dump unconnected files, etc. I know the UFS1 implementation pretty well, but that was prior to the use of soft updates or the new UFS2. I'd like to pull the valuable data off this drive before I fsck it clean and thus modify the file system. My question(s) concern the differences between UFS1 & UFS2 and the use of soft updates. AFAICT, soft-updates affects the in-memory copy and does not affect the structures on the FS itself, just the order in which those structures are updated to improve performance. I therefore assume that the FS structure is similar to the original UFS1/FFS and could use my old utilities to dump the files without modification. The concern is that possibly soft updates was interrupted during a metadata write and maybe the inode or something else became corrupt; I can't imagine how, I just wanted to verify that this wouldn't happen. It seems to me that the basic differences between UFS1 & UFS2 are the new ACLs and extended attributes, both of which don't change the underlying format of the file system. It is my guess that I should be able to repair this and even recompile ffsrecov using the old UFS headers. I'm also guessing that I should be able to throw the drives into an older freebsd system (w/o UFS2) and recover it that way. Please let me know if I'm way off base here. On a related note, the soft-updates document, http://www.usenix.org/publications/library/proceedings/usenix99/mckusick.html implies that the unconnected inodes I'm seeing with fsck are files that were deleted when the system was previously up, whose metadata was written but whose inodes' link counts weren't decremented yet. In such a case, these "unreferenced files" should be unimportant. I still wish to dump the inodes because one of my drives had a low-level failure (hence why the system crashed twice in a row) and after fsck-ing some important files did disappear without a trace (I have a list of inodes and the FS was only mounted read-only to verify the file integrity). I'm running 5.1-RELEASE with UFS2 on both drives and softupdates enabled. They are ATA/133 and ATA/100 respectfully (although the ATA/100 workes better at udma66-- otherwise I get a bunch of ICRC errors and often it'll drop to PIO mode). Any help on this topic would be appreciated. Some of the data is vital and I need it quickly. Thanks in advance, -- Rick C. PettySenior Software Engineer, KIWI Computer --- [EMAIL PROTECTED]http://www.kiwi-computer.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
