Re: FreeBSD 9 and PERC H200
- Original Message - From: "Karl Dunn" To: "Steven Hartland" >>> On 22/07/2013 23:35, Steven Hartland wrote: mps has been in FreeBSD for years surely older than 9.1 are you sure you have a generic kernel? Its certainly in GENERIC for 9.1-RELEASE in amd64 http://svnweb.freebsd.org/base/release/9.1.0/sys/amd64/conf/GENERIC?revision=243808&view=markup but not in the i386 GENERIC http://svnweb.freebsd.org/base/release/9.1.0/sys/i386/conf/GENERIC?revision=243808&view=markup as per the svn log http://svnweb.freebsd.org/base?view=revision&revision=212420 Ahh I never user i386 ;-) Indeed: root@newserver#/root(1)# uname -a FreeBSD newserver.kad-hg.org 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Thanks for the clarification. I didn't try 9.1-release amd64. I have no intention of using amd64 because of past trouble with alignment in some ports. I really wouldn't worry about that, I've been using amd64 for literally years and never seen an alignment issue with ports. There may well have been in the past for specific ports but I suspect thats long since been resolved :) Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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"
sta...@freebsd.org
Hello, i have a problem with Adobe Flash. http://www.freebsd.org/cgi/query-pr.cgi?pr=180766 ___ 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: stopping amd causes a freeze
On 22/07/2013 20:05, Artem Belevich wrote: > On Mon, Jul 22, 2013 at 2:50 AM, Dominic Fandrey wrote: > >> Occasionally stopping amd freezes my system. It's a rare occurrence, >> and I haven't found a reliable way to reproduce it. >> >> It's also a real freeze, so there's no way to get into the debugger >> or grab a core dump. I only can perform the 4 seconds hard shutdown to >> revive the system. >> >> I run amd through sysutils/automounter, which is a scripting solution >> that generates an amd.map file based on encountered devices and devd >> events. The SIGHUP it sends to amd to tell it the map file was updated >> does not cause problems, only a SIGKILL may cause the freeze. >> >> Nothing was mounted (by amd) during the last freeze. >> >> > ... > > >> I don't see any angle to tackle this, but I'm throwing it out here >> any way, in the hopes that someone actually has an idea how to approach >> the issue. >> > > Don't use KILL or make sure that nobody tries to use amd mountpoints until > new instance starts. Manually unmounting them before killing amd may help. > Why not let amd do it itself with "/etc/rc.d/amd stop" ? That was a typo, I'm using SIGTERM. Sorry about that. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: stopping amd causes a freeze
On Tue, Jul 23, 2013 at 10:43 AM, Dominic Fandrey wrote: > > Don't use KILL or make sure that nobody tries to use amd mountpoints > until > > new instance starts. Manually unmounting them before killing amd may > help. > > Why not let amd do it itself with "/etc/rc.d/amd stop" ? > > That was a typo, I'm using SIGTERM. Sorry about that. > > On SIGTERM amd will attempt to unmount its mountpoints. If someone is using them, unmount may not succeed. I've no clue what amd does in such case. The point is that you should treat amd restart as reboot of an NFS server. amd map reload does not really require amd restart. In some cases you may have to manually unmount some automounted filesystem if underlying map had changed, but that's the only case I can think of off the top of my head. In most of the cases "amq -f" worked well enough for me. By the way, are you absolutely sure that your script that restarts amd is guaranteed not to touch anything mounted with amd? Otherwise you're risking a deadlock. For example, if PATH contains amd-mounted directory then when it's time to execute next command your script may attempt to touch such path and may hang waiting for amd to respond which will never happen because the script can't start it. Now, back to debugging your problem. One way to check what's going on would be to figure out where do the processes get stuck. Start with "ps -axl" and see STAT field. CHances are that stuck processes will be in uninterruptible sleep state 'D'. Check MWCHAN field for those. Hitting '^T' which normally sends SIGINFO should also produce a message that includes process' wait channel and is convenient to use when you have console where you've started the app that is hung. Dig further into the sleeping process with "procstat -kk PID" -- it will give you in-kernel stack trace for process' threads which should whos what's going on. You may want to do it from a root login with local host directory and minimalistic PATH so it does not touch any amd mount points. --Artem ___ 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"
