lock recursion panic in cam_xpt.c
A recent CURRENT build from /head @ 209581 panics when I run "cdrecord -scanbus" with the attached backtrace. The culprit seems to be the extra call fo xpt_lock_buses() added in head rev 208752, but I'm not sure if this is the real cause yet. --- a/sys/cam/cam_xpt.c Wed Jun 02 17:27:23 2010 + +++ b/sys/cam/cam_xpt.c Wed Jun 02 18:06:32 2010 + @@ -2138,6 +2138,7 @@ xptpdperiphtraverse(struct periph_driver retval = 1; +xpt_lock_buses(); for (periph = (start_periph ? start_periph : TAILQ_FIRST(&(*pdrv)->units)); periph != NULL; periph = next_periph) { @@ -2145,9 +2146,12 @@ xptpdperiphtraverse(struct periph_driver next_periph = TAILQ_NEXT(periph, unit_links); retval = tr_func(periph, arg); -if (retval == 0) +if (retval == 0) { +xpt_unlock_buses(); return(retval); +} } +xpt_unlock_buses(); return(retval); } With a kernel built from /head when "cdrecord -scanbus" runs, an instant mutex recursion & panic happens at... Unread portion of the kernel message buffer: panic: _mtx_lock_sleep: recursed on non-recursive mutex XPT topology lock @ /usr/src/sys/cam/cam_xpt.c:4814 cpuid = 0 Uptime: 12m51s Physical memory: 3034 MB Dumping 178 MB: 163 147 131 115 99 83 67 51 35 19 3 Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/crypto.ko...Reading symbols from /boot/kernel/crypto.ko.symbols...done. done. Loaded symbols for /boot/kernel/crypto.ko Reading symbols from /boot/kernel/zlib.ko...Reading symbols from /boot/kernel/zlib.ko.symbols...done. done. Loaded symbols for /boot/kernel/zlib.ko Reading symbols from /boot/kernel/if_iwn.ko...Reading symbols from /boot/kernel/if_iwn.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_iwn.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_ibm.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/snake_saver.ko...Reading symbols from /boot/kernel/snake_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/snake_saver.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0x8068f66e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0x8068f942 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0x8067fe2a in _mtx_lock_sleep (m=0x80a83c98, tid=2272695552, opts=0, file=0x809b2014 "/usr/src/sys/cam/cam_xpt.c", line=4814) at /usr/src/sys/kern/kern_mutex.c:341 #4 0x80680047 in _mtx_lock_flags (m=0x80a83c98, opts=0, file=0x809b2014 "/usr/src/sys/cam/cam_xpt.c", line=4814) at /usr/src/sys/kern/kern_mutex.c:203 #5 0x8046abaa in xpt_lock_buses () at /usr/src/sys/cam/cam_xpt.c:4814 #6 0x8046ac14 in xptpdperiphtraverse (pdrv=0x86649640, start_periph=0x0, tr_func=0x8046b8b0 , arg=0x87682000) at /usr/src/sys/cam/cam_xpt.c:2151 #7 0x8046acd8 in xptplistpdrvfunc (pdrv=0x86649640, arg=0x87682000) at /usr/src/sys/cam/cam_xpt.c:1840 #8 0x8046a88c in xptpdrvtraverse (start_pdrv=Variable "start_pdrv" is not available. ) at /usr/src/sys/cam/cam_xpt.c:2132 #9 0x8047062c in xpt_action_default (start_ccb=0x87682000) at /usr/src/sys/cam/cam_xpt.c:1967 #10 0x8046a9b2 in xpt_action (start_ccb=0x87682000) at /usr/src/sys/cam/cam_xpt.c:2331 #11 0x8046ca36 in xptioctl (dev=0x87214e00, cmd=3294893314, addr=0x87682000 "\177\004", flag=3, td=0x87769500) at /usr/src/sys/cam/cam_xpt.c:598 #12 0x8060f6b8 in devfs_ioctl_f (fp=0x877bb8c0, com=3294893314, data=0x87682000, cred=0x872ad780, td=0x87769500) at /usr/src/sys/fs/devfs/devfs_vnops.c:669 #13 0x806dab5d in kern_ioctl (td=0x87769500, fd=3, com=3294893314, data=0x87682000 "\177\004") at file.h:254 #14 0x806dace4 in ioctl (td=0x87769500, uap=0x9aa55cec) at /usr/src/sys/kern/sys_generic.c:678 #15 0x806cff26 in syscallenter (td=0x87769500, sa=0x9aa55ce4) at /usr/src/sys/kern/subr_trap.c:314 #16 0x80953964 in syscall (frame=0x9aa55d28) at /usr/src/sys/i386/i386/trap.c:1060 #17
Re: Patch for rc.d/devd on FreeBSD 9-current
On Mon, 28 Jun 2010, Garrett Cooper wrote: On Sat, Jun 26, 2010 at 10:50 PM, Doug Barton wrote: On 06/26/10 13:29, Hans Petter Selasky wrote: Hi, Sometimes utilities that are started by devd require libraries outside /usr/lib. One example is the webcamd utility which is started by devd upon USB device insertion. What do you think about the following patch: --- devd (revision 209463) +++ devd (local) @@ -4,7 +4,7 @@ # # PROVIDE: devd -# REQUIRE: netif +# REQUIRE: netif ldconfig # BEFORE: NETWORKING mountcritremote # KEYWORD: nojail shutdown ldconfig requires mountcritremote, so this patch would introduce a circular dependency. Should ldconfig require mountcritlocal instead? The operating theory is that we want to provide robust support for /usr/local not mounted locally. (And yes, I get the irony there.) :) What could be done is a 2-pass ldconfig, as is done for some other services. However if I understood the OP's problem correctly, that may not help here because devd is trying to start something that is in /usr/local. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
On Sat, Jun 26, 2010 at 10:50 PM, Doug Barton wrote: > On 06/26/10 13:29, Hans Petter Selasky wrote: >> Hi, >> >> Sometimes utilities that are started by devd require libraries outside >> /usr/lib. One example is the webcamd utility which is started by devd upon >> USB >> device insertion. What do you think about the following patch: >> >> --- devd (revision 209463) >> +++ devd (local) >> @@ -4,7 +4,7 @@ >> # >> >> # PROVIDE: devd >> -# REQUIRE: netif >> +# REQUIRE: netif ldconfig >> # BEFORE: NETWORKING mountcritremote >> # KEYWORD: nojail shutdown > > ldconfig requires mountcritremote, so this patch would introduce a > circular dependency. Should ldconfig require mountcritlocal instead? Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
2010/6/28 Dag-Erling Smørgrav : > Garrett Cooper writes: >> It leaves stray unused lockfiles in the directory: > > That's normal and harmless. Yeah.. it's just a bit messy :D. Thanks for the help! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
Garrett Cooper writes: > It leaves stray unused lockfiles in the directory: That's normal and harmless. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in deadlkres
2010/6/28 John Baldwin : > On Friday 25 June 2010 4:52:22 pm pluknet wrote: >> On 25 June 2010 13:50, Anton Yuzhaninov wrote: >> > I've got panic on 9-current from Jun 25 2010 >> > >> > May be this is bug in deadlock resolver >> > >> > panic: blockable sleep lock (sleep mutex) process lock @ >> > /usr/src/sys/kern/kern_clock.c:203 >> > >> > db> show alllocks >> > Process 0 (kernel) thread 0xc4dcd270 (100047) >> > shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @ >> > /usr/src/sys/kern/kern_clock.c:193 >> > >> > db> show lock 0xc4dcd270 >> > class: spin mutex >> > name: D >> > flags: {SPIN, RECURSE} >> > state: {OWNED} >> > >> > (kgdb) bt >> > #0 doadump () at pcpu.h:248 >> > #1 0xc05ae59f in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:416 >> > #2 0xc05ae825 in panic (fmt=Variable "fmt" is not available. >> > ) at /usr/src/sys/kern/kern_shutdown.c:590 >> > #3 0xc048ff45 in db_panic (addr=Could not find the frame base for > "db_panic". >> > ) at /usr/src/sys/ddb/db_command.c:478 >> > #4 0xc0490533 in db_command (last_cmdp=0xc086ef1c, cmd_table=0x0, > dopager=1) at /usr/src/sys/ddb/db_command.c:445 >> > #5 0xc0490662 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 >> > #6 0xc04923ef in db_trap (type=3, code=0) at > /usr/src/sys/ddb/db_main.c:229 >> > #7 0xc05dade6 in kdb_trap (type=3, code=0, tf=0xc4b31bd0) at > /usr/src/sys/kern/subr_kdb.c:535 >> > #8 0xc078696b in trap (frame=0xc4b31bd0) at > /usr/src/sys/i386/i386/trap.c:692 >> > #9 0xc076ca0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 >> > #10 0xc05daf30 in kdb_enter (why=0xc07ea02d "panic", msg=0xc07ea02d > "panic") at cpufunc.h:71 >> > #11 0xc05ae806 in panic (fmt=0xc07efd94 "blockable sleep lock (%s) %s @ > %s:%d") at /usr/src/sys/kern/kern_shutdown.c:573 >> > #12 0xc05ee30b in witness_checkorder (lock=0xc5148088, flags=9, > file=0xc07e3b20 "/usr/src/sys/kern/kern_clock.c", line=203, interlock=0x0) >> > at /usr/src/sys/kern/subr_witness.c:1067 >> > #13 0xc05a093c in _mtx_lock_flags (m=0xc5148088, opts=0, file=0xc07e3b20 > "/usr/src/sys/kern/kern_clock.c", line=203) >> > at /usr/src/sys/kern/kern_mutex.c:200 >> > #14 0xc05706a9 in deadlkres () at /usr/src/sys/kern/kern_clock.c:203 >> > #15 0xc0588721 in fork_exit (callout=0xc05705ea , arg=0x0, > frame=0xc4b31d38) at /usr/src/sys/kern/kern_fork.c:843 >> > #16 0xc076ca80 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:270 >> >> Hi! >> >> [throw in ideas (just ignore them if they're dumb, thinking badly atm).] >> >> AFAIK, that indicates that some thread already has >> a spin mutex and then it tries to acquire a sleep mutex. >> >> Looks like kern/kern_clock.c v1.213 (SVN rev 206482) >> has a regression in handling ticks wrap-up >> w.r.t. it doesn't release a thread mutex, does it? > > This looks like a correct analysis to me. > >> >From subr_witness.c: >> 1062: * Since spin locks include a critical section, this > check >> 1063: * implicitly enforces a lock order of all sleep >> locks before >> 1064: * all spin locks. >> 1065: */ >> 1066: if (td->td_critnest != 0 && !kdb_active) >> 1067: panic("blockable sleep lock (%s) %s @ %s:%d", >> 1068: class->lc_name, lock->lo_name, file, line); >> >> >From kern_clock.c, v1.213 (in several places, while holding a thread lock): >> + /* Handle ticks wrap-up. */ >> + if (ticks < td->td_blktick) >> + continue; >> >> Should not it be like the next: >> + /* Handle ticks wrap-up. */ >> + if (ticks < td->td_blktick) { >> + thread_unlock(td); >> + continue; >> + } >> >> The precondition idea to reproduce it is to lock a subject thread >> in some deadlkres callout, handle re-wrap condition, then try >> to lock a process to witch the thread belongs in (n+m)'th deadlkres >> callout, or in different context. Thanks, that may be fixed in r209577. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: Garrett Cooper writes: : > This patch is wrong. The problems with it: : > : > (1) You don't need to unlink the pipe. If you can't unlink it, then : > you won't remove the pid file. : : The reason why my previous patch deleted `PIPE' file was because it's : not a true pipe, but instead a named file in the filesystem, as that : never gets cleaned up otherwise (please see my latest post). That's Ok. The problem is elsewhere. The PIPE should not be deleted, since that introduces races with other programs wishing to listen to the pipe. : > (2) If devd dies suddenly (kill -9, segv, etc), then the pid file will : > remain around, and devd will fail to start. : : Correct. Not quite. The pid file doesn't prevent devd starting. The lock on the pid file does. Why is the pid file still locked? Is locking broken in current? (no, it isn't: all relevant regression tests pass) What is the root cause then? For me, devd refused to start because it exec'd dhclient. dhclient survived having devd die. devd didn't close the lock file fd, so dhclient inherited it. My first knee-jerk reaction was 'why isn't that close on exec?' That's a good question, the short answer of which is 'because there are times you don't want it to be.' But even that's not the root cause. Why is devd using system(3) to execute commands? Why isn't it taking more care to create a cleaner environment for commands to execute in? why isn't it following the advice in the pidfile_close man page? These are all good questions. Also, why do the child processes get an fd to read the stream of events from the kernel on? Isn't that an information leak? So, I've copied system and added the proper calls to clean all this up. Sadly, this only addresses the complaint that Garrett brought up. It doesn't address the legitimate concerns that Hans has about startup sequence and races with mounting /usr/local. That's a very good question, indeed. You want to defer some actions until other services are available. In a launchd world, you fork and run the processes. They use whatever resources they need, but block on resources that haven't finished starting yet. That's one possible solution here, but outside the scope of devd, I'm afraid... Warner Index: devd.hh === --- devd.hh (revision 209492) +++ devd.hh (working copy) @@ -153,6 +153,7 @@ void set_pidfile(const char *); void reset(); void parse(); + void close_pidfile(); void open_pidfile(); void write_pidfile(); void remove_pidfile(); Index: devd.cc === --- devd.cc (revision 209492) +++ devd.cc (working copy) @@ -41,6 +41,7 @@ #include #include #include +#include #include #include @@ -49,6 +50,7 @@ #include #include #include +#include #include #include #include @@ -152,13 +154,67 @@ // nothing } +static int +my_system(const char *command) +{ + pid_t pid, savedpid; + int pstat; + struct sigaction ign, intact, quitact; + sigset_t newsigblock, oldsigblock; + + if (!command) /* just checking... */ + return(1); + + /* +* Ignore SIGINT and SIGQUIT, block SIGCHLD. Remember to save +* existing signal dispositions. +*/ + ign.sa_handler = SIG_IGN; + ::sigemptyset(&ign.sa_mask); + ign.sa_flags = 0; + ::sigaction(SIGINT, &ign, &intact); + ::sigaction(SIGQUIT, &ign, &quitact); + ::sigemptyset(&newsigblock); + ::sigaddset(&newsigblock, SIGCHLD); + ::sigprocmask(SIG_BLOCK, &newsigblock, &oldsigblock); + switch(pid = ::fork()) { + case -1:/* error */ + break; + case 0: /* child */ + /* +* Restore original signal dispositions and exec the command. +*/ + ::sigaction(SIGINT, &intact, NULL); + ::sigaction(SIGQUIT, &quitact, NULL); + ::sigprocmask(SIG_SETMASK, &oldsigblock, NULL); + /* +* Close the PID file, and all other open descriptors. +* Inherit std{in,out,err} only. +*/ + cfg.close_pidfile(); + ::closefrom(3); + ::execl(_PATH_BSHELL, "sh", "-c", command, (char *)NULL); + ::_exit(127); + default:/* parent */ + savedpid = pid; + do { + pid = ::wait4(savedpid, &pstat, 0, (struct rusage *)0); + } while (pid == -1 && errno == EINTR); + break; + } + ::sigaction(SIGINT, &intact, NULL); + ::sigaction(SIGQUIT, &quitact, NULL); + ::sigprocmask(SIG_SETMASK, &oldsigblock, NULL); + return(pid == -1 ? -1 : pstat
Re: Patch for rc.d/devd on FreeBSD 9-current
On Sun, Jun 27, 2010 at 3:08 PM, M. Warner Losh wrote: > In message: > Garrett Cooper writes: > : On Sat, Jun 26, 2010 at 1:45 PM, Garrett Cooper wrote: > : > On Sat, Jun 26, 2010 at 1:29 PM, Hans Petter Selasky > wrote: > : >> Hi, > : >> > : >> Sometimes utilities that are started by devd require libraries outside > : >> /usr/lib. One example is the webcamd utility which is started by devd > upon USB > : >> device insertion. What do you think about the following patch: > : >> > : >> --- devd (revision 209463) > : >> +++ devd (local) > : >> @@ -4,7 +4,7 @@ > : >> # > : >> > : >> # PROVIDE: devd > : >> -# REQUIRE: netif > : >> +# REQUIRE: netif ldconfig > : >> # BEFORE: NETWORKING mountcritremote > : >> # KEYWORD: nojail shutdown > : > > : > Funny since I was just monkeying around with this. This doesn't appear > : > to be the only issue with devd: > : > > : > # devd > : > devd: devd already running, pid: 430 > : > # pgrep 430; echo $? > : > 1 > : > # > : > > : > Looks like /etc/rc.d/devd restart is broken :(... > : > : This seems to fix that. > : Thanks, > : -Garrett > : > : Index: devd.cc > : === > : --- devd.cc (revision 209530) > : +++ devd.cc (working copy) > : @@ -739,6 +739,7 @@ > : static void > : event_loop(void) > : { > : + bool warn_user_about_cleanup; > : int rv; > : int fd; > : char buffer[DEVCTL_MAXBUF]; > : @@ -804,6 +805,17 @@ > : new_client(server_fd); > : } > : close(fd); > : + close(server_fd); > : + > : + if (unlink(PIPE) == 0) { > : + cfg.remove_pidfile(); > : + warn_user_about_cleanup = false; > : + } else > : + warn_user_about_cleanup = true; > : + > : + if (warn_user_about_cleanup == true) > : + warn("cleanup failed"); > : + > : } > : > : /* > > This patch is wrong. The problems with it: > > (1) You don't need to unlink the pipe. If you can't unlink it, then > you won't remove the pid file. The reason why my previous patch deleted `PIPE' file was because it's not a true pipe, but instead a named file in the filesystem, as that never gets cleaned up otherwise (please see my latest post). > (2) If devd dies suddenly (kill -9, segv, etc), then the pid file will > remain around, and devd will fail to start. Correct. > (3) i_really_do_not_like_names_this_long_esp_when_they_are_not_needed. Fair enough :D. > The following works around the bug in pidfile_open, and allows me to > restart devd both in a nice shutdown mode, as well as preventing devd > from running multiple times. I'm not 100% sure the error handling is > right, I'm still tracing through that path. This seems to work. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
2010/6/28 Dag-Erling Smørgrav : > "M. Warner Losh" writes: >> Dag-Erling Smørgrav writes: >> > "M. Warner Losh" writes: >> > > Maybe the real problem is that devd locks the file, then dies. The >> > > file remains locked, so the flopen is failing with EWOULDBLOCK. >> > The lock is released when the process that holds it terminates. >> So which process is that? devd took it out, and is subsequently >> killed. When it restarts, it can't take out the lock. > > What does fstat say about the pid file? > >> The same code works perfectly in 8.0-stable from April. >> >> The conclusion, I believe, is that somebody broke locking in >> current... > > Before I wrote one of my earlier replies, I traced through the code > paths that lead to a lock being released, and everything looks fine and > dandy. Besides, if someone had, as you suggest, broken locking in > current, there would be a lot more noise about it on the lists. Hi DES, When I do the following: /etc/rc.d/devd start /etc/rc.d/devd stop It leaves stray unused lockfiles in the directory: $ sudo /etc/rc.d/devd start Starting devd. $ ls -l /var/run/devd.pi* -rw--- 1 root wheel 5 Jun 28 09:53 /var/run/devd.pid srw-rw-rw- 1 root wheel 0 Jun 28 09:53 /var/run/devd.pipe $ fstat /var/run/devd.pi* USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root devd 297916 /var 447511 -rw--- 5 w /var/run/devd.pid $ sudo /etc/rc.d/devd stop Stopping devd. $ ls -l /var/run/devd.pi* -rw--- 1 root wheel 5 Jun 28 09:52 /var/run/devd.pid srw-rw-rw- 1 root wheel 0 Jun 28 09:52 /var/run/devd.pipe $ fstat /var/run/devd.pi* USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
Anton Shterenlikht writes: > I think this only happens when I copy from one xterm to another, > to paste into the mailer. I've checked the command which > I put in a file, and all seems fine. Also, the latest > error message suggests that the command is fine: OK, can you do it again with -Wl,--verbose in addition to -v? Like this: cc -static -v -Wl,--verbose -o rescue ... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[sparc64] [panic] cheetah_ipi_selected: CPU can't IPI itself
Well, I'm back in the same town as my sparc64 and so csup'd, built, and rebooted, trying to get more information about the "vm object not owned" panic I reported a while ago. To my dismay, I now get this panic, also late enough in the boot process to be starting up jails: panic: cheetah_ipi_selected: CPU can't IPI itself cpuid = 0 KDB: stack backtrace: panic() at panic+0x1c8 cheetah_ipi_selected() at cheetah_ipi_selected+0x48 tlb_page_demap() at tlb_page_demap+0xdc pmap_copy_page() at pmap_copy_page+0x4c4 vm_fault() at vm_fault+0x13ec trap_pfault() at trap_pfault+0x190 trap() at trap+0xd0 -- data access protection tar=0x224b93 sfar=0x224550 sfsr=0x85 %o7=0x4063398c -- userland() at 0x40633830 user trace: trap %o7=0x4063398c ... And the system hangs; I had to use the ALOM to reboot it. Sorry to not have more useful news. --nwf; pgpdTuFjRko2M.pgp Description: PGP signature
Re: panic in deadlkres
On Friday 25 June 2010 4:52:22 pm pluknet wrote: > On 25 June 2010 13:50, Anton Yuzhaninov wrote: > > I've got panic on 9-current from Jun 25 2010 > > > > May be this is bug in deadlock resolver > > > > panic: blockable sleep lock (sleep mutex) process lock @ > > /usr/src/sys/kern/kern_clock.c:203 > > > > db> show alllocks > > Process 0 (kernel) thread 0xc4dcd270 (100047) > > shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @ > > /usr/src/sys/kern/kern_clock.c:193 > > > > db> show lock 0xc4dcd270 > > class: spin mutex > > name: D > > flags: {SPIN, RECURSE} > > state: {OWNED} > > > > (kgdb) bt > > #0 doadump () at pcpu.h:248 > > #1 0xc05ae59f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 > > #2 0xc05ae825 in panic (fmt=Variable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:590 > > #3 0xc048ff45 in db_panic (addr=Could not find the frame base for "db_panic". > > ) at /usr/src/sys/ddb/db_command.c:478 > > #4 0xc0490533 in db_command (last_cmdp=0xc086ef1c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 > > #5 0xc0490662 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > > #6 0xc04923ef in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229 > > #7 0xc05dade6 in kdb_trap (type=3, code=0, tf=0xc4b31bd0) at /usr/src/sys/kern/subr_kdb.c:535 > > #8 0xc078696b in trap (frame=0xc4b31bd0) at /usr/src/sys/i386/i386/trap.c:692 > > #9 0xc076ca0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > > #10 0xc05daf30 in kdb_enter (why=0xc07ea02d "panic", msg=0xc07ea02d "panic") at cpufunc.h:71 > > #11 0xc05ae806 in panic (fmt=0xc07efd94 "blockable sleep lock (%s) %s @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:573 > > #12 0xc05ee30b in witness_checkorder (lock=0xc5148088, flags=9, file=0xc07e3b20 "/usr/src/sys/kern/kern_clock.c", line=203, interlock=0x0) > >at /usr/src/sys/kern/subr_witness.c:1067 > > #13 0xc05a093c in _mtx_lock_flags (m=0xc5148088, opts=0, file=0xc07e3b20 "/usr/src/sys/kern/kern_clock.c", line=203) > >at /usr/src/sys/kern/kern_mutex.c:200 > > #14 0xc05706a9 in deadlkres () at /usr/src/sys/kern/kern_clock.c:203 > > #15 0xc0588721 in fork_exit (callout=0xc05705ea , arg=0x0, frame=0xc4b31d38) at /usr/src/sys/kern/kern_fork.c:843 > > #16 0xc076ca80 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 > > Hi! > > [throw in ideas (just ignore them if they're dumb, thinking badly atm).] > > AFAIK, that indicates that some thread already has > a spin mutex and then it tries to acquire a sleep mutex. > > Looks like kern/kern_clock.c v1.213 (SVN rev 206482) > has a regression in handling ticks wrap-up > w.r.t. it doesn't release a thread mutex, does it? This looks like a correct analysis to me. > >From subr_witness.c: > 1062: * Since spin locks include a critical section, this check > 1063: * implicitly enforces a lock order of all sleep > locks before > 1064: * all spin locks. > 1065: */ > 1066:if (td->td_critnest != 0 && !kdb_active) > 1067:panic("blockable sleep lock (%s) %s @ %s:%d", > 1068:class->lc_name, lock->lo_name, file, line); > > >From kern_clock.c, v1.213 (in several places, while holding a thread lock): > + /* Handle ticks wrap-up. */ > + if (ticks < td->td_blktick) > + continue; > > Should not it be like the next: > + /* Handle ticks wrap-up. */ > + if (ticks < td->td_blktick) { > + thread_unlock(td); > + continue; > + } > > The precondition idea to reproduce it is to lock a subject thread > in some deadlkres callout, handle re-wrap condition, then try > to lock a process to witch the thread belongs in (n+m)'th deadlkres > callout, or in different context. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic with zfs v16 patch
On 06/28/10 17:20, Sam Fourman Jr. wrote: > On Mon, Jun 28, 2010 at 9:43 AM, Sam Fourman Jr. wrote: >>> Curious - this panic is UFS softdep-related - possibly from the SUJ work? >>> >>> On which file system type is your ports tree? >> >> ufs2 > > it seems ivan may be correct, I went and tried to continue the subversion > build > > I received this panic, while downloading a file (I was doing nothing > with ZFS at all this time) > > ===> License check disabled, port has not defined LICENSE > ===> Found saved configuration for postgresql-client-8.2.17_1 > => postgresql-8.2.17.tar.bz2 doesn't seem to exist in > /usr/ports/distfiles/postgresql. > => Attempting to fetch from > ftp://ftp9.us.postgresql.org/pub/mirrors/postgresql/source/v8.2.17/. > postgresql-8.2.17.tar.bz2 52% of 12 MB 855 kBps > > > http://www.puffybsd.com/img_3997.jpg > http://www.puffybsd.com/img_3999.jpg > > > any other useful data I can gather? READ_DMA and WRITE_DMA errors usually indicate that your disk has bad sectors or has become broken, but you have so many of them on multiple drives (ad4, ad8, ad10), which might mean your disk controller is dying or you have really bad cabling in the machine. You might try using something like # dd if=/dev/ad8 of=/dev/null bs=1m to see if you can reliably provoke errors on the same part of the disk - if not, there is certainly a problem with the controller or cabling; if yes, it can also be a disk problem. In any case, it looks like your problem is not related to any file system code. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On Mon, Jun 28, 2010 at 03:58:35PM +0200, Dag-Erling Smørgrav wrote: > Anton Shterenlikht writes: > > cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo > > date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo > > kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo ealpath.lo rm.lo > > rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo > > atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo > > dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs. o fsck_msdosfs.lo > > fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo > > kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo > > mknod.lo mount.lo mount_cd9660.lo mount_msd sfs.lo mount_nfs.lo > > mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo > > newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo > > routed.lo rtquery.lo rtsol.lo savecore.l spppcontrol.lo swapon.lo > > sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo > > mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo > > xz.lo tar.lo vi.lo id.lo chr > oot lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o > /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o > /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o > /usr/obj/usr/src/rescue/ escue/../librescue/popen.o > /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o > /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o > /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lk m -ll > -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs > -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf > -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm > > Look again, your command line is mangled. For instance, the "r" in > "realpath.lo" is missing and the "l" in "fsck_ffs.lo" has been replaced > with a space. I think this only happens when I copy from one xterm to another, to paste into the mailer. I've checked the command which I put in a file, and all seems fine. Also, the latest error message suggests that the command is fine: # cat /usr/src/rescue/rescue/zzz cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo ealpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs. o fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msd sfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.l spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/ escue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lk m -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm # sh < /usr/src/rescue/rescue/zzz Using built-in specs. Target: ia64-undermydesk-freebsd Configured with: FreeBSD/ia64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] /usr/obj/usr/src/tmp/usr/bin/ld -Bstatic -o rescue /usr/obj/usr/src/tmp/usr/lib/crt1.o /usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbeginT.o -L/usr/local/lib -L/usr/local/lib -L/us /obj/usr/src/tmp/usr/lib -L/usr/obj/usr/src/tmp/usr/lib rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpf .lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mo nt.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mo
Re: panic with zfs v16 patch
On Mon, Jun 28, 2010 at 9:43 AM, Sam Fourman Jr. wrote: >> Curious - this panic is UFS softdep-related - possibly from the SUJ work? >> >> On which file system type is your ports tree? > > ufs2 it seems ivan may be correct, I went and tried to continue the subversion build I received this panic, while downloading a file (I was doing nothing with ZFS at all this time) ===> License check disabled, port has not defined LICENSE ===> Found saved configuration for postgresql-client-8.2.17_1 => postgresql-8.2.17.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/postgresql. => Attempting to fetch from ftp://ftp9.us.postgresql.org/pub/mirrors/postgresql/source/v8.2.17/. postgresql-8.2.17.tar.bz2 52% of 12 MB 855 kBps http://www.puffybsd.com/img_3997.jpg http://www.puffybsd.com/img_3999.jpg any other useful data I can gather? > -- > > Sam Fourman Jr. > Fourman Networks > http://www.fourmannetworks.com > -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic with zfs v16 patch
> Curious - this panic is UFS softdep-related - possibly from the SUJ work? > > On which file system type is your ports tree? ufs2 -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
"M. Warner Losh" writes: > Dag-Erling Smørgrav writes: > > "M. Warner Losh" writes: > > > Maybe the real problem is that devd locks the file, then dies. The > > > file remains locked, so the flopen is failing with EWOULDBLOCK. > > The lock is released when the process that holds it terminates. > So which process is that? devd took it out, and is subsequently > killed. When it restarts, it can't take out the lock. What does fstat say about the pid file? > The same code works perfectly in 8.0-stable from April. > > The conclusion, I believe, is that somebody broke locking in > current... Before I wrote one of my earlier replies, I traced through the code paths that lead to a lock being released, and everything looks fine and dandy. Besides, if someone had, as you suggest, broken locking in current, there would be a lot more noise about it on the lists. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: Garrett Cooper writes: : On Sun, Jun 27, 2010 at 3:08 PM, M. Warner Losh wrote: : > In message: : > Garrett Cooper writes: : > : On Sat, Jun 26, 2010 at 1:45 PM, Garrett Cooper wrote: : > : > On Sat, Jun 26, 2010 at 1:29 PM, Hans Petter Selasky wrote: : > : >> Hi, : > : >> : > : >> Sometimes utilities that are started by devd require libraries outside : > : >> /usr/lib. One example is the webcamd utility which is started by devd upon USB : > : >> device insertion. What do you think about the following patch: : > : >> : > : >> --- devd (revision 209463) : > : >> +++ devd (local) : > : >> @@ -4,7 +4,7 @@ : > : >> # : > : >> : > : >> # PROVIDE: devd : > : >> -# REQUIRE: netif : > : >> +# REQUIRE: netif ldconfig : > : >> # BEFORE: NETWORKING mountcritremote : > : >> # KEYWORD: nojail shutdown : > : > : > : > Funny since I was just monkeying around with this. This doesn't appear : > : > to be the only issue with devd: : > : > : > : > # devd : > : > devd: devd already running, pid: 430 : > : > # pgrep 430; echo $? : > : > 1 : > : > # : > : > : > : > Looks like /etc/rc.d/devd restart is broken :(... : > : : > : This seems to fix that. : > : Thanks, : > : -Garrett : > : : > : Index: devd.cc : > : === : > : --- devd.cc (revision 209530) : > : +++ devd.cc (working copy) : > : @@ -739,6 +739,7 @@ : > : static void : > : event_loop(void) : > : { : > : + bool warn_user_about_cleanup; : > : int rv; : > : int fd; : > : char buffer[DEVCTL_MAXBUF]; : > : @@ -804,6 +805,17 @@ : > : new_client(server_fd); : > : } : > : close(fd); : > : + close(server_fd); : > : + : > : + if (unlink(PIPE) == 0) { : > : + cfg.remove_pidfile(); : > : + warn_user_about_cleanup = false; : > : + } else : > : + warn_user_about_cleanup = true; : > : + : > : + if (warn_user_about_cleanup == true) : > : + warn("cleanup failed"); : > : + : > : } : > : : > : /* : > : > This patch is wrong. The problems with it: : > : > (1) You don't need to unlink the pipe. If you can't unlink it, then : > you won't remove the pid file. : > (2) If devd dies suddenly (kill -9, segv, etc), then the pid file will : > remain around, and devd will fail to start. : > (3) i_really_do_not_like_names_this_long_esp_when_they_are_not_needed. : > : > The following works around the bug in pidfile_open, and allows me to : > restart devd both in a nice shutdown mode, as well as preventing devd : > from running multiple times. I'm not 100% sure the error handling is : > right, I'm still tracing through that path. This seems to work. : > : > Warner : > : > Index: devd.cc : > === : > --- devd.cc (revision 209492) : > +++ devd.cc (working copy) : > @@ -376,11 +376,18 @@ : > if (_pidfile == "") : > return; : > pfh = pidfile_open(_pidfile.c_str(), 0600, &otherpid); : > - if (pfh == NULL) { : > - if (errno == EEXIST) : > + if (pfh != NULL) : > + return; : > + if (errno == EEXIST) { : > + /* : > + * Work around a bug in libutil where it will return this : > + * condition when the other process does not, in fact, : > + * actually exist. Use kill(2) to see if it is there or not. : > + */ : > + if (kill(otherpid, 0) == 0) : > errx(1, "devd already running, pid: %d", (int)otherpid); : > + } else : > warn("cannot open pid file"); : > - } : > } : > : > void : > @@ -804,6 +811,8 @@ : > new_client(server_fd); : > } : > close(fd); : > + close(server_fd); : > + cfg.remove_pidfile(); : > } : : I see what you mean. pidfile_open obviously fails with this requirement: : : If a file can not be locked, a PID of an already running daemon is returned : in the pidptr argument (if it is not NULL). The function does not write : process' PID into the file here, so it can be used before : fork()ing and exit : with a proper error message when needed. If the path argument is NULL, : /var/run/.pid file will be used. : : The problem I think is that the flopen arguments are wrong -- it passes in : O_TRUNC, instead of checking whether or not the file exists beforehand, and : then attempt to read in the file (if it exists) to determine whether : or not the PID is alive. Apart from tidiness, my patch is bogus. The real problem is flock() seems to be failing now. Tests of my 8.0-stable system from April shows that it works there. Likewise, my -current system from Jan 21st appears to work. Time to start the binary search. Warner ___ freebsd-current@fr
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: <86iq537egy@ds4.des.no> Dag-Erling Smørgrav writes: : "M. Warner Losh" writes: : > Maybe the real problem is that devd locks the file, then dies. The : > file remains locked, so the flopen is failing with EWOULDBLOCK. : : The lock is released when the process that holds it terminates. So which process is that? devd took it out, and is subsequently killed. When it restarts, it can't take out the lock. The same code works perfectly in 8.0-stable from April. The conclusion, I believe, is that somebody broke locking in current... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: <86mxuf7eli@ds4.des.no> Dag-Erling Smørgrav writes: : "M. Warner Losh" writes: : > Why not fix pidfile_open to not return a file handle when the PID : > doesn't match? : : It doesn't. If it can't lock the file, or if fstat(2) fails after it : has locked the file, it returns NULL. Then we have a bug in the locking code. I've definitely seen things fail to behave properly after killing devd. Let me trace out what I think is going on: From pidfile_open: /* * Open the PID file and obtain exclusive lock. * We truncate PID file here only to remove old PID immediatelly, * PID file will be truncated again in pidfile_write(), so * pidfile_write() can be called multiple times. */ fd = flopen(pfh->pf_path, O_WRONLY | O_CREAT | O_TRUNC | O_NONBLOCK, mode); if (fd == -1) { ---> We take this path, fd == -1. count = 0; rqtp.tv_sec = 0; rqtp.tv_nsec = 500; if (errno == EWOULDBLOCK && pidptr != NULL) { again: ---> and this one, so errno is EWOULDBLOCK errno = pidfile_read(pfh->pf_path, pidptr); ---> errno is 0 here, so if (errno == 0) errno = EEXIST; ---> We return NULL with errno set toEEXIST else if (errno == EAGAIN) { if (++count <= 3) { nanosleep(&rqtp, 0); goto again; } } } free(pfh); return (NULL); } So what's going on? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
Anton Shterenlikht writes: > cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo > date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo > kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo ealpath.lo rm.lo > rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo > badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo > dumpfs.lo dumpon.lo fsck.lo fsck_ffs. o fsck_msdosfs.lo fsdb.lo fsirand.lo > gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo > kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo > mount_cd9660.lo mount_msd sfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo > mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo > reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo > savecore.l spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo > atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo > sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot lo > chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o > /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o > /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o > /usr/obj/usr/src/rescue/ escue/../librescue/popen.o > /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o > /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o > /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lk m -ll > -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs > -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf > -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm Look again, your command line is mangled. For instance, the "r" in "realpath.lo" is missing and the "l" in "fsck_ffs.lo" has been replaced with a space. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On Mon, Jun 28, 2010 at 02:38:10PM +0200, Dag-Erling Smørgrav wrote: > Anton Shterenlikht writes: > > # cc -v -static -o rescue [...] > > cc: cat.lo: No such file or directory > > Umm, try again from the object directory, /usr/obj/usr/src/rescue/rescue/ that's better: # cd /usr/src/ # make buildenv Entering world for ia64:ia64 # cd /usr/obj/usr/src/rescue/rescue # pwd /usr/obj/usr/src/rescue/rescue # cat /usr/src/rescue/rescue/zzz cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo ealpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs. o fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msd sfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.l spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/ escue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lk m -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm # sh < /usr/src/rescue/rescue/zzz Using built-in specs. Target: ia64-undermydesk-freebsd Configured with: FreeBSD/ia64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] /usr/obj/usr/src/tmp/usr/bin/ld -Bstatic -o rescue /usr/obj/usr/src/tmp/usr/lib/crt1.o /usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbeginT.o -L/usr/local/lib -L/usr/local/lib -L/us /obj/usr/src/tmp/usr/lib -L/usr/obj/usr/src/tmp/usr/lib rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpf .lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mo nt.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.l rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_ lass.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../libre cue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -l zma -larchive -lcrypto -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/obj/usr/src/tmp/usr/lib/crtend.o /usr/obj/usr/src/tmp/usr/lib/crtn.o xz.lo(.text+0x5202): In function `hardware_init': : undefined reference to `lzma_physmem' > > > # /usr/obj/usr/src/rescue/rescue/../librescue/exec.o: Permission > > denied > > That's weird, can you check the ownership of that file? Did you run > buildworld as root and buildenv as a regular user? # ls -al /usr/obj/usr/src/rescue/rescue/../librescue/exec.o -rw-r--r-- 1 root wheel 8256 28 Jun 11:57 /usr/obj/usr/src/rescue/rescue/../librescue/exec.o # no, both buildworld and buildenv are run as root. thank you anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
Anton Shterenlikht writes: > # cc -v -static -o rescue [...] > cc: cat.lo: No such file or directory Umm, try again from the object directory, /usr/obj/usr/src/rescue/rescue/ > # /usr/obj/usr/src/rescue/rescue/../librescue/exec.o: Permission > denied That's weird, can you check the ownership of that file? Did you run buildworld as root and buildenv as a regular user? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On Fri, Jun 25, 2010 at 11:47:59AM +0200, Dag-Erling Smørgrav wrote: > Anton Shterenlikht writes: > > So, just for me to be clear, I need to proceed with the buildworld, > > until I get the error, and then, without cleaning anything, do > > > > % cd /usr/src > > % make buildenv > > % cd rescue/rescue > > % make > > > > Is that correct? > > Yes. Then you take the cc comand line that failed and run it again with > the -v option and show us the output. ok, sorry, here it is. So starting with a clean src r209203 copy, and with /usr/obj/* wiped, "make -j1 buildworld" ends in cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm xz.lo(.text+0x5202): In function `hardware_init': : undefined reference to `lzma_physmem' Then doing # make buildenv # cd rescue/rescue # make gives what looks like the same error message: cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm xz.lo(.text+0x5202): In function `hardware_init': : undefined reference to `lzma_physmem' Finally repeating the last command with added -v flag gives: # cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo \ dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo \ ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo \ sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo \ ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo \ fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo \ kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo \ > mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo > mount_ntfs.lo \ mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos
Re: panic with zfs v16 patch
On 06/28/10 03:59, Sam Fourman Jr. wrote: > hello list, > > I just had a panic on a FreeBSD 9.0 built with yesterdays sources. > > uname -a > FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Jun 26 09:14:30 CDT > 2010 sfourman@:/usr/obj/usr/src/sys/ZFSv16 amd64 > > GENERIC kernel with this patch > http://people.freebsd.org/~mm/patches/zfs/v16/head-v16-extended.patch > i have a ufs2 boot drive with a separate ZFS pool > > since this was a fresh install of 9-current(specifically to test the > v16 ZFS patches) > > I was doing a zpool import of a 2TB dataset that has ~100 snapshots > it was taking over a hour to import, possibly this zfs bug > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6761786 > > So I decided to build subversion from ports while I waited on zfs import > I got the panic in the following pics > > http://www.puffybsd.com/img_3995.jpg > http://www.puffybsd.com/img_3996.jpg Curious - this panic is UFS softdep-related - possibly from the SUJ work? On which file system type is your ports tree? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Coming back to the btxld: No such file or directory installworld error
On Sun, Jun 27, 2010 at 11:27:41PM -0700, Garrett Cooper wrote: > On Sun, Jun 27, 2010 at 10:54 PM, Ruslan Ermilov wrote: > > On Sun, Jun 27, 2010 at 01:14:59PM -0700, Garrett Cooper wrote: > >> Hi Ruslan, > >> I've run into this particular error twice now in the past couple > >> of weeks when building with -j24 on a memory disk and I was wondering > >> if there was an missing dependency / race somewhere or something > >> (perhaps make obj?): > >> > >> ===> sys/boot/i386/boot2 (install) > >> # ... > >> btxld -v -E 0x2000 -f bin -b > >> /usr/obj/scratch/freebsd/current/sys/boot/i386/boot2/../btx/btx/btx -l > >> boot2.ldr -o boot2.ld -P 1 boot2.bin > >> btxld: No such file or directory > >> *** Error code 1 > > > > The "install" target isn't supposed to build stuff, only install it. > > When you see it trying to build something, this can be indicative of: > > > > - build wasn't run (e.g., after an update); > > Not the case (I ran buildworld and everything else up to that point > installed happily). > > > - a computer's date/time is set to the past (causing wrong date/time > > to be set on output files => causing them to be considered out-of- > > date by make(1)); check with date(1). > > My computer hasn't been time traveling lately :/ ("If my calculations > are correct, when this baby hits eighty-eight miles per hour... you're > gonna see some serious shit."). > > > - source files have modification times pointing to the future which > > fools make(1) into thinking that it should rebuild some target; > > check with "find /usr/src -mtime -0". > > This seems unlikely as well. Did you actually check that? (Date/time on source files can be set by CVSup servers...) > Is there a possibility that the existing Makefiles work by accident > when -j < 24 because the actions aren't executed in order :(? "install" isn't supposed to build stuff. The only exception I could remember of is timezone data files, plus some .db files. I strongly suggest checking the date/time of your computer and source files. If it's really okay, then check the following: run -j24 build, then run "make -C /usr/src/sys/boot -nn" -- if you see that it wants to build something, then this is a problem we should look into and try to fix. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Coming back to the btxld: No such file or directory installworld
On Sun, 2010-06-27 at 13:14 -0700, Garrett Cooper wrote: > Hi Ruslan, > I've run into this particular error twice now in the past couple > of weeks when building with -j24 on a memory disk and I was wondering > if there was an missing dependency / race somewhere or something > (perhaps make obj?): > > ===> sys/boot/i386/boot2 (install) > # ... > btxld -v -E 0x2000 -f bin -b > /usr/obj/scratch/freebsd/current/sys/boot/i386/boot2/../btx/btx/btx -l > boot2.ldr -o boot2.ld -P 1 boot2.bin > btxld: No such file or directory > *** Error code 1 > > Stop in /scratch/freebsd/current/sys/boot/i386/boot2. > *** Error code 1 I've seen this in the last couple of weeks as well. I build with -j3, and the buildworld seemed to go fine. During the installworld (after installkernel and reboot) I saw the same as you see. > Running the make in the respective subdirectories, then rerunning > installworld works. Example: > > btxld -v -E 0x2000 -f bin -b > /usr/obj/scratch/freebsd/current/sys/boot/i386/zfsboot/../btx/btx/btx > -l zfsboot.ldr -o zfsboot.ld -P 1 zfsboot.bin > kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=602c text=0 data=0 bss=0 entry=0 > output: fmt=bin size=66bc text=0 data=66bc org=0 entry=0 > 6468 bytes available > dd if=zfsboot.ld of=zfsboot2 obs=32768 conv=osync > 51+1 records in > 1+0 records out > 32768 bytes transferred in 0.62 secs (528611360 bytes/sec) > cat zfsboot1 zfsboot2 > zfsboot ... and I fixed it in the same way. I'm assuming there's some dependency not listed in a makefile or something, but without the log from buildworld it's hard to find. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] BSDL iconv in base system
Em 2010.06.17. 23:21, Anonymous escreveu: Gabor Kovesdan writes: [...] $ make installworld TARGET=i386 DESTDIR=/b/bbb ... ===> usr.bin/mkcsmapper (install) install -s -o root -g wheel -m 555 mkcsmapper /b/bbb/usr/bin strip: /b/bbb/usr/bin/mkcsmapper: File format not recognized install: wait: No such file or directory *** Error code 70 If cross-compiling doesn't work, how did you build the former one that gave you that error? Here is my guess libiconv_modules compiles fine but installs both normal and lib32 objdir into /usr/lib when lib32 should use /usr/lib32. mkcsmapper/mkesdb are failing to install because they're treated as build-tools for host system and never compiled for target system. However, they're not included in lib32 target and so are not built for i386 arch during normal buildworld on amd64 host where host = target. Just a short update on this... The library part is fixed but I couldn't find out a fix for mk* tools yet. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
Dag-Erling Smørgrav writes: > - Under flock semantics (flock(2) locks), the lock is released when >*all* file descriptors the process holds for that file is closed. are, even, and sorry for the horrid quoting. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Hi again, After my most recent appeal for testers, I received some excellent feedback and thank everyone that has tried the patch. I've ironed out a couple of bugs and have what I hope is the import-ready candidate patch available for a final round of testing. Please read on if you are able and willing to (re)test the code. On 06/19/10 13:27, Lawrence Stewart wrote: Amount of feedback received thus far: nichts, nil, nada *sings "I'm so ronery" in his best Kim Jong-il voice* [4] Just like Uncle Sam [5], Uncle Lawrence needs you too - yes, I'm pointing at YOU! More specifically, people out there running current with 10-15 mins to spare for some testing, please read on. On 06/13/10 18:12, Lawrence Stewart wrote: Hi all, The time has come to solicit some external testing for my SIFTR tool. I'm hoping to commit it within a week or so unless problems are discovered. SIFTR is a kernel module that logs a range of statistics on active TCP connections to a log file. It provides the ability to make highly granular measurements of TCP connection state, aimed at system administrators, developers and researchers. You can use the data to find bugs in the stack, understand why connections are performing badly and test new code to name a few uses. Development has been made possible in part by grants from the Cisco University Research Program Fund at Community Foundation Silicon Valley, and the FreeBSD Foundation. Bringing it into FreeBSD proper is being carried out under the auspices of the "Enhancing the FreeBSD TCP Implementation" FreeBSD Foundation project. More details are available at [1,2,3]. If you can help out, please read on! [snip] Latest patch which fixes 2 bugs reported by testers and adds a bit more discussion to the man page is available here: http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/siftr_9.x.r209558.patch Fixed bugs: - Running SIFTR on an INVARIANTS enabled kernel with a large number of TCP flows terminating on the machine would lead to a KASSERT triggering in the ALQ framework when SIFTR was disabled. - The "SACK enabled" data log message field was not being set correctly. If you would like to test on a kernel revision older then r209558, make sure you have my r209325 diff to applied. It is safe to apply r209325 stand alone as it is self contained and not used by any code in the tree other than SIFTR. Please adapt the following instructions as appropriate based on the patch version you're testing. Copy it to the root of your source tree and run the following: patch -p1 < siftr_9.x.r209119.patch It's a loadable kernel module so you can build it for testing like so: cd /sys/modules/siftr make kldload ./siftr.ko (don't forget to "make cleandir" to remove cruft when finished testing) It turns out that the above instructions to build the module can produce a .ko that is out of sync with your kernel in such a way that the module can load, but may blow up unexpectedly. This was observed when KTR was enabled in the running kernel. To be safe, please use the following procedure instead: - Ensure is the source tree that the kernel you are currently running was built from. cd make buildkernel cp /usr/obj//sys//modules//sys/modules/siftr/siftr.ko /tmp kldload /tmp/siftr.ko Alternatively for the last 2 steps, you can "make installkernel ; shutdown -r now" after the kernel build completes and then simply "kldload siftr" as the module will be installed to /boot/kernel/ as per usual. After applying the patch, you can read the man page by running: man -M /share/man siftr If I've done a decent job, all the info you need to understand what it does and how to use it should be in the man page. I'm interested in all feedback and reports of success/failure, along with details of the architecture tested and number of CPUs if you would be so kind. That should be enough to get the ball rolling. Thanks and I look forward to hearing from you! Cheers, Lawrence [1] http://caia.swin.edu.au/freebsd/etcp09/ [2] http://www.freebsdfoundation.org/projects.shtml#Swinburne [3] http://caia.swin.edu.au/urp/newtcp/ [4] http://www.youtube.com/watch?v=xh_9QhRzJEs (language warning) [5] http://www.sonofthesouth.net/uncle-sam/images/uncle-sam-wants-you.jpg Cheers, Lawrence ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
Dag-Erling Smørgrav writes: > "M. Warner Losh" writes: >> Maybe the real problem is that devd locks the file, then dies. The >> file remains locked, so the flopen is failing with EWOULDBLOCK. > > The lock is released when the process that holds it terminates. > >> But I suspect the real real problem is the implicit assumption that >> flock will release the lock when a process terminates... That isn't >> the case in BSD > Yes it is. Additional details: - Under POSIX semantics (fcntl(2) locks), the lock is released when *any* file descriptor the process holds for that file is closed. This is handled in fdfree(). - Under flock semantics (flock(2) locks), the lock is released when *all* file descriptors the process holds for that file is closed. This is handled in vn_closefile(). - In both cases, all locks a process holds are released when the process terminates. Gotta love the following excerpt from VOP_OPEN(9), btw: The VOP_OPEN() entry point is called before a file is accessed by a process and the VOP_CLOSE() entry point is called after a file is fin‐ ished with by the process. :) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
"M. Warner Losh" writes: > Maybe the real problem is that devd locks the file, then dies. The > file remains locked, so the flopen is failing with EWOULDBLOCK. The lock is released when the process that holds it terminates. > But I suspect the real real problem is the implicit assumption that > flock will release the lock when a process terminates... That isn't > the case in BSD Yes it is. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Patch for rc.d/devd on FreeBSD 9-current
"M. Warner Losh" writes: > Why not fix pidfile_open to not return a file handle when the PID > doesn't match? It doesn't. If it can't lock the file, or if fstat(2) fails after it has locked the file, it returns NULL. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"