Re: A smarter mergemaster
Daniel O'Connor wrote: This work does look neat, but.. Try etcmerge :) It's a bit of a pain to get started with it, but it is a *lot* faster (human input wise) than mergemaster. It only asks you about files that you have modified rather than ones that have been changed by committers (ie does a 3 way merge). It does have problems handling DB files, but that is usually not a big problem to fix. I read about etcmerge in BSD Hacks and there's been no going back for me. It seems pretty stable even though it's not been updated for a good while. Is there any chance it will ever make it into the FreeBSD core system? Ashley ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-5.4-stable panics
Hi Robert,
I don't think your patch is correct, the total linked list can be broken
while the lock is released, thus just passing the link may not be enough
I have submitted a PR[1] for this a month ago but nobody took care of it yet
Regards,
Antoine Pelisse
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
On 9/29/05, Robert Watson <[EMAIL PROTECTED]> wrote:
>
> On Thu, 29 Sep 2005, Rob Watt wrote:
>
> > On Thu, 29 Sep 2005, Robert Watson wrote:
> >
> >> Could you dump the contents of *td and *td->td_proc for me? I'm quite
> >> interested to know what the value in td->td_proc->p_state is, among
> other
> >> things. If I could also have you generate a dump of the KSE group
> >> structures in td->td_proc->p_ksegrps and the threads in
> >> td->td_proc->p_threads.
> >
> > I've attached a file with many of the values you have asked for. We
> > looked at some of the threads referenced by td->td_proc->p_threads, but
> > we weren't sure we were walking the list correctly. Do you have any tips
>
> > for walking those thread lists?
> >
> >> Could you tell me if the program named by p->p_comm is linked against a
> >> threading library? If it's a custom app, you may already know, and if
> >> not, you can run ldd on the application to see what it is linked
> >> against.
> >
> > The programs named by p->p_comm is linked against the pthreads library.
>
> This seems to be enough information to at least track this down a bit:
> td_ksegrp is NULL, rather than a corrupt value, which suggests that the
> thread is incompletely initialized. Other hints that this are the case
> are that td_critnest is 1 (as is set when it is allocated), and the state
> is TDS_INACTIVE. Some other fields are set though, such as td_oncpu,
> which is normally initialized to NOCPU.
>
> > (kgdb) p *td
> > $1 = {td_proc = 0xff004aa9f000, td_ksegrp = 0x0, td_plist =
> > {tqe_next = 0xff 00b4798000,
> > tqe_prev = 0xff00a97ae010}, td_kglist = {tqe_next =
> > 0xff00b4798000,
> > tqe_prev = 0xff00a97ae020}, td_slpq = {tqe_next = 0x0, tqe_prev
> > = 0x ff001fac7c10}, td_lockq = {
> > tqe_next = 0xff00a97ae000, tqe_prev = 0xb6797a70},
> > td_runq = {tq e_next = 0x0,
> > tqe_prev = 0x80608180}, td_selq = {tqh_first = 0x0, tqh_last
> > = 0xfff fff00633112c0},
> > td_sleepqueue = 0xff00382b0400, td_turnstile = 0xff00c1712900,
> > td_umtx q = 0xff00d1207080,
> > td_tid = 100253, td_flags = 16777216, td_inhibitors = 0, td_pflags =
> > 128, td_d upfd = 0, td_wchan = 0x0,
> > td_wmesg = 0x0, td_lastcpu = 2 '\002', td_oncpu = 2 '\002',
> > td_owepreempt = 0 '\0', td_locks = 0,
> > td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested =
> > {lh_first =
> > 0x0}, td_sleeplocks = 0x0,
> > td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred =
> > 0xf f00ad18f200,
> > td_standin = 0x0, td_upcall = 0x0, td_sticks = 0, td_uuticks = 0,
> > td_usticks =
> > 0, td_intrval = 0,
> > td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits =
> > {4294967295, 4 294967295, 4294967295,
> > 4294967295}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_generation
> > = 14, td _sigstk = {ss_sp = 0x0,
> > ss_size = 0, ss_flags = 0}, td_kflags = 0, td_xsig = 0,
> > td_profil_addr = 0, td_profil_ticks = 0,
> > td_base_pri = 182 '\u', td_priority = 182 '\u', td_pcb =
> > 0xb68 dcd10, td_state = TDS_INACTIVE,
> > td_retval = {1, 29309280}, td_slpcallout = {c_links = {sle = {sle_next
> > = 0x0},
> > tqe = {tqe_next = 0x0,
> > tqe_prev = 0xff001fac7d80}}, c_time = 55907602, c_arg =
> > 0xff0063 311260,
> > c_func = 0x802e32a0 , c_mtx = 0x0, c_flags =
> > 16}, td _frame = 0xb68dcc40,
> > td_kstack_obj = 0xff0087f93d20, td_kstack = 18446744072477315072,
> > td_kstac k_pages = 4,
> > td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0,
> > td_critnest = 1, td_md = {
> > md_spinlock_count = 1, md_saved_flags = 582}, td_sched =
> > 0xff0063311488}
>
> I'm not familiar with the internals of the thread and KSE life cycle here,
>
> so I think we'll need to look to those more familiar with this to
> understand what of two things may be going on:
>
> (1) Is the fact that td_ksegrp != NULL an invariant for a connected
> thread, and that kern_proc is relying on that but the thread code is
> failing to implement it safely?
>
> (2) Is td_ksegrp sometimes left legitimately as NULL as part of the thread
> life cycle, and that kern_proc incorrectly assumes that it is never
> NULL when hooked up to a thread.
>
> This suggests a possible work-around of simply testing td_ksegrp for NULL
> in kern_proc in order to avoid this, while attempting to resolve whether
> an invariant is violated (or incorrectly assumed), which might require
> some serious thinking and a solution that is non-trivial. Something like
> the following might work in the mean time:
>
> Index: kern_proc.c
> ===
> RCS file
Re: A smarter mergemaster
On Thu, Sep 29, 2005 at 11:41:57PM -0700, Doug Barton wrote: > > First let me say that you've obviously put a lot of work into this, and you > have some very interesting ideas here that are worthy of further discussion. > Please don't let any of my comments here be understood as criticism, or an > attempt to discourage you. Thanks! > Second, I'd like to point out that it's generally a bad idea to cross post > to more than one list. I've set a reply-to for hackers@, if you'd rather > have the discussion on current@ that's fine too, but please pick one. Well, I just couldn't decide between the two lists because I thought that -current was much devoted to reporting LORs and panics while discussions on -hackers tended to be rather theoretic unless they were about LORs and panics :-) Let's stick to -hackers now. > Finally, please be aware that in src/MAINTAINERS I have requested pre-commit > approval on changes to mergemaster. I hope that you'll respect that. I have > some more specific comments below. No problem with that, I'm by no means going to violate your maintainership over mergemaster. And yes, I should have peeked in src/MAINTAINERS earlier :-) > Yar Tikhiy wrote: > | Folks, > | > | I've got tired of dumb default choices mergemaster(8) offers and modified > | it to be a bit smarter. > > While I can appreciate your frustration, the way you've phrased this departs > from the project's tradition of respect for fellow developers and their > work. A better way for you to deal with your frustration here would have > been to send me, or alternatively, one of the mailing lists, a post which > stated your frustrations and asked for an explanation of the reasons for the > defaults. > > I am sure that you meant no actual insult here, so I'll not say anything > more about this topic. I beg your pardon. Let's say I was over-excited with having mm work the way I always wanted it to :-) And, not being a native English speaker, I didn't imagine that the word "dumb" could be insulting after I had seen so much references to the illustrious Dumb Terminals of the Golden Era of Computing ;-) > | Upgrading /etc often, as when following CURRENT, is much less pain to me > | now. > > One of the design decisions that you need to be aware of for this project > since day one was to try and balance intelligent behavior and configuration > options that would be useful for the very small percentage of the FreeBSD > user community that constitutes our developers, versus the needs of the vast > majority of "regular" users who need to be able to use the tool without > becoming experts in either our build system, or the tool itself. That is why > every single default for mergemaster is to do nothing. It was a purposeful > decision to require the user to examine change requests, and make an > affirmative choice to approve them. In fact, following CURRENT is not the only case when "expert" mode of mm could be desired. People following STABLE branches on their production machines use mm, too, and yours truly is among them. Their case is even more calling for "expert" mode because numerous machines usually need upgrading in a row. The admins study all the peculiarities of mm as soon as they run it a dozen times, but they still need to run it after that. Our /etc is well-suited for staying just slightly modified in the most common cases, so there is little need in turning each mm session into a school class to the admin. Of course, the admins will be responsible for the massive destruction their errors can cause when using mm in expert mode, but most admins are used to this kind of responsibility :-) > I find your idea of an "expert" mode for mm to be an interesting one, and I > think that enough time has gone by so that it will be "safe" to add this. > However I'd like to add a big, hairy warning message that says that users > who enable this option do so at their own risk, etc. I need to think more > about this. I'm unsure if it is hairy enough, but it's on the manpage already, as well as on the help screen, in my version. > | The fruitiest features are as follows: > | > | - mergemaster no longer teases you with pauses in -v mode. Use -N (novice > | mode) if you still want the pauses. > > I'm inclined to alter this to hide the pauses behind an expert mode flag, > but I need to study your patch more before I give a more firm opinion on > this. Do you have another strong reason for adding this mode? I just liked mm -v for it showing the list of files added locally, but I wasn't happy with the pauses obviously intended for novices, especially when I had to upgrade several machines in a row. > | - "Stale" rc.d files can be rm'ed or kept on individual basis. > > I think this is a good compromise for those who insist on "polluting" > /etc/rc.d with non-system stuff. :) If you're so inclined, could you add a > knob to specify a list of files to exclude from consideration? If not, I'll > take a look at it. Done and doc'
Re: A smarter mergemaster
[Replying to everyone who mentioned etcmerge or 3-way merge in general] On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote: > It is worth while to mention sysutils/etcmerge. > > Having the "three-way" merge makes the process much better. The primary > way I've shot myself with mergemaster is forgetting some local change. > > Being able to distinguish the class of things that are changing upstream > really helps the situation and provides a more reasonable indication of > the default: >if it changed upstream but not locally => default is install >if it changed locally but not upstream => default is keep >if it changed locally and upstream => default is merge Obviously, in order to do a 3-way merge, we need information about the old versions of original files as well. However, currently we have only the new versions in /usr/src and local versions in /etc for mergemaster to work with. I'll be glad to hear how etcmerge approaches this issue. In any case, we cannot offer the users to access the CVS repo when merging /etc. Personally, I'd like to see a complete copy of current unmodified /etc files installed to /usr/share/examples/etc. They could serve as the old original versions for the 3-way merge then. Alas, now the copy installed there is rather incomplete, motivation of which is unknown to me yet. Any ideas? -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
Robert,
We have gotten some more information from our type1 crash:
>sh lockedvnods
Locked vnodes
>sh alllocks
Process 2204 (dataplay) thread 0xff00b1726a000 (100214)
exclusive sleep mutex inp (udpinp) f = 0 (0xff00cc90fcc8) locked @
/usr/src/sys/netinet/udp_usrreq.c:762
Process 62 (pagedaemon) thread 0xff00e358c280 (100049)
exclusive sleep mutex UMA lock r = 0 (0x8068bf80) locked @
/usr/src/sys/vm/uma_core.c:1491
exclusive sleep mutex Giant r = 0 (0x8062ed80) locked @
/usr/src/sys/vm/vm_pageout.c:717
Process 48 (swi1:net) thread 0xff00e3597780 (100027)
exclusive sleep mutex IPFW static rules r = 0 (0x8067ae50) locked
@ /usr/src/sys/netinet/ip_fw2.c:149
>sh pcpu
cpuid=0
currthread = 0xff00e358c280: pid 63 "pagedaemon"
currpcb = 0xb34e3d10
fpcurrthread= none
idle thread = 0xff00e35b6000: pid 14 (idle cpu0)
spin locks held =
>sh pcpu 1
cpuid=1
currthread = 0xff00e358b3c80: pid 13 "idle cpu1"
currpcb = 0xffb34e7d10
fpcurrthread= none
idle thread = 0xff00e358b3c80: pid 13 (idle cpu1)
spin locks held =
>sh pcpu 2
cpuid=2
currthread = 0xff00e35e4000: pid 2715 "bonnie"
currpcb = 0xffb636dd10
fpcurrthread= none
idle thread = 0xff00e35b3a00: pid 12 (idle cpu2)
spin locks held =
>sh pcpu 3
cpuid=3
currthread = 0xff00e35aea00: pid 40 "irq27: em1 em2"
currpcb = 0xffb34b6d10
fpcurrthread= none
idle thread = 0xff00e35b3780: pid 11 (idle cpu0)
spin locks held =
I have attached the core output as type1-core.2.txt, but unfortunately it
does not help us determine the area of code that triggered the exception.
If I can get more DDB output from the type2 crash I will post it.
There is some encouraging news: since we stopped running top, our
6.0-BETA5 test machine has not crashed (its been running tests now for
over 26 hours).
We also started running tests on a dual single-core machine running
5-STABLE. That machine has been running for 50 hours without crashing.
This means that we are now only hitting these bugs with dual dual-core
machines running 5-STABLE.
-
Rob WattDDB:
>sh lockedvnods
Locked vnodes
>sh alllocks
Process 2204 (dataplay) thread 0xff00b1726a000 (100214)
exclusive sleep mutex inp (udpinp) f = 0 (0xff00cc90fcc8) locked @
/usr/src/sys/netinet/udp_usrreq.c:762
Process 62 (pagedaemon) thread 0xff00e358c280 (100049)
exclusive sleep mutex UMA lock r = 0 (0x8068bf80) locked @
/usr/src/sys/vm/uma_core.c:1491
exclusive sleep mutex Giant r = 0 (0x8062ed80) locked @
/usr/src/sys/vm/vm_pageout.c:717
Process 48 (swi1:net) thread 0xff00e3597780 (100027)
exclusive sleep mutex IPFW static rules r = 0 (0x8067ae50) locked @
/usr/src/sys/netinet/ip_fw2.c:149
>sh pcpu
cpuid=0
currthread = 0xff00e358c280: pid 63 "pagedaemon"
currpcb = 0xb34e3d10
fpcurrthread= none
idle thread = 0xff00e35b6000: pid 14 (idle cpu0)
spin locks held =
>sh pcpu 1
cpuid=1
currthread = 0xff00e358b3c80: pid 13 "idle cpu1"
currpcb = 0xffb34e7d10
fpcurrthread= none
idle thread = 0xff00e358b3c80: pid 13 "idle cpu1"
spin locks held =
>sh pcpu 2
cpuid=2
currthread = 0xff00e35e4000: pid 2715 "bonnie"
currpcb = 0xffb636dd10
fpcurrthread= none
idle thread = 0xff00e35b3a00: pid 12 "idle cpu2"
spin locks held =
>sh pcpu 3
cpuid=3
currthread = 0xff00e35aea00: pid 40 "irq27: em1 em2"
currpcb = 0xffb34b6d10
fpcurrthread= none
idle thread = 0xff00e35b3780: pid 11 "idle cpu0"
spin locks held =
KGDB:
Unread portion of the kernel message buffer:
panic: No TID bitmap?
cpuid = 0
KDB: enter: panic
#0 doadump () at pcpu.h:167
167 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:167
#1 0x801924f6 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0x0)
at /usr/src/sys/ddb/db_command.c:531
#2 0x80192985 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:349
#3 0x80194833 in db_trap (type=-1286719648, code=0) at
/usr/src/sys/ddb/db_main.c:221
#4 0x802cb8f0 in kdb_trap (type=3, code=0, tf=0x0) at
/usr/src/sys/kern/subr_kdb.c:470
#5 0x804169dc in trap (frame=
{tf_rdi = 0, tf_rsi = -2136928256, tf_rdx = 0, tf_rcx = 523776, tf_r8 =
-1286719440, tf_r9 = 10, tf_rax = 18, tf_rbx = -2142686258, tf_rbp =
-1286719200, tf_r10 = 20765, tf_r11 = 0, tf_r12 = 0, tf_r13 = 256, tf_r14 =
-1095697382784, tf_r15 = 768605, tf_trapno = 3, tf_addr = 0, tf_flags = 256,
tf_err = 0, tf_rip = -2144554161, tf_cs = 8, tf_rflags = 642, tf_rsp =
-1286719200, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:431
#6 0x804046fb in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:171
#7 0x in ?? ()
#8 0x80a11000 in ?? ()
#9 0x in ?? ()
#10 0x0007fe00 in
Re: journaling fs and large mailbox format
On Thu, Sep 29, 2005 at 04:11:29AM +0300, Alin-Adrian Anton wrote: > Dear Hackers, > > First of all thank you for your time and attention. > > I am in the position to implement a large-scale mail server and I > will never go for anything else but FreeBSD (fixation?). > > It should be able to handle graceously 4000 e-mail accounts where a > minimum of 50 Mb/mailbox would be a requirement. In the begining, it is > desirable that users could use as much free space as available, so this > implies some gigabytes/mailbox. > > I don't know if the mbox format can handle this, and I know Maildir > cannot handle this on UFS2 standard install, no matter of soft-updates. > (because it exhaustes the free nodes) So I currently have no solution > for this stuff. > > I was wondering what is the status of Journaling File Systems on > FreeBSD? Any which is usable and mature, with write access? XFS would > fit amazingly well with Maildir, but.. I doubt it's anything else but > readonly. > > So any suggestion would really help a lot. Thank's in advance. > > > Yours Sincerely, > -- > Alin-Adrian Anton > GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) > gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA > > "It is dangerous to be right when the government is wrong." - Voltaire > Consider to use DBMS storage as alternative. IMHO, this is more flexible solution, especially if you have a lot of disk space. Also you will be able to buil a mail cluster to scale your solution. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
On Thu, 29 Sep 2005, Robert Watson wrote: > Could you dump the contents of *td and *td->td_proc for me? I'm quite > interested to know what the value in td->td_proc->p_state is, among other > things. If I could also have you generate a dump of the KSE group > structures in td->td_proc->p_ksegrps and the threads in > td->td_proc->p_threads. I've attached a file with many of the values you have asked for. We looked at some of the threads referenced by td->td_proc->p_threads, but we weren't sure we were walking the list correctly. Do you have any tips for walking those thread lists? > > Could you tell me if the program named by p->p_comm is linked against a > threading library? If it's a custom app, you may already know, and if > not, you can run ldd on the application to see what it is linked against. > The programs named by p->p_comm is linked against the pthreads library. > Depending on how much time you have available, it might make sense for me > to grab from you a copy of your source tree, compiled kernel with debug > symbols, and core dump. We can upload the source, kernel etc somewhere, but uncompressed that is about 5G of data. What is the best way to get that to you? Thanks. - Rob Watt 6.0-BETA5.kgdb.out Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
using fast interrupts with em(4)
Hello All. For a project, I am looking into making the em(4) driver use fast interrupts. Has someone done this or are there other driver references that could help me in this? I understand that the main problems are: 1. Sharing of interrupts. 2. Blocking (memory and mutexes). Are there any other issues I might have missed? br - Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
On Fri, Sep 30, 2005 at 02:45:48AM +0400, Yar Tikhiy wrote: > The fruitiest features are as follows: Will it automatically install new versions of files where the old one was not altered? That's my biggest bugbear with mergemaster - it asks you about a zillion files in /etc/rc.d which you have to manually agree to overwrite just because the RCS ID has changed. In those cases where you've not altered them yourself, I think you should just get the latest version. However to do this properly, you'd need checksums of the original files. [*] Also, can we have mergemaster work as part of the binary upgrade process too please... the new files are in /usr/share/examples/etc so I don't see why we can't merge directly from there into /etc Regards, Brian. [*] http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-May/049784.html point 4. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
Brian Candler wrote: That's my biggest bugbear with mergemaster - it asks you about a zillion files in /etc/rc.d which you have to manually agree to overwrite just because the RCS ID has changed. In those cases where you've not altered them yourself, I think you should just get the latest version. However to do this properly, you'd need checksums of the original files. [*] Not necessarily. Diff can be made to ignore changes which match specific regular expressions (-I), so if you can reliably match the RCS Id lines you can ignore those changes. Note, though, that this is different from files which you haven't changed. The new version might change more than the RCS Id, in which you would be back to checksums, or some such. However, a change to automatically install files where *only* the RCS Id had changed would be easier and quicker to effect than the general case of all files which you hadn't changed. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
On Friday 30 September 2005 18:12, Brian Candler wrote: > On Fri, Sep 30, 2005 at 02:45:48AM +0400, Yar Tikhiy wrote: > > The fruitiest features are as follows: > > Will it automatically install new versions of files where the old one was > not altered? That's my biggest bugbear with mergemaster - it asks you about > a zillion files in /etc/rc.d which you have to manually agree to overwrite > just because the RCS ID has changed. In those cases where you've not > altered them yourself, I think you should just get the latest version. > However to do this properly, you'd need checksums of the original files. *broken record* Try etcmerge, it's in ports. I think the main problem is that you can't use etcmerge *right now* because you have to do one last manual merge to get a baseline etc directory. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpJVxuD7xPkP.pgp Description: PGP signature
Re: A smarter mergemaster
On Friday 30 September 2005 18:23, Ashley Moran wrote: > > It does have problems handling DB files, but that is usually not a big > > problem to fix. > > I read about etcmerge in BSD Hacks and there's been no going back for > me. It seems pretty stable even though it's not been updated for a good > while. Is there any chance it will ever make it into the FreeBSD core > system? It sure would be nice :) One thing would be to have automatically fetched etc directories so when you ran it for the first time it would grab a release version of etc for you :) Hmm.. I'll try and add that if I get some time I think! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgplWq14QGuRi.pgp Description: PGP signature
Re: freebsd-5.4-stable panics
On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote:
> Hi Robert,
> I don't think your patch is correct, the total linked list can be broken
> while the lock is released, thus just passing the link may not be enough
> I have submitted a PR[1] for this a month ago but nobody took care of it
> yet Regards,
> Antoine Pelisse
>
> [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
I think this patch looks ok. Robert, can you get the original panic on this
thread tested against this patch?
> On 9/29/05, Robert Watson <[EMAIL PROTECTED]> wrote:
> > On Thu, 29 Sep 2005, Rob Watt wrote:
> > > On Thu, 29 Sep 2005, Robert Watson wrote:
> > >> Could you dump the contents of *td and *td->td_proc for me? I'm quite
> > >> interested to know what the value in td->td_proc->p_state is, among
> >
> > other
> >
> > >> things. If I could also have you generate a dump of the KSE group
> > >> structures in td->td_proc->p_ksegrps and the threads in
> > >> td->td_proc->p_threads.
> > >
> > > I've attached a file with many of the values you have asked for. We
> > > looked at some of the threads referenced by td->td_proc->p_threads, but
> > > we weren't sure we were walking the list correctly. Do you have any
> > > tips
> > >
> > > for walking those thread lists?
> > >
> > >> Could you tell me if the program named by p->p_comm is linked against
> > >> a threading library? If it's a custom app, you may already know, and
> > >> if not, you can run ldd on the application to see what it is linked
> > >> against.
> > >
> > > The programs named by p->p_comm is linked against the pthreads library.
> >
> > This seems to be enough information to at least track this down a bit:
> > td_ksegrp is NULL, rather than a corrupt value, which suggests that the
> > thread is incompletely initialized. Other hints that this are the case
> > are that td_critnest is 1 (as is set when it is allocated), and the state
> > is TDS_INACTIVE. Some other fields are set though, such as td_oncpu,
> > which is normally initialized to NOCPU.
> >
> > > (kgdb) p *td
> > > $1 = {td_proc = 0xff004aa9f000, td_ksegrp = 0x0, td_plist =
> > > {tqe_next = 0xff 00b4798000,
> > > tqe_prev = 0xff00a97ae010}, td_kglist = {tqe_next =
> > > 0xff00b4798000,
> > > tqe_prev = 0xff00a97ae020}, td_slpq = {tqe_next = 0x0, tqe_prev
> > > = 0x ff001fac7c10}, td_lockq = {
> > > tqe_next = 0xff00a97ae000, tqe_prev = 0xb6797a70},
> > > td_runq = {tq e_next = 0x0,
> > > tqe_prev = 0x80608180}, td_selq = {tqh_first = 0x0, tqh_last
> > > = 0xfff fff00633112c0},
> > > td_sleepqueue = 0xff00382b0400, td_turnstile = 0xff00c1712900,
> > > td_umtx q = 0xff00d1207080,
> > > td_tid = 100253, td_flags = 16777216, td_inhibitors = 0, td_pflags =
> > > 128, td_d upfd = 0, td_wchan = 0x0,
> > > td_wmesg = 0x0, td_lastcpu = 2 '\002', td_oncpu = 2 '\002',
> > > td_owepreempt = 0 '\0', td_locks = 0,
> > > td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested =
> > > {lh_first =
> > > 0x0}, td_sleeplocks = 0x0,
> > > td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred =
> > > 0xf f00ad18f200,
> > > td_standin = 0x0, td_upcall = 0x0, td_sticks = 0, td_uuticks = 0,
> > > td_usticks =
> > > 0, td_intrval = 0,
> > > td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits =
> > > {4294967295, 4 294967295, 4294967295,
> > > 4294967295}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_generation
> > > = 14, td _sigstk = {ss_sp = 0x0,
> > > ss_size = 0, ss_flags = 0}, td_kflags = 0, td_xsig = 0,
> > > td_profil_addr = 0, td_profil_ticks = 0,
> > > td_base_pri = 182 '\u', td_priority = 182 '\u', td_pcb =
> > > 0xb68 dcd10, td_state = TDS_INACTIVE,
> > > td_retval = {1, 29309280}, td_slpcallout = {c_links = {sle = {sle_next
> > > = 0x0},
> > > tqe = {tqe_next = 0x0,
> > > tqe_prev = 0xff001fac7d80}}, c_time = 55907602, c_arg =
> > > 0xff0063 311260,
> > > c_func = 0x802e32a0 , c_mtx = 0x0, c_flags =
> > > 16}, td _frame = 0xb68dcc40,
> > > td_kstack_obj = 0xff0087f93d20, td_kstack = 18446744072477315072,
> > > td_kstac k_pages = 4,
> > > td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0,
> > > td_critnest = 1, td_md = {
> > > md_spinlock_count = 1, md_saved_flags = 582}, td_sched =
> > > 0xff0063311488}
> >
> > I'm not familiar with the internals of the thread and KSE life cycle
> > here,
> >
> > so I think we'll need to look to those more familiar with this to
> > understand what of two things may be going on:
> >
> > (1) Is the fact that td_ksegrp != NULL an invariant for a connected
> > thread, and that kern_proc is relying on that but the thread code is
> > failing to implement it safely?
> >
> > (2) Is td_ksegrp sometimes left legitimately as NULL as part of the
> > thread life cycle, and that kern_proc incorrectly assumes that it is
> > never NULL when hooked up to a thread.
> >
> > This suggests a possible work-around of simply testing td_ksegr
Re: dev_lock() question
On Thursday 29 September 2005 03:36 pm, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, John Baldwin writes:
> >On Thursday 29 September 2005 02:14 pm, Poul-Henning Kamp wrote:
> >> In message <[EMAIL PROTECTED]>, John Baldwin writes:
> >> >Actually, you would think that it could be initialized either via an
> >> > early SYSINIT() or in the init_mutexes() function in kern_mutex.c and
> >> > thus not need the early check and avoid penalizing dev_lock().
> >> >
> >> >phk, how early his dev_lock needed?
> >>
> >> Far too early due to console madness (in syscons I belive).
> >
> >So would mutex_init() work?
>
> Havn't tried. It basically has to work right before the copyright
> is printed.
Actually, mutexes won't work until after mutex_init() anyway, so it had better
work. :) I'll try it out. Patch is below for reference:
--- //depot/vendor/freebsd/src/sys/kern/kern_conf.c 2005/09/19 20:01:08
+++ //depot/projects/smpng/sys/kern/kern_conf.c 2005/09/30 12:57:36
@@ -57,8 +57,7 @@
void
dev_lock(void)
{
- if (!mtx_initialized(&devmtx))
- mtx_init(&devmtx, "cdev", NULL, MTX_DEF);
+
mtx_lock(&devmtx);
}
--- //depot/vendor/freebsd/src/sys/kern/kern_mutex.c2005/09/02 20:25:20
+++ //depot/projects/smpng/sys/kern/kern_mutex.c2005/09/30 12:57:36
@@ -900,5 +935,6 @@
mtx_init(&Giant, "Giant", NULL, MTX_DEF | MTX_RECURSE);
mtx_init(&sched_lock, "sched lock", NULL, MTX_SPIN | MTX_RECURSE);
mtx_init(&proc0.p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK);
+ mtx_init(&devmtx, "cdev", NULL, MTX_DEF);
mtx_lock(&Giant);
}
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
On Friday 30 September 2005 07:08 am, Yar Tikhiy wrote: > [Replying to everyone who mentioned etcmerge or 3-way merge in general] > > On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote: > > It is worth while to mention sysutils/etcmerge. > > > > Having the "three-way" merge makes the process much better. The primary > > way I've shot myself with mergemaster is forgetting some local change. > > > > Being able to distinguish the class of things that are changing upstream > > really helps the situation and provides a more reasonable indication of > > the default: > >if it changed upstream but not locally => default is install > >if it changed locally but not upstream => default is keep > >if it changed locally and upstream => default is merge > > Obviously, in order to do a 3-way merge, we need information about > the old versions of original files as well. However, currently we > have only the new versions in /usr/src and local versions in /etc > for mergemaster to work with. I'll be glad to hear how etcmerge > approaches this issue. > > In any case, we cannot offer the users to access the CVS repo when > merging /etc. Personally, I'd like to see a complete copy of current > unmodified /etc files installed to /usr/share/examples/etc. They > could serve as the old original versions for the 3-way merge then. > Alas, now the copy installed there is rather incomplete, motivation > of which is unknown to me yet. Any ideas? I do the equivalent of etcmerge (sort of) by hand using some old instructions from the handbook (pre-mm). Basically, for each installworld, you do a distribute of src/etc into /var/tmp/root-YYMMDD. Then you keep around the previous tree and just compare the two previous trees and merge those changes into /etc. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
Daniel O'Connor wrote: On Friday 30 September 2005 18:23, Ashley Moran wrote: It sure would be nice :) One thing would be to have automatically fetched etc directories so when you ran it for the first time it would grab a release version of etc for you :) Hmm.. I'll try and add that if I get some time I think! Funny you should say that... I had a crack at something similar myself (see below). But I was hampered by the fact that a) I had never used CVS before (we use VSS here but I'm moving it all to SVN), and b) I have no idea how the FreeBSD build process works (I'm a hardcore hacker lol) Unfortunately it seems that config files for the subsystems (eg SSH) are stored separately in the CVS tree and I didn't have time to work out where they live. While we're on the subject, how do you handle the DB files? I don't see any special mention of them in the man pages. When I last etcmerged I glossed over them and haven't had any login problems since. Ashley Here is my effort: #!/bin/sh # takes one argument: name of the tag to get from CVS cd /var/db # clear out any previous files rm -rf etc # fetch new etc files from cvs export CVSROOT=:pserver:anoncvs:[EMAIL PROTECTED]:/home/ncvs cvs login cvs -QR export -r$1 etc cvs logout cd etc # local adjustment mv etc.i386/ttys . # clear out the other platform-specific files rm -r etc.* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
On Friday 30 September 2005 23:50, Ashley Moran wrote: > Unfortunately it seems that config files for the subsystems (eg SSH) are > stored separately in the CVS tree and I didn't have time to work out > where they live. The trick is to get the system to build you an /etc - see how mergemaster does it (runs make in the right place basically) > While we're on the subject, how do you handle the DB files? I don't see > any special mention of them in the man pages. When I last etcmerged I > glossed over them and haven't had any login problems since. For passwd stuff I merge /etc/master.passwd and then run cap_mkdb to rebuild the other 3 files based on it. Also run newaliases when aliases are touched, and cap_mkdb for login.conf. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpCdWRAsvaHE.pgp Description: PGP signature
Re: A smarter mergemaster
On Fri, Sep 30, 2005 at 09:07:16AM -0400, John Baldwin wrote: > On Friday 30 September 2005 07:08 am, Yar Tikhiy wrote: > > [Replying to everyone who mentioned etcmerge or 3-way merge in general] > > > > On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote: > > > It is worth while to mention sysutils/etcmerge. > > > > > > Having the "three-way" merge makes the process much better. The primary > > > way I've shot myself with mergemaster is forgetting some local change. > > > > > > Being able to distinguish the class of things that are changing upstream > > > really helps the situation and provides a more reasonable indication of > > > the default: > > >if it changed upstream but not locally => default is install > > >if it changed locally but not upstream => default is keep > > >if it changed locally and upstream => default is merge > > > > Obviously, in order to do a 3-way merge, we need information about > > the old versions of original files as well. However, currently we > > have only the new versions in /usr/src and local versions in /etc > > for mergemaster to work with. I'll be glad to hear how etcmerge > > approaches this issue. > > > > In any case, we cannot offer the users to access the CVS repo when > > merging /etc. Personally, I'd like to see a complete copy of current > > unmodified /etc files installed to /usr/share/examples/etc. They > > could serve as the old original versions for the 3-way merge then. > > Alas, now the copy installed there is rather incomplete, motivation > > of which is unknown to me yet. Any ideas? > > I do the equivalent of etcmerge (sort of) by hand using some old instructions > from the handbook (pre-mm). Basically, for each installworld, you do a > distribute of src/etc into /var/tmp/root-YYMMDD. Then you keep around the > previous tree and just compare the two previous trees and merge those changes > into /etc. I'm curious if we can do this in the stock system using the stock tools. We could compare /usr/share/examples/etc with the results of "make distrubution" and merge the changes into /etc. Mergemaster invokes "make distrubution" anyway, so it just needs relevant /usr/share/examples/etc to be able to do a 3-way merge. This assumes that /usr/share/examples/etc is in keeping with /etc, of course, but the assumption can be verified using RCS Id strings, which should be the same here and there. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
serial login to SBC
Hello list, I am trying to use a FreeBSD box to log into a Single Board Computer. I have a null modem and it's plugged to both serial ports. The SBC runs openbsd ( /dev/cua00). When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login prompt. What I am doing wrong? I've already read the FBSD handbook. I have an OpenBSD box to experiment with first, and can't serial login either. I really need help on this one. Thank you ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-5.4-stable panics
On 9/30/05, John Baldwin <[EMAIL PROTECTED]> wrote:
> On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote:
> > Hi Robert,
> > I don't think your patch is correct, the total linked list can be broken
>
> > while the lock is released, thus just passing the link may not be enough
> > I have submitted a PR[1] for this a month ago but nobody took care of it
> > yet Regards,
> > Antoine Pelisse
> >
> > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
>
> I think this patch looks ok. Robert, can you get the original panic on
> this
> thread tested against this patch?
I had a small program which could reproduce this panic in 10 seconds, it
was basically creating empty threads and calling kvm_getprocs() in the same
time. Anyway the patch was able to stop the program from panicing.
The panic is also reproducible in RELENG_6 and HEAD IIRC.
> On 9/29/05, Robert Watson <[EMAIL PROTECTED]> wrote:
> > > On Thu, 29 Sep 2005, Rob Watt wrote:
> > > > On Thu, 29 Sep 2005, Robert Watson wrote:
> > > >> Could you dump the contents of *td and *td->td_proc for me? I'm
> quite
> > > >> interested to know what the value in td->td_proc->p_state is, among
>
> > >
> > > other
> > >
> > > >> things. If I could also have you generate a dump of the KSE group
> > > >> structures in td->td_proc->p_ksegrps and the threads in
> > > >> td->td_proc->p_threads.
> > > >
> > > > I've attached a file with many of the values you have asked for. We
> > > > looked at some of the threads referenced by td->td_proc->p_threads,
> but
> > > > we weren't sure we were walking the list correctly. Do you have any
> > > > tips
> > > >
> > > > for walking those thread lists?
> > > >
> > > >> Could you tell me if the program named by p->p_comm is linked
> against
> > > >> a threading library? If it's a custom app, you may already know,
> and
> > > >> if not, you can run ldd on the application to see what it is linked
> > > >> against.
> > > >
> > > > The programs named by p->p_comm is linked against the pthreads
> library.
> > >
> > > This seems to be enough information to at least track this down a bit:
> > > td_ksegrp is NULL, rather than a corrupt value, which suggests that
> the
> > > thread is incompletely initialized. Other hints that this are the case
> > > are that td_critnest is 1 (as is set when it is allocated), and the
> state
> > > is TDS_INACTIVE. Some other fields are set though, such as td_oncpu,
> > > which is normally initialized to NOCPU.
> > >
> > > > (kgdb) p *td
> > > > $1 = {td_proc = 0xff004aa9f000, td_ksegrp = 0x0, td_plist =
> > > > {tqe_next = 0xff 00b4798000,
> > > > tqe_prev = 0xff00a97ae010}, td_kglist = {tqe_next =
> > > > 0xff00b4798000,
> > > > tqe_prev = 0xff00a97ae020}, td_slpq = {tqe_next = 0x0, tqe_prev
> > > > = 0x ff001fac7c10}, td_lockq = {
> > > > tqe_next = 0xff00a97ae000, tqe_prev = 0xb6797a70},
> > > > td_runq = {tq e_next = 0x0,
> > > > tqe_prev = 0x80608180}, td_selq = {tqh_first = 0x0, tqh_last
> > > > = 0xfff fff00633112c0},
> > > > td_sleepqueue = 0xff00382b0400, td_turnstile =
> 0xff00c1712900,
> > > > td_umtx q = 0xff00d1207080,
> > > > td_tid = 100253, td_flags = 16777216, td_inhibitors = 0, td_pflags =
>
> > > > 128, td_d upfd = 0, td_wchan = 0x0,
> > > > td_wmesg = 0x0, td_lastcpu = 2 '\002', td_oncpu = 2 '\002',
> > > > td_owepreempt = 0 '\0', td_locks = 0,
> > > > td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested =
> > > > {lh_first =
> > > > 0x0}, td_sleeplocks = 0x0,
> > > > td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred
> =
> > > > 0xf f00ad18f200,
> > > > td_standin = 0x0, td_upcall = 0x0, td_sticks = 0, td_uuticks = 0,
> > > > td_usticks =
> > > > 0, td_intrval = 0,
> > > > td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits =
> > > > {4294967295, 4 294967295, 4294967295,
> > > > 4294967295}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_generation
> > > > = 14, td _sigstk = {ss_sp = 0x0,
> > > > ss_size = 0, ss_flags = 0}, td_kflags = 0, td_xsig = 0,
> > > > td_profil_addr = 0, td_profil_ticks = 0,
> > > > td_base_pri = 182 '\u', td_priority = 182 '\u', td_pcb =
> > > > 0xb68 dcd10, td_state = TDS_INACTIVE,
> > > > td_retval = {1, 29309280}, td_slpcallout = {c_links = {sle =
> {sle_next
> > > > = 0x0},
> > > > tqe = {tqe_next = 0x0,
> > > > tqe_prev = 0xff001fac7d80}}, c_time = 55907602, c_arg =
> > > > 0xff0063 311260,
> > > > c_func = 0x802e32a0 , c_mtx = 0x0, c_flags =
> > > > 16}, td _frame = 0xb68dcc40,
> > > > td_kstack_obj = 0xff0087f93d20, td_kstack =
> 18446744072477315072,
> > > > td_kstac k_pages = 4,
> > > > td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0,
> > > > td_critnest = 1, td_md = {
> > > > md_spinlock_count = 1, md_saved_flags = 582}, td_sched =
> > > > 0xff0063311488}
> > >
> > > I'm not familiar with the internals of the thread and KSE life cycle
> > > here,
> > >
> > > so I think we'll need
Re: serial login to SBC
On Fri, Sep 30, 2005 at 05:14:01PM +0200, [EMAIL PROTECTED] wrote: > > Hello list, > I am trying to use a FreeBSD box to log into a Single Board Computer. I > have a null modem and it's plugged to both serial > ports. The SBC runs openbsd ( /dev/cua00). > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login > prompt. Do you have getty running on that port on the SBC? > What I am doing wrong? > > I've already read the FBSD handbook. > I have an OpenBSD box to experiment with first, and can't serial login > either. > I really need help on this one. > Thank you > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Brian Reichert <[EMAIL PROTECTED]> 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
arplookup/arpresolved failure messages in mailserver
Hi, I am seeing a lot of these messages in my /var/log/messages directory and cannot understand why: arplookup 192.168.0.12 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.168.0.12rt There were more of these messages for two other IPs (one external), but this is the only one with 'rt' trailed at the end of the IP. Whats this for? Its been happenning since yesterday and it seems that the server is attempting this every 2-3 seconds, which I think is the cause for a sluggish mailserver (this litterally happened over night!). Also, would this be linked to another incident which meant that all mail was being dumped in queue (im running qmail MTA)? Following a restart of the mail server, we experienced routing problems such that we were not able to access the server from the office LAN but could be accessed by another machine on its LAN; zebrad and ospfd did not start at restart. Why was this? This morning, all seems to be fine accept a couple of the following messages from last night: Sep 29 16:08:26 freebsd10 /kernel: arplookup 217.73.66.16 failed: host is not on local network Sep 29 17:40:50 freebsd10 /kernel: arplookup 217.73.66.16 failed: host is not on local network Sep 29 23:46:38 freebsd10 /kernel: arplookup 217.73.66.16 failed: host is not on local network Forgive me for being such a novice...but I am :) Thanks Khaled ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: using fast interrupts with em(4)
In message: <[EMAIL PROTECTED]> Kernel Dev <[EMAIL PROTECTED]> writes: : Hello All. For a project, I am looking into making the em(4) driver use fast interrupts. Has someone done this or are there other driver references that could help me in this? : : I understand that the main problems are: : : 1. Sharing of interrupts. : 2. Blocking (memory and mutexes). : : Are there any other issues I might have missed? You can share fast interrupts, but it isn't a good idea... You can't block in a fast interrupt. You must use spin locks. You cannot call anything that will sleep in a fast interrupt. Ideally, you'd not modify anything that isn't covered by your own spin locks, leaving that for a taskqueue or similar queueing strategy. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: serial login to SBC
In message: <[EMAIL PROTECTED]> Brian Reichert <[EMAIL PROTECTED]> writes: : On Fri, Sep 30, 2005 at 05:14:01PM +0200, [EMAIL PROTECTED] wrote: : > : > Hello list, : > I am trying to use a FreeBSD box to log into a Single Board Computer. I : > have a null modem and it's plugged to both serial : > ports. The SBC runs openbsd ( /dev/cua00). : > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login : > prompt. : : Do you have getty running on that port on the SBC? Do you have all the modem pins connected for this cable? Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Filesystem access from a KLD causes "vrele: negative ref cnt" panic
> It is hard to say something not seeing and understanding the > complete source code. Well, it's a very simple module : http://lekernel.lya-fr.com/firmwareagent_en.html > But since fdinit() which is called from > fork1() and fdfree() which is called from exit1() get and release > reference on vnodes fd_cdir and fd_rdir point to, you need to > follow this semantics. Ok, so it should be VREF'd twice - it works now :) Thanks, Sebastien ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: serial login to SBC
On Friday 30 September 2005 12:33 pm, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > Brian Reichert <[EMAIL PROTECTED]> writes: > : On Fri, Sep 30, 2005 at 05:14:01PM +0200, [EMAIL PROTECTED] wrote: > : > Hello list, > : > I am trying to use a FreeBSD box to log into a Single Board Computer. I > : > have a null modem and it's plugged to both serial > : > ports. The SBC runs openbsd ( /dev/cua00). > : > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login > : > prompt. > : > : Do you have getty running on that port on the SBC? > > Do you have all the modem pins connected for this cable? Also, make sure and use the right speed. e.g., if the remote box's console is running at 9600, do 'cu -l /dev/cuaa0 -s 9600' -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
On Friday 30 September 2005 11:25 am, Antoine Pelisse wrote:
> On 9/30/05, John Baldwin <[EMAIL PROTECTED]> wrote:
> > On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote:
> > > Hi Robert,
> > > I don't think your patch is correct, the total linked list can be
> > > broken
> > >
> > > while the lock is released, thus just passing the link may not be
> > > enough I have submitted a PR[1] for this a month ago but nobody took
> > > care of it yet Regards,
> > > Antoine Pelisse
> > >
> > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
> >
> > I think this patch looks ok. Robert, can you get the original panic on
> > this
> > thread tested against this patch?
>
> I had a small program which could reproduce this panic in 10 seconds, it
> was basically creating empty threads and calling kvm_getprocs() in the same
> time. Anyway the patch was able to stop the program from panicing.
> The panic is also reproducible in RELENG_6 and HEAD IIRC.
It turns out that the sysctl buffer is already wired in one of the two cases
that this function is called, so I moved the wiring up to the upper layer in
the other case and cut out a bunch of the locking gymnastics as a result.
Can you try this patch?
Index: kern_proc.c
===
RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v
retrieving revision 1.231
diff -u -r1.231 kern_proc.c
--- kern_proc.c 27 Sep 2005 18:03:15 - 1.231
+++ kern_proc.c 30 Sep 2005 17:04:57 -
@@ -875,22 +875,16 @@
if (flags & KERN_PROC_NOTHREADS) {
fill_kinfo_proc(p, &kinfo_proc);
- PROC_UNLOCK(p);
error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc,
sizeof(kinfo_proc));
- PROC_LOCK(p);
} else {
- _PHOLD(p);
FOREACH_THREAD_IN_PROC(p, td) {
fill_kinfo_thread(td, &kinfo_proc);
- PROC_UNLOCK(p);
error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc,
sizeof(kinfo_proc));
- PROC_LOCK(p);
if (error)
break;
}
- _PRELE(p);
}
PROC_UNLOCK(p);
if (error)
@@ -932,6 +926,9 @@
if (oid_number == KERN_PROC_PID) {
if (namelen != 1)
return (EINVAL);
+ error = sysctl_wire_old_buffer(req, 0);
+ if (error)
+ return (error);
p = pfind((pid_t)name[0]);
if (!p)
return (ESRCH);
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: serial login to SBC
Thank you all for your replys. My answers are inline: > : Do you have getty running on that port on the SBC? yes. It should be running. We have in /etc/ttys (openbsd) tty00 "/usr/libexec/getty std.9600" dialup on secure > Do you have all the modem pins connected for this cable? I got this null modem from circuit city. it worked in other circumstances when I do serial debugging on other boxes. >Also, make sure and use the right speed. e.g., if the remote box's >console >is running at 9600, do 'cu -l /dev/cuaa0 -s 9600' I tried this and still no login prompt. One thing I've noticed on the FreeBSD (5.4 RELEASE) dmesg is sio0: port may not be enabled I enabled the first serial port in the BIOS, but I still get this. Me scratching head now. Anything else I may be missing? J. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: serial login to SBC
In message: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> writes: : One thing I've noticed on the FreeBSD (5.4 RELEASE) dmesg is : sio0: port may not be enabled : : I enabled the first serial port in the BIOS, but I still get this. : Me scratching head now. Anything else I may be missing? Can you post a dmesg? Also, ps auxww | grep getty | grep d0 should show something like: root726 0.0 0.2 1316 956 d0 Is+ 8:16AM 0:00.00 /usr/libexec/getty Pc ttyd0 You should also be able to tell if sio attaches by looking at /dev: ls -l /dev/*d0* you will likely see ad0 devices, kbd0 devices in addition to ttyd0 and cuad0 devices. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: serial login to SBC
In message: <[EMAIL PROTECTED]> Sergey Babkin <[EMAIL PROTECTED]> writes: : >From: "M. Warner Losh" <[EMAIL PROTECTED]> : : >In message: <[EMAIL PROTECTED]> : >Brian Reichert <[EMAIL PROTECTED]> writes: : >: On Fri, Sep 30, 2005 at 05:14:01PM +0200, [EMAIL PROTECTED] wrote: : >: > : >: > Hello list, : >: > I am trying to use a FreeBSD box to log into a Single Board Computer. I : >: > have a null modem and it's plugged to both serial : >: > ports. The SBC runs openbsd ( /dev/cua00). : >: > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login : >: > prompt. : >: : >: Do you have getty running on that port on the SBC? : > : >Do you have all the modem pins connected for this cable? : : Also, is the cable pin-out correct even for the Rx : and Tx pins? There are weird recombinations of : male-female and DCE-DTE pin-out used by different : manufacturers. The easiest way to check is to get : a port tester (a pass-through BOX with LEDs) from : some place like Radioshack. : : The correct Unix cable connection is : : Tx - Rx : DTR - DSR, CD : CTS - RTS : : (and the other side symmetric). Many cable : manufacturers use different (wrong) connections. Closely related is the 1 3 5 7 9 2 4 6 8 10 vs 1 2 3 4 5 6 7 8 9 10 issue for headers. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
On Thu, 29 Sep 2005, Doug Barton wrote: Alin-Adrian Anton wrote: XFS fits incredibly well with Maildir, however this I did not test practically I am curious as to what the defaults are for frag, inode, and block sizes on XFS, and whether that is one of the factors that make it work well with maildir. Doug I don't think that frag, inode and block size is the main factor that makes XFS work well in many small files situations. From what I have read about XFS I gather that it allocates inodes on demand, that it doesn't have fixed amount of them. VH ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
On Fri, Sep 30, 2005 at 09:43:13PM +0200, Vaclav Haisman wrote: > I don't think that frag, inode and block size is the main factor that makes > XFS work well in many small files situations. From what I have read about > XFS I gather that it allocates inodes on demand, that it doesn't have fixed > amount of them. Nope - not by default on a Linux 2.6.12 kernel anyway: David. 11% df -i . FilesystemInodes IUsed IFree IUse% Mounted on /dev/sda2 96384 31 963531% /boot 12% mount | fgrep /boot /dev/sda2 on /boot type xfs (rw) 13% @ i=0 14% while ( $i < 96358 ) while? touch $i while? @ i++ while? end touch: cannot touch `96353': No space left on device touch: cannot touch `96354': No space left on device touch: cannot touch `96355': No space left on device touch: cannot touch `96356': No space left on device touch: cannot touch `96357': No space left on device 16% df -i /boot FilesystemInodes IUsed IFree IUse% Mounted on /dev/sda2 96384 96384 0 100% /boot ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysctl variable creation
I'm hacking up sys/ufs/ufs/ufs_vnops.c, and I've added a sysctl entry, but it doesn't appear via sysctl -a -c vfs.ufs. Here's what I've done: --- ufs_vnops.c-origThu Sep 29 20:47:50 2005 +++ ufs_vnops.c Fri Sep 30 13:44:55 2005 @@ -79,6 +79,7 @@ #include #include #include +#include #ifdef UFS_DIRHASH #include #endif @@ -122,6 +123,12 @@ 0, DIRBLKSIZ - 12, 2, ".." }; +struct ufsstats ufsstats; + +static SYSCTL_NODE(_vfs, OID_AUTO, ufs, CTLFLAG_RD, 0, "UFS filesystem"); +SYSCTL_STRUCT(_vfs_ufs, OID_AUTO, ufsstats, CTLFLAG_RD, +&ufsstats, ufsstats, "S,ufsstats"); + void ufs_itimes(vp) struct vnode *vp; @@ -172,6 +179,7 @@ error = ufs_makeinode(MAKEIMODE(ap->a_vap->va_type, ap->a_vap->va_mode), ap->a_dvp, ap->a_vpp, ap->a_cnp); +ufsstats.create++; if (error) return (error); return (0); Compiles ok, just no sysctl variable.. Thanks! (sorry if it's a stupid mistake - I'm new to this) Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Daemon image with a beer mug?
I'm just putting the finishing touches on a paper that I'll present at the AUUG 2005 conference (see http://www.auug.org.au/ for details). The paper is about using FreeBSD to control the fermentation process. Normally I put a beastie image at the bottom right of the slides (see http://www.lemis.com/SMPng/AUUG2001/slides.pdf for an example), but in this case it would seem appropriate to have the beastie holding a mug of beer. I seem to remember having seen something like that once, but I can't trace it. If you know where there is one, please let me know. Greg -- See complete headers for address and phone numbers. pgp8grgjMFhOy.pgp Description: PGP signature
Re: sysctl variable creation
On Fri, 2005-Sep-30 16:51:51 -0500, Eric Anderson wrote: >I'm hacking up sys/ufs/ufs/ufs_vnops.c, and I've added a sysctl entry, >but it doesn't appear via sysctl -a -c vfs.ufs. Here's what I've done: The code looks correct but I can't find a '-c' option to sysctl in 4.x, 5.x or 7.x. Note that SYSCTL_STRUCT defines an opaque type that won't be displayed by default. You may want "sysctl -x vfs.ufs" -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysctl variable creation
Peter Jeremy wrote: On Fri, 2005-Sep-30 16:51:51 -0500, Eric Anderson wrote: I'm hacking up sys/ufs/ufs/ufs_vnops.c, and I've added a sysctl entry, but it doesn't appear via sysctl -a -c vfs.ufs. Here's what I've done: The code looks correct but I can't find a '-c' option to sysctl in 4.x, 5.x or 7.x. Note that SYSCTL_STRUCT defines an opaque type that won't be displayed by default. You may want "sysctl -x vfs.ufs" Yea, that's what I meant, sorry about that. I think I am missing a SYSCTL_DECL in there, so maybe this would work: --- /usr/src/sys/ufs/ufs/ufs_vnops.c-orig Thu Sep 29 20:47:50 2005 +++ /usr/src/sys/ufs/ufs/ufs_vnops.cFri Sep 30 23:14:34 2005 @@ -79,6 +79,7 @@ #include #include #include +#include #ifdef UFS_DIRHASH #include #endif @@ -122,6 +123,13 @@ 0, DIRBLKSIZ - 12, 2, ".." }; +struct ufsstats ufsstats; + +SYSCTL_DECL(_vfs_ufs); + +SYSCTL_STRUCT(_vfs_ufs, OID_AUTO, ufsstats, CTLFLAG_RW, +&ufsstats, ufsstats, "S,ufsstats"); + void ufs_itimes(vp) struct vnode *vp; @@ -172,6 +180,7 @@ error = ufs_makeinode(MAKEIMODE(ap->a_vap->va_type, ap->a_vap->va_mode), ap->a_dvp, ap->a_vpp, ap->a_cnp); +ufsstats.create++; if (error) return (error); return (0); Thanks for the reply! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
