Re: problem with kgdb and modules. (k)gdb expert needed.
In 9.x ( can't check -current, but teh mailing list has a better readership) I'm still seeing this and have still not found any solution: possible reasons for the change may be: 1/ change to kgdb? 2/ change to the compiling toolset? 3/ change to the .mk files for compiling modules? any guidance would be appreciated.. The reason I can get away with using FreeBSD ar work is because I can debug modules well as in Linux this is generally a problem.. Now I see similar breakage in freebsd. (sigh)). I really don't know where to start looking for this.. Julian On 2/3/12 11:55 PM, Julian Elischer wrote: so We upgraded our development machines from 8 stable to 9 stable. and now kgdb can't debug inside modules. instead of getting anything useful, we just get: (kgdb) bt #0 0x81814600 in ?? () from /boot/kernel/netgraph.ko #1 0x81812d80 in ?? () from /boot/kernel/ng_socket.ko #2 0x0037 in ?? () #3 0x0002 in ?? () #4 0xfe0007176aa0 in ?? () #5 0xfe0007176aa0 in ?? () #6 0x818134a0 in ?? () from /boot/kernel/ng_socket.ko #7 0x81813960 in ?? () from /boot/kernel/ng_socket.ko #8 0xff860fa3cad0 in ?? () #9 0x808cc76e in socreate (dom=Variable "dom" is not available. ) at ../../../kern/uipc_socket.c:411 but stopping in the kernel itself, we DO see stuff.. (kgdb) break socreate Breakpoint 1 at 0x808cc628: file ../../../kern/uipc_socket.c, line 372. (kgdb) c Continuing. [New Thread 100198] [Switching to Thread 100198] Breakpoint 1, socreate (dom=32, aso=0xff860fa3caf0, type=2, proto=1, cred=0xfe000c63f600, td=0xfe011501a000) at ../../../kern/uipc_socket.c:372 372 if (proto) (kgdb) bt #0 socreate (dom=32, aso=0xff860fa3caf0, type=2, proto=1, cred=0xfe000c63f600, td=0xfe011501a000) at ../../../kern/uipc_socket.c:372 #1 0x808cf710 in sys_socket (td=0xfe011501a000, uap=0xff860fa3cbc0) at ../../../kern/uipc_syscalls.c:199 #2 0x80b5599a in amd64_syscall (td=0xfe011501a000, traced=0) at subr_syscall.c:131 #3 0x80b40b57 in Xfast_syscall () at ../../../amd64/amd64/exception.S:387 #4 0x0008011c82ac in ?? () etc. it looks as if modules no longer have stack frames compiled in. does anyone know the culprit? ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problems with hast
On Sun, Jan 29, 2012 at 12:35:35AM +0200, Mikolaj Golub wrote:
> Investigating, it looks after r226859, when 'async' mode was added, we have 2
> issues with synchronization from secondary to master (rather very rear case
> normally):
>
> 1) When the synchronization from secondary to master is running and primary
> gets READ request, the request should be sent to the secondary but actually it
> is lost. As a result READ operation gets stuck. After the syncronization is
> complete the following READ requests, which now can be served by primary, work
> ok.
>
> 2) In async mode, for syncronization requests, write_complete() function,
> which sends G_GATE_CMD_DONE command to ggate, is called twice and the second
> call fails.
>
> Artem, did you run async mode? If you did then I suppose you observed the
> second issue. Could you please try the attached patch?
The analysis and fixes look good to me, please go ahead and commit
(small nits below).
> Index: sbin/hastd/primary.c
> ===
> --- sbin/hastd/primary.c (revision 230661)
> +++ sbin/hastd/primary.c (working copy)
> @@ -1255,7 +1255,7 @@ ggate_recv_thread(void *arg)
> pjdlog_debug(2,
> "ggate_recv: (%p) Moving request to the send queues.", hio);
> refcount_init(&hio->hio_countdown, ncomps);
> - for (ii = ncomp; ii < ncomps; ii++)
> + for (ii = ncomp; ncomps != 0; ncomps--, ii++)
I'd prefer not to modify ncomps in the loop, maybe something like this:
for (ii = ncomp; ii < ncomp + ncomps; ii++)
> QUEUE_INSERT1(hio, send, ii);
> }
> /* NOTREACHED */
> @@ -1326,7 +1326,7 @@ local_send_thread(void *arg)
> } else {
> hio->hio_errors[ncomp] = 0;
> if (hio->hio_replication ==
> - HAST_REPLICATION_ASYNC) {
> + HAST_REPLICATION_ASYNC && !ISSYNCREQ(hio)) {
Could you move this additional check to separate line?
Thanks!
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
pgpZaHy0KpR84.pgp
Description: PGP signature
Re: 9.0 Stable unable to buildworld, missing KERN_PROC_ENV in kvm_proc.c
On Sun, 5 Feb 2012 20:09:08 +1100 Dewayne wrote: D> Unfortunately 9.0 Stable fails to compile due to missing declaration of D> KERN_PROC_ENV in /usr/src/lib/libkvm/kvm_proc.c. csup'ed from today. D> Please refer to the following changes on 30-Jan-2012: D> http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libkvm/kvm_proc.c.diff?r1=1.106.2.1;r2=1.106.2.2;f=h D> Compile error reads: D> cc -O2 -pipe -pipe -O2 -g0 -DSTRIP_FBSDID -UDEBUGGING -march=prescott -mtune=prescott -DLIBC_SCCS -I/usr/src/lib/libkvm D> -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes D> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libkvm/kvm_proc.c D> /usr/src/lib/libkvm/kvm_proc.c: In function 'kvm_argv': D> /usr/src/lib/libkvm/kvm_proc.c:663: error: 'KERN_PROC_ENV' undeclared (first use in this function) D> /usr/src/lib/libkvm/kvm_proc.c:663: error: (Each undeclared identifier is reported only once D> /usr/src/lib/libkvm/kvm_proc.c:663: error: for each function it appears in.) D> Am I the last person using i386 architecture? ;) I'm half joking. The D> buildworld completes successfully for architecture=amd64. And there should not be problems with i386 too. The error does not look like architecture specific. Could you please recheck your sources and building procedure and give more details if the error still exists. KERN_PROC_ENV is declared in sys/sys/sysctl.h, and this was MFCed in r230754, before the MFC lib/libkvm (r230780) you are referring to. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_8_1 tinderbox] failure on mips/mips
TB --- 2012-02-05 09:29:08 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-05 09:29:08 - starting RELENG_8_1 tinderbox run for mips/mips TB --- 2012-02-05 09:29:08 - cleaning the object tree TB --- 2012-02-05 09:29:16 - cvsupping the source tree TB --- 2012-02-05 09:29:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/mips/mips/supfile TB --- 2012-02-05 09:34:41 - building world TB --- 2012-02-05 09:34:41 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 09:34:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 09:34:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 09:34:41 - SRCCONF=/dev/null TB --- 2012-02-05 09:34:41 - TARGET=mips TB --- 2012-02-05 09:34:41 - TARGET_ARCH=mips TB --- 2012-02-05 09:34:41 - TZ=UTC TB --- 2012-02-05 09:34:41 - __MAKE_CONF=/dev/null TB --- 2012-02-05 09:34:41 - cd /src TB --- 2012-02-05 09:34:41 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 5 09:34:42 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 5 10:11:13 UTC 2012 TB --- 2012-02-05 10:11:13 - cd /src/sys/mips/conf TB --- 2012-02-05 10:11:13 - /usr/sbin/config -m ADM5120 TB --- 2012-02-05 10:11:13 - building ADM5120 kernel TB --- 2012-02-05 10:11:13 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 10:11:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 10:11:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 10:11:13 - SRCCONF=/dev/null TB --- 2012-02-05 10:11:13 - TARGET=mips TB --- 2012-02-05 10:11:13 - TARGET_ARCH=mips TB --- 2012-02-05 10:11:13 - TZ=UTC TB --- 2012-02-05 10:11:13 - __MAKE_CONF=/dev/null TB --- 2012-02-05 10:11:13 - cd /src TB --- 2012-02-05 10:11:13 - /usr/bin/make -B buildkernel KERNCONF=ADM5120 >>> Kernel build for ADM5120 started on Sun Feb 5 10:11:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ADM5120 completed on Sun Feb 5 10:12:25 UTC 2012 TB --- 2012-02-05 10:12:25 - cd /src/sys/mips/conf TB --- 2012-02-05 10:12:25 - /usr/sbin/config -m IDT TB --- 2012-02-05 10:12:25 - building IDT kernel TB --- 2012-02-05 10:12:25 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 10:12:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 10:12:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 10:12:25 - SRCCONF=/dev/null TB --- 2012-02-05 10:12:25 - TARGET=mips TB --- 2012-02-05 10:12:25 - TARGET_ARCH=mips TB --- 2012-02-05 10:12:25 - TZ=UTC TB --- 2012-02-05 10:12:25 - __MAKE_CONF=/dev/null TB --- 2012-02-05 10:12:25 - cd /src TB --- 2012-02-05 10:12:25 - /usr/bin/make -B buildkernel KERNCONF=IDT >>> Kernel build for IDT started on Sun Feb 5 10:12:25 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for IDT completed on Sun Feb 5 10:14:01 UTC 2012 TB --- 2012-02-05 10:14:01 - cd /src/sys/mips/conf TB --- 2012-02-05 10:14:01 - /usr/sbin/config -m MALTA TB --- 2012-02-05 10:14:01 - building MALTA kernel TB --- 2012-02-05 10:14:01 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 10:14:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 10:14:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 10:14:01 - SRCCONF=/dev/null TB --- 2012-02-05 10:14:01 - TARGET=mips TB --- 2012-02-05 10:14:01 - TARGET_ARCH=mips TB --- 2012-02-05 10:14:01 - TZ=UTC TB --- 2012-02-05 10:14:01 - __MAKE_CONF=/dev/null TB --- 2012-02-05 10:14:01 - cd /src TB --- 2012-02-05 10:14:01 - /usr/bin/make -B buildkernel KERNCONF=MALTA >>> Kernel build for MALTA started on Sun Feb 5 10:14:01 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for MALTA completed on Sun Feb 5 10:15:29 UTC 2012 TB --- 2012-02-05 10:15:29 - cd /src/sys/mips/conf TB --- 2012-02-05 10:15:29 - /usr/sbin/config -m QEMU TB --- 2012-02-05 10:15:29 - building QEMU kernel TB --- 2012-02-05 10:15:29 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 10:15:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 10:15:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 10:15:29 - SRCCONF=/dev/null TB --- 2012-02-05 10:15:29 - TARGET=mips TB --- 2012-02-05 10:15:29 - TARGET_ARCH=mips TB --- 2012-02-05 10:15:29 - TZ=UTC TB --- 2012-02-05 10:15:29 - __MAKE_CONF=/dev/null TB ---
Re: problem with kgdb and modules. (k)gdb expert needed.
on 05/02/2012 09:58 Julian Elischer said the following: > In 9.x ( can't check -current, but teh mailing list has a better readership) > > I'm still seeing this and have still not found any solution: > possible reasons for the change may be: > 1/ change to kgdb? > 2/ change to the compiling toolset? > 3/ change to the .mk files for compiling modules? > > any guidance would be appreciated.. > The reason I can get away with using FreeBSD ar work is because I can debug > modules well > as in Linux this is generally a problem.. Now I see similar breakage in > freebsd. (sigh)). > > I really don't know where to start looking for this.. Julian, just in case, how about some basic stuff like checking that the modules are indeed built with debugging support, that .symbols are installed and are accessible, that kgdb produces those messages: "Reading symbols", "Loaded symbols". > On 2/3/12 11:55 PM, Julian Elischer wrote: >> so We upgraded our development machines from 8 stable to 9 stable. and now >> kgdb can't debug inside modules. >> >> instead of getting anything useful, we just get: >> >> (kgdb) bt >> #0 0x81814600 in ?? () from /boot/kernel/netgraph.ko >> #1 0x81812d80 in ?? () from /boot/kernel/ng_socket.ko >> #2 0x0037 in ?? () >> #3 0x0002 in ?? () >> #4 0xfe0007176aa0 in ?? () >> #5 0xfe0007176aa0 in ?? () >> #6 0x818134a0 in ?? () from /boot/kernel/ng_socket.ko >> #7 0x81813960 in ?? () from /boot/kernel/ng_socket.ko >> #8 0xff860fa3cad0 in ?? () >> #9 0x808cc76e in socreate (dom=Variable "dom" is not available. >> ) at ../../../kern/uipc_socket.c:411 >> >> >> >> but stopping in the kernel itself, we DO see stuff.. >> >> (kgdb) break socreate >> Breakpoint 1 at 0x808cc628: file ../../../kern/uipc_socket.c, line >> 372. >> (kgdb) c >> Continuing. >> >> >> >> [New Thread 100198] >> [Switching to Thread 100198] >> >> Breakpoint 1, socreate (dom=32, aso=0xff860fa3caf0, type=2, proto=1, >> cred=0xfe000c63f600, td=0xfe011501a000) at >> ../../../kern/uipc_socket.c:372 >> 372 if (proto) >> (kgdb) bt >> #0 socreate (dom=32, aso=0xff860fa3caf0, type=2, proto=1, >> cred=0xfe000c63f600, td=0xfe011501a000) at >> ../../../kern/uipc_socket.c:372 >> #1 0x808cf710 in sys_socket (td=0xfe011501a000, >> uap=0xff860fa3cbc0) at ../../../kern/uipc_syscalls.c:199 >> #2 0x80b5599a in amd64_syscall (td=0xfe011501a000, traced=0) at >> subr_syscall.c:131 >> #3 0x80b40b57 in Xfast_syscall () at >> ../../../amd64/amd64/exception.S:387 >> #4 0x0008011c82ac in ?? () >> >> >> >> etc. >> >> it looks as if modules no longer have stack frames compiled in. >> does anyone know the culprit? >> >> ___ >> freebsd-curr...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> > > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS panics on pool moved from OpenSolaris
Please see this thread: http://lists.freebsd.org/pipermail/freebsd-fs/2011-December/013215.html It looks like the same issue. The patch has been committed in head, not sure if it's MFCed. on 05/02/2012 06:57 Morgan Reed said the following: > Hi all, > > I'm experiencing an issue in migrating my NAS from OpenSolaris > over to FreeBSD, I've tried both releng_8_2 and releng_9 I have > similar issues in both cases. > > The pool is a RAID-Z pool comprising 4 1TB drives, it was originally > created on OpenSolaris (not sure what version, 2010.09 maybe, it was > one of the last ones prior to the Oracle acquisition), pool was a V14 > pool, initially I built a FreeBSD-8.2 system to migrate the pool to, > migrated it over OK, upgraded it from V14 to V15, but later testing > revealed something wasn't happy, when listing certain directories (and > even doing an ls -la at the root of the pool) resulted in a kernel > panic (Mostly GENERIC kernel, rebuilt with KVA_PAGES 512 but other > than that stock); > > panic: avl_find() succeeded inside avl_add() > cpuid = 0 > KDB: stack backtrace: > #0 0x808e0d07 at kdb_backtrace+0x47 > #1 0x808b1dc7 at panic+0x117 > #2 0x862e6602 at avl_add+0x52 > #3 0x8635c136 at zfs_fuid_table_load+0x1f6 > #4 0x8635c3ee at zfs_fuid_init+0x14e > #5 0x8635c4d7 at zfs_fuid_find_by_idx+0xb7 > #6 0x8635c52d at zfs_fuid_map_id+0x2d > #7 0x8635d56f at zfs_groupmember+0x2f > #8 0x8636df0b at zfs_zaccess_aces_check+0x1db > #9 0x8636377 at zfs_zaccess+0x57 > #10 0x8636d6fb at zfs_zaccess_rwx+0x3b > #11 0x86385f61 at zfs_freebsd_access+0xf1 > #12 0x80c02ea2 at VOP_ACCESS_APV+0x42 > #13 0x809457cf at change_dir+0x5f > #14 0x809467b1 at kern_chdir+0x81 > #15 0x80946a22 at chdir+0x22 > #16 0x808eca39 at syscallenter+0x329 > #17 0x80be4e14 at syscall+0x34 > > Looks like something in the permissions structure was causing grief, > tried running a scrub across the pool, didn't resolve the issue. > > After spending some time fighting with it I decided that it wasn't > worth the effort, and I upgraded to FreeBSD-9.0 to see if that would > assist (I normally avoid x.0 releases), once again pool imported fine, > however I was still seeing similar panics, ran a scrub across the > pool, still not happy, also upgraded the pool to v28 tried again, when > that failed I scrubbed again but still no joy. > > As a matter of interest I booted an OpenIndiana live CD and tried > copying the directories contents to another location, I am now able to > list the directories. However there are still issues. > > The issue seems to have shifted slightly, stack trace from a recent > panic is below (GENERIC kernel on 9.0-RELEASE); > > panic: avl_find() succeeded inside avl_add() > cpuid = 0 > KDB: stack backtrace: > #0 0xc0a4b157 at kdb_backtrace+0x47 > #1 0xc0a186b7 at panic+0x117 > #2 0xc5a2d7b2 at avl_add+0x52 > #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 > #4 0xc5ac479e at zfs_fuid_init+0x14e > #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 > #6 0xc5ac48ed at zfs_fuid_map_id+0x2d > #7 0xc5ac492f at zfs_groupmember+0x2f > #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db > #9 0xc5adc257 at zfs_zaccess+0xb7 > #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 > #11 0xc0d69322 at VOP_GETATTR_APV+0x42 > #12 0xc0ab81c9 at vn_stat+0x79 > #13 0xc0aaefdd at kern_statat_vnhook+0xfd > #14 0xc0aaf1cc at kern_statat+0x3c > #15 0xc0aaf156 at kern_lstat+0x36 > #16 0xc0aaf1ff at sys_lstat+0x2f > #17 0xc0d49315 at syscall+0x355 > > This time it appears to be related to some extended attribute(s), I > can do an ls on one of the directories in question but an ls -la > causes a panic, so it would seem that it's some attribute which is > only shown in the long form of the ls output that is causing the > issue. > > I've done some digging around via the magic of google and this seems > to be a fairly common issue, but I've not found a solution for it > (barring copying the data off, recreating the pool and restoring the > data, I'd like to avoid this if at all possible. > > If I could determine what the problematic attribute was and a means to > strip it (be that from FreeBSD or from an OpenIndiana liveCD) I think > that will get me back up and running. > > If anybody can provide some suggestions as to what I may be able to do > to resolve this issue in situ I would be very grateful. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Why do I get 32767 id mapping when using NSFv4 with LDAP?
I've configured a server with 9-STABLE compiled late january. I've played a bit with NFSv4 and it works great. Except that I can't get it to play nice with OpenLDAP. If I mirror the passwd and group files between the client and server the mapping is correct. If I add pam_ldap to the /etc/pam.d/system file it works fine on both systems when I browse local files, however NFSv4 map both the uid and gid as 32767. The files should belong to user olav with uid and gid 1001. Do anyone how I can get this to work properly? At least what I should look into? Do I need kerberos? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_8_2 tinderbox] failure on mips/mips
TB --- 2012-02-05 11:47:04 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-05 11:47:04 - starting RELENG_8_2 tinderbox run for mips/mips TB --- 2012-02-05 11:47:04 - cleaning the object tree TB --- 2012-02-05 11:47:12 - cvsupping the source tree TB --- 2012-02-05 11:47:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_2/mips/mips/supfile TB --- 2012-02-05 11:47:27 - building world TB --- 2012-02-05 11:47:27 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 11:47:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 11:47:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 11:47:27 - SRCCONF=/dev/null TB --- 2012-02-05 11:47:27 - TARGET=mips TB --- 2012-02-05 11:47:27 - TARGET_ARCH=mips TB --- 2012-02-05 11:47:27 - TZ=UTC TB --- 2012-02-05 11:47:27 - __MAKE_CONF=/dev/null TB --- 2012-02-05 11:47:27 - cd /src TB --- 2012-02-05 11:47:27 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 5 11:47:27 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 5 12:23:42 UTC 2012 TB --- 2012-02-05 12:23:42 - cd /src/sys/mips/conf TB --- 2012-02-05 12:23:42 - /usr/sbin/config -m ADM5120 TB --- 2012-02-05 12:23:42 - building ADM5120 kernel TB --- 2012-02-05 12:23:42 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 12:23:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 12:23:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 12:23:42 - SRCCONF=/dev/null TB --- 2012-02-05 12:23:42 - TARGET=mips TB --- 2012-02-05 12:23:42 - TARGET_ARCH=mips TB --- 2012-02-05 12:23:42 - TZ=UTC TB --- 2012-02-05 12:23:42 - __MAKE_CONF=/dev/null TB --- 2012-02-05 12:23:42 - cd /src TB --- 2012-02-05 12:23:42 - /usr/bin/make -B buildkernel KERNCONF=ADM5120 >>> Kernel build for ADM5120 started on Sun Feb 5 12:23:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ADM5120 completed on Sun Feb 5 12:24:55 UTC 2012 TB --- 2012-02-05 12:24:55 - cd /src/sys/mips/conf TB --- 2012-02-05 12:24:55 - /usr/sbin/config -m ALCHEMY TB --- 2012-02-05 12:24:55 - building ALCHEMY kernel TB --- 2012-02-05 12:24:55 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 12:24:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 12:24:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 12:24:55 - SRCCONF=/dev/null TB --- 2012-02-05 12:24:55 - TARGET=mips TB --- 2012-02-05 12:24:55 - TARGET_ARCH=mips TB --- 2012-02-05 12:24:55 - TZ=UTC TB --- 2012-02-05 12:24:55 - __MAKE_CONF=/dev/null TB --- 2012-02-05 12:24:55 - cd /src TB --- 2012-02-05 12:24:55 - /usr/bin/make -B buildkernel KERNCONF=ALCHEMY >>> Kernel build for ALCHEMY started on Sun Feb 5 12:24:56 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=10 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=10 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=10 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/libkern/umod
[releng_8_2 tinderbox] failure on powerpc/powerpc
TB --- 2012-02-05 12:12:26 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-05 12:12:26 - starting RELENG_8_2 tinderbox run for powerpc/powerpc TB --- 2012-02-05 12:12:26 - cleaning the object tree TB --- 2012-02-05 12:12:57 - cvsupping the source tree TB --- 2012-02-05 12:12:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_2/powerpc/powerpc/supfile TB --- 2012-02-05 12:14:04 - building world TB --- 2012-02-05 12:14:04 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 12:14:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 12:14:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 12:14:04 - SRCCONF=/dev/null TB --- 2012-02-05 12:14:04 - TARGET=powerpc TB --- 2012-02-05 12:14:04 - TARGET_ARCH=powerpc TB --- 2012-02-05 12:14:04 - TZ=UTC TB --- 2012-02-05 12:14:04 - __MAKE_CONF=/dev/null TB --- 2012-02-05 12:14:04 - cd /src TB --- 2012-02-05 12:14:04 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 5 12:14:04 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 5 13:00:19 UTC 2012 TB --- 2012-02-05 13:00:19 - generating LINT kernel config TB --- 2012-02-05 13:00:19 - cd /src/sys/powerpc/conf TB --- 2012-02-05 13:00:19 - /usr/bin/make -B LINT TB --- 2012-02-05 13:00:19 - cd /src/sys/powerpc/conf TB --- 2012-02-05 13:00:19 - /usr/sbin/config -m LINT TB --- 2012-02-05 13:00:19 - building LINT kernel TB --- 2012-02-05 13:00:19 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 13:00:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 13:00:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 13:00:19 - SRCCONF=/dev/null TB --- 2012-02-05 13:00:19 - TARGET=powerpc TB --- 2012-02-05 13:00:19 - TARGET_ARCH=powerpc TB --- 2012-02-05 13:00:19 - TZ=UTC TB --- 2012-02-05 13:00:19 - __MAKE_CONF=/dev/null TB --- 2012-02-05 13:00:19 - cd /src TB --- 2012-02-05 13:00:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 5 13:00:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Feb 5 13:15:46 UTC 2012 TB --- 2012-02-05 13:15:46 - cd /src/sys/powerpc/conf TB --- 2012-02-05 13:15:46 - /usr/sbin/config -m GENERIC TB --- 2012-02-05 13:15:46 - building GENERIC kernel TB --- 2012-02-05 13:15:46 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 13:15:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 13:15:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 13:15:46 - SRCCONF=/dev/null TB --- 2012-02-05 13:15:46 - TARGET=powerpc TB --- 2012-02-05 13:15:46 - TARGET_ARCH=powerpc TB --- 2012-02-05 13:15:46 - TZ=UTC TB --- 2012-02-05 13:15:46 - __MAKE_CONF=/dev/null TB --- 2012-02-05 13:15:46 - cd /src TB --- 2012-02-05 13:15:46 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Feb 5 13:15:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Feb 5 13:26:19 UTC 2012 TB --- 2012-02-05 13:26:19 - cd /src/sys/powerpc/conf TB --- 2012-02-05 13:26:19 - /usr/sbin/config -m MPC85XX TB --- 2012-02-05 13:26:19 - building MPC85XX kernel TB --- 2012-02-05 13:26:19 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 13:26:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 13:26:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 13:26:19 - SRCCONF=/dev/null TB --- 2012-02-05 13:26:19 - TARGET=powerpc TB --- 2012-02-05 13:26:19 - TARGET_ARCH=powerpc TB --- 2012-02-05 13:26:19 - TZ=UTC TB --- 2012-02-05 13:26:19 - __MAKE_CONF=/dev/null TB --- 2012-02-05 13:26:19 - cd /src TB --- 2012-02-05 13:26:19 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Sun Feb 5 13:26:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wa,-me500 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --pa
RE: 9.0 Stable unable to buildworld, missing KERN_PROC_ENV in kvm_proc.c
Hi Mikolaj,
As part of the process, I delete all logs, audit trails of the build,
/usr/obj/* and the various DESTDIR's that have been set.
The build process is from a single /usr/src but I do modify MAKEOBJDIRPREFIX,
DESTDIR and various WITHOUT_ statements through
variable switches in {make,src}.conf.
And you're right, in the sources, KERN_PROC_ENV is defined.
# ls -lrth /usr/src/sys/sys/sysctl.h
-rw-r--r-- 1 root wheel30k Jan 30 19:56 /usr/src/sys/sys/sysctl.h
# grep KERN_PROC_ENV /usr/src/sys/sys/sysctl.h
#define KERN_PROC_ENV 35 /* get environment */
The clue seems to be in here
# ls -lrth /usr/src/sys/sys/ |tail -n 12
-rw-r--r-- 1 root wheel 4.2k Jan 16 19:10 mchain.h
-rw-r--r-- 1 root wheel 8.2k Jan 16 19:10 iconv.h
-rw-r--r-- 1 root wheel 6.2k Jan 23 22:24 umtx.h
-rw-r--r-- 1 root wheel31k Jan 23 22:24 pmc.h
-rw-r--r-- 1 root wheel11k Jan 23 22:24 param.h # The following aren't
copied into /usr/include
-rw-r--r-- 1 root wheel30k Jan 30 06:24 mount.h
-rw-r--r-- 1 root wheel30k Jan 30 19:56 sysctl.h
-rw-r--r-- 1 root wheel 5.6k Jan 30 19:56 resourcevar.h
-rw-r--r-- 1 root wheel39k Jan 30 19:56 proc.h
-rw-r--r-- 1 root wheel15k Feb 4 15:19 mutex.h
-rw-r--r-- 1 root wheel40k Feb 4 15:19 elf_common.h
-rw-r--r-- 1 root wheel11k Feb 4 15:19 sx.h
# ls -lrth /usr/include/sys/ | tail -n 12
-r--r--r-- 1 root wheel11k Jan 9 00:05 syscallsubr.h
-r--r--r-- 1 root wheel11k Jan 9 00:05 syscall.h
-r--r--r-- 1 root wheel 5.0k Jan 9 00:05 resource.h
-r--r--r-- 1 root wheel10k Jan 9 00:05 file.h
-r--r--r-- 1 root wheel10k Jan 9 00:05 fcntl.h
-r--r--r-- 1 root wheel 6.4k Jan 13 10:32 taskqueue.h
-r--r--r-- 1 root wheel28k Jan 14 17:54 vnode.h
-r--r--r-- 1 root wheel 8.2k Jan 16 19:38 iconv.h
-r--r--r-- 1 root wheel 4.2k Jan 16 19:38 mchain.h
-r--r--r-- 1 root wheel 6.2k Jan 23 23:09 umtx.h
-r--r--r-- 1 root wheel31k Jan 23 23:09 pmc.h
-r--r--r-- 1 root wheel11k Jan 23 23:09 param.h # I'm looking into why
this is the last file copied.
I'm reviewing my build logs to ascertain why files after param.h aren't being
copied from /usr/src/sys into /usr/include
Its after midnight so I'll continue investigating tomorrow, clearly its going
to take some time. The buildworld succeeding only
for amd64/K8-sse is the really confusing part. So far, I note that log files
each contain:
...
if [ -L /usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys ]; then rm -f
/usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys; fi
...
cd /usr/src/include/../sys/sys; for h in *.h; do ln -fs ../../../sys/sys/$h
/usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys; done
...
Which seems normal.
And yes, grep KERN_PROC_ENV
/usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys/sysctl.h is defined
Kind regards, Dewayne.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
9.0 Stable unable to buildworld, missing KERN_PROC_ENV in kvm_proc.c
Unfortunately 9.0 Stable fails to compile due to missing declaration of KERN_PROC_ENV in /usr/src/lib/libkvm/kvm_proc.c. csup'ed from today. Please refer to the following changes on 30-Jan-2012: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libkvm/kvm_proc.c.diff?r1=1.106.2.1;r2=1.106.2.2;f=h Compile error reads: cc -O2 -pipe -pipe -O2 -g0 -DSTRIP_FBSDID -UDEBUGGING -march=prescott -mtune=prescott -DLIBC_SCCS -I/usr/src/lib/libkvm -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libkvm/kvm_proc.c /usr/src/lib/libkvm/kvm_proc.c: In function 'kvm_argv': /usr/src/lib/libkvm/kvm_proc.c:663: error: 'KERN_PROC_ENV' undeclared (first use in this function) /usr/src/lib/libkvm/kvm_proc.c:663: error: (Each undeclared identifier is reported only once /usr/src/lib/libkvm/kvm_proc.c:663: error: for each function it appears in.) Am I the last person using i386 architecture? ;) I'm half joking. The buildworld completes successfully for architecture=amd64. Regards, Dewayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problems with hast
On Sun, 5 Feb 2012 10:27:54 +0100 Pawel Jakub Dawidek wrote: PJD> The analysis and fixes look good to me, please go ahead and commit PJD> (small nits below). Thanks. Committed. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why do I get 32767 id mapping when using NSFv4 with LDAP?
Olav Gjerde wrote: > I've configured a server with 9-STABLE compiled late january. I've > played a bit with NFSv4 and it works great. Except that I can't get it > to play nice with OpenLDAP. If I mirror the passwd and group files > between the client and server the mapping is correct. If I add > pam_ldap to the /etc/pam.d/system file it works fine on both systems > when I browse local files, however NFSv4 map both the uid and gid as > 32767. The files should belong to user olav with uid and gid 1001. Do > anyone how I can get this to work properly? At least what I should > look into? Do I need kerberos? Nope, you shouldn't need Kerberos. The 32767 is what you get when it can't find a mapping. All nfsuserd does is call the library functions like getpwuid()/getpwname() to get a mapping for a uid when it gets an upcall from the kernel asking for a mapping for that uid/user. I've never used ldap, so I can't help with that except to suggest that, for some reason, the libc calls aren't working. You can run nfsuserd with "-verbose" and it will log all mapping attempts. (Maybe what it logs in /var/log/messages will give you a hint.) You can also "tcpdump -s 0 -w xxx host " and then look at "xxx" in wireshark. Then, look in the Getattr reply and see what the Owner and Owner_group replies look like. This will tell you if it is the server that isn't doing the mappings or the client after it receives the name. (For Getattr, the server should translate uid/gid to @ and then the client should turn that back into the same uid/gid.) Good luck with it, rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: DNSSec on FreeBSD 9.0-RELEASE causes CPU 100%
Hi
Just FYI, I just encountered the same issue with bind and DNSSEC.
Bind was using 100% CPU, even after a restart.
Turns out that were a key in the managed-keys folder which was
unreadable by bind (permission issue).
Hope It can help.
Arnaud Houdelette.
On 05/01/2012 01:24, George Kontostanos wrote:
Greetings everyone,
I was testing DNSSec resolution on BIND 9.8.1-P1 by adding the
following options:
options {
...
dnssec-enable yes;
dnssec-validation auto;
...
};
Unfortunately immediately after named is restarted one CPU reaches
100% utilization.
CPU: 30.1% user, 0.0% nice, 23.6% system, 0.0% interrupt, 46.3% idle
Mem: 111M Active, 14M Inact, 255M Wired, 852K Cache, 3558M Free
Swap: 2048M Total, 2048M Free
PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND
2178 bind 5 200 51364K 13828K kqread 0 0:17 84.18% named
The system is running GENERIC kernel, and it not an authoritative DNS.
Mainly used for testing purposes. My logs don't show anything strange:
Jan 5 02:03:55 hp named[2178]: starting BIND 9.8.1-P1 -t /var/named -u bind
Jan 5 02:03:55 hp named[2178]: built with '--prefix=/usr'
'--infodir=/usr/share/info' '--mandir=/usr/share/man'
'--enable-threads' '--enable-getifaddrs' '--disable-linux-caps'
'--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn'
'--without-libxml2'
Jan 5 02:03:55 hp named[2178]: using built-in root key for view _default
Jan 5 02:03:55 hp named[2178]: command channel listening on 127.0.0.1#953
Jan 5 02:03:55 hp named[2178]: command channel listening on ::1#953
an 5 02:03:55 hp named[2178]: running
Anybody has come across a similar behavior ?
Cheers,
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS panics on pool moved from OpenSolaris
Hi Andriy, Thanks for that, the patch has significantly improved matters, I'm now able to run a find across part of the drive without issue, however I'm still seeing the panics on some directories, stack trace below; panic: avl_find() succeeded inside avl_add() cpuid = 0 KDB: stack backtrace: #0 0xc0a4b157 at kdb_backtrace+0x47 #1 0xc0a186b7 at panic+0x117 #2 0xc5a2d7b2 at avl_add+0x52 #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 #4 0xc5ac479e at zfs_fuid_init+0x14e #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 #6 0xc5ac48ed at zfs_fuid_map_id+0x2d #7 0xc5ac492f at zfs_groupmember+0x2f #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db #9 0xc5adc257 at zfs_zaccess+0xb7 #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 #11 0xc0d69322 at VOP_GETATTR_APV+0x42 #12 0xc0ab81c9 at vn_stat+0x79 #13 0xc0aaefdd at kern_statat_vnhook+0xfd #14 0xc0aaf1cc at kern_statat+0x3c #15 0xc0aaf156 at kern_lstat+0x36 #16 0xc0aaf1ff at sys_lstat+0x2f #17 0xc0d49315 at syscall+0x355 Same trace as previously on 9.0. I'm following your advice to Karli and throwing some printfs into zfs_fuid_table_load, I'll advise if I find anything enlightening. Thanks, Morgan On Sun, Feb 5, 2012 at 22:20, Andriy Gapon wrote: > > Please see this thread: > http://lists.freebsd.org/pipermail/freebsd-fs/2011-December/013215.html > It looks like the same issue. > The patch has been committed in head, not sure if it's MFCed. > > on 05/02/2012 06:57 Morgan Reed said the following: >> Hi all, >> >> I'm experiencing an issue in migrating my NAS from OpenSolaris >> over to FreeBSD, I've tried both releng_8_2 and releng_9 I have >> similar issues in both cases. >> >> The pool is a RAID-Z pool comprising 4 1TB drives, it was originally >> created on OpenSolaris (not sure what version, 2010.09 maybe, it was >> one of the last ones prior to the Oracle acquisition), pool was a V14 >> pool, initially I built a FreeBSD-8.2 system to migrate the pool to, >> migrated it over OK, upgraded it from V14 to V15, but later testing >> revealed something wasn't happy, when listing certain directories (and >> even doing an ls -la at the root of the pool) resulted in a kernel >> panic (Mostly GENERIC kernel, rebuilt with KVA_PAGES 512 but other >> than that stock); >> >> panic: avl_find() succeeded inside avl_add() >> cpuid = 0 >> KDB: stack backtrace: >> #0 0x808e0d07 at kdb_backtrace+0x47 >> #1 0x808b1dc7 at panic+0x117 >> #2 0x862e6602 at avl_add+0x52 >> #3 0x8635c136 at zfs_fuid_table_load+0x1f6 >> #4 0x8635c3ee at zfs_fuid_init+0x14e >> #5 0x8635c4d7 at zfs_fuid_find_by_idx+0xb7 >> #6 0x8635c52d at zfs_fuid_map_id+0x2d >> #7 0x8635d56f at zfs_groupmember+0x2f >> #8 0x8636df0b at zfs_zaccess_aces_check+0x1db >> #9 0x8636377 at zfs_zaccess+0x57 >> #10 0x8636d6fb at zfs_zaccess_rwx+0x3b >> #11 0x86385f61 at zfs_freebsd_access+0xf1 >> #12 0x80c02ea2 at VOP_ACCESS_APV+0x42 >> #13 0x809457cf at change_dir+0x5f >> #14 0x809467b1 at kern_chdir+0x81 >> #15 0x80946a22 at chdir+0x22 >> #16 0x808eca39 at syscallenter+0x329 >> #17 0x80be4e14 at syscall+0x34 >> >> Looks like something in the permissions structure was causing grief, >> tried running a scrub across the pool, didn't resolve the issue. >> >> After spending some time fighting with it I decided that it wasn't >> worth the effort, and I upgraded to FreeBSD-9.0 to see if that would >> assist (I normally avoid x.0 releases), once again pool imported fine, >> however I was still seeing similar panics, ran a scrub across the >> pool, still not happy, also upgraded the pool to v28 tried again, when >> that failed I scrubbed again but still no joy. >> >> As a matter of interest I booted an OpenIndiana live CD and tried >> copying the directories contents to another location, I am now able to >> list the directories. However there are still issues. >> >> The issue seems to have shifted slightly, stack trace from a recent >> panic is below (GENERIC kernel on 9.0-RELEASE); >> >> panic: avl_find() succeeded inside avl_add() >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xc0a4b157 at kdb_backtrace+0x47 >> #1 0xc0a186b7 at panic+0x117 >> #2 0xc5a2d7b2 at avl_add+0x52 >> #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 >> #4 0xc5ac479e at zfs_fuid_init+0x14e >> #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 >> #6 0xc5ac48ed at zfs_fuid_map_id+0x2d >> #7 0xc5ac492f at zfs_groupmember+0x2f >> #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db >> #9 0xc5adc257 at zfs_zaccess+0xb7 >> #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 >> #11 0xc0d69322 at VOP_GETATTR_APV+0x42 >> #12 0xc0ab81c9 at vn_stat+0x79 >> #13 0xc0aaefdd at kern_statat_vnhook+0xfd >> #14 0xc0aaf1cc at kern_statat+0x3c >> #15 0xc0aaf156 at kern_lstat+0x36 >> #16 0xc0aaf1ff at sys_lstat+0x2f >> #17 0xc0d49315 at syscall+0x355 >> >> This time it appears to be related to some extended attribute(s), I >> can do an ls on one of the directories in question but an ls -la >> causes a panic, so it would seem that it's some attribute which is >> only shown in the long form of the ls output th
Re: ZFS panics on pool moved from OpenSolaris
Hi Andriy, Scratch that, it would appear to be a PEBKAC issue, looks like I omitted to actually save sid.h when I made the mods. Patch is good, I now have access to my whole pool again. Thanks, Morgan On Mon, Feb 6, 2012 at 10:23, Morgan Reed wrote: > Hi Andriy, > > Thanks for that, the patch has significantly improved > matters, I'm now able to run a find across part of the drive without > issue, however I'm still seeing the panics on some directories, stack > trace below; > > panic: avl_find() succeeded inside avl_add() > cpuid = 0 > KDB: stack backtrace: > #0 0xc0a4b157 at kdb_backtrace+0x47 > #1 0xc0a186b7 at panic+0x117 > #2 0xc5a2d7b2 at avl_add+0x52 > #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 > #4 0xc5ac479e at zfs_fuid_init+0x14e > #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 > #6 0xc5ac48ed at zfs_fuid_map_id+0x2d > #7 0xc5ac492f at zfs_groupmember+0x2f > #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db > #9 0xc5adc257 at zfs_zaccess+0xb7 > #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 > #11 0xc0d69322 at VOP_GETATTR_APV+0x42 > #12 0xc0ab81c9 at vn_stat+0x79 > #13 0xc0aaefdd at kern_statat_vnhook+0xfd > #14 0xc0aaf1cc at kern_statat+0x3c > #15 0xc0aaf156 at kern_lstat+0x36 > #16 0xc0aaf1ff at sys_lstat+0x2f > #17 0xc0d49315 at syscall+0x355 > > Same trace as previously on 9.0. > > I'm following your advice to Karli and throwing some printfs into > zfs_fuid_table_load, I'll advise if I find anything enlightening. > > Thanks, > > Morgan > > On Sun, Feb 5, 2012 at 22:20, Andriy Gapon wrote: >> >> Please see this thread: >> http://lists.freebsd.org/pipermail/freebsd-fs/2011-December/013215.html >> It looks like the same issue. >> The patch has been committed in head, not sure if it's MFCed. >> >> on 05/02/2012 06:57 Morgan Reed said the following: >>> Hi all, >>> >>> I'm experiencing an issue in migrating my NAS from OpenSolaris >>> over to FreeBSD, I've tried both releng_8_2 and releng_9 I have >>> similar issues in both cases. >>> >>> The pool is a RAID-Z pool comprising 4 1TB drives, it was originally >>> created on OpenSolaris (not sure what version, 2010.09 maybe, it was >>> one of the last ones prior to the Oracle acquisition), pool was a V14 >>> pool, initially I built a FreeBSD-8.2 system to migrate the pool to, >>> migrated it over OK, upgraded it from V14 to V15, but later testing >>> revealed something wasn't happy, when listing certain directories (and >>> even doing an ls -la at the root of the pool) resulted in a kernel >>> panic (Mostly GENERIC kernel, rebuilt with KVA_PAGES 512 but other >>> than that stock); >>> >>> panic: avl_find() succeeded inside avl_add() >>> cpuid = 0 >>> KDB: stack backtrace: >>> #0 0x808e0d07 at kdb_backtrace+0x47 >>> #1 0x808b1dc7 at panic+0x117 >>> #2 0x862e6602 at avl_add+0x52 >>> #3 0x8635c136 at zfs_fuid_table_load+0x1f6 >>> #4 0x8635c3ee at zfs_fuid_init+0x14e >>> #5 0x8635c4d7 at zfs_fuid_find_by_idx+0xb7 >>> #6 0x8635c52d at zfs_fuid_map_id+0x2d >>> #7 0x8635d56f at zfs_groupmember+0x2f >>> #8 0x8636df0b at zfs_zaccess_aces_check+0x1db >>> #9 0x8636377 at zfs_zaccess+0x57 >>> #10 0x8636d6fb at zfs_zaccess_rwx+0x3b >>> #11 0x86385f61 at zfs_freebsd_access+0xf1 >>> #12 0x80c02ea2 at VOP_ACCESS_APV+0x42 >>> #13 0x809457cf at change_dir+0x5f >>> #14 0x809467b1 at kern_chdir+0x81 >>> #15 0x80946a22 at chdir+0x22 >>> #16 0x808eca39 at syscallenter+0x329 >>> #17 0x80be4e14 at syscall+0x34 >>> >>> Looks like something in the permissions structure was causing grief, >>> tried running a scrub across the pool, didn't resolve the issue. >>> >>> After spending some time fighting with it I decided that it wasn't >>> worth the effort, and I upgraded to FreeBSD-9.0 to see if that would >>> assist (I normally avoid x.0 releases), once again pool imported fine, >>> however I was still seeing similar panics, ran a scrub across the >>> pool, still not happy, also upgraded the pool to v28 tried again, when >>> that failed I scrubbed again but still no joy. >>> >>> As a matter of interest I booted an OpenIndiana live CD and tried >>> copying the directories contents to another location, I am now able to >>> list the directories. However there are still issues. >>> >>> The issue seems to have shifted slightly, stack trace from a recent >>> panic is below (GENERIC kernel on 9.0-RELEASE); >>> >>> panic: avl_find() succeeded inside avl_add() >>> cpuid = 0 >>> KDB: stack backtrace: >>> #0 0xc0a4b157 at kdb_backtrace+0x47 >>> #1 0xc0a186b7 at panic+0x117 >>> #2 0xc5a2d7b2 at avl_add+0x52 >>> #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 >>> #4 0xc5ac479e at zfs_fuid_init+0x14e >>> #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 >>> #6 0xc5ac48ed at zfs_fuid_map_id+0x2d >>> #7 0xc5ac492f at zfs_groupmember+0x2f >>> #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db >>> #9 0xc5adc257 at zfs_zaccess+0xb7 >>> #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 >>> #11 0xc0d69322 at VOP_GETATTR_APV+0x42 >>> #12 0xc0ab81c9 at vn_stat+0x79 >>> #13 0xc0aaefdd at kern_statat_vnhook+0xfd >>>
Re: problem with kgdb and modules. (k)gdb expert needed.
On 2/5/12 3:05 AM, Andriy Gapon wrote: on 05/02/2012 09:58 Julian Elischer said the following: In 9.x ( can't check -current, but teh mailing list has a better readership) I'm still seeing this and have still not found any solution: possible reasons for the change may be: 1/ change to kgdb? 2/ change to the compiling toolset? 3/ change to the .mk files for compiling modules? any guidance would be appreciated.. The reason I can get away with using FreeBSD ar work is because I can debug modules well as in Linux this is generally a problem.. Now I see similar breakage in freebsd. (sigh)). I really don't know where to start looking for this.. Julian, just in case, how about some basic stuff like checking that the modules are indeed built with debugging support, that .symbols are installed and are accessible, that kgdb produces those messages: "Reading symbols", "Loaded symbols". it seems to have been some timing issue. the scripts that ran in 8.x fail to load the symbols in 9.x but if I do the commands again by hand, it does load them.. so it seems to be a false alarm ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
kernel debugging and ULE
so if I'm sitting still in the debugger for too long, a hardclock
event happens that goes into ULE, which then hits the following KASSERT.
KASSERT(pri >= PRI_MIN_BATCH && pri <= PRI_MAX_BATCH,
("sched_priority: invalid priority %d: nice %d, "
"ticks %d ftick %d ltick %d tick pri %d",
pri, td->td_proc->p_nice, td->td_sched->ts_ticks,
td->td_sched->ts_ftick, td->td_sched->ts_ltick,
SCHED_PRI_TICKS(td->td_sched)));
The reason seems to be that I've been sitting still for too long and
things have become pear shaped.
how is it that being in the debugger doesn't stop hardclock events?
is there something I can do to make them not happen..
It means I have to ge tmy debugging done in less than about 60 seconds.
suggesions welcome.
Julian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 8.2-stable: devd fails to restart
On Sat, 4 Feb 2012, Torfinn Ingolfsen wrote: On Sat, 04 Feb 2012 10:34:19 -0700 (MST) Warren Block wrote: Possibly relevant: http://www.freebsd.org/cgi/query-pr.cgi?pr=140462&cat= (Using DHCP from /etc/rc.conf leaves a lock on devd.pid. SYNCDHCP does not.) And the thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-October/012749.html Yes, it seems to be that problem. Tested on my other machine, which hasn't changed since the problem was discovered: root@kg-v7# service devd status devd is not running. root@kg-v7# ll /var/run/devd.pid -rw--- 1 root wheel 3 Jan 12 20:40 /var/run/devd.pid root@kg-v7# lsof /var/run/devd.pid COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dhclient 1075 root5w VREG 0,703 918547 /var/run/devd.pid dhclient 1091 _dhcp5w VREG 0,703 918547 /var/run/devd.pid root@kg-v7# So, if this was worked on back in 2009, why isn't fixed yet? I switched to using SYNCDHCP which avoids the problem, didn't enter a PR, and quickly forgot about it. It would be nice to have it fixed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
