Allocating physical memory without a kernel mapping
Hi, I'm currently trying to finish the R0 memory implementation[1] of FreeBSD for VirtualBox. One of the missing methods allocates physical non contiguous pages which don't need to have a kernel mapping (rtR0MemObjNativeAllocPhysNC). I'm using vm_phys_alloc_contig to achieve this. The pages are than mapped into the user space VM process using pmap_enter (rtR0MemObjNativeMapUser) and if they are not needed anymore vm_page_free_toq is used to free the pages (rtR0MemObjNativeFree). Everything works as long as the VM runs but if the VM process terminates and I do something else the host will panic at some point (usually when I try to start a gnome session) with "pmap_enter: missing reference to page table page "[2]. There seems to some problem with the wire count of that page but I can't see what I'm doing wrong at the moment. Thanks in advance for any help. Regards, Alexander Eichner [1] http://www.virtualbox.org/browser/trunk/src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c?rev=26899 [2]http://fxr.watson.org/fxr/source/amd64/amd64/pmap.c?im=bigexcerpts#L3076 __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: package building failure irritation
% fgrep 'Directory not empty' inkscape.txt rmdir: /work/ports/devel/boost-libs/work: Directory not empty rmdir: /work/ports/x11-toolkits/gtkmm24/work: Directory not empty rmdir: /work/ports/devel/boehm-gc/work: Directory not empty rmdir: /work/ports/math/gsl/work: Directory not empty rmdir: /work/ports/textproc/gtkspell/work: Directory not empty rmdir: /work/ports/graphics/libwpg/work: Directory not empty rmdir: /work/ports/graphics/ImageMagick/work: Directory not empty rmdir: /work/ports/textproc/p5-XML-XQL/work: Directory not empty rmdir: /work/ports/devel/boost-jam/work: Directory not empty rmdir: /work/ports/devel/icu/work: Directory not empty rmdir: /work/ports/devel/glibmm/work: Directory not empty rmdir: /work/ports/graphics/cairomm/work: Directory not empty rmdir: /work/ports/x11-toolkits/pangomm/work: Directory not empty This tells me that either there is another build running in parallel, or /work is mounted from a dodgy NFS server. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
jhell schrieb am 2010-03-01:
> On Sun, 28 Feb 2010 11:54, alexbestms@ wrote:
> >Gary Jennejohn schrieb am 2010-02-28:
> >>On Sat, 27 Feb 2010 14:49:58 +0100 (CET)
> >>Alexander Best wrote:
> >>>how about something like this?
> >>Based on a quick look it seems OK to me.
> >>Have you tested it?
> >i did. it works when `make cleanworld` is being run from /usr/src.
> >i'm not
> >sure however what the
> >.if ${.CURDIR} == ${.OBJDIR} || ${.CURDIR}/obj == ${.OBJDIR}
> >.if exists(${BW_CANONICALOBJDIR}/)
> >statement is for so i didn't include the lib32 cleanup in that
> >clause. my
> >guess is that it's used to catch the case where `make cleanworld`
> >is being run
> >in /usr/obj/usr/src
> You can't run make from a obj directory there is no Makefile,
> Targets or spoons. ;)
> This line here:
> BW_CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
> Allows the end-user to set MAKEOBJDIRPREFIX in their environment and
> have the obj directory somewhere other than CANONICALOBJDIR.
> BW is an abbreviation for "buildworld".
ah. thanks for the hint. i guess i'll change the patch so lib32 gets also
removed when the user has specified a different obj directory.
> >cheers.
> >alex
> >>---
> >>Gary Jennejohn
> >___
> >freebsd-hackers@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >To unsubscribe, send any mail to
> >"freebsd-hackers-unsubscr...@freebsd.org"
> --
> jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: package building failure irritation
On 2010-03-01 14:34:50, Dag-Erling Smørgrav wrote: > % fgrep 'Directory not empty' inkscape.txt > rmdir: /work/ports/devel/boost-libs/work: Directory not empty > rmdir: /work/ports/x11-toolkits/gtkmm24/work: Directory not empty > rmdir: /work/ports/devel/boehm-gc/work: Directory not empty > rmdir: /work/ports/math/gsl/work: Directory not empty > rmdir: /work/ports/textproc/gtkspell/work: Directory not empty > rmdir: /work/ports/graphics/libwpg/work: Directory not empty > rmdir: /work/ports/graphics/ImageMagick/work: Directory not empty > rmdir: /work/ports/textproc/p5-XML-XQL/work: Directory not empty > rmdir: /work/ports/devel/boost-jam/work: Directory not empty > rmdir: /work/ports/devel/icu/work: Directory not empty > rmdir: /work/ports/devel/glibmm/work: Directory not empty > rmdir: /work/ports/graphics/cairomm/work: Directory not empty > rmdir: /work/ports/x11-toolkits/pangomm/work: Directory not empty > > This tells me that either there is another build running in parallel, or > /work is mounted from a dodgy NFS server. 'Lo, There's certainly no parallel building going on, but /work is nullfs mounted (from ZFS). Could this cause the above? xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: package building failure irritation
xorquew...@googlemail.com writes: > There's certainly no parallel building going on, but /work is nullfs > mounted (from ZFS). Could this cause the above? Not sure. Why are you using nullfs? Can you show us the contents of those directories? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Allocating physical memory without a kernel mapping
On Mon, Mar 1, 2010 at 10:59 AM, Alexander Eichner wrote:
> Hi,
>
> I'm currently trying to finish the R0 memory implementation[1] of FreeBSD for
> VirtualBox. One of the missing methods allocates physical non contiguous
> pages which don't need to have a kernel mapping
> (rtR0MemObjNativeAllocPhysNC). I'm using vm_phys_alloc_contig to achieve
> this. The pages are than mapped into the user space VM process using
> pmap_enter (rtR0MemObjNativeMapUser) and if they are not needed anymore
> vm_page_free_toq is used to free the pages (rtR0MemObjNativeFree).
> Everything works as long as the VM runs but if the VM process terminates and
> I do something else the host will panic at some point (usually when I try to
> start a gnome session) with "pmap_enter: missing reference to page table page
> "[2].
> There seems to some problem with the wire count of that page but I can't see
> what I'm doing wrong at the moment.
> Thanks in advance for any help.
Please, try this patch against revision 26898.
--- memobj-r0drv-freebsd.c.orig 2010-02-26 10:28:44.0 +0100
+++ memobj-r0drv-freebsd.c 2010-02-26 13:55:35.0 +0100
@@ -209,8 +209,7 @@ int rtR0MemObjNativeAllocPage(PPRTR0MEMO
vm_page_t pPage;
pPage = vm_page_alloc(pMemFreeBSD->pObject, PageIndex,
- VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM |
- VM_ALLOC_WIRED);
+ VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM);
#if __FreeBSD_version >= 80 /** @todo Find exact version number */
/* Fixes crashes during VM termination on
FreeBSD8-CURRENT amd64
@@ -220,9 +219,6 @@ int rtR0MemObjNativeAllocPage(PPRTR0MEMO
if (pPage)
{
-vm_page_lock_queues();
-vm_page_wire(pPage);
-vm_page_unlock_queues();
/* Put the page into the page table now. */
#if __FreeBSD_version >= 701105
pmap_enter(kernel_map->pmap, AddressDst,
VM_PROT_NONE, pPage,
@@ -253,6 +249,8 @@ int rtR0MemObjNativeAllocPage(PPRTR0MEMO
if (rc == VINF_SUCCESS)
{
+ vm_map_wire(kernel_map, MapAddress,
MapAddress + cb,
+ VM_MAP_WIRE_SYSTEM |
VM_MAP_WIRE_NOHOLES);
pMemFreeBSD->Core.pv = (void *)MapAddress;
*ppMem = &pMemFreeBSD->Core;
return VINF_SUCCESS;
>
> Regards,
> Alexander Eichner
>
> [1]
> http://www.virtualbox.org/browser/trunk/src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c?rev=26899
> [2]http://fxr.watson.org/fxr/source/amd64/amd64/pmap.c?im=bigexcerpts#L3076
>
> __
> Do You Yahoo!?
> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
> gegen Massenmails.
> http://mail.yahoo.com
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: package building failure irritation
On Mon, Mar 01, 2010 at 01:58:29PM +, xorquew...@googlemail.com wrote: > On 2010-03-01 14:34:50, Dag-Erling Smørgrav wrote: > > % fgrep 'Directory not empty' inkscape.txt > > rmdir: /work/ports/devel/boost-libs/work: Directory not empty > > ... > > rmdir: /work/ports/x11-toolkits/pangomm/work: Directory not empty > > > > This tells me that either there is another build running in parallel, or > > /work is mounted from a dodgy NFS server. > > 'Lo, > > There's certainly no parallel building going on, but /work is nullfs > mounted (from ZFS). Could this cause the above? Caveat: this may be a "red herring." But please note that for stable/7 prior to r190970 (2009-04-12 10:43:41 -0700) or head prior to r189287 (2009-03-02 12:51:39 -0800; prior to stable/8 branch, so it's part of stable/8 already), there was a rather nasty (IMO, as I spent a fair amount of time trying to figure out what was going on) such that a FreeBSD NFS client would see precisely the above symptoms if: * A process on the FreEBSD NFS client performed a chdir() to a directory that was NFS-mounted, then started a "recursive descent" (e.g., "tar c ..." or "rm -fr") from that directory and * Some other process on the same FreeBSD NFS client attempted to perform an unmount() of the NFS-mounted file system referenced above. Note that the unmount() is doomed, as the file system is active -- a directory in it is the $cwd for the first process, after all. This may seem an unlikely -- possibly even perverse -- combination of events. However, it is actually SOP for amd(8): the master amd process periodically forks a child to perform an attempted unmount of auto-mounted NFS file systems periodically, and the way amd realizes that the file system is not eligible for unmounting is if the attempted unmount() gets EBUSY. It is *possible* that something akin to this mechanism *might* be affecting the OP. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp2kxBStWDpC.pgp Description: PGP signature
Re: [patch] extending {amd64|i386} cpu info
Garrett Cooper schrieb am 2010-03-01: > On Sun, Feb 28, 2010 at 5:43 PM, jhell wrote: > > On Fri, 26 Feb 2010 22:19, alexbestms@ wrote: > >> hi there, > >> i always forget how to decipher model and family from the cpu id. > >> of > >> course > >> there're 3rd party tools to do that for you, but instead i decided > >> to hack > >> the > >> kernel. ;) > >> maybe somebody finds these changes useful. > >> cheers. > >> alex > > What about the other arch's ? I only see i386 and amd64. I would > > think if > > this functionality is going to "make it in" that it should be done > > consistantly across the board, the way it is now. i'll have a look at the other archs to see if implementing this can be done just as easy as with i386 and amd64. alex > This is trivial enough of a change that I think it should be done > for amd64/i386. I say that because it may be a bit more difficult for > arm, mips, powerpc, sparc64, etc (probably not as much...). > Thanks, > -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: package building failure irritation
On 2010-03-01 15:10:16, Dag-Erling Smørgrav wrote: > xorquew...@googlemail.com writes: > > There's certainly no parallel building going on, but /work is nullfs > > mounted (from ZFS). Could this cause the above? > > Not sure. Why are you using nullfs? Basically because "I don't know any better". > Can you show us the contents of those directories? I'm off out, but I'll post the contents of /work when I get back tonight. xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys)
On Sun, 28 Feb 2010 18:26:05 -0800
Garrett Cooper wrote:
> On Sun, Feb 28, 2010 at 5:11 PM, Alexander Best wrote:
> > i have a small test app to check {rm|mk}dir()'s errnos with certain args
> > like
> > /, ., /proc and non-empty dirs. i'll submit it to this thread as soon as i
> > also add testcases for syscalls like rename(), unlink(), etc.
> >
> > most of the errno codes returned after applying your patch look correct. i
> > wonder however why rmdir("/proc") returns EACCESS as unprivileged user.
> > wouldn't it make more sense to also return EBUSY? why complain about
> > permission related matters when even root won't be able to perform the
> > operation.
>
> Hmm.. good question. POSIX doesn't fully expound on this case
> (http://www.opengroup.org/onlinepubs/009695399/functions/rmdir.html),
> and either seem possible...
>
This maybe from rmdir(2)?
[EACCES] Write permission is denied on the directory containing
the link to be removed.
ls -ldo /
drwxr-xr-x 44 root wheel - 1536 Feb 28 18:36 /
ls -ldo /proc
dr-xr-xr-x 2 root wheel - 512 Sep 7 2008 /proc
---
Gary Jennejohn
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [patch] extending {amd64|i386} cpu info
On Friday 26 February 2010 10:19:46 pm Alexander Best wrote: > hi there, > > i always forget how to decipher model and family from the cpu id. of course > there're 3rd party tools to do that for you, but instead i decided to hack the > kernel. ;) > > maybe somebody finds these changes useful. This should go in if only because the model and family are no longer trivial things to figure out. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 32 bit Linux lseek missing overflow check (was: Re: Linuxolator patches: stat and lseek SEEK_END for disk devices)
On Friday 26 February 2010 4:09:52 pm Juergen Lock wrote:
> On Fri, Feb 26, 2010 at 11:21:05AM -0500, John Baldwin wrote:
> > On Thursday 25 February 2010 3:28:50 pm Juergen Lock wrote:
> > > On Tue, Feb 23, 2010 at 10:50:10PM +0100, Juergen Lock wrote:
> > > > Hi!
> > > >
> > > > Before this gets buried on -hackers in another thead... :)
> > > >
> > > > I now have disks appear as block devices for Linux processes (there
> > > > already was commented out code for that in linux_stats.c, I hope my
> > > > version is now `correct enough' to be usable [1]), and I made a simple
> > > > patch to make lseek SEEK_END (L_XTND in the source) dtrt on disk
> > > > devices too by simply invoking the DIOCGMEDIASIZE ioctl there; [2]
> > > > both of these things are what (some) Linux processes expect.
> > > >
> > > > Patches are here: (made on stable/8, if they don't apply on head
> > > > I'll have to make extra versions for that...)
> > > > http://people.freebsd.org/~nox/linuxdisk-blk.patch [1]
> > > > http://people.freebsd.org/~nox/lseek-seek_end.patch [2]
> > > >
> > > > And yes, with these patches the Linux bsdtar mentioned on -hackers
> > > > in the `"tar tfv /dev/cd0" speedup patch' thread now also runs fast
> > > > on FreeBSD. :)
> > >
> > > I now added an vn_isdisk() check to the second patch after comments from
> > > julian, and I made a new patch that adds an overflow check to the 32 bit
> > > linux lseek: (also at
> > > http://people.freebsd.org/~nox/linux-lseek-overflow.patch
> > > )
> >
> > Hmm, when I asked Bruce, he actually said it was a feature that you didn't
use
> > vn_isdisk(). He also suggested that the proper way to fix lseek on
devices is
> > to fix stat in devfs to return a non-zero size. I have a possible fix to
do
> > that but haven't tested it yet:
> >
> > Index: devfs_vnops.c
> > ===
> > --- devfs_vnops.c (revision 204207)
> > +++ devfs_vnops.c (working copy)
> > @@ -44,6 +44,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -564,7 +565,11 @@
> > struct vattr *vap = ap->a_vap;
> > int error = 0;
> > struct devfs_dirent *de;
> > + struct cdevsw *dsw;
> > + struct thread *td;
> > + struct file *fpop;
> > struct cdev *dev;
> > + off_t size;
> >
> > de = vp->v_data;
> > KASSERT(de != NULL, ("Null dirent in devfs_getattr vp=%p", vp));
> > @@ -612,6 +617,18 @@
> > vap->va_ctime = dev->si_ctime;
> >
> > vap->va_rdev = cdev2priv(dev)->cdp_inode;
> > +
> > + dsw = dev_refthread(dev);
> > + if (dsw != NULL) {
> > + td = curthread;
> > + fpop = td->td_fpop;
> > + td->td_fpop = NULL;
> > + if (dsw->d_ioctl(dev, DIOCGMEDIASIZE, (caddr_t)&size,
> > + FREAD, td) == 0)
> > + vap->va_size = size;
> > + td->td_fpop = fpop;
> > + dev_relthread(dev);
> > + }
> > }
> > vap->va_gen = 0;
> > vap->va_flags = 0;
> >
>
> I had to add an D_DISK check, else it would panic at boot in a revoke
> syscall in ttydev_ioctl in ttydev_enter, apparently in the tty_lock call:
> (I didn't get a dump as it panic'd way too early in boot)
> http://fxr.watson.org/fxr/source/kern/tty.c#L159
>
> Maybe dev->si_drv1 is null here?
> http://fxr.watson.org/fxr/source/kern/tty.c#L486
>
> Anyway, with the D_DISK check added the patch seems to work:
Unfortunately it panics in g_dev_ioctl() with INVARIANTS enabled. I will bug
phk about that.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: package building failure irritation
xorquew...@googlemail.com writes: > Dag-Erling Smørgrav writes: > > xorquew...@googlemail.com writes: > > > There's certainly no parallel building going on, but /work is nullfs > > > mounted (from ZFS). Could this cause the above? > > Not sure. Why are you using nullfs? > Basically because "I don't know any better". That's begging the question... Clearly you're using nullfs because you need something done that you think nullfs can do for you. I'd like to know what that is, because I suspect that you don't actually need it, and it might be the source of your problems. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
jhell schrieb am 2010-03-01:
> On Sun, 28 Feb 2010 11:54, alexbestms@ wrote:
> >Gary Jennejohn schrieb am 2010-02-28:
> >>On Sat, 27 Feb 2010 14:49:58 +0100 (CET)
> >>Alexander Best wrote:
> >>>how about something like this?
> >>Based on a quick look it seems OK to me.
> >>Have you tested it?
> >i did. it works when `make cleanworld` is being run from /usr/src.
> >i'm not
> >sure however what the
> >.if ${.CURDIR} == ${.OBJDIR} || ${.CURDIR}/obj == ${.OBJDIR}
> >.if exists(${BW_CANONICALOBJDIR}/)
> >statement is for so i didn't include the lib32 cleanup in that
> >clause. my
> >guess is that it's used to catch the case where `make cleanworld`
> >is being run
> >in /usr/obj/usr/src
> You can't run make from a obj directory there is no Makefile,
> Targets or spoons. ;)
> This line here:
> BW_CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
> Allows the end-user to set MAKEOBJDIRPREFIX in their environment and
> have the obj directory somewhere other than CANONICALOBJDIR.
oh. and btw: wouldn't it be reasonable to prevent a user shooting himself in
the foot if he has the brilliant idea of setting "MAKEOBJDIRPREFIX = /" ?
alex
> BW is an abbreviation for "buildworld".
> >cheers.
> >alex
> >>---
> >>Gary Jennejohn
> >___
> >freebsd-hackers@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >To unsubscribe, send any mail to
> >"freebsd-hackers-unsubscr...@freebsd.org"
> --
> jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: package building failure irritation
'Lo, Here's the current state of '/work': http://coreland.ath.cx/tmp/work.txt On 2010-03-01 20:08:45, Dag-Erling Smørgrav wrote: > That's begging the question... Clearly you're using nullfs because you > need something done that you think nullfs can do for you. I'd like to > know what that is, because I suspect that you don't actually need it, > and it might be the source of your problems. I agree, ZFS likely has something to replace my use of nullfs. I used it previously to do the following using only UFS filesystems: Basically, I have a ton of jails and each jail mounts a shared 'tmp', and possibly unshared 'pkg' 'work' 'distfiles' and 'ports' directories: /storage/jails/8.0/x86_64/mk4/pkg /jail/8.0-amd64-mk4/pkgnullfs rw /storage/jails/8.0/x86_64/mk4/work /jail/8.0-amd64-mk4/work nullfs rw /storage/distfiles /jail/8.0-amd64-mk4/distfiles nullfs rw /storage/ports /jail/8.0-amd64-mk4/ports nullfs ro /storage/shared_tmp /jail/8.0-amd64-mk4/shared_tmp nullfs rw xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
snd_amd5536 for freebsd8.0
Hi, I have an ALIX3d3 board and I'm looking for the audio driver for freebsd 8.0. How do I get it running? Is there a new version of snd_amd5536.ko yet? where can I get it? All I need (at the moment) is playback. thanks for letting me know. -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
jhell schrieb am 2010-03-01:
> On Sun, 28 Feb 2010 11:54, alexbestms@ wrote:
> >Gary Jennejohn schrieb am 2010-02-28:
> >>On Sat, 27 Feb 2010 14:49:58 +0100 (CET)
> >>Alexander Best wrote:
> >>>how about something like this?
> >>Based on a quick look it seems OK to me.
> >>Have you tested it?
> >i did. it works when `make cleanworld` is being run from /usr/src.
> >i'm not
> >sure however what the
> >.if ${.CURDIR} == ${.OBJDIR} || ${.CURDIR}/obj == ${.OBJDIR}
> >.if exists(${BW_CANONICALOBJDIR}/)
> >statement is for so i didn't include the lib32 cleanup in that
> >clause. my
> >guess is that it's used to catch the case where `make cleanworld`
> >is being run
> >in /usr/obj/usr/src
> You can't run make from a obj directory there is no Makefile,
> Targets or spoons. ;)
> This line here:
> BW_CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
> Allows the end-user to set MAKEOBJDIRPREFIX in their environment and
> have the obj directory somewhere other than CANONICALOBJDIR.
this patch should take care of the lib32 dir with MAKEOBJDIRPREFIX being
defined or undefined.
cheers.
alex
> BW is an abbreviation for "buildworld".
> >cheers.
> >alex
> >>---
> >>Gary Jennejohn
> >___
> >freebsd-hackers@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >To unsubscribe, send any mail to
> >"freebsd-hackers-unsubscr...@freebsd.org"
> --
> jhell
Index: Makefile
===
--- Makefile(revision 204540)
+++ Makefile(working copy)
@@ -159,6 +159,11 @@
-chflags -R 0 ${.OBJDIR}
rm -rf ${.OBJDIR}/*
.endif
+.if exists(${MAKEOBJDIRPREFIX}/lib32${.CURDIR}/)
+-rm -rf ${MAKEOBJDIRPREFIX}/lib32${.CURDIR}/*
+-chflags -R 0 ${MAKEOBJDIRPREFIX}/lib32${.CURDIR}
+rm -rf ${MAKEOBJDIRPREFIX}/lib32${.CURDIR}/*
+.endif
#
# Handle the user-driven targets, using the source relative mk files.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
jhell schrieb am 2010-03-01:
> On Sun, 28 Feb 2010 11:54, alexbestms@ wrote:
> >Gary Jennejohn schrieb am 2010-02-28:
> >>On Sat, 27 Feb 2010 14:49:58 +0100 (CET)
> >>Alexander Best wrote:
> >>>how about something like this?
> >>Based on a quick look it seems OK to me.
> >>Have you tested it?
> >i did. it works when `make cleanworld` is being run from /usr/src.
> >i'm not
> >sure however what the
> >.if ${.CURDIR} == ${.OBJDIR} || ${.CURDIR}/obj == ${.OBJDIR}
> >.if exists(${BW_CANONICALOBJDIR}/)
> >statement is for so i didn't include the lib32 cleanup in that
> >clause. my
> >guess is that it's used to catch the case where `make cleanworld`
> >is being run
> >in /usr/obj/usr/src
> You can't run make from a obj directory there is no Makefile,
> Targets or spoons. ;)
> This line here:
> BW_CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
> Allows the end-user to set MAKEOBJDIRPREFIX in their environment and
> have the obj directory somewhere other than CANONICALOBJDIR.
sorry. the patch contained spaces instead of tabs making it fail when deleting
lib32. here's the right patch. sorry for the noise.
i'll submit this patch along with a few style cleanups of Makefile as a pr so
the changes don't get lost.
alex
> BW is an abbreviation for "buildworld".
> >cheers.
> >alex
> >>---
> >>Gary Jennejohn
> >___
> >freebsd-hackers@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >To unsubscribe, send any mail to
> >"freebsd-hackers-unsubscr...@freebsd.org"
> --
> jhell
Index: Makefile
===
--- Makefile(revision 204540)
+++ Makefile(working copy)
@@ -159,6 +159,11 @@
-chflags -R 0 ${.OBJDIR}
rm -rf ${.OBJDIR}/*
.endif
+.if exists(${MAKEOBJDIRPREFIX}/lib32${.CURDIR}/)
+ -rm -rf ${MAKEOBJDIRPREFIX}/lib32${.CURDIR}/*
+ -chflags -R 0 ${MAKEOBJDIRPREFIX}/lib32${.CURDIR}
+ rm -rf ${MAKEOBJDIRPREFIX}/lib32${.CURDIR}/*
+.endif
#
# Handle the user-driven targets, using the source relative mk files.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
On Mon, 1 Mar 2010 14:52, alexbestms@ wrote: oh. and btw: wouldn't it be reasonable to prevent a user shooting himself in the foot if he has the brilliant idea of setting "MAKEOBJDIRPREFIX = /" ? alex Trying to match something like this is going to get out of control. Though this is a nice idea but why should a user be prevented from doing such things ?. Boiling down these are not variables that usually have to be changed and if they are changed the user has done a little bit of research and is more advanced than most and recognizes that / is not a option. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kernel malloc() and free()
Hi, I am looking at the code that allocates and frees kernel memory. I understand that allocating kernel memory is quite different from the user level mallocs. In case of user level mallocs, we allocate requested size + 4 bytes and store the requested size in the additional 4 bytes. However, in the case of kernel, allocating an additional 4 bytes is a overhead since the request might fall in the next bucket. I looked into the code and the documentation in the file uma_int.h, but I don't quite understand the relation between slabs, zones and keg. How do we determine the size of the memory that we are trying to free from given the virtual address? Thanks in advance for the help. -shrivatsan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
unable to offline a failing drive in a zfs RAIDZ
I have a raidz setup as per the handbook but when I attempt to "offline" a failing drive it will not let me: kate# zpool status -c invalid option 'c' usage: status [-vx] [pool] ... kate# zpool status -v pool: storage state: ONLINE scrub: resilver completed with 0 errors on Mon Mar 1 17:36:48 2010 config: NAMESTATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1ONLINE 0 0 0 ad7 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad9 ONLINE 0 0 0 ad10ONLINE 0 0 0 ad12ONLINE 0 0 0 errors: No known data errors kate# zpool offline storage ad12 cannot offline ad12: no valid replicas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [patch] extending {amd64|i386} cpu info
jhell schrieb am 2010-03-01: > On Fri, 26 Feb 2010 22:19, alexbestms@ wrote: > >hi there, > >i always forget how to decipher model and family from the cpu id. > >of course > >there're 3rd party tools to do that for you, but instead i decided > >to hack the > >kernel. ;) > >maybe somebody finds these changes useful. > >cheers. > >alex > What about the other arch's ? I only see i386 and amd64. I would > think if this functionality is going to "make it in" that it should > be done consistantly across the board, the way it is now. just had a look at the other archs and in fact implementing these changes is not that easy as on i386 and amd64. talking about consistency: i found the cpu info outputs on arm, i64, etc. to differ from the ones on i386 and amd64. so in fact there is inconsistency present atm. i also think that on some archs it's not possible to output cpu id, stepping, family and model simply because there's no cpu instruction (CPUID or something similar) returning those info for freebsd to use. cheers. alex > -- > jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
jhell schrieb am 2010-03-01:
> On Sun, 28 Feb 2010 11:54, alexbestms@ wrote:
> >Gary Jennejohn schrieb am 2010-02-28:
> >>On Sat, 27 Feb 2010 14:49:58 +0100 (CET)
> >>Alexander Best wrote:
> >>>how about something like this?
> >>Based on a quick look it seems OK to me.
> >>Have you tested it?
> >i did. it works when `make cleanworld` is being run from /usr/src.
> >i'm not
> >sure however what the
> >.if ${.CURDIR} == ${.OBJDIR} || ${.CURDIR}/obj == ${.OBJDIR}
> >.if exists(${BW_CANONICALOBJDIR}/)
> >statement is for so i didn't include the lib32 cleanup in that
> >clause. my
> >guess is that it's used to catch the case where `make cleanworld`
> >is being run
> >in /usr/obj/usr/src
> You can't run make from a obj directory there is no Makefile,
> Targets or spoons. ;)
> This line here:
> BW_CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
> Allows the end-user to set MAKEOBJDIRPREFIX in their environment and
> have the obj directory somewhere other than CANONICALOBJDIR.
> BW is an abbreviation for "buildworld".
pr submitted. it's amd64/144405.
alex
> >cheers.
> >alex
> >>---
> >>Gary Jennejohn
> >___
> >freebsd-hackers@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >To unsubscribe, send any mail to
> >"freebsd-hackers-unsubscr...@freebsd.org"
> --
> jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
jhell schrieb am 2010-03-02:
> On Mon, 1 Mar 2010 14:52, alexbestms@ wrote:
> >oh. and btw: wouldn't it be reasonable to prevent a user shooting
> >himself in
> >the foot if he has the brilliant idea of setting "MAKEOBJDIRPREFIX
> >= /" ?
> >alex
> Trying to match something like this is going to get out of control.
> Though this is a nice idea but why should a user be prevented from
> doing such things ?.
> Boiling down these are not variables that usually have to be changed
> and if they are changed the user has done a little bit of research
> and is more advanced than most and recognizes that / is not a option.
hmmm...so you think something like this won't be useful?
alex
> --
> jhell
Index: Makefile
===
--- Makefile(revision 204540)
+++ Makefile(working copy)
@@ -112,6 +112,9 @@
.error MAKEOBJDIRPREFIX can only be set in environment, not as a global\
(in make.conf(5)) or command-line variable.
.endif
+.if ${MAKEOBJDIRPREFIX} == "/"
+.error MAKEOBJDIRPREFIX musn't point to the root directory.
+.endif
MAKEPATH= ${MAKEOBJDIRPREFIX}${.CURDIR}/make.${MACHINE}
BINMAKE= \
`if [ -x ${MAKEPATH}/make ]; then echo ${MAKEPATH}/make; else echo
${MAKE}; fi` \
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
On Mon, 1 Mar 2010 19:45, alexbestms@ wrote: jhell schrieb am 2010-03-02: On Mon, 1 Mar 2010 14:52, alexbestms@ wrote: oh. and btw: wouldn't it be reasonable to prevent a user shooting himself in the foot if he has the brilliant idea of setting "MAKEOBJDIRPREFIX = /" ? alex Trying to match something like this is going to get out of control. Though this is a nice idea but why should a user be prevented from doing such things ?. Boiling down these are not variables that usually have to be changed and if they are changed the user has done a little bit of research and is more advanced than most and recognizes that / is not a option. hmmm...so you think something like this won't be useful? alex -- jhell What about the case where MAKEOBJDIRPREFIX="/ usr/obj/dir". I suppose make will fail in this case but I don't have anything to test this situation in ATM. But aside from that "typical user" never adjusts such things and it adds just a slight bit more overhead to the build that can be avoided altoghter by the user reading what they type. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
jhell schrieb am 2010-03-02: > On Mon, 1 Mar 2010 19:45, alexbestms@ wrote: > >jhell schrieb am 2010-03-02: > >>On Mon, 1 Mar 2010 14:52, alexbestms@ wrote: > >>>oh. and btw: wouldn't it be reasonable to prevent a user shooting > >>>himself in > >>>the foot if he has the brilliant idea of setting "MAKEOBJDIRPREFIX > >>>= /" ? > >>>alex > >>Trying to match something like this is going to get out of control. > >>Though this is a nice idea but why should a user be prevented from > >>doing such things ?. > >>Boiling down these are not variables that usually have to be > >>changed > >>and if they are changed the user has done a little bit of research > >>and is more advanced than most and recognizes that / is not a > >>option. > >hmmm...so you think something like this won't be useful? > >alex > >>-- > >>jhell > What about the case where MAKEOBJDIRPREFIX="/ usr/obj/dir". I > suppose make will fail in this case but I don't have anything to > test this situation in ATM. nope. just tested it. only a real MAKEOBJDIRPREFIX="/" triggers the error. > But aside from that "typical user" never adjusts such things and it > adds just a slight bit more overhead to the build that can be > avoided altoghter by the user reading what they type. you're probably right. regular users will most definitely never come across MAKEOBJDIRPREFIX and if some advanced user decides to set it to "/" that's up to him. alex > -- > jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: `make cleanworld` and /usr/obj/lib32/usr/src
On Mon, Mar 1, 2010 at 5:19 PM, Alexander Best wrote: > jhell schrieb am 2010-03-02: > >> On Mon, 1 Mar 2010 19:45, alexbestms@ wrote: >> >jhell schrieb am 2010-03-02: > >> >>On Mon, 1 Mar 2010 14:52, alexbestms@ wrote: > >> >>>oh. and btw: wouldn't it be reasonable to prevent a user shooting >> >>>himself in >> >>>the foot if he has the brilliant idea of setting "MAKEOBJDIRPREFIX >> >>>= /" ? > >> >>>alex > > >> >>Trying to match something like this is going to get out of control. >> >>Though this is a nice idea but why should a user be prevented from >> >>doing such things ?. > >> >>Boiling down these are not variables that usually have to be >> >>changed >> >>and if they are changed the user has done a little bit of research >> >>and is more advanced than most and recognizes that / is not a >> >>option. > >> >hmmm...so you think something like this won't be useful? > >> >alex > >> >>-- > >> >>jhell > > >> What about the case where MAKEOBJDIRPREFIX="/ usr/obj/dir". I >> suppose make will fail in this case but I don't have anything to >> test this situation in ATM. > > nope. just tested it. only a real MAKEOBJDIRPREFIX="/" triggers the error. > >> But aside from that "typical user" never adjusts such things and it >> adds just a slight bit more overhead to the build that can be >> avoided altoghter by the user reading what they type. > > you're probably right. regular users will most definitely never come across > MAKEOBJDIRPREFIX and if some advanced user decides to set it to "/" that's up > to him. What about these? /./ /. // I avoided these errors by writing `abspath' for LTP (it was required for GNU make backwards compatibility). jhell is right though ... if you're going to go down this road it's going to be a maintenance mess unless you have something that will abspath the file (and I used 24 or so confusing lines in awk to do it): http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp-dev.git;a=blob;f=scripts/lib/file_functions.sh;h=fd56492569e9bcfe19dd5d35db922cd94df77fb6;hb=HEAD Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
mac_mls mac_biba mac_lomac patches to fix ptys_equal mib support for new /dev/pts in FreeBSD 8
Hi,
Found issues with sysctl mibs security.mac.biba.ptys_equal,
security.mac.lomac.ptys_equal, security.mac.mls.ptys_equal, not supporting
new /dev/pts terminal system in FreeBSD 8, proposed fix for issue.
When using a higher security grade/clearance with mac_mls it prevents
writing to the /dev/pts/5 as its set as mls/low and subjects may not write
to objects with a lower classification level than its own clearance level.
Feb 25 21:42:16 labyrinth sshd[30965]: error: /dev/pts/5: Permission denied
Feb 25 21:42:16 labyrinth sshd[30965]: error: open /dev/tty failed - could
not set controlling tty: Permission denied
-Selphie
Patches:
diff -urNp /usr/src/sys/security-orig/mac_biba/mac_biba.c
/usr/src/sys/security/mac_biba/mac_biba.c
--- /usr/src/sys/security-orig/mac_biba/mac_biba.c 2010-03-01
17:11:30.0 -0800
+++ /usr/src/sys/security/mac_biba/mac_biba.c 2010-03-01
17:16:44.0 -0800
@@ -955,6 +955,7 @@ biba_devfs_create_device(struct ucred *c
biba_type = MAC_BIBA_TYPE_EQUAL;
else if (ptys_equal &&
(strncmp(dev->si_name, "ttyp", strlen("ttyp")) == 0 ||
+ strncmp(dev->si_name, "pts/", strlen("pts/")) == 0 ||
strncmp(dev->si_name, "ptyp", strlen("ptyp")) == 0))
biba_type = MAC_BIBA_TYPE_EQUAL;
else
diff -urNp /usr/src/sys/security-orig/mac_lomac/mac_lomac.c
/usr/src/sys/security/mac_lomac/mac_lomac.c
--- /usr/src/sys/security-orig/mac_lomac/mac_lomac.c2010-03-01
17:11:30.0 -0800
+++ /usr/src/sys/security/mac_lomac/mac_lomac.c 2010-03-01
17:16:23.0 -0800
@@ -1043,6 +1043,7 @@ lomac_devfs_create_device(struct ucred *
lomac_type = MAC_LOMAC_TYPE_EQUAL;
else if (ptys_equal &&
(strncmp(dev->si_name, "ttyp", strlen("ttyp")) == 0 ||
+ strncmp(dev->si_name, "pts/", strlen("pts/")) == 0 ||
strncmp(dev->si_name, "ptyp", strlen("ptyp")) == 0))
lomac_type = MAC_LOMAC_TYPE_EQUAL;
else
diff -urNp /usr/src/sys/security-orig/mac_mls/mac_mls.c
/usr/src/sys/security/mac_mls/mac_mls.c
--- /usr/src/sys/security-orig/mac_mls/mac_mls.c2010-03-01
17:11:30.0 -0800
+++ /usr/src/sys/security/mac_mls/mac_mls.c 2010-03-01
17:15:42.0 -0800
@@ -918,6 +918,7 @@ mls_devfs_create_device(struct ucred *cr
mls_type = MAC_MLS_TYPE_HIGH;
else if (ptys_equal &&
(strncmp(dev->si_name, "ttyp", strlen("ttyp")) == 0 ||
+ strncmp(dev->si_name, "pts/", strlen("pts/")) == 0 ||
strncmp(dev->si_name, "ptyp", strlen("ptyp")) == 0))
mls_type = MAC_MLS_TYPE_EQUAL;
else
fbsd80-mac-devpts-fix.patch
Description: Binary data
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel malloc() and free()
In the last episode (Mar 01), Shrivatsan said: > I am looking at the code that allocates and frees kernel memory. I > understand that allocating kernel memory is quite different from the user > level mallocs. In case of user level mallocs, we allocate requested size > + 4 bytes and store the requested size in the additional 4 bytes. Actually FreeBSD's userland malloc hasn't ever had a 4-byte-per-element overhead like this. All BSD mallocs have been block-based, where all objects in a page are the same size. The original bsd malloc had power-of-2 size groupings (blocks holding the same size objects were linked in a list). phkmalloc was imported in 1995 which moves the block metadata into a "page directory", which is separated from the memory returned by malloc(). The current malloc (jemalloc) has a similar setup but scales much better on SMP systems. http://phk.freebsd.dk/pubs/malloc.pdf http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf > However, in the case of kernel, allocating an additional 4 bytes is a > overhead since the request might fall in the next bucket. I looked into > the code and the documentation in the file uma_int.h, but I don't quite > understand the relation between slabs, zones and keg. How do we determine > the size of the memory that we are trying to free from given the virtual > address? I'm not too familiar with the kernel malloc, but it looks like each keg holds objects of the same size (and a keg may hold multiple slabs), so once you get a pointer to the slab header with the vtoslab() macro, slab->us_keg->uk_size points to the size of the allocation. Hm. Even after some reading, I'm not sure how the slabs keep track of which elements are allocated or free. I expected to find a bitmap somewhere that malloc() sets and free() clears, but I don't see it. Maybe some kernel hacker can explain it better :) Regardless, the size of the allocation at this point isn't important, since you know all the items in the page are the same size. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: unable to offline a failing drive in a zfs RAIDZ
In the last episode (Mar 01), Aryeh Friedman said: > I have a raidz setup as per the handbook but when I attempt to "offline" a > failing drive it will not let me: > > kate# zpool status -c > invalid option 'c' > usage: > status [-vx] [pool] ... > kate# zpool status -v > pool: storage > state: ONLINE > scrub: resilver completed with 0 errors on Mon Mar 1 17:36:48 2010 > config: > > NAMESTATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz1ONLINE 0 0 0 > ad7 ONLINE 0 0 0 > ad8 ONLINE 0 0 0 > ad9 ONLINE 0 0 0 > ad10ONLINE 0 0 0 > ad12ONLINE 0 0 0 > > errors: No known data errors > kate# zpool offline storage ad12 > cannot offline ad12: no valid replicas What version of FreeBSD are you running? This looks like a known bug. It originally worked for mirrors but not RAIDZ vdevs - "zpool offline is a bit too conservative": http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=2171359 , and works for me on a 7-stable kernel: (r...@studio) /root># uname -a FreeBSD studio.evoy.net 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #53: Tue Feb 2 17:19:46 CST 2010 z...@studio.evoy.net:/usr/src-7/sys/amd64/compile/STUDIO amd64 (r...@studio) /root># mdconfig -a -t swap -s 1g ; mdconfig -a -t swap -s 1g ; mdconfig -a -t swap -s 1g md1 md2 md3 (r...@studio) /root># zpool create dummy raidz md1 md2 md3 (r...@studio) /root># zpool offline dummy md2 (r...@studio) /root># zpool status dummy pool: dummy state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: none requested config: NAMESTATE READ WRITE CKSUM dummy DEGRADED 0 0 0 raidz1DEGRADED 0 0 0 md1 ONLINE 0 0 0 md2 OFFLINE 0 0 0 md3 ONLINE 0 0 0 -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: unable to offline a failing drive in a zfs RAIDZ
Dan Nelson wrote: In the last episode (Mar 01), Aryeh Friedman said: I have a raidz setup as per the handbook but when I attempt to "offline" a failing drive it will not let me: kate# zpool status -c invalid option 'c' usage: status [-vx] [pool] ... kate# zpool status -v pool: storage state: ONLINE scrub: resilver completed with 0 errors on Mon Mar 1 17:36:48 2010 config: NAMESTATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1ONLINE 0 0 0 ad7 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad9 ONLINE 0 0 0 ad10ONLINE 0 0 0 ad12ONLINE 0 0 0 errors: No known data errors kate# zpool offline storage ad12 cannot offline ad12: no valid replicas What version of FreeBSD are you running? This looks like a known bug. It originally worked for mirrors but not RAIDZ vdevs - "zpool offline is a bit too conservative": FreeBSD kate.istudentunion.com 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 9 21:30:43 UTC 2009 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=2171359 , and works for me on a 7-stable kernel: (r...@studio) /root># uname -a FreeBSD studio.evoy.net 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #53: Tue Feb 2 17:19:46 CST 2010 z...@studio.evoy.net:/usr/src-7/sys/amd64/compile/STUDIO amd64 (r...@studio) /root># mdconfig -a -t swap -s 1g ; mdconfig -a -t swap -s 1g ; mdconfig -a -t swap -s 1g md1 md2 md3 (r...@studio) /root># zpool create dummy raidz md1 md2 md3 (r...@studio) /root># zpool offline dummy md2 (r...@studio) /root># zpool status dummy pool: dummy state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: none requested config: NAMESTATE READ WRITE CKSUM dummy DEGRADED 0 0 0 raidz1DEGRADED 0 0 0 md1 ONLINE 0 0 0 md2 OFFLINE 0 0 0 md3 ONLINE 0 0 0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys)
On Sun, 28 Feb 2010, Garrett Cooper wrote:
On Sun, Feb 28, 2010 at 5:11 PM, Alexander Best wrote:
i have a small test app to check {rm|mk}dir()'s errnos with certain args like
/, ., /proc and non-empty dirs. i'll submit it to this thread as soon as i
also add testcases for syscalls like rename(), unlink(), etc.
most of the errno codes returned after applying your patch look correct. i
wonder however why rmdir("/proc") returns EACCESS as unprivileged user.
wouldn't it make more sense to also return EBUSY? why complain about
permission related matters when even root won't be able to perform the
operation.
Hmm.. good question. POSIX doesn't fully expound on this case
(http://www.opengroup.org/onlinepubs/009695399/functions/rmdir.html),
and either seem possible...
At:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03
we have
If more than one error occurs in processing a function call, any one of
the possible errors may be returned, as the order of detection is
undefined.
So we're okay standard-wise.
In general, though, I'd think it makes sense to do permissions checks
before anything else, because in some cases the error code can leak
information. For instance, if you try to open() a nonexistent file in a
directory for which you don't have search permission ('x' bit), it's very
important that open() fail with EACCES instead of ENOENT, since you aren't
suppposed to be able to find out whether or not the file exists.
Obviously that doesn't apply in this case, because anyone is entitled to
know that /proc is the root of a mounted filesystem, but it seems to me
that it's a good habit to check permission first.
--
Nate Eldredge
n...@thatsmathematics.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GEOM_ULZMA
On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote: > Hi, > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), > [...] Wouldn't it be better to modify geom_uzip to be universal decompression class with various algorithms implemented as plugins? This is bascially what I did for the LABEL class - before we had VOL_FFS class only for UFS labels. > [...] in connection with this is an issue best left lzma > code in the file "geom_ulzma.c" or store lzma library separately. If > separately, then where better? Definiatelly separately, not sure where. There is ongoing discussion somwhere on importing this algorithm to the base for tar(1) to use, it would be best to have only one copy of code in the tree. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpXqmkopDvFy.pgp Description: PGP signature
