Re: Running a program through gdb without interfering

2009-10-09 Thread Stef Walter
Mel Flynn wrote:
 [1] In order to get this working I had to put a statically compiled ps in the 
 jail

This is a pretty standard practice. I always put these statically built
into any jails that don't match the outside system. I use the following
crunchgen config to accomplish that.

Cheers,

Stef



# Commands to build in
progs ps ipcs netstat pkill top w killall
progs systat iostat
progs jkill
progs kldstat

# Link these programs to each other
ln pkill pgrep
ln w uptime

# Libraries which we need
libs -lutil -lkvm -ldevstat -lncurses -ldevstat -lm -lnetgraph -lmemstat
-lipx
___
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


Is the FreeBSD ABI compatibility policy documented anywhere

2009-09-24 Thread Stef Walter
It seems that FreeBSD has an ABI compatibility policy where major
versions remain ABI and API compatible throughout minor point versions.
That is to say that the kernel interfaces and libraries for (eg)
7-STABLE, 7.1-RELEASE, 7.2-RELEASE are not supposed to change.

Is this a policy of the project? If so, is it documented anywhere? Or is
it just a convention?

Cheers,

Stef

___
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: kvm on amd64 - 6G?

2008-08-30 Thread Stef
Barry Boes wrote:
 I could apply such a patch to my servers, but there are two disadvantages :
   o who wants to apply kernel patches to mission critical servers? Isn't
  that a linux thing (joke!) 

Unfortunately it's not. There's a whole raft of patches (with PR's
filed) that are required when you're using certain configurations of
FreeBSD.

In particular my 6.3 production servers require:

 * A bunch of patches to ataraid to prevent panics, make the
   raid work during failures etc... Many can be found here:

   http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting


 * Patch to the 4BSD scheduler to prevent regular deadlocks on all
   quad core systems I have access to:

   http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg64390.html


 * Patch for fixing devfs to have proper behavior with symlinks
   in jails:

   http://www.freebsd.org/cgi/query-pr.cgi?pr=114057


And there are one or two other patches on some deployed systems (eg:
'multi ip jail patches'). I used to be in the
no-patches-on-my-production-servers camp, but I've found that it was
unrealistic and resulted in less stable systems.


Cheers,

Stef Walter

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 6.3 deadlock (vm_map?) with DDB output

2008-06-30 Thread Stef
John Baldwin wrote:
 On Sunday 15 June 2008 07:23:19 am Stef Walter wrote:
 I've been trying to track down a deadlock on some newish production
 servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a
 specific (although mundane) hardware configuration, and each of several
 servers running this hardware deadlock about once per week.
 
 Try this change:
 
snip
 We use it at work on 6.x.  W/o this fix, round-robin stops working on 4BSD 
 when softclock() (swi4: clock) blocks on a lock like Giant.

Just wanted to confirm: That patch did the trick. All the SMP machines
that had this problem have been stable for 11 days now, longer than any
of them were up previously.

I changed the patch slightly to work with FreeBSD 6.3-RELEASE. That's
attached, in case anyone needs this later.

Cheers,
Stef
--- sys/kern/sched_4bsd.c.orig	2006-06-16 22:11:55.0 +
+++ sys/kern/sched_4bsd.c	2008-06-18 17:04:34.0 +
@@ -157,13 +157,10 @@
 static int	sched_quantum;	/* Roundrobin scheduling quantum in ticks. */
 #define	SCHED_QUANTUM	(hz / 10)	/* Default sched quantum */
 
-static struct callout roundrobin_callout;
-
 static void	slot_fill(struct ksegrp *kg);
 static struct kse *sched_choose(void);		/* XXX Should be thread * */
 
 static void	setup_runqs(void);
-static void	roundrobin(void *arg);
 static void	schedcpu(void);
 static void	schedcpu_thread(void);
 static void	sched_priority(struct thread *td, u_char prio);
@@ -316,27 +313,6 @@
 }
 
 /*
- * Force switch among equal priority processes every 100ms.
- * We don't actually need to force a context switch of the current process.
- * The act of firing the event triggers a context switch to softclock() and
- * then switching back out again which is equivalent to a preemption, thus
- * no further work is needed on the local CPU.
- */
-/* ARGSUSED */
-static void
-roundrobin(void *arg)
-{
-
-#ifdef SMP
-	mtx_lock_spin(sched_lock);
-	forward_roundrobin();
-	mtx_unlock_spin(sched_lock);
-#endif
-
-	callout_reset(roundrobin_callout, sched_quantum, roundrobin, NULL);
-}
-
-/*
  * Constants for digital decay and forget:
  *	90% of (kg_estcpu) usage in 5 * loadav time
  *	95% of (ke_pctcpu) usage in 60 seconds (load insensitive)
@@ -618,11 +594,6 @@
 		sched_quantum = SCHED_QUANTUM;
 	hogticks = 2 * sched_quantum;
 
-	callout_init(roundrobin_callout, CALLOUT_MPSAFE);
-
-	/* Kick off timeout driven events by calling first time. */
-	roundrobin(NULL);
-
 	/* Account for thread0. */
 	sched_load_add();
 }
@@ -697,6 +668,14 @@
 		resetpriority(kg);
 		resetpriority_thread(td, kg);
 	}
+
+	/*
+	 * Force a context switch if the current thread has used up a full
+	 * quantum (default quantum is 100ms).
+	 */
+	if (!((td)-td_flags  TDF_IDLETD) 
+	ticks - PCPU_GET(switchticks) = sched_quantum)
+		td-td_flags |= TDF_NEEDRESCHED;
 }
 
 /*
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD 6.3 deadlock (vm_map?) with DDB output

2008-06-18 Thread Stef
John Baldwin wrote:
 Try this change:
 
 jhb 2007-10-27 22:07:40 UTC

snip

 We use it at work on 6.x.  W/o this fix, round-robin stops working on 4BSD 
 when softclock() (swi4: clock) blocks on a lock like Giant.

Awesome. Thanks. That looks like it'll do the trick. I'll deploy it and
keep the list posted.

Stef

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 6.3 deadlock (interrupted pmap_remove_pages) with DDB output

2008-06-16 Thread Stef Walter
Stef Walter wrote:
 I've been trying to track down a deadlock on some newish production
 servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a
 specific (although mundane) hardware configuration, and each of several
 servers running this hardware deadlock about once per week.
 
 Although I suspect that this is not hardware related, from a (naive)
 perusal of the attached stack traces.

Here's another similar deadlock that occurred on an similar machine.
Last time pmap_enter was preempted by an interrupt, this time
pmap_remove_pages was preempted by a timer.

I tried changing machdep.cpu_idle_hlt to zero, based on a hint [1], but
that didn't seem to make a difference.

Again in this case the processes are waiting on the page queue mutex:
 python (in trap  trap_pfault  vm_fault)
 rsync (in ... cluster_read  getblk  getnewbuf  vfs_vmio_release)

And another rsync process is holding the vm page queue mutex:
 rsync (in exit1  vmspace_exit  pmap_remove_pages)

The rsync process in pmap_remove_pages was interrupted by a timer while
holding the vm page queue lock and then was not scheduled again.

Kernel config and full details attched.

I may try building the kernel without PREEMPTION to see if it fixes this
problem.

Again, any and all advice or hints are welcome. I really appreciate any
time spent on this.

Stef Walter

[1]
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-02/0508.html
#
# RACK1
#

machine i386
cpu I686_CPU
ident   RACK1

# To statically compile in device wiring instead of /boot/device.hints
#hints  GENERIC.hints # Default places to look for devices.

makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols

options SCHED_4BSD  # 4BSD scheduler
options PREEMPTION  # Enable kernel thread preemption
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 FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
options KTRACE  # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time 
extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options ADAPTIVE_GIANT  # Giant mutex is adaptive.

device  apic# I/O APIC

options SMP

options QUOTA
options FAST_IPSEC
options IPFIREWALL
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_VERBOSE
options IPFIREWALL_FORWARD
options IPDIVERT
options DUMMYNET

options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ


options KDB
options KDB_TRACE
options KDB_UNATTENDED
options DDB
options INVARIANTS
options INVARIANT_SUPPORT
options WITNESS
options WITNESS_SKIPSPIN
options DIAGNOSTIC
options BREAK_TO_DEBUGGER
options DEBUG_LOCKS
options DEBUG_VFS_LOCKS


device  crypto

# Bus support.
device  eisa
device  pci

# Floppy drives
device  fdc

# ATA and ATAPI devices
device  ata
device  atadisk # ATA disk drives
device  ataraid # ATA RAID drives
device  atapicd # ATAPI CDROM drives
#device atapifd # ATAPI floppy drives
#device atapist # ATAPI tape drives
options ATA_STATIC_ID   # Static device numbering

# SCSI Controllers
#device ahb # EISA AHA1742 family
#device ahc

Re: RAID status issues with Intel MatrixRAID ataraid

2008-05-31 Thread Stef Walter
John Baldwin wrote:
 Physical Disks:
 Port Drive Model  Serial #  Size Type/Status(Vol ID)
 0WDC WD5000ABYS-0 WD-WCAPW5637184   465.8GB  Member Disk(0)
 1ST3500320NS  5QM09E6F  465.8GB  Error Occurred(0)
 2WDC WD5000ABYS-0 WD-WCAPW5548822   465.8GB  Member Disk(1)
 3ST3500320NS  5QM0991D  465.8GB  Member Disk(1)
 Press CTRL-I to enter Configuration Utility...



 RELEVANT SNIPPET FROM DMESG:

 ar0: 476937MB Intel MatrixRAID RAID1 status: READY
 ar0: disk0 READY (master) using ad4 at ata2-master
 ar0: disk1 READY (mirror) using ad6 at ata3-master
 
 Err, you have two RAID volumes, one degraded, and one ok.  ar0 is apparently 
 the one that is ok (drives 2 and 3).  What is more odd is that it isn't 
 seeing a RAID config at all for ad0 and ad2 (drives 0 and 1).

Nope, ar1 (with ad8 and ad10) is the second RAID, both are marked as
READY even though one is degraded in the BIOS.

ar0: 476937MB Intel MatrixRAID RAID1 status: READY
ar0: disk0 READY (master) using ad4 at ata2-master
ar0: disk1 READY (mirror) using ad6 at ata3-master
ar1: 476937MB Intel MatrixRAID RAID1 status: READY
ar1: disk0 READY (master) using ad8 at ata4-master
ar1: disk1 READY (mirror) using ad10 at ata5-master

In any case, this is water under the bridge for me now.

Cheers,
Stef Walter

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


RAID status issues with Intel MatrixRAID ataraid

2008-05-30 Thread Stef Walter
This isn't a bug report, just a heads up to anyone using the same setup.
This occurred in production, and I don't currently have a non-production
hardware on which to investigate this bug and/or create a patch.

In certain conditions, even though the Firmware RAID BIOS, says that a
RAID is degraded, the FreeBSD driver thinks it's business as usual. In
my case this resulted in file system corruption. Relevant output below.

FreeBSD version: 6.3-RELEASE-p2

Cheers,
Stef Walter



BIOS OUTPUT:

Copyright(C) 2003-06 Intel Corporation.  All Rights Reserved.

RAID Volumes:
ID   NameLevel  Strip  Size StatusBootable
0RAID Set 1  RAID1(Mirror)  N/A465.8GB  Degraded  Yes
1RAID1(Mirror)  N/A465.8GB  NormalYes

Physical Disks:
Port Drive Model  Serial #  Size Type/Status(Vol ID)
0WDC WD5000ABYS-0 WD-WCAPW5637184   465.8GB  Member Disk(0)
1ST3500320NS  5QM09E6F  465.8GB  Error Occurred(0)
2WDC WD5000ABYS-0 WD-WCAPW5548822   465.8GB  Member Disk(1)
3ST3500320NS  5QM0991D  465.8GB  Member Disk(1)
Press CTRL-I to enter Configuration Utility...



RELEVANT SNIPPET FROM DMESG:

ar0: 476937MB Intel MatrixRAID RAID1 status: READY
ar0: disk0 READY (master) using ad4 at ata2-master
ar0: disk1 READY (mirror) using ad6 at ata3-master

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: RAID status issues with Intel MatrixRAID ataraid

2008-05-30 Thread Stef Walter
Jeremy Chadwick wrote:
 In certain conditions, even though the Firmware RAID BIOS, says that a
 RAID is degraded, the FreeBSD driver thinks it's business as usual. In
 my case this resulted in file system corruption. Relevant output below.
 
 See the ATA (SATA, PATA, ATAPI) section, specifically the Intel
 MatrixRAID items:
 
 http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues

Yes, I reported several of those as well as provided patches for them.
That was back when I had relevant hardware in my lab.

Cheers,
Stef Walter

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Vital Patches for ataraid with Intel Matrix RAID (ICH7)

2008-03-21 Thread Stef Walter
Daniel O'Connor wrote:
 I have seen this bug in other ATA RAID implementations (VIA  Promise) 
 too. From what I can tell this part of your patch is general to all ATA 
 RAID arrays, right?

Yes, a small part. The part that will write out the RAID information
(thus updating the generation) whenever the status changes, regardless
of whether that change takes place when the machine is off or not.

Without testing, I can't be sure whether this solves the problem on
other ataraid devices.

Cheers,
Stef Walter

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Vital Patches for ataraid with Intel Matrix RAID (ICH7)

2008-03-20 Thread Stef Walter
Here's some vital patches for the ataraid driver when using Intel Matrix
RAID (often found built into mainboards these days).

These are problems that will bite at the worst time: When a disk goes
out in your RAID.

A combined patch is attached which applies to FreeBSD 6 and 7, and the
various specific problem reports and issues are outlined below.

Cheers,

Stef Walter



Fix an early boot panic if you reboot with all drives present when your
RAID is marked DEGRADED. This can happen if a drive has an unreadable
block and the drive gets detached from the RAID. Rebooting at this point
will panic. Yoichi created a patch for this over a year ago.

http://www.freebsd.org/cgi/query-pr.cgi?pr=102211


Don't duplicate the RAID amoeba style if you boot with a drive present
that was detached from a RAID. This can happen if you manage to get past
the above panic problem. You'll end up with two devices like ar0 and
ar1. This can be a major mess if ar1 was already contained active file
systems.

http://www.freebsd.org/cgi/query-pr.cgi?pr=121899


If you reboot after adding a spare, or during the rebuilding process,
the RAID will become magically READY by itself. Not cool.

http://www.freebsd.org/cgi/query-pr.cgi?pr=102210


--- sys/dev/ata/ata-raid.c.orig	2008-03-19 11:20:15.0 +
+++ sys/dev/ata/ata-raid.c	2008-03-19 21:53:37.0 +
@@ -848,10 +848,17 @@
 	rdp-status = ~AR_S_READY;
 }
 
+/* 
+ * Note that when the array breaks so comes up broken we 
+ * force a write of the array config to the remaining 
+ * drives so that the generation will be incremented past 
+ * those of the missing or failed drives (in all cases).
+ */
 if (rdp-status != status) {
 	if (!(rdp-status  AR_S_READY)) {
 	printf(ar%d: FAILURE - %s array broken\n,
 		   rdp-lun, ata_raid_type(rdp));
+writeback = 1;
 	}
 	else if (rdp-status  AR_S_DEGRADED) {
 	if (rdp-type  (AR_T_RAID1 | AR_T_RAID01))
@@ -860,6 +867,7 @@
 		printf(ar%d: WARNING - parity, rdp-lun);
 	printf( protection lost. %s array in DEGRADED mode\n,
 		   ata_raid_type(rdp));
+writeback = 1;
 	}
 }
 mtx_unlock(rdp-lock);
@@ -2157,22 +2165,23 @@
 
 	/* clear out any old info */
 	for (disk = 0; disk  raid-total_disks; disk++) {
+		u_int32_t disk_idx = map-disk_idx[disk]  0x;
 		raid-disks[disk].dev = NULL;
-		bcopy(meta-disk[map-disk_idx[disk]].serial,
+		bcopy(meta-disk[disk_idx].serial,
 		  raid-disks[disk].serial,
 		  sizeof(raid-disks[disk].serial));
 		raid-disks[disk].sectors =
-		meta-disk[map-disk_idx[disk]].sectors;
+		meta-disk[disk_idx].sectors;
 		raid-disks[disk].flags = 0;
-		if (meta-disk[map-disk_idx[disk]].flags  INTEL_F_ONLINE)
+		if (meta-disk[disk_idx].flags  INTEL_F_ONLINE)
 		raid-disks[disk].flags |= AR_DF_ONLINE;
-		if (meta-disk[map-disk_idx[disk]].flags  INTEL_F_ASSIGNED)
+		if (meta-disk[disk_idx].flags  INTEL_F_ASSIGNED)
 		raid-disks[disk].flags |= AR_DF_ASSIGNED;
-		if (meta-disk[map-disk_idx[disk]].flags  INTEL_F_SPARE) {
-		raid-disks[disk].flags = ~(AR_DF_ONLINE | AR_DF_ASSIGNED);
-		raid-disks[disk].flags |= AR_DF_SPARE;
+		if (meta-disk[disk_idx].flags  INTEL_F_SPARE) {
+		raid-disks[disk].flags = ~AR_DF_ONLINE;
+		raid-disks[disk].flags |= (AR_DF_SPARE | AR_DF_ASSIGNED);
 		}
-		if (meta-disk[map-disk_idx[disk]].flags  INTEL_F_DOWN)
+		if (meta-disk[disk_idx].flags  INTEL_F_DOWN)
 		raid-disks[disk].flags = ~AR_DF_ONLINE;
 	}
 	}
@@ -2183,7 +2192,7 @@
 		if (!strncmp(raid-disks[disk].serial, atadev-param.serial,
 		sizeof(raid-disks[disk].serial))) {
 		raid-disks[disk].dev = parent;
-		raid-disks[disk].flags |= (AR_DF_PRESENT | AR_DF_ONLINE);
+		raid-disks[disk].flags |= AR_DF_PRESENT;
 		ars-raid[raid-volume] = raid;
 		ars-disk_number[raid-volume] = disk;
 		retval = 1;
@@ -2233,11 +2242,16 @@
 }
 
 rdp-generation++;
-microtime(timestamp);
+
+/* Generate a new config_id if none exists */
+if (!rdp-magic_0) {
+microtime(timestamp);
+	rdp-magic_0 = timestamp.tv_sec ^ timestamp.tv_usec;
+} 
 
 bcopy(INTEL_MAGIC, meta-intel_id, sizeof(meta-intel_id));
 bcopy(INTEL_VERSION_1100, meta-version, sizeof(meta-version));
-meta-config_id = timestamp.tv_sec;
+meta-config_id = rdp-magic_0;
 meta-generation = rdp-generation;
 meta-total_disks = rdp-total_disks;
 meta-total_volumes = 1;/* XXX SOS */
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Vital Patches for ataraid with Intel Matrix RAID (ICH7)

2008-03-20 Thread Stef Walter
Nice list.

All the fixes I made were Intel MatrixRAID specific. It should fix the
following issue on your list, as well as others not listed.


Intel MatrixRAID incompatibilities
 * Symptom: When using a MatrixRAID-managed RAID1 array, one can crash
the kernel when a disk is lost then later reattached
 Open PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108924


FWIW, kern/108924 seems to be a duplicate of kern/102211

Cheers,
Stef Walter

Jeremy Chadwick wrote:
 On Thu, Mar 20, 2008 at 01:16:39PM +, Stef Walter wrote:
 Here's some vital patches for the ataraid driver when using Intel Matrix
 RAID (often found built into mainboards these days).
 
 Will this address any of the MatrixRAID and/or ATA issues documented
 here?
 
 http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues
 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


devfs symlink over device doesn't work

2007-06-26 Thread Stef Walter
After deleting a device in devfs, any symlink placed over it results in
ENOENT.

  # cd /dev
  # rm console
  # touch /var/log/console
  # ln -s /var/log/console console
  # ls -l console
  ls: console: No such file or directory

I'd like to fix this behavior. Or is there a reason for it that I'm not
seeing?

Reasoning:

I'm using devfs in jails, and I'd like anything written (by user space
programs, syslogd, etc...) to /dev/console to go to a file in the jail.
So at jail startup I'd like to put a symlink over /dev/console to a
normal file.

Cheers,
Stef Walter

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]