Error compiling FreeBSD-Stable with MFC'ed iconv locking
Hi John, after I updated my system (-STABLE) I received following compilation error while building the kernel (having ICONV built in): cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/libkern/iconv.c /usr/src/sys/libkern/iconv.c: In function 'iconv_mod_unload': /usr/src/sys/libkern/iconv.c:92: error: 'curthread' undeclared (first use in this function) /usr/src/sys/libkern/iconv.c:92: error: (Each undeclared identifier is reported only once /usr/src/sys/libkern/iconv.c:92: error: for each function it appears in.) /usr/src/sys/libkern/iconv.c: In function 'iconv_sysctl_add': /usr/src/sys/libkern/iconv.c:401: error: 'curthread' undeclared (first use in this function) /usr/src/sys/libkern/iconv.c: In function 'iconv_converter_handler': /usr/src/sys/libkern/iconv.c:452: error: 'curthread' undeclared (first use in this function) I applied following patch - and it works: --- sys/sys/sx.h.orig 2009-02-14 12:56:11.0 + +++ sys/sys/sx.h2009-02-14 12:57:33.0 + @@ -35,6 +35,7 @@ #include #include #include +#include #ifdef _KERNEL #include Google didn't find anything so I thought I mail this quickly. Best regards, Jens signature.asc Description: OpenPGP digital signature
Re: HEADS UP: Major CAM performance regression
Ivan Voras wrote: 2009/2/13 Scott Long : Ivan Voras wrote: Scott Long wrote: I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few days once I've gotten confirmation that the fix works and doesn't cause any adverse side-effects. Anyone wanting to help in this validation effort should apply the attached patch to their kernel source tree and recompile. Please contact me directly by email to report if the problem is fixed for you. I notice that write performance on an ESXi 3.5 hosted system is doubled, but read performance remains the same (in bonnie++). On a CISS system there is no significant change. bonnie is an unreliable tool for measuring performance. I'll try your suggestion if you have one. I don't have a magic universal testing suite in my back pocket, sorry. You need to look at your expected workload and develop tests to simulate it. When I do testing during driver development, I try a lot of different parallel, sequential, large i/o, and small i/o combinations. (except if it's about bonnie++ primarily measuring sequential read/write - if a system can't do sequential IO well, it probably won't do random IO well) This is completely false. Disks can't do sequential i/o very well due to the physical limits of long seek times, but those seek times can be greatly amortized, even in a random workload, with tagged queueing and parallel dispatch from the OS. Bonnie simply cannot exercise this very well. Bonnie tests system latency for discrete I/O's. That is all it tests. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: Major CAM performance regression
2009/2/14 Scott Long : >> I'll try your suggestion if you have one. > > I don't have a magic universal testing suite in my back pocket, sorry. > You need to look at your expected workload and develop tests to simulate > it. When I do testing during driver development, I try a lot of > different parallel, sequential, large i/o, and small i/o combinations. Of course you're right about testing for specific workloads - I just thought you needed data points "from the field" if the patch is helping or not. >> (except if it's about bonnie++ primarily measuring sequential >> read/write - if a system can't do sequential IO well, it probably >> won't do random IO well) > > This is completely false. Disks can't do sequential i/o very well due > to the physical limits of long seek times, but those seek times can be I don't follow this - where are the long seek times in sequential IO? > greatly amortized, even in a random workload, with tagged queueing and > parallel dispatch from the OS. Bonnie simply cannot exercise this very > well. > > Bonnie tests system latency for discrete I/O's. That is all it tests. Doesn't tagged queuing serve, among other things, to decrease overall latency for IOs? Since AFAIK UFS queues multiple IO requests in both directions (read-ahead and write-behind), shouldn't the benefits of the patch - liberating the tags - be visible even with sequential IO? I have the systems on which I tested for a few more days, if you need the data I can run some other tests (randomio?). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: Major CAM performance regression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Long wrote: > All, > > A major performance regression was introduced to the CAM subsystem in > FreeBSD 7.1. The following configurations are known to be affected: > > VMWare ESX > VMWare Fusion > (using bt or lsilogic controller options) > HP CISS RAID > Some MPT-SAS combinations with SATA drives attached > (Includes Dell SAS5/ir, but not PERC5/PERC6). > > Pure SCSI and SAS subsystems likely are NOT affected. Any hardware > that uses the 'ata' driver is also definitely NOT affected. To > determine if your installation is affected, run the following command as > root: > > camcontrol tags da0 > > Substitute 'da0' with another appropriate drive device number, if > needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are > 'ad' devices, they are NOT affected. > > The result from running this command should be an output similar to the > following: > > (pass0:mpt0:0:8:0): device openings: 255 > > If, instead, it reports a value of '1', you are likely affected. Note > that it may be normal for USB memory devices to report a low number. > Also, many legacy SCSI disks, and devices that are not disks, may also > be expected to report a low number. > > The effect of this problem is that only one I/O command will be issued > to the controller and disk at a time, instead of overlapping multiple > commands in parallel. This causes significantly higher latency in > servicing moderate and heavy I/O workloads, leading to very poor > performance. Performance can be easily compared by downgrading to > FreeBSD 7.0. Any estimate on when this will be MFC'ed down to RELENG_7 yet? //Svein - -- - +---+--- /"\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE - +---+--- Picture Gallery: https://gallery.stillbilde.net/v/svein/ - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmW+/IACgkQODUnwSLUlKTVuACgpk70v7d6hyBmvIdaFhLsDA01 nqIAoJkljSXU+TRb7tl9xM8EEerFeMGz =0mNQ -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Problems with samba and vista on 7.1-STABLE
I have few Samba servers running FreeBSD 7.1 were we have a problem with
connection blocking from a few Vista systems that run programs that watch
directories and files on the samba shares.
On my test setup I have managed to get a hang in about 30 min.
Samba is built with minimum functions and full debug. Options don't seems
to have any impact on the problem.
The PC uses Vista Business SP1 and all patches, I run a DAM program called
IMatch that watches for changes in the photo database.
The FreeBSD server is an up-to-date quad AMD server with 8GB running
7.1-STABLE. In normal operation, I see the following:
# sockstat | grep 445
glz smbd 7828 23 tcp4 10.255.253.1:445 10.255.253.2:57355
root smbd 76917 19 tcp4 127.0.0.1:445 *:*
root smbd 76917 20 tcp4 10.255.253.1:445 *:*
When I get the hang, it looks like this:
# sockstat | grep 445
root smbd 7828 23 tcp4 10.255.253.1:445 10.255.253.2:57355
root smbd 76917 19 tcp4 127.0.0.1:445 *:*
root smbd 76917 20 tcp4 10.255.253.1:445 *:*
and the GDB session:
# gdb /usr/local/sbin/smbd 7828
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 "amd64-marcel-freebsd"...
Attaching to program: /usr/local/sbin/smbd, process 7828
Reading symbols from /usr/local/lib/libldap-2.3.so.2...done.
Loaded symbols for /usr/local/lib/libldap-2.3.so.2
Reading symbols from /usr/local/lib/liblber-2.3.so.2...done.
Loaded symbols for /usr/local/lib/liblber-2.3.so.2
Reading symbols from /usr/local/lib/libcups.so.2...done.
Loaded symbols for /usr/local/lib/libcups.so.2
Reading symbols from /usr/lib/libssl.so.5...done.
Loaded symbols for /usr/lib/libssl.so.5
Reading symbols from /lib/libcrypto.so.5...done.
Loaded symbols for /lib/libcrypto.so.5
Reading symbols from /lib/libz.so.4...done.
Loaded symbols for /lib/libz.so.4
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libcrypt.so.4...done.
Loaded symbols for /lib/libcrypt.so.4
Reading symbols from /usr/lib/libpam.so.4...done.
Loaded symbols for /usr/lib/libpam.so.4
Reading symbols from /usr/local/lib/libexecinfo.so.1...done.
Loaded symbols for /usr/local/lib/libexecinfo.so.1
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /usr/local/lib/libdmalloc.so.1...done.
Loaded symbols for /usr/local/lib/libdmalloc.so.1
Reading symbols from /usr/local/lib/libpopt.so.0...done.
Loaded symbols for /usr/local/lib/libpopt.so.0
Reading symbols from /lib/libthr.so.3...done.
[New Thread 0x800a62e00 (LWP 100076)]
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/libsasl2.so.2...done.
Loaded symbols for /usr/local/lib/libsasl2.so.2
Reading symbols from /usr/local/lib/libintl.so.8...done.
Loaded symbols for /usr/local/lib/libintl.so.8
Reading symbols from /usr/local/lib/nss_ldap.so.1...done.
Loaded symbols for /usr/local/lib/nss_ldap.so.1
Reading symbols from /usr/lib/libcom_err.so.4...done.
Loaded symbols for /usr/lib/libcom_err.so.4
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
[Switching to Thread 0x800a62e00 (LWP 100076)]
0x000801f01d6c in select () from /lib/libc.so.7
(gdb) directory /usr/ports/net/samba32-devel/work/samba-3.2.7/source/
Source directories searched:
/usr/ports/net/samba32-devel/work/samba-3.2.7/source:$cdir:$cwd
(gdb) bt
#0 0x000801f01d6c in select () from /lib/libc.so.7
#1 0x000801d0f4d4 in select () from /lib/libthr.so.3
#2 0x006749fe in sys_select (maxfd=24, readfds=0x7fffd420,
writefds=0x7fffd3a0, errorfds=0x0, tval=0x7fffd500)
at lib/select.c:93
#3 0x004df64c in smbd_process () at smbd/process.c:839
#4 0x00854074 in main (argc=2, argv=0x7fffd638) at
smbd/server.c:1450
(gdb) frame 2
#2 0x006749fe in sys_select (maxfd=24, readfds=0x7fffd420,
writefds=0x7fffd3a0, errorfds=0x0, tval=0x7fffd500)
at lib/select.c:93
93 ret = select(maxfd,readfds2,writefds,errorfds,tval);
(gdb) print tval
$1 = (struct timeval *) 0x7fffd500
(gdb) print *tval
$2 = {tv_sec = 59, tv_usec = 77}
(gdb) The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/local/sbin/smbd, process 7828
The following is a truss of the process until I have seen the switch to
root as owner:
# time truss -p 8307
gettimeofday({1234648077.989004 },0x0) = 0 (0x0)
gettimeofday({1234648077.989081 },0x0) = 0 (0x0)
Re: Unhappy Xorg upgrade
I've just upgraded to the latest xorg on my amd64 box 7.1-STABLE FreeBSD 7.1-STABLE #0: Fri Jan 16 07:33:20 PST 2009 I have a radeon graphics card, drm0: on vgapci0 - had to add the option mentioned in UPDATING Section "ServerLayout" Option "AllowEmptyInput" "off" ... Things seem mostly running on my box, though there are many of these emacs Xlib: extension "Generic Event Extension" missing on display ":0.0". ... I now see that ssh into a remote host (solaris 10 sparc), running emacs there pops up a window, but then typing anything into the window kills it, with X protocol error: BadAlloc (insufficient resources for operation) on protocol request 149 (on the remote machine). xv works ok. This doesn't happen if the remote host is linux rh4... This didn't happen before the xorg upgrade. Seems to be some sort of incompatibility in X11. Any ideas? Sam Sirlin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
