Re: 5.5 to 6.1 upgrade
Chuck Swiger: FreeBSD's COMPAT stuff will let you run binaries compiled against an older version of FreeBSD just fine for almost all circumstances. However, as soon as you try to install a new port which depends on something already installed, or upgrade anything, you pretty much really need to upgrade *everything* to be sure that you don't compile new executables which depend on a mixture of COMPAT and current libraries... Yep. Also beware of make delete-old and make delete-old-libs, and ports that build differently depending on the OS version... Helge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb to serial
Marc Fonvieille: On Wed, May 03, 2006 at 08:33:22AM -0400, David Coder wrote: Is there a generic freebsd driver for usb-to-rs-232 adapters? My Thinkpad (running 6.1-RC) doesn't have a standard db-9 port. uftdi(4) for some USB/RS232 adapters. uplcom(4) as well, for example ucom0: Prolific Technology PL2303 Serial adapter (ATEN/IOGEAR UC232A), rev 1.10/2.02, addr 4 Helge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swi4: clock sio uses 10% cpu
Holger, puc0: Titan PCI-800H port 0xa400-0xa41f,0xa000-0xa01f mem 0xdf80-0xdf800fff,0xdf00-0xdf000fff irq 10 at device 11.0 on pci0 puc1: Titan PCI-800H port 0x9800-0x981f,0x9400-0x941f mem 0xde80-0xde800fff,0xde00-0xde000fff irq 10 at device 11.1 on pci0 The Titan device shows up as two PCI devices with shared interrupt. Shared interrupts are supported by the puc(4) driver, but not in fast interrupt mode. This eats a lot of CPU, causes silo overflows and character loss. This is what the kernel tells you: sio12: unable to activate interrupt in fast mode - using normal mode If possible try to make these two different irqs, or disable half of the board. Helge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
OLDCARD vs. NEWCARD revisited
Folks, I own an LG Electronics LW1100P wireless LAN PCI board, consisting of a Texas Instruments TI-1211 PCI-CardBus bridge and a wi(4)-compatible PCCARD. This card is recognized with an OLDCARD kernel but not with a(n almost) GENERIC kernel. I've spotted two oddities with this card and made it work with two rather trivial patches that essentially align NEWCARD a bit more to the OLDCARD behaviour: 1) The card (or the PCI/CardBus bridge?) seems to announce that it runs on 2V or 3.3V voltage. But it is actually lying about 2V support. It just doesn't work @ 2V - which is a rather pointless thing for a PCI card anyway. The delta between OLDCARD and NEWCARD is that OLDCARD did apply power starting with 5V, then 3.3V, then 2V, then 1V, but NEWCARD is doing it the other way 'round. Hence this card ends up with 2V supply and doesn't work. I've filed PR i386/91919 for this which contains a trivial patch reverting the voltage supply order. This might not be the preferred solution but it solves the issue. 2) The CIS on the card does not announce an IRQ preference at all. Hence the default IRQ mask of 0x0 applies and device_attach doesn't see an IRQ. But this is an I/O card which clearly needs an IRQ. I've filed PR i386/92070 for this which contains a trivial patch making 0x the default IRQ mask instead of 0x0. Maybe some kind soul might have a look at the PRs? Actually I think that some OLDCARD/NEWCARD issues that have been reported might be caused by these two oddities. BTW, The PR's relate to 5.4-STABLE but apply to 6.0-STABLE as well. Regards, Helge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrading form 4.2 to 5.x
Remko Lodder: Brent Bailey wrote: Hello, My company has been asked to help with the upgrade of several Freebsd systems that are pretty old. The customer is running a file server samba also running apache running FBSD 4.2, he wants to upgrade using cvsup the make buildworld procedure to upgrade to 5.x. Im very familier with the make buildworld procedure however there have been significant changes between 4.2 5.x so is this something that can be done without many problems ? Aside from reading throught the /usr/src/UPDATING file are there things i should look out for being that the 2 versions are so differrent. personally i would recommend going to the lastest stable release 4.10-p2 I welcome this lists thoughts opions on this matter thank in advance for any help :-) Hey Brent, FreeBSD 5.x has not yet been described as production release ready. So your customer is best advised to use the 4.x branch, and indeed at the moment that is 4.10 (and the patches afterwards ofcourse). Furthermore, the advice is to upgrade to a very recent 4.x first, before taking the step to 5.x. So you´ll probably want to upgrade to 4.10p2 or 4-STABLE anyway. Maybe your customer would like you to go for an updated 4.x first, and go to 5.x later when it will be STABLE. Helge ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
[EMAIL PROTECTED]: Tijl Coosemans [EMAIL PROTECTED] writes: I have an old toshiba which also needs PNPBIOS in 4-STABLE and when I tried 5-CURRENT sound just worked. Of course that doesn't say anything about your setup... PNPBIOS is on by default (and non-optional) in 5.x. That's great, so my peculiar Compaq Deskpro EN scenario should be fine as well. I will try a FreeSBIE boot anyway to verify. BTW, why not make PNPBIOS on by default in 4-STABLE? Is this a danger of breaking things, aka POLA violation against prepare for 5.x upgrade case? Helge ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installation freebsd
nico: Je voudrais savoir si je dois installer une version STABLE ou RELEASE. Quelle est la différence? Pouvez-vous me conseiller entre la freebsd 5.1 ou 4.8 ? 4.x-RELEASE is essentially a snapshot of 4.x-STABLE, with a given x. 4.x-RELEASEs receive security updates only. 4.x-STABLE is the working version that receives all fixes and enhancements. 5.x is CURRENT, not necessarily guaranteed to offer production-grade stability. CURRENT is the main development branch. Again, there are 5.x-RELEASEs, taken as snapshots from CURRENT. There is no 5.x-STABLE yet. Probably, since you ask, 4.9-RELEASE is what you want to start with. http://www.freebsd.org/releases/ Helge ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [4.9-RC] What happened to ``options HTT'' ?
Oliver Fromme: Brooks Davis [EMAIL PROTECTED] wrote: On Tue, Oct 28, 2003 at 11:42:57PM +0200, Jaco van Tonder wrote: I just cvsup'ed to that latest -STABLE and saw that option HTT is no longer availible in LINT. Does anyone know why this is no longer supported? I searched the stable@ list but cant seem to find anything on this. It is no longer necessicary as HTT logical CPUs are now activated by default. If you wish to use them, set the sysctl machdep.hlt_logical_cpus to 0. Can that sysctl be changed at runtime, or is it only possible to do it in the loader? The UPDATING entry isn't completely clear about that. I can confirm from experience that changing this sysctl to 0 immediately started the second logical CPU. Turning it back to 1 apparently stops processes on the second logical CPU to start, instead everything runs on CPU0. However processes running on the second CPU remain there until they terminate. By the way, are there any real world experiences whether it's worth it to use the logical CPUs, say, on a PostgreSQL or Apache server, or with Java stuff (jakarta/tomcat etc.)? That would interest me as well. In particular I would be interested where improvements might be expected - in CPU-intensive environments, interrupt-intensive enviroments, and I/O-intensive environments. I am running a system that walks a couple of thousand files every minute - would that benefit from HTT? (I seem to recall that UFS as part of the kernel is restricted to a single CPU?) Helge ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION AND QUESTIONS
Archie Cobbs: Guido van Rooij wrote: An esp0 or ipsec0 device would provide the handle ipfw needs. That is excatly what I wanted to say earlier. But beware: this is only true in tunnel mode. In transport mode, the KAME stack calls the subprotocol handler directly and, unless you set up your ipsec such that the decrypted packets actually are tunneled packets using a gif interface, you will never be able to catch the packets with a packet filter! This should be easy to fix though. Just have esp_input() requeue the packets on ipintrq instead of calling (*inetsw[ip_protox[nxt]].pr_input) directly. Of course, resetting m-m_pkthdr.rcvif to an appropriate value (esp0 or whatever) would have to be done first. While I (very roughly) understand how it could be implemented, I don't understand how this would work with ESP transport mode. With transport mode, the IP addresses remain unchanged, so essentially we are using publicly routable addresses, and commonly these are on the physical interfaces. How do we make the packets go to esp0 first instead of directly to the physical interface (where the routing table points them to)? Seems to me that we need some trickery routing using shadow routes to make this work, similar to using gif interfaces with ESP tunnel mode. This would add another point of confusion and violate POLA. Seems to me that an esp0 interface is really only useful for ESP tunnel mode. In that case it should be a point-to-point interface similar to gif. Perhaps worth mentioning: ESP transport mode over a gif tunnel is *not* the same as ESP tunnel mode. Having a FreeBSD box with transport mode/gif work against a non-FreeBSD machine in ESP tunnel mode will not work. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: HEADS UP: sendmail 8.12.2 MFC'ed
Yeasah Pell: The question is simply this: why are there large, complex, non-BSD packages in src-contrib that are not critical to the running of many types of systems, and not strictly a dependency of the system proper? Because they always have been. BSD users (those who have been running BSD systems for *years* and not those who jumped on the wagon lately) do expect that a decent, full-function MTA and DNS server are on board by default. And further they expect that those beasts are being configured as they have always been configured, in other words: No learning curve, no additional installation of the ports. This BSD thing is about tradition. Alternative software is what the word says: It's about re-inventing the wheel. This is the Linux spirit. The suggestion that moving sendmail or bind into the ports tree is tantamount to doing the same to vi is interesting, but I see a major difference between the two: I can hardly contrive an example where vi wouldn't be useful to have, whereas I have actually encountered many cases in my work where a DNS server and an MTA are both unwanted and even needed to be removed due to constraints unrelated to name resolution or mail transport. I have the exactly opposite experience. Most of my systems need at least an outbound-only MTA, and it's much easier to add a single rc.conf line than to build a port, set aside installing the entire ports tree first. (Yes, I have a couple of machines without ports tree. Consider, for instance firewalls or VPN gateways.) Moving it into ports will complicate matters for almost everybody, while having some decent full-function package in the base system will make it easy at least for those who use that. Count this my strong vote against removal of packages that are traditionally part of the base system. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: HEADS UP: sendmail 8.12.2 MFC'ed
Karsten W. Rohrbach: Helge Oldach([EMAIL PROTECTED])@2002.03.26 23:26:57 +: [...] standard, well- and widely-known piece of software around. You may not like it but both S*** and B*** are the de facto standards. Period. Please quote correctly and don't falsify my words here. I am not willing to discuss with you showing this unacceptable attitude. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: problem building smbfs module, any hint ?
Christopher Masto: On Thu, Nov 01, 2001 at 10:37:19AM -0800, Luigi Rizzo wrote: ok, thanks for the hint. I still think there is a bug in the dependency then, because at least from what i have seen when KLDfying other modules, you make sure that your kernel contains all is needed for later loading the module. smbfs is strange, partly a port, partly a kernel module, partly dependant on compiling the kernel with certain options (which seem to only be used for smbfs). Actually for 4.4-STABLE is is only a port, installing just smbutil. The Makefile (or pkg-plist) is slightly broken: The kernel module should not be deinstalled (it isn't installed by the port either). See ports/31635. To make it work one needs to add LIBMCHAIN *and* LIBICONV to a GENERIC kernel config. Well, this does work for me... Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Disk I/O problem in 4.3-BETA
Alfred Perlstein: * Kevin Oberman [EMAIL PROTECTED] [010312 13:46] wrote: How serious is the possible corruption issue, anyway. The loss in performance is pretty drastic although it may be that dd is an especially bad case, but I really don't like to corrupt my disks, either. If basically running with blind write caching turned on is akin to running your filesystem in async mode. This is because write caching gives the drive license to lie about completing a write, the various ordering of writes are effectively bypassed. If you crash without these dependancies actually written to the disk, when you come back up you have a good chance of losing large portions of your filesystem. I'd say this is a bit too pessimistic. There is a fundamental difference between softupdates and ATA write-cacheing: Softupdates holds the async data in main RAM while ATA write-cacheing already has it in the (cache memory of the) disk device. Obviously a power outage would affect both situations in a similar way. But during just an operating system crash (assuming power stays up), one should be better off with ATA write-cacheing, as the disk should be able to dump the data from the cache chips to the physical medium. With softupdates async data is just lost. Generally I'd say it's not a bad idea to have write caching on the disk enabled - assuming that it is decently implemented. BTW, don't SCSI disks use write cacheing as well? :-) Just my 2, Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Disk I/O problem in 4.3-BETA
Alfred Perlstein: * Helge Oldach [EMAIL PROTECTED] [010313 00:48] wrote: Alfred Perlstein: If basically running with blind write caching turned on is akin to running your filesystem in async mode. This is because write caching gives the drive license to lie about completing a write, the various ordering of writes are effectively bypassed. If you crash without these dependancies actually written to the disk, when you come back up you have a good chance of losing large portions of your filesystem. I'd say this is a bit too pessimistic. There is a fundamental difference between softupdates and ATA write-cacheing: Softupdates holds the async data in main RAM while ATA write-cacheing already has it in the (cache memory of the) disk device. Obviously a power outage would affect both situations in a similar way. But during just an operating system crash (assuming power stays up), one should be better off with ATA write-cacheing, as the disk should be able to dump the data from the cache chips to the physical medium. With softupdates async data is just lost. Generally I'd say it's not a bad idea to have write caching on the disk enabled - assuming that it is decently implemented. BTW, don't SCSI disks use write cacheing as well? :-) I'm pretty sure you're wrong. I think you misunderstood my argument. Agreed, there is practically no difference in the damage done to softupdates versus write-cacheing during a power outage. But there should be a difference when the OS dies away while power stays up. The OS dying away means that the disk has lots of time to spill out the cached data to the physical medium as it's no longer banged at high data rates by the host. So at least in theory we should be better off in this situation. I'm not 100% certain, but many people working with embedded systems have explained to me that it's no longer safe to assume that write cached data will be sync'd to the disk's media at crash time. That may be correct. But then this breaks my naive understanding of "write caching"... And again: Isn't write-cacheing turned on on SCSI disks? :-) Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Ports updating... Good ways?
Jim Weeks: On Thu, 8 Feb 2001, David Bushong wrote: I'll try to put a "cleanup" mode in one of these days, but it's rather nasty, since basically you have to: pkg_delete all of the versions (including the most recent), pkg_delete all of the programs that depended on older versions, reinstall/rebuild the most recent version, then rebuild the dependent packages. You don't really have to do this. You can remove the info files for the old versions from /var/db/pkg/. For instance, if you have checked pkg_info and found you have two versions of zip ie zip-2.3 and zip-2.2, simply rm -r /var/db/pkg/zip-2.2 Disagree. Consider that zip-2.2 had added a file /usr/local/where/ever which is no longer part of zip-2.3. Now you want that one cleaned up as well, don't you? Having two versions of one port installed is generally a Bad Thing as it may result in orphan files. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /var drive space problem
Sebastien ROCHE: My / partition is 32 Mb large. I had no problem until yesterday, when the make installkernel didn't work due to insufficient space. I think it's /modules which is bigger than it was (and the installation process makes a copy of it). Anyway it was difficult to have it work. I lost /stand and I put /lkm on /usr and I had to delete some binaries in /bin or /sbin that I don't use. Actually you can safely remove /modules and /modules.old after a successful "make buildkernel" (!) while you are in single-user just before "make installkernel". Then even a 32 MB root should suffice. If you want to be on the very safe side you can try removing /modules.old first. Often that suffices. A populated /lkm is pointless on an ELF system anyhow. Also /stand gets outdated quickly :-) and thus can be removed. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.2-stable, ports/packages in XF86 4.0.2
David W. Chapman Jr.: The problem is netscape itself, since it comes in binary format, anyone who ports it doesn't have a choice into which format, I believe the bsdi version of netscape is elf, but I'm not totally sure. It is, and the BSDI binary runs just smoothly on FreeBSD. The only issue is that the latest version is not 4.76 but 4.75. I am not sure whether this is because the BSDI version was not suffering the bug that made Netscape to release 4.76, or whether they just dropped BSDI support. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Dedicated disks (was: Dangerously Dedicated)
Glendon Gross: Is there anyone interested in rewriting that "fake" partition table, Please look at the thread with the same topic three weeks ago. I stated that it wouldn't be possible because there is a fundamental disagreement: BIOS standard demands that the first *sector* always remains reserved. However DD mode only reserves the first *block* and starts with the actual contents at the second block. This (intentionally) violates BIOS standards. Though many BIOSsen will happily accept it, some will get picky and refuse to boot a DD disk due to standards violation. If you would leave the first *sector* reserved with DD mode, you are basically left with the layout of non-DD mode, so this is pointless. or is that requirement satisfied by the non-dedicated format? Exactly. Non-DD follows the BIOS standards, so it will serve you fine, at the "expense" of losing some few kB of disk space. it would be aesthetically more pleasing to be able to use the dedicated format. Fully agree. However there are things in the BIOS architecture that don't care about aesthetics. After all, this is the PC world. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: pcm0: problem
Andre DDAdmin: I'm running 4.1.1-release, and thinking of moving to 4.2-release or stable. the problem occurs whenever I play any sound file. mp3 or wav files. if the sound card is in use and I move my mouse, it gives me this error. pcm0: hwptr went backwards - pcm0: hwptr went backwards - pcm0: hwptr went backwards - Although this entirely harmless it is fixed with 4.2-RELEASE. You want to upgrade. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make installworld from nfs directory
Hurf Sheldon: We've built oa 4.2-STABLE /usr/src (loaded with cvsup) tree by running "make buildworld", then a "make installworld" on machine "A" (originally a 4.0-RELEASE), then built a new kernel, which worked fine. Now we NFS mount the machine "A":/usr/src to machine "B":/usr/src (also 4.0-RELEASE) and run "make installworld" which dies with the message: "install: /usr/src/include/osreldate.h: No such file or directory" The build logon machine "A" says this file was created on the fly during the "make buildworld" by 'newconf.sh' . Do we have to do a "make buildworld" on every system? You need to mount A:/usr/obj to /usr/obj on B as well. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: can't flash Cisco 2516 using rcp (recv BAD, Login incorrect.
Andreas Klemm: On Fri, Dec 01, 2000 at 10:16:17AM +0100, Helge Oldach wrote: Andreas Klemm: Address or name of remote host [172.16.2.1]? Source username [ios]? ^^^ ip rcmd remote-host andreas 172.16.2.1 andreas enable ip rcmd remote-host cisco 172.16.2.1 cisco enable ip rcmd remote-host cron 172.16.2.1 cron enable ip rcmd remote-username andreas ip rcmd source-interface Ethernet0 /home/andreas/.rhosts has proper permissions: -rw--- 1 andreas andreas 174 1 Dez 07:56 /home/andreas/.rhosts Perhaps this is a username problem? The router wants to talk to the user "ios" and not to "andreas". andreas:xx:1001:1001::0:0:Andreas Klemm:/home/andreas:/bin/tcsh ios:xx:1001:1001::0:0:IOS:/home/andreas/tftpboot:/bin/tcsh Its the same user (UID) but different HOME dir OK. But you do have a proper /home/andreas/tftpboot/.rhosts? And /home/andreas/tftpboot and its contents is world readable? Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Dangerously Dedicated
Chad R. Larson: I think earlier in this thread was a reference to a document somewhat later than the BIOS code shipped with an AT. Which probably makes some sense as FreeBSD won't run on a plain IBM AT box anyway... Do we want to start a new thread on what exactly =is= the authoritative documentation for PC architecture? The real issue is FreeBSD has to be able to boot on the hardware that's in the stores. Having abandoned my i486 Overdrive box just a week ago in favor of a decent 166 MHz (gee!) Pentium CPU, I'd like to claim that FreeBSD should be able to boot on hardware that's in the field rather than in the stores. That's definitely the bigger number of variants. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.2 Beta Broke ahc Support for AHA2842
Dave Tweten: My old kernel, vintage 4.1.1, works fine with my three old Adaptec SCSI host bus adapters, two AHA1742A's and an AHA2842VL (yes, it's an old motherboard). I've cvsupped 4.2 a couple of times (most recently November 9, 14:26 PST), built world, built kernel, installed kernel, and tried to reboot. The following behavior happened both times: Early boot output looks like: ahb0: Adaptec 174x SCSI host adapter at 0x1c00-0x1cff, irq 11 (level) ahb0: on disa0 slot 1 ahb0: AHA1742A Single Ended SCSI Adapter, FW Rev. E , ID=7, 64 ECBs ahb1: Adaptec 174x SCSI host adapter at 0x2c00-0x2cff, irq 12 (level) ahb1: on eisa0 slot 2 ahb1: AHA1740A Single Ended SCSI Adapter, FW Rev. E , ID=6, 64 ECBs ahc0: Adaptec 284X SCSI Adapter at 0x8c00-0x8cff, irq 10 (edge) ahc0: on eisa0 slot 8 aic7770: Single Channel A, SCSI Id=7, 4/255 SCBs which corresponds to the output from a 4.1.1 kernel. Later, however, comes: ahc0: brkadrint, Illegal Sequencer Address referenced at seqaddr = 0x3 SCB count = 10 Waiting Queue Entries: Disconnected Queue Entries: QOUTFIFO entries: Sequencer Free SCB List: 0 1 2 3 Pending list: Kernel Free SCB list: 8 7 6 5 4 3 2 1 0 Waiting 5 seconds for SCSI devices to settle. ahb0: SCSI Bus Reset Delivered ahb1: SCSI Bus Reset Delivered Justin had just fixed this yesterday and MFC'd into STABLE. I had the same error on an aic7770 adapter which is gone now after making a new kernel. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
