debugging a proc's kernel stack...
Hi, I want to see where some a deadlock is occurring in the kernel. I've got a dump with a bunch of processes in the inode or namecache state. Can anybody give me a hint about how to find a proc's "kernel stack" - so that I can find out what these kernel was doing for these processes when it locked up... (see "repeated deadlocks in FS ..." on the smp list for more info about the problem)... thanks alot, greg To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
cache-friendly scheduling for SMP
I'm trying to run 1-2 processes with very large memory footprints on my P2 SMP machine. I'm finding that the process switches cpu's quite often, which obviously isn't good for the caches on the CPU. Can anybody point me to a paper, mailing list discussion, etc. that discusses scheduling processes to not thrash the cpu caches? Or if there's anything in place, how I can take advantage of it, etc. I got stumped on the idea a while ago, so I'm really curious... thanks, Greg To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
debugging a proc's kernel stack...
Hi, I want to see where some a deadlock is occurring in the kernel. I've got a dump with a bunch of processes in the inode or namecache state. Can anybody give me a hint about how to find a proc's "kernel stack" - so that I can find out what these kernel was doing for these processes when it locked up... (see "repeated deadlocks in FS ..." on the smp list for more info about the problem)... thanks alot, greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cache-friendly scheduling for SMP
I'm trying to run 1-2 processes with very large memory footprints on my P2 SMP machine. I'm finding that the process switches cpu's quite often, which obviously isn't good for the caches on the CPU. Can anybody point me to a paper, mailing list discussion, etc. that discusses scheduling processes to not thrash the cpu caches? Or if there's anything in place, how I can take advantage of it, etc. I got stumped on the idea a while ago, so I'm really curious... thanks, Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default value for UIDs
On Tue, Jun 28, 2011 at 09:11:54PM +0100, Chris Rees wrote: > On 28 June 2011 20:57, Chris Rees wrote: > > On 28 June 2011 20:50, jhell wrote: > >> On Tue, Jun 28, 2011 at 06:30:23PM +0100, Chris Rees wrote: > >>> On 28 June 2011 17:59, Dan Nelson wrote: > >>> > In the last episode (Jun 28), Chris Rees said: > >>> >> Hi all, > >>> >> > >>> >> [crees@zeus]~% tail -n 2 /usr/ports/UIDs > >>> >> dbxml:*:949:949::0:0:dbXML user:/nonexistent:/sbin/nologin > >>> >> nobody:*:65534:65534::0:0:Unprivileged > >>> >> user:/nonexistent:/usr/sbin/nologin > >>> >> [crees@zeus]~% grep crees /etc/passwd > >>> >> crees:*:1001:1001:Chris Rees:/home/crees:/bin/tcsh > >>> >> chris:*:1001:1001:Chris Rees:/home/crees:/bin/tcsh > >>> >> [crees@zeus]~% > >>> >> > >>> >> I'm a little concerned at how close the ports UIDs are getting to the > >>> >> username space... > >>> > > >>> > There are only 216 entries in UIDs, though, so if people are just using > >>> > "last entry + 1" when adding new ones, they should probably start > >>> > filling > >>> > the gaps instead. ?The 100s and 200s are pretty dense, but 350-399 only > >>> > has > >>> > 5 entries, 400-499 has 4, 600-699 has 7, 700-799 has 3, etc. > >>> > > >>> > >>> Thank you for pointing that out (d'oh). > >>> > >>> However, perhaps we could still address the *potential* problems. To > >>> use one example, Debian has (as long as I can remember) used 10001 for > >>> the first username. When we have 65535 - 99 UIDs to play with, > >>> expansion like this isn't a problem. > >>> > >>> Could it be worth it? Think of ten years down the line. > >>> > >> > >> Best part would be to find every port that doesnt need a statically > >> allocated UID/GID and just dynamically allocate them after a certain > >> range '3-5' or whatever for ~20,000 ports and divide that > >> namespace up by category. > >> > >> > >> dbxml really does it really need to be static ? it just needs to run. > >> > >> Also: (stable/8) /usr/ports/UIDs > >> dbxml:*:945:945::0:0:& user:/nonexistent:/sbin/nologin > >> dbxml:*:949:949::0:0:dbXML user:/nonexistent:/sbin/nologin > >> > >> Which one of these are we planning on actually using here ? > >> > > > > Interesting... glewis added the second one. > > > > Greg, what did the pointyhat say? > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/UIDs.diff?r1=1.156;r2=1.155;f=h > > > > > Mystery solved. > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/UIDs Yep, I forgot to commit my UIDs, GIDs changes with the update to dbXML, got the pointyhat email and then merged and committed without paying enough attention. Sorry about that. Thanks for removing the extra definition! -- Greg Lewis Email : gle...@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : gle...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
GSoC mutex contention profiling and lock order verification
The pthread mutex contention profiling and lock order verification entry on the ideas list caught my eye. I'm looking for a potential mentor, and any ideas or suggestions about what's desired in such a tool. The ideas page lists jeff@ as a contact, but I've not gotten a response as yet, so does anyone have an interest in this, and maybe some suggestions? ___ 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: sendmail disabled, but 'service -e' lists it as enabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/25/12 2:09 PM, rank1see...@gmail.com wrote: > # grep sendmail /etc/rc.conf sendmail_enable="NONE" # service -e | > grep sendmail /etc/rc.d/sendmail # ps -U root | grep sendmail > > > Domagoj Smolčić Hi Domagoj, /etc/rc.d/sendmail explicitly sets some variables to "NO" when sendmail_enable is "NONE". Unfortunately, the service script does not take that into account, so if you want it to report correctly, place these lines in /etc/rc.conf: sendmail_enable="NONE" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" That will cover all bases, in case some other tool depends on the value of sendmail_enable. Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+YSNUACgkQ0sRouByUApAWVQCgtKdAVtJ6Cv/TMEbpEafZRmEA 6ZkAoKyxKQGuyj73w4Hrb/hIF7xwJurg =bb7F -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: considering i386 as a tier 1 architecture
On 4/1/13, Dag-Erling Smørgrav wrote: > You're assuming that maintaining i386 as a tier 1 platform really *does* > add significantly to our workload. Indeed. We don't seem to be running into a ton of issues on this front, and I do still find my 32-bit only Atom-based netbook useful when traveling. > You should also check your calendar :) This is one of the finest pieces of April Fools' Day trolling I've seen in quite some time. I'd rank it right up there with that press release from some years ago about Microsoft's acquisition of the Roman Catholic Church. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: how do I build a single app?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/17/13 11:42 AM, david.lee...@programmer.net wrote: > Hi, > > I installed FreeBSD into a VirtualBox VM in January and started > playing with the code. I must complement you people on the clarity > of your code. I've enjoyed examining it. > > I wanted to try some code changes to some of the apps in the /bin > directory, but can't figure out how to build a single app, or even > build a single set of apps, like /usr/src/bin, /usr/src/sbin, > /usr/src/usr.bin, or /usr/src/usr.sbin. Is there a way to do this, > or do I just have to create my own Makefiles for each app I am > experimenting on? > > If this is the wrong place to ask this question, I appologize and > ask you to direct me to a mailing list that would be the > appropriate place to ask this. > > Sincerely, > > David Lee from Tennessee Hi David, You can build a single application like so: cd /usr/src/bin/csh && make install Just replace "bin/csh" with the tool you are interested in building, and you should be all set. Regards, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG/TjsACgkQ0sRouByUApDFXgCfXsIjl6PkBGei6HwoHvSZ2rg0 /9UAoLthLoGVjgroByhtA054qD8VH3rk =bgQw -END PGP SIGNATURE- ___ 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"
Instruction fault panic while installing 6.2 on VMware Server
Hi everyone, I'm creating a standard FreeBSD 6.2 ISO image that I can use to perform unattended installations into VMware Server virtual machines. I'm using VMServer 1.0.1, and I've hit a roadblock when sysinstall attempts to create the root filesystem. The first thing to mention is that VMServer is running on a CentOS 4.4 host OS, and the CPU architecture is a Via C3 Nehemiah. Technically, the VMServer software is not supposed to work on the Via C3 line, but the Nehemiah apparently supports the CMOV instruction that VMServer requires. I've been able to install Fedora Core 6 successfully and run it with no problems, so I'm wondering if I just need to find the right options to configure FreeBSD 6.2 to get it to work. Anyway, the VM boots fine, loads the FreeBSD ISO, and launches sysinstall, but as soon as newfs is invoked to make the root filesystem, I get this: Making a new root filesystem on /dev/ad0s1a Panic: privileged instruction fault (auto reboot) I've tried installing from the standard 6.2 release ISO as well as a custom ISO with a recompiled kernel, but I get the same error either way. I also tried disabling ACPI during boot with no success. My custom kernel config is included below. My first thought was that if I explicitly set the CPU to I486, that might help avoid the instruction fault, but that doesn't work. I didn't see any other options that looked like they would fix the fault, but I'm not very experienced at kernel configuration either. Does anyone have an idea how to troubleshoot this problem? Thank you for any help! Regards, Greg Larkin machine i386 cpu I486_CPU ident VMWAREC3 makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic# I/O APIC device pci device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives options ATA_STATIC_ID # Static device numbering device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. device mpt # LSI-Logic MPT-Fusion device bt # Buslogic/Mylex MultiMaster SCSI adapters device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) device at
RE: Instruction fault panic while installing 6.2 on VMware Server
> > Hi, > > On 2/23/07, Greg Larkin <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > > > I'm creating a standard FreeBSD 6.2 ISO image that I can use to > > perform unattended installations into VMware Server virtual > machines. > > I'm using VMServer 1.0.1, and I've hit a roadblock when sysinstall > > attempts to create the root filesystem. > > > > The first thing to mention is that VMServer is running on a > CentOS 4.4 > > host OS, and the CPU architecture is a Via C3 Nehemiah. > Technically, > > the VMServer software is not supposed to work on the Via C3 > line, but > > the Nehemiah apparently supports the CMOV instruction that VMServer > > requires. I've been able to install Fedora Core 6 successfully and > > run it with no problems, so I'm wondering if I just need to find the > > right options to configure FreeBSD 6.2 to get it to work. > > > > Anyway, the VM boots fine, loads the FreeBSD ISO, and launches > > sysinstall, but as soon as newfs is invoked to make the root > > filesystem, I get this: > > > > Making a new root filesystem on /dev/ad0s1a > > Panic: privileged instruction fault > > (auto reboot) > > > > I've tried installing from the standard 6.2 release ISO as well as a > > custom ISO with a recompiled kernel, but I get the same error either > > way. I also tried disabling ACPI during boot with no success. > > > > My custom kernel config is included below. My first > thought was that > > if I explicitly set the CPU to I486, that might help avoid the > > instruction fault, but that doesn't work. I didn't see any other > > options that looked like they would fix the fault, but I'm not very > > experienced at kernel configuration either. > > > > Does anyone have an idea how to troubleshoot this problem? Thank you > > for any help! > > > > Regards, > > Greg Larkin > > I have experienced similar problem in VMware Workstation > under Windows XP > on Via C3 Nehemiah processor since FreeBSD 5.x. In my case privileged > instruction fault shot somewhere in rc boot process. Tracing > down the cause of > fault i found out that it was xstore instruction, which > VMware did not emulate. > It turned out to be the merit of new random generator > appeared somewhere in > 5.x, which detected the Via processor and tried to use its > hardware random > number generator. My workaround was to patch kernel to > disable using this Via > processor feature completely. The result was successful > booting and running > FreeBSD 5.x and 6.x under VMware on this machine. > > Attached is the patch i use for 6.x kernel. > > Hope this helps. > > -- > ghozzy > Hi Ghozzy, Thanks very much for that - I appreciate it! I'm in the midst of building a new ISO, and I'll test it out and let you know what happens. I should have grepped /usr/src for "Nehemiah"! Do you (or others) think there is any call for either VMware Server detection in the kernel or a kernel config option specifying that the kernel is going to run in a VM? I wonder if patches like this and others would be useful to add to the official kernel sources, since VMware supports FreeBSD as a guest OS? Perhaps there are other kernel optimizations and configuration options that would make sense if the kernel knew it was running in a VM? Regards, Greg Larkin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Instruction fault panic while installing 6.2 on VMware Server
> > > On 02/24/07 05:44, ghozzy wrote: > > Hi, > > > > On 2/23/07, Greg Larkin <[EMAIL PROTECTED]> wrote: > >> Hi everyone, > >> > >> I'm creating a standard FreeBSD 6.2 ISO image that I can use to > >> perform unattended installations into VMware Server > virtual machines. > >> I'm using VMServer 1.0.1, and I've hit a roadblock when sysinstall > >> attempts to create the root filesystem. > >> > >> The first thing to mention is that VMServer is running on > a CentOS 4.4 > >> host OS, and the CPU architecture is a Via C3 Nehemiah. > Technically, > >> the VMServer software is not supposed to work on the Via > C3 line, but > >> the Nehemiah apparently supports the CMOV instruction that VMServer > >> requires. I've been able to install Fedora Core 6 successfully and > >> run it with no problems, so I'm wondering if I just need > to find the > >> right options to configure FreeBSD 6.2 to get it to work. > >> > >> Anyway, the VM boots fine, loads the FreeBSD ISO, and launches > >> sysinstall, but as soon as newfs is invoked to make the root > >> filesystem, I get this: > >> > >> Making a new root filesystem on /dev/ad0s1a > >> Panic: privileged instruction fault > >> (auto reboot) > >> > >> I've tried installing from the standard 6.2 release ISO as > well as a > >> custom ISO with a recompiled kernel, but I get the same > error either > >> way. I also tried disabling ACPI during boot with no success. > >> > >> My custom kernel config is included below. My first > thought was that > >> if I explicitly set the CPU to I486, that might help avoid the > >> instruction fault, but that doesn't work. I didn't see any other > >> options that looked like they would fix the fault, but I'm not very > >> experienced at kernel configuration either. > >> > >> Does anyone have an idea how to troubleshoot this problem? > Thank you > >> for any help! > >> > >> Regards, > >> Greg Larkin > > > > I have experienced similar problem in VMware Workstation > under Windows XP > > on Via C3 Nehemiah processor since FreeBSD 5.x. In my case > privileged > > instruction fault shot somewhere in rc boot process. > Tracing down the cause of > > fault i found out that it was xstore instruction, which > VMware did not emulate. > > It turned out to be the merit of new random generator > appeared somewhere in > > 5.x, which detected the Via processor and tried to use its > hardware random > > number generator. My workaround was to patch kernel to > disable using this Via > > processor feature completely. The result was successful > booting and running > > FreeBSD 5.x and 6.x under VMware on this machine. > > > > Attached is the patch i use for 6.x kernel. > > > Can you both send me the dmesg of these machines? > > > Eric > > Hi Eric, Here is the dmesg output of the FreeBSD 6.2 virtual machine that has ghozzy's probe.c patch in place. His patch prevents the kernel from using the XSTORE instruction that VMware Server doesn't support. Let me know if you need any other information. I don't remember if I cc'd the list or not a few days ago when I emailed ghozzy, but his patch fixed the installation problem I was having, and I no longer get the instruction fault panic when the root filesystem is built. I haven't put the new VM through any strenuous testing yet, but I will be over the next few weeks, and I'll update the list if the system crashes again. Thank you, Greg Copyright (c) 1992-2007 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 6.2-RELEASE-VMWAREC3 #0: Mon Feb 26 22:10:58 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: VIA C3 Nehemiah+RNG (1000.35-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x693 Stepping = 3 Features=0x380b33d real memory = 268435456 (256 MB) avail memory = 253083648 (241 MB) MADT: Forcing active-low polarity and level trigger for SCI 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
RE: Are there any known issues for installing FreeBSD on Vmware onwindows XP ?
> > Hey all, > > Are there any known issues for installing FreeBSD on Vmware > on windows XP ? > I have never tried installiing FreeBSD earlier and i just saw > a mail in this > mailing list regarding some problems while installing on > vmware. Could not > make out much. Can someone just elaborate on the issues faced while > installing on Vmware. > > Regards, > ajay. Hi Ajay, I wrote in to the list a little while back about VMware installation problems that I had with FreeBSD 6.2, but the issue was completely related to the CPU architecture (Via C3 Nehemiah) that I was using. VMware doesn't officially support that processor, even though it's supposed to be Intel compatible. Another list member sent me a kernel patch that fixed the problem (thanks ghozzy). I also have a WinXP box with a Celeron processor in it and VMware Server installed, and FreeBSD 4.x and 6.x both install and run with no problems at all. If you have any specific questions, let me know and I'll try to answer them. I'm going to be learning a lot more about VMware Server and FreeBSD in the coming months, as I'm working on redeploying my company's service using those tools as the foundation. I hope to share that knowledge with the list as I proceed. I also found this thread (http://lists.freebsd.org/pipermail/freebsd-questions/2006-October/132 716.html) with some information in it about issues to be aware of while running FreeBSD as a guest OS under VMware. Follow the thread a little way, and you'll see an example kernel config file, too. Best of luck, Greg Larkin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux executable picks up FreeBSD library over linux one and breaks
I had a Linux shared library problem on NetBSD that I think it might be helpful to mention. thunderbird (and firefox) set LD_LIBRARY_PATH to pick up their own modules. When acroread is invoked to display a pdf attachment, LD_LIBRARY_PATH is still set, and this causes acroread to read a BSD library. My workaround is to use a script for acroread that cleans the environment. I think this is a thunderbird bug; the environment of invoked programs should match the environment as of thunderbird's invocation. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: cvs question
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Aryeh > M. Friedman > I maintain a local repo of the via the cvs mode of cvsup. > When I do a: > > cvs -q -d /home/ncvs update > > It will update any modified files but will not add any new > files (it removes stale ones), but if I do a checkout it > overwrites my local modifications... any way to automatically > add new files but preserve local mods? Hi Aryeh, Give this a try: cvs -q -d /home/ncvs update -d The -d option given to the update subcommand builds directories the way cvs checkout does. Without it, update will only operate on directories that are already in your sandbox. Regards, Greg Larkin SourceHosting.net, LLC http://www.sourcehosting.net/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strdup(NULL) supposed to create SIGSEGV?
On 2008-04-23, Simun Mikecin wrote: > According to Open Group strdup should return NULL and set errno. Look at: > http://www.opengroup.org/onlinepubs/009695399/functions/strdup.html If you're going to quote documents to support your ideas, it's probably better to read them first. That document gives only lack of memory as a reason for failure. It does not state clearly, but clearly requires, correct behaviour from the caller who is required to provide a string argument. NULL is not a string, so the behaviour of the function is undefined. Basic C programming requires people not to step into the wilderness of undefined behaviour. > There is no valid argument for doing segfault instead of above behavior. If you can find an alternative that is not actually wrong, then by all means share it. To me, it seems like a good choice. Clearly, I am not alone. Greg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Cable quality (was: poor ethernet performance?)
On Friday, 16 July 1999 at 19:15:31 -0700, Matthew Dillon wrote: > : Actually, I was referring to *digital* Audio cables like those > :used for CD Transports to Digital/Analog convertors such as Kimber Kable > :would be higher grade compared to Monster Cable. You're correct about the > :bit errors though. > > Digital is digital. Either it works or it doesn't. Anything that goes over copper isn't digital, it's digital simulated on analogue. Poor quality cables *can* cause problems. But I'm sure that most of the folklore that circulates on this subject is of the same nature as the advice to use loudspeaker cables with at least 20mm**2 cross section, preferably driven by tube-based amplifiers. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Booting from vinum?
On Saturday, 17 July 1999 at 22:51:17 +0400, Alex Povolotsky wrote: > Hello! > > Is it possible to have a root partition on vinum'ed disk and benefit from > mirroring? If yes, how do I do it? Not yet. It's on the drawing board. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum is cool. anyone bitten recently?
On Saturday, 17 July 1999 at 15:07:12 -0500, Craig Johnston wrote: > Well, I'm looking into doing striping and mirroring on a new webserver > I am bringing up (3.2-stable) and I have to say, vinum looks very cool. > It took me like half an hour to get it going from first contact. > > Nice job Greg -- very straightforward. Thanks. > Now, the official status of vinum is still alpha, right? Wrong. It went out of alpha about a year ago. It's been released in 3.1 and 3.2. > But then again I know that that was (is?) the official status of > softupdates for quite some time and I have been using it with no > problems. > > So my question is, has anyone actually been bitten by vinum recently? > I'm willing to take my chances if I can at least be pretty sure that I > won't suddenly lose everything on both plexes if I am mirroring. That shouldn't happen. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
How much memory do we need to install?
AFAIK, the minimum memory for installation is still 5 MB, and the problems people had with 8MB machines failing to install was a bug, right? What's the current status? Greg - Forwarded message from Thierry Herbelot - > Delivered-To: freebsd-questi...@freebsd.org > Date: Mon, 19 Jul 1999 09:49:01 +0200 > Reply-To: thierry.herbe...@alcatel.fr > Organization: ALCATEL CIT Nanterre > X-Mailer: Mozilla 4.5 [en] (WinNT; I) > X-Accept-Language: en > To: Ben Salem > Cc: freebsd-questi...@freebsd.org > X-Loop: FreeBSD.ORG > Precedence: bulk > > You must have more than 8 Megs to install FreeBSD > > TfH > > Ben Salem wrote: >> >> Im attempting to install FreeBSD 3.2-RELEASE on a 486 8mb ram. >> >> Everything goes ok until the installation actually begins, it gets to >> chunk 1 of 106 then stops. >> >> The install seems to work fine on my other machines. >> >> I have replaced the NIC card, so I think I can rule that out. >> >> Any ideas? >> >> Thanks >> Ben Salem - End forwarded message - -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
problems with the integrated tcp-wrappers.
I've just recently switched from using the tcpwrappers port to the native tcpwrappers implemention the following config entries worked on the port but are not working with the native teln...@xxx.yyy.84.2 ftpd rlog...@xxx.yyy.84.2 r...@xxx.yyy.84.2 nta...@xxx.yyy.84.2 :\ KNOWN :\ rfc931 :\ banners /usr/local/etc/tcpd/banners.allow :\ spawn = (echo "permitted\: %s from %c" | /usr/bin/Mail -s "tcpd\: [P] %c -> %s" security)& # ssh is broken using spawn =, so don't. sshd sshdfwd-X11 : \ KNOWN \ xxx.zzz.118.0/255.255.255.0 : rfc931 It seems that the spawn is broken I've found this out by moving the banners line above the spawn. -- Email: ska...@worldgate.comVoice: +780 413 1910 Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 ---- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris)<>
Re: polling in device driver
[returning to -hackers]
On Wednesday, 21 July 1999 at 16:20:48 -0700, Jeff Hagendaz wrote:
> Hi,
>
> I asked this in -hackers, but didn't get an answer.
> Guess it is too simple to quanlify into -hackers,
> I am moving it here. Your help is highly appreciated.
No, -hackers is the right place. Just because you don't get an answer
doesn't mean that you posted in the wrong place :-)
> I am reading a Linux device driver. At some point it
> polls a device to check if it is ready. The timeout
> is set to 5 second. It uses the system jiffies to
> count the time:
>
> u32 time_out = jiffies + 5 * HZ;
> for (;;) {
> /* code to check if dev is ready */
>
> if (ready) break;
> if (intr_count == 0) schedule();
> if (jiffies > time_out) return ERROR;
> }
>
> How do I implement such polling in FreeBSD? Thanks.
If at all possible, you don't. If it's in the bottom half, you don't.
You should try to find a better way to find when the device is ready:
the driver appears to be counting interrupts, so you can probably
tsleep for 5 seconds and wakeup from the lower half when you get an
interrupt. It's difficult to give an example from the code you show.
Greg
--
When replying to this message, please copy the original recipients.
For more information, see http://www.lemis.com/questions.html
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: deny ktrace without read permissions?
On Friday, 23 July 1999 at 22:12:29 -0700, jko...@freebsd.org wrote: > > > PR bin/3546 asks that `ktrace(1)' not be allowed on files that do not have > read permissions for the user attempting to execute them. > > The intent of this change is to prevent a user from seeing how an > executable with '--x--x--x' perms works by ktrace'ing its execution. > > My question to the -hackers is: is this a useful semantic? Yes, I think so. > Would it break anything if added? Not that I can think of. But that doesn't mean anything. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Which /etc-files do I need until vinum is initialized?
On Tuesday, 27 July 1999 at 9:32:51 +0200, Alexander Maret wrote: > Hi, > > I configured vinum (RAID 1) on a 3.2S System. As I want to mirror > as much as I need to keep the system running (in case of a drive 1 > failure) I mirrored /etc as well. At boot time (until vinum is > initialized) the system only has the following files: > > /etc/defaults/rc.conf > /etc/rc.conf > /etc/rc > /etc/fstab > /etc/gettytab > /etc/login.conf > /etc/ttys > > Do I need all of these files or can I put some of them away > (for example /etc/ttys or /etc/gettytab)? The files > would of course be available as soon as vinum is initialized > and /etc mounted. Interesting question. In view of the fact that I intend to make the root file system bootable One Of These Days, I don't think you should go to too much trouble here: after all, they're only a few kilobytes each. But I think you could eliminate these ones: > /etc/gettytab > /etc/login.conf > /etc/ttys You might find it advantageous to modify /etc/rc to mount /etc (and anything else you want) immediately after starting Vinum: if [ X$start_vinum = XYES ]; then vinum start mount /etc elif [ -n "$vinum_drives" ]; then vinum read $vinum_drives mount /etc fi Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: adding to periodic/weekly
On Wednesday, 28 July 1999 at 3:04:25 +1000, Sue Blake wrote: > I want to add some maintenance tasks to be run weekly (maybe daily ones too). > There seem to be at least five ways to do this: > > Just add it to the system crontab > - Can run at a different time, if necessary. Leaves periodic unmolested. > - Separates it from other weeklies, could become lost or confusing. > Add it to /etc/periodic/weekly/999.local > - This might be what the file is intended for. > - Maybe I shouldn't clutter that file. > Create /etc/weekly.local and put it in there > - It's tempting because 999.local picks it up if present. > - Comment says this is only for backward compatibility. > Add another file /etc/periodic/weekly/.whatever > - Can keep it away from existing sequence, or insert if necessary > - Future upgrades might add files using the numbers I choose > Put it in a numbered file under /usr/local/etc/periodic/weekly/ > - This seems to be what it's intended for, but nobody said I could > - Path is already in rc.conf but doesn't exist, not sure why not used > - Can't find doc on its use, e.g. run in path order? unique numbers required? > > Which method is generally best, and why? > Are any of these methods really naughty? Interesting question. I don't have any personal preferences, though I put my stuff in /etc/crontab or my private crontab out of habit. But this is probably material for -hackers, so I'm forwarding it there. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding disks -the pain. Also vinum
On Tuesday, 3 August 1999 at 11:11:39 +0800, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > The people who I work for were about to junk a bunch of 6 year old disks when > I snaffled them. Among them were 4 DEC DSP5400S (3.8GB each), with a nice > external case. These disks had been doing duty on a boat carrying out seismic > surveys, attached to misc. Sun workstations. These are typical of their > vintage - full height 5 1/4" drives fast narrow SCSI2, and noisy as all > blazes. I have them hooked up to a NCR810, as one striped FS (it's just for > experiments, not valuable data). fdisking them was easy, but disklabelling > them was a royal pain. I ended up editing the /etc/disktab file to add an > appropriate label and running "disklabel -w -B /dev/rda0c DSP5400S" which > still gives an error message, but appears to install the label. I only found > out that it installed the label by accident, wasting a bunch of time in the > process. Did you try 'disklabel -w da0 auto'? > I created a striped volume across the 4 drives with the default stripe size of > 256K. I read the rather interesting discussion within the man pages about the > optimal stripe size and have a couple of queries. Firstly, the type of traffic > that this 13.9GB filesystem will see will be mainly sequential reading and > writing of large files. There will only be a few files (~2-30), each several > gigs. (I'm fooling around with the seismic software at home, and typcal > surveys can results in files many gigs in size). Given that FreeBSD breaks > I/Os down into 64k chunks, would having a 64k stripe size give more > parallelism? No, it would cause a higher I/O load. Vinum doesn't transfer entire stripes, it transfers what you ask for. With a large stripe size, the chances are higher that you can perform the transfer with only a single I/O. > I'm seeing 4.4MB/s if I read from an individual disk, but only about > 5.6MB/s when reading from the striped volume. How many concurrent processes? Remember that striping doesn't buy you anything with a single process. You might like to try rawio (ftp://ftp.lemis.com/pub/rawio.tar.gz) and see what that tells you. > Looking at the systat display, the 8k fs blocks do seem to be > clustered into larger requests, so I'm not too worried about the FS > block size. What have people observed with trying larger FS block > sizes? I don't know if anybody has tried larger FS blocks than 8 kB. I once created a file system with 256 kB blocks (just to see if it could be done). I also tried 512 kB blocks, but newfs died of an overflow. I'd expect that you would see a marked drop in performance, assuming that it would work at all. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding disks -the pain. Also vinum
On Tuesday, 3 August 1999 at 8:12:17 +0200, Bernd Walter wrote: > On Tue, Aug 03, 1999 at 12:16:06PM +0800, Stephen Hocking-Senior Programmer > PGS Tensor Perth wrote: >> >>> No, it would cause a higher I/O load. Vinum doesn't transfer entire >>> stripes, it transfers what you ask for. With a large stripe size, the >>> chances are higher that you can perform the transfer with only a >>> single I/O. >> >> Even if I'm using really large reads? > Several month ago I beleaved the same but there are severall points here: > - UFS/FFS don't handle clustering over 64k > - modern harddisks do preread simply by having a reversed sector layout. > - without spindle syncronisation you will have additional latency > - vinum don't aggregate access to subdisks, so the transfer to the subdisks >is limited by the stripe size. Note, BTW, that this wouldn't make much sense. To aggregate access to consecutive stripes, your transfer would have to involve *all* the disks in the stripe set, which would be a ridiculous performance hit. Read http://www.lemis.com/vinum/Performance-issues.html for more details. > For UFS/FFS there is nothing worth seting the stripesize to low. > It is generally slower to acces 32k on different HDDs than to acces 64k on > one HDD. It is always slower where the positioning time is greater than the transfer time for 32 kB. On modern disks, 32 kB transfer in about 300 µs. The average rotational latency of a disk running at 10,800 rpm is 2.8 ms, and even with spindle synchronization there's no way to avoid rotational latency under these circumstances. > Spindle Sycronisation won't bring you that much on modern HDDs - I tried > it using 5 Seagate Elite 2.9G (5,25" Full-Height). It should be useful for RAID-3 and streaming video. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding disks -the pain. Also vinum
On Tuesday, 3 August 1999 at 23:20:45 +0200, Bernd Walter wrote: > On Tue, Aug 03, 1999 at 03:59:46PM +0930, Greg Lehey wrote: >> On Tuesday, 3 August 1999 at 8:12:17 +0200, Bernd Walter wrote: >> >>> For UFS/FFS there is nothing worth seting the stripesize to low. >>> It is generally slower to acces 32k on different HDDs than to acces 64k on >>> one HDD. >> >> It is always slower where the positioning time is greater than the >> transfer time for 32 kB. On modern disks, 32 kB transfer in about 300 >> µs. The average rotational latency of a disk running at 10,800 rpm is >> 2.8 ms, and even with spindle synchronization there's no way to avoid >> rotational latency under these circumstances. > > It shouldn't be the latency, because with spindlesync they are the same > on both disks if the transfer is requested exactly the same time what > is of course idealized.. Spindle sync ensures that the same sectors on different disks are under the heads at the same time. When you perform a stripe transfer, you're not accessing the same sectors, you're accessing different sectors. There's no way to avoid rotational latency under these circumstances. > The point is that you have more then a single transfer. With small > transfers spindle sync is able to winback some of the performance > you have lost with a to small stripe size. No, this isn't correct, unless you're running 512 byte stripes. In this case, a single-stripe transfer of, say, 8 kB with the disks above would take about 7 ms total latency (same as with a single disk), but the transfer would take less time--5 µs instead of 80 µs. You'd need 16 disks, and you'd tie them all up for 7 ms. And this doesn't consider the times of SCSI command setup and such. Basically, this is not the way to go if you have multiple clients for your storage. Look at http://www.lemis.com/vinum/problems.html and http://www.lemis.com/vinum/Performance-issues.html and for more details. >>> Spindle Sycronisation won't bring you that much on modern HDDs - I tried >>> it using 5 Seagate Elite 2.9G (5,25" Full-Height). >> >> It should be useful for RAID-3 and streaming video. > > I case of large transfers it will make sense - but FFS is unable to set > up big enough requests. No, this is a case where you're only using one client, so my argumentation above doesn't apply (since you're reading sequentially, so latency is no longer an issue). Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Usenix 93 paper on hardware profiling of 386BSD
On Saturday, 7 August 1999 at 1:06:51 -0700, Arun Sharma wrote: > Does anyone have a copy of Andrew McRae's Usenix 93 paper ? > > The URL: ftp://ftp.cisco.com/amcrae/hardprof.PS doesn't > seem to be valid any more. On Saturday, 7 August 1999 at 16:27:39 +1000, Andrew McRae wrote: >> On Saturday, 7 August 1999 at 1:06:51 -0700, Arun Sharma wrote: >>> Does anyone have a copy of Andrew McRae's Usenix 93 paper ? >> >> You, maybe? >> >>> The URL: ftp://ftp.cisco.com/amcrae/hardprof.PS doesn't >>> seem to be valid any more. > > Try my home page: > > http://www.employees.org/~amcrae > > The link is: http://www.employees.org/~amcrae/papers/final_usenix.pdf Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel debugging questions
On Thursday, 19 August 1999 at 12:15:51 -0400, Zhihui Zhang wrote: > > I am using FreeBSD 4.0 and have two questions on kernel debugging: > > (2) After bootup, I try the following to debug the live system (after > reading some pages of the book "Panic! Unix system crash dump analysis"): > > now4# gdb -k /kernel.debug /dev/mem > (kgdb) run > Starting program: /kernel.debug > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > You can't do that without a process to debug. > > Is there something wrong? Yes. You shouldn't try to run the kernel. > I did the same thing with the postmortem coredump files and got > similar messages. Maybe I am using gdb in a wrong way. You can't control the execution of the kernel, you can just look at the way things are. With the core dump, you at least have the advantage that things won't change while you look at them; you can't even do that with /dev/mem. The other alternative is remote serial debugging, where you *can* influence the execution of the kernel, for example by setting breakpoints. But remember that the kernel is already running when you attach to it, so you don't say 'run', you say 'c[ontinue]'. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Mandatory locking?
I've just found a need for mandatory locking in Vinum, and I'm wondering how to implement it. If I understand things correctly, our fcntl locking doesn't perform mandatory locking, though System V does if you set the file permissions appropriately. Questions: 1. Do we have some form of mandatory locking? If so, what is it? 2. Would it make sense to implement System V's fcntl semantics? They're rather tacky: you set the setgid bit and reset the group exec bit of the file permissions. 3. Alternatively (or additionally), would it make sense to have an additional fcntl function which performs mandatory locking? I think that it's probably a good idea to implement (3), and also to do (2), possibly subject to a sysctl knob. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Sunday, 22 August 1999 at 17:31:44 -0700, Matthew Dillon wrote: > >> Questions: >> >> 1. Do we have some form of mandatory locking? If so, what is it? > > No we don't, unless you count the ad-hoc lockout in the master/slave pty > interface :-). > >> 2. Would it make sense to implement System V's fcntl semantics? >> They're rather tacky: you set the setgid bit and reset the group >> exec bit of the file permissions. > > Ugh. Yuch. No, nothing to do with permission bits, not for something > this convoluted! I don't like it either, but for compatibility reasons it would make sense. That's why I suggested a sysctl knob. >> 3. Alternatively (or additionally), would it make sense to have an >> additional fcntl function which performs mandatory locking? >> >> I think that it's probably a good idea to implement (3), and also to >> do (2), possibly subject to a sysctl knob. > > Well, #3 can't be mandatory if you have to make a fcntl call! Somehow you need to get a lock. > You mean have one program make a fcntl call that causes other > programs to return an error or block if they try to open that > file while the first program holds an open descriptor? Correct. I suppose it's worth discussing what the default should be. Should they get EAGAIN or block? Obviously you'd want a way of specifying which, but there would have to be a default for non-lock-aware programs. I think I'd go for blocking; it's less error prone. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Sunday, 22 August 1999 at 22:07:04 -0400, Garrett Wollman wrote: > < said: > >> Correct. I suppose it's worth discussing what the default should be. >> Should they get EAGAIN or block? Obviously you'd want a way of >> specifying which, but there would have to be a default for >> non-lock-aware programs. I think I'd go for blocking; it's less error >> prone. > > I'd be strongly opposed to any sort of mandatory locking. The whole > notion is unspeakably evil, although this is mitigated somewhat if it > does not apply to processes with appropriate privilege. That's a strange thing to say. Should we do away with locks in the kernel too? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Sunday, 22 August 1999 at 22:04:38 -0700, Matthew Dillon wrote: > >> Somehow you need to get a lock. >> >>> You mean have one program make a fcntl call that causes other >>> programs to return an error or block if they try to open that >>> file while the first program holds an open descriptor? >> >> Correct. I suppose it's worth discussing what the default should be. >> Should they get EAGAIN or block? Obviously you'd want a way of >> specifying which, but there would have to be a default for >> non-lock-aware programs. I think I'd go for blocking; it's less error >> prone. > > I dunno, it sounds pretty icky to me. I would redesign whatever you > are doing that requires mandatory locks to use advisory locks > instead. > > It can be as simple as a wrapper around whatever program your users are > running that is causing whatever the problem is. I'm accessing a file that any program might want to open. Redesigning everything isn't an option. On Monday, 23 August 1999 at 7:29:32 +0200, Poul-Henning Kamp wrote: > In message <19990823122719.g83...@freebie.lemis.com>, Greg Lehey writes: >> On Sunday, 22 August 1999 at 22:52:33 -0400, Garrett Wollman wrote: >>> < said: >>> >>>> That's a strange thing to say. Should we do away with locks in the >>>> kernel too? >>> >>> Of course not. Locks in the kernel are actually necessary. >> >> So what's unspeakably evil about ensuring that user processes don't >> tread on each other's feet? In my specific case, I need to make a >> Vinum volume inaccessible while rebuilding the parity stripes. How >> would you ensure that? A user process is doing the rebuilding. > > Then you give that user-process a magic ioctl to do it with. That sounds like a kludge to me. > Why should it be made unavailable ? So that certain multiple accesses can be done atomically. > I thought the idea of RAID-5 was that this wasn't needed ? No, the idea of RAID-5 is that you can tolerate failures. I'm a little surprised that there's any objection to the concept of mandatory locking. In transaction processing, locking is not optional, and if any process at all can access a file or set of files without locking, you can't guarantee the database integrity. Other OSs have used mandatory locking for decades, and System V has it too. So far I haven't seen any arguments, let alone valid ones, against having it in FreeBSD. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 8:47:34 +0200, Poul-Henning Kamp wrote: > In message <19990823152849.h83...@freebie.lemis.com>, Greg Lehey writes: > >>> Why should it be made unavailable ? >> >> So that certain multiple accesses can be done atomically. > > You don't need that. You initialize a index to 0, and whenever the > sector with that index is written, you increment it. > > At any one time you know that all parityblocks <= your index > are valid. Sure, that's pretty much what I do in the situation you're thinking about. But it won't work without locking. Take a look at vinumrevive.c and vinumrequest.c. My real question was more like "OK, I have a situation coming up in which I need to be able to lock out other processes. What tools are available for it". I don't know yet whether what I end up with can be solved by this method, but it's nice to know what tools you have. You certainly wouldn't want to lock out access to the entire device during this time. >> I'm a little surprised that there's any objection to the concept of >> mandatory locking. > > Too many of us have had wedged systems because of it I guess... Strange, I've probably used it more than anybody here, and I've never had a wedged system. Of course, you need to use it appropriately. 'rm' can be a lethal tool :-) Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 9:47:40 +0200, Poul-Henning Kamp wrote: > In message <19990823162813.i83...@freebie.lemis.com>, Greg Lehey writes: > >>>>> Why should it be made unavailable ? >>>> >>>> So that certain multiple accesses can be done atomically. >>> >>> You don't need that. You initialize a index to 0, and whenever the >>> sector with that index is written, you increment it. >>> >>> At any one time you know that all parityblocks <= your index >>> are valid. >> >> Sure, that's pretty much what I do in the situation you're thinking >> about. But it won't work without locking. Take a look at >> vinumrevive.c and vinumrequest.c. > > I still don't see the need for mandatory locking, or locking out > user access in general... I'll try to explain, using a different example, since I'm not quite sure where my rebuild stuff is going yet. To write a block to a RAID-5 device, you need to: 1. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 5. Write the data block. 6. Write the parity block. Consider what happens if a second request which refers the same parity data comes in during this business: 1. Read the old data into a temporary buffer. 1a. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 2a. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 3a. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 4a. XOR the result with the data which is to be written. 5. Write the data block. 5a. Write the data block. 6. Write the parity block. 6a. Write the parity block. The parity data read at (2a) will be wrong. It won't know of the data block to be written at (6). If the volume becomes degraded, it may no longer know about the first transaction. For this, we don't need fcntl locking: it would be too slow, and it's all done in the kernel anyway. In userland, we'd use a different example: I make a number of financial transactions over the Internet. In each case, the system checks my account balance, transfers the money and deducts it from my account: 1. Check balance. 2. Perform transfer. 3. Write updated balance back. Again, if we have two concurrent transactions, we stand to gain money: the updated balance is likely not to know about the other transaction, and will thus "forget" one of the deductions. Now I suppose you're going to come and say that this is bad programming, and advisory locking would do the job if the software is written right. Correct. You could also use the same argument to say that memory protection isn't necessary, because a correctly written program doesn't overwrite other processes address space. It's the same thing: file protection belongs in the kernel. >>>> I'm a little surprised that there's any objection to the concept of >>>> mandatory locking. >>> >>> Too many of us have had wedged systems because of it I guess... >> >> Strange, I've probably used it more than anybody here, and I've never >> had a wedged system. Of course, you need to use it appropriately. >> 'rm' can be a lethal tool :-) > > Well, maybe you were more lucky, I've had my share of troubles, and > I think the very concept stinks... You and Garrett. I've never heard this from *anybody* else. The general opinion I've heard until now was that the lack of mandatory locking was a significant weakness in BSD. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 15:28:01 -0400, Garance A Drosihn wrote: > At 3:28 PM +0930 8/23/99, Greg Lehey wrote: >> I'm a little surprised that there's any objection to the concept >> of mandatory locking. In transaction processing, locking is not >> optional, and if any process at all can access a file or set of... > > For what it's worth, I also like the idea of mandatory locking. > It's important to think through some of the implementation details, > but I would also like to see some way to specify mandatory locking > in at least some situations. > > I'm not particularly thrilled with the idea of keying it off chmod > bits, though. That seems like a recipe for disaster. Remember where that came from: System V. I don't like it either, but if we're going to do it, we should offer this method (maybe as an option) for compatibility reasons. > Anyway, I am also puzzled as to why there would be much objection to > the option of mandatory locking. My initial systems-programming > experience was on a mainframe OS where mandatory locking was the > NORM, and you had to go out of your way to avoid locking. It seemed > to work quite well in my experience. Ditto in all points. I think that the people who are objecting are seeing potential rather than real problems. Obviously you don't apply mandatory locking to every file, but there are many cases where it makes sense. On Monday, 23 August 1999 at 17:47:46 -0400, Garance A Drosihn wrote: > At 10:12 PM +0200 8/23/99, Mark Murray wrote: >> Folk are all skirting around a very convenient (and necessary) >> loophole; in cases where there _is_ mandatory locking, there >> is always some meta-user which is allowed to violate this. > > If we include non-unix systems in the discussion, this isn't > always true. In the mainframe OS that I used to work on, there was > no meta-user who could just ignore locks set by other processes. > The super-user could find which process had a file locked, and > kill that process (thus removing the lock). Or the super-user > could run a program which modified the in-core locking table > so the file did not appear to be locked. Exactly. The reason why mandatory locking isn't a problem is because it's possible to kill processes holding the locks. It should be possible to find out who these processes are. > However, ordinary programs run by that super user did not have > any magic power to ignore mandatory locks set by some other > process. > > It is true that nobody is running that mainframe OS anymore... :-) They're running similar OSs. Tandem's NSK, for example, has always had mandatory locking. > I'm just saying we COULD (and maybe "should"?) implement this > such that even root has to honor mandatory locks. Root (or some > thing) would have a way to get around or cancel the mandatory > lock, but "standard" programs run by root should not bypass the > mandatory locking. (IMO) I don't think that it should be necessary for root to have this override. The tendency in the last few years has been to lessen root's authority, not increase it. And remember, just because people on this forum haven't had much experience with mandatory locking doesn't mean that others don't: it's been in use for years, and people *don't* have (many) problems with deadlocks. The real issue here is that (mandatory) locking is standard on just about every operating system nowadays. I'd guess that even Microsoft has it. The lack of support on FreeBSD doesn't improve the system. I've done some searching on the web, and came up with a lot of stuff. http://homer.njit.edu:8000/cis332/flock.html and http://miller.cs.wm.edu/lxr3.linux/http/source/Documentation/mandatory.txt seem to be the most interesting. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 23:11:30 -0400, Christopher Masto wrote: > On Mon, Aug 23, 1999 at 10:59:10PM -0400, Chuck Robey wrote: >>> Dunno about that.. if you're using advisory locking, you know to say >>> "lock the file, then read the data, do your calculation, write it out, >>> and unlock". This manditory locking sounds like an invitation for >>> disaster. "I don't need to pay attention to the details because >>> the kernel will take care of it for me." >>> >>> Actually, I don't really understand the paradigm. Two processes need >>> to safely update a file, so one of them aquires a mandatory lock, and >>> the other.. uh.. just blocks trying to open the file? How does it >>> know it's not the first one? >> >> It means that if user A puts data in (and follows locking procedure >> correctly) then he doesn't have to worry that user B might not be >> following correct locking procedure, because user B is mandatorily >> forced to follow the procedure. There isn't any added sloppiness, just >> a guarantee that if one user locks a file, no other rogues can get into >> it while the lock exists. > > Bleah.. I can't count the number of times I've seen idiotic code like: > > open file > read data > close file > open file for write > write data > close file > > Mandatory locking of the type above doesn't force such a thing to > work. I don't see a consistency problem in the code above, it's just inefficient. > Now that I've read the rest of the thread, I see that the meaning may > be that certain files are marked such that they can't be opened > without locking. No, I think you're confusing opening and locking. It's something like this: User 1 User 2 open file open file lock file read file (blocks) diddle file unlock file read completes In fact, fcntl locking is range locking, not file locking, so as long as the two users don't want to access the same part of the file. > That seems extremely dangerous, given all the time that such a thing > hasn't been around.. I've been using it for 22 years now. > who knows how many scripts and programs will now be vulnerable to > hanging forever.. Why? There is a danger, of course, that user 1 will lock the file and not unlock it. That's a badly written program, so you stop it. End of hang. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 23:34:34 -0400, Christopher Masto wrote: > On Tue, Aug 24, 1999 at 12:52:10PM +0930, Greg Lehey wrote: >> No, I think you're confusing opening and locking. It's something like >> this: >> >> User 1 User 2 >> >> open fileopen file >> lock fileread file (blocks) >> diddle file >> unlock file >> read completes > > How about a little timing difference? > > User 1User 2 > > open file > read file > open file > lock file (blocks?) > close file > lock returnsopen file (blocks) > diddle file > unlock file > scribble over User 1's changes That's OK. In my scenario, user 2 can't know about what user 1 is doing. Typically there'll be multiple accesses. Since you mentioned mail, let's look at it, since that's where things really *do* use (advisory) locking. When I save my mail folder, I need to ensure that sendmail doesn't choose that moment to deliver a new message; otherwise it might disappear completely. Mailers and sendmail do have an agreement of some kind. But what if I want to merge the contents of another mail folder: cat oldmail >>/var/mail/grog That works, but it's playing with fire: if sendmail is delivering a message at the same time, it won't see me, and my cat doesn't get a lock beforehand, so both an incoming message and part of my mail folder could end up getting written to the same location. With mandatory locking, it would work, transparently. > What I'm getting at is that if User 2 has to do something special > anyway, it might as well be using advisory locking. What I'm getting at is that User 2 doesn't have to do anything different. >>> who knows how many scripts and programs will now be vulnerable to >>> hanging forever.. >> >> Why? There is a danger, of course, that user 1 will lock the file and >> not unlock it. That's a badly written program, so you stop it. End >> of hang. > > That's not what I meant. It hasn't been on FreeBSD, so FreeBSD is not > designed to deal with it. Obviously. > I mentioned a couple of examples.. if I lock a bunch of files in my > web space, does apache get a bunch of children stuck forever? Only as long as you keep them locked. And yes, you shouldn't go locking files longer than you need them. > Who knows what might get tripped up? Nobody. Do you know where your next SIGSEGV is coming from? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Monday, 23 August 1999 at 23:27:27 -0400, Christopher Masto wrote: > On Mon, Aug 23, 1999 at 11:16:21PM -0400, Chuck Robey wrote: >> On Mon, 23 Aug 1999, Christopher Masto wrote: >> >>> Bleah.. I can't count the number of times I've seen idiotic code like: >>> >>> open file >>> read data >>> close file >>> open file for write >>> write data >>> close file >>> >>> Mandatory locking of the type above doesn't force such a thing to work. >> >> What has that code you show above got to do with mandatory locking? >> You completely missed the explicit locking calls that you have to make, >> to get and release the locks. If you don't make the call, and you have >> madatory locking, then your process will sleep until someone else >> releases the lock; > > Exactly. You said that mandatory locking means that user A's correct > use of locking means that user B doesn't have to be careful. That's > not the case, since A can step in between B's read and write. B doesn't have to be careful about messing up A's transaction, like he doesn't need to be careful not to overwrite A's address space. If he wants his own transactions protected, he needs to do something about that. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Tuesday, 24 August 1999 at 12:38:38 +0300, Ville-Pertti Keinonen wrote:
>
> gurne...@efn.org (John-Mark Gurney) writes:
>
>> Ville-Pertti Keinonen scribbled this message on Aug 24:
>
>>> cat writes part of oldmail to /var/mail/grog
>>> sendmail locks /var/mail/grog
>>> (cat may try to write more to /var/mail/grog but blocks)
>>> sendmail delivers new mail
>>> sendmail unlocks /var/mail/grog
>>> cat writes the rest of oldmail to /var/mail/grog
>>>
>>> You'll still probably end up with a broken mailbox.
>>
>> what you do is this:
>> lockf -k $mailfile cat ${mailtmp} >> $mailfile
>
> Which doesn't support Greg's arguments for mandatory locking, as
> you're now doing locking in both programs.
Well, it doesn't support the last argument I made, which was
untenable. It doesn't affect most of the others. And we're some
distance from the dreaded deadlocks.
Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Locking in Vinum (was: Mandatory locking?)
On Tuesday, 24 August 1999 at 10:59:34 +1000, Andrew Reilly wrote: > Hi Greg, hackers list, > > I don't want to express an opinion about the need or otherwise > for mandatory locking, but I would appreciate a teensy > clarification of the problem domain: > > On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: >> To write a block to a RAID-5 device, you need to: >> >> 1. Read the old data into a temporary buffer. >> 2. Read the old parity data corresponding to the data into a >> temporary buffer. >> 3. XOR the two, storing the result in one of the temporary buffers. >> 4. XOR the result with the data which is to be written. >> 5. Write the data block. >> 6. Write the parity block. > > Are you suggesting that random user processes have to do all of > this every time that they access a vinum drive? Yes. > I thought that access was mediated by a driver or server process. Sure, that's how they do it. It's a driver, not a server, and the top half runs in process context. > Isn't this process in a position to ensure the integrity of the > transaction without any help from locking mechanisms? No. But what we're talking about here has nothing to do with Vinum's locking, which is internal. > If some major maintenance utility needs to run on the raw device, > during which time the state is inconsistent as far as user processes > are concerned, isn't it sufficient to remove their read priveliges? What if the volumes are open? What if you don't want to upset the processes, just keep them away a little while you do your thing? While testing Vinum, I found a number of race conditions. Most lasted about 50 ms. I have to lock to prevent corruption, but nobody would notice the delay. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Locking in Vinum (was: Mandatory locking?)
On Wednesday, 25 August 1999 at 1:52:38 +, Terry Lambert wrote: >>> I don't want to express an opinion about the need or otherwise >>> for mandatory locking, but I would appreciate a teensy >>> clarification of the problem domain: >>> >>> On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: >>>> To write a block to a RAID-5 device, you need to: >>>> >>>> 1. Read the old data into a temporary buffer. >>>> 2. Read the old parity data corresponding to the data into a >>>> temporary buffer. >>>> 3. XOR the two, storing the result in one of the temporary buffers. >>>> 4. XOR the result with the data which is to be written. >>>> 5. Write the data block. >>>> 6. Write the parity block. >>> >>> Are you suggesting that random user processes have to do all of >>> this every time that they access a vinum drive? >> >> Yes. > > This could also be accomplished with a volume access lock at the > CAM level. It could be, but it would introduce unnecessary waits. > I think what people are missing here is that Vinum, when doing > software RAID, is implementing a type of namespace escape, only > it isn't a standard namespace escape. Interesting terminology. I think you've lost most people already. > Because this escapes the whole file, it is _not_ like the Vinum > usage, which needs to escape parity bits on a block device. The > Vinum usage needs to prevent access to the file range covered by the > parity bits, rather than merely protecting the parity bits. Correct. I lock a stripe at a time. > It seems to me that this is a proper application of mandatory > locks. Sure. It also has nothing to do with the userland file locking I was talking about in the previous thread. > For the use proposed by Vinum, however, fcntl() based mandatory > locks are probably not the proper tool. Vinum isn't proposing fcntl-based locks. I was looking at them for a specific application; Vinum has always had its own locking mechanism (see sys/dev/vinum/vinumlock.c). > This is because you can only apply locks to devices that have a > VOP_ADVLOCK on their backing store, and which use the VFSOPS > based fileops structures. > > For the same reason that Linux user lament the inability to > place advisory range locks on special files in FreeBSD, so, too, > would Vinum be unable to place mandatory locks through that > same mechanism against special files in FreeBSD. > > To correct this to allow it to work would require hanging the > locks off of the vnode, instead of hanging them off the backing > object (I have been suggesting -- and providing patches for -- > this for literally years). Can you point me to the patches again? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Tuesday, 24 August 1999 at 22:41:15 -0400, Albert D. Cahalan wrote: > > It is clear to me that BSD won't do this. SysV and Linux have > this feature. Linux runs everywhere that FreeBSD does and has > better features too... so why run BSD at all? I assume you're talking about mandatory locking. Yes, you're right, FreeBSD has no merit, so why bother even reading the mailing lists? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Wednesday, 25 August 1999 at 8:31:23 +0530, Biju Susmer wrote: > All the files under Tandem's NSK has mandatory locking. The file cannot be > opened if another process has it opened. some thing like > > * if the file is opened for reading, any one can open it for > reading but opening for writing gives error > * if the file is open for writing, it can't be opened for > read/write This isn't locking, it's access exclusion. It's also not correct for NSK. NSK's OPEN procedure allows the following possibilities: - shared access. Any process can open the file unless another process has it opened with a different access. - exclusive access. Only this process can open the file. If it's already open, the open call will fail. - protected access. Only this process can have the file open for write. If it's already open for writing, the open call will fail. NSK uses the procedures LOCKFILE and LOCKREC for locking. Like most operating systems, locks are in the kernel and mandatory. > * if the process holding the file is killed, the lock is gone > * it is possible to get the pid of the process(es) which has > a given file open (like which process has file "xyz" open? > kind of query). btw, is there any way to get this info now in FBSD? fstat or lsof. > Also, file need not be explicitly locked. Opening a file puts proper > lock. I'm not sure what you're saying here. Opening a file doesn't lock it. If the file is audited, you must issue a BEGINTRANSACTION call before you can access it, and TMF will place locks where necessary. > A file which is open can't be deleted also ;) That's because of NSK's simplistic file system. > This kind of locking will solve most of the problems which are > pointed out. Mandatory locking on a part of the file is in no way > better than advisory locking. Again, I'm not sure how much of this you understand. I was thinking of doing something like NSK's LOCKREC function. > All the files need not have this option. there must be a way to > specify that "this file needs mandatory locking" to the kernel. That's a point for discussion. > I don't know what all changes are needed in the kernel.. but I'm > thinking about dup() and fork().. What is the fate of the lock if > the process does a fork()? I can think of a number of scenarios. Certainly another point for discussion. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Locking in Vinum (was: Mandatory locking?)
On Tuesday, 24 August 1999 at 22:28:10 -0700, Sean Eric Fagan wrote: > In article <19990825113518.d83273.kithrup.freebsd.cvs-...@freebie.lemis.com> > you write: >> Correct. I lock a stripe at a time. > > What people need to realize is that Greg is doing this locking in user mode. > > As such, he has two real options: > > 1. Implement a vinum-specific ioctl that locks a region of a file at the > device level, or > > 2. Implement standard mandatory region locking, which damned near every > OS in existence has, and which OSes which have existed for decades > longer than unix has existed have always had. > > Now, because this _is_ (currently) a vinum-specific requirement, doing (1) is > not all that unpalatable. However, it's at the wrong level (device driver, > instead of file), and it is merely putting off the inevitable. In fact, this confusion with Vinum is more historical than anything. I started thinking "what tools are available for this as yet not clearly defined task that will run in user mode and require locking?". The obvious first question was "do we support read (i.e. mandatory) locking?". > Or does nobody wish to have working Linux and Solaris/x86 > compatibility after all? > > That reason, if nothing else, is reason to design it, so it gets done > correctly. Exactly, and that was why I started this thread. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Wednesday, 25 August 1999 at 0:11:23 -0600, Wes Peters wrote: > "Daniel C. Sobral" wrote: >> >> Christopher Masto wrote: >>> >>> I don't see the use for it. >> >> :-) >> >> The thing is SO obviously flawed, that I wonder how many marketoid >> drones it took to make sensible people think it is actually useful. >> :-) > > And how many programmers with nearly (or more than) two decades of UNIX > experience it takes to convince someone it really is useful. I must say, I'm really amazed at some of the opinions that have been voiced in this thread. Of course, that's all they are, and they show the origins of their owners. Any system with multiple concurrent accesses requires locking. Only UNIX uses advisory locking. It almost does the job, so nobody has tried to fix things. But that doesn't make it right. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote:
>> All the files under Tandem's NSK has mandatory locking. The file cannot be
>> opened if another process has it opened. some thing like
>>
>> * if the file is opened for reading, any one can open it for
>> reading but opening for writing gives error
>> * if the file is open for writing, it can't be opened for
>> read/write
>> * if the process holding the file is killed, the lock is gone
>> * it is possible to get the pid of the process(es) which has
>> a given file open (like which process has file "xyz" open?
>> kind of query). btw, is there any way to get this info now in FBSD?
>
> This sounds interesting...
>
> But - aren't there NFS issues? I mean, in stateless access to
> a file - how do you know if the process holding the file is killed
> if it's remote?
NSK is a prorietary operating system ("NonStop Kernel", previously
known as Guardian, previously known as TOS), not UNIX. There is no
NFS, and there is no distinction between network access and local
access: all goes over the message system. When a file is closed, its
locks are released.
Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Wednesday, 25 August 1999 at 19:53:22 -0400, Christian Kuhtz wrote:
> On Thu, Aug 26, 1999 at 09:09:33AM +0930, Greg Lehey wrote:
>> On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote:
>>>> All the files under Tandem's NSK has mandatory locking. The file cannot be
>>>> opened if another process has it opened. some thing like
>>>>
>>>> * if the file is opened for reading, any one can open it for
>>>> reading but opening for writing gives error
>>>> * if the file is open for writing, it can't be opened for
>>>> read/write
>>>> * if the process holding the file is killed, the lock is gone
>>>> * it is possible to get the pid of the process(es) which has
>>>> a given file open (like which process has file "xyz" open?
>>>> kind of query). btw, is there any way to get this info now in FBSD?
>>>
>>> This sounds interesting...
>>>
>>> But - aren't there NFS issues? I mean, in stateless access to
>>> a file - how do you know if the process holding the file is killed
>>> if it's remote?
>>
>> NSK is a prorietary operating system ("NonStop Kernel", previously
>> known as Guardian, previously known as TOS), not UNIX. There is no
>> NFS, and there is no distinction between network access and local
>> access: all goes over the message system. When a file is closed, its
>> locks are released.
>
> How does this message system handle releasing stale locks when components
> talking to the message system die unexpectedly? Is there some sort of aging,
> override or timeout mechanism to purge stale locks?
When a process dies unexpectedly, the message system releases all
resources which were allocated to it. This includes, of course,
closing its files. If the process is on the local processor, the
locak processor cleans up. If the local processor dies, the remote
systems are informed and do the cleanup for all resources used by
processes on that processor.
Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Mandatory locking?
On Wednesday, 25 August 1999 at 18:25:31 +, Terry Lambert wrote: >>> And how many programmers with nearly (or more than) two decades of UNIX >>> experience it takes to convince someone it really is useful. > > Har! 8-). > >> I must say, I'm really amazed at some of the opinions that have been >> voiced in this thread. Of course, that's all they are, and they show >> the origins of their owners. > > Har again! 8-). I continue to be amazed. That's why I've been keeping out of this discussion. >> Any system with multiple concurrent accesses requires locking. Only >> UNIX uses advisory locking. It almost does the job, so nobody has >> tried to fix things. But that doesn't make it right. > > UNIX doesn't do this _at all_ well for "hosted OS's". > > The NetWare for UNIX product, which I worked on the attributed FS > (with resource forks and multiple namespaces) and the lock coherency > model on is one example. > > We had to add hooks into the fcntl() call in the FS to support > this. > > Something that might be interesting to look at in this regard is > the latest SAMBA code. > > The latest SAMBA code has an OS OPLOCK (Opportunity Locking) API > that it will utilize, if it is present (currently only on IRIX), > which deals with the lock coherency issues. > > Note that since SAMBA externalizes via SMB an interface that has > to implement NetBIOS calls, and those, in turn, externalize via > the DOS INT 2A/2C mechanisms into the file I/O INTs, that SAMBA > has to support mandatory locking. How does it do this under FreeBSD? Does it implement it internally? > In effect, it is an API which externalizes much of the same types > of operations that implement LEASE operations used by the current > FreeBSD NFS server implementation. > > I don't know if this would be quite sufficient (it's been a while > since I did a lease and order of operation audit on the VFS code, > and written up patches to support Jordan's class project of making > the NFS server locking work), but it should be a healthy start > down the right road, I think. > > Might even fix a couple of NFS bugs as a side benefit... > > Anyway, Sean's also right about needing mandatory file locks for > binary emulation of other platforms (some of which Sean coded for). > > Are file locks sufficient for Vinum, Greg? To repeat myself again: none of this is relevant to Vinum. The original problem I was looking out turned out not to require any other locking method than was already present in Vinum. > The current lock structures in FreeBSD are hung off the backing > inodes (of which specfs has none available that are not themselves > abstract), and the spec_advlock() function returns either EOPNOTSUPP > or EINVAL, based on the arguments its given. > > IMO, unless the lock list is hung off the vnode (I guess you > could hang the mandatory locks there, and leave the advisory > ones alone, but that's kind of a waste, especially if the locking > code can be reused), you aren't going to be able to do range > locks on your stripes. Where are advisory locks kept nowadays? I'll discuss this in a separate message. > Am I not understanding how Vinum's RAID 5 is implemented? Are > you using files for the stripes, or are you laying out the disk > as a true RAID 5 controller would lay it out? I'm laying out the disk in the same manner as a hardware RAID-5 controller would do it. Vinum's downward interface is to the disk driver, not the file system. I'll send a separate (hopefully last) message to try and sum up what I'm doing. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
locking revisited
After all the stuff that has been said on the last locking thread, I think it's better to restate the case than follow up. It's obvious from the messages in the last thread that a number of otherwise clever people have little understanding or knowledge of the concepts of file locking. I'm appending a hastily worked-over version of the section about locking from "Porting UNIX Software". Here's a summary of what I've been trying to say: All systems which do more than one thing at a time need file locking at some time or another. Since it involves cooperation between potentially unrelated processes, it's an obvious kernel function. Any "solution" requiring cooperation between processes isn't really a solution. As a result, I don't consider advisory locking to be real locking: it's just a kludge. FreeBSD is one of the few operating systems which doesn't have kernel-level locking. If we want to emulate other systems correctly, we *must* have advisory locking. This includes SCO UNIX, System V.4 and Linux. I suspect it also includes Microsoft. All this doesn't leave too much room for arguments about whether locking works or not: it works on all platforms except FreeBSD, and that's only because FreeBSD doesn't implement locking. As a result, I argue that we should implement locking. The questions are: how? I'd suggest three methods which can be individually enabled via sysctls: - System V style. We need this for compatibility with System V. The choice of mandatory or advisory locking depends on the file permissions. - Only mandatory locking. fcntl works as before, but locks are always mandatory, not advisory. I'm sure that this won't be popular, at least initially, but if you don't like it, you don't have to use it.y - Via separate calls to fcntl. fcntl currently has the following command values: #defineF_DUPFD 0 /* duplicate file descriptor */ #defineF_GETFD 1 /* get file descriptor flags */ #defineF_SETFD 2 /* set file descriptor flags */ #defineF_GETFL 3 /* get file status flags */ #defineF_SETFL 4 /* set file status flags */ #defineF_GETOWN5 /* get SIGIO/SIGURG proc/pgrp */ #defineF_SETOWN6 /* set SIGIO/SIGURG proc/pgrp */ #defineF_GETLK 7 /* get record locking information */ #defineF_SETLK 8 /* set record locking information */ #defineF_SETLKW9 /* F_SETLK; wait if blocked */ We could add a F_SETMANDLOCK or some such. Any thoughts? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key File locking FFile locking The Seventh Edition did not originally allow programs to coordinate concurrent access to a file. If two users both had a file open for modification at the same time, it was almost impossible to prevent disaster. This is an obvious disadvantage, and all modern versions of UNIX supply some form of file locking. Before we look at the functions that are available, it's a good idea to consider the various kinds of lock. There seem to be two of everything. First, the granularity is of interest: o file locking applies to the whole file. o range locking applies only to a range of byte offsets. This is sometimes misleadingly called record locking. With file locking, no other process can access the file when a lock is applied. With range locking, multiple locks can coexist as long as their ranges don't overlap. Secondly, there are two types of lock: o Advisory locks do not actually prevent access to the file. They work only if every participating process ensures that it locks the file before accessing it. If the file is already locked, the process blocks until it gains the lock. o mandatory locks prevent (block) read and write access to the file, but do not stop it from being removed or renamed. Many editors do just this, so even mandatory locking has its limitations. Finally, there are also two ways in which locks cooperate with each other: o exclusive locks allow no other locks that overlap the range. This is the only was to perform file locking, and it implies that only a single process can access the file at a time. These locks are also called also called write locks. Page 1 File locking o shared locks allow other shared locks to coexist with them. Their main purpose is to prevent an exclusive lock from being applied. In combination with man
Cheap link (was: Are the ethernet drivers time dependent?)
On Saturday, 28 August 1999 at 2:52:12 -0500, Kris Kirby wrote: > Daniel O'Connor wrote: >> >> On 28-Aug-99 Kris Kirby wrote: >>>> RS232? RS485? VERY cheap and the later is at least moderatly resistant to >>>> noise >>> Noise shouldn't be an issue. It's going to be handling "clean" data. By >>> cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like >>> cutting into. I'm going to be bearing the financial end of this project >>> of mine, so I'm going to save where I can. :-) >> >> Well serial ports come free on all new computers ;) > > You're right, I should have clarifed. I'm looking to break 128K. I don't > have any serial ports that I can jumper up to 460 or 230 kbps. > Additionally, 256K is a nice round number :-). So what's wrong with PLIP? Last time I used it, I was getting about 50 kB/s out of it. > I'm not looking to invest in new hardware, and I can save on a bit > of hardware by letting the NIC worry about the link. The NIC also > greatly simplies the system. At worst, I'd need a machine with a > 3C503 and a NE2000. And then I'll probably use dummynet for > bandwidth limiting over the link so it doesn't get flooded. > > I'm going to be building at least three of these units, assuming I get > the technical issues out of the way. So I'm looking at a cheap (hardware > and software) way of getting data in and out of a PC with IP support and > such. It just makes sense in my POV to use a NIC. It's capable of 10 > Mbps and has most of the circuitry for preparing data for transmission > on it. If you will, it's a ready to use data pump. I think the technical issues will be your problem. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: locking revisited
On Saturday, 28 August 1999 at 15:16:28 -0400, Peter Dufault wrote: >> As a result, I argue that we should implement locking. The questions >> are: how? I'd suggest three methods which can be individually enabled >> via sysctls: >> >> - System V style. We need this for compatibility with System V. The >>choice of mandatory or advisory locking depends on the file >>permissions. >> >> - Only mandatory locking. fcntl works as before, but locks are >>always mandatory, not advisory. I'm sure that this won't be >>popular, at least initially, but if you don't like it, you don't >>have to use it.y >> >> - Via separate calls to fcntl. fcntl currently has the following >>command values: >> >> #define F_DUPFD 0 /* duplicate file descriptor */ >> #define F_GETFD 1 /* get file descriptor flags */ >> #define F_SETFD 2 /* set file descriptor flags */ >> #define F_GETFL 3 /* get file status flags */ >> #define F_SETFL 4 /* set file status flags */ >> #define F_GETOWN5 /* get SIGIO/SIGURG proc/pgrp */ >> #defineF_SETOWN 6 /* set SIGIO/SIGURG proc/pgrp */ >> #define F_GETLK 7 /* get record locking >> information */ >> #define F_SETLK 8 /* set record locking >> information */ >> #define F_SETLKW9 /* F_SETLK; wait if blocked */ >> >>We could add a F_SETMANDLOCK or some such. >> >> Any thoughts? > > (I'm following up only on -hackers because I personally hate discussions > in -commit.) I'm copying -commit because that's where we're supposed to discuss these things. I made the mistake of excluding them once before, and the results were painful. > 1. Isn't vinum a device? Yes. > Isn't this file-level locking irrelevant? To Vinum, yes. > Shouldn't all locking for maintenance be done at the device level? Maybe. Depends on what kind of maintenance you're doing. What happens if you want to dd one plex to another? You've missed another message of mine, where I said that this issue has no relevance to Vinum. > 2. I'll bet there are some standards, at least in development. Have you > done a few searches? Sure. The important one was in the attachment: System V has a standard. > I have other opinions, some that I hold strongly, but since they > have to do with lack of definition of boundary conditions then I > won't bring them up until (2.) is answered. Go for it. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RELENG_3 and diskless booting
please followup only in hackers. I've Just cvsuped freebsd RELENG_3 as of this evening (~21:00 mdt) and using a rom built with etherboot 4.1b9 which has worked flawlessly for the last couple of months. Tonight I getting Searching for server... My IP xxx.yyy.zzz.www Server IP aaa.bbb.ccc.ddd, GW IP fff.ggg.hhh.iii Loading /disklessroot/hostname/kernel... FreeBSD-elf Entry = 0xC01178A0 Segment -1, offset , read 0200, loadpoint text size 2 =0x001583fe c010 Segment 2, offset , read 0200, loadpoint 0010 Segment 2, offset , read 00158400, loadpoint 00258200 Write trailing bit data size 3= 0x00018780 00158400 C0259400 Segment 3, offset , read 00158400, loadpoint 00259400 Then the machine reboots previously it did . My IP xxx.yyy.zzz.www Server IP aaa.bbb.ccc.ddd, GW IP fff.ggg.hhh.iii Loading /disklessroot/hostname/kernel... FreeBSD-elf Entry = 0xC0117669 Segment -1, offset , read 0200, loadpoint text size 2 =0x001566c6 c010 Segment 2, offset , read 0200, loadpoint 0010 Segment 2, offset , read 00158400, loadpoint 00258200 Write trailing bit data size 3= 0x00018604 001566c8 c02576c8 Segment 3, offset 00c8, read 00156800, loadpoint 002576c8 then up comes the normal kernel boot messages to console I see a lot of changes have occured, the booting kernel is FreeBSD xx 3.2-STABLE FreeBSD 3.2-STABLE #9: Thu Aug 26 22: 00:55 MDT 1999 r...@:/usr/src/sys/compile/DISKLESS i386 and was cvsuped on Aug 26 around 21:00 MDT -- Email: ska...@worldgate.com Voice: +403 413 1910Fax: +403 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 ---- PGP 2.6.2 Key fingerprint = 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 http://gras-varg.worldgate.com/~skafte/ http://www.worldgate.com/ ---- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
Matthew Dillon writes: > Though, as a side note, it should be noted that if you have DDB > enabled then lowering the secure level is pretty easy to do. If you > have access to the console, of course. It should also be noted that it makes no sense to enable DDB on systems that need to use elevated securelevels. -- Greg Black -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: debugging a proc's kernel stack...
On Monday, 13 September 1999 at 20:00:02 +, greg wrote: > Hi, I want to see where some a deadlock is occurring in the kernel. I've got > a dump with a bunch of processes in the inode or namecache state. > > Can anybody give me a hint about how to find a proc's "kernel stack" - so that > I can find out what these kernel was doing for these processes when it locked > up... > > (see "repeated deadlocks in FS ..." on the smp list for more info about the > problem)... Take a look at the .gdbinits in /usr/src/sys/modules/vinum. There's a little bit of documentation in vinum(4), but not really enough. The functions you might want are (extracted from gdb's "help user"): btp -- Show a backtrace for the process whose pid is specified as a parameter btpa -- Show backtraces for all processes in the system btpp -- Show a backtrace for the process previously selected with 'defproc' btr -- Show a backtrace from the ebp address specified defproc -- Specify a process for btpp and fr commands fr -- Show the frame of the stack of the process previously selected with 'defproc' Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel debugging questions
On Saturday, 21 August 1999 at 15:37:40 +0200, Assar Westerlund wrote: > Zhihui Zhang writes: >> Thanks for your response. I can not think of those points myself. >> However, on page 7 of the book "Panic! Unix system crash dump analysis", >> it says that a debugger named kadb in SunOS can load the real kernel >> during boot and treat the latter like a great, big, user program, stepping >> through its execution, examining and modifying values on the fly. >> >> It seems to me that FreeBSD does not have such a debugger. Maybe ddb can >> do so, but it works with assembly. > > kadb also works with assembly. That being said, I much prefer ddb to > kadb, and of course remote gdb is *much* nicer. [catching up] The nice thing about kadb is that it has a usable macro languge. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: panic() the system from the console (was: Re: kern/13721: There is no way to force system panic from console)
[including -committers for political correctness] On Friday, 17 September 1999 at 11:45:36 +0200, Sheldon Hearn wrote: > On Thu, 16 Sep 1999 13:30:30 MST, Doug wrote: >> Would not the 'panic' option in DDB be enough to handle this, or >> am I missing something? > > He wanted a to be able to panic() a machine from console without being > able to drop to DDB from console. I think this is because he believes > that DDB is a security problem. :-) Well, I'm missing something: the beginning of this thread, so this may not be 100% relevant, but I've just had the situation. So: I believe that panicing the system is also a security problem. But sometimes people have hangs and just want to get a dump. Installing DDB is overkill for this situation; how about a key attribute that panics the system? It would probably make sense to have a sysctl or some such to enable it. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: csup or svn
On Sun, Sep 26, 2010 at 11:34:34PM -0400, jhell wrote: > On 09/26/2010 22:47, Aryeh Friedman wrote: > > I currently use: > > > > csup -h cvsup9.us.freebsd.org /usr/share/examples/cvsup/cvs-supfile > > > > and when I just ran it I got: > > > > Append to CVSROOT-src/access > > Edit CVSROOT-src/access,v > > Segmentation fault (core dumped) > > > > > > (8.1-STABLE #0) > > > > Should I be using SVN instead and if so what is the repo URL I need to use? > > You can safely remove that file and continue to do what you do... or > > Yes you can use SVN ports/devel/subversion-freebsd Or you can use cvsup (it doesn't segfault on that file). -- Greg Lewis Email : gle...@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : gle...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: csup or svn
On Mon, Sep 27, 2010 at 12:13:14AM -0400, Aryeh Friedman wrote: > Isn't that a step backwards? Segfaulting seems like a bigger step backwards to me ;) > On Sun, Sep 26, 2010 at 11:55 PM, Greg Lewis wrote: > > On Sun, Sep 26, 2010 at 11:34:34PM -0400, jhell wrote: > >> On 09/26/2010 22:47, Aryeh Friedman wrote: > >> > I currently use: > >> > > >> > csup -h cvsup9.us.freebsd.org /usr/share/examples/cvsup/cvs-supfile > >> > > >> > and when I just ran it I got: > >> > > >> > ?Append to CVSROOT-src/access > >> > ?Edit CVSROOT-src/access,v > >> > Segmentation fault (core dumped) > >> > > >> > > >> > (8.1-STABLE #0) > >> > > >> > Should I be using SVN instead and if so what is the repo URL I need to > >> > use? > >> > >> You can safely remove that file and continue to do what you do... or > >> > >> Yes you can use SVN ports/devel/subversion-freebsd > > > > Or you can use cvsup (it doesn't segfault on that file). > > > > -- > > Greg Lewis ? ? ? ? ? ? ? ? ? ? ? ? ?Email ? : gle...@eyesbeyond.com > > Eyes Beyond ? ? ? ? ? ? ? ? ? ? ? ? Web ? ? : http://www.eyesbeyond.com > > Information Technology ? ? ? ? ? ? ?FreeBSD : gle...@freebsd.org > > -- Greg Lewis Email : gle...@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : gle...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
On 2008-07-03, Rob Lytle wrote: > > You can get rid of the nag screens by putting "BATCH=yes" into > > /etc/make.conf. (Not that this negates your other points.) > > What the hell does "yes" mean? That all option boxes are checked, or none > at all? I have never seen this explained anywhere. Instead of all this vociferous whining, how about just doing a bit of reading of the documentation? The ports(7) page might be a place to start. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: request for testers - xen support for domU in head
Kip Macy wrote: > Basic Xen support for 32-bit in PAE mode is in CVS. Please see the > wiki for general information: > > http://wiki.freebsd.org/FreeBSD/Xen > > Please be forewarned that I am not claiming that this is > production-ready. There are many known limitations. If you would like > to take it for a test drive and report bugs please give it a spin. > > Thanks, > Kip > Hi Kip, Thanks very much for the effort here. I'm looking forward to trying it out and providing feedback. I'm not really familiar with Xen, but perhaps enough to ask this question: Does this mean that Amazon EC2 will be able to boot FreeBSD instances? Thank you, Greg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Distributed SSH attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Lea wrote: > Hi, > > This is off topic to this list, but I dont want to subscribe to -chat > just to post there... Someone is currently running a distributed SSH > attack against one of my boxes - one attempted login for root every > minute or so for the last 48 hours. They wont get anywhere, since the > box in question has no root password, and doesn't allow root logins via > SSH anyway... > > But I was wondering if there were any security researchers out there > that might be interested in the +-800 IPs I've collected from the > botnet? The resolvable hostnames mostly appear to be in Eastern Europe > and South America - I haven't spotted any that might be 'findable' to > get the botnet software. > > I could switch out the machine for a honeypot in a VM or a jail, by > moving the host to a new IP, and if you can think of a way of allowing > the next login to succeed with any password, then you could try to see > what they delivered... But I don't have a lot of time to help. > > Regards, > -Jeremy > Hi Jeremy, You could set up DenyHosts and contribute to the pool of IPs that are attempting SSH logins on the Net: http://denyhosts.sourceforge.net/faq.html#4_0 It also looks like there's been quite a spike of SSH login activity recently: http://stats.denyhosts.net/stats.html Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKxm4H0sRouByUApARAtnPAKCQuivQdE1s0ZZnUO6qVWA87N8ZKgCgjyYD Tbv+hWI+KoXYsEpt0n4gW5k= =xCz7 -END PGP SIGNATURE- ___ 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: package building failure irritation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 xorquew...@googlemail.com wrote: > 'Lo. > > I've come up against an infuriating problem with ports. I don't even > know what causes it, let alone how to solve it. > > Essentially, to stop already-installed software from polluting port > builds, I build ports in a jail. I put a list of ports in a file and > use a trivial shell script to build them one after the other with: > > cd $port > make clean > make deinstall > make package-recursive > > The jail is set up with: > > /etc/make.conf: > WRKDIRPREFIX= /work > DISTDIR= /distfiles > PACKAGES= /pkg > PORTSDIR= /ports > > With /ports, /distfiles and /pkg being mounted from outside the > jail using nullfs (just because those directories exist on a ZFS > array outside of the jail for performance reasons). > > Before building a set of packages, the jail is wiped clean with > 'pkg_delete -a'. > > The problem is that it seems most ports just outright fail to > produce packages. I log each build and often the last lines of > the log files read something like: > > xchm: [...] > > Note that in most cases, the compilation *will* produce a package but will > fail to produce packages for dependencies, resulting in pkg_add spewing > errors upon install: > > pkg_add: could not find package liblqr-1-0.4.1 ! > pkg_add: could not find package enchant-1.4.2 ! > pkg_add: could not find package libsigc++-2.2.4.2 ! > pkg_add: autoload of dependency '/pkg/All/glibmm-2.22.1,1.tbz' failed! > pkg_add: could not find package libxml++-2.26.1 ! > pkg_add: could not find package libsigc++-2.2.4.2 ! > pkg_add: could not find package libsigc++-2.2.4.2 ! > pkg_add: autoload of dependency '/pkg/All/glibmm-2.22.1,1.tbz' failed! > pkg_add: could not find package libxml++-2.26.1 ! > pkg_add: autoload of dependency '/pkg/All/cairomm-1.8.4.tbz' failed! > pkg_add: could not find package libsigc++-2.2.4.2 ! > pkg_add: could not find package libsigc++-2.2.4.2 ! > pkg_add: autoload of dependency '/pkg/All/glibmm-2.22.1,1.tbz' failed! > pkg_add: could not find package libxml++-2.26.1 ! > pkg_add: could not find package libsigc++-2.2.4.2 ! > pkg_add: could not find package libsigc++-2.2.4.2 ! > pkg_add: autoload of dependency '/pkg/All/glibmm-2.22.1,1.tbz' failed! > > And so on and so on. > > What's the problem here? It surely shouldn't be this hard to use 'make > package'. > > The system is a vanilla install of FreeBSD 8.0 AMD64 with an up-to-date > ports tree as of yesterday. > > xw Hi xw, "make package-recursive" calls "make package-noinstall" for all of the dependent ports. I'm assuming that means that the dependent packages all have to be installed first, so I would change your script like so: cd $port make clean make deinstall make depends# just to be safe make install make package-recursive On the other hand, this is similar to what Tinderbox (http://tinderbox.marcuscom.com/README.html), so perhaps that would be a solution for you, too? Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLiAdO0sRouByUApARAhK0AKCjyH0T/n6lxt7w3fqaQM0dlh1CZQCgitmN 9R3WnYFpesYLW0mlZkVVzy0= =BCbS -END PGP SIGNATURE- ___ 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: package building failure irritation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 xorquew...@googlemail.com wrote: >> cd $port >> make clean >> make deinstall >> make depends # just to be safe >> make install >> make package-recursive > > This apparently didn't solve the problem (same errors). > > I'm stumped. > > xw Can you post a full log file of the process somewhere? The best way to capture it is with the commands: script /tmp/build.log# Starts a new shell # Run your script here and wait until it finishes exit # Saves the log file and # returns to the original shell dos2unix /tmp/build.log # Gets rid of ^M chars Then post /tmp/build.log somewhere for me to review. Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLiE1H0sRouByUApARAv81AJ98rkAnQsfymc/HUpg5c6pt85eLsACfaZh2 SFcLzJAJPZBsIcWhyEqif0g= =USeg -END PGP SIGNATURE- ___ 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: Something rotten in ports (was Re: package building failure irritation)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
xorquew...@googlemail.com wrote:
[...]
> DISTDIR= /var/ports/distfiles
> PACKAGES= /var/ports/packages
> WRKDIRPREFIX= /var/ports/work
> PORTSDIR= /var/ports/tree
>
> jail# vi /etc/profile
> FTP_PASSIVE_MODE=yes
> HTTP_PROXY=10.1.3.3:8080
> export FTP_PASSIVE_MODE
> export HTTP_PROXY
> jail# . /etc/profile
>
> jail# portsnap -p /var/ports/tree fetch extract
> Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found.
> Fetching public key from portsnap2.FreeBSD.org... done.
> Fetching snapshot tag from portsnap2.FreeBSD.org... done.
> Fetching snapshot metadata... done.
> Fetching snapshot generated at Fri Mar 12 00:22:12 UTC 2010:
> d67bd7a10044c70dc705b2c5b05db32b07ab8bd2262c3e 1% of 61 MB 161 kBps
> ...
>
> jail# cd /var/ports/tree/graphics/inkscape
> jail# make config-recursive
> jail# make fetch-recursive
> jail# make package-recursive 2>&1 | tee /tmp/inkscape.log
>
> Of course, at the end of inkscape.log:
>
[...]
> rmdir: /var/ports/work/var/ports/tree/devel/eggdbus/work: Directory not empty
> *** Error code 1 (ignored)
[...]
Hi xw,
I noticed something strange here. How is WRKDIR (in this case
"/var/ports/work/var/ports/tree/devel/eggdbus/work") defined? It looks
like bsd.port.mk combined your WRKDIRPREFIX and PORTSDIR to create that
path, but skimming the code, I can't figure out how it's doing that.
How many levels of that directory tree exist on your system?
If you look at the package-noinstall target in bsd.port.mk, you'll see
the line:
-...@${rmdir} ${WRKDIR}
and I believe that's the one that throws the "Directory not empty" error.
Have you tried just setting PORTSDIR and letting bsd.port.mk set the
rest of the paths with their defaults that are relative to PORTSDIR? If
that works, then we can start hunting for places that are not handling
absolute vs. relative paths correctly in bsd.port.mk.
Hope that helps,
Greg
- --
Greg Larkin
http://www.FreeBSD.org/ - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
http://twitter.com/sourcehosting/ - Follow me, follow you
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLmwhW0sRouByUApARArf3AJ41IkBVHYDmWcDH+JIMSpf15HrvogCgg10O
igt2EmedReaASRFsCyn1a3A=
=EgS8
-END PGP SIGNATURE-
___
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: fsck and large file system
On Wednesday, 12 May 1999 at 15:18:22 -0400, Mark J. Taylor wrote:
> On 12-May-99 Matthew Jacob wrote:
>>
>>
>>>> I was wondering if anyone has done any work on fsck and very large
>>>> file
>>>> systems. We have a system that has 126 GB RAID Array. As you can
>>>> imagine,
>>>> fsck chokes trying to alloc enough blocks to store it's internal
>>>> data
>>>> structures (128 MB RAM, 128 MB Swap)
>>
>> Huh- I remember fixing this for NetBSD. You have to do a setrlimit within
>> fsck so it can malloc enough space and have enough swap to back that. We
>> were fsck'ing 600GB+ filesystems.
>>
>>>
>>>> We would like to treat this array as a single large disk, and was
>>>> wondering
>>>> if anyone else had run into this situation, and had a work around.
>>>
>>
>> I've been doing 120GB+ filesystems for FreeBSD for quite some time. The
>> real fun will be the 1TB filesystems.
>
> The problem that we ran into in a system with several 130 MB RAID5 arrays
> is that the fsck was running out of RAM+swap. We had to add a vnode to swap
> to before the fsck would complete (basically added more swap space).
> We had to have over 100 MB swap space to fsck the 130 MB volume, and the
> system has 64 MB RAM. This was is 2.2.8 (haven't upgraded it yet).
Why can't you just use more swap rather than resort to vnodes?
> BTW: this system is getting VERY poor I/O performance, using the DPT SCSI RAID
> controller and three arrays of four 49 GB Seagate drives. "iozone" reports
> 340,000 bytes/sec write and 9,800,000 bytes/sec read.
That's particularly bad. Which model was it? I've done some
comparisons with Vinum and found that the write performance of Vinum
(RAID-5) was round 25% of read performance, while it was below 10% on
the SmartRAID IV.
You should also try rawio (ftp://ftp.lemis.com/pub/rawio.tar.gz).
iozone and bonnie use block devices, and they measure the total
system, not just the storage device.
> This horrendous write rate makes the system virtually unusable.
> Anyone have any ideas on improving the performance?
Use Vinum :-)
> Would an upgrade from its 2.2.8 to 3.{1,2} help?
It doesn't seem to be a FreeBSD issue.
> It is a Pentium 166. During the "iozone" test, there seems to be
> only a few (less than 10) interrupts from the DPT card per second
> ("systat -vm 1"). Am I losing interrupts (it would seem so)... ?
I think you'd get a message if you lost interrupts. It would be
interesting to correlate the interrupt load with the test you're
doing.
Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
DPT performance (was: fsck and large file system)
On Thursday, 13 May 1999 at 10:02:36 +0100, Andrew Doran wrote: > Chuck Youse wrote: > >> Whoa ... can anyone substantiate that this poor performance is typical >> or atypical of DPT SCSI RAID controllers? > > This is atypical, What's typical? Have you (or anybody else) done any measurements? I'd be very interested to see other results. > however DPT HBAs are *very* touchy about termination and > cabling. For instance, with two identical (old) Seagate Hawks on a > SmartCache III, I get 2MB/s reads from one and 500kB/s from the > other. Have you analysed the reasons for this discrepancy? If you can't get rid of the problem, it's not exactly an advertisement for DPT. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Problems with Ethernet programming
[trimming other mailing lists] On Thursday, 13 May 1999 at 13:32:42 +0400, Pavel V. Antipov wrote: > Hi, > > I encapsulated my data packet into the Ethernet packet, > set the source and destination Ethernet addresses, specified the frame > type (my own). > Now I want to send this packet into the Ethernet network and > recieve it of destination computer. > Please, tell me how can i write/read the Ethernet packet. It's not a "do this" sort of answer. I'd recommend getting a book on network programming; Richard Stevens is particularly good. >for hackers and devel : >Sorry please for my message. I posted it into the question mailing list >but haven't got any help. -hackers is the correct list for this sort of question. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
real time stuff
Even though its for linux, and linux is really a different animal, has anyone who is interested in realtime stuff looked at http://www.rtlinux.org they have a whack of patches against 2.0.36 and 2.2.1. -- Email: ska...@worldgate.com Voice: +780 413 1910Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 ---- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ifconfig: changing mac address
On Friday, 14 May 1999 at 15:43:15 -0400, Mark J. Taylor wrote: > On 14-May-99 Daniel Eischen wrote: >>>> Is it possible to change the mac address of an ethernet card using >>>> ifconfig? >>> >>> Not in any 'standard' card, no. Some cards (in SUN workstations) allow >>> you to swap the EEPROM with the mac address, and I'll bet somewhere >>> someone has designed a card with a programmable mac address, but >>> normally it's not settable. >> >> Yeah, we've got some Dy-4 m68k-based single board computers that >> allow the lower 3 bytes of the MAC address to be programmed. It's >> kind of annoying though, because the lower 3 bytes are always >> set to 0 and we have to uniquely set them for each board that >> we deliver to our customer. >> >> The MAC addresses were meant to be unique; why do you want the >> ability to change them? So you can make M$ viruses without >> anyone figuring it out who made them ;-)? > > One of the purposes of changing the MAC address is for server > redundancy. Yes, and in fact Tandem^H^H^H^H^H^HCompaq use this for their NonStop Ethernet. The machine has two ethernet boards. If one goes down, the other assumes its identity. It seems there's a need, and the possibility. Would somebody like to suggest a syntax? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ifconfig: changing mac address
On Friday, 14 May 1999 at 21:15:33 -0500, Dan Nelson wrote: > In the last episode (May 14), David Scheidt said: >> On Sat, 15 May 1999, Greg Lehey wrote: >> :It seems there's a need, and the possibility. Would somebody like >> :to suggest a syntax? >> >> ifconfig interface ether ab:cd:ef:fe:dc:ab [options] >> >> makes sense to me. > > And the next step would be to make the kernel realize that two cards > ifconfig'd with the same MAC address are meant to be bonded together as > one route (lots of switches support this). I have some machines that > I'd love to be able to get 20MB/sec bandwidth between transparently. I think you need to reconsider that idea. How are you going to double the bandwidth of the wire? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ifconfig: changing mac address
On Friday, 14 May 1999 at 21:41:23 -0500, David Scheidt wrote: > On Sat, 15 May 1999, Greg Lehey wrote: > > :On Friday, 14 May 1999 at 21:15:33 -0500, Dan Nelson wrote: > :> > :> And the next step would be to make the kernel realize that two cards > :> ifconfig'd with the same MAC address are meant to be bonded together as > :> one route (lots of switches support this). I have some machines that > :> I'd love to be able to get 20MB/sec bandwidth between transparently. > : > :I think you need to reconsider that idea. How are you going to double > :the bandwidth of the wire? > : > > I think he means having two interfaces in each box, with the same MAC. So he > has two wires, each with 10Mbs. If you have two different nets, why do you need the same Ethernet address? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ifconfig: changing mac address
On Friday, 14 May 1999 at 21:54:02 -0500, David Scheidt wrote: > On Sat, 15 May 1999, Greg Lehey wrote: > > : > :If you have two different nets, why do you need the same Ethernet > :address? > : > > Transparent redundancy. With them both up on the same MAC address, if one > fails, you have no loss of connection, though you may drop some packets, of > course. Most of the time you get twice the bandwidth. > > David, who doesn't want to think about writing a driver for this. OK, now maybe I'm missing something here. But an Ethernet address is used to identify a board. Arp binds it to an IP address. An IP address is bound to a network. So if you're on a different network, you get a different IP address. Why do you need the same Ethernet address? This is very different from having two boards on the same network, both with the same Ethernet address. As I observed earlier, that does make sense, but it's a hot standby situation. I can't see any point in arranging for both of them to accept or send data. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Debugging
[moved to -hackers] On Sunday, 16 May 1999 at 23:03:11 -0500, Mike Heffner wrote: > > I would like to trace the source of a panic during boot time. How do I compile > the boot loader code in DEBUG mode? I tried defining DEBUG with make, but it > didn't work. What's the _right_ way to compile specific code with debug mode > set. If there's a url for this, please let me know. This is probably a better candidate for -hackers, so I've moved it there. You have a basic problem that you can't take a dump until you have a dump device. If you panic before that, you're limited to ddb or serial gdb. There's some stuff in the online handbook about how to set up serial gdb, and in LINT about how to set up ddb. Note that the flags for the serial device have changed in *some* versions of FreeBSD, so check your LINT file for the correct flags. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Debugging
On Tuesday, 18 May 1999 at 9:00:49 +0200, Sheldon Hearn wrote: > > > On Mon, 17 May 1999 09:58:10 +0100, Doug Rabson wrote: > >> I don't think LINT in current mentions the new debug flag. > > Are you talking about this: > > # The `makeoptions' parameter allows variables to be passed to the > # generated Makefile in the build area. DEBUG happens to be magic. > [...] > #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug > symbols No. Doug's right, it appears. The flags are for the serial ports (sio0, etc). LINT says: # `flags' for serial drivers that support consoles (only for sio now): # 0x10enable console support for this unit. The other console flags # are ignored unless this is set. Enabling console support does # not make the unit the preferred console - boot with -h or set # the 0x20 flag for that. Currently, at most one unit can have # console support; the first one (in config file order) with # this flag set is preferred. Setting this flag for sio0 gives # the old behaviour. # 0x20force this unit to be the console (unless there is another # higher priority console). This replaces the COMCONSOLE option. # 0x40reserve this unit for low level console operations. Do not # access the device in any normal way. In fact, there's also a 0x80, which you need to set (along with 0x10, it appears) to run remote debugging. I'm guessing a bit at this, since I haven't had time to look at the code, but 0x90 works for me. Doug? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Debugging
On Tuesday, 18 May 1999 at 9:17:03 +0200, Sheldon Hearn wrote: > > On Tue, 18 May 1999 16:34:55 +0930, Greg Lehey wrote: >> In fact, there's also a 0x80, which you need to set (along with 0x10, >> it appears) to run remote debugging. I'm guessing a bit at this, >> since I haven't had time to look at the code, but 0x90 works for me. > > This is something new since about 4 months ago, then? I used 0x10 on a > 4.0-CURRENT machine a while back and managed to do remote debugging > successfully (after a little help from you, in fact). :-) On Tuesday, 18 May 1999 at 9:09:34 +0100, Doug Rabson wrote: > On Tue, 18 May 1999, Greg Lehey wrote: > >> In fact, there's also a 0x80, which you need to set (along with 0x10, >> it appears) to run remote debugging. I'm guessing a bit at this, >> since I haven't had time to look at the code, but 0x90 works for me. >> Doug? > > I used to use 0x50 but now 0x80 works fine. I'm not sure why the debug > flag changed from 0x40 to 0x80 but the new systems seems to allow both > serial console and serial debugging at the same time so I'm not > complaining. Kirk committed some stuff a week or two ago. And yes, IIRC it was to allow the same serial port to be used for both purposes. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
PNP Soundcards w/ diskless booting.
I'm using /usr/ports/net/etherboot, to boot diskless workstations. Everything is working quite well. Now some of the stations need sound, and there are an abundancy of pnp soundcards that workfine, but with the network boot I'm immediately in the kernel, no cli to config the PNP. Now if I include the INTRO_USERCONFIG, of course I get the cli but because /boot doesn't exist I can't save the info, and adds un-neccesary complication to machines that doen't need it. Any thoughts... -- Email: ska...@worldgate.com Voice: +780 413 1910Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 ---- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PNP Soundcards w/ diskless booting.
this has got it THANKS Quoting Eivind Eklund (eiv...@freebsd.org) On Subject: Re: PNP Soundcards w/ diskless booting. Date: Fri, May 21, 1999 at 01:35:08AM +0200 > On Thu, May 20, 1999 at 01:21:10PM -0600, Greg Skafte wrote: > > I'm using /usr/ports/net/etherboot, to boot diskless workstations. > > Everything is working quite well. > > > > Now some of the stations need sound, and there are an abundancy of pnp > > soundcards that workfine, but with the network boot I'm immediately in the > > kernel, no cli to config the PNP. > > > > Now if I include the INTRO_USERCONFIG, of course I get the cli but because > > /boot doesn't exist I can't save the info, and adds un-neccesary > > complication > > to machines that doen't need it. > > > > > > Any thoughts... > > If the BIOS supports PnP: Put the PCs in question in working mode. > The switch for non-working mode is usually labelled 'PnP OS', and > setting it to 'YES' will make the BIOS not work, while setting it to > 'NO' will make the BIOS work correctly (and your sound card work > without any mess). > > Don't ask me why they include a crappy labelled do-not-work button - > it is probably a result of lacking clue, as so much else in this > world. > > Eivind. -- Email: ska...@worldgate.com Voice: +780 413 1910Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 ---- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Visiting Hong Kong and China
I'll be in Hong Kong on Sunday, the 31st May, and in Beijing on the 1st June. After that, I'll be traveling round most of China. If anybody is interested in getting together, please contact me, and we'll see what we can do. Make sure to copy me: I've unsubscribed from most mailing lists for the duration. For those who are expecting to see me at USENIX: yes, I'll be there :-) Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Book stores [was: Re: serial ports]
> Both of these appear to be in print currently, so you should be able to > find them (or order them) through any reputbale book shop. Does > Australia have a good on-line bookstore yet? This might be a good > opportunity for some FreeBSD hackers with ecommerce skills and a few > million dollars to invest in stock, or someone who already owns a > bookstore. ;^) The vast majority of the Australian population lives close to one or more of the fine technical book stores, which normally have these titles on their shelves or can get them in a day or two. And, for the odd title that is not available locally, there is always amazon.com which works pretty well for me. -- Greg Black -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
Bill Paul writes: > If you have a real, detailed and accurate bug report to submit, then fine: > let's hear it. But if you just want to make vague and unsubstantiated > complaints, do me a favor and just keep it to yourself. This whole argument strikes me as a good wake up call for all of us. It really is important to make sure that problems with software are reported and that those reports are framed in a useful manner, because that is the only way that software gets improved. I'm sometimes guilty of not bothering to report bugs that I can easily work around, even though I hate it when people who use my software do the same. I'm re-motivated now to make the effort to contribute meaningful reports whenever I find bugs. As an aside, my experience with the xl driver (ever since I added it in to 2.2.7) has been completely positive, so I can't help with fixing any possible problems there. As for Dennis, he's just not worth responding to. He has a bad reputation as a total waste of space with an attitude problem as big as Texas. Just ignore him. -- Greg Black -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
DE driver in RELENG_3 vs RELENG_2_2
I'm running several osicom 2340 quad ethernet cards under RELENG_2_2 with few issues (quad digital 21140). I've setup a testbox 1 hd has RELENG_2_2 a second disk has RELENG_3 (cvsuped yesterday). Under RELENG_3 the nic pauses underload, regardless of which port is being used. Gated is running on the box with ospf and there is mbone traffic on one of the ethernet ports, so multicast does come into play. Any thoughts or comments. As a side note OSICOM has just released a quad intel 82558 card. -- Email: ska...@worldgate.com Voice: +780 413 1910Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 ---- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: DE driver in RELENG_3 vs RELENG_2_2
are these all dec 21x4x cards or not Quoting Doug Ambrisko (ambri...@whistle.com) On Subject: Re: DE driver in RELENG_3 vs RELENG_2_2 Date: Wed, Jun 02, 1999 at 04:39:45PM -0700 > Greg Skafte writes: > | I'm running several osicom 2340 quad ethernet cards under RELENG_2_2 with > | few issues (quad digital 21140). > | > | I've setup a testbox 1 hd has RELENG_2_2 a second disk has RELENG_3 > | (cvsuped yesterday). > | > | Under RELENG_3 the nic pauses underload, regardless of which port is being > | used. > > FYI, I've seen similar problems with other quad ethernet cards. I haven't > been able to track it down yet. > > Doug A. -- Email: ska...@worldgate.com Voice: +780 413 1910Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 ---- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel config script:
Wes Peters writes:
> And, as far as *word processors* go, troff, nroff, and ed pretty
> much suck. Don't get me wrong, I completely agree they are useful
> tools, as borne out by the number of books that have been typeset
> over the years using troff. But a word processor they DO NOT make.
Clearly you have not read that remarkable book "Word Processing
on the UNIX System" by Morris Kreiger (McGraw-Hill, 1985), which
says in the introductory note to the reader: "This is a book for
beginners -- beginners to computers, to word processing, to
UNIX." Although the larger part of the book covers {n,t}roff
and friends, there is of course a significant section on text
editors, where Krieger explains why ed is a far better tool for
real writers than full screen editors such as vi -- and he only
covers ed in the book.
I first came across this wondrous work when consulting for a
client who had asked his previous consultant to "include word
processing" as part of a business system he was setting up.
That consultant felt he had done his job, as recently as 1986,
by providing a SysVr2 Unix box with {n,t}roff and ed, a
dot-matrix printer, and that book. For some reason, that
company was still using typewriters to do their "word
processing" when I came on the scene. I stole the book in case
anybody was tempted to go back to it for guidance, and have
provided them with a solution they find easy to use and which
allows them to be productive.
That's not to say that I think ed and troff are not useful. I
use ed every day, often for substantial documents. I use troff
less often, but certainly every week.
> > One of the machines I run -CURRENT on is a 4
> > year-old Pentium. Other than build times being longer than I would
> > like, I don't have noticable performance issues. The same machine
> > is essentially unable to run NT, and do work at the same time.
>
> But as a word processor, is it really any better than MacWrite on an
> original Mac 128K? Or, to stack the deck a little more, a Mac Plus?
> *I* don't think so. That was a system well suited to word processing,
> except the tiny screen. Nothing since then has advanced the state of
> the art in word processing, only in being able to do other things with
> your word processor.
All my Unix machines are excellent for my word processing
needs. For one thing, any document that I wrote 20 years ago on
a Unix box can be trivially printed today on any other Unix
box. This is not likely to change. And it is not likely to be
true of many other so-called word processing systems.
More importantly, they also serve quite nicely as development
machines for all the software that I write. It seems to me to
be eminently sensible to have computers that can do more than
one thing, and do those things well. Unix on the desktop serves
not only me and my clients but also my wife and my children for
all their needs. And it never crashes and nor do any of the
applications they use. This is a pretty good arrangement.
--
Greg Black --
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.2-stable, panic #12
"David E. Cross" writes: > fd=open(argv[1], O_CREAT, 600); Since this opens the file so that it cannot be written to, not to mention the really weird mode it will get if it's created by that open(), the rest of the thing doesn't deserve to work. Generally speaking, it's a good idea to make sure that test code is at least decent before starting to puzzle over what it does. -- Greg Black -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.2-stable, panic #12
sth...@nethelp.no writes: > > "David E. Cross" writes: > > > > > fd=open(argv[1], O_CREAT, 600); > > > > Since this opens the file so that it cannot be written to, not > > to mention the really weird mode it will get if it's created by > > that open(), the rest of the thing doesn't deserve to work. > > That may be the case, but it shouldn't panic the machine. I did not suggest that it was a likely cause of the panic. I said that it's a fair thing for people who provide test code to at least make it correct so that other people don't have to waste their time on irrelevant issues. Of course, if it is the broken test code that provokes a panic, that should be stated up front as part of the test case. -- Greg Black -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Device drivers (was: looking for a reference manual)
[moved to -hackers; this is more appropriate there] On Tuesday, 15 June 1999 at 20:51:59 +0300, garret.wh...@nokia.com wrote: > > Hi All! > > I'm looking to write device drivers for FreeBSD. To this end, I'm searching > for a Driver-Kernel interface reference manual for FreeBSD (ordinary BSD > should do). (You know, a reference that documents all the low-level library > calls and such.) I have one for SVR4 but I'm having trouble finding one for > BSD. Anyone know of one? There's nothing that corresponds directly to the System V DDI/DKI manual. Some (but unfortunately not all) kernel functions and structures are described in section 9 of the manual. Look at intro(9) for a start. There's also a tutorial at http://www.freebsd.org/tutorials/ddwg/ddwg.html. But you'll find that you'll have to read a lot of other driver code before you get your driver finished. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum performance
On Thursday, 17 June 1999 at 11:03:32 +0300, Pavel Narozhniy wrote: > "David E. Cross" wrote: >> >> I have a drive that is rated at ~16 Meg/second, and indeed it delivers on the >> order of 15+ Meg/second. If I use Vinum to create a concatinated device >> of 2 such units performance drops to 2.5 Meg/sec. This seems like a >> drastic drop in performance. Any ideas what I am doin incorrectly? > > Try to place those drives on two different SCSI controllers. That wouldn't be the problem with a concatenated plex. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum performance
On Thursday, 17 June 1999 at 3:43:10 -0400, David E. Cross wrote: > I have a drive that is rated at ~16 Meg/second, and indeed it delivers on the > order of 15+ Meg/second. If I use Vinum to create a concatinated device > of 2 such units performance drops to 2.5 Meg/sec. This seems like a > drastic drop in performance. Indeed, if you're comparing apples with apples. > Any ideas what I am doin incorrectly? No. You haven't really given any details. Most of the performance testing I have done has been with striped plexes (which offer the potential for better performance), and I've found that in massively concurrent situations the performance is roughly what you would expect (almost n * normal disk performance, where n is the number of disks in the stripe set. I'd expect performance of a concatenated plex to be pretty close to that of the raw disk. How are you measuring performance? I'd recommend rawio (ftp://ftp.lemis.com/pub/rawio.tar.gz). Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum performance
On Thursday, 17 June 1999 at 11:10:08 +0300, Narvi wrote: > > On Thu, 17 Jun 1999, David E. Cross wrote: > >> I have a drive that is rated at ~16 Meg/second, and indeed it delivers on the >> order of 15+ Meg/second. If I use Vinum to create a concatinated device >> of 2 such units performance drops to 2.5 Meg/sec. This seems like a >> drastic drop in performance. Any ideas what I am doin incorrectly? > > Try changing stripe size. How big is it right now? This was a concatenated plex. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum performance
On Thursday, 17 June 1999 at 11:52:43 +0300, Ville-Pertti Keinonen wrote: > > cro...@cs.rpi.edu (David E. Cross) writes: > >> I have a drive that is rated at ~16 Meg/second, and indeed it delivers on the >> order of 15+ Meg/second. If I use Vinum to create a concatinated device >> of 2 such units performance drops to 2.5 Meg/sec. This seems like a >> drastic drop in performance. Any ideas what I am doin incorrectly? > > You've accidentally striped subdisks on the same drive? ;--) > > Like Greg Lehey said, you haven't really provided enough details. He did provide one detail, though; this is a concatenated plex, not a striped one. > The minimum info required would be: > > - Is this read or write performance? That wouldn't be enough. > Many disks are shipped with write caching disabled, and write > performance can be significantly worse than read performance. Not if it works without Vinum. > - Are you testing through the filesystem? (How are you testing?) That's the real qustion. > Maybe you're doing a dd test and accessing /dev/vinum/vol/* rather > than /dev/vinum/rvol/*... That would, in fact, be faster. But we need to know what he's doing, and I suspect you're on the right track. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum performance
On Thursday, 17 June 1999 at 22:36:49 +0300, Narvi wrote: > > On Thu, 17 Jun 1999, Greg Lehey wrote: > >> On Thursday, 17 June 1999 at 11:10:08 +0300, Narvi wrote: >>> >>> On Thu, 17 Jun 1999, David E. Cross wrote: >>> >>>> I have a drive that is rated at ~16 Meg/second, and indeed it delivers on >>>> the >>>> order of 15+ Meg/second. If I use Vinum to create a concatinated device >>>> of 2 such units performance drops to 2.5 Meg/sec. This seems like a >>>> drastic drop in performance. Any ideas what I am doin incorrectly? >>> >>> Try changing stripe size. How big is it right now? >> >> This was a concatenated plex. > > Do we know that for a fact? I see no reason to doubt what he said. > It could be concatenated by striping. No, the organizations are concatenated, striped or RAID-5. One doesn't mean the other. > And no, i am not sure he was using vinum terminology (and he didn't > say plex anywhere). I don't know any other usage of the word "concatenated" in this connection. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum performance
On Thursday, 17 June 1999 at 15:50:10 +0300, Ville-Pertti Keinonen wrote: > > g...@lemis.com (Greg Lehey) writes: > >>> You've accidentally striped subdisks on the same drive? ;--) >>> >>> Like Greg Lehey said, you haven't really provided enough details. >> >> He did provide one detail, though; this is a concatenated plex, not a >> striped one. > > Or he at least *thinks* it's concatenated. ;--) I didn't miss that - > but given numbers that bad, it sounds like there might be some really > silly mistake involved. OK, you're the second person to say that. Let's wait until he comes back with more details. >>> Many disks are shipped with write caching disabled, and write >>> performance can be significantly worse than read performance. >> >> Not if it works without Vinum. > > My thought was that he might be comparing read performance and write > performance (they are often pretty close). But even so, the > difference shouldn't be *that* big. I'm sure there's something wrong here. I'd just like to find out what it is. I don't think it's with Vinum, but I'm prepared to be proven wrong. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Remote serial gdb--status?
I've been away from work for several weeks, and I now find that I can no longer start remote serial gdb. I am using sio0 on the debugged machine side, and sio1 on the debugging machine side. Here are the relevant dmesg outputs: panic (debugged machine): sio0: system console sio0: gdb debugging port ... sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 sio0: type 16550A freebie (debugging machine): sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: interrupting at irq 3 I can communicate fine using cu, and a breakout box shows all modem signals asserte (DCD, DTR, DSR, RTS, CTS). When I go into remote debug on panic, RxD flashes, and when freebie tries to attach to panic, TxD flashes, so I'm obviously addressing the correct ports. I've checked the bit rate and configuration of the ports before going into debug, and they look right (9600 bps, cs8, -istrip, -parenb). I don't know what else to look for. Any ideas? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Beware of UnixWare 7
Those of you who were at Usenix may have picked up a free copy of a UnixWare 7 CD-ROM from SCO. If so, be careful when installing it. I tried installing it on a machine with two other systems installed. It failed to install (looped trying to install drivers it didn't need). When I rebooted, I found that it had overwritten the Master Boot Record (which is silly, since it knew there were two other systems on the disk), and it also rewrote the partition table: it changed the numbers of the partitions. This is particularly difficult for FreeBSD, which has the partition number explicitly in the device name. In my case, FreeBSD was on partition 2, devices /dev/rwd0s2a and /dev/rwd0s2e. It was moved to partition 3, so the device names changed to devices /dev/rwd0s3a and /dev/rwd0s3e. Since I didn't have device nodes for these devices, I was unable to remount the root file system, and I had to use the fixit floppy to rewrite the partition table. Nothing got lost, but it was a real pain. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum performance
[Format recovered--see http://www.lemis.com/email/email-format.html] On Friday, 18 June 1999 at 1:14:20 -0700, Darryl Okahata wrote: > Greg Lehey wrote: > >> On Thursday, 17 June 1999 at 3:43:10 -0400, David E. Cross wrote: >>> I have a drive that is rated at ~16 Meg/second, and indeed it >>> delivers on the order of 15+ Meg/second. If I use Vinum to create >>> a concatinated device of 2 such units performance drops to 2.5 >>> Meg/sec. This seems like a drastic drop in performance. >> >> Indeed, if you're comparing apples with apples. > > Possible marginally-related data point: with the 3.1-RELEASE vinum, > and with striped drives (yes, I know the original user is using > concatenated devices), I saw pretty bad write performance with the > default filesystem frag size. Increasing the frag size (via newfs), > increased performance substantially. That shouldn't have anything to do with it. If you see anything unusual in Vinum performance, please tell me. It's easy to come to incorrect conclusions about the cause of performance problems, and disseminating them doesn't help. Follow the links at http://www.lemis.com/vinum.html for a discussion of Vinum performance. The biggest factor influencing Vinum performance on striped plexes is the stripe size, which should be at least 256 kB. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Beware of UnixWare 7
On Friday, 18 June 1999 at 8:29:10 +0200, Luigi Rizzo wrote: >> Those of you who were at Usenix may have picked up a free copy of a >> UnixWare 7 CD-ROM from SCO. If so, be careful when installing it. I > ... >> When I rebooted, I found that it had overwritten the Master Boot >> Record (which is silly, since it knew there were two other systems on >> the disk), and it also rewrote the partition table: it changed the >> numbers of the partitions. This is particularly difficult for >> FreeBSD, which has the partition number explicitly in the device name. > > which is not much smarter... > >> /dev/rwd0s2e. It was moved to partition 3, so the device names >> changed to devices /dev/rwd0s3a and /dev/rwd0s3e. Since I didn't have >> device nodes for these devices, I was unable to remount the root file >> system, and I had to use the fixit floppy to rewrite the partition >> table. Nothing got lost, but it was a real pain. > > hit a similar problem the other day, i think i managed to fix it > withouth the floppy by mounting again the root partition on /mnt > and there acting appropriately. Nice one. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Beware of UnixWare 7
On Friday, 18 June 1999 at 18:44:50 +0930, Mark Newton wrote: > Greg Lehey wrote: > >> Those of you who were at Usenix may have picked up a free copy of a >> UnixWare 7 CD-ROM from SCO. If so, be careful when installing it. > > SCO has been a real pain in the bum about partition tables for as > long as I can remember. To be fair, this is UnixWare (ex Novell, ex Univel, ex USL), not OpenDeathtrap. I always thought it a little better, but I never tried to share disks with it before. > Don't even try installing it anywhere other than on your normal boot > disk either. I've never had any luck getting SCO OpenServer onto a > secondary disk of any kind. That wouldn't surprise me. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Beware of UnixWare 7
On Friday, 18 June 1999 at 11:29:53 +0200, Soren Schmidt wrote: > It seems Greg Lehey wrote: >> FreeBSD, which has the partition number explicitly in the device name. >> In my case, FreeBSD was on partition 2, devices /dev/rwd0s2a and >> /dev/rwd0s2e. It was moved to partition 3, so the device names >> changed to devices /dev/rwd0s3a and /dev/rwd0s3e. Since I didn't have >> device nodes for these devices, I was unable to remount the root file >> system, and I had to use the fixit floppy to rewrite the partition >> table. Nothing got lost, but it was a real pain. > > Thats the reason why I always use /dev/rwd0a etc, ie without the > slicenumbers in it, that way it will always use the FreeBSD > slice no matter what number is has gotten. Of cause that only > works if you only have one FreeBSD slice, but that is most > normal I guess... Yup, I prefer the "compatibility slice" names too. They're not as fussy as the strict slice names, and they look less System V.4-ish. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
