Re: Packet loss every 30.999 seconds
On Wed, Dec 19, 2007 at 12:06:59PM -0500, Mark Fullmer wrote: >Thanks for the other info on timer resolution, I overlooked >clock_gettime(). If you have a UP system with a usable TSC (or equivalent) then using rdtsc() (or equivalent) is a much cheaper way to measure short durations with high resolution. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpCXh5EuAxtY.pgp Description: PGP signature
Re: 7.0BETA4 ../cc_tools/insn-attrtab.c compiles forever
Julian Stacey wrote: > Anyone else noticed on 7.0BETA4 (& hence Ive cc'd re@) I did see some weird behaviour while compiling gcc, though I don't remember if it's the same file (looks like it). They usually disappeared after removing CPUTYPE and -O2 from compiler flags. signature.asc Description: OpenPGP digital signature
Re: 7.0BETA4 ../cc_tools/insn-attrtab.c compiles forever
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 19, 2007 at 09:36:32PM +0100, Julian Stacey wrote: > Anyone else noticed on 7.0BETA4 (& hence Ive cc'd re@) > > This runs forever: > > ===> cc_int (all) > Warning: Object directory not changed from original > /usr/src/gnu/usr.bin/cc/cc_int > cc -O2 -fno-strict-aliasing -march=i586 -DIN_GCC -DHAVE_CONFIG_H > -DPREFIX=\"/usr\" -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools > -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -c > ../cc_tools/insn-attrtab.c > > With or without -pipe & with or without /usr/obj > All the rest of /usr/src compiles OK though. > > FreeBSD lapn.js.berklix.net 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Sun Dec 16 > 09:18:21 CET 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC > i386 Hi there. I'd bet you're seeing some serious thrashing there. I've come across at least one other user having problems with that particular part of buildworld and -O2/-Os optimization levels. Seems like gcc4 is quite the memory hog so I don't know whether something can be done, other than either adding more RAM, trying to tweak swappiness, or taking a break while this thing compiles itself. Cheers. \n\n -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Nikos Ntarmos <[EMAIL PROTECTED]> iD8DBQFHalMLm6J1ac+VFgoRAiE0AJ94qpti098fL9xs5XV2Jbeg/Al5NgCcClxA AC8C6HMO6d13OoKlfdqy9Wc= =fUnL -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]"
Performance!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have read all related threads about performance problems with multi
core systems but still have no idea what to do to make thinks better.
Below are results of testing postgresql on HP DL380G5 using sysbench.
The results are comparable to:
http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
but the same tests running on the same hardware using Linux (kernel
2.6.18-53.1.4.el5 SMP x86_64) are very different.
PostgreSQL is tuned equal.
dmesg:
...
CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz
K8-class CPU)
Origin = "GenuineIntel" Id = 0x10676 Stepping = 6
Features=0xbfebfbff
Features2=0xce3bd>
AMD Features=0x2800
AMD Features2=0x1
Cores per package: 4
usable memory = 8575655936 (8178 MB)
avail memory = 8288337920 (7904 MB)
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
...
test:
sysbench --num-threads=${i} --test=oltp --pgsql-user=bench
- --pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0
- --oltp-read-only=on run
tuning:
kern.ipc.shmmax=2147483647
kern.ipc.shmall=524288
kern.ipc.semmsl=512
kern.ipc.semmap=256
kern.ipc.somaxconn=2048
kern.maxfiles=65536
vfs.read_max=32
kern.ipc.semmni=256
kern.ipc.semmns=2048
results:
FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE
#threads#transactions/sec user/system
1 500 7.4%,5.3%
5 199030.9%,23.4%
10 251039.9%,35.0%
20 254944.5%,43.5%
40 192129.8%,59.4%
60 158022.7%,70.6%
80 134118.9%,75.9%
100 122716.5%,79.3%
Linux
#threads#transactions/sec
1 693
5 3539
10 5789
20 5791
40 5661
60 5517
80 5401
100 5319
What can be done to improve these results?
Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHal7hxJBWvpalMpkRAsaiAJ9G3ZoTv6cUbR4yix07TEMf7PKm7gCgoroM
+xvcXkcaFjSTxYfjk5rqMko=
=Tpsq
-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]"
[7.0 beta4] iwi : firmware stuck in state 4, resetting
Hi, I've got many deconnections with iwi on 7.0 with WPA, far more than on 6.2. iwi0: firmware error iwi0: link state changed to DOWN iwi0: link state changed to UP iwi0: firmware stuck in state 4, resetting [...] Then I have to make an "/etc/rc.d/netif restart iwi0" to reconnect. With debug enable on iwi : Dec 15 01:12:03 roxette kernel: sending command idx=13 type=26 len=96 Dec 15 01:12:03 roxette kernel: Beacon miss: 26 >= 24 Dec 15 01:12:03 roxette kernel: Beacon miss: 27 >= 24 Dec 15 01:12:03 roxette kernel: Beacon miss: 28 >= 24 Dec 15 01:12:04 roxette kernel: Beacon miss: 29 >= 24 Dec 15 01:12:08 roxette kernel: iwi0: firmware stuck in state 4, resetting I put the complete log here : http://user.lamaiziere.net/patrick/messages.4.bz2 Any idea ? Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD on Dell T105? ($350 dual-core Opteron)
[I'm adding -current as there are other discussions of hardware compatibility there, trim if appropriate] Chris Shenton <[EMAIL PROTECTED]> writes: > > http://www.dell.com/downloads/global/products/pedge/en/pe_T105_spec_sheet.pdf > > Processors Single AMD Opteron TM 1000 series at up to 2.8GHz; > Single AMD SempronTM LE1250 at 2.2GHz > > HyperTransportTMHyperTransport at 2000MT/s > > Chipset nVidia CK8-04 Pro > > Network Interfaces Single embedded Gigabit3 NIC I installed FreeBSD 7.0-BETA4 amd64 this morning and it boots fine, detects both CPUs, but can't seem to find a driver for the ethernet. It doesn't offer anything at install time (only slip and ppp) and shows nothing in ifconfig when running. The one thing I see in dmesg is: pci2: at device 0.0 (no driver attached) Some pages I've found say this is a Broadcom 5721J chipset: http://www1.ap.dell.com/content/products/features.aspx/servers_Q4_W5_2007-12-01_pedge_t105_Q421211?c=my&cs=mybsd1&l=en&s=bsd An Ubuntu message says they see it with a Broadcom NetXtreme BCM5722 driver: http://ubuntuforums.org/showthread.php?p=3961378 Any suggestions on how I can poke at it to find what kind of hardware it's using and what driver I need to use for it? Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD on Dell T105? ($350 dual-core Opteron)
On Thursday 20 December 2007, Chris Shenton wrote: > [I'm adding -current as there are other discussions of hardware > compatibility there, trim if appropriate] > > Chris Shenton <[EMAIL PROTECTED]> writes: > > > > http://www.dell.com/downloads/global/products/pedge/en/pe_T105_spec_s > >heet.pdf > > > > Processors Single AMD Opteron TM 1000 series at up to > > 2.8GHz; Single AMD SempronTM LE1250 at 2.2GHz > > > > HyperTransportTMHyperTransport at 2000MT/s > > > > Chipset nVidia CK8-04 Pro > > > > Network Interfaces Single embedded Gigabit3 NIC > > I installed FreeBSD 7.0-BETA4 amd64 this morning and it boots fine, > detects both CPUs, but can't seem to find a driver for the ethernet. It > doesn't offer anything at install time (only slip and ppp) and shows > nothing in ifconfig when running. > > The one thing I see in dmesg is: > > pci2: at device 0.0 (no driver attached) > > Some pages I've found say this is a Broadcom 5721J chipset: > > > http://www1.ap.dell.com/content/products/features.aspx/servers_Q4_W5_20 >07-12-01_pedge_t105_Q421211?c=my&cs=mybsd1&l=en&s=bsd > > An Ubuntu message says they see it with a Broadcom NetXtreme BCM5722 > driver: > > > http://ubuntuforums.org/showthread.php?p=3961378 > > Any suggestions on how I can poke at it to find what kind of hardware > it's using and what driver I need to use for it? Sounds like the bge(4) driver might work. Take a look at "pciconfig -lv" to identify the chip and PCI vendor id. Try adding that information to src/sys/dev/bge/if_bge.c::bge_devs[] and subsequent chip revision arrays. It's easiest to build a kernel w/o device bge and loading bge from modules. This way you can cd to src/sys/modules/bge and "make load; #test; make unload; #change source; #repeat" until it works. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: FreeBSD on Dell T105? ($350 dual-core Opteron)
On Thu, 20 Dec 2007 07:50:35 -0500 Chris Shenton <[EMAIL PROTECTED]> wrote: > Any suggestions on how I can poke at it to find what kind of hardware > it's using and what driver I need to use for it? 'pciconf -lv' is usually good for the "poking" part. -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mounted cd, tray locking, cdcontrol
FreeBSD 6.2-RELEASE-p6 amd64
This is what "cdcontrol eject" performs (incidentally, on a mounted acd
device):
11991 cdcontrol CALL open(0x7fffe130,0,0x9)
11991 cdcontrol NAMI "/dev/acd0"
11991 cdcontrol RET open 3
11991 cdcontrol CALL ioctl(0x3,CDIOCALLOW,0)
11991 cdcontrol RET ioctl 0
11991 cdcontrol CALL ioctl(0x3,CDIOCEJECT,0)
11991 cdcontrol RET ioctl -1 errno 16 Device busy
11991 cdcontrol CALL exit(0x)
This is how handling of the above ioctls looks in atapi-cd.c:
...
case CDIOCALLOW:
error = acd_prevent_allow(dev, 0);
cdp->flags &= ~F_LOCKED;
break;
...
case CDIOCEJECT:
if (pp->acr != 1) {
error = EBUSY;
break;
}
error = acd_tray(dev, 0);
break;
...
In other words:
CDIOCALLOW - unconditionally send "allow" to the device
CDIOCEJECT - if device is opened by anybody else other than ioctl issuer
then return EBUSY, otherwise send "stop (without eject)", "allow", "eject".
So, if you issue cdcontrol eject on a mounted (or otherwise opened
device) the net result is weird: CD tray is not ejected but it is
unlocked, i.e pressing a button on the physical device will eject the tray.
I think this is messy. The most obvious target is cdcontrol - it doesn't
have to issue CDIOCALLOW and actually this ioctl creates all the mess
(but read about SCSI devices below).
Possible secondary target: maybe CDIOCALLOW should also do some checking
of current access to the device.
BTW, it would be also nice to have separate 'allow' and 'prevent'
commands of cdcontrol, if just for the sake of testing.
>From a cursory glance at scsi_cd.c it seems that for SCSI CD-ROMs there
are no "in-use" checks for either of the ioctls:
CDIOCALLOW - unconditionally send "allow" to the device
CDIOCEJECT - unconditionally send "eject"
I am not sure if I like this but at least this is consistent: if I'd
issue "cdcontrol eject" on a cd device, then it would be actually
ejected no matter what. (And this is exactly because of the explicit
CDIOCALLOW from cdcontrol, because "prevent" was internally issued to a
drive on device open). For acd it neither ejects nor preserves original
state.
So another target is inconsistency in ioctl handling between cd and acd.
And I don't want yet to cloud the matters with interaction between
scsi-cd driver and atapi-cd driver when atapicam is enabled :-)
P.S. a PR with a terse description is already opened for the above
behavior of acd:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118779
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mounted cd, tray locking, cdcontrol
On Thu, Dec 20, 2007 at 02:59:13PM +0200, Andriy Gapon wrote: > P.S. a PR with a terse description is already opened for the above > behavior of acd: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118779 This is a regression since RELENG_4 (RELENG_3 was OK), please take a look at (incorrectly closed) PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/28166 Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance!
> I have read all related threads about performance problems with multi > core systems but still have no idea what to do to make thinks better. > Below are results of testing postgresql on HP DL380G5 using sysbench. > The results are comparable to: > http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 > but the same tests running on the same hardware using Linux (kernel > 2.6.18-53.1.4.el5 SMP x86_64) are very different. > PostgreSQL is tuned equal. > > results: > FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE > #threads#transactions/sec user/system > 1 500 7.4%,5.3% > 5 199030.9%,23.4% > 10 251039.9%,35.0% > 20 254944.5%,43.5% > 40 192129.8%,59.4% > 60 158022.7%,70.6% > 80 134118.9%,75.9% > 100 122716.5%,79.3% > > Linux > #threads#transactions/sec > 1 693 > 5 3539 > 10 5789 > 20 5791 > 40 5661 > 60 5517 > 80 5401 > 100 5319 > > What can be done to improve these results? What postgres-version did you use for this benchmark? Eventhough this is a synthetic benchmark the difference in performance may indicate some penalties on 8-core servers on FreeBSD. According to http://people.freebsd.org/~kris/scaling/mysql.html mysql scale the same until until 8 clients on both Linux and FreeBSD. This is an older test though and Linux has probably done some optimizations. Could be interesting so see whether the results differ if you disable one of the cpu's and rerun the tests. -- 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: FreeBSD 7 on old SMP server?
Joshua Coombs wrote: > MaXX wrote: > > I have an old netfinity 7000 (Quad PIII 500, 1Gb RAM) running 6.2 > > at the moment. I was wondering if it will take benefit of all the > > SMP improvement of 7 or is it too old? It runs a few postgresql > > databases, peak loads in the 2 to 4 range. It's not too old, and I would recommend that you give 7.0 a try. Don't forget to enable the ULE scheduler. I've got a dual Celeron-466 with 448 MB RAM, and it's certainly not too old, either. (OK, Celerons aren't the best processor to build an SMP system, but it does work nicely for me. And it was dead cheap for an SMP system at the time when I built it, about 10 years ago.) > My hacked up 386 showed gains going from 6.2 to 7, the big win that I've > noticed is scp throughput, I can sustain 40 to 45kbps where in the past > the box walled at around 30kbps. Apache seems to have less latency > responding to gets also. I'm just running a 7b3 kernel at the moment, > I'm going to have to repartition with a lot more swap space to be able > to build a 7 world (When did the ram use for a buildworld skyrocket?!) > but even with this setup, 7 + ULE is a win for me. Are you saying you run FreeBSD 7 on an 80386(SX/DX) machine? How exactly did you hack it? As far as I know, support for 80386 processors was removed from FreeBSD a while ago. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0BETA4 /usr/src/gnu/usr.bin/cc/cc_int Thrashes
Julian Stacey wrote: > Has 7.0-BETA4 perhaps wrongly got a -pipe in the .mk macros ? It was added 9 years 7 months ago my JKH (see the CVS repository, src/share/mk/sys.mk rev 1.31). He wrote: "Add -pipe to default CFLAGS. The optimization it provides is cheap and does not require any special action on the part of the user to take advantage of it." It might not be that "cheap" anymore with gcc 4.2 being the default compiler now, known to be somewhat more RAM- hungry than its predecessors. However, I still think that -pipe should be kept on by default, because it will help on the vast majority of machines. Old machines with very little RAM need some special-tuning anyway, so it's reasonable to give them special CFLAGS that don't contain -pipe. (Apart from that I would recommend to use a faster and sufficiently RAM-equipped machine for building and then perform only the install on the smaller machine, or install directly on its harddisk by plugging it into the faster machine temporarily. That's how I used to update an old 486SX notebook that had only 4 MB RAM and no network except SLIP/PLIP.) YMMV, of course. Please take the above only as my personal opinion on the matter. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jlogin.sh - a small nice jails helper!
Miroslav Lachman wrote:
> It is nice idea, but I think you should have a better scripting style ;)
Yes, it almost looked like perl. :-)
May I suggest a few further improvements?
> login_shell="/bin/tcsh"
I certainly wouldn't want tcsh. How about looking at
$SHELL, and if it doesn't exist, then fall back to the
standard shell (which is /bin/sh).
Also, the last command (jexec) should be preceded by
"exec" so the shell doesn't hang around. So the last
part of the script would look like this:
jail_path=$(jls | awk '$1=='$jail_id' {print $4}')
if [ -z "$SHELL" -o ! -x "$jail_path/$SHELL" ]; then
login_shell="$SHELL"
else
login_shell="/bin/sh"
fi
echo "Logging in to $jail_hostname"
exec jexec $jail_id $login_shell
Best regards
Oliver
PS: By the way, here's another useful script that displays
processes running in jails, ordered by jail IDs:
http://www.secnetix.de/~olli/scripts/jps
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
___
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 on old SMP server?
Oliver Fromme wrote: > My hacked up 386 showed gains going from 6.2 to 7, the big win that I've > noticed is scp throughput, I can sustain 40 to 45kbps where in the past > the box walled at around 30kbps. Apache seems to have less latency > responding to gets also. I'm just running a 7b3 kernel at the moment, > I'm going to have to repartition with a lot more swap space to be able > to build a 7 world (When did the ram use for a buildworld skyrocket?!) > but even with this setup, 7 + ULE is a win for me. Are you saying you run FreeBSD 7 on an 80386(SX/DX) machine? How exactly did you hack it? As far as I know, support for 80386 processors was removed from FreeBSD a while ago. For a very short while with 6.0 I was tweaking the kernel to detect 386s as 486s, as well as using CPU_DISABLE_CMPXCHG and having ok luck. I've now got a Cyrix 486DrX-2 66 installed in place of my Am386DX-40, which supports CMPXCHG as well as ID'ing as a 486 so I don't need to do any tweaking to stay running. If I can get another viable 386DX box reassembled I'll see if 7 can be pressed into functioning on it as 6 could. Joshua Coombs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jlogin.sh - a small nice jails helper!
Oliver Fromme wrote:
Miroslav Lachman wrote:
> It is nice idea, but I think you should have a better scripting style ;)
Yes, it almost looked like perl. :-)
May I suggest a few further improvements?
> login_shell="/bin/tcsh"
I certainly wouldn't want tcsh. How about looking at
$SHELL, and if it doesn't exist, then fall back to the
standard shell (which is /bin/sh).
I have tought about optional second argument with shell name, your idea
about $SHELL is also good.
Also, the last command (jexec) should be preceded by
"exec" so the shell doesn't hang around. So the last
part of the script would look like this:
jail_path=$(jls | awk '$1=='$jail_id' {print $4}')
if [ -z "$SHELL" -o ! -x "$jail_path/$SHELL" ]; then
login_shell="$SHELL"
else
login_shell="/bin/sh"
fi
echo "Logging in to $jail_hostname"
exec jexec $jail_id $login_shell
Best regards
Oliver
PS: By the way, here's another useful script that displays
processes running in jails, ordered by jail IDs:
http://www.secnetix.de/~olli/scripts/jps
I am using your jps in slightly modified version ;)
ME="${0##*/}"
Usage()
{
cat <<-tac
$ME -- List processes that are running inside a jail.
This is intended to complement the standard jls(8) command.
Usage:
$MElist all jailed processes
$ME list only processes in jail
Run the jls(8) command to get a list of jails and JIDs.
tac
exit 1
}
if [ $# -gt 2 ]; then
Usage
fi
if [ $# -eq 1 ]; then
case "$1" in
""|*[!0-9]*) Usage ;;
esac
FILTER='$1=="'$1'"'
sum_jid="$1"
jname=`jls | awk "$FILTER"'{ print $3 }'`
else
FILTER='$1!="0"'
sum_jid="all"
jname="-"
fi
ps -axww -o jid,pid,%mem,rss,user,command | awk '$1!~/[0-9]/||'"$FILTER"
| sort -n
echo
echo "=="
echo " summary for JID $sum_jid / $jname"
echo " %MEMRSS VSZ %CPU "
ps -axww -o jid,%mem,rss,vsz,%cpu | awk '$1!~/[0-9]/||'"$FILTER" | awk
'{ sm += $2; sp += $3; sv += $4; sc += $5 } END { printf(" %3d %9i %9i
%3d \n", sm, sp, sv, sc) }'
#--
___
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 on old SMP server?
Joshua Coombs wrote: Oliver Fromme wrote: > My hacked up 386 showed gains going from 6.2 to 7, the big win that I've > noticed is scp throughput, I can sustain 40 to 45kbps where in the past > the box walled at around 30kbps. Apache seems to have less latency > responding to gets also. I'm just running a 7b3 kernel at the moment, > I'm going to have to repartition with a lot more swap space to be able > to build a 7 world (When did the ram use for a buildworld skyrocket?!) > but even with this setup, 7 + ULE is a win for me. Are you saying you run FreeBSD 7 on an 80386(SX/DX) machine? How exactly did you hack it? As far as I know, support for 80386 processors was removed from FreeBSD a while ago. For a very short while with 6.0 I was tweaking the kernel to detect 386s as 486s, as well as using CPU_DISABLE_CMPXCHG and having ok luck. I've now got a Cyrix 486DrX-2 66 installed in place of my Am386DX-40, which supports CMPXCHG as well as ID'ing as a 486 so I don't need to do any tweaking to stay running. If I can get another viable 386DX box reassembled I'll see if 7 can be pressed into functioning on it as 6 could. Joshua Coombs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Would that be a multiday buildworld? Brian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet loss every 30.999 seconds
Thanks, I'll test this later on today.
On Dec 19, 2007, at 1:11 PM, Kostik Belousov wrote:
On Wed, Dec 19, 2007 at 09:13:31AM -0800, David G Lawrence wrote:
Try it with "find / -type f >/dev/null" to duplicate the problem
almost
instantly.
I was able to verify last night that (cd /; tar -cpf -) > all.tar
would
trigger the problem. I'm working getting a test running with
David's ffs_sync() workaround now, adding a few counters there
should
get this narrowed down a little more.
Unfortunately, the version of the patch that I sent out isn't
going to
help your problem. It needs to yield at the top of the loop, but
vp isn't
necessarily valid after the wakeup from the msleep. That's a
problem that
I'm having trouble figuring out a solution to - the solutions that
come
to mind will all significantly increase the overhead of the loop.
As a very inadequate work-around, you might consider lowering
kern.maxvnodes to something like 2 - that might be low enough to
not trigger the problem, but also be high enough to not significantly
affect system I/O performance.
I think the following may be safe. It counts only the clean scanned
vnodes
and does not evaluate the vp, that indeed may be reclaimed, after
the sleep.
I never booted with the change.
diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c
index cbccc62..e686b97 100644
--- a/sys/ufs/ffs/ffs_vfsops.c
+++ b/sys/ufs/ffs/ffs_vfsops.c
@@ -1176,6 +1176,7 @@ ffs_sync(mp, waitfor, td)
struct ufsmount *ump = VFSTOUFS(mp);
struct fs *fs;
int error, count, wait, lockreq, allerror = 0;
+ int yield_count;
int suspend;
int suspended;
int secondary_writes;
@@ -1216,6 +1217,7 @@ loop:
softdep_get_depcounts(mp, &softdep_deps, &softdep_accdeps);
MNT_ILOCK(mp);
+ yield_count = 0;
MNT_VNODE_FOREACH(vp, mp, mvp) {
/*
* Depend on the mntvnode_slock to keep things stable enough
@@ -1233,6 +1235,11 @@ loop:
(IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 &&
vp->v_bufobj.bo_dirty.bv_cnt == 0)) {
VI_UNLOCK(vp);
+ if (yield_count++ == 500) {
+ yield_count = 0;
+ msleep(&yield_count, MNT_MTX(mp), PZERO,
+ "ffspause", 1);
+ }
continue;
}
MNT_IUNLOCK(mp);
___
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 on old SMP server?
Brian wrote: Would that be a multiday buildworld? Brian 10 days on average. : ) I'm trying a 7 build without -pipe to see if I can squeak it through with 64MB RAM + 384MB swap, I'd much prefer not having to do a dump/restore to reallocate space for more swap. I'm almost thinking a non -pipe build may be quicker given the limited ram I have. Josh C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
more cpufreq woes
Hi, I once again have a freeze with cpufreq, this time on a Tyan S3950 MB + X2 BE 2400 proc; dev.cpu.0.freq_levels: 2277/10 2178/91708 1980/76426 1782/62805 990/30193 Same proc works OK with Asus M2N32 WS Pro ... Same Tyan MB works OK with X2 BE 2350 which shows dev.cpu.0.freq_levels: 2079/10 1980/91311 1782/75334 990/40013 With 'sysctl debug.cpufreq.lowest=1000' it works OK, but that's not really what I'd like to do. This is on RELENG_6. Best, Arno ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI STR (s3) makes machine behave very odd
Hello, with Beta4 I tried 'acpiconf -s3'. The machine shut down but I couldn't wake it up with the keyboard. Pressing the power button makes the drives start up but the machine switches off two seconds later. This is done in an endless loop. I tried a kernel without any driver, just the absolut neccesarry like sc, no USB etc. Hardware is a ich9 board (Gigabyte p965-DS4) Here's some dmesg which looks suspicious: acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3fde (3) failed If someone can help diagnose the problem I can come up wtih the acpi tables. Thanks in advance, STR is a really big "must have" these days taking incredable fast machines booting incredible slowly and consuming increadible much power while idling... -Harry signature.asc Description: OpenPGP digital signature
Re: ACPI STR (s3) makes machine behave very odd
Harald Schmalzbauer schrieb am 21.12.2007 00:55 (localtime): > Hello, > > with Beta4 I tried 'acpiconf -s3'. The machine shut down but I couldn't > wake it up with the keyboard. > Pressing the power button makes the drives start up but the machine > switches off two seconds later. > This is done in an endless loop. > > I tried a kernel without any driver, just the absolut neccesarry like > sc, no USB etc. Hardware is a ich9 board (Gigabyte p965-DS4) Hmm, nonsense, it's something like P35-DS4, sorry > Here's some dmesg which looks suspicious: > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, 3fde (3) failed > > If someone can help diagnose the problem I can come up wtih the acpi tables. > > Thanks in advance, STR is a really big "must have" these days taking > incredable fast machines booting incredible slowly and consuming > increadible much power while idling... signature.asc Description: OpenPGP digital signature
Re: Performance!
On Thu, 20 Dec 2007 15:35:52 +0100
"Claus Guttesen" <[EMAIL PROTECTED]> wrote:
>
> What postgres-version did you use for this benchmark? Eventhough this
> is a synthetic benchmark the difference in performance may indicate
> some penalties on 8-core servers on FreeBSD.
>
> According to http://people.freebsd.org/~kris/scaling/mysql.html mysql
> scale the same until until 8 clients on both Linux and FreeBSD. This
> is an older test though and Linux has probably done some
> optimizations.
>
> Could be interesting so see whether the results differ if you disable
> one of the cpu's and rerun the tests.
>
I would try asking in the pgsql's performance mailing list , [EMAIL PROTECTED]
(u'll need to subscribe first).
there was a bit of discussion on this subject recently on a somewhat unrelated
thread ( http://archives.postgresql.org/pgsql-performance/2007-12/msg00276.php
)...
B
_
{Beto|Norberto|Numard} Meijome
If you're not part of the solution, you're part of the precipitate.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
