Re: valgrind on FreeBSD 7
Am Dienstag, 18. März 2008 06:44:23 schrieb Daniel O'Connor: > On Tue, 18 Mar 2008, Mike Silbersack wrote: > > Here's a tarball of what's in perforce right now. I tried it a > > little bit, and it seemed to work for me. Make sure to install the > > kernel module! > > > > http://www.silby.com/valgrind_freebsd_3.tar.gz > > > > But don't send me questions about it - I'm not an expert on it, I'm > > just the guy who grabbed it from perforce and found that it seems to > > work. :) > > Thanks for that (and to whomever is cutting the code)! > > Valgrind is an enormously helpful tool. Okay, so far valgrind on FreeBSD 7 isn't workable for me, simply because it doesn't yet support threading (missing syscall implementation, which causes the running program to bomb). Anyway, if there is anybody who's regularily cutting releases from the perforce tree, if you'd be so kind to give me a hint when a new release is available, I'd be more than grateful to give it a run! Thanks! -- Heiko Wundram ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
On Wednesday 19 March 2008 06:48:46 pm Matthew Dillon wrote: > :Matthew Dillon wrote: > :> :Matt, > :> > :>... > :> > :> :Don't you use something like VMWare for development and debugging? > :> > :> We use vkernel's for development and debugging. Pretty much > :> everything except hardware device driver development can be done using a > :> vkernel... > : > :Does that include trying to get rid of the BGL, for example? > > Yah, the SMP stuff works the same in a vkernel as it does in a real > kernel. If anything, the vkernel is even more sensitive to conflicts > since vkernel 'cpus' are threads on the real system and can wind up > being scheduled as time-share (for example, booting a 4-cpu vkernel > on a single-cpu platform). Except that you still need "real" hardware concurrency to see some races and that is important for testing. I'd worry about the overhead of any non-hardware assisted virtualization basically enforcing more serialization and coherency than is present in real-world systems meaning that code will work fine in the virtual environment and only break on real hardware. For example, when I worked on the rwlock implementation for FreeBSD 6/7, I wrote a custom kernel module that banged on the locks a lot and used KTR traces to verify that every single code path in the lock and unlock routines was exercised on a 4-way machine. I do think that vitualized environments can certainly be useful for many things (I used qemu for the recent GPT boot stuff and BTX changes and being able to single step in gdb for that was extremely useful and time-saving), but with concurrency races I think it is very important to make sure there is a lot of testing on full-speed, concurrent hardware. -- John Baldwin ___ 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)
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(×tamp);
+
+/* Generate a new config_id if none exists */
+if (!rdp->magic_0) {
+microtime(×tamp);
+ 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)
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 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Transferring ports
On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote:
> * Ivan Voras ([EMAIL PROTECTED]) wrote:
> > Is there a utility that would do that, and if not, does anyone have the
> > time to write one?
>
> Actually, I've already had an idea of utility with pretty similar
> functionality for a long time. The utility would copy directory
> hierarchies recursively based on file include/exclude list, like this:
>
> +/{etc,bin,sbin,lib}
> +/usr
> -/usr/local
> +/usr/local/{bin,sbin,libexec,share,lib}
> -/usr/share/locale
> +/usr/share/locale/ru_RU*
>
> so `my_cool_copy_utility / /path/to/jail` will copy /etc,/bin,/sbin,/lib
> and /usr dirs to jail, but in /usr/share/locale will only copy
> russian locales, but no others, and in usr/local it won't copy
> man, include and other dirs not needed in a jail.
>
> The purpose is similar - creating jails out of host system in fast
> and easy way, possibility to strip everything unneeded (useful for
> secure minimal jails or flash/livecd/embedded installations of
> minimal size) and add something extra, like stuff from /usr/local
> without installing full packages in a jail, or, say, copying over
> additional tree of jail-specific changes (mostly stuff under /etc
> and /usr/local/etc).
>
> Such an utility is something I still might start working on.
Err... why not use rsync for that? It works locally, too -
I use it to copy directories all over the place all the time.
Come to think of it... oh, just go install net/rsync, take a look at
its manual page and the "FILTER RULES" section in particular - it even
supports rules with prefixes, "-" for exclude, "+" for include, just
like you want them :) Well, okay, you might need to list separate
directories on separate lines (it doesn't seem to support the {bin,sbin}
syntax), but other than that, it seems to fit your requirements pretty
well :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence claims to be an Epimenides paradox, but it is lying.
pgpHVw3fpalLG.pgp
Description: PGP signature
Re: vkernel & GSoC, some questions
:Except that you still need "real" hardware concurrency to see some races and :that is important for testing. I'd worry about the overhead of any :non-hardware assisted virtualization basically enforcing more serialization :and coherency than is present in real-world systems meaning that code will :work fine in the virtual environment and only break on real hardware. For :example, when I worked on the rwlock implementation for FreeBSD 6/7, I wrote :a custom kernel module that banged on the locks a lot and used KTR traces to :verify that every single code path in the lock and unlock routines was :exercised on a 4-way machine. : :I do think that vitualized environments can certainly be useful for many :things (I used qemu for the recent GPT boot stuff and BTX changes and being :able to single step in gdb for that was extremely useful and time-saving), :but with concurrency races I think it is very important to make sure there is :a lot of testing on full-speed, concurrent hardware. : :-- :John Baldwin Hardware and vkernel/qemu environments exercise different code paths and different timing mechanics. Certain bugs show up on vkernel's more readily then on real hardware, while other bugs show up more readily on real hardware then on vkernel's. I don't think one is particularly better then another with regards to testing, they just cover different continuums. -Matt Matthew Dillon <[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: Transferring ports
On 20/03/2008, Doug Poland <[EMAIL PROTECTED]> wrote: > Peter Pentchev wrote: > > On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote: > >> * Ivan Voras ([EMAIL PROTECTED]) wrote: > >>> Is there a utility that would do that, and if not, does anyone have the > >>> time to write one? > >> > > Would this not be an appropriate use for packages? If one creates a > package for every installed port on the "host" system, then one simply > installs the package on the target system. Yes, that's exactly what I need (the same functionality as "pkg_create -b" + install on the other system), only without the actual package file being created. Pipes would also be acceptable (piping the output of pkg_create from one machine to the other, etc). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Transferring ports
Peter Pentchev wrote: On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote: * Ivan Voras ([EMAIL PROTECTED]) wrote: Is there a utility that would do that, and if not, does anyone have the time to write one? >> Would this not be an appropriate use for packages? If one creates a package for every installed port on the "host" system, then one simply installs the package on the target system. I have used this technique with some success when "transferring" ports from one system to another. In my situation, I'm using the same architecture (i386) and OS version (6.3 --> 6.3 or 7.0 --> 7.0). -- Regards, Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Transferring ports
Peter Pentchev wrote: On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote: The purpose is similar - creating jails out of host system in fast and easy way, possibility to strip everything unneeded (useful for secure minimal jails or flash/livecd/embedded installations of minimal size) and add something extra, like stuff from /usr/local without installing full packages in a jail, or, say, copying over additional tree of jail-specific changes (mostly stuff under /etc and /usr/local/etc). Such an utility is something I still might start working on. I don't use the host system.. I keep a special pristine jail just for that purpose (to act as a source for other jails). sometimes I also use null=mounts, and sometimes if the jails are on one big partition, I hardlink some stuff.. e.g binaries in /bin etc betweem teh jails.. saves memory and disk.. Of course that is only when I basically trust the jail user (me). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Linux version of libusb that works with FreeBSD
There was a thread on this subject a couple of months ago: a working libusb in /compat/linux. Has anybody tried to make this work? There is a linux binary application I want to run and a photo film scanner that it uses via libusb directly (not sane backend)... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fpathconf() and extended attributes
Hi, I am trying to detect whether it is possible to set extended attributes on a file/fd. Now, fpathconf() seems like it could be the right thing but pathconf(2) doesn't mention extended attributes at all and neither does statfs(2). Is there any other way how to detect extended attributes availability? -- VH signature.asc Description: OpenPGP digital signature
Re: Transferring ports
Ivan Voras wrote: On 20/03/2008, Doug Poland <[EMAIL PROTECTED]> wrote: Peter Pentchev wrote: > On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote: >> * Ivan Voras ([EMAIL PROTECTED]) wrote: >>> Is there a utility that would do that, and if not, does anyone have the >>> time to write one? >> Would this not be an appropriate use for packages? If one creates a package for every installed port on the "host" system, then one simply installs the package on the target system. Yes, that's exactly what I need (the same functionality as "pkg_create -b" + install on the other system), only without the actual package file being created. Pipes would also be acceptable (piping the output of pkg_create from one machine to the other, etc). > Too bad you cannot accept the package file. If pkg_create would accept a - instead of specifying the output tarball, then one could do some foo with nc, i.e., target# nc -l 1234 | tar -xf - source# pkg_create -b mypackage - | nc target 1234 -- Regards, Doug ___ 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)
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]"
Re: Re: vkernel & GSoC, some questions
>From: Matthew Dillon >To: John Baldwin <[EMAIL PROTECTED]> >:Except that you still need "real" hardware concurrency to see some races and >:that is important for testing. I'd worry about the overhead of any > >Hardware and vkernel/qemu environments exercise different code paths >and different timing mechanics. Certain bugs show up on vkernel's >more readily then on real hardware, while other bugs show up more >readily on real hardware then on vkernel's. I don't think one is When testing multi-threaded code I sometimes insert artificial delays at different strategic locations. This widens any present race windows and makes the related bugs show up every time instead of once in a while. Of course, the resulting code works slower during the tests too :-) -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: remote operation or admin
On Wed, Mar 19, 2008 at 03:10:12PM -0400, Chuck Robey wrote: >it might be possible to find some way to extend the work domain of an smp >system to stretch across machine lines, to jump across motherboards. Maybe >not to be global (huge latencies scare me away), but what about just going >3 feet, on a very high speed bus, like maybe a private pci bus? Not what >is, what could be? This is definitely possible. DEC built a memory channel adapter which allowed multiple AlphaServers to share (part of) each other's RAM. You could also try looking at Amoeba - it is a cross between a "traditional" SMP system and a cluster. There's probably no reason why you couldn't build a kernel module to "share" RAM between hosts using Ethernet or similar - though it would be much slower than accessing local RAM. >small, but with a bunch of bandwidth. So, in that case, what really are >the differences between smp and clustering, besides the raw current size of >the implementation? Are there huge basic differences between the >clustering concept and by smp's actual tasks? The access time differences between local and remote RAM mean that there are different trade-offs: Memory coherence is extremely expensive so more effort is expended in avoiding operations that require coherence. In general tasks that work well in a clustered environment have very low inter-process communication requirements. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpYKpCyNy1aN.pgp Description: PGP signature
