Re: HEADS UP: Release schedule for 2006
On Fri, Dec 23, 2005 at 01:13:20PM -0600, Mark Linimon wrote: On Thu, Dec 22, 2005 at 01:10:19PM -0800, Jo Rhett wrote: I and many others have offered to work on this. The core team has repeatedly stated that they won't integrate the efforts Please provide hard evidence for this assertion. Merely repeating it will not be sufficiently convincing. I would like to see _specific_ references (email or other documentation) that that is _exactly_ what core, or anyone else, has said. I cannot recall any such thing on any of the mailing lists that I have monitored for the past several years. Without that, my high degree of skepticism about this claim will remain. Sorry for the late reply. I saw this and realized that not only will we apparently need to rehash the ball-busting thread giant topic again, but now I need to prove it ever existed giggle Ugh. Yeah, I'll do the research sometime early next week. Mostly to find archives with useful threading so that you can read all the way down the trafic tree. -- 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: HEADS UP: Release schedule for 2006
On Fri, Dec 23, 2005 at 03:38:20PM +1100, Peter Jeremy wrote: I agree with Brooks. I don't recall ever seeing a message from -core (or anyone else talking on behalf of the Project) stating that code to make binary updates possible would not be integrated. For that matter, I don't recall ever seeing code offered to implement such a feature. As stated before, let me find some threaded archives and I'll find the relevant topics. Perhaps it wasn't -core that vetoed it, but it was harshly fought against for ivory tower reasons, and nobody from -core ever stood up to show interest. Core OS packages have been discussed but I don't recall the idea ever being vetoed. Some work have been done in breaking bits of the base OS out into packages (perl, games and UUCP come to mind) but packaging the entire system is a major undertaking. In any case, I don't see how packaging the system would help you. Taking Solaris as an example of an OS which is broken up into lots of packages, patches don't replace whole packages, they replace individual files. Obviously the details need to be ironed out. The current freebsd package system is certainly missing a few key features (in my mind) but most everyone agrees on the basics. Packaged cores allow identification of what you have. Package databases can store what you have changed. Package databases can store how to back out the change. This is pretty much the only things that prevent freebsd-update from working perfectly in production environments, to name the most obvious candidate for adapting to this job. -- 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 Thu, Dec 22, 2005 at 09:08:13PM -0600, Matthew D. Fuller wrote: Having done full OS upgrades a number of times, I can't remember the last time it took more than 5 or 10 minutes (during most of which the When the servers are in 17 countries around the world, with no CD-ROM access. You keep missing the point about not your home computer. Back to the point, the comments aren't bad. Your idea that binary operating system upgrades from ISO are easier demonstrates that you're talking about home computers, not production servers. Oh, no. Heck, I find that upgrades from SOURCE are easier. In fact, just last month I bought my first CD burner, so it wasn't until a few weeks ago that I even burned my first ISO (and that, just to test the burner and figure out how to do it), and I've never booted or installed off one. For small groups of servers, I NFS mount installworlds, and for larger groups, I rdist out binaries. But it always comes from source. You can't do source installations on flash-based systems. You can't do NFS across the Internet (we don't even have RPC working at all on production systems) -- 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 Thu, Dec 22, 2005 at 01:09:04PM -0800 I heard the voice of Jo Rhett, and lo! it spake thus: No, you're missing the point. More core OS upgrades means less incremental patches (which are easier to apply than a full update). On Thu, Dec 22, 2005 at 09:08:13PM -0600, Matthew D. Fuller wrote: Right. I don't understand how B follows A here. These patches come from where? Security advisories, mailing list discussions, and eating too much beef right before bed and waking up at 2am with brilliant ideas? Why would there be less of them, just because RELENG_X_Y_RELEASE tags are laid down more often? FreeBSD provides patches for two major OS revisions, right? If you have more OS revisions in less time, then you have a smaller window of support time. Simple. -- 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, Dec 23, 2005 at 11:36:11AM +1030, Daniel O'Connor wrote: On each 'client' PC.. NFS mount /usr/src and /usr/obj installkernel reboot installworld Works fine on home computers behind firewalls. Useless on public servers that don't run RPC. Useless on flash-based servers where minimizing writes is necessary. (mergemaster does far far far too many writes) You are putting words in the mouth of core@ - Sorry. As said before, the topic is always struck down and nobody from core has ever stood up to say we'll support this. I don't know whose on core this week, nor will I at any given time. I just know that core has either struck it down or been Silent. I find it very hard to believe that core would suggest someone NOT implement a good framework for doing full binary upgrades via the network. A good binary update mechanism shouldn't be just the network. Updates from flash devices, ISO images, etc should all work much the same way. Unless you mean core@ said they would not support packaging the base which is different. People have clearly identified the problems that prevent a useful binary update mechanism from working, and what they need from core. Some have asked for core packages, others have other ideas, and some have said anything that gives me versioning ability and For binary upgrades without booting from CD-ROM to be possible, we need versioning of some sort at the OS level. Core OS packages are the most This is not true - I don't see it as being mandatory to be able to apply binary updates. (Case in point - freebsd-update works fine without it) freebsd-update works fine if you run GENERIC with no build options. Back to useful for home computers. freebsd-update is hampered by the exact problems I'm listing here. Difficulty determining what I have, no method to store what I did and no effective backout mechanism to speak of. Nobody that I know cares whether or not the solution manifests as core os packages, but some sort of core versioning ability has to be developed and supported by the core. popular suggestion, but not the only path. Every year this topic comes up and gets struck down again. Yes, because a) it isn't necessary, b) it may not solve the problem, c) there are no patches to evaluate. I think the people suggesting it see it as a panacea to fix their problems but haven't fully evaluated it. You're arguing my own points. Again, nobody (that I know) cares that it manifests as core OS packages. Certainly the existing package system used for ports wouldn't work as-is for this task. But the have/did/undo problems remain to be solved. -- 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 )
Patrick M. Hausen, and lo! it spake thus:
Any suggestions for an alternative to NFS if your 'client' servers
are located all over the world and you want to installworld across
the Internet? I was planning to use NFS/TCP secured by IPSec
transport mode, but anything less complicated would be greatly
appreciated ;-)
On Fri, Dec 23, 2005 at 02:56:57AM -0600, Matthew D. Fuller wrote:
This is one of the situations where r{dist,sync}'ing out the binaries
makes more sense than NFS mounting and running installworld (which
would be awful awful slow, above and beyond security and convenience
issues).
This works fine for small patches (ie cvs patch last year). How do you
handle configuration changes/comparisons? (ie mergemaster stuff?)
--
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 Fri, 23 Dec 2005 07:47, Jo Rhett wrote: But FreeBSD Update suffers from all of the same limitations that I've been describing because of lack of integration with the Core OS. 1. modified kernels are foobar ..yet are practically mandatory on production systems 2. modified sources are foobar ..yet many common production situations require source compilation options 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. 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. Not having run jails I am not very qualified to comment Exactly. Sorry, not trying to be rude but if you have never felt the pain don't try and say it doesn't exist. -- 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, 2005-Dec-22 13:17:30 -0800, Jo Rhett wrote: But FreeBSD Update suffers from all of the same limitations that I've been describing because of lack of integration with the Core OS. 1. modified kernels are foobar ..yet are practically mandatory on production systems 2. modified sources are foobar ..yet many common production situations require source compilation options On Fri, Dec 23, 2005 at 03:56:48PM +1100, Peter Jeremy wrote: So you want to be able to make arbitrary changes you your source code and compilation options and then expect the FreeBSD project to provide a tool that will apply binary fixes to the resultant executables? 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. If the core OS supported the necessary features for handling patches to the core, then we could stop building all these tools ourselves and focus on real work. I don't know that modified kernels are mandatory. A lot of work has been going on to reduce the need to re-compile the kernel for common situations. Likewise, I don't know that many common and require go together - IMHO, 'desire' or 'would be nice' are more appropriate descriptions. Would you care to provide some details of what you believe can be done to reduce your need to re-compile the OS. It's not a recompile issue. It's a tracking/update/backout issue. I don't mind recompiling, if I could somehow push the updates to all the right systems and they would have it stored somewhere that they were patched... I'm not sure that FreeBSD Update is totally unusable for you. If you have the situation where you have a modified FreeBSD that you need to roll out to a large number of hosts, you just need to have your own FreeBSD Update server - you test the changes in your environment and then roll them out as you require. I've looked it over, and our current mechanism works better than freebsd-update at the moment. Always subject to change. I don't run jails so I'm not familiar with the problems here. Maybe you'd like to explain the problems you run into. It's really just the same problem. Some mechanism to find out what is, and store what has been done. -- 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]
Hello! 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. 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. 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. 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 ... Just some thoughts, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ 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, 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. 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. Not having run jails I am not very qualified to comment Exactly. Sorry, not trying to be rude but if you have never felt the pain don't try and say it doesn't exist. Just because I don't run jails doesn't mean I don't know the pain of upgrading a system. -- 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 pgpGpPXTPTxIl.pgp Description: PGP signature
Re: rpcbind lingering on IP no longer specified on command line
On Wed, 2006-01-04 at 15:44 -0500, Vivek Khera wrote: On Jan 4, 2006, at 2:41 PM, Doug Barton wrote: What does 'sockstat | grep rpcbind' tell you? # 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 *:* As Dmitry Morozovsky points out, it seems it always listens to tcp *: 111 which seems to be a bad thing. I'm running 6.0-RELEASE-p1. This came up because of some security scans we're having run for some compliance certificates we need... 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. Gavin ___ 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, 2006-Jan-05 01:37:27 -0800, Jo Rhett 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.
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
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. How would you like
to write a formal requirements specification and post it here (or in
-arch).
It's not a recompile issue. It's a tracking/update/backout issue. I don't
mind recompiling, if I could somehow push the updates to all the right
systems and they would have it stored somewhere that they were patched...
Have you looked at tools like Bcfg2 ( http://www.mcs.anl.gov/cobalt/bcfg2/ )?
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Postfix and faststart
Hi: after the last cvsup, my FreeBSD 6.0, i386 is not capable to start postfix. I'm using the link in the /usr/local/etc/rc.d/postfix.sh to start the postfix program. Looking in the code, I saw that we need to change this in a file in /usr/local/etc/postfix/postfix-script to have the faststart flag.. Someone else find this problem? -- Paniago -- Carlos F. A. Paniago[EMAIL PROTECTED] http://www.cnptia.embrapa.br/ Fone: +55 (19) 3789-5815 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
keyboard failing on Dell laptop with 6.0-Stable this week.
I have an old Dell Inspiron 5000 (800MHz, 512M RAM), that I've been running 6.0 since it was released. It was running great with -Stable cvsupped around Dec 18th or so. Tuesday, I saw that a problem with NFS locking was fixed, and I was having an nfs/amd problem on a desktop Vectra, so I cvsupped both machines and did a buildworld, etc. The Vectra had no problem. I'm not sure if the NFS issue is solved, I haven't had opportunity to be on that machine this week. Anyway, after coming up in full user mode, the keyboard is locked up on the Dell. I searched the archives and it seems that 5.4-S has some problems in this regard and that devd is the culprit. I commented out the 8-10 lines in devd.conf that have ukbd0 in them. But that didn't help at all. I tried turning off devd, big mistake, the network didn't come up then. Makes sense. I tried coming up without DBUS, as that was the last thing I'd done before the holiday's on the machine. No help. I have a usb keyboard at home, but this machine is at work, and I forgot it over night. Anybody have any other ideas. Oh, I had a custom kernel, also tried the GENERIC kernel and the old kernel. I re-cvsupped on Wednesday and built again. Thanks, Paul. -- __ 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: rpcbind lingering on IP no longer specified on command line
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... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recurring problem: processes block accessing UFS file system
Hi! Greg == Greg Rivers [EMAIL PROTECTED] writes: Greg It's taken more than a month, but the problem has recurred Greg without snapshots ever having been run. I've got a good trace I think that I have the same problem on a fresh CURRENT. For some processes I see MWCHAN = ufs and D in the STAT. And I can't kill such processes even with -9. And system can't kill them too on shutdown. So, system can't do shutdown and wait forever after All buffers synced message. At this moment I've entered to KDB do show lockedvnods: Locked vnodes 0xc687cb58: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xcb5b1934 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending ino 2072602, on dev ad4s1g 0xc687ca50: tag ufs, type VDIR usecount 31, writecount 0, refcount 32 mountedhere 0 flags () v_object 0xc85d2744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending ino 2072603, on dev ad4s1g 0xc687c948: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc875d000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending ino 2072615, on dev ad4s1g 0xc691f420: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc8a773e0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending ino 2072680, on dev ad4s1g 0xc691f318: tag ufs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc8a7b2e8 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7019780 (pid 74103) with 2 pending ino 2072795, on dev ad4s1g 0xc69bb528: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc7890744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f4600 (pid 74129) with 1 pending ino 2072767, on dev ad4s1g Locked vnodes 0xc687cb58: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xcb5b1934 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending ino 2072602, on dev ad4s1g 0xc687ca50: tag ufs, type VDIR usecount 31, writecount 0, refcount 32 mountedhere 0 flags () v_object 0xc85d2744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending ino 2072603, on dev ad4s1g 0xc687c948: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc875d000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending ino 2072615, on dev ad4s1g 0xc691f420: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc8a773e0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending ino 2072680, on dev ad4s1g 0xc691f318: tag ufs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc8a7b2e8 ref 0 pages 1 lock type ufs: EXCL (count 1) by t(kgdb) After that I've done call doadump and got vmcore. ps show me: (kgdb) ps During symbol reading, Incomplete CFI data; unspecified registers at 0xc04d97eb. pidproc uid ppid pgrp flag stat comm wchan 74686 c94640000 1 1 00 1 sh ufs c687caa8 74195 c970d0000 3074 74195 4000100 1 sshd ufs c687caa8 74178 c7682adc0 3074 74178 004000 1 sshd ufs c687c9a0 74129 c9b82adc 1008 1 5504 004000 1 parser3.cgi ufs c691f370 74103 c70b5458 1008 1 5504 00 1 httpdufs c69bb580 65610 c92c0458 1005 1 65610 004000 1 sftp-server ufs c691f478 5518 c6247458 1008 1 5516 004002 1 perl5.8.7ufs c687caa8 3081 c7523d080 1 3081 00 1 cron ufs c687caa8 3074 c7682d080 1 3074 000100 1 sshd ufs c687caa8 3016 c7523adc0 1 3016 00 1 syslogd ufs c687caa8 519 c68e4d08 80 1 518 000100 1 nginxufs c691f370 34 c6260 0 0 000204 1 schedcpu - e88b3cf0 33 c62438b00 0 0 000204 1 syncer ktsusp c6243938 32 c6243adc0 0 0 000204 1 vnlruktsusp c6243b64 31 c6243d080 0 0 000204 1 bufdaemonktsusp c6243d90 30 c62440000 0 0 00020c 1 pagezero pgzero c06c21a0 29 c624422c0 0 0 000204 1 vmdaemon psleep c06c1d08 28 c62444580 0 0 000204 1 pagedaemon psleep c06c1cc8 27 c602e6840 0 0 000204 1 irq1: atkbd0 26 c602e8b00 0 0 000204 1 swi0: sio 25 c602eadc0 0 0 000204 1 irq18: atapci1 24
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Jo Rhett wrote this message on Thu, Jan 05, 2006 at 01:24 -0800: You are putting words in the mouth of core@ - Sorry. As said before, the topic is always struck down and nobody from core has ever stood up to say we'll support this. I don't know whose on core this week, nor will I at any given time. I just know that core has either struck it down or been Silent. 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.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recurring problem: processes block accessing UFS file system
On 5 Jan, Denis Shaposhnikov wrote: Hi! Greg == Greg Rivers [EMAIL PROTECTED] writes: Greg It's taken more than a month, but the problem has recurred Greg without snapshots ever having been run. I've got a good trace I think that I have the same problem on a fresh CURRENT. For some processes I see MWCHAN = ufs and D in the STAT. And I can't kill such processes even with -9. And system can't kill them too on shutdown. So, system can't do shutdown and wait forever after All buffers synced message. At this moment I've entered to KDB do show lockedvnods: Locked vnodes 0xc687cb58: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xcb5b1934 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending ino 2072602, on dev ad4s1g 0xc687ca50: tag ufs, type VDIR usecount 31, writecount 0, refcount 32 mountedhere 0 flags () v_object 0xc85d2744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending ino 2072603, on dev ad4s1g 0xc687c948: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc875d000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending ino 2072615, on dev ad4s1g 0xc691f420: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc8a773e0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending ino 2072680, on dev ad4s1g 0xc691f318: tag ufs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc8a7b2e8 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7019780 (pid 74103) with 2 pending ino 2072795, on dev ad4s1g 0xc69bb528: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc7890744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f4600 (pid 74129) with 1 pending ino 2072767, on dev ad4s1g Locked vnodes 0xc687cb58: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xcb5b1934 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending ino 2072602, on dev ad4s1g 0xc687ca50: tag ufs, type VDIR usecount 31, writecount 0, refcount 32 mountedhere 0 flags () v_object 0xc85d2744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending ino 2072603, on dev ad4s1g 0xc687c948: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc875d000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending ino 2072615, on dev ad4s1g 0xc691f420: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc8a773e0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending ino 2072680, on dev ad4s1g 0xc691f318: tag ufs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc8a7b2e8 ref 0 pages 1 lock type ufs: EXCL (count 1) by t(kgdb) After that I've done call doadump and got vmcore. ps show me: (kgdb) ps During symbol reading, Incomplete CFI data; unspecified registers at 0xc04d97eb. pidproc uid ppid pgrp flag stat comm wchan 74686 c94640000 1 1 00 1 sh ufs c687caa8 74195 c970d0000 3074 74195 4000100 1 sshd ufs c687caa8 74178 c7682adc0 3074 74178 004000 1 sshd ufs c687c9a0 74129 c9b82adc 1008 1 5504 004000 1 parser3.cgi ufs c691f370 74103 c70b5458 1008 1 5504 00 1 httpdufs c69bb580 65610 c92c0458 1005 1 65610 004000 1 sftp-server ufs c691f478 5518 c6247458 1008 1 5516 004002 1 perl5.8.7ufs c687caa8 3081 c7523d080 1 3081 00 1 cron ufs c687caa8 3074 c7682d080 1 3074 000100 1 sshd ufs c687caa8 3016 c7523adc0 1 3016 00 1 syslogd ufs c687caa8 519 c68e4d08 80 1 518 000100 1 nginxufs c691f370 34 c6260 0 0 000204 1 schedcpu - e88b3cf0 33 c62438b00 0 0 000204 1 syncer ktsusp c6243938 32 c6243adc0 0 0 000204 1 vnlruktsusp c6243b64 31 c6243d080 0 0 000204 1 bufdaemonktsusp c6243d90 30 c62440000 0 0 00020c 1 pagezero pgzero c06c21a0 29 c624422c0 0 0 000204 1 vmdaemon psleep c06c1d08 28 c62444580 0 0 000204 1 pagedaemon psleep c06c1cc8 27 c602e6840
WITNESS speedup patch for RELENG_5
If you are running RELENG_5 and using WITNESS, you might want to try the
patch below. It speeds up WITNESS rather dramatically. This patch was
committed to HEAD in late August (subr_witness.c 1.198) and early
September (subr_witness.c 1.200). It was MFC'ed to RELENG_6 in the last
few days. I'd like to MFC it to RELENG_5, but I think it should get a
bit more exposure before I do.
Index: sys/kern/subr_witness.c
===
RCS file: /home/ncvs/src/sys/kern/subr_witness.c,v
retrieving revision 1.178.2.8
diff -u -r1.178.2.8 subr_witness.c
--- sys/kern/subr_witness.c 4 May 2005 19:26:30 - 1.178.2.8
+++ sys/kern/subr_witness.c 12 Sep 2005 04:52:53 -
@@ -165,16 +165,9 @@
static int isitmychild(struct witness *parent, struct witness *child);
static int isitmydescendant(struct witness *parent, struct witness *child);
static int itismychild(struct witness *parent, struct witness *child);
-static int rebalancetree(struct witness_list *list);
static voidremovechild(struct witness *parent, struct witness *child);
-static int reparentchildren(struct witness *newparent,
- struct witness *oldparent);
static int sysctl_debug_witness_watch(SYSCTL_HANDLER_ARGS);
-static voidwitness_displaydescendants(void(*)(const char *fmt, ...),
- struct witness *, int indent);
static const char *fixup_filename(const char *file);
-static voidwitness_leveldescendents(struct witness *parent, int level);
-static voidwitness_levelall(void);
static struct witness *witness_get(void);
static voidwitness_free(struct witness *m);
static struct witness_child_list_entry *witness_child_get(void);
@@ -185,20 +178,21 @@
struct lock_object *lock);
static voidwitness_list_lock(struct lock_instance *instance);
#ifdef DDB
-static voidwitness_list(struct thread *td);
+static voidwitness_leveldescendents(struct witness *parent, int level);
+static voidwitness_levelall(void);
+static voidwitness_displaydescendants(void(*)(const char *fmt, ...),
+ struct witness *, int indent);
static voidwitness_display_list(void(*prnt)(const char *fmt, ...),
struct witness_list *list);
static voidwitness_display(void(*)(const char *fmt, ...));
+static voidwitness_list(struct thread *td);
#endif
SYSCTL_NODE(_debug, OID_AUTO, witness, CTLFLAG_RW, 0, Witness Locking);
/*
- * If set to 0, witness is disabled. If set to 1, witness performs full lock
- * order checking for all locks. If set to 2 or higher, then witness skips
- * the full lock order check if the lock being acquired is at a higher level
- * (i.e. farther down in the tree) than the current lock. This last mode is
- * somewhat experimental and not considered fully safe. At runtime, this
+ * If set to 0, witness is disabled. If set to a non-zero value, witness
+ * performs full lock order checking for all locks. At runtime, this
* value may be set to 0 to turn off witness. witness is not allowed be
* turned on once it is turned off, however.
*/
@@ -250,6 +244,16 @@
static struct witness_child_list_entry *w_child_free = NULL;
static struct lock_list_entry *w_lock_list_free = NULL;
+static int w_free_cnt, w_spin_cnt, w_sleep_cnt, w_child_free_cnt, w_child_cnt;
+SYSCTL_INT(_debug_witness, OID_AUTO, free_cnt, CTLFLAG_RD, w_free_cnt, 0, );
+SYSCTL_INT(_debug_witness, OID_AUTO, spin_cnt, CTLFLAG_RD, w_spin_cnt, 0, );
+SYSCTL_INT(_debug_witness, OID_AUTO, sleep_cnt, CTLFLAG_RD, w_sleep_cnt, 0,
+);
+SYSCTL_INT(_debug_witness, OID_AUTO, child_free_cnt, CTLFLAG_RD,
+w_child_free_cnt, 0, );
+SYSCTL_INT(_debug_witness, OID_AUTO, child_cnt, CTLFLAG_RD, w_child_cnt, 0,
+);
+
static struct witness w_data[WITNESS_COUNT];
static struct witness_child_list_entry w_childdata[WITNESS_CHILDCOUNT];
static struct lock_list_entry w_locklistdata[LOCK_CHILDCOUNT];
@@ -575,6 +579,87 @@
#ifdef DDB
static void
+witness_levelall (void)
+{
+ struct witness_list *list;
+ struct witness *w, *w1;
+
+ /*
+* First clear all levels.
+*/
+ STAILQ_FOREACH(w, w_all, w_list) {
+ w-w_level = 0;
+ }
+
+ /*
+* Look for locks with no parent and level all their descendants.
+*/
+ STAILQ_FOREACH(w, w_all, w_list) {
+ /*
+* This is just an optimization, technically we could get
+* away just walking the all list each time.
+*/
+ if (w-w_class-lc_flags LC_SLEEPLOCK)
+ list = w_sleep;
+ else
+ list = w_spin;
+ STAILQ_FOREACH(w1, list, w_typelist) {
+ if (isitmychild(w1, w))
+ goto skip;
+
Re: Recurring problem: processes block accessing UFS file system
Don == Don Lewis [EMAIL PROTECTED] writes: Don pid 519 wants to lock this vnode but some other thread is Don holding the vnode lock. Unfortunately we don't know who the Don lock holder is because the message is truncated. Is it possible to find out the answer from the crashdump? Don This might just be a vnode lock leak. Build a debug kernel with Don the DEBUG_VFS_LOCKS and DEBUG_LOCKS options and see if anything Don shows up. I'll try, thank you. -- DSS5-RIPE DSS-RIPN 2:550/[EMAIL PROTECTED] 2:550/[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://neva.vlink.ru/~dsh/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recurring problem: processes block accessing UFS file system
On 5 Jan, Denis Shaposhnikov wrote: Don == Don Lewis [EMAIL PROTECTED] writes: Don pid 519 wants to lock this vnode but some other thread is Don holding the vnode lock. Unfortunately we don't know who the Don lock holder is because the message is truncated. Is it possible to find out the answer from the crashdump? It's possible if you have the matching debug kernel, though it is more painful. In kgdb: print *(struct vnode *)0xc691f318 print (struct vnode *)0xc691f318-v_vnlock-lk_lockholder-td_proc-p_pid) or something like that. Don This might just be a vnode lock leak. Build a debug kernel with Don the DEBUG_VFS_LOCKS and DEBUG_LOCKS options and see if anything Don shows up. I'll try, thank you. Are you using any unusual file systems, such as nullfs or unionfs? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recurring problem: processes block accessing UFS file system
Don == Don Lewis [EMAIL PROTECTED] writes: Don Are you using any unusual file systems, such as nullfs or Don unionfs? Yes, I'm use a lots of nullfs. This is a host system for about 20 jails with nullfs mounted ro system: /dev/mirror/gm0s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/mirror/gm0s1d on /usr/local (ufs, local) /dev/mirror/gm0s1e on /home (ufs, local, nosuid) /dev/mirror/gm0s1f on /tmp (ufs, local, noexec) /dev/mirror/gm0s1g on /var (ufs, NFS exported, local) procfs on /proc (procfs, local) devfs on /var/named/dev (devfs, local) /var/jail/build/the.jail on /var/jail/netflow/the.jail/.build (nullfs, local, read-only) /var/jail/netflow/the.jail.etc on /var/jail/netflow/the.jail/.build/etc (nullfs, local, read-only) /var/jail/netflow/the.jail.local on /var/jail/netflow/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/netflow/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/mysql/the.jail/.build (nullfs, local, read-only) /var/jail/mysql/the.jail.etc on /var/jail/mysql/the.jail/.build/etc (nullfs, local, read-only) /var/jail/mysql/the.jail.local on /var/jail/mysql/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/mysql/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/dspam/the.jail/.build (nullfs, local, read-only) /var/jail/dspam/the.jail.etc on /var/jail/dspam/the.jail/.build/etc (nullfs, local, read-only) /var/jail/dspam/the.jail.local on /var/jail/dspam/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/dspam/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/deliver_smtp/the.jail/.build (nullfs, local, read-only) /var/jail/deliver_smtp/the.jail.etc on /var/jail/deliver_smtp/the.jail/.build/etc (nullfs, local, read-only) /var/jail/deliver_smtp/the.jail.local on /var/jail/deliver_smtp/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/deliver_smtp/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/clamav/the.jail/.build (nullfs, local, read-only) /var/jail/clamav/the.jail.etc on /var/jail/clamav/the.jail/.build/etc (nullfs, local, read-only) /var/jail/clamav/the.jail.local on /var/jail/clamav/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/clamav/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/mx1_smtp/the.jail/.build (nullfs, local, read-only) /var/jail/mx1_smtp/the.jail.etc on /var/jail/mx1_smtp/the.jail/.build/etc (nullfs, local, read-only) /var/jail/mx1_smtp/the.jail.local on /var/jail/mx1_smtp/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/mx1_smtp/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/smtp_smtp/the.jail/.build (nullfs, local, read-only) /var/jail/smtp_smtp/the.jail.etc on /var/jail/smtp_smtp/the.jail/.build/etc (nullfs, local, read-only) /var/jail/smtp_smtp/the.jail.local on /var/jail/smtp_smtp/the.jail/.build/usr/local (nullfs, local, read-only) /var/jail/mx1_smtp/the.jail/var/db/postfix on /var/jail/smtp_smtp/the.jail/var/db/postfix (nullfs, local, read-only) devfs on /var/jail/smtp_smtp/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/cacti/the.jail/.build (nullfs, local, read-only) /var/jail/cacti/the.jail.etc on /var/jail/cacti/the.jail/.build/etc (nullfs, local, read-only) /var/jail/cacti/the.jail.local on /var/jail/cacti/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/cacti/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/rk80/the.jail/.build (nullfs, local, read-only) /var/jail/rk80/the.jail.etc on /var/jail/rk80/the.jail/.build/etc (nullfs, local, read-only) /var/jail/rk80/the.jail.local on /var/jail/rk80/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/rk80/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/syslog/the.jail/.build (nullfs, local, read-only) /var/jail/syslog/the.jail.etc on /var/jail/syslog/the.jail/.build/etc (nullfs, local, read-only) /var/jail/syslog/the.jail.local on /var/jail/syslog/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/syslog/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/tftpboot/the.jail/.build (nullfs, local, read-only) /var/jail/tftpboot/the.jail.etc on /var/jail/tftpboot/the.jail/.build/etc (nullfs, local, read-only) /var/jail/tftpboot/the.jail.local on /var/jail/tftpboot/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/tftpboot/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/clickon/the.jail/.build (nullfs, local, read-only) /var/jail/clickon/the.jail.etc on /var/jail/clickon/the.jail/.build/etc (nullfs, local, read-only) /var/jail/clickon/the.jail.local on /var/jail/clickon/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/clickon/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/sulci/the.jail/.build (nullfs, local,
SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel)
Boy... what a major disappointment I just had... I got in my SunFire X4100 dual opteron server and a LSI MegaRAID 320-2X PCI-X card. Unfortunately, the Sun seems to only accept 1/2 height cards. Totally lame. Anyhow, I'm having a hard time finding 1/2 height U320 RAID cards with dual channels (I can't imagine how the connectors would fit, but hey I can hope). Does anyone have any recommendations? Naturally I'm going to run 6.0-RELEASE on it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gdm problem with kernel as of 2005-01-04
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 -- Richard Kuhns Wintek Corporation E-mail: [EMAIL PROTECTED] 427 N 6th Street Tel: +1 (765) 742-8428 Lafayette, IN 47901-1126 Fax: +1 (765) 742-0646 United States of America ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recurring problem: processes block accessing UFS file system
On 5 Jan, Denis Shaposhnikov wrote: Don == Don Lewis [EMAIL PROTECTED] writes: Don Are you using any unusual file systems, such as nullfs or Don unionfs? Yes, I'm use a lots of nullfs. This is a host system for about 20 jails with nullfs mounted ro system: That would be my guess as to the cause of the problem. Hopefully DEBUG_VFS_LOCKS will help pinpoint the bug. ___ 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 4:27 PM, Vivek Khera wrote: Anyhow, I'm having a hard time finding 1/2 height U320 RAID cards with dual channels (I can't imagine how the connectors would fit, but hey I can hope). Does anyone have any recommendations? Naturally I'm going to run 6.0-RELEASE on it. Ok... seems that my only likely candidate is the Adaptec 2230SLP. I'm not a big adaptec fan so I have little experience with these. There was a discussion on the -scsi list a year ago and the card is listed as supported, but it is hard to find how stable these cards are and how well they perform under heavy I/O + network load. The only other aac controller I have is a Dell PERC type which is god- awful slow, but I hear that's dell's fault not adaptec's. I don't know what to believe there. That card is quite stable however. Any experiences with this that anyone wishes to share? ___ 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 Thu, Jan 05, 2006 at 01:24 -0800: Sorry. As said before, the topic is always struck down and nobody from core has ever stood up to say we'll support this. I don't know whose on core this week, nor will I at any given time. This information is publicly available if you want to do the research. I just know that core has either struck it down or been Silent. 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.) Because of this, it's more much difficult for me to give your technical arguments as much credence as I would otherwise. 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. But your mileage may vary. mcl ___ 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 Thu, 5 Jan 2006, Scott Mitchell wrote: Hi all, 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 supported by amr(4), but I'm wondering how well it actually works in the case of a disk failure. Will the driver tell me that disk has failed (a syslog message would be enough) or will I have to make a daily trip into the server room to check the front panel lights? Presumably it handles hot-swapping a replacement drive OK? From what I remember, you will receive status-change kernel messages when disks disappear, rebuilds start, and so forth. So for most day-to-day manipulation you should be fine. You may want to make sure the auto rebuild option is enabled in the controller's BIOS since no working control programs from userland are generally available at this time. That also means you can't create new volumes at runtime, but thats not so horrible... -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | 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 Thu, Jan 05, 2006 at 03:34:24PM -0800, Doug White wrote: On Thu, 5 Jan 2006, Scott Mitchell wrote: Hi all, 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 supported by amr(4), but I'm wondering how well it actually works in the case of a disk failure. Will the driver tell me that disk has failed (a syslog message would be enough) or will I have to make a daily trip into the server room to check the front panel lights? Presumably it handles hot-swapping a replacement drive OK? From what I remember, you will receive status-change kernel messages when disks disappear, rebuilds start, and so forth. So for most day-to-day manipulation you should be fine. That would be fine - as long as there's some notification of important events. You may want to make sure the auto rebuild option is enabled in the controller's BIOS since no working control programs from userland are generally available at this time. That also means you can't create new volumes at runtime, but thats not so horrible... I expect there will only ever be one volume, so that's unlikely to be a problem :) Many thanks, 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 PERC4e/DC RAID?
On Thu, Jan 05, 2006 at 03:34:24PM -0800, Doug White wrote: On Thu, 5 Jan 2006, Scott Mitchell wrote: Hi all, 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 supported by amr(4), but I'm wondering how well it actually works in the case of a disk failure. Will the driver tell me that disk has failed (a syslog message would be enough) or will I have to make a daily trip into the server room to check the front panel lights? Presumably it handles hot-swapping a replacement drive OK? From what I remember, you will receive status-change kernel messages when disks disappear, rebuilds start, and so forth. So for most day-to-day manipulation you should be fine. You may want to make sure the auto rebuild option is enabled in the controller's BIOS since no working control programs from userland are generally available at this time. That also means you can't create new volumes at runtime, but thats not so horrible... The sysutils/megarc port appears to work for both status change polling and runtime configuration (at least on a PE800 and a PE2850 that I tested 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 PERC4e/DC RAID?
On Thu, Jan 05, 2006 at 06:09:09PM -0600, David Sze wrote: On Thu, Jan 05, 2006 at 03:34:24PM -0800, Doug White wrote: On Thu, 5 Jan 2006, Scott Mitchell wrote: supported by amr(4), but I'm wondering how well it actually works in the case of a disk failure. Will the driver tell me that disk has failed (a syslog message would be enough) or will I have to make a daily trip into the server room to check the front panel lights? Presumably it handles hot-swapping a replacement drive OK? From what I remember, you will receive status-change kernel messages when disks disappear, rebuilds start, and so forth. So for most day-to-day manipulation you should be fine. You may want to make sure the auto rebuild option is enabled in the controller's BIOS since no working control programs from userland are generally available at this time. That also means you can't create new volumes at runtime, but thats not so horrible... The sysutils/megarc port appears to work for both status change polling and runtime configuration (at least on a PE800 and a PE2850 that I tested on). Cool, I'll check that out when the hardware arrives. Many thanks, 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: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
[cross post to -current removed] On Thu, 5 Jan 2006 19:54, Jo Rhett wrote: On Fri, Dec 23, 2005 at 11:36:11AM +1030, Daniel O'Connor wrote: On each 'client' PC.. NFS mount /usr/src and /usr/obj installkernel reboot installworld Works fine on home computers behind firewalls. Useless on public servers that don't run RPC. Useless on flash-based servers where minimizing writes is necessary. (mergemaster does far far far too many writes) For NFS mount, read: any network file system. You can also use, say IPSEC to protect the NFS packets (although I'm not claiming it's a trivial thing to set up..) As for restricting the number of writes - that is a totally separate issue and isn't very relevant to this discussion. You are putting words in the mouth of core@ - Sorry. As said before, the topic is always struck down and nobody from core has ever stood up to say we'll support this. I don't know whose on core this week, nor will I at any given time. I just know that core has either struck it down or been Silent. In general core IS silent. Core isn't some governing body that decides what happens in FreeBSD and plans in detail what happens. You are showing a fundamental misunderstanding about how FreeBSD works. Also, you just said ... the topic is always struck down ... - what do 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? A good binary update mechanism shouldn't be just the network. Updates from flash devices, ISO images, etc should all work much the same way. Absolutely. In fact you could put /usr/src and /usr/obj on a CD/DVD/Flash drive and upgrade that way. I would *welcome* a more sophisticated method for binary upgrades that was a lot smarter. I imagine pretty much everyone else would too. Unless you mean core@ said they would not support packaging the base which is different. People have clearly identified the problems that prevent a useful binary update mechanism from working, and what they need from core. Some have asked for core packages, others have other ideas, and some have said anything that gives me versioning ability and and..? Anyway, so what? Nothing stops you writing such a system, and I contend it isn't necessary to version the base system, or package it specially to do binary upgrades. Something similar to freebsd-update could do it. This is not true - I don't see it as being mandatory to be able to apply binary updates. (Case in point - freebsd-update works fine without it) freebsd-update works fine if you run GENERIC with no build options. Back to useful for home computers. 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.. freebsd-update is hampered by the exact problems I'm listing here. Difficulty determining what I have, no method to store what I did and no effective backout mechanism to speak of. Then feel free to expand on it. This IS an open source project - you can see how everything is written, if you want to improve it Nobody that I know cares whether or not the solution manifests as core os packages, but some sort of core versioning ability has to be developed and supported by the core. I don't think core is really very relevant here - core is there to mostly settle disputes. The way forward is to achieve consensus and have working solutions. 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 :) -- 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 pgpOsYpsgg2xj.pgp Description: PGP signature
Re: 6.0 on Dell 1850 with PERC4e/DC RAID?
Scott Mitchell wrote: Hi all, 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 supported by amr(4), but I'm wondering how well it actually works in the case of a disk failure. Will the driver tell me that disk has failed (a syslog message would be enough) or will I have to make a daily trip into the server room to check the front panel lights? Presumably it handles hot-swapping a replacement drive OK? I found some posts mentioning some management/monitoring tools for these controllers that were allegedly available from the www.lsilogic.com website, but I can't find anything on there for FreeBSD. Do the Linux tools work? 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 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]
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
ml (And, as well, that you do not even understand the role the core plays ml in the project. Hint: it is not primarily technical in nature.) For those curious to know how the project works, the following online resources may help: A project model for the FreeBSD Project http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/index.html The FreeBSD development process: a case study http://www.cs.colostate.edu/puml/pub/FreeBSD_TSEVersion.pdf The FreeBSD Committers Guide http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ 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: [ ... ] The only other aac controller I have is a Dell PERC type which is god- awful slow, but I hear that's dell's fault not adaptec's. I don't know what to believe there. That card is quite stable however. Any experiences with this that anyone wishes to share? 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. If you've got the older PERC/3 AAC controller, it looks something like this: 6-pi# dmesg | grep aac aac0: Dell PERC 3/Di mem 0xf000-0xf7ff irq 31 at device 2.1 on pci2 aac0: i960RX 100MHz, 118MB cache memory, optional battery present aac0: Kernel 2.5-0, Build 2991, S/N x aac0: Supported Options=0 aacd0: RAID 1 (Mirror) on aac0 aacd0: 17355MB (35544576 sectors) Mounting root from ufs:/dev/aacd0s1a 7-pi# diskinfo -v -t aacd0 aacd0 512 # sectorsize 18198822912 # mediasize in bytes (17G) 35544576# mediasize in sectors 2212# Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 1.344172 sec =5.377 msec Half stroke: 250 iter in 1.300260 sec =5.201 msec Quarter stroke: 500 iter in 2.705104 sec =5.410 msec Short forward:400 iter in 2.605101 sec =6.513 msec Short backward: 400 iter in 2.157570 sec =5.394 msec Seq outer: 2048 iter in 0.954848 sec =0.466 msec Seq inner: 2048 iter in 0.952256 sec =0.465 msec Transfer rates: outside: 102400 kbytes in 3.248853 sec =31519 kbytes/sec middle:102400 kbytes in 3.174779 sec =32254 kbytes/sec inside:102400 kbytes in 4.612511 sec =22200 kbytes/sec 8-pi# uname -a FreeBSD pi.codefab.com 5.4-STABLE FreeBSD 5.4-STABLE #0: Wed Nov 9 23:04:08 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PI i386 ...set up as a RAID-1 mirror using a pair of 18 GB, hmm, 10K RPM Seagates, IIRC? Seems a bit slower under 5 than under 4, but not unreasonably so. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
