Re: NFS performance tuning
On Mon, Mar 17, 2003 at 09:02:01PM -0500, John wrote: >This is an open ended email with a question about how > to increase performance of a 4-stable system running in a > high-load environment. The src is current as of: It may be worth chatting to Daniel Ellard, who has some interesting PRs open on FreeBSD NFS server performance. It certainly sounds like you could do some testing/benchmarking for him. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ìå÷òà þííîãî ÷åëîâåêà!!!
Çäðàâñòâóéòå! Ìíå 13 ëåò ó ìåíÿ åñòü ìå÷òà ïîïðîøó âàñ îòêëèêíóòüñÿ åñëè åñòü òàêàÿ âîçìîæíîñòü. http://www.zk.narod.ru Ïðîøó ïðîùåíèÿ, åñëè îòíÿë ó âàñ âðåìÿ... Ñåðãåé To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
some questions about ACL implementation
Hi, robert I am reading the ACL implementation based FreeBSD5.0 release. I have some problems, please help. 1. the 'extattrctl initattr -p / 388 posix1e.acl_access' command: why the size is 388. the 'ufs_extattr_header' size is 12 and the 'acl' is 324, so the sum is 336. 2. what is the relationship of ACL_GROUP_OBJ and ACL_MASK? If I do not set the ACL EA, we can not get the information of 'ACL_MASK'. ACL_MASK represents what? 3. "As part of the ACL is stored in the inode, and the rest in an EA, assemble both into a final ACL product. Right now this is not done very efficiently.", Do you any viewpoint about that? How we can improve the efficiency? 4. about ACL based on UFS2, do the ACLs of an inode store di_extb? Could you introduce the ACLs' management on UFS2? Thank you very much! Best Regards Ouyang Kai _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: debugging a repeating panic (solved)
Just a followup to this, jlemon narrowed down the problem for me to be inet6 related. He wrote, - >I think I narrowed this down to IPv6. In particular, netstat shows: > >fe80::%lo0/64 fe80::1%lo0 Uc lo0 >fe80::1%lo0 link#3UHL lo0 > >with the first line being a cloned entry. The route is garbage >collected after 1 day of inactivity, so that's when the crash happens. > >I'm not sure why it's crashing just yet, but something seems odd on >the machine Sure enough, I took out inet6 from the box and no more panics. Sample dump below. (It was always in the same place) (kgdb) bt full #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 error = 0 #1 0xc016726c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 howto = 256 #2 0xc01676ed in panic (fmt=0xc03109f9 "%s") at /usr/src/sys/kern/kern_shutdown.c:595 fmt = 0xc03109f9 "%s" bootopt = 256 buf = "page fault", '\000' #3 0xc02bf15e in trap_fatal (frame=0xded66e00, eva=1089938309) at /usr/src/sys/i386/i386/trap.c:974 frame = (struct trapframe *) 0xded66e00 eva = 0 code = 16 type = 12 ss = 16 esp = 0 softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl = 0, ssd_p = 1, ssd_xx = 13, ssd_xx1 = 2, ssd_def32 = 1, ssd_gran = 1} #4 0xc02bedb1 in trap_pfault (frame=0xded66e00, usermode=0, eva=1089938309) at /usr/src/sys/i386/i386/trap.c:867 va = 1089937408 vm = (struct vmspace *) 0x0 map = 0xdea2a180 rv = 0 ftype = 1 '\001' p = (struct proc *) 0xded89c60 #5 0xc02be8cb in trap (frame={tf_fs = -566231016, tf_es = -556269552, tf_ds = -556400624, tf_edi = -1020112715, tf_esi = -1023322971, tf_ebp = -556372388, tf_isp = -556372436, tf_ebx = 1089938309, tf_edx = -1023322937, tf_ecx = -1023322939, tf_eax = 28, tf_trapno = 12, tf_err = 0, tf_eip = -1072019560, tf_cs = 8, tf_eflags = 66050, tf_esp = 13568, tf_ss = -1020112720}) at /usr/src/sys/i386/i386/trap.c:466 p = (struct proc *) 0xded89c60 sticks = 15876603469163024560 i = 0 ucode = 0 type = 12 code = 0 eva = 1089938309 #6 0xc01a4798 in ifa_ifwithnet (addr=0xc33250b0) at /usr/src/sys/net/if.c:611 ifp = (struct ifnet *) 0xc035e120 ifa = (struct ifaddr *) 0x6200 ifa_maybe = (struct ifaddr *) 0xc3015e00 af = 2 addr_data = 0xc33250b2 "" cplim = 0x0 #7 0xc01cfa29 in in_pcbladdr (inp=0xdc550680, nam=0xc33250b0, plocal_sin=0xded66e94) at /usr/src/sys/netinet/in_pcb.c:459 fport = 13568 ro = (struct route *) 0x3500 plocal_sin = (struct sockaddr_in **) 0x0 ia = (struct in_ifaddr *) 0x0 sin = (struct sockaddr_in *) 0xc33250b0 #8 0xc01cfb17 in in_pcbconnect (inp=0xdc550680, nam=0xc33250b0, p=0xded89c60) at /usr/src/sys/netinet/in_pcb.c:526 inp = (struct inpcb *) 0xdc550680 ifaddr = (struct sockaddr_in *) 0xdc550680 sin = (struct sockaddr_in *) 0xc33250b0 sa = {sin_len = 176 '°', sin_family = 0 '\000', sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\200ô1Ü"} error = 0 #9 0xc01e3709 in udp_connect (so=0xdc31f480, nam=0xc33250b0, p=0xded89c60) at /usr/src/sys/netinet/udp_usrreq.c:866 p = (struct proc *) 0xded89c60 inp = (struct inpcb *) 0xdc550680 s = 1644167168 error = 0 #10 0xc0186564 in soconnect (so=0xdc31f480, nam=0xc33250b0, p=0xded89c60) at /usr/src/sys/kern/uipc_socket.c:389 so = (struct socket *) 0xdc31f480 nam = (struct sockaddr *) 0x0 p = (struct proc *) 0x0 s = 0 error = 0 ---Type to continue, or q to quit--- #11 0xc0189c28 in connect (p=0xded89c60, uap=0xded66f80) at /usr/src/sys/kern/uipc_syscalls.c:394 uap = (struct connect_args *) 0xded66f80 fp = (struct file *) 0xc3ea9640 so = (struct socket *) 0xdc31f480 sa = (struct sockaddr *) 0xc33250b0 error = 0 s = -600705920 #12 0xc02bf4ad in syscall2 (frame={tf_fs = -1078001617, tf_es = 47, tf_ds = -1078001617, tf_edi = -1077983904, tf_esi = 59, tf_ebp = -1077996464, tf_isp = -556372012, tf_ebx = 673944780, tf_edx = 0, tf_ecx = 0, tf_eax = 98, tf_trapno = 12, tf_err = 2, tf_eip = 673621160, tf_cs = 31, tf_eflags = 659, tf_esp = -1077997132, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175 params = 0xbfbf11b8 "\b" i = 0 callp = (struct sysent *) 0xc031fff0 p = (struct proc *) 0xded89c60 orig_tf_eflags = 659 sticks = 0 error = 0 narg = 3 args = {8, 135103192, 16, 0, 0, 0, 0, 0} have_mplock = 1 code = 98 #13 0xc02ab1db in Xint0x80_syscall () No symbol table info available. #14 0x2827f651 in ?? () No symbol table info available. #15
HP-UX FS mountable?
Does anyone know whether I can mount a HP-UX (10.26) disk under FreeBSD? -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: some questions about ACL implementation
On Tue, Mar 18, 2003 at 08:19:15PM +0800, ouyang kai wrote: > 1. the 'extattrctl initattr -p / 388 posix1e.acl_access' command: why the > size is 388. the 'ufs_extattr_header' size is 12 and the 'acl' is 324, so > the sum is 336. Maybe each some structs isn't packed. I mean when you compile it align size of some structures for ex on pargraph (16 bytes) or something like this. > -- With best wishes Nikolay mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pmap_wired_count() macro?
Hi Gang. Can someone enlighten me as to where I can find the pmap_wired_count() macro? I have tried a quick grep through sys but I am not able to find where it is. I ask this because I was browsing through our mlock() implementation and the 'ifndef pmap_wired_count' and was wondering what it did. I do have an idea what this macro would do, but I just failed to find it in our src tree. Thanks in advance. -- Hiten To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS performance tuning
The tweaks I've been working on are for read performance. Based on what you sent, I don't think read performance is your problem at all (although they might help you anyway, in the long run). So, my advice might be no more useful than line noise, but here goes: 1. You've got a nfsd taking 48% of an athlon 2200? Wow. If you can profile it to get a look at where it's spending the time, that would be incredibly interesting. I've never seen an nfsd do that. 2. You've got 5 network interfaces, and 2 of them are gigabit, but you're only running 8 nfsds. By rule of thumb, I would add more. This doesn't solve your mystery, however, because it's the master that's eating all the CPU. (Why do the gigabit interfaces see an order of magnitude less traffic than the 100Mb/s?) 3. Are you using TCP or UDP? Any kind of flow control on the switch? I'm interested to hear what other people have to say. -Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fgdg
I prefer it that way: 1. run freebsd install partition the disk, using multiplies of heads*sectors as base unit make ...s1 slice of type 6 (and possibly make fairly big ad0s2 of type 5) make ...s3 and install freebsd there (I have seen windows at my place occasionally removing primary partitions placed in chain between C: (...s1) and extended partition) 2. setup windows to ...s1 3. when (if) wanting to run linux fdisk (I use it to add logical drives rather than that of windows), switch bios to normal disk translation before and to LBA after (in most cases one-time operation) Is there any freebsd fdisk capable of dealing with logical drives? Roman Kurakin wrote: Hi, Joerg Micheel wrote: On Mon, Mar 17, 2003 at 12:39:22PM +0300, sergej wrote: mozno li ustanovit% odnovremenno na odin disk: unix i windows, i kak jto sdelat%! I think it would be better if you will ask questions in English. Get yourself a copy of the "Complete FreeBSD" by Greg Lehey, which covers this subject very well. This question also belongs to , not -hackers. In short, the configuration option is there with FreeBSD as delivered, but you need to take care on making the right steps at the right time. Starting off with BSD first is the better way to proceed, adding Windows later. If you setup at first FreeBSD and then add Windows you will lose FreeBSD's boot loader. And you will have to reinstall bootloader. You also could meet other problems. If your set incorrect (from FreeBSD's point of view) geometry for you hard disk and install freebsd 5.0 after Windows 2000, freebsd will "fix" windows partition entry and any reinstalletions or fix procedures of Windows will lead to nothing. Probably some last versions from 4.x branch have the same "features", but the last 4.x version I worked with at home was 4.3. PS. I don't know if this bug was fixed in current versions. I am almost sure that it is not. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
High CPU usage on high-bandwidth long distance connections.
Hello, Scenario: Two hosts: *** Host a: CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2790.96-MHz 686-class CPU) Hyperthreading: 2 logical CPUs real memory = 1073676288 (1048512K bytes) em0: flags=8843 mtu 4470 options=3 media: Ethernet autoselect (1000baseSX ) *** Host b: CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2790.96-MHz 686-class CPU) Hyperthreading: 2 logical CPUs real memory = 536301568 (523732K bytes) bge0: flags=8843 mtu 4470 options=3 media: Ethernet autoselect (1000baseSX ) Both Ethernet cards are PCI-X. Parameters (for both hosts): kern.ipc.maxsockbuf=8388608 net.inet.tcp.rfc1323=1 kern.ipc.nmbclusters="8192" The hosts are connected directly (no LAN equipment inbetween) to high capacity backbone routers (10 Gbit/sec backbone), and are approx 1000 km/625 miles(!) apart. Measuring RTT gives: RTTmax = 20.64 ms. Buffer size needed = 3.69 Mbytes, so I add 25% and set: sysctl net.inet.tcp.sendspace=4836562 sysctl net.inet.tcp.recvspace=4836562 MTU=4470 all the way. OS = FreeBSD 4-STABLE (as of today). Now the problem: The receiver works fine, but on the *sender* I run out if CPU (doesn't matter if host a or host b is sender). Measuring bandwidth with ttcp gives: ttcp-t: buflen=61440, nbuf=30517, align=16384/0, port=5001 tcp ttcp-t: 1874964480 bytes in 22.39 real seconds = 638.82 Mbit/sec +++ ttcp-t: 30517 I/O calls, msec/call = 0.75, calls/sec = 1362.82 ttcp-t: 0.0user 20.8sys 0:22real 93% 16i+382d 326maxrss 0+15pf 9+280csw This is very repeatable (within a few %), and is the same regardless of which direction I use. During that period, the sender shows: 0.0% user, 0.0% nice, 94.6% system, 5.4% interrupt, 0.0% idle I have read about DEVICE_POLLING, but that doesn't seem to be supported on any GigE PCI-X cards?!? Does anybody have an idea on which knob to tune next to be able to fill my (long-distance) GigE link? I am mostly interested in what to do to not eat all my CPU, but also if there are anu other TCP parameters that I haven't thought about. I have configured my kernel for SMP (Xeon CPU with hyperthreading), don't know if that is good or bad in this case? With kind regards, --Borje To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: High CPU usage on high-bandwidth long distance connections.
On Tue, Mar 18, 2003 at 08:51:29PM +0100, Borje Josefsson wrote: [snip scenario] > > The hosts are connected directly (no LAN equipment inbetween) to high > capacity backbone routers (10 Gbit/sec backbone), and are approx 1000 > km/625 miles(!) apart. Measuring RTT gives: > RTTmax = 20.64 ms. Buffer size needed = 3.69 Mbytes, so I add 25% and set: > > sysctl net.inet.tcp.sendspace=4836562 > sysctl net.inet.tcp.recvspace=4836562 > > MTU=4470 all the way. > > OS = FreeBSD 4-STABLE (as of today). > > Now the problem: > > The receiver works fine, but on the *sender* I run out if CPU (doesn't > matter if host a or host b is sender). Measuring bandwidth with ttcp gives: > > ttcp-t: buflen=61440, nbuf=30517, align=16384/0, port=5001 tcp > ttcp-t: 1874964480 bytes in 22.39 real seconds = 638.82 Mbit/sec +++ > ttcp-t: 30517 I/O calls, msec/call = 0.75, calls/sec = 1362.82 > ttcp-t: 0.0user 20.8sys 0:22real 93% 16i+382d 326maxrss 0+15pf 9+280csw > > This is very repeatable (within a few %), and is the same regardless of > which direction I use. > > During that period, the sender shows: > > 0.0% user, 0.0% nice, 94.6% system, 5.4% interrupt, 0.0% idle I had something vaguely similar happen while I was porting the FreeBSD 4.2 networking stack to LynxOS. It turned out the culprit was sbappend(). It does a linear pointer chase down the mbuf chain each time you do a write() or send(). With a high bandwidth-delay product, that chain can get very long. This topic came up on freebsd-net last July, and Luigi Rizzo provided the following URL for a patch to cache the end of the mbuf chain, so sbappend() stays O(1) instead of O(n). http://docs.freebsd.org/cgi/getmsg.cgi?fetch=366972+0+archive/2001/freebsd-net/20010211.freebsd-net The subject of the July thread was 'the incredible shrinking socket', if you want to hunt through the archives. Hope this helps. -- Ed Mooring ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rumour of password aging failure in 4.7/4.8RC
I've received a few reports from teh field that password aging with ssh in 4.7 and 4.8RC is broken. Is there anyone out there that is using passwork expiry and ssh? Who's the expert? The method being used: Define a class called the shellusers class in the /etc/login.conf. Run cap_mkdb on the login.conf file Go into the master.passwd file and expired an account. According to our clients, after the account is expired SSH on 4.7 disallows any logins. It is supposed to allow your connection and then just force you to change your password. On 4.8-RC ssh seems to be totally ignoring the fact that the password is expired. "login" on the other hand acts as expected. Is this the correct procedure? (If not, what IS the correct proceedure? Where is password expiry documented? (man login.conf and man passwd seem the best references so far..). How does PAM come into this? The older version of SSH we have on the 4.4 boxes works with the same password expiration set up without any problems. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HP-UX FS mountable?
Christoph Kukulies wrote: > > Does anyone know whether I can mount a HP-UX (10.26) disk under FreeBSD? FreeBSD does not support the partitioning or FS layout for HP/UX, so you can not mount it locally. You could mount it via NFS (of course). According to the "5.0 way of doing things", you could implement a "GEOM" module that would be able to deal with locating the first block of any FS's on the volume, and from there, deal with it with an FS module. The actual FS layout for HP/UX FS volumes depends on the specific version and FS type, but most of that information is documented in the system header files, if you have them. NetBSD for that particular hardware can mount it. I don't know about NetBSD/i386. So that would also be a place to start. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Sound drivers
Hello, hackers! How are you? I want to write sound driver for FreeBSD (pcm bridge driver) for Envy24 chip and M-Audio Audiophile 2496 sound card. Is here any documentation about pcm architecture? I've looked through sources, but I have still some questions... Lev Serebryakov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ether_input: drop bdg packet
On Thu, Mar 13, 2003 at 01:13:29PM -0500, IAccounts wrote: > I have 5.0 running as a bridge/ipfw firewall configuration, which is > seemingly working very well in an ISP environment. However, there is > something that I don't know if it is an error, or normal. On the console, > I get the following message many times per second: > > ether_input: drop bdg packet > > I am suspecting that this is just a logging issue within part of the > bridge/ipfw code, but I would like some feeback if possible to what > exactly this is for. > > I have looked through bridge.c, ipfw.c, bpf.c, bpf_filter.c and many > others for the answer. There is much reference to DROP in bridge.c, but > nothing that looks like the console message. I would really like to find > out why this is happening, and how to make some changes, so I would > appreciate it if someone could point me in the direction of the code for > this as opposed to or in addition to the answer. The message is in src/sys/net/if_ethersubr.c. However, it was removed in revision 1.34 which is probably why you cannot find it. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rumour of password aging failure in 4.7/4.8RC
Julian Elischer <[EMAIL PROTECTED]> writes: > Ok so we'll have to miss 4.8. Does making it work for PAM allow it to > work for ssh? I don't understand what you mean - PAM already supports password expiry and changing, so it should work for console logins at least (though to be honest I never tested it very thoroughly). The problem with ssh is that password changing is supposed to happen at a later point than authentication, and the way the monitor currently works makes it very awkward to implement. For PAM, I can probably cheat by pretending that password changing is part of the authentication procedure (which it normally isn't in ssh), but it'll only work for ssh2 since the ssh1 challenge-response mechanism doesn't allow multiple challenges. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rumour of password aging failure in 4.7/4.8RC
Julian Elischer <[EMAIL PROTECTED]> writes: > The other thing they are on about is "3 tries and you are out" password > lockouts. /usr/src/contrib/libpam/modules/pam_tally.c is what they want. > We're trying to 'resurect' it and see if it still works with 4.8. > is there a similar file for the new PAM code? No, but I'll probably write one soon as it will allow us to claim that FreeBSD fulfills the CAPP requirements for authentication strength. > Are old and new PAM modules in any way compatible? If we wrote one that > ran on 4.x would we be able to continue to run int (even with a > recompile) when we switch to 5.3? Depends on how carefully you write it. The reverse (that a module written for 5.x will work on 4.x with minimal modifications) is more likely to be true. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rumour of password aging failure in 4.7/4.8RC
[EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: > > How does PAM come into this? > It doesn't, really. It's a privsep problem + the fact that some of > the pertinent code has been disabled and / or left unimplemented > because it wouldn't work with privsep (so turning privsep off won't > help). I just checked the code, and it should actually work if privsep is turned off (which should be reasonably safe - there are no known vulnerabilities in the OpenSSH versions which ship with 4.7 and 4.8, and the recent OpenSSL problem doesn't affect OpenSSH). You may want to give it a try. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Terry Lambert wrote: > > Sergey Babkin wrote: > > # OK, let's suppose that our changes are finally complete, and nobody > > # else has committed any other changes in between > > cvs ci > > Suppose someone has? If you are so out of touch with the net you > need a cache, you are probably going to get a conflict, because It's very likely that the conflict can be cured by a simple "cvs update". > > So pretty much all I want is to make this procedure a bit more > > convenient, able to handle whole subdirectories as opposed > > to separate files. > > That's reasonable, but... you're rcs ci is a killer; it assumes > a local repostory in parallel. I guess you want a "multicvs", > which does checkins remotely or locally? I'm not sure what is a "multicvs", I just want to have some storage for the data before I get to commit it to the real repository. For example, suppose I write some code. Then I run a test on it and find some deficency that needs a non-obvious fix. At this point I want to save the present version somewhere before I start doing the fix, to make sure that I at least won't make things worse, and if I make them worse then I can always return back. After the fix is done and the test runs successfully, the final result can be committed to the central repository. > > As a model consider this: suppose we build a separate copy of the CVS > > binary, called "mycvs" that has the following differences from > > the normal CVS: > > That's actually grosser than the rcs version (IMO)... It's only an example to show an analogy. Though after thinking about it, it looks like a good model to start with and cover under the hood of cvs commands. > > > of verbatim copying of the repository. > > > > > > Incoherent: > > [ ... diagram ... ] > > > Why is it incoherent ? CVS checks that the version obtained by "cvs co" > > and then modified is still the top of the tree. If it's not, > > it will refuse to commit and will request you to do an update. > > I left out the (I thought) obvious part; ket me fix it: > > ,---.-cvsup(1)->,---. > | Main | cvsup(2)->| Cache |<--. > | Repo |[CONFLICT] | Repo | | > `---' `---' | > ^ | | > |cvs co | > cvs ci(2) | cvs ci(1) > [CONFLICT] V | > cvs ci(3) ,---. | > | | Work | | > `---| Copy |---' > `---' > > Order: > cvsup(1) > cvs co > cvs ci(1) > cvs ci(2) [CONFLICT] > [FIX] cvs ci(3) > cvsup(2) [CONFLICT] > > In other words, you can't order commits with conflicts, without > going to the main repo first in call cases. That destroys your > intended disconnected use. When cvs ci(2) finds a conflict, the master repository is left unchanged. So cvsup will never see any conflicts. The real sequence would be cvsup(1) cvs co cvs ci(1) cvs ci(2) [CONFLICT - check-in fails] cvsup(2) cvs update [hopefully update resolves the conflict, or fix it manually] cvs ci(3) > The first time you get a conflict, your MYCVSROOT repository > is blown, and you won't be able to resyncronize it, without > replacing ",v" and "CVS/*" file contents. No. Two repositories in this example are completely independent. Their only connection is by checking in and out the same file manually. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Sergey Babkin wrote: > Terry Lambert wrote: > > > # OK, let's suppose that our changes are finally complete, and nobody > > > # else has committed any other changes in between > > > cvs ci > > > > Suppose someone has? If you are so out of touch with the net you > > need a cache, you are probably going to get a conflict, because > > It's very likely that the conflict can be cured by a simple > "cvs update". How? Your local repository is out of date. You can't update your local repository because it's a cache, and the cache contains some local changes, and any update will bow those changes away, or abort because there's a conflict. This is exactly my "incoherent" picture. Are you saying that you can "cvs update" vs. the main repository the checked out local sources, merge the changes, and do it that way? If you do that, you lose your locally maintained modification history. > > > So pretty much all I want is to make this procedure a bit more > > > convenient, able to handle whole subdirectories as opposed > > > to separate files. > > > > That's reasonable, but... you're rcs ci is a killer; it assumes > > a local repostory in parallel. I guess you want a "multicvs", > > which does checkins remotely or locally? > > I'm not sure what is a "multicvs", I just want to have some > storage for the data before I get to commit it to the real > repository. For example, suppose I write some code. Then I run > a test on it and find some deficency that needs a non-obvious > fix. At this point I want to save the present version somewhere > before I start doing the fix, to make sure that I at least > won't make things worse, and if I make them worse then I can > always return back. After the fix is done and the test > runs successfully, the final result can be committed to the > central repository. You want to save it in a local cache. I get that. The local cache is "a snapshot of the remote repository, which is out of date", right? You don't have access to the remote repository in order to make the local cache "not out of date". So you commit it to the local cache. You find you need a fix, make another change, and then commit *that* to the local cache. Then you want to commit the changes in the local cache to the remote repository. Have I understood you so far? If so: Q1: The original commit comment is some long-winded thing that explains the reason for the change, and the next comment is a terse "fix logic error in hash lookup", and the next comment is a long-winded thing about another new feature. Do you want to maintain the modification history for the intermediate local copies? Q2: If the answer to Q1 is "no", then what the heck happens to the commit comments for the first several commits? Q3: If the answer to Q2 is "glue them all together", then do you maintain a commit per comment, to keep comments like "fix logic error in hash lookup" meaningful, or do you just dump meaningless comments into the main repository later? > > ,---.-cvsup(1)->,---. > > | Main | cvsup(2)->| Cache |<--. > > | Repo |[CONFLICT] | Repo | | > > `---' `---' | > > ^ | | > > |cvs co | > > cvs ci(2) | cvs ci(1) > > [CONFLICT] V | > > cvs ci(3) ,---. | > > | | Work | | > > `---| Copy |---' > > `---' [ ... ] > When cvs ci(2) finds a conflict, the master repository is left > unchanged. So cvsup will never see any conflicts. The real sequence > would be > > cvsup(1) > cvs co > cvs ci(1) > cvs ci(2) [CONFLICT - check-in fails] > cvsup(2) BOOM! YOUR HEAD EXPLODES! cvsup(2) will consider the cache repository HEAD trashed. It will either abort, or it will overwrite your cache contents, and you will lose your local modifications. Either way, you are screwed. You can't make local checkins to the same place CVSup writes to. > > The first time you get a conflict, your MYCVSROOT repository > > is blown, and you won't be able to resyncronize it, without > > replacing ",v" and "CVS/*" file contents. > > No. Two repositories in this example are completely independent. > Their only connection is by checking in and out the same file > manually. That's not there in this diagram. I tried to give you a second diagram, which I labelled "coherent", which had a second, seperate local repository, but you guys rejected it. You can't make local checkins to the same place CVSup writes to; CVS is too stupid, and CVSup is too stupid to handle it. You'd need a "multicvs" -- one that could operate a shadow repository. I still
Re: Sound drivers
Hi, Lev Serebryakov asked: > I want to write sound driver for FreeBSD (pcm bridge driver) ... > Is here any documentation about pcm architecture? I wrote a pcm audio driver and tried to document things somewhat in a largish comment block and some web page doc, you should be able to get the kit and doc from: http://alumni.cse.ucsc.edu/~brucem/geode.html Hope this helps, please let me know if you find something missing or bogus! - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sound drivers
Bruce R. Montague wrote: > > Hi, Lev Serebryakov asked: >> I want to write sound driver for FreeBSD (pcm bridge driver) ... >> Is here any documentation about pcm architecture? > > I wrote a pcm audio driver and tried to document things > somewhat in a largish comment block and some web page > doc, you should be able to get the kit and doc from: > > http://alumni.cse.ucsc.edu/~brucem/geode.html > > Hope this helps, please let me know if you find something > missing or bogus! You can also direct questions at the sound developers via [EMAIL PROTECTED] or here depending on whether you think other people might be interested in the info. Kind Regards - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mixer for /etc/rc
Hi. I want to mixer in /etc/rc (setting sound volume on boot). I add it to /etc/rc, /etc/defaults/rc.conf, etc... Would you review and commit? for CURRENT - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Index: rc === RCS file: /home/ncvs/src/etc/rc,v retrieving revision 1.326 diff -u -r1.326 rc --- rc 23 Dec 2002 07:09:44 - 1.326 +++ rc 19 Mar 2003 04:56:17 - @@ -768,6 +768,12 @@ ;; esac +case ${mixer_enable} in +[Yy][Ee][Ss]) + echo -n ' mixer'; ${mixer_program:-/usr/sbin/mixer} ${mixer_flags} + ;; +esac + case ${sshd_enable} in [Yy][Ee][Ss]) if [ -x ${sshd_program:-/usr/sbin/sshd} ]; then Index: defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.171 diff -u -r1.171 rc.conf --- defaults/rc.conf17 Mar 2003 23:15:53 - 1.171 +++ defaults/rc.conf19 Mar 2003 04:54:22 - @@ -426,6 +426,9 @@ harvest_ethernet="YES" # Entropy device harvests ethernet randomness harvest_p_to_p="YES" # Entropy device harvests point-to-point randomness dmesg_enable="YES" # Save dmesg(8) to /var/run/dmesg.boot +mixer_enable="NO" # setup mixer volume +mixer_program="/usr/sbin/mixer"# Which mixer executable to run (if enabled). +mixer_flags="vol 100" # mixer volume value ## ### Define source_rc_confs, the mechanism used by /etc/rc.* ## - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - for CURRENT which rcng (/etc/rc.d/mixer) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #!/bin/sh # # $FreeBSD$ # # PROVIDE: mixer # KEYWORD: FreeBSD NetBSD . /etc/rc.subr name="mixer" rcvar=`set_rcvar` command="/usr/sbin/${name}" load_rc_config $name run_rc_command "$1" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - for STABLE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Index: etc/rc === RCS file: /home/ncvs/src/etc/rc,v retrieving revision 1.212.2.51 diff -u -r1.212.2.51 rc --- etc/rc 17 Oct 2002 17:25:07 - 1.212.2.51 +++ etc/rc 19 Mar 2003 04:51:34 - @@ -531,6 +531,12 @@ ;; esac +case ${mixer_enable} in +[Yy][Ee][Ss]) + echo -n ' mixer'; ${mixer_program:-/usr/sbin/mixer} ${mixer_flags} + ;; +esac + case ${sshd_enable} in [Yy][Ee][Ss]) if [ -x ${sshd_program:-/usr/sbin/sshd} ]; then Index: etc/defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.53.2.62 diff -u -r1.53.2.62 rc.conf --- etc/defaults/rc.conf12 Feb 2003 03:56:46 - 1.53.2.62 +++ etc/defaults/rc.conf19 Mar 2003 04:52:10 - @@ -378,6 +378,9 @@ update_motd="YES" # update version info in /etc/motd (or NO) start_vinum="NO" # set to YES to start vinum unaligned_print="YES" # print unaligned access warnings on the alpha (or NO). +mixer_enable="NO" # setup mixer volume +mixer_program="/usr/sbin/mixer"# Which mixer executable to run (if enabled). +mixer_flags="vol 100" # mixer volume value ## ### Define source_rc_confs, the mechanism used by /etc/rc.* ## - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mcount() / kernel profiling
Greeting, Could anybody give me some advise about the kernel profiling implementation in FreeBSD. Specifically, I am confused by: 1. Is the asm code in /sys/i386/isa/prof_machdep.c the entry code plugged into each function? and it calls _MCOUNT_DECL(frompc, selfpc) in /sys/libkern/mcount.c, which to my understanding is the implementation doing real profiling? 2. How does __mcount linked by each function? I know GCC has an option -finstrument-functions and one can write __cyg_profile_func_enter() and __cyg_profile_func_exit() procedure. But what mechanism is used for mcount? Thanks a lot - Yaoping R. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rumour of password aging failure in 4.7/4.8RC
Julian Elischer <[EMAIL PROTECTED]> writes: > I've received a few reports from teh field that password aging > with ssh in 4.7 and 4.8RC is broken. Recent versions of OpenSSH do not support prompting the user for a new password. I haven't tested it, but I think users with expired passwords will simply be locked out. > Is there anyone out there that is using passwork expiry > and ssh? Who's the expert? In the FreeBSD community, that would be me. > How does PAM come into this? It doesn't, really. It's a privsep problem + the fact that some of the pertinent code has been disabled and / or left unimplemented because it wouldn't work with privsep (so turning privsep off won't help). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rumour of password aging failure in 4.7/4.8RC
On Tue, 18 Mar 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: > Julian Elischer <[EMAIL PROTECTED]> writes: > > I've received a few reports from teh field that password aging > > with ssh in 4.7 and 4.8RC is broken. > > Recent versions of OpenSSH do not support prompting the user for a new > password. I haven't tested it, but I think users with expired > passwords will simply be locked out. > > > Is there anyone out there that is using passwork expiry > > and ssh? Who's the expert? > > In the FreeBSD community, that would be me. > > > How does PAM come into this? > > It doesn't, really. It's a privsep problem + the fact that some of > the pertinent code has been disabled and / or left unimplemented > because it wouldn't work with privsep (so turning privsep off won't > help). So, the fix would be to go back to an old version of ssh? there are patches in the OpenSSH mailing lists to make this work for AIX. (bug '14' if that helps). I can't work out what they do however. > > DES > -- > Dag-Erling Smørgrav - [EMAIL PROTECTED] > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rumour of password aging failure in 4.7/4.8RC
Julian Elischer <[EMAIL PROTECTED]> writes: > So, the fix would be to go back to an old version of ssh? Yes, but you'd have to go back to a version with known remotely exploitable vulnerabilities. Since this is a problem for you and your customers, I will look into getting password changing to work, at least for PAM authentication, when I import 3.6 (which should be out in a few weeks). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rumour of password aging failure in 4.7/4.8RC
On Tue, 18 Mar 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: > Julian Elischer <[EMAIL PROTECTED]> writes: > > So, the fix would be to go back to an old version of ssh? > > Yes, but you'd have to go back to a version with known remotely > exploitable vulnerabilities. > > Since this is a problem for you and your customers, I will look into > getting password changing to work, at least for PAM authentication, > when I import 3.6 (which should be out in a few weeks). Ok so we'll have to miss 4.8. Does making it work for PAM allow it to work for ssh? That's where they are worried the most. > > DES > -- > Dag-Erling Smørgrav - [EMAIL PROTECTED] THANKS! The banks are all getting paranoid at the though of an organised break-in attempt from "unfriendly" sources and it trickles down to us.. The other thing they are on about is "3 tries and you are out" password lockouts. /usr/src/contrib/libpam/modules/pam_tally.c is what they want. We're trying to 'resurect' it and see if it still works with 4.8. is there a similar file for the new PAM code? (or another way of doing it?) Are old and new PAM modules in any way compatible? If we wrote one that ran on 4.x would we be able to continue to run int (even with a recompile) when we switch to 5.3? > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message