devd question
I'm trying to make devd run an stty command whenever a USB serial device
is attached. Unfortunately, $device-name is ucom[0-9] and the device
names are /dev/cuaU[0-9] - how do I get the correct name in the device
action? I haven't found a way to extract the number by itself, so I'm
stuck with specifying a separate rule for each number, like so:
attach 100 {
device-name "ucom0";
action "stty -f /dev/cuaU0.init raw";
};
Help would be much appreciated!
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS root File System
Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. Aharon Friedman wrote: (note the fact that / can not be easily rolled back to previous state using ZFS's snapshot feature, and can not be easily switched between clones I actually keep a full minimal install on my UFS /bootdisk slice (which i use geom mirror for) and then symlink /bootdisk/boot to /boot on the ZFS /. This way should I ever need to rollback ZFS / I can quickly change the vfs.root.mountfrom to /dev/mirror/gm0 and then have a base system living entirely on UFS. If you do it that way you can easily rollback your ZFS / should you need to and then just reboot back to the ZFS / when you're done. Cheers, Dillon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: devd question
On Sat, Feb 28, 2009 at 02:13:10PM +0100, Michael Sperber wrote:
>
> I'm trying to make devd run an stty command whenever a USB serial device
> is attached. Unfortunately, $device-name is ucom[0-9] and the device
> names are /dev/cuaU[0-9] - how do I get the correct name in the device
> action? I haven't found a way to extract the number by itself, so I'm
> stuck with specifying a separate rule for each number, like so:
>
> attach 100 {
> device-name "ucom0";
> action "stty -f /dev/cuaU0.init raw";
> };
>
> Help would be much appreciated!
There are some other notifications that are send through devctl when
cdev is created. They have system set to DEVFS, subsystem to CDEV,
and type CREATE. The data is the /dev node name. I am not sure how
to assign the action in the devd.
pgpRadFRWrEez.pgp
Description: PGP signature
Re: Question about disk schedulers
On Sat, Feb 28, 2009 at 01:47:07AM -0500, Yoshihiro Ota wrote: > Hi, Luigi and Fabio: > > I have a question about the GEOM disk scheduler you announed a while ago. > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047597.html > > Can you tell me how does the scheduler interact with gjournal? > Do you expect to improve response time even if used together with gjounral > or to interfere each other? > > As I only had a journaled partition available for an experiment, I tried > this combination on 7.1-RELEASE but it paniced 4 times out of 5 at attempts > as soon as I mounted. Hi, a possible problem is that the scheduler uses the bio_caller1 field in the topmost request to store classification info -- there is no place to store the info in a standard 'bio' and changing the structure is rather intrusive. I see that gjournal.h has this comment: /* * Use bio_caller1 field as a pointer in queue. */ #define bio_nextbio_caller1 so if gjournal is the top layer in the hierarchy there might be a conflict. Apart from adding a specific field to the struct bio (in the long term this is the way to go) perhaps one could try and add a gnop class on top of gjournal, so that would free the bio_caller1 in the topmost bio and prevent the panic. But thanks for the report, we will keep this in mind and in the next release (which should happen in a week or so) we will also add a patch or suggestion for handling this problem cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS root File System
On Fri, Feb 27, 2009 at 07:21:15PM -0800, Matthew Dillon wrote: > My experience with one of our people trying to do the same thing > w/ HAMMER... we got it working, but it is not necessarily cleaner. > > I'd rather just boot from a small UFS /boot partition on 'a' (256M > or 512M), followed by swap on 'b', followed by the big-ass root > partition on 'd' using your favorite filesystem. For those who want resilience, on FreeBSD you could also make that boot partition mirrored across drives with gmirror. -- Clifton -- Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
vm_thread_new: kstack allocation failed with vm.kmem_size="1536M"
So, I have a farm of machines runnign 7.1/amd64, all of which have 16 gig of memory in them. This afternoon, as an experiment, I altered loader.conf to have these two lines in it: vm.kmem_size="1536M" vm.kmem_size_max="1536M" This is what I do on machines running ZFS - these machines are not, however running ZFS, and do not have the zfs module loaded. I just wanted to see if they would run OK with those kernel settings (as I may put ZFS on them in the future) I expected it to run fine, I just wanted to make sure. But after about an hour I started getting the message in the subject line, and the machines were unable to fork and needed to be reset. Explanation anyone ? This makes no sense to me - I have actually expanded the amount of memory available, so why is it now running out of stack space ?! The machines are running a very simple setup of apache, mysql and tomcat - and this runs fine with the kernel variables set as default. I am very puzzled. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: vm_thread_new: kstack allocation failed with vm.kmem_size="1536M"
In the last episode (Feb 28), Pete French said: > So, I have a farm of machines runnign 7.1/amd64, all of which have 16 gig > of memory in them. This afternoon, as an experiment, I altered > loader.conf to have these two lines in it: > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > > This is what I do on machines running ZFS - these machines are not, > however running ZFS, and do not have the zfs module loaded. I just wanted > to see if they would run OK with those kernel settings (as I may put ZFS > on them in the future) You've probably reduced kmem_size from the default. I don't set anything on my 6 GB amd64 system, and I get: $ sysctl vm.kmem_size vm.kmem_size_max vm.kmem_size: 2061496320 vm.kmem_size_max: 3865468109 I assume your 16GB system would default to even larger numbers. What values do you get without forcing anything in loader.conf? -- Dan Nelson dnel...@allantgroup.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: vm_thread_new: kstack allocation failed with vm.kmem_size="1536M"
> You've probably reduced kmem_size from the default. I don't set anything on > my 6 GB amd64 system, and I get: > > $ sysctl vm.kmem_size vm.kmem_size_max > vm.kmem_size: 2061496320 > vm.kmem_size_max: 3865468109 > > I assume your 16GB system would default to even larger numbers. What values > do you get without forcing anything in loader.conf? Nope, I get 419430400 (i.e. 400M) on all the machines without anything in loader.conf - what version of FreeBSD are you running to get those numbers ? I thought that 1536M was the absolute maximum for kmem in versions of FreeBSD before 8-CURRENT. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: vm_thread_new: kstack allocation failed with vm.kmem_size="1536M"
In the last episode (Mar 01), Pete French said: > > You've probably reduced kmem_size from the default. I don't set > > anything on my 6 GB amd64 system, and I get: > > > > $ sysctl vm.kmem_size vm.kmem_size_max > > vm.kmem_size: 2061496320 > > vm.kmem_size_max: 3865468109 > > > > I assume your 16GB system would default to even larger numbers. What > > values do you get without forcing anything in loader.conf? > > Nope, I get 419430400 (i.e. 400M) on all the machines without anything > in loader.conf - what version of FreeBSD are you running to get those > numbers ? I thought that 1536M was the absolute maximum for kmem > in versions of FreeBSD before 8-CURRENT. I'm running 7-STABLE as of Feb 26 or so. Commit r187466 on Jan 20 bumped up kmem_size_max on amd64 to 3.6GB: http://svn.freebsd.org/viewvc/base?view=revision&revision=187466 -- Dan Nelson dnel...@allantgroup.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.1 new install halts on BTX error
On Wed, 25 Feb 2009, Gavin Atkinson wrote: > On Thu, 2009-01-29 at 12:13 +0900, David Adam wrote: > > I upgraded my 7.0 system to 7.1-RELEASE with freebsd-update only to find > > that it no longer boots correctly, instead crashing with a BTX backtrace. > > If I break to the loader prompt and use 'ls /boot', I also get a > > backtrace. > > > > A new install of 7.1 on this hardware using a separate SCSI card and drive > > array also leads to a BTX backtrace. I have copied this below as the first > > (most repeatable) error and also included the other problems. > > > > A fresh install of 7.0 works fine. FreeSBIE 1.0, based on FreeBSD 5.3, > > also boots fine and will happily list the contents of the original drive's > > /boot in the loader, although refuses to load the kernel. The FreeBSD 7.1 > > install CD also boots and allows me to install over FTP. > > A patch has just gone into HEAD which may fix this problem. If you want > to test it, it's at > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S.diff?r1=1.47;r2=1.48 > and should apply cleanly. I built and installed a new version of -CURRENT which has this patch, using the instructions at the bottom of UPDATING. To be certain - btx doesn't need loading into the boot blocks, does it? bsdlabel -wB from my 7.0-RELEASE install and then using make installworld etc with DESTDIR should ensure that the new boot binaries are installed? If so, then unfortunately the patch does not help - btx still crashes with a similar traceback to the one I originally posted. I would be more than happy to test further patches. David Adam zanc...@ucc.gu.uwa.edu.au ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
