Re: Migrating from x86 (32) to amd64
On Fri, Mar 09, 2007 at 08:54:42PM +0300 I heard the voice of Artem Kuchin, and lo! it spake thus: > > Theoretically, what would be the procedure? - Do a full cross-build of the amd64 world/kernel. - newfs your swap partition (or an extra partition/drive). - installworld/kernel the amd64 stuff onto that. - Boot into that temporary amd64 world. - installworld/kernel the amd64 stuff onto your main partition. - Boot back normal-like, re-enable swap. You should be able to do that in an hour hands-on easily. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic: spin lock smp rendezvous ... held too long
On Mar 9, 2007, at 03:41, Kris Kennaway wrote:
On Fri, Mar 09, 2007 at 12:44:03AM +0100, Eirik ?verby wrote:
Hi all,
I just installed 6.2-RELEASE on a Supermicro 6013P-8 server, a dual
P4-Xeon 2.4ghz with 4GB ECC memory and an asr driven SCSI RAID
controller.
It has been working OK (although I suspect the asr driven, being
giant-locked, is very inefficient) for a little while, but as I was
extracting a bunch of tarballs it paniced like so:
spin lock smp rendezvous held by 0xc9d54600 for > 5 seconds
panic: spin lock held too long
cpuid = 0
I don't have a dump device (though I'm setting that up for the next
reboot). However, I have tried turning off HT, to see if that might
help.
Does this look familiar to anyone? Or do I need to produce more data
if it happens again?
It can mean that something deadlocked. Turning on WITNESS may help to
debug this, although it has a large performance impact.
Just opened the vmcore file, and this is what I see, with a bt at the
end:
Unread portion of the kernel message buffer:
dev = da0s1f, block = 3802920, fs = /usr
panic: ffs_blkfree: freeing free block
cpuid = 1
Uptime: 23h59m46s
Dumping 3967 MB (3 chunks)
chunk 0: 1MB (158 pages) ... ok
chunk 1: 3966MB (1015280 pages) 3950 3934 3918 3902 3886 3870 3854
3838 3822 3806 3790 3774 3758 3742 3726 3710 3694 3678 3662 3646 3630
3614 3598 3582
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 06
fault virtual address = 0x18c
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc04542f4
stack pointer = 0x28:0xe98a3c88
frame pointer = 0x28:0xe98a3c90
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 18 (swi2: cambio)
trap number = 12
panic: page fault
cpuid = 1
3566 3550 3534 3518 3502 3486 3470 3454 3438 3422 3406 3390 3374 3358
3342 3326 3310 3294 3278 3262 3246 3230 3214 3198 3182 3166 3150 3134
3118 3102 3086 3070 3054 3038 3022 3006 2990 2974 2958 2942 2926 2910
2894 2878 2862 2846 2830 2814 2798 2782 2766 2750 2734 2718 2702 2686
2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2494 2478 2462
2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2254 2238
2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014
1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790
1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566
1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342
1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118
1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878
862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606
590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334
318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46
30 14 ... ok
chunk 2: 1MB (128 pages)
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc067550a in boot (howto=260) at /usr/src/sys/kern/
kern_shutdown.c:409
#2 0xc0675831 in panic (fmt=0xc0911dc2 "ffs_blkfree: freeing free
block") at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc07b375e in ffs_blkfree (ump=0xc9607c00, fs=0xc93c5800,
devvp=0xc9625110, bno=3802920, size=16384, inum=39400)
at /usr/src/sys/ufs/ffs/ffs_alloc.c:1869
#4 0xc07c38c6 in indir_trunc (freeblks=0xcb2bfa00, dbn=15210848,
level=0, lbn=12, countp=0xe98b8c6c)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:2894
#5 0xc07c32f6 in handle_workitem_freeblocks (freeblks=0xcb2bfa00,
flags=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2744
#6 0xc07c01b1 in process_worklist_item (mp=0xc95d87c8, flags=0) at /
usr/src/sys/ufs/ffs/ffs_softdep.c:967
#7 0xc07bfeb2 in softdep_process_worklist (mp=0xc95d87c8, full=0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:851
#8 0xc07bfc08 in softdep_flush () at /usr/src/sys/ufs/ffs/
ffs_softdep.c:762
#9 0xc065ec4d in fork_exit (callout=0xc07bfa6c ,
arg=0x0, frame=0xe98b8d38) at /usr/src/sys/kern/kern_fork.c:821
#10 0xc0879dac in fork_trampoline () at /usr/src/sys/i386/i386/
exception.s:208
PGP.sig
Description: This is a digitally signed message part
Re: Panic: spin lock smp rendezvous ... held too long
On Mar 9, 2007, at 03:41, Kris Kennaway wrote: On Fri, Mar 09, 2007 at 12:44:03AM +0100, Eirik ?verby wrote: Hi all, I just installed 6.2-RELEASE on a Supermicro 6013P-8 server, a dual P4-Xeon 2.4ghz with 4GB ECC memory and an asr driven SCSI RAID controller. It has been working OK (although I suspect the asr driven, being giant-locked, is very inefficient) for a little while, but as I was extracting a bunch of tarballs it paniced like so: spin lock smp rendezvous held by 0xc9d54600 for > 5 seconds panic: spin lock held too long cpuid = 0 I don't have a dump device (though I'm setting that up for the next reboot). However, I have tried turning off HT, to see if that might help. Does this look familiar to anyone? Or do I need to produce more data if it happens again? It can mean that something deadlocked. Turning on WITNESS may help to debug this, although it has a large performance impact. I can't turn on WITNESS here "just like that", as I'll need some time to find a replacement server for some critical applications. However, the strange thing is that this server has been running solid as a rock (not one single crash) for 2 years with FreeBSD 4.x on it, so I am fairly sure there is no hardware issue. It crashed today, and I have obtained a dump. I am running 6.2- RELEASE with the stock SMP kernel, and haven't recompiled yet, so I can't seem to find a kernel.debug, but I'm building one now with the 6.2-RELEASE sources, as supplied on the CD. I'm assuming this will give me a useable kernel.debug. Anything in particular I should look for if/when I'm able to peek into the dump with kgdb? thanks, /Eirik Kris PGP.sig Description: This is a digitally signed message part
Re: MFC request: QLogic 24xx FibreChannel controller
On Fri, 9 Mar 2007, Joao Barros wrote:
There are two FC switches, but AFAIK a multipath setup would have, for
example one disk coming from isp0 and the other from isp1, as isp0 and
isp1 are connected to two switches...
It's entirely possible that something's ill defined in the FC management
console (I din't do it - it's another guy's responsibility :) )
You're right, I missed that detail :)
You can always ask the "responsible" guy what he did, but right now
I'd say you have a freebie ;)
Use the attached to see if the attached disks are in fact paths to the
same device based upon serial ##!/bin/sh
#
# This script gets a list of da devices and Vital Product Data Serial numbers.
#
# It checks for same devices by matching serial number *and* logical unit
#
camcontrol devl|sed -e 's/^.*lun.//' -e 's/(//' -e 's/)//' -e 's/,/ /'|grep da|\
sed -e 's/pass.* //' -e 's/pass.*$//' | while read lun disk
do
serno=`camcontrol inquiry ${disk} -S`
if [ X"${serno}" != X ]
then
echo "${disk} ${lun} ${serno}" >>/tmp/t$$
echo ${lun}"."${serno} >> /tmp/y$$
fi
done
cat /tmp/y$$ | while read serno_lun_pair
do
grep $serno_lun_pair /tmp/t$$ > /tmp/a$$
nmatch=`cat /tmp/a$$ |wc -l|sed 's/ //g'`
if [ $nmatch -lt 2 ]
then
continue
fi
echo "Potential Same Devices:"
cat /tmp/a$$ | awk ' { printf "\t%s (lun %s)\t%s\n", $1, $2, $3 }'
cat /tmp/t$$ | grep -v $serno_lun_pair > /tmp/d$$
mv /tmp/d$$ /tmp/t$$
done
rm -f /tmp/t$$ /tmp/y$$ /tmp/a$$
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MFC request: QLogic 24xx FibreChannel controller
The GEOM multipath code hasn't been MFC'd yet. On Fri, 9 Mar 2007, Ivan Voras wrote: Joao Barros wrote: On 3/9/07, Ivan Voras <[EMAIL PROTECTED]> wrote: I'm not familiar with this hardware, but I'm curious why I see the one test drive I assigned to it twice. I seem to recall reading somewhere a discussion for Linux in which it's been mentioned that one of these should be a read-write and another "read-only" device, but is this correct? I can write to both drives. I'd say because you have a multipath setup, the driver being the exception. I guess the in house isp guru Matt Jacob can give you a better explanation ;) I don't think it's because of multipath (as far as I understand it) because both disks are atached to isp0: da1 at isp0 bus 0 target 0 lun 0 da2 at isp0 bus 0 target 1 lun 0 There are two FC switches, but AFAIK a multipath setup would have, for example one disk coming from isp0 and the other from isp1, as isp0 and isp1 are connected to two switches... It's entirely possible that something's ill defined in the FC management console (I din't do it - it's another guy's responsibility :) ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MFC request: QLogic 24xx FibreChannel controller
On 3/9/07, Ivan Voras <[EMAIL PROTECTED]> wrote: Joao Barros wrote: > On 3/9/07, Ivan Voras <[EMAIL PROTECTED]> wrote: >> I'm not familiar with this hardware, but I'm curious why I see the one >> test drive I assigned to it twice. I seem to recall reading somewhere a >> discussion for Linux in which it's been mentioned that one of these >> should be a read-write and another "read-only" device, but is this >> correct? I can write to both drives. > > I'd say because you have a multipath setup, the driver being the exception. > I guess the in house isp guru Matt Jacob can give you a better > explanation ;) I don't think it's because of multipath (as far as I understand it) because both disks are atached to isp0: da1 at isp0 bus 0 target 0 lun 0 da2 at isp0 bus 0 target 1 lun 0 There are two FC switches, but AFAIK a multipath setup would have, for example one disk coming from isp0 and the other from isp1, as isp0 and isp1 are connected to two switches... It's entirely possible that something's ill defined in the FC management console (I din't do it - it's another guy's responsibility :) ) You're right, I missed that detail :) You can always ask the "responsible" guy what he did, but right now I'd say you have a freebie ;) -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/share/man/man4 Makefile watchdog.4 src/share/man/man9 watchdog.9 src/sys/arm/xscale/i80321 i80321_wdog.c src/sys/dev/ichwd ichwd.c src/sys/dev/ipmi ipmi.c src/sys/dev/mk48txx mk48t
Hi, The commit below to ichwd.c, breaks the watchdog on a number of Intel boards I tried it against. (ICH5 and ICH7) The module loads, but the box never reboots after sending a sig 11 to watchdogd ichwd module loaded ichwd0: on isa0 Reverting to the version of ichwd.c prior to your commit unbreaks it and the watchdog works once again in that the box reboots after killing watchdogd. ---Mike At 05:56 PM 2/20/2007, Nick Hibma wrote: n_hibma 2007-02-20 22:56:29 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) share/man/man4 Makefile watchdog.4 share/man/man9 watchdog.9 sys/arm/xscale/i80321 i80321_wdog.c sys/dev/ichwdichwd.c sys/dev/ipmi ipmi.c sys/dev/mk48txx mk48txx.c sys/dev/watchdog watchdog.c sys/i386/i386elan-mmcr.c sys/kern kern_clock.c sys/sys watchdog.h usr.sbin/watchdogd watchdog.8 watchdogd.c Log: MFC the following commits: Align the interfaces for the various watchdogs and make the interface behave as expected. Also: - Return an error if WD_PASSIVE is passed in to the ioctl as only WD_ACTIVE is implemented at the moment. See sys/watchdog.h for an explanation of the difference between WD_ACTIVE and WD_PASSIVE. - Remove the I_HAVE_TOTALLY_LOST_MY_SENSE_OF_HUMOR define. If you've lost your sense of humor, than don't add a define. Specific changes: i80321_wdog.c Don't roll your own passive watchdog tickle as this would defeat the purpose of an active (userland) watchdog tickle. ichwd.c / ipmi.c: WD_ACTIVE means active patting of the watchdog by a userland process, not whether the watchdog is active. See sys/watchdog.h. kern_clock.c: (software watchdog) Remove a check for WD_ACTIVE as this does not make sense here. This reverts r1.181. Revision ChangesPath 1.371 +1 -0 src/share/man/man4/Makefile 1.8 +69 -25src/share/man/man4/watchdog.4 1.4 +7 -1 src/share/man/man9/watchdog.9 1.3 +15 -11src/sys/arm/xscale/i80321/i80321_wdog.c 1.7 +12 -30src/sys/dev/ichwd/ichwd.c 1.8 +8 -17 src/sys/dev/ipmi/ipmi.c 1.8 +3 -1 src/sys/dev/mk48txx/mk48txx.c 1.4 +4 -1 src/sys/dev/watchdog/watchdog.c 1.33 +9 -9 src/sys/i386/i386/elan-mmcr.c 1.193 +3 -3 src/sys/kern/kern_clock.c 1.4 +0 -4 src/sys/sys/watchdog.h and Don't exit from watchdogd on receiving a signal if we cannot stop the watchdog. That'll require -KILL. This avoids resetting your system on one of the watchdogs that you cannot disable. Revision ChangesPath 1.15 +18 -11src/usr.sbin/watchdogd/watchdogd.c Reviewed by:phk RevisionChangesPath 1.320.2.25 +1 -0 src/share/man/man4/Makefile 1.6.8.2 +69 -25src/share/man/man4/watchdog.4 1.3.8.1 +7 -1 src/share/man/man9/watchdog.9 1.2.2.1 +15 -11src/sys/arm/xscale/i80321/i80321_wdog.c 1.5.2.2 +12 -30src/sys/dev/ichwd/ichwd.c 1.3.2.5 +6 -17 src/sys/dev/ipmi/ipmi.c 1.6.2.2 +3 -1 src/sys/dev/mk48txx/mk48txx.c 1.2.8.1 +9 -2 src/sys/dev/watchdog/watchdog.c 1.31.2.2+9 -9 src/sys/i386/i386/elan-mmcr.c 1.178.2.4 +3 -3 src/sys/kern/kern_clock.c 1.3.8.1 +0 -4 src/sys/sys/watchdog.h 1.6.2.1 +5 -4 src/usr.sbin/watchdogd/watchdog.8 1.10.2.2+19 -13src/usr.sbin/watchdogd/watchdogd.c ___ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all 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: MFC request: QLogic 24xx FibreChannel controller
On 3/9/07, Ivan Voras <[EMAIL PROTECTED]> wrote: I'm not familiar with this hardware, but I'm curious why I see the one test drive I assigned to it twice. I seem to recall reading somewhere a discussion for Linux in which it's been mentioned that one of these should be a read-write and another "read-only" device, but is this correct? I can write to both drives. I'd say because you have a multipath setup, the driver being the exception. I guess the in house isp guru Matt Jacob can give you a better explanation ;) -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Migrating from x86 (32) to amd64
On 2007-Mar-09 22:16:36 +0300, Artem Kuchin <[EMAIL PROTECTED]> wrote: >Is there way to more or less sefely migrade to AMD64 arhitecture via >csup and >source build? >>... >>>Damn it. Then i guess i need to do some experimenting myself. >> >>Definitely. >> >>>Theoretically, what would be the procedure? >> >>1) Backup system. >>2) Download amd64 install ISO and burn to CD >>3) Boot from CD >>4) Follow instructions for fresh install >>5) Restore/merge configuration from backups. >> >>If you have a spare amd64 system and most of the content is static, >>you could reduce downtime by doing steps 4 thru 5 on the second system >>and either swapping the disk(s) or the entire system. > >no, that's no what i ment. I mean the procedure to source build/install >amd64 on x86 and make it work. Just theoretically, I presume you've read the bottom bit of /usr/src/UPGRADING You should be able to cross-build an amd64 world with: # make TARGET_ARCH=amd64 buildworld # make TARGET_ARCH=amd64 KERNCONF=YourKernel buildkernel (I'm confident this will work but watch out for CPU or architecture-specific flags in your /etc/make.conf) # mkdir /lib32 /usr/lib32 # cp -p /lib/* /lib32 # cp -p /usr/lib/* /usr/lib32 # cp -p /var/run/ld-elf.so.hints /var/run/ld-elf32.so.hints # cp -p /libexec/ld-elf.so.1 /libexec/ld-elf32.so.1 These steps setup the i386 emulation infrastructure (some of these steps may be overkill) # make TARGET_ARCH=amd64 KERNCONF=YourKernel DESTDIR=/ installkernel I think this will work. Reboot to single user mode (shouldn't have any problems) Mount /usr /var and anything else needed for the install # mergemaster -p # make TARGET_ARCH=amd64 DESTDIR=/ installworld These steps are probably the riskiest because you are relying on tricking the amd64 kernel into believing your i386 world is an i386 emulation. If anything goes wrong here, you will probably need to restore from backups because you can't run on the old kernel once you've started installing amd64 binaries. I haven't tried running an amd64 kernel with an i386 userland but after symlinking /lib32 -> lib and /usr/lib32 -> lib and copying the ld-elf.so files in my i386 filesystems, I can chroot into it whilst running my amd64 kernel and execute commands. # make delete-old # mergemaster These steps should be OK Note that I wouldn't attempt to try going from 5.4/i386 to 6.2/amd64 in one step. You want to minimise the things that can go wrong... -- Peter Jeremy pgp02GwLpUBHf.pgp Description: PGP signature
Re: MFC request: QLogic 24xx FibreChannel controller
Joao Barros wrote: > On 3/9/07, Ivan Voras <[EMAIL PROTECTED]> wrote: >> I'm not familiar with this hardware, but I'm curious why I see the one >> test drive I assigned to it twice. I seem to recall reading somewhere a >> discussion for Linux in which it's been mentioned that one of these >> should be a read-write and another "read-only" device, but is this >> correct? I can write to both drives. > > I'd say because you have a multipath setup, the driver being the exception. > I guess the in house isp guru Matt Jacob can give you a better > explanation ;) I don't think it's because of multipath (as far as I understand it) because both disks are atached to isp0: da1 at isp0 bus 0 target 0 lun 0 da2 at isp0 bus 0 target 1 lun 0 There are two FC switches, but AFAIK a multipath setup would have, for example one disk coming from isp0 and the other from isp1, as isp0 and isp1 are connected to two switches... It's entirely possible that something's ill defined in the FC management console (I din't do it - it's another guy's responsibility :) ) signature.asc Description: OpenPGP digital signature
Re: Some Unix benchmarks for those who are interesed
On Mar 9, 2007, at 11:34 AM, Eric Anderson wrote: I've got a VIA C3 Samuel myself, and it is fine for what it is, which is a low-power clone of the Pentium-MMX in terms of capabilities; the newer C3 Nehemiah is roughly comparable to a P2, plus SSE and the extra AES/RNG crypto stuff. Look at dmesg or cpuid and compare CPU features. I'm pretty familiar with C3 and C7 chips. I wouldn't compare performance of a CPU based on CPU features. Of course not-- but then, I said "capabilities", not performance. If you'd like to compare performance, choose a task or benchmark which matters to you, and go from there. The comparisons I have done suggests a 200MHz PPro will do a "make buildworld" faster than a 600MHz C3 Samuel, for example. YMMV, and I'd rather not debate this matter further if you feel strongly about it... -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Canonical 4.x to 6.x upgrade docs?
Hi all, some time ago Yar Tikhiy posted a message to this list in which he described a way to directly update a 4.11 box to 6.2. The message can be found here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=190896+0+archive/2007/freebsd-stable/20070225.freebsd-stable HTH, Philipp -- www.familie-ost.info/~pj ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some Unix benchmarks for those who are interesed
On 03/09/07 12:55, Chuck Swiger wrote: On Mar 8, 2007, at 9:24 PM, Eric Anderson wrote: [ ... ] Dunno. I was merely trying to keep things honest, since what was communicated (whether intended or not) was that a C3 isn't modern, and is akin to a Pentium, which it isn't. I've got a VIA C3 Samuel myself, and it is fine for what it is, which is a low-power clone of the Pentium-MMX in terms of capabilities; the newer C3 Nehemiah is roughly comparable to a P2, plus SSE and the extra AES/RNG crypto stuff. Look at dmesg or cpuid and compare CPU features. I'm pretty familiar with C3 and C7 chips. I wouldn't compare performance of a CPU based on CPU features. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Canonical 4.x to 6.x upgrade docs?
On Fri, Mar 09, 2007 at 09:30:01AM -0800, Bruce A. Mah wrote: > If memory serves me right, Artem Kuchin wrote: > > > >> Has anyone succeeded in doing a 4.x -> 6.x upgrade from source without > >> upgrading first to 5.x as an intermediate step? > > > > > > > > tried twice - did not work, but going to 5 and then to 6 was not a problem. > > But i suspect than going from older 4.x to newer 5.x (like 5.4) might not > > work > > and it might need another round of upgrade lile 4.x - 5.1 - 5.4 - 6.2 > > I don't kwow for sure. > > What's the basis for your suspicion? > > 5.X releases up through and including 5.4 included a migration guide > (written mostly by me) with step-by-step instructions on migrating from > 4.X. I don't recall any widespread problem reports from people when > following these directions correctly on migrating from 4.X to 5.4. And > I'm fairly sure that a number of the FreeBSD.org machines were upgraded > using exactly this procedure (4.X to 5.4, then 5.4 to 6.X). I've found a description of direct 4.x -> 6.x remote upgrade method (in Russian): http://ark-devil.livejournal.com/2007/02/04/ Here comes a translation: /* Hail those that make the sunset by hands, ski'd and standing in hammock (c) DE 1. Install a loader of 6.x 2. Install a kernel of 4.x into /boot/kernel 3. Install GENERIC of 6.x into /boot/kernel6 4. Install mfsroot.gz with utilities into /boot/mfsroot.gz 5. echo 'mfsroot_load="YES"' > "/boot/loader.conf" echo 'mfsroot_type="mfs_root"' >> "/boot/loader.conf" echo 'mfsroot_name="/boot/mfsroot"' >> "/boot/loader.conf" 6. echo 'nextboot_enable="YES"' > /boot/nextboot.conf echo 'kernel="kernel6"' >> /boot/nextboot.conf echo 'vfs.root.mountfrom="ufs:md0"' >> /boot/nextboot.conf Now reboot. The loader will try to boot the kernel6 and, if successful, run sshd from mfsroot. You should now log in remotely and perform upgrade as you like. If not successful, the system will boot 4.x after power-cycle and you have another chance. / Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some Unix benchmarks for those who are interesed
On Mar 8, 2007, at 9:24 PM, Eric Anderson wrote: [ ... ] Dunno. I was merely trying to keep things honest, since what was communicated (whether intended or not) was that a C3 isn't modern, and is akin to a Pentium, which it isn't. I've got a VIA C3 Samuel myself, and it is fine for what it is, which is a low-power clone of the Pentium-MMX in terms of capabilities; the newer C3 Nehemiah is roughly comparable to a P2, plus SSE and the extra AES/RNG crypto stuff. Look at dmesg or cpuid and compare CPU features. A quick sample from http://www.nycbug.org/?NAV=dmesgd;f_bsd=FreeBSD suggests: CPU: VIA C3 Samuel 2 (601.37-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x673 Stepping = 3 Features=0x803035 CPU: Pentium/P55C (167.05-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bf CPU: Pentium II/Pentium II Xeon/Celeron (397.33-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbffMCA,CMOV,PAT,PSE36,MMX,FXSR> CPU: VIA C3 Nehemiah+RNG (1000.35-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x693 Stepping = 3 Features=0x380b33dE> CPU: Intel(R) Pentium(R) III CPU family 1400MHz (1403.27-MHz 686- class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbffMCA,CMOV,PAT,PSE36,MMX,FXSR,SSE> -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Migrating from x86 (32) to amd64
Is there way to more or less sefely migrade to AMD64 arhitecture via csup and source build? ... Damn it. Then i guess i need to do some experimenting myself. Definitely. Theoretically, what would be the procedure? 1) Backup system. 2) Download amd64 install ISO and burn to CD 3) Boot from CD 4) Follow instructions for fresh install 5) Restore/merge configuration from backups. If you have a spare amd64 system and most of the content is static, you could reduce downtime by doing steps 4 thru 5 on the second system and either swapping the disk(s) or the entire system. no, that's no what i ment. I mean the procedure to source build/install amd64 on x86 and make it work. Just theoretically, -- Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Migrating from x86 (32) to amd64
On 2007-Mar-09 20:54:42 +0300, Artem Kuchin <[EMAIL PROTECTED]> wrote: >>>Is there way to more or less sefely migrade to AMD64 arhitecture via >>>csup and >>>source build? ... >Damn it. Then i guess i need to do some experimenting myself. Definitely. >Theoretically, what would be the procedure? 1) Backup system. 2) Download amd64 install ISO and burn to CD 3) Boot from CD 4) Follow instructions for fresh install 5) Restore/merge configuration from backups. If you have a spare amd64 system and most of the content is static, you could reduce downtime by doing steps 4 thru 5 on the second system and either swapping the disk(s) or the entire system. -- Peter Jeremy pgpcE3zNJGkFJ.pgp Description: PGP signature
Progress installing on IBM LS21 "Blade" machine
As you may know, I've been sending all sorts of messages trying to get help running FreeBSD 6.x on this AMD Opteron-based blade (LS21). Now I've managed to get it to work mostly as I want it, so here's some maps for future explorers. First, things that don't work: * 64-bit kernels. With or without ACPI, on 6-stable or on 7-current, kernels in AMD64 mode don't finish booting, or in the best case boot but can't run SMP (they don't find additional CPUs, but mptable information is correct - see previous posts). There's even a sort-of regression in 7-current: while 6-stable without ACPI boots but finds only one CPU, 7-current kernel hangs with or without ACPI, either during USB bus' detection or just after "parallel port" detection (which is obviously not present on blades but still detected...). * One irritating umass device. It seems that there's an embedded umass (USB mass storage) device in the blade or blade center which is listed in device tree but doesn't respond to any probes, thus hanging the boot process for upto 15 minutes until all timeouts expire. First time this happened I almost gave up and pronounced it a lost cause, but it appears to be a harmless (if irritating) timeout issue. I've built a kernel without umass support, but that means I also lost the built-in CD/DVD drive in the chasis. Second, what works: * 32-bit i386 kernels in any mode: UP, SMP, UP/PAE, SMP/PAE, I've tried them all, and except the problem with umass, they all work as advertised. I'm running SMP/PAE since I need the additional memory. * Network interfaces are of the bce variety and need SerDes support to work. This has been MFC'ed somewhere early february. * FibreChannel interface is QLogic 24xx, support for which has been MFCed very recently (almost 2 days ago). So, plain 6.2-release can't run on the blade, but 6-stable can, without additional patches. Here's dmesg for the machine: Copyright (c) 1992-2007 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 6.2-STABLE #4: Fri Mar 9 17:10:32 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PAESMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2400.10-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40f12 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f,,CR8> Cores per package: 2 real memory = 4815060992 (4592 MB) avail memory = 4191055872 (3996 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic1 irqs 16-31 on motherboard ioapic0 irqs 0-15 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 cpu2: on acpi0 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 cpu3: on acpi0 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 bce0: mem 0xea00-0xebff irq 17 at device 4.0 on pci2 bce0: ASIC ID 0x57060021; Revision (A2); PCI-X 64-bit 133MHz miibus0: on bce0 gentbi0: on miibus0 gentbi0: 1000baseSX, 1000baseSX-FDX, auto bce0: Ethernet address: 00:14:5e:6d:2d:74 bce1: mem 0xec00-0xedff irq 18 at device 5.0 on pci2 bce1: ASIC ID 0x57060021; Revision (A2); PCI-X 64-bit 133MHz miibus1: on bce1 gentbi1: on miibus1 gentbi1: 1000baseSX, 1000baseSX-FDX, auto bce1: Ethernet address: 00:14:5e:b3:2a:38 isab0: at device 2.2 on pci0 isa0: on isab0 ohci0: port 0x3000-0x30ff mem 0xf9fff000-0xf9ff irq 3 at device 3.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1: port 0x3100-0x31ff mem 0xf9ffe000-0xf9ffefff irq 3 at device 3.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, le
Re: Migrating from x86 (32) to amd64
Is there way to more or less sefely migrade to AMD64 arhitecture via csup and source build? AFAIK nobody has lived to tell the tale (or at least I didn't see any followups from people who claimed they'd try it). In any case it would be better to migrate it via binary reinstall (the same as installing from scratch, using the boot CD...). Damn it. Then i guess i need to do some experimenting myself. Theoretically, what would be the procedure? Any recomendations? Try using PAE, but read up on possible problems. No, just not PAE. Tried it on 6.2, felt all the pain, cried outloud and went back to simple plain 32 bit. As it has been told - PAE IS AN UGLY HACK. -- Regards Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Canonical 4.x to 6.x upgrade docs?
What's the basis for your suspicion? My memory might play tricks on me, but i think I remember that i tried to upgrade from 4.1 to 5.3 longtime ago and it did not work. I had to up to 5.0 and the to 5.3. But that might be just some weird client install (i did not install freebsd on that box originally). The world just did not compile. I canot provide any more detail on that, sorry. -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Migrating from x86 (32) to amd64
Artem Kuchin wrote: > Is there way to more or less sefely migrade to AMD64 arhitecture via > csup and > source build? AFAIK nobody has lived to tell the tale (or at least I didn't see any followups from people who claimed they'd try it). In any case it would be better to migrate it via binary reinstall (the same as installing from scratch, using the boot CD...). > Any recomendations? Try using PAE, but read up on possible problems. signature.asc Description: OpenPGP digital signature
Re: Canonical 4.x to 6.x upgrade docs?
If memory serves me right, Artem Kuchin wrote: > >> Has anyone succeeded in doing a 4.x -> 6.x upgrade from source without >> upgrading first to 5.x as an intermediate step? > > > > tried twice - did not work, but going to 5 and then to 6 was not a problem. > But i suspect than going from older 4.x to newer 5.x (like 5.4) might not work > and it might need another round of upgrade lile 4.x - 5.1 - 5.4 - 6.2 > I don't kwow for sure. What's the basis for your suspicion? 5.X releases up through and including 5.4 included a migration guide (written mostly by me) with step-by-step instructions on migrating from 4.X. I don't recall any widespread problem reports from people when following these directions correctly on migrating from 4.X to 5.4. And I'm fairly sure that a number of the FreeBSD.org machines were upgraded using exactly this procedure (4.X to 5.4, then 5.4 to 6.X). Bruce. signature.asc Description: OpenPGP digital signature
Re: Canonical 4.x to 6.x upgrade docs?
Has anyone succeeded in doing a 4.x -> 6.x upgrade from source without upgrading first to 5.x as an intermediate step? tried twice - did not work, but going to 5 and then to 6 was not a problem. But i suspect than going from older 4.x to newer 5.x (like 5.4) might not work and it might need another round of upgrade lile 4.x - 5.1 - 5.4 - 6.2 I don't kwow for sure. -- Regards Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/108150: [ste] [patch] ASUS NX1001 (if_ste) hardware support
Hi! I confirm that the problem exists and proposed solution works. I've just installed a router with ASUS NX1001 PCI card and have been forced to rebuild kernel with device id manually added to the driver. Only then the card was attached by the driver. Please commit this. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MFC request: QLogic 24xx FibreChannel controller
Ivan Voras ha scritto: I'm interested in having support for QLogic 24xx cards in 6-stable It was backported 34 hours ago ;-) My card identifies itself as 2462s, in an IBM blade. Nobody tested the new code with a 246x card, but probably is the same as 242x (tested). -- Alex Dupre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MFC request: QLogic 24xx FibreChannel controller
Alex Dupre wrote: > Ivan Voras ha scritto: >> I'm interested in having support for QLogic 24xx cards in 6-stable > > It was backported 34 hours ago ;-) That was fast :) I've cvsupped before trying to get the blade to work (needed SerDes support for bce cards) but wow, it has been almost three days now :( time flies... I'll try it now and report how it's doing. signature.asc Description: OpenPGP digital signature
Re: Canonical 4.x to 6.x upgrade docs?
Has anyone succeeded in doing a 4.x -> 6.x upgrade from source without upgrading first to 5.x as an intermediate step? Michael Grant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Processes get stuck in "ufs" state
On Fri, Mar 09, 2007 at 06:08:25PM +0300, Oleg Derevenetz wrote: > On Wed, Mar 07, 2007 at 05:22:38AM +0300, Oleg Derevenetz wrote: > > >>Sometimes (once a week approximately) I have a problem with the same > >>symptoms described here on SMP FreeBSD 6.2-STABLE with dual AMD > >>Opteron(tm) > >>Processor 850: > >> > >>http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat= > >> > >>Sometimes (apparently when CPU load suddenly goes up) all processes that > >>interacts with disk gets stuck in "ufs" state, but in my case > >>SIGSTOP/SIGCONT seemingly does not help. > > > >See developer handbook, Deadlock Debugging chapter for instruction what > >information shall be gathered to debug the problem. > > OK, I built kernel with debug options and will wait for stuck. By the way, > when debug options turned on, I see this message on every boot when nullfs > mounting in progress: > > acquiring duplicate lock of same type: "vnode interlock" > 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:806 > 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2040 > KDB: stack backtrace: > kdb_backtrace(3,cfc60300,c05926d0,c05926d0,c05542c4,...) at > kdb_backtrace+0x29 > witness_checkorder(cfd5c4dc,9,c051cf1e,7f8) at witness_checkorder+0x578 > _mtx_lock_flags(cfd5c4dc,0,c051cf1e,7f8,cfb28b90,...) at > _mtx_lock_flags+0x78 > vrefcnt(cfd5c414) at vrefcnt+0x20 > null_checkvp(cff5eae0,c050c4a6,215) at null_checkvp+0x56 > null_lock(f02f1a68) at null_lock+0x66 > VOP_LOCK_APV(c054d540,f02f1a68) at VOP_LOCK_APV+0x87 > vn_lock(cff5eae0,1002,cfc60300,cff5eae0,cff5ed04,...) at vn_lock+0xac > nullfs_root(cff76b90,2,f02f1ae0,cfc60300,0,8,0,c05cfca0,0,c051c79c,407) at > nullfs_root+0x26 > vfs_domount(cfc60300,cfe3d340,cfe3d130,d,cfe3d3f0,c05817e0,0,c051c79c,2bf) > at vfs_domount+0x975 > vfs_donmount(cfc60300,d,cfe73080,cfe73080,0,...) at vfs_donmount+0x3f9 > nmount(cfc60300,f02f1d04) at nmount+0x8b > syscall(3b,3b,3b,bf7fe5f5,bf7feea0,...) at syscall+0x25b > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280bc0e7, esp = > 0xbf7fe5bc, ebp = 0xbf7fee38 --- > > This host have nullfs filesystems. Is this can be related to deadlock ? This is harmless, just ignore it. pgp3azpHgEcQb.pgp Description: PGP signature
Re: any success with new sun "M2" product variant for X4100 and X2100
On Mar 8, 2007, at 4:45 PM, Jens Fallesen wrote: One issue I have is that the embedded management software can run on NIC 1 only. And once FreeBSD detects this, the embedded management software is disabled. Does anyone know of a way to make FreeBSD detect NIC 0 only? Did you spring for the $100 LOM card or are you just using the embedded software?
Re: Processes get stuck in "ufs" state
On Wed, Mar 07, 2007 at 05:22:38AM +0300, Oleg Derevenetz wrote: Sometimes (once a week approximately) I have a problem with the same symptoms described here on SMP FreeBSD 6.2-STABLE with dual AMD Opteron(tm) Processor 850: http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat= Sometimes (apparently when CPU load suddenly goes up) all processes that interacts with disk gets stuck in "ufs" state, but in my case SIGSTOP/SIGCONT seemingly does not help. See developer handbook, Deadlock Debugging chapter for instruction what information shall be gathered to debug the problem. OK, I built kernel with debug options and will wait for stuck. By the way, when debug options turned on, I see this message on every boot when nullfs mounting in progress: acquiring duplicate lock of same type: "vnode interlock" 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:806 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2040 KDB: stack backtrace: kdb_backtrace(3,cfc60300,c05926d0,c05926d0,c05542c4,...) at kdb_backtrace+0x29 witness_checkorder(cfd5c4dc,9,c051cf1e,7f8) at witness_checkorder+0x578 _mtx_lock_flags(cfd5c4dc,0,c051cf1e,7f8,cfb28b90,...) at _mtx_lock_flags+0x78 vrefcnt(cfd5c414) at vrefcnt+0x20 null_checkvp(cff5eae0,c050c4a6,215) at null_checkvp+0x56 null_lock(f02f1a68) at null_lock+0x66 VOP_LOCK_APV(c054d540,f02f1a68) at VOP_LOCK_APV+0x87 vn_lock(cff5eae0,1002,cfc60300,cff5eae0,cff5ed04,...) at vn_lock+0xac nullfs_root(cff76b90,2,f02f1ae0,cfc60300,0,8,0,c05cfca0,0,c051c79c,407) at nullfs_root+0x26 vfs_domount(cfc60300,cfe3d340,cfe3d130,d,cfe3d3f0,c05817e0,0,c051c79c,2bf) at vfs_domount+0x975 vfs_donmount(cfc60300,d,cfe73080,cfe73080,0,...) at vfs_donmount+0x3f9 nmount(cfc60300,f02f1d04) at nmount+0x8b syscall(3b,3b,3b,bf7fe5f5,bf7feea0,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280bc0e7, esp = 0xbf7fe5bc, ebp = 0xbf7fee38 --- This host have nullfs filesystems. Is this can be related to deadlock ? -- 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: Background process
On Mar 8, 2007, at 7:14 PM, Doug Barton wrote: Failing that, if you need to preserve anything that is emitted from the program, nohup is probably your best bet. If it isn't going to spit anything out on the terminal, take a look at daemon(8), which you probably will want to run with the -f option. I can't remember needing nohup to run *anything* since the ancient days of the old old old /bin/sh which would kill all of your processes upon logout. Modern shells do not do this. Just redirect the stdin/stdout/stderr appropriately and run in bg. The more appropriate tool, assuming the original program has no "run as daemon" flag is the daemon(8) program as mentioned above.
Weird NFS behaviour
Hi, we have performance problems with our FreeBSD 6.2 based NFS server. Picture the following setup: FreeBSD Client ---> Samba-Server ---> NFS-Server all three machines are running FreeBSD 6.2 (the same image). The NFS server is configured with 16 nfsd. sysctl.conf has net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=65536 Now, what's the problem: The Samba-Server mounts shares via NFS. All servers are on Gigabit Ethernet and I get read transfer rates exceeding 50MB/s from the NFS server. This is all good and well, but if I copy a file via scp(1) (sic!) to the samba server into the NFS mounted directory, not only do I seldomly exceed 12MB/s but I also get a very strange traffic pattern on the em0 interface of the samba server. I get _twice_ as much incoming traffic on the em0 interface as outgoing traffic. systat -if on samba: em0 in 24.726 MB/s 25.905 MB/s3.046 GB out12.941 MB/s 13.558 MB/s1.994 GB systat -if on nfs-server em0 in 11.497 MB/s 12.999 MB/s3.727 GB out11.878 MB/s 13.423 MB/s 995.485 MB To stress, this is running: gigabit-client:# scp large-file [EMAIL PROTECTED]:/mnt/nfs-share/ The wicked part is this: If I copy a file from the samba server directly to the NFS share (not as a passthrough), I get these traffic patterns: systat -if on samba: em0 in432.724 KB/s432.724 KB/s3.772 GB out12.399 MB/s 12.399 MB/s2.481 GB systat -if on nfs: em0 in 12.091 MB/s 15.791 MB/s 184.766 MB out 440.939 KB/s562.521 KB/s1.339 GB This is running: samba:# cp large-file /mnt/nfs-share/ What on earth is causing each received NFS packet to be _bounced_ to the samba server when using ssh, scp, smbd, etc. And not when generating the traffic locally? nfsstat -s is showing an increase in READ calls similar to WRITE calls when using the samba machine as pass-through. It is showing _no_ increase in READ calls when copying the files directly. NB: All these test were run _without_ smbd running, it's just that this server is designated to become our samba server. Setting vfs.nfsrv.async=1 doubled write performance, but the weird traffic pattern remains. (Am I asking for too much trouble by setting async NFS?) Thanks for any pointers! Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any success with new sun "M2" product variant for X4100 and X2100
On Mar 9, 2007, at 8:19 AM, Thomas Hurst wrote: Also, if anyone knows which ethernet ports they put in that'd be helpful. I'd avoid them if they had broadcom chips :-( 2 nVidia nForce nve(4)'s and 2 Intel Pro/1000 em(4)'s. Quite a step back from the quad em(4)'s in !M2's, but 2 usable NIC's should be enough for most uses. Thanks for the info... I just need 2 NICs so that works for me. Now, if they'd rearrange the guts to take a full-height card I could go back to using LSI RAID cards instead of Adaptec ones :-)
Migrating from x86 (32) to amd64
Maybe someone could help me. I have a machine with 4GB of RAM 128MB of which is wasted and i really need 2 gigs more. This is a heavy duty production server with a lot of jails and custom scripts, etc.. and i am afraid i cannot reinstall all from scratch. Furthermore it is located in the data center away from the office and i simply cannot spend whoel day there, but 2-4 hours would be ok. Currentlyt it is 5.4-STABLE (i386, 32bit architecture) Is there way to more or less sefely migrade to AMD64 arhitecture via csup and source build? Any recomendations? -- Regards Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any success with new sun "M2" product variant for X4100 and X2100
* Vivek Khera ([EMAIL PROTECTED]) wrote: > Has anyone successfully booted FreeBSD 6 on the new "M2" variants of > sun's X2100 or X4100 boxes? I have three X4100 original versions that > works stunningly well (but I don't use the internal disks) with > FreeBSD 6.1. I was just curious how the new ones work, and the X2100 > seems to fit the bill for what I currently need. We have a pair of X4100M2's in production right now running 6.2, though we run a pretty cut-down kernel that lacks USB support. There are some dmesg warnings related to the IOAPICs but they seem harmless: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 6 ioapic1: WARNING: intbase 48 != expected base 24 ioapic2: Changing APIC ID to 7 ioapic2: WARNING: intbase 56 != expected base 55 ioapic3: Changing APIC ID to 5 ioapic3: WARNING: intbase 24 != expected base 63 ioapic0 irqs 0-23 on motherboard ioapic3 irqs 24-47 on motherboard ioapic1 irqs 48-54 on motherboard ioapic2 irqs 56-62 on motherboard Disks work fine with mpt(4), just as with !M2. > Also, if anyone knows which ethernet ports they put in that'd be > helpful. I'd avoid them if they had broadcom chips :-( 2 nVidia nForce nve(4)'s and 2 Intel Pro/1000 em(4)'s. Quite a step back from the quad em(4)'s in !M2's, but 2 usable NIC's should be enough for most uses. -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP doesn't work without ACPI?
Ivan Voras wrote:
> Ivan Voras wrote:
>
>> Since I need it in production, I'll try i386 6.2-release+PAE...
>
> Ok, PAE uniprocessor kernel boots fine, finds all the memory but I can't
> create (clone) a vlan device ("ifconfig vlan0 create"). It fails with an
> error in SIOCIFCREATE.
>
> Since creating vlan0 worked in amd64 mode (and is probably
> 64-bit-friendly), is it a problem with PAE?
Ok, I found it - on a non-PAE system this works because ifconfig
automagically loads if_vlan.ko, but since there are no modules in PAE
kernel, this obviously fails... (so I'll build device vlan into the kernel)
signature.asc
Description: OpenPGP digital signature
Re: SMP doesn't work without ACPI?
Ivan Voras wrote:
> Since I need it in production, I'll try i386 6.2-release+PAE...
Ok, PAE uniprocessor kernel boots fine, finds all the memory but I can't
create (clone) a vlan device ("ifconfig vlan0 create"). It fails with an
error in SIOCIFCREATE.
Since creating vlan0 worked in amd64 mode (and is probably
64-bit-friendly), is it a problem with PAE?
signature.asc
Description: OpenPGP digital signature
Re: fibre channel cards
Generally speaking, the LSI-Logic cards are faster, at least for 2Gb, in terms of IOPS. However, the LSI-Logic firmware is less capable of coping with complicated topologies and the mpt(4) driver is less mature than isp(4). Another thing to keep in mind is that for new cards (as opposed to 'EBay' cards) that LSI is half the port cost of QLogic. On 3/8/07, Claus Guttesen <[EMAIL PROTECTED]> wrote: > Are there any other fibre channel cards supported on FreeBSD? > > What card would one recommend to connect to an external RAID array > for running a fairly busy database (several million inserts/selects/ > updates per day)? I've tried qlogic's 2310 and haven't had any issue with those. I did recompile the kernel and included ispfw which is commented out by default in GENERIC. I don't know whether they perform better or worse than hba's from LSI. regards Claus ___ 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]"
