Re: dump cache performance
On 2010-Oct-24 18:05:05 +0200, Jean-Francois Dockes j...@dockes.org wrote: It appears that modifying dump to use a shared cache in a very simple way (move the control structures to the shared segment and perform simple locking) yields substantial speed increases. Indeed. That's better than I expected. Would someone be interested in reviewing the patch and/or perform more tests ? I've mostly convered to ZFS but still have UFS root (which is basically a full base install without /var but including /usr/src - 94k inodes and 1.7GB). I've run both the 8-stable (stable) and patched (jfd) dump alternately 4 times with 50/250MB cache with the following results: x stable + jfd ++ | +| | +| | x+| |x xx +| ||AMA| ++ N Min MaxMedian AvgStddev x 4 9413 9673 95689555.5 107.12143 + 4 15359 15359 15359 15359 0 Difference at 95.0% confidence 5803.5 +/- 131.063 60.7347% +/- 1.3716% (Student's t, pooled s = 75.7463) -- Peter Jeremy pgpTPIvainovD.pgp Description: PGP signature
Re: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up
On Sunday, October 24, 2010 07:25:59 Matthias Apitz wrote:
Hello,
I have a new laptop Acer Aspire One D250 and I want to install a
8-CURRENT as of CVS from May 2009 (as I use this on all my laptops).
The laptop comes with as Wifi chip:
no...@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4
rev=0x01 hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM4310 USB Controller'
class = network
I learned after searching around that it should be supported by bwi(4)
and one should install the firmware kmod from the ports. I have in
loader.conf:
[..]
Please try attached patch, I'm not sure if it is that simple.. worth a try
though.
--
Bernhard
--- a/sys/dev/bwi/if_bwi_pci.c
+++ b/sys/dev/bwi/if_bwi_pci.c
@@ -85,6 +85,7 @@ static const struct bwi_dev {
{ PCI_VENDOR_BROADCOM, 0x4311,Broadcom BCM4311 802.11b/g Wireless Lan },
{ PCI_VENDOR_BROADCOM, 0x4312,Broadcom BCM4312 802.11a/b/g Wireless Lan },
{ PCI_VENDOR_BROADCOM, 0x4313,Broadcom BCM4312 802.11a Wireless Lan },
+ { PCI_VENDOR_BROADCOM, 0x4315,Broadcom BCM4312 802.11b/g Wireless Lan},
{ PCI_VENDOR_BROADCOM, 0x4320,Broadcom BCM4306 802.11b/g Wireless Lan},
{ PCI_VENDOR_BROADCOM, 0x4321,Broadcom BCM4306 802.11a Wireless Lan},
{ PCI_VENDOR_BROADCOM, 0x4325,Broadcom BCM4306 802.11b/g Wireless Lan},
___
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: fix pnpinfo on arch=amd64
On Saturday, October 23, 2010 8:22:48 pm Alexander Best wrote: this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any longer on arch=amd64. This utility isn't really useful on amd64 though. No amd64 machines have ISA slots in which to place an ISA PnP adapter. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fix pnpinfo on arch=amd64
On Mon, Oct 25, 2010 at 08:45:47AM -0400, John Baldwin wrote: On Saturday, October 23, 2010 8:22:48 pm Alexander Best wrote: this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any longer on arch=amd64. This utility isn't really useful on amd64 though. No amd64 machines have ISA slots in which to place an ISA PnP adapter. Are you really sure about that? See http://www.ibase.com.tw/2009/mb945.htmL or http://www.adek.com/ATX-motherboards.html for what certainly looks like counter-examples. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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: fix pnpinfo on arch=amd64
On Monday, October 25, 2010 9:34:37 am Erik Trulsson wrote: On Mon, Oct 25, 2010 at 08:45:47AM -0400, John Baldwin wrote: On Saturday, October 23, 2010 8:22:48 pm Alexander Best wrote: this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any longer on arch=amd64. This utility isn't really useful on amd64 though. No amd64 machines have ISA slots in which to place an ISA PnP adapter. Are you really sure about that? See http://www.ibase.com.tw/2009/mb945.htmL or http://www.adek.com/ATX-motherboards.html for what certainly looks like counter-examples. Hmm, well, I suspect in this case these boards exist to support really ancient custom hardware. If you are stuck with one of these, then manually needing to fix up pnpinfo.c is probably the least of your problems. However, I strongly doubt that FreeBSD users are lining up to buy these motherboards so they can use an ISA SB16 adapter with FreeBSD/amd64. I was not aware of these boards previously, but I still doubt that pnpinfo is relevant to any FreeBSD/amd64 users. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On Sat, 2010-10-23 at 15:20 +0400, Anthony Pankov wrote:
Greetings.
Just for note.
Some time ago i thought about the same problem.
I started something then had delayed it forever in favour of fast wrong
way.
So, the aim was:
---
NAME
modcfg - modify configuration
SYNOPSIS
modcfg -f config_file -t config_type {-s param=val | -u param}
modcfg -l
modcfg -i plugin
DESCRIPTION
The modcfg utility modifies configuration file in
accordance to parameters.
The following options are available:
-f config_file- the file itself which to be modified
-t config_type- type of config_file. Type specifies the internal
structure of config_file, or, more roughly,
program which this file belongs to. To
list available types see -l option.
-s param=val - set configuration parameter 'param' to value
'val'.
-u param - unset configuration parameter 'param' (or set it to
default).
-l - list all supported types of config files.
-i plugin- install plugin 'plugin' for modcfg utility.
Plugin is used to support additional configuration file
type.
EXAMPLES
The command
modcfg -f /etc/rc.conf -t rc -s keymap=ru.cp1251
sets parameter 'keymap' to value 'ru.cp1251'in file rc.conf.
The command
modcfg -f /etc/rc.conf -t rc -u keymap
resets parameter 'keymap' to default value.
I think it's great that you've taken on the task of finding a solution
that works best for you, but this doesn't really work that well for the
case of rc.conf(5) files because it neither sources
`/etc/defaults/rc.conf' nor calls source_rc_confs() from said-file.
So yes, one could modify a variable in a given file with your utility,
but it doesn't take into account that rc.conf(5) is not a single file,
it's a collection of files. Least of which contains:
/etc/defaults/rc.conf
/etc/rc.conf
/etc/rc.conf.local
/etc/rc.conf.d/*
NOTE: The last one is not sourced by source_rc_confs() but is sourced
by /etc/rc.d/* (the local-service boot-scripts), most [if not all] of
which call load_rc_config(). In example, /etc/rc.d/foo would first
source /etc/rc.subr then call `load_rc_config foo' which will both call
source_rc_confs() from /etc/defaults/rc.conf AND
source /etc/rc.conf.d/foo [if it exists].
This heirarchical structure forces a level of complexity onto the user
which _can_ be confusing at times to less experienced users, and
therefore providing a utility that ignores said-heirarchy forces the
user to either navigate the complexity themselves or to write a wrapper
script around your utility to manage it for them.
Whereas, I started my utility (sysrc) from the ground-up with the
express purpose of wrangling this complexity. I wanted a tool that would
-- overall -- help me in my daily routines of managing thousands of
FreeBSD workstations/pedestals/servers (fyi: a pedestal is server-class
hardware in workstation-tower-like chassis).
To install obtained plugin 'samba.mcfg' use
modcfg -i samba.mcfg
After that configuration type 'samba' will be supported.
Out of curiosity, why must the user be forced to install the plugin
manually? Why not have the code automatically probe for the plugin on
first-use? For example, when 'samba'-type is used for the first time,
take that as a queue to load the module and if the module can't be
loaded, die with an error. I think this streamlines the process (but
wouldn't go as far as to remove the `-i' parameter -- keep it, it could
be useful to some).
---
INTERNALLY
modcfg itself is very simple. It parse command line options, then load
plugin (module) for specified 'config_type', then call _set(file,param,
value) or _unset(file,param) function from this module.
So, plugin (module) should have functions such as:
_set(file, param, value) or, better name, {$type}_set. rc_set, for
example.
_unset(file, param)
_description - for display in module list.
Your utility I think loosely resembles Apple's Core Data Programming
API.
I recently have been making my way through this Mac/iOS API known as
Core Data Programming which uses relationship mapping (similar to your
`config_type') to teach the Core Data API how modify different
underlying data containers (but extends far beyond BSD-style
configuration files).
For example, Core Data -- in an object-oriented fashion -- provides a
set of high-level access routines for accessing your data meanwhile the
specifics of how that data was obtained or how said data is persistently
stored back to the container are hidden from your application (much in
the way that your utility masks from the user how the data is stored in
the specific configuration-file type).
Much like your utility, Core Data already supports some well-known data
containers -- SQLite, Boulder/IO (simple key=value pairs), etc. -- and
can easily be extended through OOP's
Re: fix pnpinfo on arch=amd64
On Sun Oct 24 10, Garrett Cooper wrote: On Sun, Oct 24, 2010 at 4:57 AM, Alexander Best arun...@freebsd.org wrote: On Sat Oct 23 10, Garrett Cooper wrote: On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best arun...@freebsd.org wrote: this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any longer on arch=amd64. 1. I had to modify the Makefile to get it to work. probably because you built pnpinfo from contrib/pnpinfo and not from usr.sbin/pnpinfo. i'm not sure your changes to contrib/pnpinfo/Makefile are according to current practice. maybe the vendor Makefile shouldn't be modified and every additional stuff should rather go into usr.sbin/pnpinfo/Makefile. but i don't really know. Ah... I was a bit confused as to why there was a copy hanging out in contrib, because it seems like it was imported primarily to FreeBSD in 2.2 (which contradicts the manpage as it states that it was imported in 7.2). I see it's over in DragonFly, but not in the other BSDs; it has a BSD license; doesn't denote any kind of proprietary info (leverages some of the FreeBSD isa(4) driver structures); doesn't have an external website for development; etc. I was also a bit confused why this directory wasn't iterated over in usr.sbin, but it appears to be missing from SUBDIR in usr.sbin/Makefile (wonder how many others are missing and whether or not the tools / apps really have any value, but that's another top for another thread). also in the in usr.sbin/pnpinfo/makefile there's a check for PC98 that i'm not sure is really needed. No, it's not used anymore (I looked over pnpinfo and the isa/machine headers). 2. FWIW, I don't there's really much point in adding a check for only x86 architectures, if the tool is capable of more than that. yeah you're probably right. to be honest i know nothing about archs != i386|amd64. ;) so i just added the amd64 option, because i didn't want to break pnpinfo on other platforms. Well, but there are other platforms, other than x86 that could benefit from using this tool (arm, mips, etc). There might be some bugs lurking in the code dealing with endianness, but that should be resolved first by enabling the tool for all platforms and fixing the cases one by one (unfortunately I don't have either architecture at my disposal, otherwise I'd test this out). I do have a Sparc64 pizza box that I could test this out on though later on this week... hmmm. 3. Might as well close the file descriptor after opening it. right. expecially, because opening /dev/io (even in ro mode) is a huge security issue. so better close it asap. of course on i386/amd64 (maybe pc98 too?) i386_set_ioperm(2) could be used to work around the security issue. but since pnpinfo's job is to access hardware directly i think opening /dev/io directly can be consideren ok. Well, right... but there's no reason to leak a filehandle until the program is finished :). SIGBUS occurs because it doesn't have permission to write via outb. It's a shame that there isn't a more proper way to catch this SIGBUS fault minus adding a SIGBUS handler (but that might have other undesired side effects). well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper io permissions. Yeah, and it's x86 specific. Kind of curious why there isn't a more generalized name for this API, but it appeared to be geared towards x86 (today, not so much according to LEGACY in io(4)). FWIW, it also looks like the manpages are missing for those syscalls, even though they're referenced in io(4)... $ man i386_get_ioperm No manual entry for i386_get_ioperm $ man i386_set_ioperm No manual entry for i386_set_ioperm are you running amd64? me too. it appears these manual pages are only being installed under i386. that's a bug imo. they should also be installed under amd64. the manuals are in /usr/src/lib/libc/i386/sys/ ... and I couldn't find anything in the syscall entry table for this syscall. I did a bit more poking and it looks like the Linux ioperm syscall is the only really publicly available means of accessing this functionality. I could be wrong though. they are defined in /usr/src/sys/amd64/include/sysarch.h (for amd64) and /usr/src/sys/i386/include/sysarch.h (for i386). Thanks, -Garrett -- a13x ___ 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
SYSCALL_MODULE() macro and modfind() issues
hi fbsd-hackers,
Noticed a issue in 8.1-release, 8.1p1-release and 8.1-stable
amd64/i386, to where modfind() will no longer find pmap_helper for the
/usr/ports/sysutils/pmap port, or other syscall modules using
SYSCALL_MODULE() macro.
The issue is that modfind() function no longer finds any modules using
SYSCALL_MODULE() macro to register the kernel module. Making it
difficult for userland apps to call the syscall provided. modfind()
always returns -1 which prevents modstat() from getting the required
information to perform the syscall.
Also tested, the demo syscall module:
cat /usr/share/examples/kld/syscall/module/syscall.c
/*-
* Copyright (c) 1999 Assar Westerlund
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD: src/share/examples/kld/syscall/module/syscall.c,v
1.6.2.1.4.1 2010/06/14 02:09:06 kensmith Exp $
*/
#include sys/param.h
#include sys/proc.h
#include sys/module.h
#include sys/sysproto.h
#include sys/sysent.h
#include sys/kernel.h
#include sys/systm.h
/*
* The function for implementing the syscall.
*/
static int
hello(struct thread *td, void *arg)
{
printf(hello kernel\n);
return (0);
}
/*
* The `sysent' for the new syscall
*/
static struct sysent hello_sysent = {
0, /* sy_narg */
hello /* sy_call */
};
/*
* The offset in sysent where the syscall is allocated.
*/
static int offset = NO_SYSCALL;
/*
* The function called at load/unload.
*/
static int
load(struct module *module, int cmd, void *arg)
{
int error = 0;
switch (cmd) {
case MOD_LOAD :
printf(syscall loaded at %d\n, offset);
break;
case MOD_UNLOAD :
printf(syscall unloaded from %d\n, offset);
break;
default :
error = EOPNOTSUPP;
break;
}
return (error);
}
SYSCALL_MODULE(syscall, offset, hello_sysent, load, NULL);
-
/* userland app to call syscall */
#include stdio.h
#include sys/syscall.h
#include sys/types.h
#include sys/module.h
int main(int argc, char **argv) {
char *endptr;
int syscall_num;
struct module_stat stat;
/*Helloworld syscall test*/
stat.version = sizeof(stat);
modstat(modfind(syscall), stat);
syscall_num = stat.data.intval;
syscall (syscall_num);
}
-
-Estella Mystagic (Selphie)
___
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
stock gdb bug: DWARF2 with DWARF_OFFSET_SIZE == 8
gdb on MIP64 does not read DWARF2 line information correctly if gcc was configured with DWARF_OFFSET_SIZE == 8. .debug_line starts with total length field which could be 12 bytes long or 4 bytes long. If it starts with 0x - it's 12 bytes long. Depending on its size one of the following field is either 8 bytes or 4 bytes. This one-line patch fixes this issue for MIPS64 but I'm not 100% sure that it doesn't break something else. So I'd appreciate input of someone with better grip on ELF/DWARF stuff then me. Patch: http://people.freebsd.org/~gonzo/patches/mips64gdb.diff Thanks. ___ 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
