Re: 9.1 minimal ram requirements
I just checked in a change to HEAD (247814) that compiles CTL in GENERIC
but disables it by default. (i.e. it uses no memory) You can re-enable
it with the existing loader tunable.
i.e. set kern.cam.ctl.disable=0 in /boot/loader.conf and it will be
enabled.
Ken
On Wed, Feb 27, 2013 at 18:26:28 -0800, Adrian Chadd wrote:
Hi Ken,
I'd like to fix this for 9.2 and -HEAD.
Would you mind if I disabled CTL in GENERIC (but still build it as a
module) until you've fixed the initial RAM reservation that it
requires?
Thanks,
Adrian
On 22 December 2012 22:32, Adrian Chadd adr...@freebsd.org wrote:
Ken,
Does CAM CTL really need to pre-allocate 35MB of RAM at startup?
Adrian
On 22 December 2012 16:45, Sergey Kandaurov pluk...@gmail.com wrote:
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl wrote:
On 12/23/2012 12:27 AM, Jakub Lach wrote:
Guys, I've heard about some absurd RAM requirements
for 9.1, has anybody tested it?
e.g.
http://forums.freebsd.org/showthread.php?t=36314
jup, I can comfirm this with nanobsd (cross) compiled
for my soekris net4501 which has 64 MB mem:
from dmesg: real memory = 67108864 (64 MB)
while the same config compiled against a 9.0 tree still works...
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot.
A longer term workaround could be to postpone those memory allocations
until the first call to CTL.
# cam ctl init allocates roughly 35 MB of kernel memory at once
# three memory pools, somewhat under M_DEVBUF, and memory disk
# devbuf takes 1022K with kern.cam.ctl.disable=1
Type InUse MemUse HighUse Requests Size(s)
devbuf 213 20366K - 265
16,32,64,128,256,512,1024,2048,4096
ctlmem 5062 10113K - 5062 64,2048
ctlblk 200 800K - 200 4096
ramdisk 1 4096K -1
ctlpool 532 138K - 532 16,512
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Kenneth Merry
k...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
Hi Ken,
I'd like to fix this for 9.2 and -HEAD.
Would you mind if I disabled CTL in GENERIC (but still build it as a
module) until you've fixed the initial RAM reservation that it
requires?
Thanks,
Adrian
On 22 December 2012 22:32, Adrian Chadd adr...@freebsd.org wrote:
Ken,
Does CAM CTL really need to pre-allocate 35MB of RAM at startup?
Adrian
On 22 December 2012 16:45, Sergey Kandaurov pluk...@gmail.com wrote:
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl wrote:
On 12/23/2012 12:27 AM, Jakub Lach wrote:
Guys, I've heard about some absurd RAM requirements
for 9.1, has anybody tested it?
e.g.
http://forums.freebsd.org/showthread.php?t=36314
jup, I can comfirm this with nanobsd (cross) compiled
for my soekris net4501 which has 64 MB mem:
from dmesg: real memory = 67108864 (64 MB)
while the same config compiled against a 9.0 tree still works...
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot.
A longer term workaround could be to postpone those memory allocations
until the first call to CTL.
# cam ctl init allocates roughly 35 MB of kernel memory at once
# three memory pools, somewhat under M_DEVBUF, and memory disk
# devbuf takes 1022K with kern.cam.ctl.disable=1
Type InUse MemUse HighUse Requests Size(s)
devbuf 213 20366K - 265
16,32,64,128,256,512,1024,2048,4096
ctlmem 5062 10113K - 5062 64,2048
ctlblk 200 800K - 200 4096
ramdisk 1 4096K -1
ctlpool 532 138K - 532 16,512
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On Mon, 24 Dec 2012 04:50:22 +1100, Ian Smith wrote:
[following up my own message with a later report]
On Sun, 23 Dec 2012 15:21:23 +0300, Sergey Kandaurov wrote:
On 23 December 2012 10:22, Ian Smith smi...@nimnet.asn.au wrote:
On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote:
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which
is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish
boot.
I've just added that, thanks Sergey, but it's sadly not an option for
installation. I guess it's too late for the release notes - which at
RC3 made no mention of CAM CTL at all - but it's not yet clear to me
whether even 256MB is enough to boot, install and run 9.1 GENERIC?
If you perform clean installation (e.g. from ISO), you can escape to the
loader prompt and set the tunable there w/o the need for
/boot/loader.conf.
I experimented with Vbox and AFAIK 256MB was enough even with CAM CTL.
Ah right; I'd booted and installed from memstick, where escape to loader
prompt is not an option. I'll burn a disc1 and try that with the 128MB
again, and make sure that 256MB is comfortable - after holiday madness.
So I tried again with the 128MB RAM, from a disc1 boot, from loader set
kern.cam.ctl.disable=1, installed all distributions, no problems; with
sshd, powerd, no ntpd (laptop had broken NIC then, now fixed), loaded
acpi_ibm (working well, and suspend and resume finally work reliably out
of the box, excellent!), top showing 77MB free. Ran it for over a day
doing nothing much - resume, browse some stuff, suspend - 77MB free.
With 256MB instead, installed as above _without_ disabling kern.cam.ctl,
no problems, to another slice. As an aside, bsdinstall didn't update my
boot0, leaving the previously installed slice selected on boot, but I'm
more relieved it didn't mess with it :) top showed 167MB free, steady.
256MB as above but with kern.cam.ctl.disabled=1, top shows 202MB free.
202 - 167 = 35MB extra by cam.ctl. Without cam.ctl, 128 - 77 = 51MB
used, 256 - 202 = 54MB used, unsure where 3MB went but I'm not worried.
So I'm happy to say that 128MB RAM, with kern.cam.ctl.disabled=1, boots,
installs and runs 9.1-R fine. I might even try it on my ancient but so
far unstoppable 10yrs x24x7 Compaq Armada 1500c, maxed out at 160MB :)
I notice that my previous 202MB free is now down to 6.4MB, with swap
touched at 336K, that's likely normal; I'll work it a bit harder soon.
It'd be nice if booting from memstick allowed dropping to loader.
cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
Well, now there is release, but -STABLE is still pre, while -STABLE code is already well past release builds ;) Eh, imperfect world... -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-tp5771583p5773408.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
from Mark Linimon lini...@lonesome.com: In an ideal world, the bits that will almost certainly become FreeBSD 9.1 would not appear on the masters, or any of the mirrors, until the same instant that the release announcement is set to freebsd-annou...@freebsd.org. In practice this doesn't happen. If there is some clever way for that to happen, we haven't found it yet. It has happened in the past that even as the release bits were propogating, One Last Big Bug was found and those bits had to be pulled and re-done. It would have looked like you had FreeBSD Release X.Y but you wouldn't have had the final bits that everyone else did. I understand your frustration that this process takes days, and in general the frustration with this particular release -- more than you could possibly believe. However, until we figure out the process that would exist in an ideal world, this is what we have, and so if you need something that will be in 9.1, your options at this moment are: build an install from 9-STABLE; find one of the snapshots (and no, I am not the one to ask, sorry); or wait. Sorry, but that's the best I can offer right now. mcl So that's why I downloaded-updated source tree using svn, built and installed, and uname -a revealed 9.1-PRERELEASE. It seemed strange after 9.1-RELEASE became available on FTP servers December 5. Maybe they can do something to better document device ctl in GENERIC; I kept it because it was there, and one is led to think it is needed due to changes in FreeBSD. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On Sat, Dec 29, 2012 at 1:46 PM, Thomas Mueller muelle...@insightbb.com wrote: from Mark Linimon lini...@lonesome.com: In an ideal world, the bits that will almost certainly become FreeBSD 9.1 would not appear on the masters, or any of the mirrors, until the same instant that the release announcement is set to freebsd-annou...@freebsd.org. In practice this doesn't happen. If there is some clever way for that to happen, we haven't found it yet. It has happened in the past that even as the release bits were propogating, One Last Big Bug was found and those bits had to be pulled and re-done. It would have looked like you had FreeBSD Release X.Y but you wouldn't have had the final bits that everyone else did. I understand your frustration that this process takes days, and in general the frustration with this particular release -- more than you could possibly believe. However, until we figure out the process that would exist in an ideal world, this is what we have, and so if you need something that will be in 9.1, your options at this moment are: build an install from 9-STABLE; find one of the snapshots (and no, I am not the one to ask, sorry); or wait. Sorry, but that's the best I can offer right now. mcl So that's why I downloaded-updated source tree using svn, built and installed, and uname -a revealed 9.1-PRERELEASE. It seemed strange after 9.1-RELEASE became available on FTP servers December 5. Maybe they can do something to better document device ctl in GENERIC; I kept it because it was there, and one is led to think it is needed due to changes in FreeBSD. Tom Most likely you took the stable/9 aka 9-STABLE sources. They have internal name 9.1-PRERELEASE until the 9.1-RELEASE goes out of the door. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On Sat, Dec 29, 2012 at 1:59 PM, Kimmo Paasiala kpaas...@gmail.com wrote: On Sat, Dec 29, 2012 at 1:46 PM, Thomas Mueller muelle...@insightbb.com wrote: from Mark Linimon lini...@lonesome.com: In an ideal world, the bits that will almost certainly become FreeBSD 9.1 would not appear on the masters, or any of the mirrors, until the same instant that the release announcement is set to freebsd-annou...@freebsd.org. In practice this doesn't happen. If there is some clever way for that to happen, we haven't found it yet. It has happened in the past that even as the release bits were propogating, One Last Big Bug was found and those bits had to be pulled and re-done. It would have looked like you had FreeBSD Release X.Y but you wouldn't have had the final bits that everyone else did. I understand your frustration that this process takes days, and in general the frustration with this particular release -- more than you could possibly believe. However, until we figure out the process that would exist in an ideal world, this is what we have, and so if you need something that will be in 9.1, your options at this moment are: build an install from 9-STABLE; find one of the snapshots (and no, I am not the one to ask, sorry); or wait. Sorry, but that's the best I can offer right now. mcl So that's why I downloaded-updated source tree using svn, built and installed, and uname -a revealed 9.1-PRERELEASE. It seemed strange after 9.1-RELEASE became available on FTP servers December 5. Maybe they can do something to better document device ctl in GENERIC; I kept it because it was there, and one is led to think it is needed due to changes in FreeBSD. Tom Most likely you took the stable/9 aka 9-STABLE sources. They have internal name 9.1-PRERELEASE until the 9.1-RELEASE goes out of the door. Erm too little coffee this early... I should have written IF you are following stable/9 aka 9-STABLE the 9.1-PRERELEASE is what you will see as the internal name until 9.1-RELEASE is released. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
What you are seeing is behind-the-scenes preparation. The release is official when, and only when, a security-signed email is sent to freebsd-annou...@freebsd.org from the Release Engineering team. Yeah, Mark. You're right. Further, I'm right too. What should I install on blank node? Beta? No beta on the site. RC1-3? No RC on the site. 9.0? I need kms at least on laptop. My simple question is: what is the file on the server? Please, no only-when, no wait-for-... I'm might be ignorant in many ways, but I expect freebsd site to content what it reads as a file name. So, do I have installed 9.1 on my desktop and laptop or some alien OS? Do I have to wait more and reinstall from the beginning, when official announcement comes? To be clear: freebsd is my only OS on computer for many years and I do not argue in any way. I just want to say that silence is not a good kind of communication. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
It has happened in the past that even as the release bits were propogating, One Last Big Bug was found and those bits had to be pulled and re-done. It would have looked like you had FreeBSD Release X.Y but you wouldn't have had the final bits that everyone else did. I'm aware of this. I simply did not have alternative. I understand your frustration that this process takes days, and in general the frustration with this particular release -- more than you could possibly believe. However, until we figure out the process that would exist in an ideal world, this is what we have, and so if you need something that will be in 9.1, your options at this moment are: build an install from 9-STABLE; find one of the snapshots (and no, I am not the one to ask, sorry); or wait. I'm not fond of one-size fits all principle. If an image is correct, I'll stick with it, till next treshold. At the moment, I fill relaxed, since both systems work as the best machines I had in my life. As I stated before, I could stand bugs and do not expect perfect system anytime. Freebsd suits me. If I have a problem, I wait or go around, or forget the issue. My bad was that release problem sinchronized with my power surge issue. At any other time, I'd be patient and you'd never hear of me. Sorry, but that's the best I can offer right now. Wrong. You made psychological thing and I could be not worried about state of OS. If this image differs from the final one, I do not care, if they are the same in parts that matter to me. I will upgrade at the next insert. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On Wed, Dec 26, 2012 at 06:02:33PM +0100, Zoran Kolic wrote: Seeing 9.1-RELEASE instead 9.1-PRERELASE or 9.1-RC4 is also a bad suprise for me... I assume it does not look like release is the lack of packages. What you are seeing is behind-the-scenes preparation. The release is official when, and only when, a security-signed email is sent to freebsd-annou...@freebsd.org from the Release Engineering team. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
Seeing 9.1-RELEASE instead 9.1-PRERELASE or 9.1-RC4 is also a bad suprise for me... I assume it does not look like release is the lack of packages. Simply, I installed and compiled from ports. Cannot say if it stands on the site as a decoration, but I have it on desktop and laptop and found it a serious piece of work. The point is that I had to install, since I had had two new computers waiting blank. If no-one has any idea on the subject, I will just remove the line in kernel. Hopes are that old make reinstallkernel KERNCONF... still works. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On Wed, Dec 26, 2012 at 6:02 PM, Zoran Kolic zko...@sbb.rs wrote: Seeing 9.1-RELEASE instead 9.1-PRERELASE or 9.1-RC4 is also a bad suprise for me... I assume it does not look like release is the lack of packages. Simply, I installed and compiled from ports. Making a Release is a well defined process as I read on http://www.freebsd.org/doc/en/articles/releng/release-proc.html and it has its precisely defined meaning. If we loose that meaning the process is irrelevant and so the word RELEASE. Process stands for quality I guess... There are two extremely important sentences imo at the end of this document: FreeBSD releases must always be reproducible. - this way we get system that behaves exactly the same after some time, this is very important. Local hacks in the release engineer's environment are not acceptable. - this is what happens now? Cannot say if it stands on the site as a decoration, but I have it on desktop and laptop and found it a serious piece of work. The point is that I had to install, since I had had two new computers waiting blank. 9.1-RC3 works just fine as well for some weeks :-) When your computers are not production machines I also recommend this to you Zoran to test RC in order to make RELEASE a better product. What you have now is labeled as RELEASE but it is a decoration. The RELEASE will be different from what you have found and installed (I think there are already versions with different tags available). This is really the thing that pushed me away from Linux :-( If no-one has any idea on the subject, I will just remove the line in kernel. Hopes are that old make reinstallkernel KERNCONF... still works. Good luck :-) However if you simply want to diable that RAM consuming function there is a switch that can disable it and make install possible..? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
9.1-RC3 works just fine as well for some weeks :-) When your computers are not production machines I also recommend this to you Zoran to test RC in order to make RELEASE a better product. What you have now is labeled as RELEASE but it is a decoration. The RELEASE will be different from what you have found and installed (I think there are already versions with different tags available). This is really the thing that pushed me away from Linux :-( I removed the line and it booted just fine. To me, 9.1 is probably the best looking release, but it might be due to new hardware. I'n not aware what is going on, regarding release or release. At full speed I support the way devel team does the work. And contrary, the team has to bear with users, who want to know. I had new desktop and new laptop waiting, since power surge killed some devices at my home. And I waited for 3 months. None could say I was impatient. The release image is on the site. And, if you change RC3 to RELEASE in browser, there is even more. Why would serious guys keep those files available, if not for usage? My best guess is that some packages compile made all that fuss. What else might be? Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On Wed, Dec 26, 2012 at 7:43 PM, Zoran Kolic zko...@sbb.rs wrote: 9.1-RC3 works just fine as well for some weeks :-) When your computers are not production machines I also recommend this to you Zoran to test RC in order to make RELEASE a better product. What you have now is labeled as RELEASE but it is a decoration. The RELEASE will be different from what you have found and installed (I think there are already versions with different tags available). This is really the thing that pushed me away from Linux :-( I removed the line and it booted just fine. To me, 9.1 is probably the best looking release, but it might be due to new hardware. I'n not aware what is going on, regarding release or release. At full speed I support the way devel team does the work. And contrary, the team has to bear with users, who want to know. I had new desktop and new laptop waiting, since power surge killed some devices at my home. And I waited for 3 months. None could say I was impatient. The release image is on the site. And, if you change RC3 to RELEASE in browser, there is even more. Why would serious guys keep those files available, if not for usage? My best guess is that some packages compile made all that fuss. What else might be? Best regards Zoran You are correct, the hold up that has kept the release from being announced is the recent security incident that could have compromised the package build clusters. It looks like everything is all right after all. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
So, it's fine and recommended to remove ctl device from kernel? I installed from image on the site two weeks ago and consider it release. Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
I always considered FreeBSD to be the most unabiguous, straightforward and sometimes even raw, but still extremely powerful and innovative, operating system out there. Seeing 9.1-RELEASE instead 9.1-PRERELASE or 9.1-RC4 is also a bad suprise for me... I have fallback into RC3 and I think the RELEASE files should be removed as well because there was no RELEASE yet. There is no rush to get RELEASE, I am sure it is better to get RC4, RC5, RC6 and then a RELEASE when its ready. When people get buggy and unstable RELEASE and install it on a production systems they will neither come back to the system nor even support it in future :-( -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On Tue, Dec 25, 2012 at 6:41 PM, Kimmo Paasiala kpaas...@gmail.com wrote: If it works for 99.99% percent of the users and fails for the remaining miniscule percentage because they have a very peculiar hardware, very small amount of ram etc, should the release called buggy and unstable? I really don't think so. Hey hey :-) Its rather a matter of organization, not to rush towards a release (see do we get 9.1 before christmas), if there are known issues (see security, etc). I also started to use RC myself as I found some stuff suprising on 9.0. But when I consider someone to use FreeBSD while there are release made before release, or rarely used stuff added by default that takes 1000% of standard kernel RAM usage, or similar - this does not look serious, this makes people think i will use linux, things like this happens there all the time but i have more drivers, etc, etc. Even for FreeBSD enhousiast it is hard to discuss with people on better organization of FreeBSD over Linux in that case. From what I read there are people working hard to make a release, but we should not rush them at cost of quality. I am still with FreeBSD and I really like it more than Linux, this is why I think quality is more important than bleeding-edge here :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
http://www.freebsd.org/cgi/query-pr.cgi?pr=174671 -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-tp5771583p5771862.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On 23 December 2012 10:22, Ian Smith smi...@nimnet.asn.au wrote:
On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote:
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot.
I've just added that, thanks Sergey, but it's sadly not an option for
installation. I guess it's too late for the release notes - which at
RC3 made no mention of CAM CTL at all - but it's not yet clear to me
whether even 256MB is enough to boot, install and run 9.1 GENERIC?
If you perform clean installation (e.g. from ISO), you can escape to the
loader prompt and set the tunable there w/o the need for /boot/loader.conf.
I experimented with Vbox and AFAIK 256MB was enough even with CAM CTL.
A longer term workaround could be to postpone those memory allocations
until the first call to CTL.
Under what circumstances is CAM CTL needed? What would leaving it out
of GENERIC cost, and whom? Is it loadable? dmesg.boot reports loading,
but I don't see a module, nor can I find much information about CTL in
cam(3|4) or /sys/conf/NOTES. apropos found ctladm and ctlstat, but I'm
little the wiser as to when it may be needed, beyond CAM/SCSI debugging?
The purpose and current status are well documented in the initial commit
message (r229997) and the supplied README.ctl.txt. To my modest knowledge,
it should be safe to just comment out 'device ctl' in GENERIC.
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On 23 Dec 2012 06:40, Adrian Chadd adr...@freebsd.org wrote: Hi guys, Would someone please file a PR for this? This is a huge unused allocation of memory for something that honestly likely shouldn't have been included by default in GENERIC. I've cc'ed ken on a reply to this. Hopefully after the holidays he can chime in and figure out what's going on. Maybe just disabling it in GENERIC moving forward is enough - chances are it'll be fine being just a module. Oh gods... Please let's just make it an erratum notice at this stage! Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On 12/23/2012 01:35 PM, Chris Rees wrote: On 23 Dec 2012 06:40, Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org wrote: Hi guys, Would someone please file a PR for this? This is a huge unused allocation of memory for something that honestly likely shouldn't have been included by default in GENERIC. I've cc'ed ken on a reply to this. Hopefully after the holidays he can chime in and figure out what's going on. Maybe just disabling it in GENERIC moving forward is enough - chances are it'll be fine being just a module. Oh gods... Please let's just make it an erratum notice at this stage! not sure if it helps, I 'vw setting up my old test env, while i tmp resolved the issue by using 9.0, i am interested im getting 9.1 working too... The old test moved producion now, so i needed some time to get new flashcards (which requierd new bioses etc etc) and some other minor fidling. For this nanobsd image I used/tested svn revisons = 243710 ~ 244139 Marten Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-PRERELEASE #0 r244161: Thu Dec 13 08:46:37 CET 2012 root@brie:/usr/obj/nanobsd.full/i386.i386/usr/src/sys/KERNEL i386 CPU: AMD Am5x86 Write-Back (486-class CPU) Origin = AuthenticAMD Id = 0x4f4 Family = 0x4 Model = 0xf Stepping = 4 Features=0x1FPU real memory = 67108864 (64 MB) avail memory = 46436352 (44 MB) kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xc0dce310, 0) error 19 ctl: CAM Target Layer loaded ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. *** WARNING: missing CPU_ELAN -- timekeeping may be wrong pcib0 pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 17.0 on pci0 pci1: PCI bus on pcib1 sis0: NatSemi DP8381[56] 10/100BaseTX port 0xd000-0xd0ff mem 0xa400-0xa4000fff irq 9 at device 0.0 on pci1 sis0: Silicon Revision: DP83816A miibus0: MII bus on sis0 nsphyter0: DP83815 10/100 media interface PHY 0 on miibus0 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c7:aa:04 sis1: NatSemi DP8381[56] 10/100BaseTX port 0xd100-0xd1ff mem 0xa4001000-0xa4001fff irq 9 at device 1.0 on pci1 sis1: Silicon Revision: DP83816A miibus1: MII bus on sis1 nsphyter1: DP83815 10/100 media interface PHY 0 on miibus1 nsphyter1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c7:aa:05 sis2: NatSemi DP8381[56] 10/100BaseTX port 0xd200-0xd2ff mem 0xa4002000-0xa4002fff irq 9 at device 2.0 on pci1 sis2: Silicon Revision: DP83816A miibus2: MII bus on sis2 nsphyter2: DP83815 10/100 media interface PHY 0 on miibus2 nsphyter2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c7:aa:06 sis3: NatSemi DP8381[56] 10/100BaseTX port 0xd300-0xd3ff mem 0xa4003000-0xa4003fff irq 9 at device 3.0 on pci1 sis3: Silicon Revision: DP83816A miibus3: MII bus on sis3 nsphyter3: DP83815 10/100 media interface PHY 0 on miibus3 nsphyter3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis3: Ethernet address: 00:00:24:c7:aa:07 sis4: NatSemi DP8381[56] 10/100BaseTX port 0xe000-0xe0ff mem 0xa000-0xafff irq 10 at device 18.0 on pci0 sis4: Silicon Revision: DP83815D miibus4: MII bus on sis4 nsphyter4: DP83815 10/100 media interface PHY 0 on miibus4 nsphyter4: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis4: Ethernet address: 00:00:24:c1:28:a4 sis5: NatSemi DP8381[56] 10/100BaseTX port 0xe100-0xe1ff mem 0xa0001000-0xa0001fff irq 11 at device 19.0 on pci0 sis5: Silicon Revision: DP83815D miibus5: MII bus on sis5 nsphyter5: DP83815 10/100 media interface PHY 0 on miibus5 nsphyter5: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis5: Ethernet address: 00:00:24:c1:28:a5 sis6: NatSemi DP8381[56] 10/100BaseTX port 0xe200-0xe2ff mem 0xa0002000-0xa0002fff irq 5 at device 20.0 on pci0 sis6: Silicon Revision: DP83815D miibus6: MII bus on sis6 nsphyter6: DP83815 10/100 media interface PHY 0 on miibus6 nsphyter6: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis6: Ethernet address: 00:00:24:c1:28:a6 cpu0 on motherboard isa0: ISA bus on motherboard pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xc8000-0xd0fff pnpid ORM on isa0 ata0: ATA channel at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: ATA channel at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atrtc0: AT realtime clock at port 0x70 irq 8 on isa0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer at port 0x40 on isa0 Timecounter i8254
Re: 9.1 minimal ram requirements
On Sun, 23 Dec 2012 15:21:23 +0300, Sergey Kandaurov wrote:
On 23 December 2012 10:22, Ian Smith smi...@nimnet.asn.au wrote:
On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote:
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot.
I've just added that, thanks Sergey, but it's sadly not an option for
installation. I guess it's too late for the release notes - which at
RC3 made no mention of CAM CTL at all - but it's not yet clear to me
whether even 256MB is enough to boot, install and run 9.1 GENERIC?
If you perform clean installation (e.g. from ISO), you can escape to the
loader prompt and set the tunable there w/o the need for /boot/loader.conf.
I experimented with Vbox and AFAIK 256MB was enough even with CAM CTL.
Ah right; I'd booted and installed from memstick, where escape to loader
prompt is not an option. I'll burn a disc1 and try that with the 128MB
again, and make sure that 256MB is comfortable - after holiday madness.
A longer term workaround could be to postpone those memory allocations
until the first call to CTL.
That would seem to make sense, while making it a module is still on the
todo list. I guess there must be systems that need CAM CTL to boot?
Under what circumstances is CAM CTL needed? What would leaving it out
of GENERIC cost, and whom? Is it loadable? dmesg.boot reports loading,
but I don't see a module, nor can I find much information about CTL in
cam(3|4) or /sys/conf/NOTES. apropos found ctladm and ctlstat, but I'm
little the wiser as to when it may be needed, beyond CAM/SCSI debugging?
The purpose and current status are well documented in the initial commit
message (r229997) and the supplied README.ctl.txt. To my modest knowledge,
it should be safe to just comment out 'device ctl' in GENERIC.
Thanks for the reference, seems that I won't be needing it just now; it
just wasn't clear to me what if any other subsystems might hang off it.
cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
Ok, I'll see about disabling it in GENERIC and STABLE/9 for now, at least until Ken has some idea of what's going on. Thanks, Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
.. has someone filed a PR for it? Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
The reason it grabs RAM up front is that it was written for an embedded
platform where memory allocations might fail later on after things had been
running and memory got fragmented.
At this point, no, it doesn't need to allocate all of its memory up front.
I actually need to put some effort into right-sizing the memory footprint,
but that will take adding some fields to the path inquiry CCB so it knows
what the capabilities of the target adapter are. (And that typically takes
a CAM version bump, which breaks the ABI...)
In any case, the memory footprint (and any possible side effects from
the mpt driver with FC boards) are why I put the disable switch in. If
there is memory allocated when it is disabled, then that is a bug.
I'm on vacation so it'll be a little while before I'm in a position to
fix this, but hopefully the disable switch should help anyone running
with smaller amounts of memory.
Ken
On Sat, Dec 22, 2012 at 22:32:07 -0800, Adrian Chadd wrote:
Ken,
Does CAM CTL really need to pre-allocate 35MB of RAM at startup?
Adrian
On 22 December 2012 16:45, Sergey Kandaurov pluk...@gmail.com wrote:
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl wrote:
On 12/23/2012 12:27 AM, Jakub Lach wrote:
Guys, I've heard about some absurd RAM requirements
for 9.1, has anybody tested it?
e.g.
http://forums.freebsd.org/showthread.php?t=36314
jup, I can comfirm this with nanobsd (cross) compiled
for my soekris net4501 which has 64 MB mem:
from dmesg: real memory = 67108864 (64 MB)
while the same config compiled against a 9.0 tree still works...
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot.
A longer term workaround could be to postpone those memory allocations
until the first call to CTL.
# cam ctl init allocates roughly 35 MB of kernel memory at once
# three memory pools, somewhat under M_DEVBUF, and memory disk
# devbuf takes 1022K with kern.cam.ctl.disable=1
Type InUse MemUse HighUse Requests Size(s)
devbuf 213 20366K - 265
16,32,64,128,256,512,1024,2048,4096
ctlmem 5062 10113K - 5062 64,2048
ctlblk 200 800K - 200 4096
ramdisk 1 4096K -1
ctlpool 532 138K - 532 16,512
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Kenneth Merry
k...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On 12/23/2012 12:27 AM, Jakub Lach wrote: Guys, I've heard about some absurd RAM requirements for 9.1, has anybody tested it? e.g. http://forums.freebsd.org/showthread.php?t=36314 jup, I can comfirm this with nanobsd (cross) compiled for my soekris net4501 which has 64 MB mem: from dmesg: real memory = 67108864 (64 MB) while the same config compiled against a 9.0 tree still works... cheers Marten -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-tp5771583.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl wrote:
On 12/23/2012 12:27 AM, Jakub Lach wrote:
Guys, I've heard about some absurd RAM requirements
for 9.1, has anybody tested it?
e.g.
http://forums.freebsd.org/showthread.php?t=36314
jup, I can comfirm this with nanobsd (cross) compiled
for my soekris net4501 which has 64 MB mem:
from dmesg: real memory = 67108864 (64 MB)
while the same config compiled against a 9.0 tree still works...
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot.
A longer term workaround could be to postpone those memory allocations
until the first call to CTL.
# cam ctl init allocates roughly 35 MB of kernel memory at once
# three memory pools, somewhat under M_DEVBUF, and memory disk
# devbuf takes 1022K with kern.cam.ctl.disable=1
Type InUse MemUse HighUse Requests Size(s)
devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096
ctlmem 5062 10113K - 5062 64,2048
ctlblk 200 800K - 200 4096
ramdisk 1 4096K -1
ctlpool 532 138K - 532 16,512
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote:
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl wrote:
On 12/23/2012 12:27 AM, Jakub Lach wrote:
Guys, I've heard about some absurd RAM requirements
for 9.1, has anybody tested it?
e.g.
http://forums.freebsd.org/showthread.php?t=36314
jup, I can comfirm this with nanobsd (cross) compiled
for my soekris net4501 which has 64 MB mem:
from dmesg: real memory = 67108864 (64 MB)
while the same config compiled against a 9.0 tree still works...
Same as the first message in that forum thread, I tried installing from
i386 9.1-RC3 memstick on a PIII-M with 128MB RAM (Thinkpad T23) and it
panics just a few percent into extracting base.txz, much to my surprise.
I had a 256MB stick and was going to try that instead, but was in a bit
of a hurry so just added it for 384MB and have had no further trouble,
but haven't done anything much with it yet, no X or other packages.
However the same forum user 'Zav' later reports the same panic at 2.5d
uptime with 320MB, after earlier panics with 192MB post-installation
when 'trying to do something', so I'm wondering if even 256MB is enough
for 9.1? .. scratch my ambition to upgrade an older maxed-out 160MB
laptop that runs fine on 5.5 w/X, KDE and all, albeit using some swap.
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot.
I've just added that, thanks Sergey, but it's sadly not an option for
installation. I guess it's too late for the release notes - which at
RC3 made no mention of CAM CTL at all - but it's not yet clear to me
whether even 256MB is enough to boot, install and run 9.1 GENERIC?
A longer term workaround could be to postpone those memory allocations
until the first call to CTL.
Under what circumstances is CAM CTL needed? What would leaving it out
of GENERIC cost, and whom? Is it loadable? dmesg.boot reports loading,
but I don't see a module, nor can I find much information about CTL in
cam(3|4) or /sys/conf/NOTES. apropos found ctladm and ctlstat, but I'm
little the wiser as to when it may be needed, beyond CAM/SCSI debugging?
# cam ctl init allocates roughly 35 MB of kernel memory at once
# three memory pools, somewhat under M_DEVBUF, and memory disk
# devbuf takes 1022K with kern.cam.ctl.disable=1
Type InUse MemUse HighUse Requests Size(s)
devbuf 213 20366K - 265
16,32,64,128,256,512,1024,2048,4096
ctlmem 5062 10113K - 5062 64,2048
ctlblk 200 800K - 200 4096
ramdisk 1 4096K -1
ctlpool 532 138K - 532 16,512
--
wbr,
pluknet
cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
Ken,
Does CAM CTL really need to pre-allocate 35MB of RAM at startup?
Adrian
On 22 December 2012 16:45, Sergey Kandaurov pluk...@gmail.com wrote:
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl wrote:
On 12/23/2012 12:27 AM, Jakub Lach wrote:
Guys, I've heard about some absurd RAM requirements
for 9.1, has anybody tested it?
e.g.
http://forums.freebsd.org/showthread.php?t=36314
jup, I can comfirm this with nanobsd (cross) compiled
for my soekris net4501 which has 64 MB mem:
from dmesg: real memory = 67108864 (64 MB)
while the same config compiled against a 9.0 tree still works...
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot.
A longer term workaround could be to postpone those memory allocations
until the first call to CTL.
# cam ctl init allocates roughly 35 MB of kernel memory at once
# three memory pools, somewhat under M_DEVBUF, and memory disk
# devbuf takes 1022K with kern.cam.ctl.disable=1
Type InUse MemUse HighUse Requests Size(s)
devbuf 213 20366K - 265
16,32,64,128,256,512,1024,2048,4096
ctlmem 5062 10113K - 5062 64,2048
ctlblk 200 800K - 200 4096
ramdisk 1 4096K -1
ctlpool 532 138K - 532 16,512
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
Hi guys,
Would someone please file a PR for this? This is a huge unused
allocation of memory for something that honestly likely shouldn't have
been included by default in GENERIC.
I've cc'ed ken on a reply to this. Hopefully after the holidays he can
chime in and figure out what's going on.
Maybe just disabling it in GENERIC moving forward is enough - chances
are it'll be fine being just a module.
Thanks,
Adrian
On 22 December 2012 16:45, Sergey Kandaurov pluk...@gmail.com wrote:
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl wrote:
On 12/23/2012 12:27 AM, Jakub Lach wrote:
Guys, I've heard about some absurd RAM requirements
for 9.1, has anybody tested it?
e.g.
http://forums.freebsd.org/showthread.php?t=36314
jup, I can comfirm this with nanobsd (cross) compiled
for my soekris net4501 which has 64 MB mem:
from dmesg: real memory = 67108864 (64 MB)
while the same config compiled against a 9.0 tree still works...
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot.
A longer term workaround could be to postpone those memory allocations
until the first call to CTL.
# cam ctl init allocates roughly 35 MB of kernel memory at once
# three memory pools, somewhat under M_DEVBUF, and memory disk
# devbuf takes 1022K with kern.cam.ctl.disable=1
Type InUse MemUse HighUse Requests Size(s)
devbuf 213 20366K - 265
16,32,64,128,256,512,1024,2048,4096
ctlmem 5062 10113K - 5062 64,2048
ctlblk 200 800K - 200 4096
ramdisk 1 4096K -1
ctlpool 532 138K - 532 16,512
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
