problems with shared libraries
I am trying to port a little program that makes use of shared libraries, and havin some problems with that. This is the situation: the software is an mp3 player daemon, controllable through sockets. For inout/output, it uses xmms plugins. the problem happens when loading the xmms plugin shared lib. If I do not link the program with -export-dynamic, I can load the plugin, call the init entry point, and then call some other functions in the plugin. However, the plugin at some point needs to call a function in my program, and that fails. I get an error from the ld-elf saying that the symbol is undefined. I guess this is expected since I did not link with -export-dynamic, right ? Well, if I do link with -export-dynamic, I can not even make the first call to anything in the plugin, it segfaults immediately on some g_vsprintf_XXX function (that seems to come from glib). What is going on ? I link the program with glib and all necessary libs. If anybody has some insight on this, please let me know... bruno To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problems with shared libraries
I tried that and resolved all entry points. It is neither dlopen() nor
dlsym() that fail, it is when I try using that entry point that it fails.
code snippet:
if ((phandle = dlopen(filename, RTLD_LAZY)) == NULL) {
/* failed to load input plug */
event_printf(EVENT_LOG, 0, "dlopen: %s.", dlerror());
return(-1);
}
if ((gpi = dlsym(phandle, "get_iplugin_info")) != NULL) {
/* initialise as an input plugin */
fails here> ip = (InputPlugin *) gpi();
ip->handle = phandle;
ip->filename = (char *)strdup(filename);
if (ip->init) ip->init();
event_printf(EVENT_LOG, 0,
"pluginterface_load: Initialised %s", ip->description);
ipl_add(ip);
return 1;
}
the backtrace shows that calling get_iplugin_info() leads to a
g_strdup_printf() that later fails in vfprintf() from libc_r.so.4
so it fails in a call to glib. You'll tell me there is a bug in the
plugin, but I know there is not, this plugin (shared lib) works perfectly
with xmms.
The code to load and init the plugin was lifted from xmms actually.
Which leads me to thinking there is a problem between differing libs, or
something. Any other ideas ?
bruno
> [EMAIL PROTECTED] wrote:
> > Well, if I do link with -export-dynamic, I can not even make the first
> > call to anything in the plugin, it segfaults immediately on some
> > g_vsprintf_XXX function (that seems to come from glib).
> >
> > What is going on ? I link the program with glib and all necessary libs.
> >
> > If anybody has some insight on this, please let me know...
>
> Nothing a tiny bit of instrumentation and a change in the way
> you open it couldn't fix.
>
> Set RTLD_NOW rather than RTLD_LAZY for testing. When the dlopen()
> fails, call dlerror() to retrieve the error message; it will tell
> you exactly what is failing.
>
> -- Terry
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: problems with shared libraries (fwd)
that worked, I dlopen'ed glib in my program and put a stub for the glib function that was failing. It was getting bad data. Guess glib needs some stuff inited first maybe... anyway, it seems it works by spoofing it ! thanks bruno >Create a module "wrapper.so" that dlopen's glib.so.xxx, and *then* >dlopen's your module, and then reflects the interfaces down. >Alternately, don't use glib: it's intrinsically broken, by design. >-- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Building my own release ISOs
Does this look about right to build from a test branch? sudo make release SVNROOT=ssh+svn://svn.freebsd.org/base SVNBRANCH=projects/sbruno_64cpus MAKE_ISOS=y MAKE_DVD=y NO_FLOPPIES=y NODOC=y NOPORTSATALL=y WORLD_FLAGS=-j32 KERNEL_FLAGS=-j32 BUILDNAME=sbruno CHROOTDIR=/new_release Sean ___ 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: Building my own release ISOs
On Mon, 2010-11-22 at 06:26 -0800, John Baldwin wrote: > On Sunday, November 21, 2010 8:31:22 pm Sean Bruno wrote: > > Does this look about right to build from a test branch? > > > > sudo make release SVNROOT=ssh+svn://svn.freebsd.org/base > > SVNBRANCH=projects/sbruno_64cpus MAKE_ISOS=y MAKE_DVD=y NO_FLOPPIES=y > > NODOC=y NOPORTSATALL=y WORLD_FLAGS=-j32 KERNEL_FLAGS=-j32 > > BUILDNAME=sbruno CHROOTDIR=/new_release > > Sure. Note, though, that you don't have to create a branch just to build a > release with a patch. You can always use LOCAL_PATCHES to apply patches to > the source tree you build a release against. > Indeed, I guess I could do it that way. That does involve the step of creating a patch set and directory. Sean ___ 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"
(free)(open)IPMI tools in base
I'm not particular at the moment, but with the proliferation of IPMI in the server environment, is there any consideration to putting one of the appropriately licensed tools into the base? Sean ___ 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: Freebsd And the sun x4440
On Wed, 2012-05-16 at 17:42 -0700, Mark Saad wrote: > Once in the initial loading of the kernel at the "|" for 1-2 mins . > Then again shortly after printing the kernel banner "freebsd > 7.3-release etc etc etc" . This delay is about 1-2 mins as well. This looked like the "memory check" in my tests of -Current in the projects/largeSMP tree. You may want to try to manually disable the check using the following as a base. This is my diff to -Current. Your mileage may vary. Index: sys/amd64/amd64/machdep.c === --- sys/amd64/amd64/machdep.c (revision 221963) +++ sys/amd64/amd64/machdep.c (working copy) @@ -1430,6 +1430,8 @@ && pa >= trunc_page(dcons_addr) && pa < dcons_addr + dcons_size) goto do_dump_avail; + if (1) + goto baluba; page_bad = FALSE; @@ -1474,6 +1476,7 @@ */ if (page_bad == TRUE) continue; +baluba: /* * If this good page is a continuation of the * previous set of good pages, then just increase Sean ___ 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"
NFS mount inside jail fails
Silly thing I ran into today. User wanted to NFS mount a dir inside a jail. After I groaned about the security implication of this, I noted that there is a sysctl that looks like it should allow this. Namely, security.jail.mount_allowed. I noted that setting this follows a path that *should* have allowed this silly thing to happen, except that the credentials in the nfsclient were not setup correctly. e.g. VFS_SET(nfs_vfsops, oldnfs, VFCF_NETWORK); -- I changed this to: VFS_SET(nfs_vfsops, oldnfs, VFCF_NETWORK|VFCF_JAIL); This seems to allow the user's desired effect after setting security.jail.mount_allowed=1 I *think* this is the correct behavior, if a bit silly when taking into account the purpose of a jail. Thoughts? Sean ___ 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"
building my own release images from -CURRENT
Just trying some hackery with building my own release images from -CURRENT today. I've built world and my kernel, when I enter release and "make memstick" I get the following: ** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to the temproot environment *** Error code 1 Stop in /dumpster/scratch/sbruno-scratch/test/release. ___ 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: building my own release images from -CURRENT
On Tue, 2011-08-16 at 15:15 -0700, Test Rat wrote: > Sean Bruno writes: > > > Just trying some hackery with building my own release images from > > -CURRENT today. > > > > I've built world and my kernel, when I enter release and "make memstick" > > I get the following: > > > > ** Creating the temporary root environment in /var/tmp/temproot > > *** /var/tmp/temproot ready for use > > *** Creating and populating directory structure in /var/tmp/temproot > > > > > > *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to > > the temproot environment > > > > *** Error code 1 > > > > Stop in /dumpster/scratch/sbruno-scratch/test/release. > > Where points /usr/src? Have you tried the patch in misc/159666 ? Well, wow. Ok, misc/159666 does indeed fix this problem. I'm very confused by the fact that it has not come up before. Let me cc r...@freebsd.org and see if we can get a commit for this. Sean ___ 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: building my own release images from -CURRENT
On Tue, 2011-08-16 at 15:15 -0700, Test Rat wrote: > Have you tried the patch in misc/159666 ? Committed to -current svn R 224978. thanks for the patch! Sean ___ 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: Large machine test ideas
On Tue, 2011-08-30 at 17:11 -0700, Ivan Voras wrote: > On 29.8.2011. 20:15, John Baldwin wrote: > > > However, the SRAT code just ignores the table when it encounters an issue > > like > > this, it doesn't hang. Something else later in the boot must have hung. > > Anyway... that machine can in its maximal configuration be populated > with eight 10-core CPUs, i.e. 80 physical / 160 logical, so here's a > vote from me to bump the shiny new cpuset infrastructure maximum CPU > count to 256 before 9.0. > > http://www.supermicro.com/products/system/5U/5086/SYS-5086B-TRF.cfm Doesn't that (MAXCPU) seriously impact VM usage, lock contention etc ... ? I mean, if we have 2 cpus in a machine, but MAXCPU is set to 256, there is a bunch of "lost" memory and higher levels of lock contention? I thought that attilio was taking a stab at enhancing this, but at the current time anything more than a value of 64 for MAXCPU is kind of a "caveat emptor" area of FreeBSD. Sean P.S. I say 64 as yahoo has been running 64 cpus with local patches for a while, so I know that this works fairly well. ___ 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"
Subversion upgrades of existing dirs
How do I upgrade an existing svn tree with the current svn client. I don't really get what the client is trying to tell me here. [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn up svn: E155036: Please see the 'svn upgrade' command svn: E155036: Working copy '/dumpster/scratch/sbruno-scratch/9' is an old development version (format 12); to upgrade it, use a format 18 client, then use 'tools/dev/wc-ng/bumpt [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn upgrade . svn: E155019: Can't upgrade '/dumpster/scratch/sbruno-scratch/9' as it is not a pre-1.7 working copy directory svn: E15: Missing default entry [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ pkg_info 44bsd-csh-20001106_3 The traditional 4.4BSD /bin/csh C-shell ambit-2.0.39Extended bash brace expansion to expand hostnames or comman apr-ipv6-devrandom-gdbm-db42-1.4.5.1.3.12 Apache Portability Library bash-4.1.10 The GNU Project's Bourne Again SHell bison-2.4.3,1 A parser generator from FSF, (mostly) compatible with Yacc db42-4.2.52_5 The Berkeley DB package, revision 4.2 expat-2.0.1_1 XML 1.0 parser written in C gdbm-1.8.3_3The GNU database manager gettext-0.18.1.1GNU gettext package libiconv-1.13.1_1 A character set conversion library libtool-2.4_1 Generic shared library support script m4-1.4.16,1 GNU m4 neon29-0.29.6_2 An HTTP and WebDAV client library for Unix systems pkg-config-0.25_1 A utility to retrieve information about installed libraries sqlite3-3.7.7.1 An SQL database engine in a C library subversion-1.7.2Version control system ___ 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: Subversion upgrades of existing dirs
On Thu, 2011-12-22 at 09:51 -0800, Dimitry Andric wrote: > On 2011-12-22 18:33, Sean Bruno wrote: > > How do I upgrade an existing svn tree with the current svn client. I > > don't really get what the client is trying to tell me here. > > > > [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn up > > svn: E155036: Please see the 'svn upgrade' command > > svn: E155036: Working copy '/dumpster/scratch/sbruno-scratch/9' is an > > old development version (format 12); to upgrade it, use a format 18 > > client, then use 'tools/dev/wc-ng/bumpt > > > > [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn upgrade . > > svn: E155019: Can't upgrade '/dumpster/scratch/sbruno-scratch/9' as it > > is not a pre-1.7 working copy directory > > svn: E15: Missing default entry > > This is on an NFS share, right? That is most likely fixed by running > NFSv4, or by making sure rpc.lockd and rpc.statd run on both server and > client. > > It looks like Subversion needs file locking to work in a certain way, > otherwise it will give these obscure messages. Maybe it is useful to > report it to the Subversion guys... (and hopefully not get the answer > "don't do that" back :) > Eh? No. That's the other email thread I started ... back in November I think ... oh hey, you responded to that one! :-) http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029580.html sean ___ 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: Subversion upgrades of existing dirs
On Thu, 2011-12-22 at 09:56 -0800, Jason Hellenthal wrote: > > On Thu, Dec 22, 2011 at 09:33:45AM -0800, Sean Bruno wrote: > > How do I upgrade an existing svn tree with the current svn client. I > > don't really get what the client is trying to tell me here. > > > > [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn up > > svn: E155036: Please see the 'svn upgrade' command > > svn: E155036: Working copy '/dumpster/scratch/sbruno-scratch/9' is an > > old development version (format 12); to upgrade it, use a format 18 > > client, then use 'tools/dev/wc-ng/bumpt > > > > [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn upgrade . > > svn: E155019: Can't upgrade '/dumpster/scratch/sbruno-scratch/9' as it > > is not a pre-1.7 working copy directory > > svn: E15: Missing default entry > > > > seeing as this is a scratch location I wouldnt waste the time to figure it > out and just recheck the sources out for 9 and move over whatever needed to > function. I have found some instances of pre-checked out source unable to > upgrade for whatever reason. > > 'tools/dev/wc-ng/bumpt' should be in the source tarball for SVN. Round about > it is telling you to use a Subversion 1.8 client. > Yeah, I'm hoping that this doesn't impact users too much, but I think people are going to run into this. I have working directories that I share amongst the cluster machines for building, upgrading, testing and installing. I'd like to not have to keep a fbsd9 tree for svn version "x" and another fbsd9 tree for svn version "y" I guess I should fire off a pr to ports/subversion then ... Sean ___ 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: Subversion upgrades of existing dirs
On Thu, 2011-12-22 at 09:33 -0800, Sean Bruno wrote: > How do I upgrade an existing svn tree with the current svn client. I > don't really get what the client is trying to tell me here. > > [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn up > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: Working copy '/dumpster/scratch/sbruno-scratch/9' is an > old development version (format 12); to upgrade it, use a format 18 > client, then use 'tools/dev/wc-ng/bumpt > > [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn upgrade . > svn: E155019: Can't upgrade '/dumpster/scratch/sbruno-scratch/9' as it > is not a pre-1.7 working copy directory > svn: E15: Missing default entry > > > [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ pkg_info > 44bsd-csh-20001106_3 The traditional 4.4BSD /bin/csh C-shell > ambit-2.0.39Extended bash brace expansion to expand hostnames or > comman > apr-ipv6-devrandom-gdbm-db42-1.4.5.1.3.12 Apache Portability Library > bash-4.1.10 The GNU Project's Bourne Again SHell > bison-2.4.3,1 A parser generator from FSF, (mostly) compatible > with Yacc > db42-4.2.52_5 The Berkeley DB package, revision 4.2 > expat-2.0.1_1 XML 1.0 parser written in C > gdbm-1.8.3_3The GNU database manager > gettext-0.18.1.1GNU gettext package > libiconv-1.13.1_1 A character set conversion library > libtool-2.4_1 Generic shared library support script > m4-1.4.16,1 GNU m4 > neon29-0.29.6_2 An HTTP and WebDAV client library for Unix systems > pkg-config-0.25_1 A utility to retrieve information about installed > libraries > sqlite3-3.7.7.1 An SQL database engine in a C library > subversion-1.7.2Version control system > > Even more strange, on another machine in the cluster I can read and update my tree with subversion-1.7.1 ... but that version doesn't know how to upgrade the tree? I'm so confused on this. [sbruno@crush /dumpster/scratch/sbruno-scratch/9]$ pkg_info |grep subversion subversion-1.7.1_1 Version control system [sbruno@crush /dumpster/scratch/sbruno-scratch/9]$ svn upgrade svn: E155019: Can't upgrade '/dumpster/scratch/sbruno-scratch/9' as it is not a pre-1.7 working copy directory svn: E15: Missing default entry Sean ___ 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: SuperMicro IPMI keyboard - fails for 'mountroot>' prompt under FreeBSD 9-R...
On Mon, 2012-02-27 at 04:09 -0800, Karl Pielorz wrote: > > --On 27 February 2012 12:04 + Karl Pielorz > wrote: > > > Once the kernel is loading you see: > > Sorry - that should be, once the O/S is booting, not kernel loading - you > see: ... > > > " > > ugen1.2: at usbus1 > > ums0: > 1.10/0.01, addr 2> on usbus1 > > ums0: 3 buttons and [Z] coordinates ID=0 > > ukbd0: > rev 1.10/0.01, addr 2?> on usbus1 > > kbd2 at ukbd0 > > " > > -Karl > > _ Can you dump the full dmesg on boot? I've noted that shared ethernet devices and IPMI seem to conflict. Expecially if the kernel is explicity turning off the ethernet device becuase its not configured. Sean ___ 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: Recurring "rescan already queued" message
On Tue, 2012-02-28 at 07:33 -0800, Dmitry S. Kasterin wrote: > Hello! > > I am trying to install 9.0-RELEASE from standard amd64 memstick image. > During the install huge amount of "rescan already queued" messages > breaks installer interface. > > (noperiph:ata1:0:-1:-1): rescan already queued > (noperiph:ata1:0:-1:-1): rescan already queued > (noperiph:ata1:0:-1:-1): rescan already queued > (noperiph:ata1:0:-1:-1): rescan already queued > > So, I have 2 questions: > > 1) Are these messages harmless? > 2) Messages are a little bit annoying. So, is there any way to suppress them? I had the same issue on my laptop with an eSATA port. I disabled the eSATA port and that made the messages go away. According to mav@ these were harmless, but annoying. Sean ___ 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"
[sudo] configure --host=i386
I was trying to cross compile sudo for i386 on an amd64 host and was befuddled by the following ./configure error output. checking for library containing crypt... -lcrypt checking for library containing getspnam... no checking for library containing getprpwnam... no configure: error: "dlopen present but libtool doesn't appear to support your platform." I've tried this on 7,8,9 and head with the same result. Thoughts? Sean ___ 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"
[patch] Disable bios probe if acpi is enabled
I'm noting that newer machines are completely hosed if we attempt to
probe for bios values. I'm proposing this change.
-bash-4.2$ p4 diff -du //depot/yahoo/ybsd_7/src/sys/i386/i386/bios.c
--- //depot/yahoo/ybsd_7/src/sys/i386/i386/bios.c 2011-09-16
22:47:30.0
+++ /home/seanbru/ybsd_7/src/sys/i386/i386/bios.c 2011-09-16
22:47:30.0
@@ -84,6 +84,12 @@
char *p;
/*
+ * Don't do bios probing if acpi is enabled, its
+ * pointless and breaks on newer systems
+ */
+if (!resource_disabled("acpi", 0))
+ return;
+/*
* BIOS32 Service Directory, PCI BIOS
*/
signature.asc
Description: This is a digitally signed message part
Dell R620 + H710p
Just a note from the "yahoo bsd" world. In order to get the R620/720 working here, we switched out the Broadcom ethernet device with an Intel (its a purchase option), and integrated the project/head_mfi branch to get things working in our universe. Sean http://people.freebsd.org/~sbruno/r620_dmidecode.txt http://people.freebsd.org/~sbruno/r620_pciconf.txt signature.asc Description: This is a digitally signed message part
mfid, raid monitoring daemon
I'm trying to decide if I should cram "mfid" for mfi(4) controllers into the src tree or if we should package it up into a ports package. I suspect that either one is acceptible, but it seems to make more sense to put it into the src tree since mfiutil is also there. Comments? Sean ref: http://svnweb.freebsd.org/base/user/sbruno/mfid/ signature.asc Description: This is a digitally signed message part
Re: gnome start error?help me.
On Tue, 2012-05-15 at 18:13 -0700, cz li wrote: > FreeBSD9.0 support for the ATI HD2300 or ATI x2300 graphics card? according to man 4 radeon, the x2300 is supported. according to man 4 radeonhd, it supports both. Take a look at the man page. You might have to do a port upgrade of your xorg installation. Or, PC-BSD 9 for your desktop might be an alternative. Sean ___ 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"
[jail] Allowing root privledged users to renice
I've been toying with the idea of letting jails renice processes ... how dangerous and/or stupid is this idea? //depot/yahoo/ybsd_9/src/sys/kern/kern_jail.c#5 - /home/seanbru/ybsd_9/src/sys/kern/kern_jail.c 270a271,275 + int jail_allow_renice = 0; + SYSCTL_INT(_security_jail, OID_AUTO, allow_renice, CTLFLAG_RW, +&jail_allow_renice, 0, +"Prison root can renice processes"); 3857a3863,3865 + case PRIV_SCHED_SETPRIORITY: + if (!jail_allow_renice) + return (EPERM); ___ 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"
tkcvs/tkdiff
Does anyone have tkdiff working from ports right now? I keep getting nothing but a "wish" window popping up when I install tkcvs. I didn't see any obvious results with my internet search foo, so thought I'd ask here as well as in other places. Sean ___ 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: tkcvs/tkdiff
On Wed, 2012-06-06 at 14:40 -0700, Sean Bruno wrote: > I keep getting > nothing but a "wish" window popping up when I install tkcvs. Correction: I get a "wish" window popping up when I run "tkdiff file1 file2" Sean ___ 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: run_interrupt_driven_hooks: ... xpt_config" delay
On Wed, 2012-06-20 at 03:00 -0700, rank1see...@gmail.com wrote: > >From 3 machines with that type of cutom kernels, only 1 suffers from > this (and problem is gone, as soon as I revert to GENERIC) Please post your "custom kernel config" somewhere so we can see what is different. Sean ___ 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"
dtraceall.ko with old nfsclient
Ran into some symbol errors with the dtraceall module when using the *old* nfs client. I think that this is more or less the right thing to do, but I'm not sure. --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c 2011-11-02 23:46:55.0 +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c 2011-11-02 23:46:55.0 @@ -66,8 +66,11 @@ MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); +#if defined (NFSCL) MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); +#else /* defined (NFSCLIENT) */ MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); +#endif #if defined(__amd64__) || defined(__i386__) MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); ___ 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: dtraceall.ko with old nfsclient
On Tue, 2012-07-10 at 06:41 -0700, Fabian Keil wrote: > > > > --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > 2011-11-02 23:46:55.0 > > > > +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > 2011-11-02 23:46:55.0 > > > @@ -66,8 +66,11 @@ > > > MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); > > > MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); > > > MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); > > > +#if defined (NFSCL) > > > MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); > > > +#else /* defined (NFSCLIENT) */ > > Any objections to changing this to > #elif defined (NFSCLIENT) > ? No objections here. I suspect that this is the more correct thing regardless. I mean, it keeps the nfs dtrace objects loading in the event someone is running a non-nfs kernel... right? Sean ___ 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: dtraceall.ko with old nfsclient
On Thu, 2012-07-12 at 12:47 -0700, Andrew Boyer wrote:
> On Jul 12, 2012, at 3:39 PM, Andriy Gapon wrote:
>
> > on 12/07/2012 22:36 Fabian Keil said the following:
> >> Andriy Gapon wrote:
> >>
> >>> on 12/07/2012 21:17 Fabian Keil said the following:
> Benjamin Kaduk wrote:
>
> > On Wed, 11 Jul 2012, Fabian Keil wrote:
> >
> >> I'm using the following modification of Sean's patch:
>
> This way it seems to work as expected:
>
> diff --git a/sys/modules/dtrace/dtraceall/Makefile
> b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b 100644
> --- a/sys/modules/dtrace/dtraceall/Makefile +++
> b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD:
> src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 uqs
> Exp $
>
> KMOD= dtraceall -SRCS= dtraceall.c opt_compat.h
> +SRCS= dtraceall.c opt_compat.h opt_nfs.h
>
> CFLAGS+= -I${.CURDIR}/../../..
>
> >>>
> >>> If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, does
> >>> it compile OK with the above change?
> >>
> >> Depends on your expectations I guess. As neither NFS-related option gets
> >> defined, no dependency on either NFS module is registered. The compiler has
> >> no complaints, though.
> >
> > Interesting. Could you repeat after sufficient cleaning up?
> > I am not sure where from opt_nfs.h file could come.
> >
>
> Maybe related: check out sys/modules/ipfw/Makefile. It makes its own option
> headers for INET and INET6.
>
> -A
>
> --
> Andrew Boyer abo...@averesystems.com
>
>
>
>
I've pondered this on an off for a couple of weeks now. I can clearly
see that if we want compile time dependencies, that's fine, we can make
each nfclient object dependant on the #define. Both are valid cases to
have loaded though, so they shouldn't be conditional on each other as in
my patches.
If one does this however, the module makefile needs to be adjusted like
the ipfw makefile to create an opt_nfs.h with the NFS client defines,
else you will have neither dtrace object available.
There isn't a clear way that I can see to compile dtraceall.ko as a
module if you are doing so outside of the kernel compile though. The
module tree isn't really aware of what you are running, therefore it
would have to compile to load both regardless. Which, if your kernel
doesn't support one or both nfs objects, will cause a kldload failure.
I'm not real clear how to unwind this situation.
Sean
___
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"
pmc warnings on stable/9
I have no idea the significance, or danger. When compiling on stable/9 I have always seen the following WARNINGS. Can we silence/fix these? Or is it supposed to be that way? :-) WARNING: hwpmc_soft.c: enum pmc_event has too many values: 1531 > 1023 WARNING: kern_pmc.c: enum pmc_event has too many values: 1531 > 1023 WARNING: kern_rwlock.c: enum pmc_event has too many values: 1531 > 1023 WARNING: kern_sx.c: enum pmc_event has too many values: 1531 > 1023 WARNING: kern_lock.c: enum pmc_event has too many values: 1531 > 1023 WARNING: hwpmc_intel.c: enum pmc_event has too many values: 1531 > 1023 WARNING: hwpmc_tsc.c: enum pmc_event has too many values: 1531 > 1023 WARNING: hwpmc_amd.c: enum pmc_event has too many values: 1531 > 1023 WARNING: kern_clock.c: enum pmc_event has too many values: 1531 > 1023 WARNING: kern_mutex.c: enum pmc_event has too many values: 1531 > 1023 WARNING: trap.c: enum pmc_event has too many values: 1531 > 1023 WARNING: hwpmc_x86.c: enum pmc_event has too many values: 1531 > 1023 WARNING: hwpmc_uncore.c: enum pmc_event has too many values: 1531 > 1023 WARNING: hwpmc_piv.c: enum pmc_event has too many values: 1531 > 1023 WARNING: hwpmc_core.c: enum pmc_event has too many values: 1531 > 1023 WARNING: hwpmc_logging.c: enum pmc_event has too many values: 1531 > 1023 WARNING: hwpmc_mod.c: enum pmc_event has too many values: 1531 > 1023 ___ 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"
ctfconvert failure on stable/9
Not sure what to make of this error: ERROR: ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)] my kernel is compiling, but I seem to fail at understanding something? Sean ___ 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"
clang/llvm failure on a project branch
Not sure if I really need to have this code yet, but I found a bit of code that works under gcc but fails under clang/llvm on my project branch of pxe_http: http://svnweb.freebsd.org/base/user/sbruno/pxe_http_head/sys/boot/i386/pxe_http/ ===> i386/pxe_http (all) pxe_isr.S:45:3: error: unexpected directive .code16 .code16 ^ pxe_isr.S:45:10: error: .code16 not supported yet .code16 ^ *** [pxe_isr.o] Error code 1 Stop in /home/sbruno/sbruno/pxe_http_head/sys/boot/i386/pxe_http. *** [all] Error code 1 Stop in /home/sbruno/sbruno/pxe_http_head/sys/boot/i386. *** [all] Error code 1 Stop in /home/sbruno/sbruno/pxe_http_head/sys/boot. ___ 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: clang/llvm failure on a project branch [fixed]
On Fri, 2013-02-08 at 14:32 -0800, Sean Bruno wrote: > Not sure if I really need to have this code yet, but I found a bit of > code that works under gcc but fails under clang/llvm on my project > branch of pxe_http: > > http://svnweb.freebsd.org/base/user/sbruno/pxe_http_head/sys/boot/i386/pxe_http/ > > ===> i386/pxe_http (all) > pxe_isr.S:45:3: error: unexpected directive .code16 > .code16 > ^ > pxe_isr.S:45:10: error: .code16 not supported yet > .code16 > ^ > *** [pxe_isr.o] Error code 1 > Thanks to Hiren for the suggestion. Thanks to dim for the code. :-) http://svnweb.freebsd.org/base?view=revision&revision=246569 Sean ___ 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"
Eliminating a warning in sys/boot
So, this is not a valid warning in our universe and I'd like to silence it when compiling sys/boot as printf(9) and sprintf(9) supports this format. How can we silence this warning for the FreeBSD universe? ===> efi/libefi (all) In file included from efinet.c:39: /home/sbruno/fbsd_head/sys/boot/efi/libefi/../../common/dev_net.c:328:19: warning: invalid conversion specifier 'D' [-Wformat-invalid-specifier] sprintf(temp, "%6D", d->myea, ":"); SEan signature.asc Description: This is a digitally signed message part
sparc64 zfsroot/gmirror?
I'm restoring some of the sparc64 machines for freebsd.org and had a question with regards to what to do about the / Since it wasn't obvious how to setup zfs root things I setup something that looks like this: => 0 71087625 da0 VTOC8 (33G) 03855601 freebsd-ufs (188M) 385560 707020652 freebsd-zfs (33G) => 0 71087625 da1 VTOC8 (33G) 03855601 freebsd-ufs (188M) 385560 707020652 freebsd-zfs (33G) Where everything *except* /boot is in the mirrored zpool. I can reinstall the system trivially, and am looking for suggestions. Sean ___ 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: sparc64 zfsroot/gmirror?
On Tue, 2013-02-19 at 22:59 -0500, Kurt Lidl wrote:
> On Tue, Feb 19, 2013 at 04:03:09PM -0800, Sean Bruno wrote:
> > I'm restoring some of the sparc64 machines for freebsd.org and had a
> > question with regards to what to do about the /
> >
> > Since it wasn't obvious how to setup zfs root things I setup something
> > that looks like this:
> >
> > => 0 71087625 da0 VTOC8 (33G)
> > 03855601 freebsd-ufs (188M)
> > 385560 707020652 freebsd-zfs (33G)
> >
> > => 0 71087625 da1 VTOC8 (33G)
> > 03855601 freebsd-ufs (188M)
> > 385560 707020652 freebsd-zfs (33G)
> >
> >
> > Where everything *except* /boot is in the mirrored zpool.
> >
> > I can reinstall the system trivially, and am looking for suggestions.
>
> I wrote up a script to do the heavy lifting for installing
> a completely zfs system on a sparc64 machine.
>
> http://www.pix.net/ftp/pub/freebsd/sparc_zfs_setup.txt
>
> The 12GB space for zfs is appropriate for a 18Gb disk, and allows
> the remainder of the disk space to accommodate a 4Gb-ish swap space,
> for crash dumps. The swap is placed at the end of the disk, since
> that's the slowest part to access.
>
> -Kurt
>
Ah, I see I'm completely overthinking it.
From your script:
gpart bootcode -p /boot/zfsboot ${disk}
dd if=/boot/zfsloader of=/dev/${disk}a bs=512 oseek1024
conv=notrunc,sync
That's what I was missing hence my silly layout.
Sean
signature.asc
Description: This is a digitally signed message part
extend printf(9) %b format to allow 0 bits set
A small patch from my wanderings today for your review. This patch to kvprintf() allows me to set a %b format string of: "\20\0unset\1ONESET\2TWOSET" In the case that the variable being compared has the value of 0, it will display "0x0" http://people.freebsd.org/~sbruno/subr_prf.txt Sean signature.asc Description: This is a digitally signed message part
Re: CFR: FireWire: Don't allow a tlabel to reference an xfer after free
On Thu, 2013-03-28 at 11:25 -0600, Will Andrews wrote: > Diff: http://people.freebsd.org/~will/patches/fix-fwmem-use-after-free.diff > > >From the commit log: > > FireWire: Don't allow a tlabel to reference an xfer after free. > > sys/dev/firewire/firewire.c: > - fw_xfer_unload(): Since we are about to free this xfer, call > fw_tl_free() to remove the xfer from its tlabel's list, if > it has a tlabel. > - In every occasion when a xfer is removed from a tlabel's list, > reset xfer->tl to -1 while holding fc->tlabel_lock, so that the > xfer isn't mis-identified as belonging to a tlabel. > > > Thanks, > --Will. > ___ Ack. Looks like a valid commit. sean signature.asc Description: This is a digitally signed message part
Relocatable intel 'em' driver patch(intel v6.4.1)
I did a small amount of search and replace against the intel em ethernet driver to allow it to be relocatable today. If anyone is interested, here is the diff against my tree. So, one should be able to copy v6.4.1 of the intel driver into the kernel src tree, overwriting RELENG_6's version and apply this diff. I've tested it a couple of times, but buyer beware. This might just be a good reference for someone wanting to do the same thing I needed to do. sean P.S I'm not sure of the history here, but is there any specific reason that this driver is being maintained outside of the mainline kernel branches? 38c38 < #include "e1000_80003es2lan.h" --- > #include 38c38 < #include "e1000_api.h" --- > #include 42c42 < #include "e1000_api.h" --- > #include 41c41 < #include "e1000_82541.h" --- > #include 38c38 < #include "e1000_api.h" --- > #include 38c38 < #include "e1000_api.h" --- > #include 39c39 < #include "e1000_82543.h" --- > #include 38c38 < #include "e1000_api.h" --- > #include 40c40 < #include "e1000_82571.h" --- > #include 38c38 < #include "e1000_api.h" --- > #include 35,37c35,37 < #include "e1000_mac.h" < #include "e1000_nvm.h" < #include "e1000_phy.h" --- > #include > #include > #include 38c38 < #include "e1000_hw.h" --- > #include 38,40c38,40 < #include "e1000_osdep.h" < #include "e1000_regs.h" < #include "e1000_defines.h" --- > #include > #include > #include 497,500c497,500 < #include "e1000_mac.h" < #include "e1000_phy.h" < #include "e1000_nvm.h" < #include "e1000_manage.h" --- > #include > #include > #include > #include 39c39 < #include "e1000_ich8lan.h" --- > #include 38c38 < #include "e1000_api.h" --- > #include 35c35 < #include "e1000_mac.h" --- > #include 38c38 < #include "e1000_api.h" --- > #include 35c35 < #include "e1000_manage.h" --- > #include 38c38 < #include "e1000_api.h" --- > #include 35c35 < #include "e1000_nvm.h" --- > #include 38c38 < #include "e1000_api.h" --- > #include 35c35 < #include "e1000_phy.h" --- > #include 51c51 < #include "e1000_api.h" --- > #include 81,82c81,82 < #include "e1000_api.h" < #include "if_e1000.h" --- > #include > #include 6,10c6,10 < SRCS= device_if.h bus_if.h pci_if.h opt_bdg.h < SRCS+= if_e1000.c $(SHARED_SRCS) < SHARED_SRCS = e1000_api.c e1000_phy.c e1000_nvm.c e1000_mac.c e1000_manage.c < SHARED_SRCS += e1000_80003es2lan.c e1000_82542.c e1000_82541.c e1000_82543.c < SHARED_SRCS += e1000_82540.c e1000_ich8lan.c e1000_82571.c --- > SRCS= device_if.h bus_if.h pci_if.h opt_bdg.h \ > if_e1000.c e1000_api.c e1000_phy.c e1000_nvm.c \ > e1000_mac.c e1000_manage.c e1000_80003es2lan.c \ > e1000_82542.c e1000_82541.c e1000_82543.c \ > e1000_82540.c e1000_ich8lan.c e1000_82571.c 14c14 < CFLAGS += -I/usr/src/sys/dev/em --- > #CFLAGS += -I../../dev/em ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rc functions don't allow processes to shutdown
Tobias Roth wrote: Sean Bruno wrote: I noticed that if rc.conf has ntpd_enable="NO", an invocation of /etc/rc.d/ntpd stop won't actually shut down ntpd. I checked a couple of other processes(like net-snmp) and noted the same behavior. I would have expected that rc would be able to invoke the stop routines if a utility is disabled, but apparently the check for enabled/disabled occurs much too early in the rc handling functions for the stop to fire off. I could investigate further, as I am sure that it's a fairly easy fix to allow the stop functions to be invoked regardless of the enable/disable state. Does it make sense to anyone else that the rc functions should be able to shutdown a process when it has been disabled in rc.conf? /etc/rc.d/ntpd forcestop Indeed one could invoke that. My question is more about what 'stop' should or should not do. Specifically, should it 'stop' when a process has been disabled? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rc functions don't allow processes to shutdown
I noticed that if rc.conf has ntpd_enable="NO", an invocation of /etc/rc.d/ntpd stop won't actually shut down ntpd. I checked a couple of other processes(like net-snmp) and noted the same behavior. I would have expected that rc would be able to invoke the stop routines if a utility is disabled, but apparently the check for enabled/disabled occurs much too early in the rc handling functions for the stop to fire off. I could investigate further, as I am sure that it's a fairly easy fix to allow the stop functions to be invoked regardless of the enable/disable state. Does it make sense to anyone else that the rc functions should be able to shutdown a process when it has been disabled in rc.conf? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rc functions don't allow processes to shutdown
Doug Barton wrote: On Fri, 31 Aug 2007, Sean Bruno wrote: I noticed that if rc.conf has ntpd_enable="NO", an invocation of /etc/rc.d/ntpd stop won't actually shut down ntpd. I checked a couple of other processes(like net-snmp) and noted the same behavior. FYI, there is a list for discussing rc.d issues, [EMAIL PROTECTED] The current behavior is by design, and I don't think that changing it is a good idea this late in the game. Ah, as usual, I picked the wrong list. I'll take design issues there. Assuming that lack of an affirmative _enable variable is a constant, the only way that a service can be started is with either onestart or forcestart. The symmetry here would be to stop it the same way. This may be symmetrical, but I question whether or not the 'correct' behavior is symmetrical. I don't see the benefit to the end user in this implementation, e.g. trying to disable a running service. If a new-ish admin edits the rc.conf prior to shutting down the service, there could be some consternation. However, my entire idea of how to shut down a process in FreeBSD may be flawed, and I may be the one who is in need of a 'design change'. :) Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pluggable Disk Scheduler Project
On 10/17/07, Fabio Checconi <[EMAIL PROTECTED]> wrote: > > From: Ulf Lilleengen <[EMAIL PROTECTED]> > > Date: Wed, Oct 17, 2007 03:09:35PM +0200 > > > > On ons, okt 17, 2007 at 02:19:07 +0200, Fabio Checconi wrote: > > > Maybe I've not enough experience/knowledge of the driver subsystem, > [...] > > If you look at it, Hybrid is just a generalization of the existing > > bioq_* API already defined. And this API is used by GEOM classes _before_ > > device drivers get the requests AFAIK. > > > > I looked at the Hybrid code, but I don't think that the bioq_* > family of calls can be the right place to start, for the problems > experienced during the Hybrid development with locking/anticipation > and because you can have the same request passing through multiple > bioqs during its path to the device (e.g., two stacked geoms using > two different bioqs and then a device driver using bioq_* to organize > its queue, or geoms using more than one bioq, like raid3; I think > the complexity can become unmanageable.) One could even think to > configure each single bioq in the system, but things can get very > complex in this way. > > > > For a simple example on a driver, the md-driver might be a good place to > > look. Note that I have little experience and knowledge of the driver > > subsystem myself. > > > > I'll take a look, thanks. > > > > Also note (from the Hybrid page): > > * we could not provide support for non work-conserving schedulers, due to a > [...] > > > > This certainly argues for having this in the GEOM layer, but perhaps it's > > possible to change the assumtions done in some drivers? The locking issue > > should perhaps be better planned though, and an audit of the driver disksort > > code is necessary. > > > > I need some more time to think about that :) > > > > Also: > > * as said, the ATA driver in 6.x/7.x moves the disksort one layer below the > > one we are working at, so this particular work won't help on ATA-based 6.x > > machines. > > We should figure out how to address this, because the work done at that > > layer is mostly a replica of the bioq_*() API. > > > > So, I see this can get a bit messy thinking of that the ATA drivers does > > disksorts on its own, but perhaps it would be possible to fix this by > > letting > > changing the general ATA driver to use it's own pluggable scheduler. > > > > Anyway, I shouldn't demand that you do this, especially since I don't have > > any code or anything to show to, and because you decide what you want to do. > > I still cannot say if a GEOM scheduler is better than a scheduler > put at a lower level, or if the bioq_* interface is better than any > other alternative, so your suggestions are welcome. Moreover I'd > really like to discuss/work together, or at least do things with > some agreement on them. If I'll have the time to experiment with > more than one solution I'll be happy to do that. > > > > However, I'd hate to see the Hybrid effort go to waste :) I was hoping some > > of the authors of the project would reply with their thoughts, so I CC'ed > > them. > > Well, the work done on Hybrid had also interesting aspects from > the algorithm side... but that's another story... > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Serial speed for boot device selection prompt
I have a drive that contains two seperate bootable partitions(ad0s1a and ad0s2a). The boot device selection menu(boot0?) appears to only be able to support 9600 8N1. I wanted to run the serial console at 115200, but I currently have to switch to 9600 if I need to change the boot device. Is there a way around this that I can't see? Could I get around this with a BIOS that can do console redirection? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serial speed for boot device selection prompt
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html Thanks for the pointers. I am currently unable to access www.freebsd.org for some reason. It appears that I get a timeout trying to retrieve anything from the web site. Other folks in my office seem to have the same problem, yet I can access the web site from my home network. Any ideas what the connection issues might be? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD.org website problems was: Serial speed for boot device selection prompt
Jeremy Chadwick wrote: On Thu, Oct 25, 2007 at 10:36:28AM -0700, Sean Bruno wrote: Thanks for the pointers. I am currently unable to access www.freebsd.org for some reason. It appears that I get a timeout trying to retrieve anything from the web site. Other folks in my office seem to have the same problem, yet I can access the web site from my home network. Any ideas what the connection issues might be? Someone else recently reported similar on their FreeBSD box, and the fix for them was to disable RFC1323 TCP window scaling. Try this: sysctl -w net.inet.tcp.rfc1323=0 If this works for you, you can place the variable=value portion in /etc/sysctl.conf for application upon start-up. If your FreeBSD box acts as a gateway for the rest of your office, and the then that might explain why others are seeing the same thing. Otherwise the problem is likely not FreeBSD-related, and you should talk to your office networking folks to find out what's going on. Interesting, what is _really_ going on with the website? I was having connectivity issues to www.freebsd.org from linux, netbsd and freebsd machines. After adjusting the appropriate value for linux, netbsd and freebsd the issues seem to clear. Under linux adjust: net.ipv4.tcp_window_scaling Under FreeBSD/NetBSD adjust: net.inet.tcp.rfc1323 Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serial speed for boot device selection prompt
If you want serial capability in boot0, you should set BOOT_COMCONSOLE_SPEED=115200 in your make.conf. After you do that, you'll need to rebuild the boot blocks. The procedure for doing that is step 4 of Section 24.6.5.2 in the Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html The BIOS call that boot.S is using (int 0x14) only supports a maximum speed of 9600. To get speeds greater that 9600, it needs to do the I/O itself. There used to be a version floating around that did this. I have a extemely modified version that uses this method. If you can't find a version that does this, let mw know and I'll see if I can cleanup what I have. Larry Thanks, that at least confirmed my theory while reviewing the assembly that boot.S was not capable of more than 9600. I'll look around first, but may request the code later. Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iSCSI initiator driver beta version, testers wanted
Amir Tahmasebi wrote: Hello Danny, Do you know if there is any problem with ISCSI initiator when using FreeBSD version 6.x? Thanks I was able to backport the driver from 7 fairly easily. If there is some interest, here is a small diff. Simply copying the iscontrol from RELENG_7 into RELENG_6 and changing the makefiles worked for me. isc_cam.c 399,400d398 < < #if __FreeBSD_version >= 70 402,404d399 < #else < if(xpt_bus_register(sim, 0/*bus_number*/) != CAM_SUCCESS) < #endif Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Modules stopped compiling?
I'm not sure what I did, but my kernel config isn't compiling modules any longer. Is there something that I failed to do here? http://consultcsg.com/MYKERNEL Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How long is a hz?
Jason Slagle wrote: On Mon, 28 Jan 2008, Sean Bruno wrote: I couldn't quite find the definition for "hz" in sys/ this morning. What is it's value and where is it defined? From http://en.wikipedia.org/wiki/Hertz The hertz (symbol: Hz) is the International System of Units (SI) base unit of frequency. Its base unit is cycle/s or s^-1 (also called inverse seconds, reciprocal seconds). In English, hertz is used as both singular and plural. As any SI unit, Hz can be prefixed; commonly used multiples are kHz (kilohertz, 10^3 Hz), MHz (megahertz, 10^6 Hz), GHz (gigahertz, 10^9 Hz) and THz (terahertz, 10^12 Hz). One hertz simply means one cycle per second (typically that which is being counted is a complete cycle); 100 Hz means one hundred cycles per second, and so on. The unit may be applied to any periodic event--for example, a clock might be said to tick at 1 Hz, or a human heart might be said to beat at 1.2 Hz. The frequencies of aperiodic events, such as radioactive decay, are expressed in becquerels. But more importantly, where is "hz" defined in the kernel tree? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How long is a hz?
I couldn't quite find the definition for "hz" in sys/ this morning. What is it's value and where is it defined? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How long is a hz?
Sam Leffler wrote: Sean Bruno wrote: Jason Slagle wrote: On Mon, 28 Jan 2008, Sean Bruno wrote: I couldn't quite find the definition for "hz" in sys/ this morning. What is it's value and where is it defined? http://fxr.watson.org/fxr/ident?i=hz Thank you Sam. You have taught me "how to fish" as it were. The answer that I was searching for is located at: http://fxr.watson.org/fxr/source/kern/subr_param.c#L56 Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Question about http://torrents.freebsd.org:8080/index.html
Does it seem correct to all concerned that each release actually lists all files twice? There is a torrent for the entire release CD ISO set, and then there is a completely separate torrent for each CD ISO file. At least that is what it looks like to me. Is this correct? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about http://torrents.freebsd.org:8080/index.html
Kris Kennaway wrote: Sean Bruno wrote: Does it seem correct to all concerned that each release actually lists all files twice? There is a torrent for the entire release CD ISO set, and then there is a completely separate torrent for each CD ISO file. At least that is what it looks like to me. Is this correct? Yes. Many people like to download the whole thing in one torrent. It does split the aggregate swarm bandwidth, but it doesn't seem to be a problem in practice. Kris Thanks for anticipating my next question! :) <2cents> I just found it odd that that users couldn't just specify the file to download from the release torrent. It also makes it slightly(read almost negligible) harder to seed effectively as I would need to download more than one centralized torrent. Since I use the complete torrent for my purposes, I can only assist the folks who also download the entire torrent. Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about http://torrents.freebsd.org:8080/index.html
Lowell Gilbert wrote: Sean Bruno <[EMAIL PROTECTED]> writes: <2cents> I just found it odd that that users couldn't just specify the file to download from the release torrent. It also makes it slightly(read almost negligible) harder to seed effectively as I would need to download more than one centralized torrent. Since I use the complete torrent for my purposes, I can only assist the folks who also download the entire torrent. You *can* do it both ways. Right after a release, I often download the "everything" torrent, then continue to seed that one while also seeding the partial torrents. I use file links to avoid needing to download the partial torrents separately. Ah, that's a good idea. I'll do something like that tonight. That solution doesn't seem to be very obvious to me though. Not that I am an expert in this kind of stuff. /me drops it. Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB Install Method
Does anyone have a pointer to a FreeBSD 7 install method for those of us without CD/DVD Rom drives? The easiest way for me would be to boot off of a USB stick and then install across the network, but I'm open to suggestions. Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Exposing Zone Sleeps
Find attached a patch against -CURRENT.
This update exposes a counter that indicates the number of times that we
sleep when attempting to allocate a slab from the keg. In other words,
the number of times we BLOCK and wait, which is bad.
This allows differentiation between times when we failed to allocate and
it was ok and times where we were forced to sleep. The current FAIL
counter does not make this distinction.
Exposes this information via uma_zone_t->uz_sleeps.
Add a new sysctl to retrieve this information.
Enhance vmstat -z to retrieve this information.
We've found this *extremely* useful here at Yahoo in the past and would
like to commit this if it is acceptable.
Tested on 32bit and 64bit architectures on 6/7/CURRENT.
Index: usr.bin/vmstat/vmstat.c
===
--- usr.bin/vmstat/vmstat.c (revision 208460)
+++ usr.bin/vmstat/vmstat.c (working copy)
@@ -1294,16 +1294,17 @@
memstat_strerror(error));
}
}
- printf("%-20s %8s %8s %8s %8s %8s %8s\n\n", "ITEM", "SIZE",
- "LIMIT", "USED", "FREE", "REQUESTS", "FAILURES");
+ printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE",
+ "LIMIT", "USED", "FREE", "REQ", "FAIL", "SLEEP");
for (mtp = memstat_mtl_first(mtlp); mtp != NULL;
mtp = memstat_mtl_next(mtp)) {
strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME);
strcat(name, ":");
- printf("%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n", name,
+ printf("%-20s %6llu, %6llu,%8llu,%8llu,%8llu,%4llu,%4llu\n",name,
memstat_get_size(mtp), memstat_get_countlimit(mtp),
memstat_get_count(mtp), memstat_get_free(mtp),
- memstat_get_numallocs(mtp), memstat_get_failures(mtp));
+ memstat_get_numallocs(mtp), memstat_get_failures(mtp),
+ memstat_get_sleeps(mtp));
}
memstat_mtl_free(mtlp);
printf("\n");
Index: lib/libmemstat/memstat.h
===
--- lib/libmemstat/memstat.h (revision 208460)
+++ lib/libmemstat/memstat.h (working copy)
@@ -139,6 +139,7 @@
uint64_t memstat_get_count(const struct memory_type *mtp);
uint64_t memstat_get_free(const struct memory_type *mtp);
uint64_t memstat_get_failures(const struct memory_type *mtp);
+uint64_t memstat_get_sleeps(const struct memory_type *mtp);
void *memstat_get_caller_pointer(const struct memory_type *mtp,
int index);
void memstat_set_caller_pointer(struct memory_type *mtp,
Index: lib/libmemstat/memstat.c
===
--- lib/libmemstat/memstat.c (revision 208460)
+++ lib/libmemstat/memstat.c (working copy)
@@ -188,6 +188,7 @@
mtp->mt_count = 0;
mtp->mt_free = 0;
mtp->mt_failures = 0;
+ mtp->mt_sleeps = 0;
mtp->mt_zonefree = 0;
mtp->mt_kegfree = 0;
@@ -304,6 +305,13 @@
return (mtp->mt_failures);
}
+uint64_t
+memstat_get_sleeps(const struct memory_type *mtp)
+{
+
+ return (mtp->mt_sleeps);
+}
+
void *
memstat_get_caller_pointer(const struct memory_type *mtp, int index)
{
Index: lib/libmemstat/memstat_internal.h
===
--- lib/libmemstat/memstat_internal.h (revision 208460)
+++ lib/libmemstat/memstat_internal.h (working copy)
@@ -65,6 +65,7 @@
uint64_t mt_count; /* Number of current allocations. */
uint64_t mt_free; /* Number of cached free items. */
uint64_t mt_failures; /* Number of allocation failures. */
+ uint64_t mt_sleeps; /* Number of allocation sleeps. */
/*
* Caller-owned memory.
Index: lib/libmemstat/memstat_uma.c
===
--- lib/libmemstat/memstat_uma.c (revision 208460)
+++ lib/libmemstat/memstat_uma.c (working copy)
@@ -208,6 +208,7 @@
mtp->mt_numallocs = uthp->uth_allocs;
mtp->mt_numfrees = uthp->uth_frees;
mtp->mt_failures = uthp->uth_fails;
+ mtp->mt_sleeps = uthp->uth_sleeps;
for (j = 0; j < maxcpus; j++) {
upsp = (struct uma_percpu_stat *)p;
@@ -402,6 +403,7 @@
mtp->mt_numallocs = uz.uz_allocs;
mtp->mt_numfrees = uz.uz_frees;
mtp->mt_failures = uz.uz_fails;
+ mtp->mt_sleeps = uz.uz_sleeps;
if (kz.uk_flags & UMA_ZFLAG_INTERNAL)
goto skip_percpu;
for (i = 0; i < mp_maxid + 1; i++) {
Index: sys/vm/uma_int.h
===
--- sys/vm/uma_int.h (revision 208460)
+++ sys/vm/uma_int.h (working copy)
@@ -327,6 +327,7 @@
u_int64_t uz_allocs UMA_ALIGN; /* Total number of allocations */
u_int64_t uz_frees; /* Total number of frees */
u_int64_t uz_fails; /* Total number of alloc failures */
+ u_int64_t uz_sleeps; /* Total number of alloc sleeps */
uint16_t uz_fills; /* Outstanding bucket fills */
uint16_t uz_count; /* Highest value ub_ptr can have */
Index: sys/vm/uma.h
===
--- sys/vm/uma.h (revision 208460)
+++ sys/vm/uma.h (working copy)
@@ -600,7 +600,8 @@
u_int64_
Re: Exposing Zone Sleeps
> Hi Sean, > > Nice work on this. I applied this to stable/8 r208530 and I am in the > process of compiling the kernel right now. Everything else has built & > runs as expected "i386". Attached is the adjusted patch which was one > modification to the line number for uz_sleeps in sys/vm/uma_int.h. > > 8 files changed, 106 insertions(+), 7 deletions(-) > > For those wishing to apply this patch and test for them self: > > cd /usr/src > patch cd /usr/src/include > make obj && make depend && make includes && make install > cd /usr/src/lib/libmemstat > make obj && make depend && make includes && make install > cd /usr/src/usr.bin/vmstat > make obj && make depend && make install > cd /usr/src > make kernel KERNCONF=YOUR_KERN_CONF > reboot > > Can't wait to see some results from this & I will report back with > either negative results of the build & run or positive results from the > stats collected. > > If there is anything needed feel free to let me know and I will do what > is possible ASAP. > > Thanks again, > > - -- > > jhell Excellent. Please check the output of vmstat -z and the appropriate sysctl. I changed the display a bit to keep it from wrapping on a standard terminal. Sean P.S. My intention it to MFC this to all releases. ___ 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: Exposing Zone Sleeps
On Tue, 2010-05-25 at 07:47 -0700, Sean Bruno wrote: > > Hi Sean, > > > > Nice work on this. I applied this to stable/8 r208530 and I am in the > > process of compiling the kernel right now. Everything else has built & > > runs as expected "i386". Attached is the adjusted patch which was one > > modification to the line number for uz_sleeps in sys/vm/uma_int.h. > > > > 8 files changed, 106 insertions(+), 7 deletions(-) > > > > For those wishing to apply this patch and test for them self: > > > > cd /usr/src > > patch > cd /usr/src/include > > make obj && make depend && make includes && make install > > cd /usr/src/lib/libmemstat > > make obj && make depend && make includes && make install > > cd /usr/src/usr.bin/vmstat > > make obj && make depend && make install > > cd /usr/src > > make kernel KERNCONF=YOUR_KERN_CONF > > reboot > > > > Can't wait to see some results from this & I will report back with > > either negative results of the build & run or positive results from the > > stats collected. > > > > If there is anything needed feel free to let me know and I will do what > > is possible ASAP. > > > > Thanks again, > > > > - -- > > > > jhell > > Excellent. Please check the output of vmstat -z and the appropriate > sysctl. I changed the display a bit to keep it from wrapping on a > standard terminal. > > Sean > > P.S. My intention it to MFC this to all releases. > I do have a concern related to the removal of an #ifdef DDB in this patch. Any comments? Sean ___ 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: Exposing Zone Sleeps
On Wed, 2010-05-26 at 11:52 -0700, Garrett Cooper wrote:
> >>
> >> This patch instead pardon the early.post but there was a problem with
> >> the last patch that I attached for stable/8 r208530 with arguments 10 &
> >> 11 to function sysctl_vm_zone where it wanted a long unsigned integer
> >> rather than u_int64_t.
> >>
> >> This patch satisfies that. Whether its correct is left to the reader but
> >> compiles cleanly & runs smoothly.
> >
> > I know this seems trivial, but could you change:
> >
> > + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE",
> > + "LIMIT", "USED", "FREE", "REQ", "FAIL", "SLEEP");
> >
> > to
> >
> > + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE",
> > + "LIMIT", "USED", "FREE", "REQS", "FAIL", "SLEEP");
> >
> > that way the plural nature of requests is more straightforward and
> > understood.
> >
> > Also, do all of the fields _really_ need to have a field width? Seems
> > like overkill to me...
>
> Oh, and the field width for the last item is wrong; SLEEP will be
> truncated to SLEE.
> Thanks,
> -Garrett
I hate this type of column implementation. Any ideas on a more useful
implementation?
also, I'm missing an email in this thread somehow. I didn't see the
second version of the REL-8 patch.
Sean
___
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"
RFT Exposing Zone Sleeps
So, after some modifications and guidance from rwatson, alc and others,
I've modified this patch a bit. The end result is that a sleep on slab
alloc counter is displayed with a "vmstat -z". This can be used for
diagnostics of low memory situations and has been VERY handy at Yahoo.
I've removed the sysctl to eliminate some heartache, moved the sleep
count into a proper place in the data structure, properly instrumented
the debugger function and returned the #ifdef.
Patch provided against -current. Tested on amd64 and x86
Sean
Index: usr.bin/vmstat/vmstat.c
===
--- usr.bin/vmstat/vmstat.c (revision 209161)
+++ usr.bin/vmstat/vmstat.c (working copy)
@@ -1294,16 +1294,17 @@
memstat_strerror(error));
}
}
- printf("%-20s %8s %8s %8s %8s %8s %8s\n\n", "ITEM", "SIZE",
- "LIMIT", "USED", "FREE", "REQUESTS", "FAILURES");
+ printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE",
+ "LIMIT", "USED", "FREE", "REQ", "FAIL", "SLEEP");
for (mtp = memstat_mtl_first(mtlp); mtp != NULL;
mtp = memstat_mtl_next(mtp)) {
strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME);
strcat(name, ":");
- printf("%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n", name,
+ printf("%-20s %6llu, %6llu,%8llu,%8llu,%8llu,%4llu,%4llu\n",name,
memstat_get_size(mtp), memstat_get_countlimit(mtp),
memstat_get_count(mtp), memstat_get_free(mtp),
- memstat_get_numallocs(mtp), memstat_get_failures(mtp));
+ memstat_get_numallocs(mtp), memstat_get_failures(mtp),
+ memstat_get_sleeps(mtp));
}
memstat_mtl_free(mtlp);
printf("\n");
Index: lib/libmemstat/memstat.h
===
--- lib/libmemstat/memstat.h (revision 209161)
+++ lib/libmemstat/memstat.h (working copy)
@@ -139,6 +139,7 @@
uint64_t memstat_get_count(const struct memory_type *mtp);
uint64_t memstat_get_free(const struct memory_type *mtp);
uint64_t memstat_get_failures(const struct memory_type *mtp);
+uint64_t memstat_get_sleeps(const struct memory_type *mtp);
void *memstat_get_caller_pointer(const struct memory_type *mtp,
int index);
void memstat_set_caller_pointer(struct memory_type *mtp,
Index: lib/libmemstat/memstat.c
===
--- lib/libmemstat/memstat.c (revision 209161)
+++ lib/libmemstat/memstat.c (working copy)
@@ -188,6 +188,7 @@
mtp->mt_count = 0;
mtp->mt_free = 0;
mtp->mt_failures = 0;
+ mtp->mt_sleeps = 0;
mtp->mt_zonefree = 0;
mtp->mt_kegfree = 0;
@@ -304,6 +305,13 @@
return (mtp->mt_failures);
}
+uint64_t
+memstat_get_sleeps(const struct memory_type *mtp)
+{
+
+ return (mtp->mt_sleeps);
+}
+
void *
memstat_get_caller_pointer(const struct memory_type *mtp, int index)
{
Index: lib/libmemstat/memstat_internal.h
===
--- lib/libmemstat/memstat_internal.h (revision 209161)
+++ lib/libmemstat/memstat_internal.h (working copy)
@@ -65,6 +65,7 @@
uint64_t mt_count; /* Number of current allocations. */
uint64_t mt_free; /* Number of cached free items. */
uint64_t mt_failures; /* Number of allocation failures. */
+ uint64_t mt_sleeps; /* Number of allocation sleeps. */
/*
* Caller-owned memory.
Index: lib/libmemstat/memstat_uma.c
===
--- lib/libmemstat/memstat_uma.c (revision 209161)
+++ lib/libmemstat/memstat_uma.c (working copy)
@@ -208,6 +208,7 @@
mtp->mt_numallocs = uthp->uth_allocs;
mtp->mt_numfrees = uthp->uth_frees;
mtp->mt_failures = uthp->uth_fails;
+ mtp->mt_sleeps = uthp->uth_sleeps;
for (j = 0; j < maxcpus; j++) {
upsp = (struct uma_percpu_stat *)p;
@@ -402,6 +403,7 @@
mtp->mt_numallocs = uz.uz_allocs;
mtp->mt_numfrees = uz.uz_frees;
mtp->mt_failures = uz.uz_fails;
+ mtp->mt_sleeps = uz.uz_sleeps;
if (kz.uk_flags & UMA_ZFLAG_INTERNAL)
goto skip_percpu;
for (i = 0; i < mp_maxid + 1; i++) {
Index: sys/vm/uma_int.h
===
--- sys/vm/uma_int.h (revision 209161)
+++ sys/vm/uma_int.h (working copy)
@@ -327,6 +327,7 @@
u_int64_t uz_allocs UMA_ALIGN; /* Total number of allocations */
u_int64_t uz_frees; /* Total number of frees */
u_int64_t uz_fails; /* Total number of alloc failures */
+ u_int64_t uz_sleeps; /* Total number of alloc sleeps */
uint16_t uz_fills; /* Outstanding bucket fills */
uint16_t uz_count; /* Highest value ub_ptr can have */
Index: sys/vm/uma.h
===
--- sys/vm/uma.h (revision 209161)
+++ sys/vm/uma.h (working copy)
@@ -600,7 +600,8 @@
u_int64_t uth_allocs; /* Zone: number of allocations. */
u_int64_t uth_frees; /* Zone: number of frees. */
u_int64_t uth_fails; /* Zone: number of alloc failures. */
- u_int64_t _uth_reserved1[3]; /* Reserved
What is the exected behavior with the NMI button?
While trying to get a deadlock sorted out in the GPROF code, I attempted to use this fancy shmancy NMI button on my Dell server. I noted that, not unlike the goggles, it did nothing once the system was deadlocked. I noted that when the system was running normally, an NMI log message would be spewed to the console. What is supposed to happen in these two cases when we toggle the NMI button? Sean ___ 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: What is the exected behavior with the NMI button?
On Fri, 2010-06-25 at 07:17 -0700, Sean Bruno wrote: > While trying to get a deadlock sorted out in the GPROF code, I attempted > to use this fancy shmancy NMI button on my Dell server. > > I noted that, not unlike the goggles, it did nothing once the system was > deadlocked. I noted that when the system was running normally, an NMI > log message would be spewed to the console. In the event you don't get the goggles reference. http://www.youtube.com/watch?v=OqfOxm_1BE0 Sean ___ 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: Set default pxeboot vfs.root.mountfrom to nfs?
On Tue, 2010-06-29 at 15:07 -0700, Garrett Cooper wrote: > Hi Hackers, > I realize this is a trivial patch, but it's a minor item that I > found kind of fascinating (and not thoroughly documented elsewhere > because many examples are booting mfsroots instead of directly booting > off nfs roots), but I'm proposing that pxeboot default to > vfs.root.mountfrom="nfs" to reduce the need for special case > loader.conf files just for pxe booting (and thus, enable > out-of-the-box netbooting ^o^!!!). > Thoughts? > Thanks! > -Garrett I'll just give this a +1 and move on. sean ___ 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"
[Patch] Kgmon/Gprof On/Off Switch
Found this lying around the Yahoo tree this week. Basically it allows
you to activate, reset and deactivate profiling with the '-f" flag.
Kind of nice to have if you want the ability to turn on profiling for
debugging live systems.
Applies cleanly to head at the moment.
Sean
Index: usr.sbin/kgmon/kgmon.8
===
--- usr.sbin/kgmon/kgmon.8 (revision 209631)
+++ usr.sbin/kgmon/kgmon.8 (working copy)
@@ -70,6 +70,8 @@
Dump the contents of the profile buffers into a
.Pa gmon.out
file.
+.It Fl f
+Free profiling buffer. Also stops profiling.
.It Fl r
Reset all the profile buffers.
If the
Index: usr.sbin/kgmon/kgmon.c
===
--- usr.sbin/kgmon/kgmon.c (revision 209631)
+++ usr.sbin/kgmon/kgmon.c (working copy)
@@ -72,7 +72,7 @@
struct gmonparam gpm;
};
-int Bflag, bflag, hflag, kflag, rflag, pflag;
+int Bflag, bflag, hflag, kflag, rflag, pflag, fflag;
int debug = 0;
int getprof(struct kvmvars *);
int getprofhz(struct kvmvars *);
@@ -82,6 +82,7 @@
void dumpstate(struct kvmvars *kvp);
void reset(struct kvmvars *kvp);
static void usage(void);
+voidfreebuf(struct kvmvars *kvp);
int
main(int argc, char **argv)
@@ -93,7 +94,7 @@
seteuid(getuid());
kmemf = NULL;
system = NULL;
- while ((ch = getopt(argc, argv, "M:N:Bbhpr")) != -1) {
+ while ((ch = getopt(argc, argv, "M:N:Bbfhpr")) != -1) {
switch((char)ch) {
case 'M':
@@ -113,6 +114,10 @@
bflag = 1;
break;
+ case 'f':
+ fflag = 1;
+ break;
+
case 'h':
hflag = 1;
break;
@@ -158,6 +163,10 @@
dumpstate(&kvmvars);
if (rflag)
reset(&kvmvars);
+ if (fflag) {
+ freebuf(&kvmvars);
+ disp = GMON_PROF_OFF;
+ }
if (accessmode == O_RDWR)
setprof(&kvmvars, disp);
(void)fprintf(stdout, "kgmon: kernel profiling is %s.\n",
@@ -403,36 +412,44 @@
/*
* Write out the arc info.
*/
- if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL)
- errx(8, "cannot allocate froms space");
- if (kflag) {
- i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, (void *)froms,
- kvp->gpm.fromssize);
- } else {
- mib[2] = GPROF_FROMS;
- i = kvp->gpm.fromssize;
- if (sysctl(mib, 3, froms, &i, NULL, 0) < 0)
- i = 0;
- }
- if (i != kvp->gpm.fromssize)
- errx(9, "read froms: read %lu, got %ld: %s",
- kvp->gpm.fromssize, (long)i,
- kflag ? kvm_geterr(kvp->kd) : strerror(errno));
- if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == NULL)
- errx(10, "cannot allocate tos space");
- if (kflag) {
- i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, (void *)tos,
- kvp->gpm.tossize);
- } else {
- mib[2] = GPROF_TOS;
- i = kvp->gpm.tossize;
- if (sysctl(mib, 3, tos, &i, NULL, 0) < 0)
- i = 0;
- }
- if (i != kvp->gpm.tossize)
- errx(11, "read tos: read %lu, got %ld: %s",
- kvp->gpm.tossize, (long)i,
- kflag ? kvm_geterr(kvp->kd) : strerror(errno));
+if (kvp->gpm.fromssize > 0) {
+if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL)
+errx(8, "cannot allocate froms space");
+if (kflag) {
+i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms,
+ (void *)froms,
+ kvp->gpm.fromssize);
+} else {
+mib[2] = GPROF_FROMS;
+i = kvp->gpm.fromssize;
+if (sysctl(mib, 3, froms, &i, NULL, 0) < 0)
+i = 0;
+}
+if (i != kvp->gpm.fromssize)
+errx(9, "read froms: read %lu, got %ld: %s",
+ kvp->gpm.fromssize, (long)i,
+ kflag ? kvm_geterr(kvp->kd) : strerror(errno));
+}
+if (kvp->gpm.tossize > 0) {
+if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) ==
+ NULL)
+errx(10, "cannot allocate tos space");
+if (kflag) {
+i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos,
+ (void *)tos,
+ kvp->gpm.tossize);
+} else {
+mib[2] = GPROF_TOS;
+i = kvp->gpm.tossize;
+if (sysctl(mib, 3, tos, &i, NULL, 0) < 0)
+i = 0;
+}
+if (i != kvp->gpm.tossize)
+errx(11, "read tos: read %lu, got %ld: %s",
+ kvp->gpm.tossize, (long)i,
+ kflag ? kvm_geterr(kvp->kd) : strerror(errno));
+}
+
if (debug)
warnx("lowpc 0x%lx, textsize 0x%lx",
(unsigned long)kvp->gpm.lowpc, kvp->gpm.textsize);
@@ -509,11 +526,13 @@
if (kvm_write(kvp->kd, (u_long)kvp->gpm.kcount, zbuf,
kvp->gpm.kcountsize) != kvp->gpm.kcountsize)
errx(13, "tickbuf zero: %s", kvm_geterr(kvp->kd));
- if (
Re: [Patch] Kgmon/Gprof On/Off Switch
On Thu, 2010-07-01 at 16:46 -0700, Sean Bruno wrote:
> Found this lying around the Yahoo tree this week. Basically it allows
> you to activate, reset and deactivate profiling with the '-f" flag.
>
> Kind of nice to have if you want the ability to turn on profiling for
> debugging live systems.
>
> Applies cleanly to head at the moment.
>
> Sean
Updated with proper man page formatting.
Sean
Index: usr.sbin/kgmon/kgmon.8
===
--- usr.sbin/kgmon/kgmon.8 (revision 209745)
+++ usr.sbin/kgmon/kgmon.8 (working copy)
@@ -70,6 +70,9 @@
Dump the contents of the profile buffers into a
.Pa gmon.out
file.
+.It Fl f
+Free profiling buffer.
+Also stops profiling.
.It Fl r
Reset all the profile buffers.
If the
Index: usr.sbin/kgmon/kgmon.c
===
--- usr.sbin/kgmon/kgmon.c (revision 209745)
+++ usr.sbin/kgmon/kgmon.c (working copy)
@@ -72,7 +72,7 @@
struct gmonparam gpm;
};
-int Bflag, bflag, hflag, kflag, rflag, pflag;
+int Bflag, bflag, hflag, kflag, rflag, pflag, fflag;
int debug = 0;
int getprof(struct kvmvars *);
int getprofhz(struct kvmvars *);
@@ -82,6 +82,7 @@
void dumpstate(struct kvmvars *kvp);
void reset(struct kvmvars *kvp);
static void usage(void);
+voidfreebuf(struct kvmvars *kvp);
int
main(int argc, char **argv)
@@ -93,7 +94,7 @@
seteuid(getuid());
kmemf = NULL;
system = NULL;
- while ((ch = getopt(argc, argv, "M:N:Bbhpr")) != -1) {
+ while ((ch = getopt(argc, argv, "M:N:Bbfhpr")) != -1) {
switch((char)ch) {
case 'M':
@@ -113,6 +114,10 @@
bflag = 1;
break;
+ case 'f':
+ fflag = 1;
+ break;
+
case 'h':
hflag = 1;
break;
@@ -158,6 +163,10 @@
dumpstate(&kvmvars);
if (rflag)
reset(&kvmvars);
+ if (fflag) {
+ freebuf(&kvmvars);
+ disp = GMON_PROF_OFF;
+ }
if (accessmode == O_RDWR)
setprof(&kvmvars, disp);
(void)fprintf(stdout, "kgmon: kernel profiling is %s.\n",
@@ -403,36 +412,44 @@
/*
* Write out the arc info.
*/
- if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL)
- errx(8, "cannot allocate froms space");
- if (kflag) {
- i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, (void *)froms,
- kvp->gpm.fromssize);
- } else {
- mib[2] = GPROF_FROMS;
- i = kvp->gpm.fromssize;
- if (sysctl(mib, 3, froms, &i, NULL, 0) < 0)
- i = 0;
- }
- if (i != kvp->gpm.fromssize)
- errx(9, "read froms: read %lu, got %ld: %s",
- kvp->gpm.fromssize, (long)i,
- kflag ? kvm_geterr(kvp->kd) : strerror(errno));
- if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == NULL)
- errx(10, "cannot allocate tos space");
- if (kflag) {
- i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, (void *)tos,
- kvp->gpm.tossize);
- } else {
- mib[2] = GPROF_TOS;
- i = kvp->gpm.tossize;
- if (sysctl(mib, 3, tos, &i, NULL, 0) < 0)
- i = 0;
- }
- if (i != kvp->gpm.tossize)
- errx(11, "read tos: read %lu, got %ld: %s",
- kvp->gpm.tossize, (long)i,
- kflag ? kvm_geterr(kvp->kd) : strerror(errno));
+if (kvp->gpm.fromssize > 0) {
+if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL)
+errx(8, "cannot allocate froms space");
+if (kflag) {
+i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms,
+ (void *)froms,
+ kvp->gpm.fromssize);
+} else {
+mib[2] = GPROF_FROMS;
+i = kvp->gpm.fromssize;
+if (sysctl(mib, 3, froms, &i, NULL, 0) < 0)
+i = 0;
+}
+if (i != kvp->gpm.fromssize)
+errx(9, "read froms: read %lu, got %ld: %s",
+ kvp->gpm.fromssize, (long)i,
+ kflag ? kvm_geterr(kvp->kd) : strerror(errno));
+}
+if (kvp->gpm.tossize > 0) {
+if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) ==
+ NULL)
+errx(10, "cannot allocate tos space");
+if (kflag) {
+i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos,
+ (void *)tos,
+ kvp->gpm.tossize);
+} else {
+mib[2] = GPROF_TOS;
+i = kvp->gpm.tossize;
+if (sysctl(mib, 3, tos, &i, NULL, 0) < 0)
+i = 0;
+}
+if (i != kvp->gpm.tossize)
+errx(11, "read tos: read %lu, got %ld: %s&qu
Re: [Patch] Kgmon/Gprof On/Off Switch
On Tue, 2010-07-06 at 17:40 -0700, Bruce Evans wrote: > On Tue, 6 Jul 2010, Sean Bruno wrote: > > > On Thu, 2010-07-01 at 16:46 -0700, Sean Bruno wrote: > >> Found this lying around the Yahoo tree this week. Basically it allows > >> you to activate, reset and deactivate profiling with the '-f" flag. > > I want something like this, but this implementation has too many style > bugs and obscure or missing locking. > > >> Kind of nice to have if you want the ability to turn on profiling for > >> debugging live systems. > > We already have this via `kgmon -hBb', but this patch implements > something different. Normal profiling requires configuring the kernel > with "config -p[p]", but that adds a lot of overhead, even when profiling > is not turned on. The patch implements dynamic configuration of flat > profiling only (since dynamic call graphs are too hard to implement, > but this restriction is not mentioned anywhere in the patch or the > accompanying mail. > > Userland profiling has the same lossage -- you have to configure > programs specially by compiling with -pg, but that adds a lot of > overhead, even when profiling is not turned on. Moreover, in userland > there is no library support for turning profiling on and off or for > dumping and clearing the statistics except on program start and > completion, so the much larger overhead of always maintaining the call > graph is normally always present. > > In FreeBSD-1, I (ab)used a bug in the implementation to turn on flat > profiling (only) in the kernel. This avoids the large call graph > overhead (it still costs a function call and some other branches on > every call and maybe on every return, but the branches for this are > predictable so the overhead is not very large. This should be made > a standard feature, and perhaps this patch implements it as a bug > without really trying, as in FreeBSD-1 (implementing it just takes > setting gp->state to a value that gives flat profiling while keeping > mcount() null if full profiling is configured. > > % Index: usr.sbin/kgmon/kgmon.8 > % === > % --- usr.sbin/kgmon/kgmon.8(revision 209745) > % +++ usr.sbin/kgmon/kgmon.8(working copy) > % @@ -70,6 +70,9 @@ > % Dump the contents of the profile buffers into a > % .Pa gmon.out > % file. > % +.It Fl f > % +Free profiling buffer. > % +Also stops profiling. > % .It Fl r > % Reset all the profile buffers. > % If the > > Freeing the profiling buffer alone isn't very useful. The memory wastage > from always allocating it at boot time and never freeing it would be > rarely noticed, and would fix some races or simplify avoidance of races. > However, apart from the race problems, ordinary statically configured > profiling should free things too, since unlike in userland it is normal > to have profiling turned off most of the time even when it is statically > configured. > > The above doesn't really describe what -f does. In normal profiling, > there are multiple profiling buffers and freeing just the flat profiling > one makes no sense. -f in fact frees the profiling buffer only if the > kernel is _not_ configured for profiling (as is required to not corrupt > the set of profiling buffers if the kernel is configured for profiling). > The profiling buffer is automatically allocated on first use iff it > is not already allocated, and of course -f has no effect if no buffer > is allocated. Perhaps -r should automatically deallocate, so -f would > not be needed. Kernel profiling has this feature of allowing multiple > dumps of the buffer(s) before reset, so reset is a good time to deallocate. > > Style bugs in the above: f is unsorted between p and r. > > % Index: usr.sbin/kgmon/kgmon.c > % === > % --- usr.sbin/kgmon/kgmon.c(revision 209745) > % +++ usr.sbin/kgmon/kgmon.c(working copy) > % @@ -72,7 +72,7 @@ > % struct gmonparam gpm; > % }; > % > % -int Bflag, bflag, hflag, kflag, rflag, pflag; > % +int Bflag, bflag, hflag, kflag, rflag, pflag, fflag; > > Style bugs: now f is unsorted after r and p. p was already unsorted after r. > > % int debug = 0; > % int getprof(struct kvmvars *); > % int getprofhz(struct kvmvars *); > % @@ -82,6 +82,7 @@ > % void dumpstate(struct kvmvars *kvp); > % void reset(struct kvmvars *kvp); > % static void usage(void); > % +voidfreebuf(struct kvmvars *kvp); > > Style bugs: f is unsorted after u; all the old declarations are indented > with 1 tab while the new one is indented with spaces. > >
Re: svn commit: r210561 - projects/sv/sys/net
On Thu, 2010-07-29 at 14:06 -0700, Ed Maste wrote: > On Wed, Jul 28, 2010 at 03:10:31PM +, Attilio Rao wrote: > > > Log: > > Initial import of the netdump files. > > They still need a lot of polishing and cleanup so they might not be > > considered definitive at all. > > This code is a port to recent FreeBSD of Darrell Anderson's network > crashdump support, which was done in the 4.x days. I can't find a > current website with the original versions but archive.org has a cache > of course: > > http://web.archive.org/web/20041204223729/http://www.cs.duke.edu/~anderson/freebsd/netdump/ > > Quoting from the old readme: > > Netdump provides FreeBSD kernel crash dumping over the network. > Netdump is a FreeBSD kernel module client and user-level server. > > A normal kernel crash writes a raw dump of memory to a dedicated > partition (usually the swap partition) using a low-level disk routine, > and then copies that raw dump into a file (via savecore) during the > following boot process. > > Netdump replaces the standard dump routine. During a crash, a netdump > client broadcasts to locate a netdump server, then sends the dump as > UDP/IP packets (with retransmission after loss). The netdump server > creates a dump file suitable for gdb. If netdump fails (for example, > no netdump server is located), a normal disk dump is performed. > > There is cleanup work to be done still, but we plan to have this in > shape for 9.0. > > -Ed > ___ Excellent. I'll start tracking this over here at Yahoo. Sean ___ 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"
/etc/rc.d/mountcritremote
An issue in testing came up where we were trying to mount NFS directories from the same server, i.e. a machine trying to mount an NFS dir on itself. Because mountcritremote runs before the NFS server is up, we modified the REQUIRES section and appended nfsd. I *think* that this is a silly implementation, however it does make sense that this change be made. Comments? Index: mountcritremote === --- mountcritremote (revision 212057) +++ mountcritremote (working copy) @@ -4,7 +4,7 @@ # # PROVIDE: mountcritremote -# REQUIRE: NETWORKING FILESYSTEMS cleanvar ipsec +# REQUIRE: NETWORKING FILESYSTEMS cleanvar ipsec nfsd # KEYWORD: nojail . /etc/rc.subr ___ 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: /etc/rc.d/mountcritremote
On Tue, 2010-08-31 at 10:45 -0700, Dirk-WIllem van Gulik wrote: > On 31 Aug 2010, at 17:16, Sean Bruno wrote: > > > An issue in testing came up where we were trying to mount NFS > > directories from the same server, i.e. a machine trying to mount an NFS > > dir on itself. > > > > Because mountcritremote runs before the NFS server is up, we modified > > the REQUIRES section and appended nfsd. > > Are you sure that is right for PXE style boots - where this is heavily relied > on ? > > Dw. Not sure. If the nfs server isn't configured to startup, then this is a no-op. I'm not sure what application would be running in a pxeboot environment and run an NFS server. Sean ___ 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: /etc/rc.d/mountcritremote
On Tue, 2010-08-31 at 09:29 -0700, N.J. Mann wrote: > In message <1283271393.3665.13.ca...@home-yahoo>, > Sean Bruno (sean...@yahoo-inc.com) wrote: > > An issue in testing came up where we were trying to mount NFS > > directories from the same server, i.e. a machine trying to mount an NFS > > dir on itself. > > > > Because mountcritremote runs before the NFS server is up, we modified > > the REQUIRES section and appended nfsd. > > Is this not what the 'late' attribute in /etc/fstab is for? > > e.g. > > oberon% grep /usr/ports /etc/fstab > oberon:/export/usr/ports /usr/ports nfs late,rw,tcp > > > Cheers, >Nick. Good question. Looking over the man page for mount, is there any reason to use 'late' versus what I am suggesting? Sean ___ 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: /etc/rc.d/mountcritremote
On Tue, 2010-08-31 at 12:27 -0700, Garrett Cooper wrote: > On Tue, Aug 31, 2010 at 11:32 AM, Sean Bruno wrote: > > On Tue, 2010-08-31 at 09:29 -0700, N.J. Mann wrote: > >> In message <1283271393.3665.13.ca...@home-yahoo>, > >> Sean Bruno (sean...@yahoo-inc.com) wrote: > >> > An issue in testing came up where we were trying to mount NFS > >> > directories from the same server, i.e. a machine trying to mount an NFS > >> > dir on itself. > >> > > >> > Because mountcritremote runs before the NFS server is up, we modified > >> > the REQUIRES section and appended nfsd. > >> > >> Is this not what the 'late' attribute in /etc/fstab is for? > >> > >> e.g. > >> > >> oberon% grep /usr/ports /etc/fstab > >> oberon:/export/usr/ports /usr/ports nfs late,rw,tcp > > Specifying `late' seems extremely unnecessary for NFS mounts. If > mountcritremote can't properly depend on nmbd, nfsd, smbd for mounting > filesystems, then it seems like a rc script dependency issue > (otherwise, mountcritremote is basically mountcritlocal, waiting for > some networking connectivity to come up, right?). Yup. That's my impression. In my user's application, they have 100's of NFS mounts, of which ONE is a local-to-the-server mount. So, in this case, I don't really want to delay the mounting, I want the mounting to succeed at the time mountcritremote is invoked. The user application is doing something silly and severely knuckle headed, but it seems it should work in the way I propose instead of mounting late in "mountlate" However, I'm pretty ignorant of the dependencies in the system of rc scripts. There may be dragons here. Sean Sean ___ 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"
ATA patch for RELENG_6
I got this patch a while ago and I don't see it appearing in RELENG_6
yet. Can someone "sheperd" this along or point out why it's not acceptable?
This patch was generated by a failure to boot correctly off of a compact
flash IDE module from Transcend.
Index: dev/ata/ata-chipset.c
===
--- dev/ata/ata-chipset.c (.../FreeBSD_RELENG_6_13APR07/src/sys)
(revision 5436)
+++ dev/ata/ata-chipset.c (.../miralink.FreeBSD.6/src/sys)
(revision 5436)
@@ -2059,7 +2059,8 @@
atadev->mode = ATA_SA150;
}
else {
- mode = ata_limit_mode(dev, mode, ATA_UDMA5);
+ /*mode = ata_limit_mode(dev, mode, ATA_UDMA5);*/
+ mode = ata_check_80pin(dev, ATA_UDMA5);
if (!ata_controlcmd(dev, ATA_SETFEATURES, ATA_SF_SETXFER, 0, mode))
atadev->mode = mode;
}
--
Sean Bruno
MiraLink Corporation
6015 NE 80th Ave, Ste 100
Portland, OR 97218
Phone 503-621-5143
Fax 503-621-5199
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Error from systinstall while trying to install man page packages
I am attempting to install the man page distribution from sysinstall on my RELENG_7 box and getting errors that my distribution doesn't exist. I assume that it is due to the fact that I have recompiled my kernel and sysinstall is using something from my "uname" output to figure out what directories it should look in for packages. Can anyone give me some guidance on how to get sysinstall to know what it's version acutally is? uname output: FreeBSD ophelia 7.0-STABLE FreeBSD 7.0-STABLE #7: Fri Jun 27 12:11:52 UTC 2008 [EMAIL PROTECTED]:/usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC i386 -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Error from systinstall while trying to install man page packages
Sebastian Tymków wrote: Hi, You can set information in sysinstall using "Options" and setting "Release name" Best regards, Sebastian Tymkow Thanks. What should I set the Release name to? -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Error from systinstall while trying to install man page packages
Garrett Cooper wrote: On Fri, Jun 27, 2008 at 1:45 PM, Sean Bruno <[EMAIL PROTECTED]> wrote: Sebastian Tymków wrote: Hi, You can set information in sysinstall using "Options" and setting "Release name" Best regards, Sebastian Tymkow Thanks. What should I set the Release name to? According to uname above, 7.0-STABLE (IIRC). Maybe uname -r would show the appropriate value? -Garrett Everything looks fine here as far as I can tell. I still get an error from sysinstall stating that 7.0-STABLE can't be found. Since I rebuilt the kernel from src, should I buildworld on the box and see if that resolves the issue? [EMAIL PROTECTED] ~]$ uname -r 7.0-STABLE [EMAIL PROTECTED] ~]$ uname -a FreeBSD ophelia 7.0-STABLE FreeBSD 7.0-STABLE #9: Fri Jun 27 15:49:54 UTC 2008 [EMAIL PROTECTED]:/usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC i386 Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel module programming
well i'm making an interactive bootsplash for PCBSD and i wan't to know where i can get info in retrieving the current log from the kernel (dmesg output), sorry for any mistake as this is not my native lang... regards Bruno Faria... _ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Module Dependencies
I'm messing around with dev/firewire/sbp_targ at home this week and wanted to know if there was a way to warn or notify when trying to run config against a kernel configuration file that has "device sbp_targ" but doesn't have "device targbh". Is there such a mechanism? Sean ___ 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"
BSDCan Firewire Plugfest
Dan has accepted my proposal to have a plugfest at BSDCan on Friday night: http://www.bsdcan.org/2009/schedule/events/144.en.html I'm hoping that folks can bring their various devices and laptops to the occasion. Even if you don't have a Firewire device, swing by with your laptop and see if there's any new information to be gained from your machines. Sean ___ 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: smart self-test vs 7200.12/ich9r/ahci
On Thu, 2009-04-09 at 16:24 +0300, Andriy Gapon wrote: > I wonder if anybody has an issue like I do: > http://thread.gmane.org/gmane.linux.utilities.smartmontools/6354 > > Does anybody has guesses/clues about what might be happening? > I couldn't see anything specifically wrong with the output. Is there something wrong with the drive? Sean ___ 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: smart self-test vs 7200.12/ich9r/ahci
On Mon, 2009-04-13 at 10:06 +0300, Andriy Gapon wrote: > Smart self test never completing. The "self-test" never goes beyond "90%" complete? Sean ___ 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"
8 week projects
My open source class this summer has a lot of people in it looking for 8 week projects. If you have a decently spec'd out project that a Junior/Senior CS student can accomplish, send me a link or pointer to it and I'll see if I can get the project some attention. Sean ___ 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"
C6 sleep state
Has anyone worked on code for the C6 power state for the Intel Nehalem processors yet? http://download.intel.com/design/processor/applnots/320354.pdf Sean ___ 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: 6.0-STABLE & powerd: eating my keyboard input
On Thu, Nov 24, 2005 at 01:33:46AM +, BSD wrote: > Hi all, > > I just upgraded from 6.0-RELEASE to -STABLE today (FreeBSD 6.0-STABLE > #0: Thu Nov 24 00:40:48 WET 2005). After the upgrade I couldn't login > anymore, so I thought I probably erased master.passwd by mistake with > mergemaster, and rebooted into single user mode. Here I reset both root > and my user account password, and processed to multiuser, only to fail > the login again. Both on KDE and console. I rebooted again into single > user, and changed both password to 3 characters. Now I could login, but > every word I typed would have some letters wiped out (that was why the > login was failing, it was "eating" my password). > > A quick 'top' inspection showed powerd using ~30% CPU, which is > abnormal. I killed it, and voila! No more letter-eating. I started it > again, and back to the same. > > powerd has always worked fine, it started behaving like this when I > upgraded just an hour ago. This is a centrino laptop from acer. > Comments, suggestions ? > There is a recent commit from Nate Lawson dated 2005-11-24 05:29:15 UTC that should fix that issue. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850
On Tue, Jan 24, 2006 at 06:48:37PM -0500, Surer Dink wrote: > All, > (I was told this was /one/ of the appropriate forums for this message - > however I did not want to cross-post - if this is not the correct place, > please let me know and I will try the other suggestions [acpi- and ports-].) > > I have tried every means I could find to read the temperature sensors (CPU, > case, disk) on Dell PowerEdge 2850 machines, and none seem to work. Has > anyone had success in doing this? If such support does not exist, what > would be required to add it? If needed, I am willing to finance (within > reason) development of this feature. [I was told that Linux and Windows > software to read this information is available, so I assume this is > possible.] > First, install sysutils/freeipmi, then try it by this command: # bmc-info If it don't work, or loop forever, please install dmidecode (sysutils/dmidecode) then give us the output from it for the type entry 38 (IPMI Device Information). An example of such entry is: Handle 0x002B DMI type 38, 18 bytes. IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 1.5 I2C Slave Address: 0x10 NV Storage Device: Not Present Base Address: 0x0CA8 (I/O) Register Spacing: 32-bit Boundaries Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850
On Wed, Jan 25, 2006 at 03:39:44PM -0500, Surer Dink wrote:
> On 1/25/06, Bruno Ducrot <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Jan 24, 2006 at 06:48:37PM -0500, Surer Dink wrote:
> > > I have tried every means I could find to read the temperature sensors
> > (CPU,
> > > case, disk) on Dell PowerEdge 2850 machines, and none seem to work. Has
> > > anyone had success in doing this? If such support does not exist, what
> > > would be required to add it? If needed, I am willing to finance (within
> > > reason) development of this feature. [I was told that Linux and Windows
> > > software to read this information is available, so I assume this is
> > > possible.]
> >
> > First, install sysutils/freeipmi, then try it by this command:
> > # bmc-info
> >
> > If it don't work, or loop forever, please install
> > dmidecode (sysutils/dmidecode) then give us the output from
> > it for the type entry 38 (IPMI Device Information).
>
>
> bmc-info hangs, output of dmidecode for type 38 is:
> Handle 0x2600
> DMI type 38, 18 bytes.
> IPMI Device Information
> Interface Type: KCS (Keyboard Control Style)
> Specification Version: 1.5
> I2C Slave Address: 0x10
> NV Storage Device: Not Present
> Base Address: 0x0CA8 (I/O)
> Register Spacing: 32-bit Boundaries
>
> Incidentally, I attempted the same on other servers (Dell 2550 and some
> Supermicros) and they do not contain a "type 38" at all...
The DMI stuff is more or less optional. If not present, this won't
means IPMI is not there. For both Dell 2550 (this time..) and the
Supermicros, if there are some remote cards control then FreeIPMI should
work even if no such handle does not exist at all.
If this won't work, for the supermicro at least I
think sysutils/mbmon may work.
Back to the Dell 2850, the problem is the 'Register Spacing:
32-bit Boundaries' line.
FreeIPMI 0.1.3 does not implement this feature and use
always the default 8-bit boundary. The symptom is that bmc-info
hang forever.
Fortunately, the next release will include this support. By now,
there is a beta available but no port has been done.
By now, you can try to copy the attached file to
ports/sysutils/freeipmi/files
and rebuild the port.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
--- libfreeipmi/src/ipmi-kcs-interface.c2006/01/26 11:20:55 1.1
+++ libfreeipmi/src/ipmi-kcs-interface.c2006/01/26 11:24:14
@@ -70,11 +70,11 @@
#include "freeipmi.h"
#if defined(__FreeBSD__)
-#define _INB(port) inb (port)
-#define _OUTB(data, port) outb (port, data)
+#define _INL(port) inl (port)
+#define _OUTL(data, port) outl (port, data)
#else
-#define _INB(port) inb (port)
-#define _OUTB(data, port) outb (data, port)
+#define _INL(port) inL (port)
+#define _OUTL(data, port) outL (data, port)
#endif
static u_int64_t kcs_poll_count;
@@ -115,7 +115,7 @@
#ifdef __FreeBSD__
#ifdef USE_IOPERM
/* i386_set_ioperm has known problems on FBSD 5.x (bus errors). */
- return (i386_set_ioperm(sms_io_base, 0x02, 0x01));
+ return (i386_set_ioperm(sms_io_base, 0x08, 0x01));
#else
/* Opening /dev/io raises IOPL bits for current process. */
/* XXX This fd will remain open until exit as there is no
@@ -206,7 +206,7 @@
int8_t
ipmi_kcs_get_status (u_int16_t sms_io_base)
{
- return _INB (IPMI_KCS_REG_STATUS (sms_io_base));
+ return _INL (IPMI_KCS_REG_STATUS (sms_io_base));
}
/*
@@ -244,7 +244,7 @@
int8_t
ipmi_kcs_read_byte (u_int16_t sms_io_base)
{
- return _INB (IPMI_KCS_REG_DATAOUT (sms_io_base));
+ return _INL (IPMI_KCS_REG_DATAOUT (sms_io_base));
}
/*
@@ -253,7 +253,7 @@
void
ipmi_kcs_read_next (u_int16_t sms_io_base)
{
- _OUTB (IPMI_KCS_CTRL_READ, IPMI_KCS_REG_DATAIN (sms_io_base));
+ _OUTL (IPMI_KCS_CTRL_READ, IPMI_KCS_REG_DATAIN (sms_io_base));
}
/*
* Set up channel for writing.
@@ -261,7 +261,7 @@
void
ipmi_kcs_start_write (u_int16_t sms_io_base)
{
- _OUTB (IPMI_KCS_CTRL_WRITE_START, IPMI_KCS_REG_CMD (sms_io_base));
+ _OUTL (IPMI_KCS_CTRL_WRITE_START, IPMI_KCS_REG_CMD (sms_io_base));
}
/*
@@ -270,7 +270,7 @@
void
ipmi_kcs_write_byte (u_int16_t sms_io_base, u_int8_t byte)
{
- _OUTB (byte, IPMI_KCS_REG_DATAIN (sms_io_base));
+ _OUTL (byte, IPMI_KCS_REG_DATAIN (sms_io_base));
}
/*
@@ -279,7 +279,7 @@
void
ipmi_kcs_end_write (u_int16_t sms_io_base)
{
- _OUTB (IPMI_KCS_CTRL_WRITE_END, IPMI_KCS_REG_CMD (sms_io_base));
+ _OUTL (IPMI_KCS_CTRL_WRITE_END, IPMI_KCS_REG_CMD (sms_io_base));
}
/*
@@ -288,7 +288,7 @@
void
ipmi_kcs_get_abort (u_int16_t sms_io_base)
{
- _OUTB (IPMI_KCS_CTRL_GET_ABORT, IPMI_KCS_REG_CMD (sms_io_base));
+
Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850
On Thu, Jan 26, 2006 at 07:04:48PM +0100, Oliver Fromme wrote: > Hi, > > Sorry for jumping into this thread. > I have the same problem, but on different hardware. > > Bruno Ducrot <[EMAIL PROTECTED]> wrote: > > > > First, install sysutils/freeipmi, then try it by this command: > > > > # bmc-info > > It hangs forever. "bmc-config -o" prints a few lines > (starts with "Section User1" and doesn't seem useful), > then also hangs forever. > > Oh, by thy way, my machine is a HP ProLiant DL360 G4 > (formerly Compaq). Ask HP. They use a propritary solution. If they can't help you, I'm afraid nobody can't here. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DRM kernel module for unichrome ?
Hi everybody, I am trying to get DRI to work on a VIA C3 motherboard. Background: running mplayer freezes X. (just X, I can ssh and reboot the box) Running mplayer -vo x11 (instead of the default that uses Xv extension) works, but uses much CPU. I understand that for Xv, XVmc to work, DRI must be enabled. However, although the port graphics/dri includes a unichrome_dri.so, I do not see the corresponding drm kernel module in /boot/loader. (I would assume it would be unichrome.ko) The question is then, is anybody working on this module ? How hard is it to port the linux one over to FreeBSD ? Who "owns" the current drm kernel modules and how can I assist in porting the unichrome drm module ? bruno ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
valid VMA ranges and mincore()
Hi memory management hackers, The mincore(2) system call is, on FreeBSD, not usable for some purposes for which it can be used on other platforms. Let me explain the purpose, the problem and two proposed solutions. The purpose === The task at hand is to enumerate the VMAs of the current process. In other words, determine which address ranges are mapped and which aren't. If the /proc filesystem is available, the /proc/curproc/map file can be opened and parsed; it contains the necessary information. But I'm being told that /proc is not mounted by default, and as an application developer I have no control over that. So, I must look for a solution that works also when /proc is not mounted. The purpose of this task can be a) To detect whether a SIGSEGV is actually a stack overflow, a write access to a read-only memory page, or simply a bug in the program. If the fault address is near to the stack segment, it's likely a stack overflow; if it's nearer to a data segment, it's more likely a bug. b) To choose optimal addresses for mmap with MAP_FIXED that obey some constraints about lengths and bit patterns. Ideally the OS would have a system call that allows to iterate over the VMAs of the current process (corresponding to the lines of /proc/curproc/map), or to retrieve the list of VMAs as a big array. Lacking such a system call, on platforms other than FreeBSD, for example NetBSD, I can use mincore() instead. The problem === On NetBSD, Linux, Solaris, mincore() applied to a range of addresses that is partially not mapped, returns -1 with errno set to ENOMEM. See NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/sys/mincore.2?rev=1.19&content-type=text/plain Linux:http://linux.about.com/library/cmd/blcmdl2_mincore.htm Solaris: http://docs.sun.com/app/docs/doc/816-5167/6mbb2jaib?a=view This is consistent with mprotect(), which also fails with errno = ENOMEM if the address range is not fully mapped. FreeBSD doesn't work this way: it fills 0 values into the array passed as argument instead, a 0 for each unmapped page. This makes it impossible to distinguish a page which is valid address range but currently swapped out from a page which is unmapped. As a consequence, mincore() does not help for the aforementioned purpose. Proposals = Alternatively: Proposal 1: Change mincore() to behave like the one on NetBSD, Linux, Solaris. Proposal 2: Define a new constant MINCORE_MAPPED != 0, and change mincore() to set the per-page value to - MINCORE_MAPPED for a page that is mapped but swapped out, - 0 for a page which is unmapped address range. Proposal 1 would have the advantage to lead to the same code across platforms. Proposal 2 would have the advantage to be backward compatible. Can you do something about this? Bruno (an application programmer, not a FreeBSD kernel hacker) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: valid VMA ranges and mincore()
Hello Konstantin, Thanks for reacting on this issue. > Please, evaluate the patch. If it does what you need - It doesn't change the manual page mincore.2. - For unmapped areas, it appears to be filling in values of -1 into the array. This is not what Linux, Solaris, NetBSD do: They return -1 from the system call and set errno to ENOMEM. See Linux:http://linux.about.com/library/cmd/blcmdl2_mincore.htm Solaris: http://docs.sun.com/app/docs/doc/816-5167/6mbb2jaib?a=view NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/sys/mincore.2?rev=1.19&content-type=text/plain - Filling in values of -1 into the array will confuse existing applications, because -1 is all bits set, i.e. the nonexistent pages will appear to be in-core, modified, referenced. - Filling in values of -1 into the array could be done more easily by changing the statements in sys/vm/vm_mmap.c lines 861 and 902. Thanks. Bruno ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: valid VMA ranges and mincore()
Hello Konstantin,
> > - Filling in values of -1 into the array could be done more easily by
> > changing the statements in sys/vm/vm_mmap.c lines 861 and 902.
> I do not agree. It zeroes array not only for holes, but also for (some)
> skipped vm areas.
ok, you understand the code better than I do :-)
> Index: vm_mmap.c
> ===
> RCS file: /usr/local/arch/ncvs/src/sys/vm/vm_mmap.c,v
> retrieving revision 1.205
> diff -u -r1.205 vm_mmap.c
> --- vm_mmap.c 21 Apr 2006 07:17:25 - 1.205
> +++ vm_mmap.c 14 Jun 2006 13:51:20 -
> @@ -756,8 +756,10 @@
> first_addr = addr = trunc_page((vm_offset_t) uap->addr);
> end = addr + (vm_size_t)round_page(uap->len);
> map = &td->td_proc->p_vmspace->vm_map;
> - if (end > vm_map_max(map) || end < addr)
> + if (end < addr)
> return (EINVAL);
> + if (end > vm_map_max(map))
> + return (ENOMEM);
>
> /*
>* Address of byte vector
> @@ -770,8 +772,18 @@
> RestartScan:
> timestamp = map->timestamp;
>
> - if (!vm_map_lookup_entry(map, addr, &entry))
> - entry = entry->next;
> + if (!vm_map_lookup_entry(map, first_addr, &entry)) {
> + vm_map_unlock_read(map);
> + return (ENOMEM);
> + }
> + for (current = entry;
> + (current != &map->header) && (current->end < end);
> + current = current->next) {
> + if (current->end != current->next->start) {
> + vm_map_unlock_read(map);
> + return (ENOMEM);
> + }
> + }
>
> /*
>* Do this on a map entry basis so that if the pages are not
>
Looks good to me: This does what Linux, NetBSD, Solaris do. Thanks!
Bruno
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NOT A [GPL License violation]
On Sun, Oct 08, 2006 at 05:01:30PM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Lutz Boehne <[EMAIL PROTECTED]> writes: > : In any case, I suggest you get back to that person and ask for more > : information. > > That was my suggestion as well. I grepped the entire tree, both ports > and src, and couldn't find any code that came close to resembling this > code. > > Googling shows two packages that contain this code, but those aren't > part of FreeBSD and they are distributed under the LGPL and the GPL. > > Finally, there was no need to forward this to hackers@ or [EMAIL PROTECTED] > Not > only did I see it in audit, several people forwarded this to core@ for > investigation. > I'm working on Dell's laptop support, even though I'm not the one who code a tool for a fan control (and I don't know if such tool under FreeBSD exist). Some preminaly code can be found here: http://people.FreeBSD.org/~bruno/i8kutils_bsd.tar.bz [1] http://people.FreeBSD.org/~bruno/acpi_dell.tar.gz [2] http://people.FreeBSD.org/~bruno/dellctl.tar.gz [3] For now, the 3 tar ball above have not been publically send to any public list I'm aware of, because those are only priminally work. For [1], people can check I haven't removed any copyright, nor I even bothered adding my name. In any case, I don't plan to add that one to the base system. In fact, I think to remove it from http://people.FreeBSD.org/~bruno/ in the near future. For [2], people can check it's a really preliminary work, and is based on some calls to ACPI methods under the DSDT. Since it's a really different approach taken from the driver found under Linux, it's free from any GPL'ed code. Finally [3] is only a userspace tool to control [2]. Since [2] and [3] are free from any GPL'ed codes, I consider commiting them if one day they work. Actually I even considered to port [2] under Linux, because this is the right way to go when ACPI mode is enabled for obvious reason. The io ports related to the SMM handler are shared, and ACPI take care to handle an ACPI mutex before entering SMM, that at least might eliminate strange cases when sometimes i8k doesn't work. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NOT A [GPL License violation]
On Mon, Oct 09, 2006 at 08:53:30PM +0100, Jonathan Buzzard wrote: > Bruno Ducrot wrote: > > [SNIP] > > > > I'm working on Dell's laptop support, even though I'm not > > the one who code a tool for a fan control (and I don't > > know if such tool under FreeBSD exist). > > > > Some preminaly code can be found here: > > > > http://people.FreeBSD.org/~bruno/i8kutils_bsd.tar.bz [1] > > http://people.FreeBSD.org/~bruno/acpi_dell.tar.gz [2] > > http://people.FreeBSD.org/~bruno/dellctl.tar.gz [3] > > > > For now, the 3 tar ball above have not been publically send to any > > public list I'm aware of, because those are only priminally work. > > > > For [1], people can check I haven't removed any copyright, nor I even > > bothered adding my name. In any case, I don't plan to add that one to > > the base system. > > In fact, I think to remove it from http://people.FreeBSD.org/~bruno/ > > in the near future. > > > > For [2], people can check it's a really preliminary work, and is based > > on some calls to ACPI methods under the DSDT. Since it's a really > > different approach taken from the driver found under Linux, it's free > > from any GPL'ed code. > > > > Finally [3] is only a userspace tool to control [2]. > > > > Since [2] and [3] are free from any GPL'ed codes, I consider commiting > > them if one day they work. > > > > Actually I even considered to port [2] under Linux, because this is > > the right way to go when ACPI mode is enabled for obvious reason. > > The io ports related to the SMM handler are shared, and ACPI take > > care to handle an ACPI mutex before entering SMM, that at least might > > eliminate strange cases when sometimes i8k doesn't work. > > There is already a Toshiba ACPI module that does that I believe. Or at > least it exposes a /dev/toshiba that enables you to but the laptop into > SMM in the same was as the Toshiba/Dell drivers do. Not exactly. The ACPI method for the Toshiba is not the same as for the Dell. Toshiba use \_SB_.VALD.GHCI() method in order to access the HCI whereas Dell use \SMI() (and other methods). They are different and don't share any API I'm aware of, but I may be wrong of course. > I still use a 2.4 kernel and hence APM as I have never gotten around to > upgrading to 2.6, as this is complicated by running an entirely LVM system. > > You are however correct that ACPI is the correct way to go. Depend. If APM work better for you there is no reason to enable ACPI after all. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NOT A [GPL License violation]
On Tue, Oct 10, 2006 at 02:45:21PM +0800, Ganbold wrote: > Bruno, > > Did you make suspend/resume work? Unrelated. acpi_dell isn't for suspend/resume. But I'm aware of the problem and I'm working on that. > Did you make your volume up/down key work? That one of the goal. But there is a need to work more and I'm waiting some input from someone in touch with Dell BIOS engineers. That why I said this doesn't work, and why I haven't yet made them public. But I don't know if Jonathan Buzzard was aware of that work and if his complain was related to this work. > I have Latitude D620 and can't make above work. I might get one D620 soon hopefully. I will then be able to work more on this support. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
I am too dumb to understand geom(4)
How does one make geom_concat(4) load at boot, assume two devices are to be used as a single concatenated device and then create the /dev/ device for it? My MIPS kernconf has: # GEOM modules device geom_map# to get access to the SPI flash partitions device geom_uncompress # compressed in-memory filesystem hackery! device geom_concat # device geom_label # options GEOM_CONCAT # concatenation device support options GEOM_UNCOMPRESS options GEOM_LABEL And yet, I am unable to use gconcat to do anthing useful: # gconcat usage: gconcat help gconcat list [-a] [name ...] gconcat status [-ags] [name ...] gconcat load [-v] gconcat unload [-v] # kldstat -v|grep g_ 43 g_part_mbr 42 g_part_bsd 44 g_uncompress 38 g_map 41 g_part 19 g_md 35 g_concat 37 g_disk 57 g_class 40 g_label 39 g_vfs 36 g_dev signature.asc Description: This is a digitally signed message part
Re: I am too dumb to understand geom(4)
On Mon, 2013-09-16 at 13:16 +0200, Ivan Voras wrote: > On 13/09/2013 23:29, Sean Bruno wrote: > > How does one make geom_concat(4) load at boot, assume two devices are to > > be used as a single concatenated device and then create > > the /dev/ device for it? > > > > My MIPS kernconf has: > > > > # GEOM modules > > device geom_map# to get access to the SPI flash > > partitions > > device geom_uncompress # compressed in-memory filesystem > > hackery! > > device geom_concat # > > device geom_label # > > options GEOM_CONCAT # concatenation device support > > options GEOM_UNCOMPRESS > > options GEOM_LABEL > > > > And yet, I am unable to use gconcat to do anthing useful: > > > > # gconcat > > usage: gconcat help > >gconcat list [-a] [name ...] > >gconcat status [-ags] [name ...] > >gconcat load [-v] > >gconcat unload [-v] > > You are missing the "gconcat label" command. These commands are > implemented by .so helper libraries provided by GEOM classes, in this > case /lib/geom/geom_concat.so, so you need to make sure it exists. It > has nothing to do with the kernel. > > A ... yes. Thank you. I did not install any of the /lib/geom/*.so files into my disk image. Compiling and installing those does the trick. Thank you. Sean signature.asc Description: This is a digitally signed message part
Trying to use /bin/sh
I was attempting to simply set my EDITOR env variable for use on my system today and discovered that I do *not* understand how computers work. After realizing that I simply do not understand what's going on, I broke down and put an "echo test" into /etc/profile and ~/.profile. I can't see why, but logging in via xdm/xfce4 isn't doing any of the normal login things and nothing in my .profile is ever executed by any shell, ever. None of these get executed unless its a login shell. xfce4 doesn't seem to pick these up when starting up, so I have no idea what to do. For now, I've put the needed things into a .bashrc and switched my loging shell to bash, which is not really what I wanted to do. Sean signature.asc Description: This is a digitally signed message part
examining the environment
Hi everybody, How can I examine an other process environment ? I have a daemon that needs to do something according to an environment variable set in a different process. Can I open an other process and lookup environment variables set in his space ? bruno ### Bruno Schwander Senior Software Engineer Worldgate Communications, Inc email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: examining the environment
Thanks everybody, I checked the code and the magic function is kvm_getenvv() bruno Wes Peters wrote: > bruno schwander wrote: > > > > Hi everybody, > > > > How can I examine an other process environment ? > > > > I have a daemon that needs to do something according to an environment > > variable set in a different process. Can I open an other process and lookup > > environment variables set in his space ? > > ps can do this, check it's code. > > -- >Where am I, and what am I doing in this handbasket? > > Wes Peters [EMAIL PROTECTED] -- ### Bruno Schwander Senior Software Engineer Worldgate Communications, Inc email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
