Re: mfid, raid monitoring daemon
On Thu, Mar 8, 2012 at 10:08 AM, Sean Bruno sean...@yahoo-inc.com wrote: I'm trying to decide if I should cram mfid for mfi(4) controllers into the src tree or if we should package it up into a ports package. I suspect that either one is acceptible, but it seems to make more sense to put it into the src tree since mfiutil is also there. Comments? Sean ref: http://svnweb.freebsd.org/base/user/sbruno/mfid/ I agree with placing it into the tree. Mfiutil is a great utility, but having a monitoring daemon in the tree would be a great addition. -jgh ___ 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: Keeping /etc/localtime up-to-date
On Mon, Mar 28, 2011 at 02:22:01PM -0400, Maxim Khitrov thus spake: Same here, though I'd be happy to change this habit if mergemaster handled the updates for me. This would be a good solution for source updates, but how would this work for binary upgrades via freebsd-update, as mergemaster is not used for this operation. -jgh -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 ___ 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: Error amavisd on freebsd 8.2
On Thu, Mar 10, 2011 at 03:08:50PM +, juki thus spake: Dear all, I try install the amavisd-new for the new mailserver, but the amavisd service can't running, I checked in log and there nothing error, I try to deinstall amavisd in port (/usr/port/security/amavisd-new) and back to reinstall and not success. What can I do for resolving it??? Errors would be good for helping you in resolve this problem, and you may want to consider following up with freebsd-ports@ on this issue, as you may yield more feedback, and potentially resolve your issue in a more timely manner. -jgh Thanks Regards, Juki Powered by Telkomsel BlackBerry® ___ 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 -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 ___ 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: listing all modules compiled into a kernel instance
On Tue, Mar 01, 2011 at 12:01:48PM -0800, Carl thus spake: On 2011-03-01 3:20 AM, Maxim Khitrov wrote: kldstat provides information about components that were loaded dynamically. If your kernel was built with INCLUDE_CONFIG_FILE option (enabled by default in GENERIC), then you can see the static components using: config -x /boot/kernel/kernel As has been shown though, kldstat -v actually does show static components, at least those declared with DRIVER_MODULE(), and config -x does not improve on the situation at all because components like ucom were not cited in the configuration file. IMHO, there needs to be a reliable way to query an existing kernel that yields a _complete_ list of which components are actually included. On 2011-03-01 5:00 AM, John Baldwin wrote: Maybe ucom doesn't appear because it doesn't have a DRIVER_MODULE() declaration (because it isn't a driver). Yes, that would explain it. I can explicitly include ucom in a kernel by adding device ucom in the configuration file, in which case it would call DRIVER_MODULE(), right? That would then make it appear in the kldstat -v list? So why is it a driver when it's done explicitly, but not a driver when done implicitly? That makes no sense to me since the functionality doesn't change. IMHO, this is a bug that needs to be fixed, not just for ucom but any implicitly included driver. Who should submit a bug report? There was a documentation bug that was put in regarding the ucom device, and it was to update the device name in the documentation. http://www.freebsd.org/cgi/query-pr.cgi?pr=155074 I don't know if a PR is still required, but this may be worth a look first. Carl / K0802647 -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 ___ 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
