Re[2]: 5.4 freezes randomly
DOC I don't know if this will help, but mpd4 is the development version--I'd DOC try mpd 3 (/usr/ports/net/mpd). I'm using it for a VPN server on FBSD DOC 6.0, without any troubles... The problem was solved. There was a tunnel loop. With 400+ users mpd4 works much better than mpd3.18 -- [ /Iexa ] mailto:[EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
Date: Thu, 5 Jan 2006 10:31:33 -0500 From: Vivek Khera [EMAIL PROTECTED] Subject: Re: rpcbind lingering on IP no longer specified on command line To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jan 5, 2006, at 6:06 AM, Gavin Atkinson wrote: Can anyone explain why rpcbind will still bind to all tcp interfaces? Although I believe this is a bug, it is actually working as documented: from rpcbind(8): -h bindip Specify specific IP addresses to bind to for UDP requests. Yeah, I noticed that little tiny UDP requests note in the -h docs too. There's no reason to bind to all tcp addresses, and it is causing me heartburn for getting the server certified... Good grief, why not just firewall off the undesired UDP ports and call it good? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[6.0] Snapshot removes acls flag from fs.
When I make snapshot of fs it removes acls flag from mount. While the command is mount -u -o snapshot etc. I don't think it should remove the flag because it is not specified besides the snapshot option. Vaclav Haisman signature.asc Description: OpenPGP digital signature
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote: 1. modified kernels are foobar ..yet are practically mandatory on production systems Look around. Every major commercial OS does it just fine. While I agree with much of your reasoning, I know exactly zero people running a modified kernel of any version of Windows, Mac OS X or Solaris, to name just three commercial OS's. You're tickling a different subject here. All three of these operating systems have loadable kernel modules that work. I mean, they dynamically load the modules they need, and you can disable kernel modules in configuration files. FreeBSD has loadable kernel modules, but they don't autoload (you have to modify rc files) and you can't trim down the kernel to minimize unused memory without recompiling. To give you a specific example: if we could remove NFS and the 3ware driver from the kernel in a configuration file, we could probably run GENERIC. (we do *a lot* of other modifications, but NFS is the main memory hog we have to remove on small footprint systems, and the 3ware driver we have to update independently, which requires that it be a loadable module and not compiled in) So yeah, this is a different problem. However I wasn't going to tackle this issue in this thread because the -core team appears to be very aware of this issue and it seems to improve a bit in every release. And third party drivers (which one could count as kernel modifications) did fail and will fail sometimes in weird ways even for minor version upgrades/patches. BTDT - Windows Services Packs, Solaris patches, Mac OS X updates, reboot, *boom*, because some hardware suppliers driver didn't adhere to the OS manufacturer's standards or because the latter silently changed something undocumented. I don't know what you're trying to say here. I don't disagree, I'm just not sure what you mean. It almost sounds like you're trying to make my own point about having the ability to backout patches, which we don't have today. While I would appreciate a packaged core system or at least a better definition of core system at all, I strongly believe that binary updating a custom kernel is impossible. If the kernel is consistent across the enterprise (but not, say GENERIC) then binary updates would be trivial. With better definition of core system I mean, if you have a long lived production system that you might have upgraded from 4.x to 5.x to 6.0, you will have a lot of cruft lying on your filesystem that once was part of the core and now isn't. And there is no simple and automated way to find out what to delete ... That's another good point for having file revisions. We don't have that particular problem, but I can easily imagine how having versioning of the core OS would be useful to help isolate these orphaned files. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Wed, Jan 04, 2006 at 10:46:06PM +0300, Dmitry Morozovsky wrote:
On Wed, 4 Jan 2006, Vivek Khera wrote:
VK I had rpcbind running with on two interfaces like this:
VK
VK rpcbind -h 192.168.100.200 -h 10.0.0.9
VK
VK Now, I changed rpcbind_flags in /etc/rc.conf to just have the first
address,
VK and I restarted rpcbind. the process list from ps shows it is running
like
VK this:
VK
VK rpcbind -h 192.168.100.200
VK
VK Yet nmap on the other address shows rpcbind is still listening on udp
there.
VK How do I stop that?
As I sometimes looked into this, rpcbind (formely portmap) listens on all
described addresses via udp *and* an tcp:*.111 - I tried to dig why is this
but
did not succeed much.
Please test this patch. It's probably a very naive fix, but seems to
work OK.
Ceri
--
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)
Index: rpcbind.8
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.8,v
retrieving revision 1.7
diff -u -r1.7 rpcbind.8
--- rpcbind.8 18 Jan 2005 20:02:43 - 1.7
+++ rpcbind.8 6 Jan 2006 10:35:02 -
@@ -83,7 +83,7 @@
With this option, the name-to-address translation consistency
checks are shown in detail.
.It Fl h Ar bindip
-Specify specific IP addresses to bind to for UDP requests.
+Specify specific IP addresses to bind to.
This option
may be specified multiple times and is typically necessary when running
on a multi-homed host.
@@ -95,14 +95,14 @@
.Dv INADDR_ANY ,
which could lead to problems on a multi-homed host due to
.Nm
-returning a UDP packet from a different IP address than it was
+returning a packet from a different IP address than it was
sent to.
Note that when specifying IP addresses with
.Fl h ,
.Nm
will automatically add
.Li 127.0.0.1
-and if IPv6 is enabled,
+and, if IPv6 is enabled,
.Li ::1
to the list.
.It Fl i
Index: rpcbind.c
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.c,v
retrieving revision 1.14
diff -u -r1.14 rpcbind.c
--- rpcbind.c 7 Nov 2004 04:32:51 - 1.14
+++ rpcbind.c 6 Jan 2006 10:28:10 -
@@ -209,11 +209,11 @@
struct passwd *p;
if((p = getpwnam(RUN_AS)) == NULL) {
- syslog(LOG_ERR, cannot get uid of daemon: %m);
+ syslog(LOG_ERR, cannot get uid of %s: %m, RUN_AS);
exit(1);
}
if (setuid(p-pw_uid) == -1) {
- syslog(LOG_ERR, setuid to daemon failed: %m);
+ syslog(LOG_ERR, setuid to %s failed: %m, RUN_AS);
exit(1);
}
}
@@ -272,7 +272,8 @@
* XXX - using RPC library internal functions. For NC_TPI_CLTS
* we call this later, for each socket we like to bind.
*/
- if (nconf-nc_semantics != NC_TPI_CLTS) {
+ if (nconf-nc_semantics != NC_TPI_CLTS
+ nconf-nc_semantics != NC_TPI_COTS_ORD) {
if ((fd = __rpc_nconf2fd(nconf)) 0) {
int non_fatal = 0;
@@ -308,7 +309,8 @@
hints.ai_socktype = si.si_socktype;
hints.ai_protocol = si.si_proto;
}
- if (nconf-nc_semantics == NC_TPI_CLTS) {
+ if (nconf-nc_semantics == NC_TPI_CLTS ||
+ nconf-nc_semantics == NC_TPI_COTS_ORD) {
/*
* If no hosts were specified, just bind to INADDR_ANY.
Otherwise
* make sure 127.0.0.1 is added to the list.
@@ -348,7 +350,7 @@
hints.ai_flags = AI_NUMERICHOST;
} else {
/*
-* Skip if we have an AF_INET6 adress.
+* Skip if we have an AF_INET6 address.
*/
if (inet_pton(AF_INET6,
hosts[nhostsbak], host_addr) == 1)
@@ -361,7 +363,7 @@
hints.ai_flags = AI_NUMERICHOST;
} else {
/*
-* Skip if we have an AF_INET adress.
+* Skip if we have an AF_INET address.
*/
if (inet_pton(AF_INET, hosts[nhostsbak],
host_addr) == 1)
pgpcOPKf0MNey.pgp
Description: PGP signature
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, Jan 05, 2006 at 09:11:58PM +1030, Daniel O'Connor wrote: On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: How do you expect these two to be handled in a binary upgrade? I can't see how it's possible.. Look around. Every major commercial OS does it just fine. Most of the open source OSes do it just fine. Debian had probably the easiest to use system, and they've risen, owned the world and fallen all while FreeBSD has been debating this issue. You appear to be misunderstanding what I said. I'm not arguing binary upgrades shouldn't be done but I'm suggesting that it isn't NECESSARY to version and package the base install to do it. Whether or not the core is 'packaged' is an implementation detail. I've heard good arguements either way. But some sort of versioning is required. How do you know what to update? How do you know if it has been updated already? Checksum analysis is the VERY long way around and incredibly CPU intensive. And it requires an extensive database of all possible combinations. I don't think integrating it with the core OS (whatever that means) will magically fix this. If you knew what it meant, you would understand why it would help. Ah what a great explanation of what is meant. There are several people who don't know what is meant here and I haven't seen a decent explanation forthcoming. I had explained it several times in other replies, and wasn't going to repeat it again. Especially not against a global wide open I don't think it will help without any backing arguements or qualifications to the statement. It's just too broad to work with. In short, not trying to be rude but would prefer to focus on solutions that explain the 10k view. Just because I don't run jails doesn't mean I don't know the pain of upgrading a system. Just because you've upgraded a system doesn't mean you understand or even grasp the issues involved in managing jails. You can tell me that driving a car should give you the experience to argue riding motorcycles with me, but I'm going to have trouble taking you seriously ;-) (no offense intended, really... just trying to be clear) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, Jan 05, 2006 at 01:26:12PM -0500, Ender wrote: I think what integrated with the core OS means from a user standpoint is: from a fresh minimum install of freebsd I can type freebsd-update-whatever and it will update my system. Just freebsd-update ;-) That works fairly well with the current freebsd-update (or bsdupdates.com) solutions. For most GENERIC installed systems, it works fairly well. I use on 3 systems at my home for this, and I'm pretty happy with it. It doesn't work very well in environments with compiled options, custom kernels, and other situations. That's what I'm trying to tackle here. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, Jan 05, 2006 at 10:40:56PM +1100, Peter Jeremy wrote:
No. I want a binary update mechanism. Obviously if we have local
configuration options we'll have to compile our own binaries. But doing
the work of tracking system updates currently requires us to build our own
patch tracking mechanism, and then re-write it for every new release.
On Thu, 2006-Jan-05 01:37:27 -0800, Jo Rhett wrote:
If you're willing to do your own compiles:
1) CVSup or cvs update to whatever branch you want
2) make build{world,kernel}
3) make DESTDIR=/updates install{world,kernel}
4) mergemaster -D /updates
5) rsync or similar
Hm. So how do I know which systems need the upgrade?
So what occurs if the wrong version is rsynced to the wrong system?
What do I do if a kernel module upgrade fails? How do I restore state?
This problem is solved fairly well in every other OS I can think of. But
for FreeBSD we're currently solving it with very complex cfengine
management tied to lots of local databases and thousands of lines of our
own code. It's all the long way around a problem that is very simple to
solve in the core.
It seems fairly obvious that you are frustrated by FreeBSD's inability
to meet your needs as far as updating is concerned. I suspect I'm not
alone in being uncertain exactly what your requirements are and what
additional features FreeBSD needs to satisfy you.
Some implementation (any!) that versions the core. Something you can query
to ask what is, update to say what you've done, and revert to restore a
previous state.
How would you like
to write a formal requirements specification and post it here (or in
-arch).
This has been written many times, by people better at explaining the issues
than I am. I'll find someone elses and forward it to you.
Have you looked at tools like Bcfg2 ( http://www.mcs.anl.gov/cobalt/bcfg2/ )?
I haven't compared bcfg2 to what we're doing now (cfengine) but it would
likely have all of the same problems. Namely, we'd have to build and
maintain a database of all possible software combinations, and what systems
are running which patches, and then write scripts that do the right updates
to the right systems.
Again, thousands of lines of perl/ruby/shell to work around a very well
known limitation in freebsd.
--
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with PERC4e/DC RAID?
On Fri, Jan 06, 2006 at 01:21:56PM +1100, Michael Vince wrote: FYI there also has been a big update to the amr driver which claims to dramatically increase performance among other things, interestingly enought it was augmented by Yahoo, I can only assume they are moving to Dell, yahoo for me (and now you :). The updates are still in -current but it will be MFC'ed into stable sooner or later. http://lists.freebsd.org/pipermail/cvs-src/2005-December/056814.html Yeah, I saw that, and it sounds most excellent. Good to see some real support from the likes of Dell and LSI, too. I might be able to get away with running -stable on this machine, but -current will be right out. Hopefully these changes can be MFCed in time for 6.1. Scott Log: Mega update to the LSI MegaRAID driver: 1. Implement a large set of ioctl shims so that the Linux management apps from LSI will work. This includes infrastructure to support adding, deleting and rescanning arrays at runtime. This is based on work from Doug Ambrosko, heavily augmented by LSI and Yahoo. 2. Implement full 64-bit DMA support. Systems with more than 4GB of RAM can now operate without the cost of bounce buffers. Cards that cannot do 64-bit DMA will automatically revert to using bounce buffers. This option can be forced off by setting the 'hw.amr.force_sg32 tunable in the loader. It should only be turned off for debugging purposes. This work was sponsored by Yahoo. 3. Streamline the command delivery and interrupt handler paths after much discussion with Dell and LSI. The logic now closely matches the intended design, making it both more robust and much faster. Certain i/o failures under heavy load should be fixed with this. 4. Optimize the locking. In the interrupt handler, the card can be checked for completed commands without any locks held, due to the handler being implicitely serialized and there being no need to look at any shared data. Only grab the lock to return the command structure to the free pool. A small optimization can still be made to collect all of the completions together and then free them together under a single lock. Items 3 and 4 significantly increase the performance of the driver. On an LSI 320-2X card, transactions per second went from 13,000 to 31,000 in my testing with these changes. However, these changes are still fairly experimental and shouldn't be merged to 6.x until there is more testing. Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing towards this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.0] Snapshot removes acls flag from fs.
On Fri, Jan 06, 2006 at 10:50:57AM +0100, V??clav Haisman wrote: When I make snapshot of fs it removes acls flag from mount. While the command is mount -u -o snapshot etc. I don't think it should remove the flag because it is not specified besides the snapshot option. You probably want something like: mount -u -o cur,snapshot ... See the current and fstab options in the mount man page. An easier way to do this would be to use the mksnap_ffs command, which should preserve the old options. David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote: I believe core has a policy of never supporting vaporware... There is always the chicken and egg problem with arguments like this... I'll code this if you agree to support it and maintain it/I will agree to support it once you code it... In FreeBSD, and many open source projects, no code, no support, how can you support or even agree to support something that doesn't exist? And then as soon as FreeBSD agrees to support something that doesn't exist, either a) other people who were interested in the project stop, even if you end up never producing a bit of code, or b) someone else produces better code, drops the support for the original, but then the author complains about being told they'd support his code, and going with another code base... Bottom line: Once code exists, then support can be talked about.. This is the chicken and egg problem that will kill FreeBSD. I don't bother writing up patches for FreeBSD because every time I do they sit in a PR and get ignored for several years. Then someone that does have commit rights makes their own patch (which often is less useful) but they own it and the best I've ever succeeded at was convincing them to put some of the ideas from my patch into their code. Note that none of these patches were ever rejected for any technical or political or any other reason. They just don't get paid attention to. Thus, I try to get consensus that the idea has merit. IF freebsd committers can be bothered to pay attention to the idea, I'll write code for it. But I'm too old and tired to spend another week writing up something that will get ignored for X years and then dropped for obsoletion again. AND there are a lot of opinions and politics around how to version the core that have nothing to do with code. There's no value in writing code that will be ignored because it doesn't agree with -core's view of should be. I'm a coder, not a politician. If we can get consensus on what type of implementation would be acceptable to core, then I and many others would be happy to write code to implement this idea. But this is a considerable amount of work that will be closely tied to the operation system installation. It's not something that you can churn out 7 different implementations of just to see which one fits the current polical environment. Back to your finale: Bottom line: Once code exists, then support can be talked about.. This is bullhockey and you know it. Once the project is done, we'll authorize a budget for it? Once the season is over we'll know who should be on the starting team? Yeah, hindsight is sweet. But this isn't a simple change. It will require very close integration with the installation and kernel modules at least (and probably more). So having some sort of consensus that (a) the project has interest and (b) what flavors would be acceptable to the existing groups - are both necessary for this project to even mumble it's first line of code. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
I just know that core has either struck it down or been Silent. On Thu, Jan 05, 2006 at 05:32:26PM -0600, Mark Linimon wrote: The latter is an entirely different case from the former, and you've been claiming core has done the former. This, and the above, tell me that you're not interested in checking your facts before making an accusation. (And, as well, that you do not even understand the role the core plays in the project. Hint: it is not primarily technical in nature.) I agree with most of what you said here. This was known and understood. Agreement on direction is what I was expecting, er, dreaming about. Not technical issues. Sorry if that surprises you. But I have to take objection to this: As a final observation, FreeBSD is rarely advanced by postings of the form 'FreeBSD must do XYZ'. This is primarily because volunteers work on whatever they feel interested in doing with their free time, rather than the priorities anyone else sets for them. First, this is obvious and true for all open source projects. But no, FreeBSD _never_ advances because someone writes code that does something well. FreeBSD _only_ advances when the core developers agree that this thing is worthy of their interest. And I'm not even saying this is a bad thing. It just means that writing code without buy-in from the core developers is GUARANTEED to be a waste of time. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
On Fri, 6 Jan 2006 21:53, Jo Rhett wrote: you mean? Are you claiming someone from (or claiming to be from core) said Don't do this, we won't allow it? If so, can you supply proof? I used to write a lot of patches to freebsd. I used to submit a lot of bug reports. I've found over the years that unless you have gotten pre-agreement from others about the nature of the patch, or agreement to focus on the problem, neither one amounts to a hill of beans. Installation problems that existed in 4.4 are still alive and well in the 6.0 installer, for example. shrugs That is not my experience. How FreeBSD works is by getting someone in the core team to care about the issue. No amount of problem reports, patches or code will generate even a millimeter of movement otherwise. You are mistaking core@ for [EMAIL PROTECTED] Like I've said before, core is largely irrelevant in FreeBSD when it comes to deciding what stuff gets added. I've written far too much code for various freebsd problems, and it has always been ignored. Not rejected, ignored. Unless someone with commit rights thinks it's a good idea, writing code for freebsd is a waste of time. Yes.. and those people AREN'T CORE. Please, please stop confusing your terms, it makes the discussion much harder than it needs to be. You ARE right if what you mean is that We need interested committers to help thrash out a system for making upgrades simpler. I imagine there are a few committers interested, but I'd say you need to ask the right way first.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpW2Ga0PbgcH.pgp Description: PGP signature
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Hi there, Jo Rhett wrote: On Fri, Jan 06, 2006 at 11:20:13AM +1030, Daniel O'Connor wrote: So, uhh, how would your magical binary upgrade system handle custom kernels? Why would it be any different? You still haven't explained how this would work.. Versioning of the core package would tell you WHAT you have with a query. It's trivial to then install the matching patches. Right now every enterprise has to build a backend database tracking core os, installed options, compile options, etc for every single installed system. Or build a checksum database that can be used to derive this information from the system (if all systems have the CPU/RAM to spare to play this game) I'm actually wondering how yahoo for instance handles this situation. To my knowledge, they have several thousand of FreeBSD based servers. Either they are all the same in regards to configuration and version, or they have some other cunning way to solve the issue of patching. We need support from the freebsd core developers that this is a worthwhile idea, and what kind of solutions would be acceptable to them. Once we have a direction to go in, code can be written. Generally speaking: Your statement is true. You don't start writing code without an agreement that the direction choosen is a direction where FreeBSD wants to evolve. However, you (as in, you as a developer) could come up with a proof of concept. Start with an implementation like you would like to have it. And even if it's just a piece of paper and some code. Then start this thread over again, fine tune the concept and hopefully some others will jump aboard and help developing. I would like to, but I do lack knowledge in C. Shell and a wee bit of Perl is fine. Definitly too few knowledge for a project like that :-/ If you supply a working framework then I think you'll find a lot of support materialises. The problem is when you are just proposing vapourware solutions everyone steps in and wants it done their way. Code speaks louder than words :) I've written far too much code for various freebsd problems, and it has always been ignored. Not rejected, ignored. Unless someone with commit rights thinks it's a good idea, writing code for freebsd is a waste of time. That statement ain't true. If the code solves your problem, fine. If it solves problems of others too, even better. Chances are higher that it doesn't get ignored... regards, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.0 on Dell 1850 with DRAC4 management card?
Hi all, On to my next question about running 6.0 on a Dell PE1850, since it seems that the RAID card will work just fine... I'm thinking about getting the machine with a DRAC4 remote management card. This looks to be OS-independent (you can configure through the BIOS) so I expect it will just work. I've seen various posts talking about how it tends to take over the keyboard and render the real console inaccessible, but there are workarounds for that. Does anyone have the console redirection working? I'd like to leave the 'real' console (actually a USB keyboard attached to a KVM) active so the machine is accessible to someone actually in the server room, but still be able to get to the console remotely when necessary. The Dell docs imply that you can just point a browser at the DRAC and fire up a new console, but I'd like to hear from someone who's done this with FreeBSD! Apologies for all the dumb questions... I'd try all this stuff myself but the hardware isn't here yet and has to go into production pretty quickly once it arrives. All the similar machines in the building are already running Windows and someone would object if I 'liberated' any of them :) Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
Scott Mitchell wrote: Hi all, On to my next question about running 6.0 on a Dell PE1850, since it seems that the RAID card will work just fine... I'm thinking about getting the machine with a DRAC4 remote management card. This looks to be OS-independent (you can configure through the BIOS) so I expect it will just work. I've seen various posts talking about how it tends to take over the keyboard and render the real console inaccessible, but there are workarounds for that. I'm not sure about that, but I have 15 of these machines in locations all over Ontario, running Windows2003 Server. To make the thing as secure as possible, there is no keyboard or monitor on the server, I attach through the client's LAN. The DRAC gets a static IP on the local subnet, so using a laptop with a connection (hard or wireless), I can access and control the server from inside the server room, from an office or desk in the building, or from anywhere in the world there is an Internet connection. The last option means having VPN access to the local building network. Does anyone have the console redirection working? I'd like to leave the 'real' console (actually a USB keyboard attached to a KVM) active so the machine is accessible to someone actually in the server room, but still be able to get to the console remotely when necessary. The Dell docs imply that you can just point a browser at the DRAC and fire up a new console, but I'd like to hear from someone who's done this with FreeBSD! Works for me! It's really cool! You can access multiple servers through additional browser windows. As long as there is another computer in the server room with access to your server, they can control it through the browser interface. No KBD or monitor are necessary. I'd like to assume FreeBSD will just work. Ralph ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: [Flow-tools] Memory leak ?]
Hello, I will try with malloc and Electric Fence. I have no idea how big must be a process, because I use flow-capture for first time on this machine. Please, if someone have experience with this tool, to share some statistics. Only for information - flow-capture is a part of flow-tools in /usr/ports category net-mgmt. To collect netflow-data I use softflowd. Thank you for your email. On Friday 06 January 2006 13:15, you wrote: [flow-capture process too large] On Fri, 2006-Jan-06 11:08:54 +0200, Todor Dragnev wrote: Can someone help with this ? Help how? AFAIK, flow-control/flow-capture is not a FreeBSD port so finding someone here with knowledge of it may be difficult. If you think it's a problem with FreeBSD, you're going to need to supply more information so that we can help you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Fri, 6 Jan 2006, Ceri Davies wrote: CD VK I had rpcbind running with on two interfaces like this: CD VK CD VK rpcbind -h 192.168.100.200 -h 10.0.0.9 CD VK CD VK Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, CD VK and I restarted rpcbind. the process list from ps shows it is running like CD VK this: CD VK CD VK rpcbind -h 192.168.100.200 CD VK CD VK Yet nmap on the other address shows rpcbind is still listening on udp there. CD VK How do I stop that? CD CD As I sometimes looked into this, rpcbind (formely portmap) listens on all CD described addresses via udp *and* an tcp:*.111 - I tried to dig why is this but CD did not succeed much. CD CD Please test this patch. It's probably a very naive fix, but seems to CD work OK. Well, two objections: - (obvious and dumb ;): three kinds of changes inside: behaviour, style and typo ;-))) - serious: no way to run on NO_INET6 kernel: [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc 83231 ?? Ss 0:00.00 /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p program vers proto port service 104 tcp111 rpcbind 103 tcp111 rpcbind 102 tcp111 rpcbind 104 udp111 rpcbind 103 udp111 rpcbind 102 udp111 rpcbind 104 local111 rpcbind 103 local111 rpcbind 102 local111 rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# sockstat -4 | grep rpc root rpcbind83332 7 udp4 *:111 *:* root rpcbind83332 8 udp4 *:608 *:* root rpcbind83332 9 tcp4 *:111 *:* Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
Hi there, Scott Mitchell wrote: Hi all, I'm thinking about getting the machine with a DRAC4 remote management card. This looks to be OS-independent (you can configure through the BIOS) so I expect it will just work. I've seen various posts talking about how it tends to take over the keyboard and render the real console inaccessible, but there are workarounds for that. I don't know about the DRAC with FreeBSD, but I assume that the BIOS of this Dell still supports BIOS redirection to serial port. If so, you can have Monitor and Keyboard connected locally and use the serial console remote. Just get a small console server (depending on the amount of servers you have remote), for instance an old cyclades TS. Connect them and you can get on your serial port through the console server via ssh. There you go ;) ssh username:[EMAIL PROTECTED] A pretty nice way to do remote management. HTH, Marian PS.: If you need additional informations, ask me. At work we have approx 1000 servers (appr. 300 dell's) remote managed with console servers. And it's working fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
On Fri, Jan 06, 2006 at 09:12:06AM -0500, Ralph Hempel wrote: Scott Mitchell wrote: Hi all, On to my next question about running 6.0 on a Dell PE1850, since it seems that the RAID card will work just fine... I'm thinking about getting the machine with a DRAC4 remote management card. This looks to be OS-independent (you can configure through the BIOS) so I expect it will just work. I've seen various posts talking about how it tends to take over the keyboard and render the real console inaccessible, but there are workarounds for that. I'm not sure about that, but I have 15 of these machines in locations all over Ontario, running Windows2003 Server. I should have said that this was really a FreeBSD issue rather than a problem with the DRAC - apparently it attaches as a second keyboard and mouse, but FreeBSD has historically only allowed a single 'console' keyboard to exist. 6.0 has the kbdmux(4) driver that might solve this without and messing about with keyboard attachments. To make the thing as secure as possible, there is no keyboard or monitor on the server, I attach through the client's LAN. The DRAC gets a static IP on the local subnet, so using a laptop with a connection (hard or wireless), I can access and control the server from inside the server room, from an office or desk in the building, or from anywhere in the world there is an Internet connection. The last option means having VPN access to the local building network. That sounds cool. The server room is right behind my desk so it's not a big deal go in there, but being able to reboot a stuck machine from home is nice! Does anyone have the console redirection working? I'd like to leave the 'real' console (actually a USB keyboard attached to a KVM) active so the machine is accessible to someone actually in the server room, but still be able to get to the console remotely when necessary. The Dell docs imply that you can just point a browser at the DRAC and fire up a new console, but I'd like to hear from someone who's done this with FreeBSD! Works for me! It's really cool! You can access multiple servers through additional browser windows. As long as there is another computer in the server room with access to your server, they can control it through the browser interface. No KBD or monitor are necessary. I'd like to assume FreeBSD will just work. Me too. Sounds like it will mostly behave itself. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel)
On Jan 5, 2006, at 11:08 PM, Chuck Swiger wrote: There's an interesting thread about the AMR RAID controller used in the newer 18x0/28x0 Dells with the PERC/4 controller, and I know of enough people using them that such improvements (by Doug Ambrisko?) will be welcomed. Thanks for your note. Turns out I have more than one Dell system with aac controllers in them :-) One happens to be a PE 1750 with the PERC 3/Di in it running RAID1. It is lightly loaded but is sufficient for that server's needs, but is running FreeBSD 4.11 on it. Is there a way to backport this diskinfo utility to 4.x or 5.x? Looks most useful! On my 6.0 box with a PERC 3/Si card (aac driver too) it is showing seek times slower than yours but transfer rates faster. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /boot/nextboot.conf not deactivated after one boot
On Thu, Jan 05, 2006 at 01:41:33PM +0100, Marius Nuennerich wrote:
Hi folks,
it seems like /boot/nextboot.conf is neither deleted nor
nextboot_enable set to NO on the first line after a reboot.
So it isn't a one shot anymore as the manpage claims.
System is 6.0-RELEASE.
I think this is down to a typo in /etc/rc.d/root; at least I can't find
any other reference to /boot/nextkernel in src/. Patch attached
(root.diff).
It would also be fine imo, if the -k option would be optional and the
next kernel defaults to kernel.
I'm not sure if getopts can be persuaded to take an optional argument to
an option. If not, the attached patch (nextboot.diff) should work for
you.
Ceri
--
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)
Index: etc/rc.d/root
===
RCS file: /home/ncvs/src/etc/rc.d/root,v
retrieving revision 1.11
diff -u -r1.11 root
--- etc/rc.d/root 2 Dec 2005 21:33:43 - 1.11
+++ etc/rc.d/root 6 Jan 2006 14:37:51 -
@@ -34,8 +34,8 @@
# If we booted a special kernel remove the record
# so we will boot the default kernel next time.
- if [ -e /boot/nextkernel ]; then
- rm -f /boot/nextkernel
+ if [ -e /boot/nextboot.conf ]; then
+ rm -f /boot/nextboot.conf
fi
}
Index: sbin/reboot/nextboot.8
===
RCS file: /home/ncvs/src/sbin/reboot/nextboot.8,v
retrieving revision 1.4
diff -u -r1.4 nextboot.8
--- sbin/reboot/nextboot.8 12 Dec 2002 17:25:56 - 1.4
+++ sbin/reboot/nextboot.8 6 Jan 2006 15:13:24 -
@@ -24,7 +24,7 @@
.\
.\ $FreeBSD: src/sbin/reboot/nextboot.8,v 1.4 2002/12/12 17:25:56 ru Exp $
.\
-.Dd November 4, 2002
+.Dd January 6, 2006
.Dt NEXTBOOT 8
.Os
.Sh NAME
@@ -33,8 +33,8 @@
.Sh SYNOPSIS
.Nm
.Op Fl f
+.Op Fl k Ar kernel
.Op Fl o Ar options
-.Fl k Ar kernel
.Nm
.Fl D
.Sh DESCRIPTION
@@ -68,6 +68,8 @@
This option specifies a kernel directory relative to
.Pa /boot
to load the kernel and any modules from.
+If this option is not provided, defaults to
+.Dq Li kernel .
.It Fl o Ar options
This option
allows the passing of kernel flags for the next boot.
@@ -90,7 +92,7 @@
.Pp
To enable into single user mode with the normal kernel:
.Pp
-.Dl nextboot -o -s -k kernel
+.Dl nextboot -o -s
.Pp
To remove an existing nextboot configuration:
.Pp
Index: sbin/reboot/nextboot.sh
===
RCS file: /home/ncvs/src/sbin/reboot/nextboot.sh,v
retrieving revision 1.1
diff -u -r1.1 nextboot.sh
--- sbin/reboot/nextboot.sh 24 May 2002 04:06:03 - 1.1
+++ sbin/reboot/nextboot.sh 6 Jan 2006 15:13:24 -
@@ -10,10 +10,12 @@
nextboot_file=/boot/nextboot.conf
display_usage() {
- echo Usage: nextboot [-f] [-o options] -k kernel
+ echo Usage: nextboot [-f] [-k kernel] [-o options]
echonextboot -D
}
+kernel=kernel
+
while getopts Dfk:o: argument ; do
case ${argument} in
D)
@@ -40,11 +42,6 @@
exit 0
fi
-if [ xxx${kernel} = xxx ]; then
- display_usage
- exit 1
-fi
-
if [ ${force} = NO -a ! -d /boot/${kernel} ]; then
echo Error: /boot/${kernel} doesn't exist. Use -f to override.
exit 1
pgp042fBvaYVV.pgp
Description: PGP signature
Re: rpcbind lingering on IP no longer specified on command line
On Jan 6, 2006, at 4:40 AM, James Long wrote: Yeah, I noticed that little tiny UDP requests note in the -h docs too. There's no reason to bind to all tcp addresses, and it is causing me heartburn for getting the server certified... Good grief, why not just firewall off the undesired UDP ports and call it good? I guess we could take that band-aid approach... however, how do you know what port RPC decides to listen on other than the 111 port? It is more or less random. That makes it very difficult to firewall. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with PERC4e/DC RAID?
On Jan 5, 2006, at 5:41 PM, Scott Mitchell wrote: I may be getting a new Dell PE1850 soon, to replace our ancient CVS server (still running 4-STABLE). The new machine will ideally run 6.0 and have a PERC4e/DC RAID card - the one with battery-backed cache. This is listed as I have an 1850 with the buil-in PERC 4e/Si since all I needed was the RAID1 mirror of the internal drives. It works extremely well, and the speed is quite good. As for notices of when the drives go bad, under 4.x I've had disk failures with the amr driver (different PERC cards) and not gotten any such notices in the syslog that I recall. I did find a program posted to one of the freebsd lists called 'amrstat' that I run nightly. It produces this kind of output: Drive 0:68.24 GB, RAID1 writeback,no-read-ahead,no-adaptative- io optimal If it says degraded it is time to fix a drive. You just fire up the lsi megaraid tools and find out which drive it is. If you go to the LSI download area, they have one file for FreeBSD, which is labeled the driver. In that zip file is also the management software for freebsd. You'll want that. Personally, I like the MEGAMGR software which was released for freebsd 4.x and mimics the BIOS' interface in a terminal window. The rebuild on LSI controllers is set to automatic on the dells as default. It just works as expected. Overall, I'm a big fan of the LSI cards and the amr driver... Unfortunately for me, the latest equipment I just got only takes low- profile cards, and LSI doesn't offer a dual channel RAID card in low- profile configuration... so I need to look at adaptec. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Fri, Jan 06, 2006 at 05:35:28PM +0300, Dmitry Morozovsky wrote: On Fri, 6 Jan 2006, Ceri Davies wrote: CD VK I had rpcbind running with on two interfaces like this: CD VK CD VK rpcbind -h 192.168.100.200 -h 10.0.0.9 CD VK CD VK Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, CD VK and I restarted rpcbind. the process list from ps shows it is running like CD VK this: CD VK CD VK rpcbind -h 192.168.100.200 CD VK CD VK Yet nmap on the other address shows rpcbind is still listening on udp there. CD VK How do I stop that? CD CD As I sometimes looked into this, rpcbind (formely portmap) listens on all CD described addresses via udp *and* an tcp:*.111 - I tried to dig why is this but CD did not succeed much. CD CD Please test this patch. It's probably a very naive fix, but seems to CD work OK. Well, two objections: - (obvious and dumb ;): three kinds of changes inside: behaviour, style and typo ;-))) Well yeah, but I figured that didn't matter for now. I disagree that the RUN_AS stuff is style though; the previous hardcoded daemon completely takes away the point of the '#define RUN_AS daemon'. If you are referring to my indentation, again that's just a keep the patch simple thing. Anyway... - serious: no way to run on NO_INET6 kernel: [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc 83231 ?? Ss 0:00.00 /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p program vers proto port service 104 tcp111 rpcbind 103 tcp111 rpcbind 102 tcp111 rpcbind 104 udp111 rpcbind 103 udp111 rpcbind 102 udp111 rpcbind 104 local111 rpcbind 103 local111 rpcbind 102 local111 rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# sockstat -4 | grep rpc root rpcbind83332 7 udp4 *:111 *:* root rpcbind83332 8 udp4 *:608 *:* root rpcbind83332 9 tcp4 *:111 *:* That's more annoying. It's not INET6 though; it's because the local transport is also tpi_cots_ord, so /var/run/rpcbind.sock is not getting created. I'll take another go at this over the weekend. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpXkG0Mwshuf.pgp Description: PGP signature
Re: 6.0 on Dell 1850 with DRAC4 management card?
On Jan 6, 2006, at 9:47 AM, Marian Hettwer wrote: I don't know about the DRAC with FreeBSD, but I assume that the BIOS of this Dell still supports BIOS redirection to serial port. If so, you can have Monitor and Keyboard connected locally and use the serial console remote. Just get a small console server (depending on the amount of servers you have remote), for instance an old cyclades TS. Connect them and you can get on your serial port through the console server via ssh. This is precisely what I do. The cyclades work extremely well, except for one flaw: if you power cycle them they send a BREAK signal down every serial port. So just make sure you don't have BREAK_TO_DEBUGGER enabled on your kernels and you're safe. Otherwise expect every server to break to debugger on a power cycle of your cyclade. Not that you need to ever reboot those little boxes, but you never know I've never enabled the DRAC card on any dell I have that came with them... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
Vivek Khera wrote: On Jan 6, 2006, at 9:47 AM, Marian Hettwer wrote: I don't know about the DRAC with FreeBSD, but I assume that the BIOS of this Dell still supports BIOS redirection to serial port. If so, you can have Monitor and Keyboard connected locally and use the serial console remote. Just get a small console server (depending on the amount of servers you have remote), for instance an old cyclades TS. Connect them and you can get on your serial port through the console server via ssh. This is precisely what I do. The cyclades work extremely well, except for one flaw: if you power cycle them they send a BREAK signal down every serial port. So just make sure you don't have BREAK_TO_DEBUGGER enabled on your kernels and you're safe. Otherwise expect every server to break to debugger on a power cycle of your cyclade. Not that you need to ever reboot those little boxes, but you never know How old is your Cyclades box? Since mid 2002 these boxes don't send a break when power cycled. And I know what I say, being an ex-employee of cyclades (o' course, technician). We had customers with quite a large amount of sun servers and these are usually pretty sensitive regarding breaks. Never had an issue due to power cycles... hm... consider a replacement :) The old boxes had 5 years of warranty. So, go for it ;)) I've never enabled the DRAC card on any dell I have that came with them... I'd rather stick with a good old console which I can access remotely via ssh, too. So Long, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
I've never enabled the DRAC card on any dell I have that came with them... Hmmm. The DRAC card can save you a long drive sometimes. You actually get to look at the hardware boot process and can even adjust BIOS settings if needed. To get to a FreeBSD console, I think that the OS actually needs to boot. The DRAC lets you control the server BEFORE the OS is even loaded, all through a browser interface. Ralph ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
On Jan 6, 2006, at 11:22 AM, Marian Hettwer wrote: How old is your Cyclades box? Since mid 2002 these boxes don't send a break when power cycled. And I know what I say, being an ex- employee of cyclades (o' course, technician). We had customers with quite a large amount of sun servers and these are usually pretty sensitive regarding breaks. Never had an issue due to power cycles... hm... consider a replacement :) The old boxes had 5 years of warranty. So, go for it ;)) thanks for the note. it was an original ts1000 i bought new in spring 2001. it recently died so I got a replacement for the $100 repair fee. i haven't tried a power cycle on this one: i unplugged everything before I powered it on :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
Ralph Hempel wrote: I've never enabled the DRAC card on any dell I have that came with them... Hmmm. The DRAC card can save you a long drive sometimes. You actually get to look at the hardware boot process and can even adjust BIOS settings if needed. To get to a FreeBSD console, I think that the OS actually needs to boot. The DRAC lets you control the server BEFORE the OS is even loaded, all through a browser interface. Well, you can do that too, if you enable Console Redirection to Serial Port in the BIOS. The old DELL 1550 and 1650 were definetly capable of doing so. I don't know about the 1850, but I assume they can redirect the console too. Usually the BIOS accepts VT100 or ANSI input. Of course you want to go with VT100. And from your workstation: export TERM=vt100 ssh user:[EMAIL PROTECTED] and of you go. The only thing missing would be hardware power down. if that can be done via DRAC, that'll be an advantage :) - Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Fri, 6 Jan 2006, Ceri Davies wrote: CD [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p CD rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success CD CD That's more annoying. It's not INET6 though; it's because the local CD transport is also tpi_cots_ord, so /var/run/rpcbind.sock is not getting CD created. I'll take another go at this over the weekend. Ah yes, I did not check sockets other than tcp4. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
The only thing missing would be hardware power down. if that can be done via DRAC, that'll be an advantage :) Yes, you get that too. Full hardware power down. Wait as long as you want, then power the machine up. It's not the same as a remote reboot where you HOPE the server comes up far enough to get a console session. Plus you don't need anything mote than an Ethernet connection to your existing infrastructure to make it all work. If you are paranoid and/or have a lot of servers, you can put all the DRAC ports on a separate subnet and their own VPN... Ralph ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ucom.ko and palm pilot m500
Hello List, I own an old palm pilot -- a m500 model -- and have the following problem when I try to sync under 6-STABLE. Whenever I pressed the HotSync-Button of that device -- connected to my 6-STABLE box via a USB cable, the pilot was recognized as a ugen0 device. Using the pilot-xfer program then failed. After some investigation on pilot-link.org I learned, that Palm devices work with FreeBSD over USB only with the ucom driver (while for those of Handspring, the generic ugen driver is sufficient). -- Well, I made sure, that ucom.ko was loaded, but the device was still detected by the ugen.ko-module instead. Even after unloading the generic driver, the ucom driver still wasn't able to detect the palm pilot. Just a few minutes ago, I cvsuped the kernel sources and rebuilt and installed the kernel along with the modules (and rebooted), but it still doesn't work. Am I the only one with that problem (and such an old pilot)? -- I have searched the FreeBSD documentation, pilot-link docu, etc.. but didn't find anything. Is it possible to somehow force the ucom driver to accept the pilot, or give him some hints? Thanks in advance. -- bye Carsten ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gdm problem with kernel as of 2005-01-04
I'm in at work and turned off gdm in my rc.conf and rebooted. The keyboard works fine! Then manually starting gdm and it still works. That's great. I think that something happened in the rc files that makes it start earlier and that's conflicting with something that freezes the keyboard. Richard Kuhns wrote: I just finished a buildworld/buildkernel/mergemaster on my Dell Inspiron 9300. Upon rebooting, I noticed that gdm seemed to start earlier in the boot process than it used to. When the login screen appeared, the mouse seemed to work fine, but nothing I typed appeared. Attempting to use C-A-F1 to switch to vty0 just beeped. C-A-Del worked to reboot the laptop. I booted single user, commented out gdm_enable=YES in /etc/rc.conf, and rebooted -- everything was fine. I put the gdm_enable back and ran /usr/X11R6/etc/rc.d/gdm.sh start -- gdm started, fully functional. I rebooted again -- gdm ignored the keyboard. After several reboots, I've found that gdm seems to work fine as long as I don't have 'gdm_enable=YES' in /etc/rc.conf when the machine boots. I've just finished upgrading gdm (using portmanager); still the same problem. If anyone has suggestions/wants me to try anything, just say so. Thanks! - Rich -- __ Paul T. Root /_ \ 1977 MGB / /|| \\ ||\/ || _ | || || || \ ||__// \__/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
Hej there, Ralph Hempel wrote: Yes, you get that too. Full hardware power down. Wait as long as you want, then power the machine up. It's not the same as a remote reboot where you HOPE the server comes up far enough to get a console session. Well, if the BIOS can do console redirection, the server will come up far enough ;) If I don't see a BIOS screen, although console redirection is enabled, there's something really really wrong... Plus you don't need anything mote than an Ethernet connection to your existing infrastructure to make it all work. same counts for a console server (say 48 ports, 1 U) and all servers connected to it. One IP adress, ethernet... If you are paranoid and/or have a lot of servers, you can put all the DRAC ports on a separate subnet and their own VPN... I would do that anyway... IMO an out-of-band network belongs into its own subnet (vlan) and you want to secure it in some way for remote access (ssh only, VPN, whatever) Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
nsswitch - pflog problem
Hi, I have a little (I hope) problem with my FreeBSD 6-STABLE. I had pf+pflog working fine... I added nss_ldap, pam_ldap etc. Everything worked fine, until reboot. I noticed strange message: pflogd[244]: NSSWITCH(nss_method_lookup): ldap, passwd, endpwent, not found Nevertheless everything works. After some experiments I discovered the message being triggered by /etc/nsswitch.conf: when I change passwd: files to passwd: files ldap message appears. Thanks in advance Tim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Swapfile problem in 6?
On 2 Jan, Lars Kristiansen wrote: Attempting to catch up with my backlog of unread email, only 12K unread messages to go ... On 24 Nov, Rob wrote: I have cvsup'ed the sources to STABLE as of Nov. 23rd 2005. After recompiling/installing world and debug-kernel, I again get a kernel deadlock when using swapfile: http://surfion.snu.ac.kr/~lahaye/swapfile2.txt Previous deadlocks are still documented here http://surfion.snu.ac.kr/~lahaye/swapfile.txt I hope this is of use for fixing this bug in 6. If further investigation is needed, then please let me know. This is a deadlock caused by memory exhaustion. The pagedaemon only has a limited number of bufs that it uses for writing dirty pages to swap to prevent it from saturating the I/O subsystem with large numbers of writes. In this case, pagedaemon is trying to free up memory by writing dirty pages, and it has used up all of its bufs and is waiting for the write requests to complete and the bufs the bufs to be returned to it. This isn't happening because md0 is stuck waiting for memory. This is a little bit suprising to me because it looks like writes to vnode backed devices are done synchronously by default. If you have a chance to test this again, a stack trace of md0 in the deadlock state would be interesting. I'd like to know where md0 is getting stuck. I wonder if pagedaemon should scan ahead and more agressively discard clean pages when it has run out of bufs to write dirty pages, especially in low memory situations. Preventing the creation of more dirty pages would be nice, but I don't know how to do that ... Just in case it can help. Do not have this machine available for testing at the moment but this is the last debuginfo I did get from it. Here is a trace from a situation when a possible idle system got stuck during the night and db showed only one locked vnode: db show lockedvnods Locked vnodes 0xc1309330: tag ufs, type VREG usecount 1, writecount 1, refcount 154 mountedhere 0 flags () v_object 0xc12cb39c ref 0 pages 606 lock type ufs: EXCL (count 1) by thread 0xc126b900 (pid 178) ino 8155, on dev ad0s1f db trace 178 Tracing pid 178 tid 100058 td 0xc126b900 sched_switch(c126b900,0,1) at 0xc066a4db = sched_switch+0x17b mi_switch(1,0) at 0xc065f49e = mi_switch+0x27e sleepq_switch(c09b2a98,c484bacc,c065f0e3,c09b2a98,0) at 0xc0677f00 = sleepq_switch+0xe0 sleepq_wait(c09b2a98,0,0,c08ad92d,37b) at 0xc0678100 = sleepq_wait+0x30 msleep(c09b2a98,c09b2d00,244,c08adb6a,0) at 0xc065f0e3 = msleep+0x333 vm_wait(c12cb39c,0,c08990f3,ad7,c06512a4) at 0xc07c6a71 = vm_wait+0x91 allocbuf(c28fa9d8,4000,354000,0,354000) at 0xc06a2f89 = allocbuf+0x4e9 getblk(c1309330,d5,0,4000,0) at 0xc06a29cb = getblk+0x4eb cluster_read(c1309330,1000,0,d5,0) at 0xc06a5d65 = cluster_read+0xe5 ffs_read(c484bc9c) at 0xc07a631f = ffs_read+0x28f VOP_READ_APV(c09309a0,c484bc9c) at 0xc0838aab = VOP_READ_APV+0x7b mdstart_vnode(c1310800,c1634294,c1310820,1,c0566e10) at 0xc056688c = mdstart_vnode+0xec md_kthread(c1310800,c484bd38,c1310800,c0566e10,0) at 0xc0566f7f = md_kthread+0x16f fork_exit(c0566e10,c1310800,c484bd38) at 0xc0645618 = fork_exit+0xa8 fork_trampoline() at 0xc0816f3c = fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc484bd6c, ebp = 0 --- The md thread is stuck waiting for memory to be freed by pagedaemon. Pagedaemon is stuck waiting for at least one of its pageout requests to complete. The pageout requests are probably all stuck waiting for md. I had expected that the problem is that while pagedaemon is allowed to dig deeper into the free page pool, I didn't think that the md thread would be allowed to, allowing the md thread to get wedged first. That does not appear to be the case because the vm_page_alloc() call in allocbuf() has the VM_ALLOC_SYSTEM flag set, which should match vm_page_alloc()'s treatment of requests by pagedaemon. I don't see how the md thread could be consuming a large number of reserved pages, but it looks like that must be what is happening. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
On Fri, Jan 06, 2006 at 05:32:54PM +0100, Marian Hettwer wrote: The only thing missing would be hardware power down. if that can be done via DRAC, that'll be an advantage :) One big advantage of the DRAC is virtual media (floppy, CD) support. Good for BIOS/firmware upgrades, booting a rescue/repair CD, or even reinstalling the OS. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ucom.ko and palm pilot m500
Carsten CC Wald wrote to freebsd-stable@freebsd.org on Fri, 6 Jan 2006 16:43:15 +: CCW I own an old palm pilot -- a m500 model -- and have the following CCW problem when I try to sync under 6-STABLE. CCW Whenever I pressed the HotSync-Button of that device -- connected to my CCW 6-STABLE box via a USB cable, the pilot was recognized as a ugen0 CCW device. man uvisor -- With best regards, Gleb Kozyrev. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel)
Vivek Khera wrote: On Jan 5, 2006, at 11:08 PM, Chuck Swiger wrote: There's an interesting thread about the AMR RAID controller used in the newer 18x0/28x0 Dells with the PERC/4 controller, and I know of enough people using them that such improvements (by Doug Ambrisko?) will be welcomed. Thanks for your note. Turns out I have more than one Dell system with aac controllers in them :-) They seem to be OK, although I like the AMR's a little better. I had to update the RAID BIOS on the PE 2650 before auto-rebuild of a broken mirror would work right using the aac controller. (It's either rackrounted Dells or HP 370/380 Proliants for me, depending upon the specific client in question.) One happens to be a PE 1750 with the PERC 3/Di in it running RAID1. It is lightly loaded but is sufficient for that server's needs, but is running FreeBSD 4.11 on it. Is there a way to backport this diskinfo utility to 4.x or 5.x? Looks most useful! On my 6.0 box with a PERC 3/Si card (aac driver too) it is showing seek times slower than yours but transfer rates faster. diskinfo runs on 5.x, at least. I'm not sure about 4.x; I think some of the underlying infrastructure which smarttools also depends upon wasn't available until 5.x... -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with PERC4e/DC RAID?
On Jan 5, 2006, at 9:21 PM, Michael Vince wrote: Items 3 and 4 significantly increase the performance of the driver. On an LSI 320-2X card, transactions per second went from 13,000 to 31,000 in my testing with these changes. However, these changes are still fairly experimental and shouldn't be merged to 6.x until there is more testing. Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing towards this. Damn that's awesome! Thanks to all who helped with this... This will be great for some of my servers. Now, does anyone have any numbers to compare this with other RAID cards? Particularly the 2230SLP? :-) /me wishes LSI maid low profile dual channel cards... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ucom.ko and palm pilot m500
On Friday 06 January 2006 17:51, Gleb Kozyrev wrote: man uvisor Great! Thank you. That's what I needed! -- uvisor.ko apparently uses ucom.ko and the ucom0 device I looked for is (temporarily) created. However, after pressing the sync button the pilot can then be accessed through the /dev/ttyU0 device. Since I didn't find this information at kpilot.org or pilot-link.org or whatsoever (although they oftern refer to FreeBSD) and somebody else might have the same problem ... here is what I did: 1. Load the proper kernel modules. Among others this is uvisor.ko. $ kldload /boot/kernel/uvisor.ko (In addition, I configured this in /boot/loader.conf) 2. Configure /etc/usbd.conf in such a way, that the permissions of the proper device will be set when it appears after pressing the HotSync button. This is /dev/ttyU0 in my case. I just synced as a normal user and it works. -- bye Carsten ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.0 hangs at boot on Toshiba laptop
Hi everybody, I tried to install on my laptop (Toshiba M60-176) FreeBSD 6.0 STABLE and it failed despite careful installation and web/archives search. It is a multiboot installation (Windows XP/Linux Ubuntu/FreeBSD) driven by GRUB 4.95. After the whole installation process ended, the reboot is performed and the bootstrap goes until the FreeBSD menu is displayed. Whatever the chosen option (default, without ACPI, fail-safe, verbose, etc.) the system hangs immediately. For example with the first choice, we have : /boot/kernel/acpi.ko/boot/kernel/acpi.ko text=0x40c2c data=0x2160+0x1090 [..] and everything stops. The situation is explained very clearly here : http://marc.theaimsgroup.com/?l=freebsd-mobilem=113177565322135w=2 I do not think it is related to GRUB (the real boot has started, this version allows for UFS2 access, various GRUB settings have been tried, unsucessfully) nor to ACPI since even when disabled, thanks to the relevant menu option, the boot hangs as well (same behaviour, without the ACPI module line being displayed). I cannot disable Legacy USB in my BIOS, if ever it was a common workaround. If it can help, I detailed my full installation process here : http://osdl.sourceforge.net/OSDL/OSDL-0.3/src/doc/web/main/documentation/misc/Toshiba.html#freebsd (by the way, there seems to be a bug when aborting/restarting under sysinstall : apparently in some cases it tries to install FreeBSD on the ramdisk instead of the requested slice). Thanks in advance for any hint, kind regards, Olivier. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
asr-util Not work after upgrade to 5.4
Dear all: As I upgraded to 5.4 I found the raid utilities 'asr-util' no longer work for me. I tried to deinstall and install again, but the problem still ! The error message in the console after the comman 'raidutil -L raid' is : Engine connect failed: COMPATILITY number Any one know now to solve it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ucom.ko and palm pilot m500
On Friday 06 January 2006 01:56 pm, Carsten Wald wrote: On Friday 06 January 2006 17:51, Gleb Kozyrev wrote: man uvisor Great! Thank you. That's what I needed! -- uvisor.ko apparently uses ucom.ko and the ucom0 device I looked for is (temporarily) created. However, after pressing the sync button the pilot can then be accessed through the /dev/ttyU0 device. Since I didn't find this information at kpilot.org or pilot-link.org or whatsoever (although they oftern refer to FreeBSD) and somebody else might have the same problem ... here is what I did: 1. Load the proper kernel modules. Among others this is uvisor.ko. $ kldload /boot/kernel/uvisor.ko (In addition, I configured this in /boot/loader.conf) 2. Configure /etc/usbd.conf in such a way, that the permissions of the proper device will be set when it appears after pressing the HotSync button. This is /dev/ttyU0 in my case. I just synced as a normal user and it works. You shouldn't be using usbd/usbd.conf as it is going away (It's already gone in CURRENT). You should configure it using devd/devd.conf instead. -- Anish Mistry pgpakgSIHZSNx.pgp Description: PGP signature
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Fri, 2006-Jan-06 02:34:40 -0800, Jo Rhett wrote:
On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote:
While I agree with much of your reasoning, I know exactly zero
people running a modified kernel of any version of Windows,
Mac OS X or Solaris, to name just three commercial OS's.
You're tickling a different subject here. All three of these operating
systems have loadable kernel modules that work.
As does FreeBSD.
I mean, they dynamically
load the modules they need, and you can disable kernel modules in
configuration files. FreeBSD has loadable kernel modules, but they don't
autoload (you have to modify rc files)
This isn't quite true. FreeBSD does not currently have the tools to
automatically load kernel modules for most hardware device drivers and
they need to either be built into the kernel or specified in
loader.conf. Writing a tool to do this automatically would be fairly
simple - either use pciconf(8) and a database of PCI ID to driver
mappings or (as Solaris and X do) load every module and see if it can
attach to anything, unload it if it can't. To date, no-one has been
sufficiently motivated to do so.
FreeBSD will autoload kernel modules for many software functions if
their functionality is required (NFS, SysV IPC, firewalls). In some
cases this is automatic (NFS client loads automatically if NFS
filesystems are found). In other cases, (eg firewalls) you need to
configure the functionality anyway.
and you can't trim down the kernel
to minimize unused memory without recompiling.
In the absence of tools to automatically detect your configuration and
load the appropriate modules, GENERIC includes a fairly standard set
of drivers that also exist as modules. GENERIC probably could be cut
down somewhat but this isn't the forum to discuss that.
To give you a specific example: if we could remove NFS and the 3ware
driver from the kernel in a configuration file, we could probably run
GENERIC.
IMHO, NFS server could be removed without problems (it will autoload),
as could tw{a,e} (which are loadable). NFS client can't be removed
because it has to be built in to support diskless operation.
hog we have to remove on small footprint systems
FreeBSD has never claimed to optimally support small footprint systems
without customisation. There are too many variables and some kernel
functionality can't be readily converted to modules (eg IPv6 support).
In any case, the way to minimise the kernel footprint is to statically
load all the required functionality and not have any modules.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Jo Rhett wrote this message on Fri, Jan 06, 2006 at 03:03 -0800: On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote: I believe core has a policy of never supporting vaporware... There is always the chicken and egg problem with arguments like this... I'll code this if you agree to support it and maintain it/I will agree to support it once you code it... In FreeBSD, and many open source projects, no code, no support, how can you support or even agree to support something that doesn't exist? And then as soon as FreeBSD agrees to support something that doesn't exist, either a) other people who were interested in the project stop, even if you end up never producing a bit of code, or b) someone else produces better code, drops the support for the original, but then the author complains about being told they'd support his code, and going with another code base... Bottom line: Once code exists, then support can be talked about.. This is the chicken and egg problem that will kill FreeBSD. I don't And many other open source software projects... FreeBSD isn't unique in this.. I've submitted patches to many other projects just to have them ignored for years too... It's a problem of voluteer orginizations.. bother writing up patches for FreeBSD because every time I do they sit in a PR and get ignored for several years. Then someone that does have commit rights makes their own patch (which often is less useful) but they own it and the best I've ever succeeded at was convincing them to put some of the ideas from my patch into their code. Note that none of these patches were ever rejected for any technical or political or any other reason. They just don't get paid attention to. Thus, I try to get consensus that the idea has merit. IF freebsd committers can be bothered to pay attention to the idea, I'll write code for it. But I'm too old and tired to spend another week writing up something that will get ignored for X years and then dropped for obsoletion again. You're trying to target to large of an audience... You need to get _A_ committer interested in your work, and get HIM to guide you and commit your work... AND there are a lot of opinions and politics around how to version the core that have nothing to do with code. There's no value in writing code that will be ignored because it doesn't agree with -core's view of should be. I'm a coder, not a politician. If we can get consensus on what type of implementation would be acceptable to core, then I and many others would be happy to write code to implement this idea. But this is a considerable amount of work that will be closely tied to the operation system installation. It's not something that you can churn out 7 different implementations of just to see which one fits the current polical environment. stop talking about core... -core makes absolutely no technical decisions about how FreeBSD is.. it is the developers, and previously there was a technical review board for settling differences between developers that were pure technical in nature... And if you claim you didn't know this, then you better read the email you respond to more closely, since this has been pointed out to you numerous times.. and you said in another email: First, this is obvious and true for all open source projects. But no, FreeBSD _never_ advances because someone writes code that does something well. FreeBSD _only_ advances when the core developers agree that this thing is worthy of their interest. hmmm... you really are choosing to completely ignore what people have said about core, that at least you did add developers after core, which makes it appear less likely that you're talking about -core.. but lots of stuff gets done w/o core developers... I did lots of work on -sparc64, and I'm pretty sure you wouldn't call me a core developer.. and I also got TS-7200 arm support (though it hasn't been committed to cvs due to issues that I haven't resolved with device configuration)... As for the whole installation thing, you need to talk with re (release engineering) as they are the ones to really have final say in what installation and releases look like... Back to your finale: Bottom line: Once code exists, then support can be talked about.. This is bullhockey and you know it. Once the project is done, we'll authorize a budget for it? Once the season is over we'll know who should FreeBSD isn't commercial, so you can't talk about budgets... And most orgs want some sort of prototypes and feasibility study done before they'll commit any budget to it... be on the starting team? Yeah, hindsight is sweet. But this isn't a simple change. It will require very close integration with the installation and kernel modules at least (and probably more). So having some sort of consensus that (a) the project has interest and (b) what flavors would be acceptable to the existing groups
Motherboard
Hi all! I'm setting up a new server with FreeBSD 6.0. The motherboard I am planning to use is Asus A8N-SLI Premium. Does anyone know if the on- board ethernet controller (nve(4)) works? Also I'm planning on getting this graphics controller: Gainward GeForce 6200 TurboCache, PCI-Express. Sincerely, Øystein Holmen___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Motherboard
Øystein Holmen wrote on Fri, Jan 06, 2006 at 11:03:18PM +0100: Hi all! I'm setting up a new server with FreeBSD 6.0. The motherboard I am planning to use is Asus A8N-SLI Premium. Does anyone know if the on- board ethernet controller (nve(4)) works? Works for me with the newest 7-current commits, but losing carrier means temporary machine hang. The other GbE on the board works, too. Temperature monitoring is also functional. Be warned that this board even with the newest BIOS does not correctly do remapping of the physical memory between 3-4 GB to above 4 GB. Also I'm planning on getting this graphics controller: Gainward GeForce 6200 TurboCache, PCI-Express. Works for me, nv driver. No nvidia driver for FreeBSD/AMD64. Martin -- %%% Martin Cracauer cracauer@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with PERC4e/DC RAID?
On Fri, Jan 06, 2006 at 10:35:46AM -0500, Vivek Khera wrote: On Jan 5, 2006, at 5:41 PM, Scott Mitchell wrote: I may be getting a new Dell PE1850 soon, to replace our ancient CVS server (still running 4-STABLE). The new machine will ideally run 6.0 and have a PERC4e/DC RAID card - the one with battery-backed cache. This is listed as I have an 1850 with the buil-in PERC 4e/Si since all I needed was the RAID1 mirror of the internal drives. It works extremely well, and the speed is quite good. We'll only be mirroring the internal drives too for now - the 4e/DC seems to be the only RAID option on the 1850 with battery-backed cache, and doesn't cost much more for the extra peace-of-mind. As for notices of when the drives go bad, under 4.x I've had disk failures with the amr driver (different PERC cards) and not gotten any such notices in the syslog that I recall. That's a pity. Maybe Doug was thinking of one of the aac(4) based PERC cards? Still, something I can run out of cron to check the array status should be fine. I did find a program posted to one of the freebsd lists called 'amrstat' that I run nightly. It produces this kind of output: Drive 0:68.24 GB, RAID1 writeback,no-read-ahead,no-adaptative- io optimal If it says degraded it is time to fix a drive. You just fire up the lsi megaraid tools and find out which drive it is. If you go to the LSI download area, they have one file for FreeBSD, which is labeled the driver. In that zip file is also the management software for freebsd. You'll want that. Personally, I like the MEGAMGR software which was released for freebsd 4.x and mimics the BIOS' interface in a terminal window. There's a port of the management software now: sysutils/megarc The rebuild on LSI controllers is set to automatic on the dells as default. It just works as expected. Cool. Overall, I'm a big fan of the LSI cards and the amr driver... Unfortunately for me, the latest equipment I just got only takes low- profile cards, and LSI doesn't offer a dual channel RAID card in low- profile configuration... so I need to look at adaptec. This is on your x4100? Nice machine. We have a v20z with dual Opteron 270s that I totally love. Looking at getting an x4100 too... sadly these are product development machines so they'll be running RedHat and Solaris. Doesn't the x4100 have h/w RAID built in? Or does that not work with FreeBSD? Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with DRAC4 management card?
On Fri, Jan 06, 2006 at 05:22:04PM +0100, Marian Hettwer wrote: Vivek Khera wrote: On Jan 6, 2006, at 9:47 AM, Marian Hettwer wrote: I don't know about the DRAC with FreeBSD, but I assume that the BIOS of this Dell still supports BIOS redirection to serial port. If so, you can have Monitor and Keyboard connected locally and use the serial console remote. Just get a small console server (depending on the amount of servers you have remote), for instance an old cyclades TS. Connect them and you can get on your serial port through the console server via ssh. Thanks all for the replies - this is good stuff. I have been thinking about something like that - we have a bunch of old Sun boxes with their serial ports chained together for console access, would be nice to have that done properly. On the other hand the Windows guys seem to really like the DRAC cards on the Dells they look after. I've never enabled the DRAC card on any dell I have that came with them... I'd rather stick with a good old console which I can access remotely via ssh, too. I agree that is the best way. Sun have got this right on their Opteron servers: Ethernet port for the management board, ssh access into that then just start a console session. Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /boot/nextboot.conf not deactivated after one boot
On Fri, 6 Jan 2006 15:14:41 + Ceri Davies [EMAIL PROTECTED] wrote: On Thu, Jan 05, 2006 at 01:41:33PM +0100, Marius Nuennerich wrote: Hi folks, it seems like /boot/nextboot.conf is neither deleted nor nextboot_enable set to NO on the first line after a reboot. So it isn't a one shot anymore as the manpage claims. System is 6.0-RELEASE. I think this is down to a typo in /etc/rc.d/root; at least I can't find any other reference to /boot/nextkernel in src/. Patch attached (root.diff). It would also be fine imo, if the -k option would be optional and the next kernel defaults to kernel. I'm not sure if getopts can be persuaded to take an optional argument to an option. If not, the attached patch (nextboot.diff) should work for you. I tested both patches and they work as they should. Please commit :) Thanks Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.0] Snapshot removes acls flag from fs.
David Malone wrote: On Fri, Jan 06, 2006 at 10:50:57AM +0100, V??clav Haisman wrote: When I make snapshot of fs it removes acls flag from mount. While the command is mount -u -o snapshot etc. I don't think it should remove the flag because it is not specified besides the snapshot option. You probably want something like: mount -u -o cur,snapshot ... See the current and fstab options in the mount man page. An easier way to do this would be to use the mksnap_ffs command, which should preserve the old options. David. Hmmm, I use the sysutils/snapshot port that allows to automates this through periodic.conf... I guess I should rather complain to them then. VH signature.asc Description: OpenPGP digital signature
Re: asr-util Not work after upgrade to 5.4
Paul.LKW wrote: As I upgraded to 5.4 I found the raid utilities 'asr-util' no longer work for me. I tried to deinstall and install again, but the problem still ! The error message in the console after the comman 'raidutil -L raid' is : Engine connect failed: COMPATILITY number Any one know now to solve it. Add 'options ASR_COMPAT' to your kernel config and compile a new kernel. This is listed in /sys/i386/conf/NOTES but didn't make it into the release notes. -Jonathan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on Dell 1850 with PERC4e/DC RAID?
On Jan 6, 2006, at 6:38 PM, Scott Mitchell wrote: We'll only be mirroring the internal drives too for now - the 4e/DC seems to be the only RAID option on the 1850 with battery-backed cache, and doesn't cost much more for the extra peace-of-mind. Then you'll be pleasantly surprised to know that the 4e/Si has a battery too. I certainly was... and it even has 256MB of cache RAM. Quite the bargain! I'll send you screen shots of the config menus in private email. Unfortunately for me, the latest equipment I just got only takes low- profile cards, and LSI doesn't offer a dual channel RAID card in low- profile configuration... so I need to look at adaptec. This is on your x4100? Nice machine. We have a v20z with dual Opteron 270s that I totally love. Looking at getting an x4100 too... sadly these are product development machines so they'll be running RedHat and Solaris. Doesn't the x4100 have h/w RAID built in? Or does that not work with FreeBSD? Yes, this is the X4100. It only has room for two low-profile PCI-X cards, which the 320-2X certainly is not. Curiously, LSI has on their web site some big announcements about some deals with Sun to use their products, so one would hope they would have a low-profile high-end card. Currently they only have a low-end card that is low profile. I'm biting the bullet and getting an Adaptec 2230 low profile card. I hope it is fast. if not, then back to the drawing board... sigh. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.0] Snapshot removes acls flag from fs.
David Malone wrote: On Fri, Jan 06, 2006 at 10:50:57AM +0100, V??clav Haisman wrote: When I make snapshot of fs it removes acls flag from mount. While the command is mount -u -o snapshot etc. I don't think it should remove the flag because it is not specified besides the snapshot option. You probably want something like: mount -u -o cur,snapshot ... See the current and fstab options in the mount man page. An easier way to do this would be to use the mksnap_ffs command, which should preserve the old options. David. Hmmm, I use the sysutils/snapshot port that allows to automates this through periodic.conf... I guess I should rather complain to them then. And as a workaround you could remount immediately after taking a snapshot. Example command in crontab if you want to use the options from fstab: /usr/local/sbin/periodic-snapshot daily ; mount -a -u -o fstab -t nomfs -- Lars VH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpcbind lingering on IP no longer specified on command line
On Fri, Jan 06, 2006 at 10:22:43AM -0500, Vivek Khera wrote: On Jan 6, 2006, at 4:40 AM, James Long wrote: Yeah, I noticed that little tiny UDP requests note in the -h docs too. There's no reason to bind to all tcp addresses, and it is causing me heartburn for getting the server certified... Good grief, why not just firewall off the undesired UDP ports and call it good? I guess we could take that band-aid approach... however, how do you know what port RPC decides to listen on other than the 111 port? It is more or less random. That makes it very difficult to firewall. P-shaw. If you're enduring heartburn for getting the server certified then firewall off the rpcbind service from unwanted IPs and voila, you get your get your server certified and business goes on. Then you'll have the luxury of time to debug the true problem with rpcbind, and your testing is done behind the privacy of your firewall. As far as unpredictable listening ports opened by rpc, that is exactly why a secure firewall opens only selected ports on selected IPs, and blocks everything else. It doesn't matter if it listens on port X of IP y when your firewall doesn't permit incoming connections on that port and IP in the first place. Jim # sockstat | grep rpcbind root rpcbind11382 5 stream /var/run/rpcbind.sock root rpcbind11382 6 dgram - /var/run/logpriv root rpcbind11382 7 udp4 127.0.0.1:111 *:* root rpcbind11382 8 udp4 192.168.100.200:111 *:* root rpcbind11382 9 udp4 *:664 *:* root rpcbind11382 10 tcp4 *:111 *:* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: vm_object_backing_scan: object mismatch
I just upgraded to RELENG_6 from 6.0 and after running for about a day I got the following panic: Jan 6 21:37:47 bigguy kernel: pid 30546 (gaim), uid 1001 inumber 10313 on /var: filesystem full panic: vm_object_backing_scan: object mismatch KDB: enter: panic [thread pid 22780 tid 100175 ] Stopped at kdb_enter+0x32: leave db bt Tracing pid 22780 tid 100175 td 0xc8119300 kdb_enter(c06a50b0,c06f9460,c06b9bcd,e9a30978,c8119300) at kdb_enter+0x32 panic(c06b9bcd,0,c06b99b4,604,0) at panic+0x14c vm_object_backing_scan(c7d7dad4,0,c06b99b4,63b,0) at vm_object_backing_scan+0x4e c vm_object_collapse(c9923630,0,c06b99b4,214,c7d7dad4) at vm_object_collapse+0x1b4 vm_object_deallocate(c7d7dad4,0,c06b906f,89e,0) at vm_object_deallocate+0x351 vm_map_delete(c7d16e10,0,bfc0,c7d16e10,0) at vm_map_delete+0x29d vm_map_remove(c7d16e10,0,bfc0,c8119300,e9a30a9c) at vm_map_remove+0x55 exec_new_vmspace(e9a30bf0,c06eeec0,2ec,0,0) at exec_new_vmspace+0x243 exec_elf32_imgact(e9a30bf0,0,c06a2586,149,43) at exec_elf32_imgact+0x1bd kern_execve(c8119300,e9a30ca8,0,807b94c,807a000) at kern_execve+0x417 execve(c8119300,e9a30d04,c,41d,3) at execve+0x67 syscall(3b,3b,3b,1,0) at syscall+0x13d Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (59, FreeBSD ELF32, execve), eip = 0x805571f, esp = 0xbfbfd9bc, ebp = 0xbfbfd9d8 --- The trace with ps output is here: http://am-productions.biz/docs/bigguy-vm-panic.txt -- Anish Mistry pgpLCiRbKe2MK.pgp Description: PGP signature
