Re: 7 on Soekris net4801?
On Sat, 3 Nov 2007, Henrik Brix Andersen wrote: On Sun, Nov 04, 2007 at 02:59:36AM +1100, Ian Smith wrote: any particular/new issues with RELENG_7 on the Soekris net4801? Thought I should check before upgrading my T23 as a build platform .. I haven't done this before, and will be relying on the howtos for 6.X I recently upgraded two of my net4801s to RELENG_7 - the only problem I have seen so far, is that savecore(8) attempts to do non-aligned DMA transfers and fails. I haven't had time to dig further into this issue yet, though. Thanks, Brix. I'm wondering if that's still (again?) to do with item 3 at http://www.soekris.com/Issue0003.htm ? I've no idea whether a similar 'quick-fix' to that given for FreeBSD 4.X to /sys/dev/ata/ata-dma.c would work with the 5.5-S and 6.1-R code I have here, noting that the alignment is now specified in bytes rather than the earlier bytes-1, so '4' is presumably the value needed for dword alignment. Hmm, ok, trying to dig a little deeper .. rev 1.118 notes say: Add support for a the National Geode SC1100. Thanks to Soekris engineering for sponsoring a Soekris 4801 to make this support. but I couldn't find anywhere in 1.118 or in later versions up to 1.147 (RELENG_7, HEAD) that does anything other than 'ch-dma-alignment = 2;' (Not that me not finding it means much :) I also noticed at 1.137.2.2: Add support for using DMA on dump, greatly speeds up the dump process. Copying Soren in case he may have a bead on this, but it hardly seems any impediment to preparation or building for it when the box arrives. Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
usb card reader problem
Howdy! I'd like to know how card readers, using umass, behave on future 6.3 or 7.0. On my amd64 6.2, after loading umass module, only first time I connect usb cable to it I see reading of da devices. No daxs1 in /dev direc- tory. Next remove/connect of usb reader gives nothing at all. Any news? Of course, it is always possible I missed some necessary step. Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7 on Soekris net4801?
On Sun, 2007-11-04 at 02:59 +1100, Ian Smith wrote: Hi, any particular/new issues with RELENG_7 on the Soekris net4801? I did not experiance any issues on on wrap/net4826 boards.. only issues with tinybsd (ssh and polulating /var /tmp) I 'll post that later on small@ kind regards, Marten ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD-BETA2 Signal 11 During Install
On Sun, 2007-11-04 at 00:28 -0400, [EMAIL PROTECTED] wrote: Byung-Hee HWANG wrote: Hi, On Sat, 2007-11-03 at 18:27 -0400, [EMAIL PROTECTED] wrote: Hi, I tested out FreeBSD 7.0-BETA2 [...] Really? I think you are from the future.. lftp :~ open freebsd.mirrors.tds.net lftp freebsd.mirrors.tds.net:~ cd pub/FreeBSD/releases/i386/ISO-IMAGES cd ok, cwd=/pub/FreeBSD/releases/i386/ISO-IMAGES lftp freebsd.mirrors.tds.net:/pub/FreeBSD/releases/i386/ISO-IMAGES cd 7.0 lftp freebsd.mirrors.tds.net:/pub/FreeBSD/releases/i386/ISO-IMAGES/7.0 ls -rw-r--r--1 ftp ftp 116736000 Nov 02 17:20 7.0-BETA2-i386-bootonly.iso -rw-r--r--1 ftp ftp 669032448 Nov 02 17:21 7.0-BETA2-i386-disc1.iso [...snip...] oh.. thanks! thanks! i go to upgrade to BETA2! -- I trust these two men with my life. They are my two right arms. I cannot insult them by sending them away. -- Vito Corleone, Chapter 1, page 29 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD-BETA2 Signal 11 During Install
[EMAIL PROTECTED] wrote: Byung-Hee HWANG wrote: Hi, On Sat, 2007-11-03 at 18:27 -0400, [EMAIL PROTECTED] wrote: Hi, I tested out FreeBSD 7.0-BETA2 [...] Really? I think you are from the future.. lftp :~ open freebsd.mirrors.tds.net lftp freebsd.mirrors.tds.net:~ cd pub/FreeBSD/releases/i386/ISO-IMAGES cd ok, cwd=/pub/FreeBSD/releases/i386/ISO-IMAGES lftp freebsd.mirrors.tds.net:/pub/FreeBSD/releases/i386/ISO-IMAGES cd 7.0 lftp freebsd.mirrors.tds.net:/pub/FreeBSD/releases/i386/ISO-IMAGES/7.0 ls -rw-r--r--1 ftp ftp 116736000 Nov 02 17:20 7.0-BETA2-i386-bootonly.iso -rw-r--r--1 ftp ftp 669032448 Nov 02 17:21 7.0-BETA2-i386-disc1.iso -rw-r--r--1 ftp ftp372736 Nov 02 17:21 7.0-BETA2-i386-disc2.iso -rw-r--r--1 ftp ftp 232144896 Nov 02 17:22 7.0-BETA2-i386-docs.iso -rw-r--r--1 ftp ftp 266 Nov 02 17:22 CHECKSUM.MD5 -rw-r--r--1 ftp ftp 406 Nov 02 17:22 CHECKSUM.SHA256 It was released on November 2nd. Unless someone on accident uploaded the beta 2 images by mistake at the wrong time, it exists. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh: Revision *1.72.2.3 *Branches: RELENG_7 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh?only_with_tag=RELENG_7 Get ready for the BETA2 builds. And yes beta2 exist not only on mirrors but on the main ftp too. Normally announces are little late to give enough time for all mirrors to sync new iso images. So let's focus on the real problem :) Russell Doucette ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 7.0-BETA2 Available
The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available. The checksums for the currently available ISOs are: MD5 (7.0-BETA2-amd64-bootonly.iso) = 281df205655164713eb9df549486e0db MD5 (7.0-BETA2-amd64-disc1.iso) = ccd2ff3d8a1c4a08364e1be3a6a11c7a MD5 (7.0-BETA2-amd64-disc2.iso) = 461d9878c313646ef7319386952c5db7 MD5 (7.0-BETA2-amd64-docs.iso) = ff778f8ea78c31fa23738b824fd1cfd0 MD5 (7.0-BETA2-amd64-livefs.iso) = 90e01fdd44bbf2578cf0f82cef1b0b5f MD5 (7.0-BETA2-i386-bootonly.iso) = 1e9e9fdf946898ee5d93159eeb18df2c MD5 (7.0-BETA2-i386-disc1.iso) = 27b676f5084bc90ad9d99c4dfd1680db MD5 (7.0-BETA2-i386-disc2.iso) = 3a5a3a0582ac78e0853189a041ec1930 MD5 (7.0-BETA2-i386-docs.iso) = a9d0886c07c10e2a0f28cb144b7f3895 MD5 (7.0-BETA2-pc98-bootonly.iso) = aeee6decc1a3c620a0a271cdd0536a07 MD5 (7.0-BETA2-pc98-disc1.iso) = 5817e9ca01eb41aabe264336085870b2 MD5 (7.0-BETA2-sparc64-bootonly.iso) = 4f1c9bad4bc6d43c87eef33189c89125 MD5 (7.0-BETA2-sparc64-disc1.iso) = 1e2d4dcfcc206d0efb9e6ff6dda3d554 MD5 (7.0-BETA2-sparc64-disc2.iso) = ff975432eed1facee6f86ad32388bb37 SHA256 (7.0-BETA2-amd64-bootonly.iso) = f7596d902faa66122d0d8e13386ac6aed7666400e9b1cdd8461da75e628f0cbf SHA256 (7.0-BETA2-amd64-disc1.iso) = 09bbe1dcb9e538899a3f71421753fa79c4784839021253dcdac07fba4f494327 SHA256 (7.0-BETA2-amd64-disc2.iso) = fef9d81797b26f6b6f840c28b0c0523fdfc3fe457c0a7927ad39010fde633790 SHA256 (7.0-BETA2-amd64-docs.iso) = aa14566df1221297c7ceea83080b69f76082ca1096dd34e4b8f45281e069f9c6 SHA256 (7.0-BETA2-amd64-livefs.iso) = e17e0afeae2d7ee70bef8ecdd2a50083a0dba784b617c5eda01ce4ccaf65fcac SHA256 (7.0-BETA2-i386-bootonly.iso) = 4aa17e88f84d05cb83c0aeec0ced3dd8b9523f2ca262a3db32cbdbdb6a713b5b SHA256 (7.0-BETA2-i386-disc1.iso) = 565e0d41a2aa98cb5dcc5fd1b9cd8a06e5ec7cd293351563937ef38c19002738 SHA256 (7.0-BETA2-i386-disc2.iso) = a4407612a9e63f3f124c41b2fce60d396a7968f3c01d1fdde7a5a1ade1c763c8 SHA256 (7.0-BETA2-i386-docs.iso) = 15f03146d095d99c6129e0d4101489a23ace43b89987a6c577cae593d44564a9 SHA256 (7.0-BETA2-pc98-bootonly.iso) = a7609eb00097008b58a98f01134a9cf8254019a33ed82e7ff3f20332c52ac2ca SHA256 (7.0-BETA2-pc98-disc1.iso) = 0d69b6f0c8b7eb5ee096d8921330f1cc4842b02ebe580c268aa7b5955f5e117f SHA256 (7.0-BETA2-sparc64-bootonly.iso) = 58d31e4e6317f5b09e9502d56511145b73df9d39b830fc53fc076393bbd978f6 SHA256 (7.0-BETA2-sparc64-disc1.iso) = 1e0e740748748be15ce4e8c981840746b041611ad938fd62d75bd59324ece670 SHA256 (7.0-BETA2-sparc64-disc2.iso) = ceacabbc6f7c7aaf30eaf0017df240b843b4041a9fa35d4ee1110dced3cda206 -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: FreeBSD 7.0-BETA2 Available
On Sun, 2007-11-04 at 06:31 -0500, Ken Smith wrote: The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. [...] It works fine, thanks! [EMAIL PROTECTED]:~ uname -a FreeBSD viola.izb.knu.ac.kr 7.0-BETA2 FreeBSD 7.0-BETA2 #1: Sun Nov 4 20:11:14 KST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Sincerely, -- They shot him five times. But he's though. -- Santino Corleone, Chapter 2, page 79 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7 on Soekris net4801?
On Sun, 4 Nov 2007 09:02:42 +0100, Marten Vijn wrote: On Sun, 2007-11-04 at 02:59 +1100, Ian Smith wrote: any particular/new issues with RELENG_7 on the Soekris net4801? I did not experiance any issues on on wrap/net4826 boards.. only issues with tinybsd (ssh and polulating /var /tmp) I 'll post that later on small@ That'll be great, there's been nothing in -small for months. Thanks, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7 on Soekris net4801?
On Mon, Nov 05, 2007 at 01:09:14AM +1100, Ian Smith wrote: On Sun, 4 Nov 2007 09:02:42 +0100, Marten Vijn wrote: only issues with tinybsd (ssh and polulating /var /tmp) I 'll post that later on small@ That'll be great, there's been nothing in -small for months. That's because -small@ was obsoleted by -embedded@ -- see http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpBQnaTIsCn4.pgp Description: PGP signature
Re: kern/104406: [ufs] Processes get stuck in ufs stateunderpersistent CPU load
Oleg Derevenetz wrote: Dumpdev is swap partition on da0 (single physical disk) that connected to Mylex AcceleRAID 170 RAID controller. The problem arrives when I copy large amount of files from FTP to another disk (da1) that is connected to the same RAID controller. If the driver or controller is misbehaving it could explain both problems. Any chance you can get another disk in there on a different controller to dump onto? Yes, I got IDE disk and saved kernel dump for another static hang state on it. Here is the dump: ftp://oleg.vsi.ru/private/vmcore.0.zip Is this just the vmcore, or the debugging kernel also? Both are needed to make sense of the dump. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-BETA2 Available
On Sunday 04 November 2007, Ken Smith wrote: The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available. These release announcements seem to be shorter and shorter with every release. Is there a changelog to see what has changed since BETA1? If so, would you please consider linking to it in future announcements? Thanks a lot :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD-6.2, 7.0-BETA1 boot on Lenovo X60
Hello All, Last few days I try to boot FreeBSD-6.2, 7.0-BETA1 boot CD using USB CDROM drive on Lenovo X60. It give kind of assembler code non-stop flow over screen. Can't boot system and some times give BTX halted message after CPU register code ES=, Is there any way to boot/install FreeBSD-6.2/7.0-BETA on X60? Regards, Balgaa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD-6.2, 7.0-BETA1 boot on Lenovo X60
Balgansuren Batsukh wrote: Last few days I try to boot FreeBSD-6.2, 7.0-BETA1 boot CD using USB CDROM drive on Lenovo X60. It give kind of assembler code non-stop flow over screen. This is a well-known issue with the USB support of some BIOSes (these days, actually most of them). The BIOS uses protected mode, while BTX also does, and this clashes. You'll need to wire up an IDE or SATA optical drive, or fiddle with PXE to get FreeBSD installed. On my X41, which is the predecessor to your X60, I installed OpenBSD instead... :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of MySQL on 7 w/o patches applied
- Original Message From: Peter Schuller [EMAIL PROTECTED] To: Ivan Voras [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, November 4, 2007 3:22:08 PM Subject: Re: Status of MySQL on 7 w/o patches applied So to follow-up, with RELENG_7 the performance is now significantly better than 6.2 for me too. I guess it was the debugging options in userland. If someone wants details anyway I'll provide them, but since it is no longer that interesting I'm leaving it as is if no one speaks up. It's always interesting to get third party confirmations on such benchmarks so please post them :) Better late than never... So to recap, these tests were done on single-processer AMD64 machines with 512 MB of memory. So nothing as interesting as SMP scalability and such, but still interesting to see an increase in absolute speed in the simple case. They were also performed maintaly with the 4BSD scheduler. Due to the reason for running these tests, they were also made with MyISAM rather than InnoDB, prepared as such: sysbench --test=oltp \ --mysql-table-engine=myisam \ --oltp-table-size=100 \ prepare And run as such: sysbench --num-threads=16 \ --max-requests=10 \ --test=oltp \ --oltp-table-size=1 \ --mysql-socket=/tmp/mysql.sock \ --oltp-read-only \ run The MySQL version is 5.0.45_1 in both cases, compiled from ports with default build settings, and (on purpose) default MySQL runtime settings (empty my.cnf). Nothing in loader.conf on either machine. On the RELENG_7 one I tried the following, one at a time, but none of them caused a different time source to be chosen (probably because I was doing it the wrong way): kern.timecounter.tc.TSC.quality=1000 kern.timecounter.hardware=TSC kern.timecounter.choice=TSC(1200) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.smp_tsc=1 CPU details (6.2 machine, then RELENG_7 machine): CPU: AMD Athlon(tm) 64 Processor 3200+ (1989.81-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x40ff2 Stepping = 2 Features=0x78bfbff ,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1d,,CR8 CPU: AMD Athlon(tm) 64 Processor 3200+ (1989.82-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x40ff2 Stepping = 2 Features=0x78bfbff ,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1d And the sysbench results: 6.2: OLTP test statistics: queries performed: read:140 write: 0 other: 20 total: 160 transactions:10 (261.10 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 140 (3655.45 per sec.) other operations:20 (522.21 per sec.) Test execution summary: total time: 382.9903s total number of events: 10 total time taken by event execution: 6125.6312 per-request statistics: min:0.0028s avg:0.0613s max:0.8482s approx. 95 percentile: 0.0697s Threads fairness: events (avg/stddev): 6250./94.01 execution time (avg/stddev): 382.8520/0.01 RELENG_7 from October 16: OLTP test statistics: queries performed: read:140 write: 0 other: 20 total: 160 transactions:10 (292.50 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 140 (4095.01 per sec.) other operations:20 (585.00 per sec.) Test execution summary: total time: 341.8797s total number of events: 10 total time taken by event execution: 5468.4663 per-request statistics: min:0.0028s avg:0.0547s max:0.8707s approx. 95 percentile: 0.0561s Threads fairness: events (avg/stddev): 6250./124.43 execution time (avg/stddev): 341.7791/0.01 -- / Peter Schuller Peter, Could you please try this patch Jeff posted in FreeBSD-performance@ ? Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best
Re: FreeBSD-BETA2 Signal 11 During Install
Hi, Yes I have tis problem since beta1! Signal 11 appears in sysinstall when it try to get INDEX from ftp site. At the end of this operation appears signal 11 and core dumps (the same as Russell Doucette has). So I have installed 7BETA2, without X - it allow me to avoid installation of binary packages after installing ports collection. Then I compile the cvsup from the port collection and syncronize src-all with RELENG_7 and doc-all, ports-all with CURRENT. After in I recompile all system (kernel and world). For kernel I have my own config. but the problem has lefted! When sysinstall try to read INDEX from ftp site appears signal 11 (as I think) and programm crushes. On the screen appears such error: Bus error (core dumped) I have amd64 FreeBSD7 beta2 (this problem was in beta1 and beta1.5) Mihail. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-BETA2 Available
Olli Hauer wrote: Ken Smith wrote: The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available. The checksums for the currently available ISOs are: G, Just updated from the source rebuild world and kernel do debug a system hang and notice after hours of recompile (during system hang) that this part is missing in GENERIC (BETA2) # Debugging for use in -current optionsKDB # Enable kernel debugger support. optionsDDB # Support DDB. optionsGDB # Support remote GDB. optionsINVARIANTS # Enable calls of extra sanity checking optionsINVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS optionsWITNESS # Enable checks to detect deadlocks and cycles optionsWITNESS_SKIPSPIN# Don't run witness on spinlocks for speed I always thought this will removed if BETA? and RC? phase finished. Please correct me if I'm wrong. Yes, you're wrong. The debugging options are removed early in the beta cycle when the branch occurs, not at the end right before release. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-BETA2 Available
Kris Kennaway wrote: Olli Hauer wrote: Ken Smith wrote: The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available. The checksums for the currently available ISOs are: G, Just updated from the source rebuild world and kernel do debug a system hang and notice after hours of recompile (during system hang) that this part is missing in GENERIC (BETA2) # Debugging for use in -current optionsKDB # Enable kernel debugger support. optionsDDB # Support DDB. optionsGDB # Support remote GDB. optionsINVARIANTS # Enable calls of extra sanity checking optionsINVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS optionsWITNESS # Enable checks to detect deadlocks and cycles optionsWITNESS_SKIPSPIN# Don't run witness on spinlocks for speed I always thought this will removed if BETA? and RC? phase finished. Please correct me if I'm wrong. Yes, you're wrong. The debugging options are removed early in the beta cycle when the branch occurs, not at the end right before release. Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Thanks, Please forgive me the noise new kernel build has started ... olli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-BETA2 Available
Ken Smith wrote: The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available. The checksums for the currently available ISOs are: G, Just updated from the source rebuild world and kernel do debug a system hang and notice after hours of recompile (during system hang) that this part is missing in GENERIC (BETA2) # Debugging for use in -current optionsKDB # Enable kernel debugger support. optionsDDB # Support DDB. optionsGDB # Support remote GDB. optionsINVARIANTS # Enable calls of extra sanity checking optionsINVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS optionsWITNESS # Enable checks to detect deadlocks and cycles optionsWITNESS_SKIPSPIN# Don't run witness on spinlocks for speed I always thought this will removed if BETA? and RC? phase finished. Please correct me if I'm wrong. olli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD-6.2, 7.0-BETA1 boot on Lenovo X60
On Sun, 4 Nov 2007 23:49:13 +0800 Balgansuren Batsukh [EMAIL PROTECTED] wrote: Last few days I try to boot FreeBSD-6.2, 7.0-BETA1 boot CD using USB CDROM drive on Lenovo X60. Can't boot system and some times give BTX halted message after CPU register code ES=, Take a look at this: http://hack.org/mc/freebsd-x60.html or try the boot floopies: ftp://ftp7.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/floppies/ ftp://ftp7.freebsd.org/pub/FreeBSD/releases/i386/7.0-BETA2/floppies/ Andreas -- GnuPG key : 0x2A573565 | http://cyb.websimplex.de/pubkey.asc Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 pgpVXrYvfCmLI.pgp Description: PGP signature
Re: FreeBSD-6.2, 7.0-BETA1 boot on Lenovo X60
Andreas Rudisch wrote: or try the boot floopies: ftp://ftp7.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/floppies/ ftp://ftp7.freebsd.org/pub/FreeBSD/releases/i386/7.0-BETA2/floppies/ There's no floppy drive in the X series ThinkPads, so you'll end up using an USB floppy drive. This will probably lead to the same BTX loader problem as with USB CD-ROM drives. The same is probably applicable to booting from USB sticks, and I'm not even sure FreeBSD supports booting off those. AFAIK the only non-PXE alternative is using the UltraBase docking station, which has an optical drive bay connected via ATAPI. But it's rather expensive; here in .nl, it's about EUR 175 for the dock, and EUR 130 for the CD-RW/DVD drive (not even a DVD writer!!). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Source upgrade from 5.5 to 6.X not safe?
On Fri, 2 Nov 2007, [LoN]Kamikaze wrote: Well, in this case after running 'make installkernel' and rebooting, the system did not come back up because it got kernel fatals on reboot (fatal trap 12: page fault while in kernel mode). It appears that my filesystems got marked dirty in the reboot loop that ensued, and I had to manually fsck them. I figured after that it might boot, but alas problems remained, so after grabbing a disc1 image of 6.2 on CDROM I moved kernel.old back and kernel to kernel.bad. Now, sometimes I work fast and loose with the rules of upgrading, but I was surprised that I managed to royally screw up things. Any pointers would be appreciated before I shave off a few years of my life again. I think you might have no choice but to omit the reboots, because the world contains lots of stuff that has to do with the kernel (like mounting). So just go into single user mode and do the usual stuff: # make installkernel # mergemaster -p # make installworld # mergemaster # shutdown -r now and pray to your deity of choice. If the reason for your problem is something else however you're stuck with a system that can not run with your old kernel. So better backup before you try. In general, new kernels can reliably run old user spaces, but not new user spaces on old kernels. This is because new user spaces often grow dependencies on new system calls, etc, that have appeared in the kernel, and a system call being missing can lead to rather extreme unhappiness if, say, it's in libc :-). When I upgrade a remote systems, I'll actually almost always run a few days with the new kernel and the old user space to make sure everything has settled nicely before doing the user space upgrade, which is harder to revert. Reverting to an old kernel is easy, and leaving the door open is likewise easy -- as long as you don't installworld. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/104406: [ufs] Processes get stuck in ufs stateunderpersistent CPU load
Dumpdev is swap partition on da0 (single physical disk) that connected to Mylex AcceleRAID 170 RAID controller. The problem arrives when I copy large amount of files from FTP to another disk (da1) that is connected to the same RAID controller. If the driver or controller is misbehaving it could explain both problems. Any chance you can get another disk in there on a different controller to dump onto? Yes, I got IDE disk and saved kernel dump for another static hang state on it. Here is the dump: ftp://oleg.vsi.ru/private/vmcore.0.zip Is this just the vmcore, or the debugging kernel also? Both are needed to make sense of the dump. Kernel binary with kernel config is here: ftp://oleg.vsi.ru/private/kernel.zip This kernel was built statically, and no modules loaded on boot at all. -- Oleg Derevenetz [EMAIL PROTECTED] OOD3-RIPE Phone: +7 4732 539880 Fax: +7 4732 531415 http://www.vsi.ru CenterTelecom Voronezh ISPhttp://isp.vsi.ru ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Source upgrade from 5.5 to 6.X not safe?
On Nov 04, Robert Watson wrote: When I upgrade a remote systems, I'll actually almost always run a few days with the new kernel and the old user space to make sure everything has settled nicely before doing the user space upgrade, which is harder to revert. Reverting to an old kernel is easy, and leaving the door open is likewise easy -- as long as you don't installworld. This is sort of what I was hoping to try, but alas I crashed and burned before I could even get the new kernel up and running. I never answered another question posed, and that was whether or not I rebooted in single-user mode - I did not. I also did not install the kernel while in single-user mode because, well, I'm the only user :) Your comment seemed to imply that it can be a safe operation to reboot and run the machine regularly after make installkernel. Am I reading that correctly? In general, is it possible that the installkernel did /not/ complete correctly before I shut down? Is it ever possible that the machine could get put into an indeterminate state when doing installkernel on a running machine? HP-UX used to behave horribly when a binary got clobbered for a process that was running, but I have no idea how FreeBSD copes with changing disk images of a running process. Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Best way to use more that 4 gigs of memory ?
I have been doing some experiments with runnign 32 bit processed on and amd64 kernel over the last couple of days and am wondering what the general feel is for the best way to use over 4 gigs of memory. As far as I can see I have 3 options: 1) amd64 kernel + 64 bit processes 2) amd64 kernel + 32 bit processes 3) i386 kernel with PAE and 32 bit processes I was initially thinking that option 1 was the best, but benchmarking it the programs take 3 times longer to run that option 2! This astounds me and I intend to investigate why, but given it is rue then that rules it out as a viable solution for deploying stuff. Which leaves either 32 bit processes on a 64 bit kernel or alternatively running under PAE on a 32 bit kerenel. I don't know a lot about PAE and was wondering if anyone had any advice either way as to which wouldbe the most stable and/or best performing. cheers, -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[SOLVED] Re: freebsd-7.0b1 xorg-7.3_1 runs only once
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 02 Nov 2007 13:24:04 -0700, Mark Atkinson [EMAIL PROTECTED] wrote: J.R. Oldroyd wrote: xorg-7.3_1 runs fine, but just once. Subsequent attempts to start xorg result in: (EE) I810(0): V_BIOS address 0x0 out of range (EE) I810(0): VBE initialization failed. (EE) Screen(s) found, but none have a usable configuration. I also have this problem on with the i915 module. There are some differences in agp between -current/7.0 and -stable, but i915 and drm have been MFC'd between stable and current, so I'm not sure what's up. The problem goes away if you deinstall x11-drivers/xf86-video-i810 and use in its place x11-drivers/xf86-video-intel. There's further discussion about this over on the x11@ list. -jr -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHLjiils33urr0k4kRAstkAJ4oak02MEwL3As1EqEx4CWGpFwiAACfb2oF 4OJkloq7/t7hhep5c6DSTGI= =m4jU -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/104406: [ufs] Processes get stuck in ufs stateunderpersistent CPU load
Oleg Derevenetz wrote: Dumpdev is swap partition on da0 (single physical disk) that connected to Mylex AcceleRAID 170 RAID controller. The problem arrives when I copy large amount of files from FTP to another disk (da1) that is connected to the same RAID controller. If the driver or controller is misbehaving it could explain both problems. Any chance you can get another disk in there on a different controller to dump onto? Yes, I got IDE disk and saved kernel dump for another static hang state on it. Here is the dump: ftp://oleg.vsi.ru/private/vmcore.0.zip Is this just the vmcore, or the debugging kernel also? Both are needed to make sense of the dump. Kernel binary with kernel config is here: ftp://oleg.vsi.ru/private/kernel.zip This kernel was built statically, and no modules loaded on boot at all. -- Oleg Derevenetz [EMAIL PROTECTED] OOD3-RIPE Phone: +7 4732 539880 Fax: +7 4732 531415 http://www.vsi.ru CenterTelecom Voronezh ISPhttp://isp.vsi.ru That kernel doesn't appear to match with the vmcore, are you sure it is the right one? Are you able to successfully run kgdb on these locally? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best way to use more that 4 gigs of memory ?
1) amd64 kernel + 64 bit processes 2) amd64 kernel + 32 bit processes 3) i386 kernel with PAE and 32 bit processes I was initially thinking that option 1 was the best, but benchmarking it the programs take 3 times longer to run that option 2! This astounds me and I intend to investigate why, but given it is rue then that rules it out as a viable solution for deploying stuff. How did you benchmark? Maby there are some hints on tune/optimize? -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best way to use more that 4 gigs of memory ?
Hi, On 4 Nov 2007, at 21:11, Pete French wrote: I have been doing some experiments with runnign 32 bit processed on and amd64 kernel over the last couple of days and am wondering what the general feel is for the best way to use over 4 gigs of memory. As far as I can see I have 3 options: 1) amd64 kernel + 64 bit processes 2) amd64 kernel + 32 bit processes 3) i386 kernel with PAE and 32 bit processes I was initially thinking that option 1 was the best, but benchmarking it the programs take 3 times longer to run that option 2! This astounds me and I intend to investigate why, but given it is rue then that rules it out as a viable solution for deploying stuff. I had similar results, I surmise (without evidence) it's to do with cache usage. Which leaves either 32 bit processes on a 64 bit kernel or alternatively running under PAE on a 32 bit kerenel. I don't know a lot about PAE and was wondering if anyone had any advice either way as to which wouldbe the most stable and/or best performing. If your workload is CPU-intensive it probably doesn't matter; if it isn't, I'd do some more experiments. cheers, -pcf. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/104406: [ufs] Processes get stuck in ufs stateunderpersistent CPU load
Dumpdev is swap partition on da0 (single physical disk) that connected to Mylex AcceleRAID 170 RAID controller. The problem arrives when I copy large amount of files from FTP to another disk (da1) that is connected to the same RAID controller. If the driver or controller is misbehaving it could explain both problems. Any chance you can get another disk in there on a different controller to dump onto? Yes, I got IDE disk and saved kernel dump for another static hang state on it. Here is the dump: ftp://oleg.vsi.ru/private/vmcore.0.zip Is this just the vmcore, or the debugging kernel also? Both are needed to make sense of the dump. Kernel binary with kernel config is here: ftp://oleg.vsi.ru/private/kernel.zip This kernel was built statically, and no modules loaded on boot at all. That kernel doesn't appear to match with the vmcore, are you sure it is the right one? Are you able to successfully run kgdb on these locally? # kgdb kernel vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. (no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer. (kgdb) bt #0 0xc0554b12 in doadump () #1 0xc048fe2b in db_fncall () #2 0xc048fc30 in db_command () #3 0xc048fcf8 in db_command_loop () #4 0xc04918f5 in db_trap () #5 0xc056e158 in kdb_trap () #6 0xc06c5960 in trap () #7 0xc06b176a in calltrap () #8 0xc056debf in kdb_enter () #9 0xc069bad6 in siointr1 () #10 0xc069b8cd in siointr () #11 0xc06b5565 in intr_execute_handlers () #12 0xc06b7cc6 in lapic_handle_intr () #13 0xc06b1b23 in Xapic_isr1 () #14 0xc06aaa4d in acpi_cpu_c1 () #15 0xc049b9c9 in acpi_cpu_idle () #16 0xc06b9e54 in cpu_idle () #17 0xc05402e9 in idle_proc () #18 0xc05400cc in fork_exit () #19 0xc06b17cc in fork_trampoline () (kgdb) info threads 114 Thread 100124 (PID=854: mc) 0xc05663ab in sched_switch () 113 Thread 100059 (PID=851: csh) 0xc05663ab in sched_switch () 112 Thread 100107 (PID=850: su) 0xc05663ab in sched_switch () 111 Thread 100125 (PID=845: csh) 0xc05663ab in sched_switch () 110 Thread 100122 (PID=844: sshd) 0xc05663ab in sched_switch () 109 Thread 100137 (PID=840: sshd) 0xc05663ab in sched_switch () 108 Thread 100138 (PID=839: httpd) 0xc05663ab in sched_switch () 107 Thread 100085 (PID=838: httpd) 0xc05663ab in sched_switch () 106 Thread 100092 (PID=837: httpd) 0xc05663ab in sched_switch () 105 Thread 100104 (PID=836: httpd) 0xc05663ab in sched_switch () 104 Thread 100083 (PID=835: httpd) 0xc05663ab in sched_switch () 103 Thread 100042 (PID=834: httpd) 0xc05663ab in sched_switch () 102 Thread 100064 (PID=833: httpd) 0xc05663ab in sched_switch () 101 Thread 100082 (PID=832: httpd) 0xc05663ab in sched_switch () 100 Thread 100106 (PID=831: httpd) 0xc05663ab in sched_switch () 99 Thread 100114 (PID=830: httpd) 0xc05663ab in sched_switch () 98 Thread 100080 (PID=829: httpd) 0xc05663ab in sched_switch () 97 Thread 100096 (PID=828: httpd) 0xc05663ab in sched_switch () 96 Thread 100113 (PID=827: httpd) 0xc05663ab in sched_switch () 95 Thread 100103 (PID=826: httpd) 0xc05663ab in sched_switch () 94 Thread 100139 (PID=825: httpd) 0xc05663ab in sched_switch () 93 Thread 100140 (PID=824: httpd) 0xc05663ab in sched_switch () 92 Thread 100141 (PID=823: httpd) 0xc05663ab in sched_switch () 91 Thread 100142 (PID=822: httpd) 0xc05663ab in sched_switch () 90 Thread 100076 (PID=821: httpd) 0xc05663ab in sched_switch () 89 Thread 100093 (PID=820: httpd) 0xc05663ab in sched_switch () 88 Thread 100069 (PID=819: httpd) 0xc05663ab in sched_switch () 87 Thread 100099 (PID=818: httpd) 0xc05663ab in sched_switch () 86 Thread 100068 (PID=817: httpd) 0xc05663ab in sched_switch () 85 Thread 100041 (PID=816: httpd) 0xc05663ab in sched_switch () 84 Thread 100070 (PID=815: httpd) 0xc05663ab in sched_switch () 83 Thread 100098 (PID=814: httpd) 0xc05663ab in sched_switch () 82 Thread 100050 (PID=813: httpd) 0xc05663ab in sched_switch () 81 Thread 100088 (PID=812: httpd) 0xc05663ab in sched_switch () 80 Thread 100131 (PID=811: httpd) 0xc05663ab in sched_switch () 79 Thread 100100 (PID=810: httpd) 0xc05663ab in sched_switch () 78 Thread 100133 (PID=809: mysqld) 0xc05663ab in sched_switch () 77 Thread 100126 (PID=809: mysqld) 0xc05663ab in sched_switch () 76 Thread 100134 (PID=809: mysqld) 0xc05663ab in sched_switch () 75 Thread 100079 (PID=809: mysqld) 0xc05663ab in sched_switch () 74 Thread 100128 (PID=809: mysqld) 0xc05663ab in sched_switch () 73 Thread
Re: FreeBSD-6.2, 7.0-BETA1 boot on Lenovo X60
On Sun, 2007-11-04 at 23:49 +0800, Balgansuren Batsukh wrote:
Hello All,
Last few days I try to boot FreeBSD-6.2, 7.0-BETA1 boot CD using USB CDROM
drive on Lenovo X60.
It give kind of assembler code non-stop flow over screen.
Can't boot system and some times give BTX halted message after CPU register
code ES=,
Is there any way to boot/install FreeBSD-6.2/7.0-BETA on X60?
If you have another box on the network, PXE is the way to go. I have
used it to troubleshoot my X60, when I have rendered it unbootable,
enough times to justify time spent. I have acquired UltraBase since
then, but it is still *much more convenient* to boot with PXE in need.
Below are relevant pieces of the information from the server (its name
is 'twinhead', its IP is 10.0.3.236 and install CD is copied into
'/SHARED/tftpboot', tftp user with access to the setup is named 'sunny'
-- you will have to adjust it accordingly):
=== excerpt from /usr/local/etc/dhcpd.conf (I am
using isc-dhcp3-server-3.0.5_2):
server-name twinhead;
server-identifier 10.0.3.236;
next-server 10.0.3.236;
# This is a very basic subnet declaration.
subnet 10.0.3.0 netmask 255.255.255.0 {
range 10.0.3.33 10.0.3.64;
option routers 10.0.3.242;
option domain-name-servers 10.0.3.242;
option root-path /SHARED/tftpboot;
filename boot/pxeboot;
}
/SHARED/tftpboot/boot/loader.rc
echo Loading Kernel...
load /boot/kernel/kernel
echo Loading mfsroot...
load -t mfs_root /mfsroot
echo booting...
echo \007\007
echo initializing h0h0magic...
set vfs.root.mountfrom=ufs:/dev/md0c
boot
excerpt from /etc/inetd.conf
tftpdgram udp waitroot/usr/libexec/tftpd tftpd -u
sunny -l -s /SHARED/tftpboot
I have also gunzip'ed /SHARED/tftpboot/boot/mfsroot.gz and placed it
into /SHARED/tftpboot/.
I don't think there was much else needed doing before you can attempt
booting your X60. Once you boot, you can switch to FTP install, so
version, you are booting from, does not need exactly match whatever you
want installed.
Note: you need to make sure there are no other active DHCP servers on
your network -- I have spend few hours hunting down that one ;)
Regards,
Balgaa
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Alexandre Sunny Kovalenko
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6-STABLE net-p2p/deluge port
On Fri, Nov 02, 2007 at 06:00:53PM -0500, Jeremy Messenger wrote: On Fri, 02 Nov 2007 06:05:28 -0500, Jonathan Chen [EMAIL PROTECTED] wrote: Hi, Is anyone else on the list experiencing kernel panics with 6-STABLE when using net-p2p/deluge? Recent versions of deluge 0.5.6.x seem to be tickling a kernel bug in the networking code. Anyone using it on 7-STABLE with success? I am running 0.5.6.2 in RELENG_7 and I don't see any panic. It works fine to download about 1.5MiB/s yesterday and have been doing seed at all the time since yesterday. I took the plunge and upgraded to RELENG_7, and can confirm that the panic doesn't happen with BETA2. Yay! -- Jonathan Chen [EMAIL PROTECTED] -- Lots of folks confuse bad management with destiny - Kin Hubbard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD 7.0-BETA1] strange behavior in hostname resolving order
At Sat, 03 Nov 2007 00:05:07 +0900,
Byung-Hee HWANG [EMAIL PROTECTED] wrote:
Usually i prefer 6to4(stf(4)) to 6over4(gif(4)) because some
tunnel providers like to limit bandwidth too musch. So until my
upstream ISP give me native ipv6 addresses (it's take long time maybe),
i'm going to use 6to4 instead of 6over4 continuous.
(snip)
And from now on, i would give you one question. Why is 7.0-BETA1
different from another -RELEASE in hostname resolving order? AFAIK, at
least on 6.2-RELEASE, the order is first IPv6 and then IPv4. However,
7.0-BETA1 try to lookup in first IPv4 than IPv6. Here is the evidence:
This is most likely because 7.0 now installs the address selection
policy table at boot time by default:
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/defaults/rc.conf.diff?r1=1.304r2=1.305
Now if you have (which I guess is your network configuration)
A. a global IPv4 address and
B. a 6to4 IPv6 address,
and have a candidate destination addresses
C. a global IPv4 address (like 210.226.20.15)
D. a native global IPv6 address (like 2001:218:422:1::15)
then getaddrinfo() will prefer the combination of {A and C} because
these addresses have a matching scope while B and D don't. If you
make sure the 6to4 source address always wins, you should modify the
policy table to:
PrefixPrecedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 1
::/96 20 3
:::0:0/96100 4
(i.e., change the label of 2002::/16).
JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-BETA2 Available
- Ladislav Bodnar [EMAIL PROTECTED] wrote: On Sunday 04 November 2007, Ken Smith wrote: The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available. These release announcements seem to be shorter and shorter with every release. Is there a changelog to see what has changed since BETA1? If so, would you please consider linking to it in future announcements? Thanks a lot :-) I recommend reading the FreeBSD quarterly reports. They have a better overview of what is going on each version. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
