Better pkg bootstrapping instructions?
Especially on -CURRENT, it's not going to be uncommon to see things like this: The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg please wait _http._tcp.pkg.FreeBSD.org pkg: Error fetching http://pkg.FreeBSD.org/freebsd:10:arm:32:el:oabi:softfp/latest/Latest/pkg.txz: Not Found It would be nice if the next line said: "A pre-built version of pkg could not be found for your system." "Please install it from source using the ports-mgmt/pkg port." ___ 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: LK_RETRY set with incompatible flags
Andriy Gapon wrote:
> on 31/01/2013 15:29 Sergey Kandaurov said the following:
> > Hi.
> >
> > Got this assertion on idle NFS server while `ls -la /.zfs/shares/'
> > issued on NFS client.
> > kern/vfs_vnops.c:_vn_lock()
> > KASSERT((flags & LK_RETRY) == 0 || error == 0,
> > ("LK_RETRY set with incompatible flags (0x%x) or
> > an error occured (%d)",
> >
> > panic: LK_RETRY set with incompatible flags (0x200400) or an error
> > occured (11)
> >
> > What does that mean and how is it possible? As you can see, both
> > parts
> > of assertion failed.
> > 11 is EDEADLK
> > 0x200400: LK_RETRY & LK_UPGRADE
>
> LK_SHARED, not LK_UPGRADE.
> Apparently the thread already holds an exlusive lock on the vnode,
> which you
> confirm below.
>
>
> > Tracing pid 2943 tid 101532 td 0xfe004f5b7000
> > kdb_enter() at kdb_enter+0x3e/frame 0xff848e45ef50
> > vpanic() at vpanic+0x147/frame 0xff848e45ef90
> > kassert_panic() at kassert_panic+0x136/frame 0xff848e45f000
> > _vn_lock() at _vn_lock+0x70/frame 0xff848e45f070
> > zfs_lookup() at zfs_lookup+0x392/frame 0xff848e45f100
> > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame
> > 0xff848e45f240
> > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame
> > 0xff848e45f260
> > vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xff848e45f2b0
> > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xff848e45f2d0
> > lookup() at lookup+0x548/frame 0xff848e45f350
> > nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xff848e45f400
> > nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xff848e45f6b0
> > nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xff848e45f8a0
> > nfssvc_program() at nfssvc_program+0x482/frame 0xff848e45fa00
> > svc_run_internal() at svc_run_internal+0x1e9/frame
> > 0xff848e45fba0
> > svc_thread_start() at svc_thread_start+0xb/frame 0xff848e45fbb0
> > fork_exit() at fork_exit+0x84/frame 0xff848e45fbf0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xff848e45fbf0
> > --- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffd488, rbp =
> > 0x7fffd730 ---
> >
> > db> show lockedvnods
> > Locked vnodes
> >
> > 0xfe02e21b11d8: tag zfs, type VDIR
> > usecount 4, writecount 0, refcount 4 mountedhere 0
> > flags (VI_ACTIVE)
> > v_object 0xfe02d9f2eb40 ref 0 pages 0
> > lock type zfs: EXCL by thread 0xfe004f5b7000 (pid 2943,
> > nfsd,
> > tid 101532)
> >
> >
> >
I just took a look at zfs_vnops.c and I am probably missing something,
but I can't see how this ever worked for a lookup of ".." when at the
root (unless ZFS doesn't do the ".." is the current directory when at
the root).
Here's the code snippet:
1442if (error == 0 && (nm[0] != '.' || nm[1] != '\0')) {
1443int ltype = 0;
1444
1445if (cnp->cn_flags & ISDOTDOT) {
1446ltype = VOP_ISLOCKED(dvp);
1447VOP_UNLOCK(dvp, 0);
1448}
1449ZFS_EXIT(zfsvfs);
1450error = zfs_vnode_lock(*vpp, cnp->cn_lkflags);
1451if (cnp->cn_flags & ISDOTDOT)
1452vn_lock(dvp, ltype | LK_RETRY);
1453if (error != 0) {
1454VN_RELE(*vpp);
1455*vpp = NULL;
1456return (error);
1457}
Maybe line# 1451 should be changed to:
if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp)
I'm not at all familiar with ZFS, so I've probably way
off the mark on this, rick
ps: I hope kib and jhb don't mind being added as cc's, since
they are familiar with this stuff, although maybe not ZFS
specifics.
>
>
> --
> Andriy Gapon
> ___
> 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"
___
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: Physbio changes final call for tests and reviews
On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: > Hi, > I finished the last (insignificant) missed bits in the Jeff' physbio > work. Now I am asking for the last round of testing and review, esp. for > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > controllers which drivers are changed by the patchset. Please do test > this before the patchset is committed into HEAD ! > > The plan is to commit the patch somewhere in two weeks from this moment. > The patch is required for the finalizing of the unmapped I/O work for UFS > I did in parallel, which I hope to finish shortly after the commit. > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff > First tests on sparc64 with ata(4), mpt(4) and sym(4) look good (to be sure I still need to test with a machine using a streaming buffer in addition to the IOMMU, though). However, by accident I noticed that your patch (i.e. stock head is fine) somehow breaks smartd of smartmontools with ata(4): root@b1k2:/root # smartd ata3: timeout waiting for write DRQ The machine just hangs at this point (it's also strange that the above message is from the PIO rather than from the DMA path). One note: mjacob@ probably will be annoyed if you don't wrap the changes to isp(4) in __FreeBSD_version so the same source still compiles on older ones. Marius ___ 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"
Physbio changes final call for tests and reviews
Hi, I finished the last (insignificant) missed bits in the Jeff' physbio work. Now I am asking for the last round of testing and review, esp. for the !x86 architectures. Another testing focus are the SCSI HBAs and RAID controllers which drivers are changed by the patchset. Please do test this before the patchset is committed into HEAD ! The plan is to commit the patch somewhere in two weeks from this moment. The patch is required for the finalizing of the unmapped I/O work for UFS I did in parallel, which I hope to finish shortly after the commit. Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff Thank you in advance. pgpLMY3ajuk5x.pgp Description: PGP signature
Re: scheduler->swapper, SI_SUB_RUN_SCHEDULER->SI_SUB_LAST
On Sat, Feb 02, 2013 at 01:50:40PM +0200, Andriy Gapon wrote: > > I would like to propose the following mostly cosmetic change: > http://people.freebsd.org/~avg/scheduler-swapper.diff > > This is something that bit me early in my FreeBSD days, so I am kind of > obsessed > with it. > The current naming is confusing/misleading indeed. > And magic properties of SI_SUB_RUN_SCHEDULER:SI_ORDER_LAST is a "hidden gem". You may remove the Giant unlock from the scheduler()/swapper() as well then, doing it before the swapper() call in the mi_startup(). Note that the wait chain for the idle swapper is still called "sched". pgpoffOjD0HeF.pgp Description: PGP signature
scheduler->swapper, SI_SUB_RUN_SCHEDULER->SI_SUB_LAST
I would like to propose the following mostly cosmetic change: http://people.freebsd.org/~avg/scheduler-swapper.diff This is something that bit me early in my FreeBSD days, so I am kind of obsessed with it. The current naming is confusing/misleading indeed. And magic properties of SI_SUB_RUN_SCHEDULER:SI_ORDER_LAST is a "hidden gem". -- Andriy Gapon ___ 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: some questions on kern_linker and pre-loaded modules
on 28/01/2013 17:40 John Baldwin said the following: > Yes, I think it is too hard at present to safely allow a linker file to > override the same module in a kernel, so the duplicate linker file should > just be rejected entirely. I'm not sure if your change is completely > correct for that. Incidentally that particular patch was broken. Here is a working patch: http://people.freebsd.org/~avg/linker_file_register_modules-linker_kernel_file.diff But I really need to get a better understanding of the bigger picture and then discuss what has to be done in that scope. I plan to write a larger response to your complete followup. Thank you. -- Andriy Gapon ___ 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"
