Re: JFS2 on freebsd
On 09-Sep-05, at 5:43 PM, Sergey Babkin wrote: From: Mike Silbersack [EMAIL PROTECTED] On Fri, 9 Sep 2005, Kamal R. Prasad wrote: would a port of JFS2 be of interest to freebsd core? thanks -kamal There are many things that would be of interest to FreeBSD users, but that's not a good reason to start a project. If you're motivated only because you think others desire your work, you'll probably give up when you have to start dealing with all the realities of the project. However, if you're motivated because *you* want to port JFS2, then you'll probably do a good job of it. I want to make a freebsd port of JFS2. The source code is available at http://jfs.sourceforge.net/ The reasons are academic and I have no reason to suggest that people stop using ufs. So, of course support for new filesystem support is good, but my personal opinion is that JFS2 isn't worth your time, for two reasons: a) Even if it's BSD licensed, it's unlikely to displace UFS as our default filesystem. The license is not a BSD license -and for those who are interested - it reads as follows:- -- /* * Copyright (c) International Business Machines Corp., 2000-2002 * Portions Copyright (c) Christoph Hellwig, 2001-2002 * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See * the GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -- b) It's not a widely used filesystem, so it doesn't really increase our interoperability with other OSes. I will make it a seperate module (which is how it exists in linux). It may not be appropriate to be used as a boot filesystem. If someone from freebsd is interested in reviewing the port -pl. let me know. thanks -kamal . OTOH, updating our ext2 code, or ntfs code (if that's even possible) would be something of use to many people, I suspect. Why not go for ext3 instead of JFS then? It has journaling in it. -SB Kamal R. Prasad UNIX systems consultant http://www.kamalprasad.com/ [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-5.4-stable panics
On 1 Oct, Don Lewis wrote:
On 30 Sep, John Baldwin wrote:
It turns out that the sysctl buffer is already wired in one of the two cases
that this function is called, so I moved the wiring up to the upper layer in
the other case and cut out a bunch of the locking gymnastics as a result.
Index: kern_proc.c
===
RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v
retrieving revision 1.231
diff -u -r1.231 kern_proc.c
--- kern_proc.c 27 Sep 2005 18:03:15 - 1.231
+++ kern_proc.c 30 Sep 2005 17:04:57 -
@@ -875,22 +875,16 @@
if (flags KERN_PROC_NOTHREADS) {
fill_kinfo_proc(p, kinfo_proc);
-PROC_UNLOCK(p);
error = SYSCTL_OUT(req, (caddr_t)kinfo_proc,
sizeof(kinfo_proc));
-PROC_LOCK(p);
} else {
-_PHOLD(p);
FOREACH_THREAD_IN_PROC(p, td) {
fill_kinfo_thread(td, kinfo_proc);
-PROC_UNLOCK(p);
error = SYSCTL_OUT(req, (caddr_t)kinfo_proc,
sizeof(kinfo_proc));
-PROC_LOCK(p);
if (error)
break;
}
-_PRELE(p);
}
PROC_UNLOCK(p);
if (error)
@@ -932,6 +926,9 @@
if (oid_number == KERN_PROC_PID) {
if (namelen != 1)
return (EINVAL);
+error = sysctl_wire_old_buffer(req, 0);
+if (error)
+return (error);
p = pfind((pid_t)name[0]);
if (!p)
return (ESRCH);
sched_lock needs to be grabbed before the FOREACH_THREAD_IN_PROC loop.
Can _PHOLD()/_PRELE() be dropped?
It turns out that fill_kinfo_thread() grabs a bunch of locks to grab
things out of struct proc, which breaks badly if sched_lock is grabbed
before calling fill_kinfo_thread().
I refactored fill_kinfo_thread() into two functions, one of which
doesn't need any additional locks and only gathers per-thread data, and
a new function, fill_kinfo_proc_only(), which gathers the data that is
common to all theads and can be called before grabbing sched_lock. This
should be more efficient if there is more than one thread because the
per-process data is only gathered once, and only the per-thread data in
kinfo_proc is overwritten for each thread.
Index: kern_proc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v
retrieving revision 1.231
diff -u -r1.231 kern_proc.c
--- kern_proc.c 27 Sep 2005 18:03:15 - 1.231
+++ kern_proc.c 2 Oct 2005 08:48:56 -
@@ -73,6 +73,8 @@
static void doenterpgrp(struct proc *, struct pgrp *);
static void orphanpg(struct pgrp *pg);
+static void fill_kinfo_proc_only(struct proc *p, struct kinfo_proc *kp);
+static void fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp);
static void pgadjustjobc(struct pgrp *pgrp, int entering);
static void pgdelete(struct pgrp *);
static int proc_ctor(void *mem, int size, void *arg, int flags);
@@ -596,33 +598,22 @@
}
}
#endif /* DDB */
-void
-fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp);
/*
- * Fill in a kinfo_proc structure for the specified process.
+ * Clear kinfo_proc and fill in any information that is common
+ * to all threads in the process.
* Must be called with the target process locked.
*/
-void
-fill_kinfo_proc(struct proc *p, struct kinfo_proc *kp)
-{
- fill_kinfo_thread(FIRST_THREAD_IN_PROC(p), kp);
-}
-
-void
-fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp)
+static void
+fill_kinfo_proc_only(struct proc *p, struct kinfo_proc *kp)
{
- struct proc *p;
struct thread *td0;
- struct ksegrp *kg;
struct tty *tp;
struct session *sp;
struct timeval tv;
struct ucred *cred;
struct sigacts *ps;
- p = td-td_proc;
-
bzero(kp, sizeof(*kp));
kp-ki_structsize = sizeof(*kp);
@@ -684,78 +675,14 @@
kp-ki_tsize = vm-vm_tsize;
kp-ki_dsize = vm-vm_dsize;
kp-ki_ssize = vm-vm_ssize;
- }
+ } else if (p-p_state == PRS_ZOMBIE)
+ kp-ki_stat = SZOMB;
kp-ki_sflag = p-p_sflag;
kp-ki_swtime = p-p_swtime;
kp-ki_pid = p-p_pid;
kp-ki_nice = p-p_nice;
bintime2timeval(p-p_rux.rux_runtime, tv);
kp-ki_runtime = tv.tv_sec * (u_int64_t)100 + tv.tv_usec;
- if (p-p_state != PRS_ZOMBIE) {
-#if 0
- if (td == NULL) {
- /* XXXKSE: This should never happen. */
- printf(fill_kinfo_proc(): pid %d has no threads!\n,
- p-p_pid);
- mtx_unlock_spin(sched_lock);
- return;
- }
serial port question
Hi, I need to set serial port to given parity/speed/etc. and then cat from it... when I: stty -f /dev/cuaa0 speed 1200 its still at 9600 (the default setting) how do I alter speed of serial port? minicom/cu is able to do it but I want to do it via stty. how can this be done? thnx for answer roman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serial port question
Divacky Roman writes: Hi, I need to set serial port to given parity/speed/etc. and then cat from it... when I: stty -f /dev/cuaa0 speed 1200 its still at 9600 (the default setting) how do I alter speed of serial port? minicom/cu is able to do it but I want t o do it via stty. how can this be done? See discussion of the initial-state and lock-state devices in the sio manual page. Another, hacky way to do it is like this: sleep 1000 /dev/cuaa0 stty -f /dev/cuaa0 speed 1200 The sleep holds the device open so that the values set using stty remain effective. Without the sleep the stty values are only effective while the command is being executed because stty opens the device and then, once stty exits, the device is closed and all the new settings are lost. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in propagate_priority w/ postgresql under heavy load
Robert Watson wrote: I can't speak to the problem with the core dumps, as it sounds like that is device/firmware related. However, I probably can lend a hand in debugging the problems you're seeing. I don't think the dump problem is device/firmware related, as a reboot -d gives me a dump just fine. Often, this means the actual panic or failure has not occurred in the thread that prints out the panic you see, but another panic. So the first task on hitting a propagate_priority() panic is to identify the thread that actually had the problem. Hmmm, so we have a very elusive problem here, one that is not easily pinpointed.. Somehow, this does not come as a surprise :) If you want to do this by e-mail so we can lend a hand, you probably want to hook up a serial console so you can copy and paste the debugging session. Compile DDB into the kernel (this should have no performance overhead), and when the system panics, you'll (ideally) get a db prompt. [excellent help in debugging deleted for brevity] Right, so perhaps i am missing something here, but this in my kernel config should do it (full config included below for completeness sake, as well as dmesg output): # debug options KDB options DDB # options KDB_TRACE # makeoptions DEBUG=-g # debug Furthermore, since reboot -d does dump to swap now (by limiting physical memory to just below the swap partition size in the bootloader config), i would expect to get a dump also when a panic occurs, and i would expect a ddb prompt. Alas, this is what i get: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc051c253 stack pointer = 0x10:0xe93efb3c frame pointer = 0x10:0xe93efb50 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 6092 (postgres) And that, that is all.. No ddb no 'dumping MB', just that. So basically, i fear this is a non-debugable problem, since putting in witness and such slows the kernel to a point where the panic does not occur anymore (at least, not in the 4 weeks i've been running the box with witness invariants). Clueless :) Best, Koen [ full kernel config: # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.13 2005/04/02 16:37:58 scottl Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident YIN-YANG # debug #options WITNESS #options INVARIANTS #optionsINVARIANT_SUPPORT options KDB options DDB # options KDB_TRACE # makeoptions DEBUG=-g # debug # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with
Importing bio aka RAID Management Framework from OpenBSD
Hi all, I proposed to import bio aka RAID Management Framework from OpenBSD. I have studied how bio is implemented in OpenBSD and here is a quick resume of the 3 components that make bio: - bio - ioctl tunnel pseudo-device /dev/bio.c biovar.h The bio driver provides userland applications ioctl access to devices otherwise not found as /dev nodes. The /dev/bio device node operates by delegating ioctl(2) calls to a requested device driver. Only drivers which have registered with the bio device can be accessed via this inter- face. - ciss, amr - supported device drivers - bioctl - RAID management interface RAID device drivers which support management functionality can register their services with the bio(4) driver. bioctl then can be used to main- tain RAID volumes. After analysing the structure of /src my initial idea was: new /src/sys/contrib/dev/bio/bio.c biovar.h new /src/sys/modules/bio/makefile new /src/contrib/bio/bioctl.c edit amr and ciss to register themselves on bio 1st: are these the correct places to be putting this files? 2nd: the drivers need to register to bio, this one being a kernel module. If bio is not compiled in that can represent a problem. Ideas? References: Theo De Raadt initial presentation of bio: http://marc.theaimsgroup.com/?l=openbsd-miscm=112630095818062 bio manpage: http://www.openbsd.org/cgi-bin/man.cgi?query=biosektion=4arch=i386apropos=0manpath=OpenBSD+Current bioctl manpage: http://www.openbsd.org/cgi-bin/man.cgi?query=bioctlsektion=8arch=i386apropos=0manpath=OpenBSD+Current -- Joao Barros ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4 AMD64 MPD
On Wed, Sep 28, 2005 at 04:00:08PM -0300, Daniel Dias Gon?alves wrote: D I installed MPD and it doesn't start, NETGRAPH is enable on kernel. mpd-3.18 doesn't work on AMD64. Future mpd-3.19 will work. However, the problem is already fixed in mpd port. You need to update your ports tree and resintall mpd. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How to troubleshoot solid freeze-up?
I'm looking for some tips on how to troubleshoot a possible driver problem. Here is the scenario: 1. Using a Pentium II 333Mhz mobile processor, 82443BX motherboard, and Intel i82559 NIC (fxp driver). 2. A combination of heavy disk I/O, high CPU utilization, and high network traffic causes a solid machine freeze-up sometime between 10 minutes and 3 hours of running. 3. Replacing the NIC with a DP83815-based card (sis driver) seems to solve the problem. I have run the problem load for up to 8 hours without issue on this NIC. 4. The problem is reproducable on multiple identical machines with multiple identical NICs. Also reproducable on an i82558 NIC integrated on the motherboard. How can I go about collecting useful information to troubleshoot this when the machine locks solid? How can a get a core under this scenario? Switching to another NIC permanently is not a great solution because this is a semi-embedded application and I need to use the NIC on the motherboard. Thanks, David Madole ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to troubleshoot solid freeze-up?
On Sun, Oct 02, 2005 at 03:59:50PM -0400, David S. Madole wrote: I'm looking for some tips on how to troubleshoot a possible driver problem. Here is the scenario: 1. Using a Pentium II 333Mhz mobile processor, 82443BX motherboard, and Intel i82559 NIC (fxp driver). 2. A combination of heavy disk I/O, high CPU utilization, and high network traffic causes a solid machine freeze-up sometime between 10 minutes and 3 hours of running. 3. Replacing the NIC with a DP83815-based card (sis driver) seems to solve the problem. I have run the problem load for up to 8 hours without issue on this NIC. 4. The problem is reproducable on multiple identical machines with multiple identical NICs. Also reproducable on an i82558 NIC integrated on the motherboard. How can I go about collecting useful information to troubleshoot this when the machine locks solid? How can a get a core under this scenario? Switching to another NIC permanently is not a great solution because this is a semi-embedded application and I need to use the NIC on the motherboard. You can't break to DDB in the usual way, right (Ctrl+alt+esc)? Try turning on KDB_STOP_NMI instead. Also try turning on WITNESS in case you're seeing a lock order reversal. Actually you forgot to mention what version of FreeBSD you're running, those suggestions only apply to 5.x and above. Kris pgpDdrmJrUf6t.pgp Description: PGP signature
Re: freebsd-5.4-stable panics
On 2 Oct, Don Lewis wrote: It turns out that fill_kinfo_thread() grabs a bunch of locks to grab things out of struct proc, which breaks badly if sched_lock is grabbed before calling fill_kinfo_thread(). I refactored fill_kinfo_thread() into two functions, one of which doesn't need any additional locks and only gathers per-thread data, and a new function, fill_kinfo_proc_only(), which gathers the data that is common to all theads and can be called before grabbing sched_lock. This should be more efficient if there is more than one thread because the per-process data is only gathered once, and only the per-thread data in kinfo_proc is overwritten for each thread. [ snip ] After fixing a few whitespace nits and one minor buglet, I commited my patch to HEAD, in kern_proc.c 1.232. I hope to be able to MFC it soon. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
