Re: Concurrent access to SMbus
I notice that the /dev/smbX devices are exclusive access. This makes it impossible to run two (or more) programs concurrently that want to talk to SMbus devices (in my case, healthd and lmmon, both of which want to open /dev/smb0 to access the LM78). Is this an SMbus restriction, or an artifact of the smb driver? I did a very quick scan through /sys/dev/smbus/* and nothing jumped out to indicate why it needs to be exclusive access. Transactions on the bus should be locked, ie. only one client talking at a time, but it should probably be feasible to allow more than one opener. The SMBus code is dearly in need of a maintainer. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: APM problems on NEC Versa 2000C
I have an older 486 laptop which is newly running FreeBSD 4.0-RELEASE. When I attempted to enable APM and reboot, I got the following on my screen: --begin screen-- Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x58:0x337 stack pointer = 0x10:0xc334dcdc frame pointer = 0x10:0xc334dce0 code segment= base 0xc00ea00, limit 0x, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags= resume, IOPL = 0 current process = 184 (apm) interrupt mask = none kernel: type 9 trap, code=0 Stopped at 0x337: This is inside the APM BIOS - it's probably a BIOS bug that doesn't affect Windows/DOS. With such an old system, you are probably SOL unless you can track down more details (eg. special hacks for this system and Linux). -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: VM coloring description in NOTES
currently - candidate PQ_HUGECACHE PQ_CACHE1024 PQ_LARGECACHE PQ_CACHE512 PQ_MEDIUMCACHEPQ_CACHE256 PQ_NORMALCACHEPQ_CACHE64 Hmm. At boot time, the BIOS displayes this square box with a lot of grub in it that FreeBSD then proceeds to rediscover. Is there no way to whack the BIOS into submission and have it cough up the cache size? It's probably going to be BIOS-vendor specific *sigh*. Then again, perhaps it would be nice to have an interface to some of the more widely used bioses. I image you could pry all sorts of tuning information about the machine from its clammy little hands. Cache size, cache scheme, memory type. There were earlier comments on FreeBSD taking over the task of the BIOS. Food for thought. :-) Kees Jan = TV is the worst of both worlds. It's not as good at words as radio is because the pictures are a distraction which demand attention, and it's not as good as cinema because the pictures are not nearly as good. Douglas Adams To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Documentation selection in sysinstall
[ Going to -doc where it's pertinent, -hackers where it might find someone who's prepared to do the work, and jkh for any expert commentary he feels like tossing in. And while I've got Jordan's attention -- did the last attempt at re-writing sysinstall generate any specification documents? If nothing else, they'd be useful content for the doc project. ] [ I didn't go through this at Usenix -- not enough time ] The documentation is now being built and made available as FreeBSD packages (one package per combination of document, language, and output format). This means we could do away with the "doc" distribution when installing FreeBSD, and instead allow the user to choose which documentation packages they want to install. In theory, this is a doddle. sysinstall already lets the user choose from packages to install. In practice, I think it's a little more difficult, because: 1. [ I haven't run the code to confirm this, not having a network connection at the moment. ] When you do the "post-install" configure via sysinstall, it wants to grab the INDEX file from somewhere (CDROM, the 'net, or whatever) in order to present you with an up-to-date list of packages to install. The doc package building doesn't work like that. There is no INDEX file for sysinstall to grok. We need to find some other way for sysinstall to get the list of docs, languages, and formats that are supported it. This shouldn't be too hard -- looking in /pub/FreeBSD/doc/packages on the FTP site gives a complete list of what's currently built in terms of languages and output formats, and the filenames are easily parseable. 2. We need to find a UI model that allows the user to efficiently select the language and formats they want to install. I'm thinking of initially presenting a dialog box that looks like this: Documentation is available in the following languages: English Spanish French Japanese Chinese with the list extending as necessary, based on what sysinstall found on the FTP site. After the user has chosen a language, then present them with a list like this: Now choose the documentation you would like to install, and the formats you would like to use. HTML HTMLText PS PDF PDB RTF Split Books Handbook[ ][X] [ ][ ] [ ] [ ] [ ] FAQ [X][X] [ ][ ] [ ] [ ] [ ] Porter's Handbook [ ][ ] [ ][X] [ ] [ ] [ ] [... and so on ...] From my reading of dialog(3) I believe this to be, uh, optimistic at best. I've also glossed over the issue of how sysinstall turns "porters-handbook" in a filename to "Porter's Handbook" on screen. Thinking about it, we will probably need an INDEX.lang file that maps filenames to titles -- we should be able to generate this when we build the packages by grabbing the first title element from a document. The alternative to a display like this would seem to be a fairly horrendous nest of menus and sub-menus that the user would have to navigate through. That's about where I am in my thinking about this so far. Alternative viewpoints, suggestions, offers to do the work, and prototypes are gratefully received. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCI transaction ordering!!!
hi, HP-UX device driver reference manual says, "The side-effects of any write are not guaranteed to happen immediately. Writes are posted; they will complete eventually" to make sure all writes are flushed from the queue, it suggests to perform a read operation. i would like to know if the above behaviour is same across all operating systems, esp if it is the same in FreeBSD case also?? Thanks, mohan Telecom RD , FAC-D, SAS ph:- 5281461 x3078 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
I would like to know more about VFS and VM
I would like to know more about current VFS and VM in FreeBSD kernel. Where I can get more details about that (from begginings). I'm requiring unionfs/nullfs to be working to use in jails. I'm ready to give some time to make changes in implementation to be working. roln ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How many files can I put in one diretory?
On 23-Jun-00 Nicole Harrington. wrote: Yeah.. This is why databases where invented :) Hey I agree... However even if the html was databased.. (working on that now) the custom graphics cannot be. (yet) On Fri, 23 Jun 2000 13:12:48 +0930 (CST), "Daniel O'Connor" [EMAIL PROTECTED] said: Daniel Hmm.. can't you do binary blobs in a DB and change the image Daniel URL's to be cgi requests? I was considering this for a project I developed: web up/download of lots of large files. I was using MySQL and some of the folks on that list recommended not storing large files in the DB: even though the disk consumption is the same, if it's in a DB you can't spread it across partitions as space requirements grow. So I store the file path in the DB and the actual file on the UNIX filesystem. To reduce search time I use a two-level directory hierarchy, each of which has 256 subdirectories. To distribute files evenly, I store the file under a name which is the MD5 hash of the filename, time, etc, etc. This gives me a 32-char name of [0-9a-f]. So if file foo.tar.gz hashes to name cafebabedeadbeef0123456789abcdef it is stored under /filestore/ca/fe/cafebabedeadbeef0123456789abcdef This gives me 256 * 256 = 65536 directories. My requirement was to store at least 10 Million files, and this works out to about 150 files per directory -- easy for UNIX to get to quickly. It's been working very well for me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I would like to know more about VFS and VM
On Mon, 26 Jun 2000, Rolandas Naujikas wrote: I would like to know more about current VFS and VM in FreeBSD kernel. Where I can get more details about that (from begginings). A back issue of DaemonNews's 'Blueprints' column has an excellent article explaining the VM system. http://www.daemonnews.org/ I'm requiring unionfs/nullfs to be working to use in jails. I'm ready to give some time to make changes in implementation to be working. If you're starting from nothing you have a lot to learn. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: struct proc
On Monday, June 26, 2000, Fox Anderson wrote:
Hi all!
What is the difference between p and curproc in my syscall?
static int
my_syscall(struct proc *p, my_syscallargs *uap) {
curproc-..
}
p is the process that made the syscall, curproc is the current
running process. You should be using p for the process that
called my_syscall.
--
|Chris Costello [EMAIL PROTECTED]
|It wasn't as easy to get programs right as we had thought. - Wilkes, 1949
`--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Documentation selection in sysinstall
And while I've got Jordan's attention -- did the last attempt at re-writing sysinstall generate any specification documents? If nothing else, they'd be useful content for the doc project. ] No, this is one of the items on my TODO list which I really really really have to get to soon or we'll never get Son Of Sysinstall finished. In theory, this is a doddle. sysinstall already lets the user choose from packages to install. In practice, I think it's a little more difficult, because: I'm still wondering why the docs bits can't be, at a minimum, "front-ended" by the ports collection in a new doc category? I can understand why you'd want to keep them in their own CVS repository section (doc/), but it would be cool if you could use ports to build and install (or make packages out of) the various documentation sets, especially now that there's talk of breaking up the handbook. Once that happened, you'd automagically appear in the INDEX and under your own category. No work would need to be done to sysinstall. My life would be easier. :) 2. We need to find a UI model that allows the user to efficiently select the language and formats they want to install. This wouldn't be quite so elegant, but perhaps Satoshi also wouldn't object to giving you more than one category under ports, just as the German, Japanese, Korean, etc. ports have done. It's either that or accelerate his efforts to go to a multi-layered ports collection so you could have sub-categories. That would lead to menu items like doc-english, doc-vietnamese, doc-french, etc. I'm thinking of initially presenting a dialog box that looks like this: I'm certain that once you start writing code for libdialog, my suggestions above will start sounding a lot less icky than they probably do to you right now. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM coloring description in NOTES
[This message has also been posted.] On Mon, 26 Jun 2000 10:42:35 +0100, Koster, K.J. [EMAIL PROTECTED] wrote: currently - candidate PQ_HUGECACHE PQ_CACHE1024 PQ_LARGECACHE PQ_CACHE512 PQ_MEDIUMCACHEPQ_CACHE256 PQ_NORMALCACHEPQ_CACHE64 Hmm. At boot time, the BIOS displayes this square box with a lot of grub in it that FreeBSD then proceeds to rediscover. Is there no way to whack the BIOS into submission and have it cough up the cache size? It's probably going to be BIOS-vendor specific *sigh*. Then again, perhaps it would be nice to have an interface to some of the more widely used bioses. I image you could pry all sorts of tuning information about the machine from its clammy little hands. Cache size, cache scheme, memory type. For Intel processors, CPUID instruction spits out both L1 and L2 cache sizes. Perhaps, these things should be made a runtime option than a compile time option ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM coloring description in NOTES
Just curious because I have no experience in this area... but what exactly does cache coloring get us... I've never actually gotten a really straight answer on this... Thanks = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Mon, 26 Jun 2000, Arun Sharma wrote: [This message has also been posted.] On Mon, 26 Jun 2000 10:42:35 +0100, Koster, K.J. [EMAIL PROTECTED] wrote: currently - candidate PQ_HUGECACHE PQ_CACHE1024 PQ_LARGECACHE PQ_CACHE512 PQ_MEDIUMCACHEPQ_CACHE256 PQ_NORMALCACHEPQ_CACHE64 Hmm. At boot time, the BIOS displayes this square box with a lot of grub in it that FreeBSD then proceeds to rediscover. Is there no way to whack the BIOS into submission and have it cough up the cache size? It's probably going to be BIOS-vendor specific *sigh*. Then again, perhaps it would be nice to have an interface to some of the more widely used bioses. I image you could pry all sorts of tuning information about the machine from its clammy little hands. Cache size, cache scheme, memory type. For Intel processors, CPUID instruction spits out both L1 and L2 cache sizes. Perhaps, these things should be made a runtime option than a compile time option ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM coloring description in NOTES
On Mon, Jun 26, 2000 at 12:50:41PM -0400, Kenneth Wayne Culver wrote: Just curious because I have no experience in this area... but what exactly does cache coloring get us... I've never actually gotten a really straight answer on this... Thanks Read Curt Schimmel's book UNIX systems for modern architectures for an answer. Basically, it ensures that if P1 and P2 are two pages that are allocated successively (temporal locality), then the first cache line in P1 and the first cache line in P2 do not compete with each other for the L2 cache. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI transaction ordering!!!
In message [EMAIL PROTECTED] Mohana Krishna Penumetcha writes: : HP-UX device driver reference manual says, : "The side-effects of any write are not guaranteed to happen : immediately. Writes are posted; they will complete eventually" : to make sure all writes are flushed from the queue, it suggests to perform : a read operation. : : i would like to know if the above behaviour is same across all operating : systems, esp if it is the same in FreeBSD case also?? I think so. This is a hardware bridge issue. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM coloring description in NOTES
Alright, well that makes sense.. I guess it speeds things up some too? (I had it enabled for a while, but didn't notice a difference). = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Mon, 26 Jun 2000, Arun Sharma wrote: On Mon, Jun 26, 2000 at 12:50:41PM -0400, Kenneth Wayne Culver wrote: Just curious because I have no experience in this area... but what exactly does cache coloring get us... I've never actually gotten a really straight answer on this... Thanks Read Curt Schimmel's book UNIX systems for modern architectures for an answer. Basically, it ensures that if P1 and P2 are two pages that are allocated successively (temporal locality), then the first cache line in P1 and the first cache line in P2 do not compete with each other for the L2 cache. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
strange symlink behaviour if / terminated
preliminaries : # mkdir -p /path/name /path/to # touch /path/name/file # ln -s /path/name /path/to/symlink # mv /path/to/symlink/ /other/location ^ note the terminating slash. move the target of the symlink instead of the symlink itself. same results w/ rm -r and cp -r. slightly different results w/ rm and cp. # rm /path/to/symlink/ rm: /path/to/symlink/: is a directory # cp /path/to/symlink/ /other/location cp: /path/to/symlink/ is a directory (not copied). # rmdir -p /path/to/symlink/ remove the symlink itself instead of do nothing, such as in : # rmdir -p /path/to/symlink rmdir: /path/to/symlink: Not a directory also, strange output from rmdir -p : # mkdir -p /path/name # rmdir -p /path/name rmdir: : No such file or directory # mkdir -p /path/name/ # rmdir -p /path/name/ rmdir: /path/name: No such file or directory I don't have done these tests under some other OSes (HP-UX, Solaris, IRIX) yet, but I'm sure that they do nothing or they work on symlink itself instead of the target. Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange symlink behaviour if / terminated
In message [EMAIL PROTECTED] Cyrille Lefevre writes: : # mv /path/to/symlink/ /other/location : ^ note the terminating slash. Read the terminating slash as "/." and it all should make sense. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI transaction ordering!!!
On Mon, 26 Jun 2000, Mohana Krishna Penumetcha wrote: hi, HP-UX device driver reference manual says, "The side-effects of any write are not guaranteed to happen immediately. Writes are posted; they will complete eventually" to make sure all writes are flushed from the queue, it suggests to perform a read operation. i would like to know if the above behaviour is same across all operating systems, esp if it is the same in FreeBSD case also?? It does not depend on the O/S. It is a PCI optimization that addresses bridges (PCI-host bridges and PCI-PCI bridges) and performing a read transaction (useful or dummy) is the way required by PCI specifications to flush posted transactions. Some bridges may also elect to flush posted transactions on some event like when IRQ is raised, but this is broken approach due to the fact that IRQ lines can be shared by several PCI devices and have no dependency with lines used for transactions (INTR lines look like side-band signals on PCI). On PCI, only PCI transactions (except interrupt acknowledge) can act as synchronisation events and read transactions (useful or dummy) have to be used when the software or the PCI device requires posted writes to be flushed. If you are interested in PCI, I suggest you to read the PCI specifications. May-be, you will have to read them several times prior to having a reasonnable understanding of them. :-) If this happens, you should not have to worry, since it seems to me that they have been often not well understood even by hardware designers and architects. ;-) (I may be disagreed here) As a result of this misunderstanding probably, some real hardwares are not full PCI compliant (or not enough PCI-friendly :-)). For example regarding flushing of posted transactions: PCI specifications require the following when a read is attempted through a bridge (I intentionnaly donnot speak about delayed transactions for simplicity): 1) Flush posted writes to the destination BUS 2) Perform the read to the device (on the destination BUS). 3) Flush posted writes to the originating BUS. (at least those attempted prior to the read having been accepted by the device targetted by the read) 4) Complete the read at the originating device (on the originating BUS). On some systems, as Alpha for example, (3) is not required to be performed. As a result, if the device does not flush posted transactions prior to telling the software driver about events (as completions), stale data can be read from memory by the software driver. When (3) is performed, the device is only required to move data to memory and set some flag in some proper order and the flushing of posted transactions that ensures no stale data will be read can be achieved from the software driver (no flushing is needed from the device). By the way, the documentations I have read about bridges and architectures let me under the impression that numerous PCI device drivers (not only on BSD systems) are broken (in race) regarding transaction posting issues. In my opinion, a PCI device driver that just don't care about posted transactions has every chance to be broken, at least on some architecture or using some bridge. Using legacy IO method rather than MMIO does not make it more safe, since host bridges are also allowed to post IO writes. Speaking about Intel hardware and architecture: - IA32 does not reorder STOREs when they are carried out to the system BUS, neither it allows LOADs to pass STOREs. - Intel host bridges are, at least on paper, PCI compliant regarding ordering rules and donnot post IO write transactions. Such strong ordering situation allows PCI devices and drivers designed with ISA in mind to work reasonnably, but if you move such a device and/or driver to MMIO world with posted writes or to systems that follow ordering rules weaker than PCI requirements, races will likely appear. Gérard. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: struct proc
In article [EMAIL PROTECTED],
Chris Costello [EMAIL PROTECTED] wrote:
On Monday, June 26, 2000, Fox Anderson wrote:
What is the difference between p and curproc in my syscall?
static int
my_syscall(struct proc *p, my_syscallargs *uap) {
curproc-..
}
p is the process that made the syscall, curproc is the current
running process. You should be using p for the process that
called my_syscall.
Since only one process can enter the kernel at a time (currently),
and p is the process that made the system call, it is also the
current process. I claim that (p == curproc) in this example, and
that it would be better to code with p than with curproc.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: struct proc
:p is the process that made the syscall, curproc is the current : running process. You should be using p for the process that : called my_syscall. : :Since only one process can enter the kernel at a time (currently), :and p is the process that made the system call, it is also the :current process. I claim that (p == curproc) in this example, and :that it would be better to code with p than with curproc. : :John : John Polstra [EMAIL PROTECTED] :... Even in an MP system, curproc is not going to be ripped out from under a syscall. p will always be curproc. (curproc in an MP system is a per-cpu variable). This whole p vs curproc thing is a huge mess. 95% of the time p == curproc. The only places where it might not is in I/O ops that are completed by an interrupt or (in the case of NFS) some other process. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs update failed
John Polstra wrote: In article [EMAIL PROTECTED], Cyrille Lefevre [EMAIL PROTECTED] wrote: the problem I have, is that, when I run "cvs -t update -r RELENG_4", I got the following message (last 4 lines) : [...] cvs update: notice: main loop with [EMAIL PROTECTED]:/cvsroot - Starting server: rsh anoncvs.netbsd.org -l anoncvs cvs server anoncvs.netbsd.org: Connection refused cvs [update aborted]: end of file from server (consult above messages if any) what's happen ? Either your CVSROOT environment variable is set incorrectly, or you have a "CVS/Root" file somewhere in your tree that contains the wrong value. The value listed is for NetBSD, and the NetBSD server doesn't even like it. Thanks, that's a CVS/Root from adrian's fsck/fsck_ffs which was imported from the NetBSD source tree. I get rid of thoses CVS trees until there are incorporated w/in the FreeBSD source tree. Cyrille. -- home: mailto:[EMAIL PROTECTED] work: mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: struct proc
On Mon, 26 Jun 2000, Matthew Dillon wrote: This whole p vs curproc thing is a huge mess. 95% of the time p == curproc. The only places where it might not is in I/O ops that are completed by an interrupt or (in the case of NFS) some other process. Any chances to clean this up ? Eg., change the policy to either pass p as parameter or use curproc, but not both. As example of curproc/p mess I can point to VFS_ROOT() call which misses p parameter, but obviously needs it. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs update failed
On Tue, Jun 27, 2000, Cyrille Lefevre wrote: John Polstra wrote: In article [EMAIL PROTECTED], Cyrille Lefevre [EMAIL PROTECTED] wrote: the problem I have, is that, when I run "cvs -t update -r RELENG_4", I got the following message (last 4 lines) : [...] cvs update: notice: main loop with [EMAIL PROTECTED]:/cvsroot - Starting server: rsh anoncvs.netbsd.org -l anoncvs cvs server anoncvs.netbsd.org: Connection refused cvs [update aborted]: end of file from server (consult above messages if any) what's happen ? Either your CVSROOT environment variable is set incorrectly, or you have a "CVS/Root" file somewhere in your tree that contains the wrong value. The value listed is for NetBSD, and the NetBSD server doesn't even like it. Thanks, that's a CVS/Root from adrian's fsck/fsck_ffs which was imported from the NetBSD source tree. I get rid of thoses CVS trees until there are incorporated w/in the FreeBSD source tree. No, the fsck wrappers came straight from NetBSD. FreeBSD's fsck was turned into fsck_ffs, and fsck comes from NetBSD. I've kept the CVS/Root entries intact for both, so people can generate a diff from the origin source trees. Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the [EMAIL PROTECTED]rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
