FreeBSD Quarterly Status Report for October - December 2009
Introduction This report covers FreeBSD related projects between October and December 2009. This is the last of the four reports covering 2009, which has shown to be a very important year for the FreeBSD Project. Besides other notable things, a new major version of FreeBSD, 8.0-RELEASE, has been released, while the release process for 7.3-RELEASE is soon to begin. Thanks to all the reporters for the excellent work! We hope you enjoy reading. Let us also take this opportunity to wish you all a happy and successful new year for 2010. Please note that the deadline for submissions covering the period between January and March 2010 is April 15th, 2010. __ Google Summer of Code * BSD-licensed iconv Projects * 3G USB support * Clang replacing GCC in the base system * FreeBSD TDM Framework * HAST -- Highly Available Storage * Intel XScale hwpmc(9) support * POSIX utmpx for FreeBSD * SUJ -- Journaled SoftUpdates * The webcamd deamon FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Release Engineering * The FreeBSD Foundation Status Report Network Infrastructure * bwn(4) -- Broadcom Wireless driver * IP Payload Compression Protocol support * Ralink wireless RT2700U/2800U/3000U run(4) USB driver * Syncing pf(4) with OpenBSD 4.5 * Wireless mesh networking Kernel * CAM-based ATA implementation * Group Limit Increase * NFSv4 ACL support * V4L support in Linux emulator Documentation * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project Architectures * Flattened Device Tree for embedded FreeBSD * FreeBSD/ia64 * FreeBSD/mips * FreeBSD/sparc64 Ports * Chromium web browser * Ports Collection * VirtualBox on FreeBSD Vendor / 3rd Party Software * DAHDI (Zaptel) support for FreeBSD * NVIDIA amd64 driver Miscellaneous * AsiaBSDCon 2010 -- The BSD Conference * BSDCan 2010 -- The BSD Conference * meetBSD 2010 -- The BSD Conference * The FreeBSD Forums Userland utilities * BSD-licensed text processing tools __ 3G USB support Contact: Andrew Thompson thom...@freebsd.org Recently, a bunch of new device IDs have been added for the u3g(4) cellular wireless driver; the list should be comparable now with other operating systems around. A lot of these devices have a feature where the unit first attaches as a disk or CD-ROM that contains the Win/Mac drivers. This state should be detected by the u3g driver and the usb device is sent a command to switch to modem mode. This has been working for quite some time but as it is implemented differently for each vendor I am looking for feedback on any units where the auto switchover is not working (or the init is not recognized at all). Please ensure you are running an up to date kernel, like r201681 or later from 9.0-CURRENT, or 8-STABLE after the future merge of this revision. __ AsiaBSDCon 2010 -- The BSD Conference URL: http://2010.AsiaBSDCon.org/ Contact: AsiaBSDCon Information secret...@asiabsdcon.org AsiaBSDCon is a conference for users and developers on BSD based systems. AsiaBSDCon is a technical conference and aims to collect the best technical papers and presentations available to ensure that the latest developments in our open source community are shared with the widest possible audience. The conference is for anyone developing, deploying and using systems based on FreeBSD, NetBSD, OpenBSD, DragonFlyBSD, Darwin and MacOS X. The next conference will be held at the Tokyo University of Science, Tokyo, Japan, on 11th to 14th March, 2010. For more detailed information, please check the conference web site. __ BSD-licensed iconv URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 009/gabor_iconv Contact: Gábor Kövesdán ga...@freebsd.org Good compatibility has been ensured and there are only few pending items that have to be reviewed/enhanced. Recently, an enhancement has been completed, which makes it possible to accomplish better transliteration, just like in the GNU version. An initial testing patch is expected at the beginning of February. Open tasks: 1. Enhance conversion tables to make use of enhanced transliteration. 2. A performance optimization might be done later. __ BSD-licensed text processing tools URL:
Re: ptrace bug or feature?
On Sat, Jan 16, 2010 at 09:01:37PM +0200, Ali Polatel wrote:
Hey everyone,
Problem: ptrace's PT_SETREGS request can't alter system calls.
Code: http://alip.github.com/code/ptrace-freebsd-deny.c
Expected: The file foo.bar shouldn't be created.
Got: The file is created. Other efforts like replacing
PT_GETREGS/PT_SETREGS calls with PT_KILL doesn't help, the file is
created nevertheless.
I'm inclined to call this a bug but I can't be sure.
Any comments appreciated.
TIA
It may be a missed feature, not a bug. There is obvious hack value
in ability to modify syscall arguments from the debugger.
Do you know whether other operating systems allow this ?
I was around this code today, and wrote the patch for i386, amd64
and ia32 on amd64. Other architectures need to be handled.
diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c
index df301d1..bd7ee63 100644
--- a/sys/amd64/amd64/trap.c
+++ b/sys/amd64/amd64/trap.c
@@ -885,95 +885,131 @@ dblfault_handler(struct trapframe *frame)
panic(double fault);
}
-/*
- * syscall - system call request C handler
- *
- * A system call is essentially treated as a trap.
- */
-void
-syscall(struct trapframe *frame)
-{
- caddr_t params;
+struct syscall_args {
+ u_int code;
struct sysent *callp;
- struct thread *td = curthread;
- struct proc *p = td-td_proc;
- register_t orig_tf_rflags;
- int error;
- int narg;
register_t args[8];
register_t *argp;
- u_int code;
- int reg, regcnt;
- ksiginfo_t ksi;
-
- PCPU_INC(cnt.v_syscall);
+ int narg;
+};
-#ifdef DIAGNOSTIC
- if (ISPL(frame-tf_cs) != SEL_UPL) {
- panic(syscall);
- /* NOT REACHED */
- }
-#endif
+static int
+fetch_syscall_args(struct thread *td, struct syscall_args *sa)
+{
+ struct proc *p;
+ struct trapframe *frame;
+ caddr_t params;
+ int reg, regcnt, error;
+ p = td-td_proc;
+ frame = td-td_frame;
reg = 0;
regcnt = 6;
- td-td_pticks = 0;
- td-td_frame = frame;
- if (td-td_ucred != p-p_ucred)
- cred_update_thread(td);
+
params = (caddr_t)frame-tf_rsp + sizeof(register_t);
- code = frame-tf_rax;
- orig_tf_rflags = frame-tf_rflags;
+ sa-code = frame-tf_rax;
if (p-p_sysent-sv_prepsyscall) {
- (*p-p_sysent-sv_prepsyscall)(frame, (int *)args, code,
params);
+ (*p-p_sysent-sv_prepsyscall)(frame, (int *)sa-args,
+ sa-code, params);
} else {
- if (code == SYS_syscall || code == SYS___syscall) {
- code = frame-tf_rdi;
+ if (sa-code == SYS_syscall || sa-code == SYS___syscall) {
+ sa-code = frame-tf_rdi;
reg++;
regcnt--;
}
}
-
if (p-p_sysent-sv_mask)
- code = p-p_sysent-sv_mask;
+ sa-code = p-p_sysent-sv_mask;
- if (code = p-p_sysent-sv_size)
- callp = p-p_sysent-sv_table[0];
+ if (sa-code = p-p_sysent-sv_size)
+ sa-callp = p-p_sysent-sv_table[0];
else
- callp = p-p_sysent-sv_table[code];
+ sa-callp = p-p_sysent-sv_table[sa-code];
- narg = callp-sy_narg;
- KASSERT(narg = sizeof(args) / sizeof(args[0]),
+ sa-narg = sa-callp-sy_narg;
+ KASSERT(sa-narg = sizeof(sa-args) / sizeof(sa-args[0]),
(Too many syscall arguments!));
error = 0;
- argp = frame-tf_rdi;
- argp += reg;
- bcopy(argp, args, sizeof(args[0]) * regcnt);
- if (narg regcnt) {
+ sa-argp = frame-tf_rdi;
+ sa-argp += reg;
+ bcopy(sa-argp, sa-args, sizeof(sa-args[0]) * regcnt);
+ if (sa-narg regcnt) {
KASSERT(params != NULL, (copyin args with no params!));
- error = copyin(params, args[regcnt],
- (narg - regcnt) * sizeof(args[0]));
+ error = copyin(params, sa-args[regcnt],
+ (sa-narg - regcnt) * sizeof(sa-args[0]));
}
- argp = args[0];
+ sa-argp = sa-args[0];
+ /*
+* This may result in two records if debugger modified
+* registers or memory during sleep at stop/ptrace point.
+*/
#ifdef KTRACE
if (KTRPOINT(td, KTR_SYSCALL))
- ktrsyscall(code, narg, argp);
+ ktrsyscall(sa-code, sa-narg, sa-argp);
#endif
+ return (error);
+}
- CTR4(KTR_SYSC, syscall enter thread %p pid %d proc %s code %d, td,
- td-td_proc-p_pid, td-td_name, code);
+/*
+ * syscall - system call request C handler
+ *
+ * A system call is essentially treated as a trap.
+ */
+void
+syscall(struct trapframe *frame)
+{
+ struct thread *td;
+ struct proc *p;
+ struct syscall_args sa;
+
Re: ptrace bug or feature?
On Sun, 17 Jan 2010, Kostik Belousov wrote: It may be a missed feature, not a bug. There is obvious hack value in ability to modify syscall arguments from the debugger. Do you know whether other operating systems allow this ? Linux does, I've used it. -- Nate Eldredge n...@thatsmathematics.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ptrace bug or feature?
Nate Eldredge yazmış: On Sun, 17 Jan 2010, Kostik Belousov wrote: It may be a missed feature, not a bug. There is obvious hack value in ability to modify syscall arguments from the debugger. Do you know whether other operating systems allow this ? Linux does, I've used it. Yep it does, here's example code: http://alip.github.com/code/ptrace-linux-deny.c -- Nate Eldredge n...@thatsmathematics.com -- Regards, Ali Polatel pgpKVUVxSoTYO.pgp Description: PGP signature
Weekend PR smashing
Howdy all, I've recently taken up perusing the PR database looking for small(ish) bugs that will help me: (1) start contributing to FreeBSD again (2) familiarize myself with -CURRENT. Last weekend I knocked off #43337 (to which my patch still remains unaddressed) and started looking for more and more bugs, particularly in the 'bin' category. I've noticed a couple things, and would love a helping hand with: * There's a lot of **old** PRs, some of the userland bugs that are over a decade old I have no idea what to do with (try to reproduce a bug filed against 2.2?) * There's a lot of PRs with patches and a discussion; I don't *think* I can do anything helpful with these Additionally, I feel somewhat overwhelmed, I'm really hunting for tasks anywhere from a few hours to an all-nighter. Some of the things the KDE team does to get people involved I find useful, such as the bugs howto for information on triaging and getting started with contributing: http://quality.kde.org/develop/howto/howtobugs.php As well as the junior jobs keyword in their bugzilla: https://bugs.kde.org/buglist.cgi?keywords=junior-jobsbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcmdtype=doit Are there similar resources I've not stumbled across yet? I would like to help, I have but one machine running -CURRENT and sporadic free time over the weekends. Tips? :D Cheers, -R. Tyler Ballance -- Jabber: rty...@jabber.org GitHub: http://github.com/rtyler Twitter: http://twitter.com/agentdero Blog: http://unethicalblogger.com pgpE7fenfBmzv.pgp Description: PGP signature
limits for run away Firefox ?
Hi hackers I'm tired of my X server occasionaly freezing, swap thrasing, firefox dumps: 4,346,937,344 ~/firefox-bin.core so as a temporary cludge I ran touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core I could put X users in another group, reduce limits, per man login.conf ... RESOURCE LIMITS suggestions of values welcome. Yes 7.1 is old, thats my screen server, till I complete local builds of 7.2 8.0 on other boxes., then I'll upgrade, but I'll still want firefox though I see firefox is still troublesome eg uname -r # 8.0-RELEASE cd /usr/ports/www/firefox/Makefile ; make make# === firefox-2.0.0.20_9,1 is forbidden: too many security issues cd ../firefox3 ; make # is OK, runs on 8.0 i686, but on amd64 fails with GLib-WARNING **: g_set_prgname() called multiple times so I'm pausing for perspective, comment invited :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: limits for run away Firefox ?
On Sun, 17 Jan 2010 20:07, jhs@ wrote: Hi hackers I'm tired of my X server occasionaly freezing, swap thrasing, firefox dumps: 4,346,937,344 ~/firefox-bin.core so as a temporary cludge I ran touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core I could put X users in another group, reduce limits, per man login.conf ... RESOURCE LIMITS suggestions of values welcome. Yes 7.1 is old, thats my screen server, till I complete local builds of 7.2 8.0 on other boxes., then I'll upgrade, but I'll still want firefox though I see firefox is still troublesome eg uname -r # 8.0-RELEASE cd /usr/ports/www/firefox/Makefile ; make make# === firefox-2.0.0.20_9,1 is forbidden: too many security issues cd ../firefox3 ; make # is OK, runs on 8.0 i686, but on amd64 fails with GLib-WARNING **: g_set_prgname() called multiple times so I'm pausing for perspective, comment invited :-) Cheers, Julian Is it a possibility for you to add something like this to your ~/.login_conf me:\ :umask=027:\ :lang=C:\ :charset=en_US.ISO8859-1:\ :coredumpsize=0 Of course, adjust accordingly. Maybe you could just run it in a different class that you can setup globally in your login.conf as well so you do not have to turn off core dumps for your user entirely. At least you wont have the core dumps but this may not exactly be what you are looking for. Best of luck. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
what's Exception: t_mutex::lock failed in ports/net/twinkle/ ?
Colleagues, I have installed ports/net/twinkle/ v. 1.4.2 on 8.0-RELEASE. When started, it displays the Exception: t_mutex::lock failed messagebox and exits after pressing the OK button. What is this error? I really need a SIP softphone on a FreeBSD box. Google was not particularly helpful, actually, it only finds my own post to a Russian newsgroup on the same problem. If somebody wants to have a look, I am willing to provide a kdump. TIA for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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
