From gnn at freebsd.org Thu May 1 01:13:49 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Thu May 1 01:13:54 2008 Subject: Some odd behaviour of vmstat and vmtotal... Message-ID: Howdy, In deploying 7.0 at work we were finding a persistent problem when running "vmstat 1" on systems. The problem shows up as a 10ms "pause" in processing, usually packet stamping and forwarding by a user level process. This is due to the fact that vmstat calls the vmtotal() routine which in turn does a whole lot of locking. The vmtotal call locks and walks the VM object list twice in a mark and sweep operation. So, the question is, "What is the right way to fix this?" I could remove the locking since the O_ACTIVE bit is not used by any other routine besides vmtotal, but I'm not too happy about that. The relevant code can be found in src/sys/vm/vm_meter.c in vmtotal(). Thoughts? Best, George From mtm at wubethiopia.com Thu May 1 04:56:52 2008 From: mtm at wubethiopia.com (Mike Makonnen) Date: Thu May 1 04:56:57 2008 Subject: error in src/etc/rc.d/mountcritlocal In-Reply-To: <20080430151402.23674a45.oliver@FreeBSD.org> References: <20080428173019.9741ad41.oliver@FreeBSD.org> <4817FAC3.3090304@wubethiopia.com> <20080430151402.23674a45.oliver@FreeBSD.org> Message-ID: <48194E3A.5000609@wubethiopia.com> Oliver Lehmann wrote: > Mike Makonnen wrote: > > >> I'm not sure what you mean. The checkyesno() routine considers "true" a >> valid parameter. Could you please post the exact error you're getting. >> > > I already posted it... I'm getting: > > $true is not set properly - see rc.conf(5) > > This is because: > > you call "start_boot true" > start_boot itself calls checkyesno $1 - so it calls "checkyesno true" > > checkyesno then defines _value with "eval _value=\$${1}" so _value gets > $true which is not an allowed value. > > let me past the comment of checkyesno: > > # checkyesno var > # Test $1 variable, and warn if not set to YES or NO. > # Return 0 if it's "yes" (et al), nonzero otherwise. > > A variablename has to be handed over to checkyesno, not a value like > "true" or "yes" or whatever else. You see the error? > > Please try the attached patch. Thanks! Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ wubethiopia.com | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm @ FreeBSD.Org | FreeBSD - http://www.freebsd.org -------------- next part -------------- Index: etc/rc.subr =================================================================== RCS file: /home/ncvs/src/etc/rc.subr,v retrieving revision 1.80 diff -u -r1.80 rc.subr --- etc/rc.subr 26 Jan 2008 11:22:11 -0000 1.80 +++ etc/rc.subr 1 May 2008 04:57:36 -0000 @@ -171,10 +171,14 @@ { local always - if [ -n "$1" ] && checkyesno $1; then + case $1 in + # "yes", "true", "on", or "1" + [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1) always=true - else + ;; + *) always=false + ;; fi if [ "$autoboot" = yes -o "$always" = true ]; then echo "ERROR: ABORTING BOOT (sending SIGTERM to parent)!" From alfred at freebsd.org Thu May 1 05:15:56 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Thu May 1 05:16:00 2008 Subject: Some odd behaviour of vmstat and vmtotal... In-Reply-To: References: Message-ID: <20080501045736.GU30325@elvis.mu.org> * gnn@freebsd.org [080430 18:13] wrote: > Howdy, > > In deploying 7.0 at work we were finding a persistent problem when > running "vmstat 1" on systems. The problem shows up as a 10ms "pause" > in processing, usually packet stamping and forwarding by a user level > process. This is due to the fact that vmstat calls the vmtotal() > routine which in turn does a whole lot of locking. The vmtotal call > locks and walks the VM object list twice in a mark and sweep > operation. > > So, the question is, "What is the right way to fix this?" I could > remove the locking since the O_ACTIVE bit is not used by any other > routine besides vmtotal, but I'm not too happy about that. > > The relevant code can be found in src/sys/vm/vm_meter.c in vmtotal(). > > Thoughts? Can you _really_ remove the locking? I don't think that would be safe if the list is being manipulated, but I haven't checked. Typically one uses a sentinal to get around such problems. Basically insert a dummy object that no one should touch other than you, then drop the lock periodically and insert it into the list, then resume. -- - Alfred Perlstein From oliver at FreeBSD.org Thu May 1 07:21:39 2008 From: oliver at FreeBSD.org (Oliver Lehmann) Date: Thu May 1 07:21:43 2008 Subject: error in src/etc/rc.d/mountcritlocal In-Reply-To: <48194E3A.5000609@wubethiopia.com> References: <20080428173019.9741ad41.oliver@FreeBSD.org> <4817FAC3.3090304@wubethiopia.com> <20080430151402.23674a45.oliver@FreeBSD.org> <48194E3A.5000609@wubethiopia.com> Message-ID: <20080501092131.0a394c20.oliver@FreeBSD.org> Mike Makonnen wrote: > Please try the attached patch. > Thanks! I cannot really test the patch because this involves rebooting the system which is not that easy as it sounds ;) You can just test it yourself. Put some garbage in /etc/fstab reboot w/o your patch - see the strange error message - apply your patch and reboot once more... -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From geo at pulsar.bg Thu May 1 09:24:38 2008 From: geo at pulsar.bg (Georgi Iovchev) Date: Thu May 1 09:24:42 2008 Subject: is there driver for (Bearlake) HECI Controller for releng_7 (or 7_0_0) Message-ID: <422521026.20080501122436@pulsar.bg> Hello lists Intel G33 motherboard (Intel DG33FB) with FreeBSD 7 AMD64 (7.0-RELEASE-p1) one thing is missing: [root@asterisk ~]# pciconf -lv | grep -A3 none none0@pci0:0:3:0: class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '(Bearlake) HECI Controller' class = simple comms Actually I dont know if I really need this (machine will be used for asterisk voip solution), but for completeness is there a driver for this piece of hardware? 10x in advance From sclark46 at earthlink.net Thu May 1 13:05:25 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu May 1 13:05:30 2008 Subject: reboot after panic Message-ID: <4819BB3A.6000407@earthlink.net> Hello List How do I get my freebsd 6.1 box to automatically reboot after a panic? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From wb at freebie.xs4all.nl Thu May 1 13:12:40 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Thu May 1 13:12:48 2008 Subject: reboot after panic In-Reply-To: <4819BB3A.6000407@earthlink.net> References: <4819BB3A.6000407@earthlink.net> Message-ID: <20080501131235.GA47003@freebie.xs4all.nl> Quoting Stephen Clark, who wrote on Thu, May 01, 2008 at 08:44:42AM -0400 .. > Hello List > > How do I get my freebsd 6.1 box to automatically reboot after a panic? It should do that automatically? > Thanks, > Steve > -- > > "They that give up essential liberty to obtain temporary safety, > deserve neither liberty nor safety." (Ben Franklin) > > "The course of history shows that as a government grows, liberty > decreases." (Thomas Jefferson) > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --- end of quoted text --- -- Wilko Bulte wilko@FreeBSD.org From freebsd at byshenk.net Thu May 1 13:27:27 2008 From: freebsd at byshenk.net (Greg Byshenk) Date: Thu May 1 13:27:31 2008 Subject: samba build failure on 6-STABLE Message-ID: <20080501132724.GD840@core.byshenk.net> I'm posting this to freebsd-stable even though it is a problem with a port, because the port itself has not changed, but a rebuild fails (on a system and with a configuration that worked before my most recent system updates). Basically my problem is that the current Samba3 (samba-3.0.28,1) won't build on a recent 6-STABLE system (I noticed it with sources csup'd 24 April, and it continues with sources csup'd today, 1 May). The strange thing is that this is a version of samba that has previously built successfully, on the machine and with the configuration that is now failing. (I was attempting to rebuild because I saw some strange library errors.) This at least suggests to me that the problem is _not_ due to something changing with Samba, but to some other change that is being reflected in the Samba build. The system in question is built from sources csup'd today (1 May 2008), with all installed ports current as of today. The same Samba did build successfully with a source and ports tree csup'd on 7 March 2008. As a test to see if there is some problem with the ports dependencies, I've tried a 'portupgrade -fR samba'; all of the dependencies built fine, but then I got the same error when attempting to build Samba itself. It is not definitive, but this suggests to me that this is not a ports problem (per se), but a kernel/world problem. This latter is highlighted by the fact that Samba builds without error on a system with sources csup'd on 17 April. That is, if I take the exact same system on which the build fails, revert my world/kernel to a build from 17 April (leaving everything else exactly the same), then the error disappears and Samba builds successfully. The actual error is below. Any ideas are welcome. I have a machine that I can play with if someone would like me to try anything. -greg Compiling smbd/oplock_linux.c smbd/oplock_linux.c: In function `signal_handler': smbd/oplock_linux.c:73: error: structure has no member named `si_fd' The following command failed: cc -I. -I/usr/ports/net/samba3/work/samba-3.0.28/source -O2 -fno-strict-aliasing -pipe -D_SAMBA_BUILD_=3 -I/usr/local/include -I/usr/ports/net/samba3/work/samba-3.0.28/source/iniparser/src -Iinclude -I./include -I. -I. -I./lib/replace -I./lib/talloc -I./tdb/include -I./libaddns -I./librpc -DHAVE_CONFIG_H -I/usr/local/include -DLDAP_DEPRECATED -I/usr/ports/net/samba3/work/samba-3.0.28/source/lib -D_SAMBA_BUILD_=3 -fPIC -DPIC -c smbd/oplock_linux.c -o smbd/oplock_linux.o *** Error code 1 Stop in /usr/ports/net/samba3/work/samba-3.0.28/source. *** Error code 1 Stop in /usr/ports/net/samba3. *** Error code 1 Stop in /usr/ports/net/samba3. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From mike at jellydonut.org Thu May 1 14:39:30 2008 From: mike at jellydonut.org (Michael Proto) Date: Thu May 1 14:39:35 2008 Subject: samba build failure on 6-STABLE In-Reply-To: <20080501132724.GD840@core.byshenk.net> References: <20080501132724.GD840@core.byshenk.net> Message-ID: <4819D621.9090901@jellydonut.org> Greg Byshenk wrote: > I'm posting this to freebsd-stable even though it is a problem with a port, > because the port itself has not changed, but a rebuild fails (on a system > and with a configuration that worked before my most recent system updates). > > Basically my problem is that the current Samba3 (samba-3.0.28,1) won't build > on a recent 6-STABLE system (I noticed it with sources csup'd 24 April, and > it continues with sources csup'd today, 1 May). The strange thing is that > this is a version of samba that has previously built successfully, on the > machine and with the configuration that is now failing. (I was attempting > to rebuild because I saw some strange library errors.) This at least > suggests to me that the problem is _not_ due to something changing with Samba, > but to some other change that is being reflected in the Samba build. > > > The system in question is built from sources csup'd today (1 May 2008), with > all installed ports current as of today. The same Samba did build successfully > with a source and ports tree csup'd on 7 March 2008. > > As a test to see if there is some problem with the ports dependencies, I've > tried a 'portupgrade -fR samba'; all of the dependencies built fine, but then > I got the same error when attempting to build Samba itself. It is not > definitive, but this suggests to me that this is not a ports problem (per se), > but a kernel/world problem. > > This latter is highlighted by the fact that Samba builds without error on a > system with sources csup'd on 17 April. That is, if I take the exact same > system on which the build fails, revert my world/kernel to a build from > 17 April (leaving everything else exactly the same), then the error > disappears and Samba builds successfully. > > > The actual error is below. Any ideas are welcome. I have a machine that I can > play with if someone would like me to try anything. > > -greg > > > Compiling smbd/oplock_linux.c > smbd/oplock_linux.c: In function `signal_handler': > smbd/oplock_linux.c:73: error: structure has no member named `si_fd' > The following command failed: > cc -I. -I/usr/ports/net/samba3/work/samba-3.0.28/source -O2 -fno-strict-aliasing -pipe -D_SAMBA_BUILD_=3 -I/usr/local/include -I/usr/ports/net/samba3/work/samba-3.0.28/source/iniparser/src -Iinclude -I./include -I. -I. -I./lib/replace -I./lib/talloc -I./tdb/include -I./libaddns -I./librpc -DHAVE_CONFIG_H -I/usr/local/include -DLDAP_DEPRECATED -I/usr/ports/net/samba3/work/samba-3.0.28/source/lib -D_SAMBA_BUILD_=3 -fPIC -DPIC -c smbd/oplock_linux.c -o smbd/oplock_linux.o > *** Error code 1 > > Stop in /usr/ports/net/samba3/work/samba-3.0.28/source. > *** Error code 1 > > Stop in /usr/ports/net/samba3. > *** Error code 1 > > Stop in /usr/ports/net/samba3. > I can confirm this on a 6-STABLE system last SUPed (kernel and world rebuilt) to 20080428 11:23 EDT. samba-3.0.28,1 built fine on this box when it was 6.3-RELEASE, and now fails in exactly the same place when trying to rebuild on 6-STABLE. -Proto From xenophon at irtnog.org Thu May 1 15:58:50 2008 From: xenophon at irtnog.org (Matthew X. Economou) Date: Thu May 1 15:58:54 2008 Subject: reboot after panic In-Reply-To: <4819BB3A.6000407@earthlink.net> References: <4819BB3A.6000407@earthlink.net> Message-ID: Steve, I recall having to set dumpdev in /etc/rc.conf before I could get FreeBSD to reboot automatically after a panic. I have dumpdev=AUTO set on all of my headless servers. If you are feeling especially brave, you can also set fsck_y_enable=YES and background_fsck=NO. Good luck! ;) -- "I slashread your textcast about jargon and nodnodnod with your cyber-sentiment." - gad_zuki! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4514 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080501/ecf703f5/smime.bin From sam at freebsd.org Thu May 1 15:59:09 2008 From: sam at freebsd.org (Sam Leffler) Date: Thu May 1 15:59:12 2008 Subject: Some odd behaviour of vmstat and vmtotal... In-Reply-To: <20080501045736.GU30325@elvis.mu.org> References: <20080501045736.GU30325@elvis.mu.org> Message-ID: <4819E3F0.9040308@freebsd.org> Alfred Perlstein wrote: > * gnn@freebsd.org [080430 18:13] wrote: > >> Howdy, >> >> In deploying 7.0 at work we were finding a persistent problem when >> running "vmstat 1" on systems. The problem shows up as a 10ms "pause" >> in processing, usually packet stamping and forwarding by a user level >> process. This is due to the fact that vmstat calls the vmtotal() >> routine which in turn does a whole lot of locking. The vmtotal call >> locks and walks the VM object list twice in a mark and sweep >> operation. >> >> So, the question is, "What is the right way to fix this?" I could >> remove the locking since the O_ACTIVE bit is not used by any other >> routine besides vmtotal, but I'm not too happy about that. >> >> The relevant code can be found in src/sys/vm/vm_meter.c in vmtotal(). >> >> Thoughts? >> > > Can you _really_ remove the locking? I don't think that would be safe > if the list is being manipulated, but I haven't checked. > > Typically one uses a sentinal to get around such problems. Basically > insert a dummy object that no one should touch other than you, then > drop the lock periodically and insert it into the list, then resume. > > net80211 uses a scan generation # to walk it's node lists. No sentinel. Sam From gavin at FreeBSD.org Thu May 1 16:49:32 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu May 1 16:49:36 2008 Subject: What does system do after "Uptime: "? In-Reply-To: <200804301544.20802.jhb@freebsd.org> References: <481560AC.90109@delphij.net> <1209376409.59233.14.camel@buffy.york.ac.uk> <4818BF27.2080209@delphij.net> <200804301544.20802.jhb@freebsd.org> Message-ID: <1209660552.68622.53.camel@buffy.york.ac.uk> On Wed, 2008-04-30 at 15:44 -0400, John Baldwin wrote: > On Wednesday 30 April 2008 02:49:11 pm Xin LI wrote: > > Gavin Atkinson wrote: > > | On Sun, 2008-04-27 at 22:29 -0700, Xin LI wrote: > > |> Hi, > > |> > > |> Just wonder what the system would do after Uptime: during reboot? Will > > |> there be any callbacks be called? I have received some report regarding > > |> hangs after this, and IIRC the only operation is to IPI BSP to do reboot? > > | > > | Several callbacks are called after that message. Anything that > > | registers with the shutdown_post_sync or shutdown_final event handler, > > | for example, and the dump routine if you are using "reboot -d". > > | > > | Before trying to diagnose this, however, make sure you are running with > > | sys/dev/usb/ehci_pci.c 1.30 (which has also been MFC'd to 6/7), as that > > | seems to have been the cause of most of the recently reported "hangs > > | after printing uptime" PRs. > > > > I see... It seems that this is the culprit. > > > > To John: Do you think it's worthy to make this an errata to the > > supported RELENG_6_X and RELENG_7_0 branches? > > If someone wants to push re@ to do that they can, but my experience with > getting re@ to actually get errata fixes has me skeptical (I think I had > patches for about 6 or 7 panics or kernel deadlocks for 6.2 that never got > pushed as errata patches). FWIW, there have been probably around 10 PRs in in the last few months about this behaviour. I'd vote for it as an errata candidate. Gavin From delphij at delphij.net Thu May 1 16:59:19 2008 From: delphij at delphij.net (Xin LI) Date: Thu May 1 16:59:22 2008 Subject: What does system do after "Uptime: "? In-Reply-To: <1209660552.68622.53.camel@buffy.york.ac.uk> References: <481560AC.90109@delphij.net> <1209376409.59233.14.camel@buffy.york.ac.uk> <4818BF27.2080209@delphij.net> <200804301544.20802.jhb@freebsd.org> <1209660552.68622.53.camel@buffy.york.ac.uk> Message-ID: <4819F6D3.80104@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gavin Atkinson wrote: | FWIW, there have been probably around 10 PRs in in the last few months | about this behaviour. I'd vote for it as an errata candidate. FWIW I have written to re@ indicating some changes I wanted for RELENG_7_0 as candidates. Could you please let me know if I have missed something important? http://www.delphij.net/errata-20080430.xml Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgZ9tIACgkQi+vbBBjt66AHvgCdEVoZPONbOw15G1dpN2oP2coy JIYAn2l4UlwNFNGUGd9cX+J749+L+FEs =cA5t -----END PGP SIGNATURE----- From stefan.lambrev at moneybookers.com Thu May 1 17:30:50 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Thu May 1 17:30:53 2008 Subject: What does system do after "Uptime: "? In-Reply-To: <4819F6D3.80104@delphij.net> References: <481560AC.90109@delphij.net> <1209376409.59233.14.camel@buffy.york.ac.uk> <4818BF27.2080209@delphij.net> <200804301544.20802.jhb@freebsd.org> <1209660552.68622.53.camel@buffy.york.ac.uk> <4819F6D3.80104@delphij.net> Message-ID: <4819FA26.7050703@moneybookers.com> Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gavin Atkinson wrote: > | FWIW, there have been probably around 10 PRs in in the last few months > | about this behaviour. I'd vote for it as an errata candidate. > > FWIW I have written to re@ indicating some changes I wanted for > RELENG_7_0 as candidates. Could you please let me know if I have missed > something important? > > http://www.delphij.net/errata-20080430.xml Please look at this thread in -net : TCP options order changed in FreeBSD 7,incompatible with some routers I think problem mention there should go in errata as it's quite serious. src/sys/netinet/tcp_output.c Revision 1.141.2.4 (not sure that this is the fix ..) P.S. When can we expect 7.0p1 ? :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From delphij at delphij.net Thu May 1 18:02:22 2008 From: delphij at delphij.net (Xin LI) Date: Thu May 1 18:02:25 2008 Subject: What does system do after "Uptime: "? In-Reply-To: <4819FA26.7050703@moneybookers.com> References: <481560AC.90109@delphij.net> <1209376409.59233.14.camel@buffy.york.ac.uk> <4818BF27.2080209@delphij.net> <200804301544.20802.jhb@freebsd.org> <1209660552.68622.53.camel@buffy.york.ac.uk> <4819F6D3.80104@delphij.net> <4819FA26.7050703@moneybookers.com> Message-ID: <481A059E.5020503@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Lambrev wrote: | Xin LI wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Gavin Atkinson wrote: |> | FWIW, there have been probably around 10 PRs in in the last few months |> | about this behaviour. I'd vote for it as an errata candidate. |> |> FWIW I have written to re@ indicating some changes I wanted for |> RELENG_7_0 as candidates. Could you please let me know if I have missed |> something important? |> |> http://www.delphij.net/errata-20080430.xml | | Please look at this thread in -net : | TCP options order changed in FreeBSD 7,incompatible with some routers | I think problem mention there should go in errata as it's quite serious. | | src/sys/netinet/tcp_output.c Revision 1.141.2.4 (not sure that this is | the fix ..) I see, I will take a look at it. IIRC at least two files were involved. | P.S. When can we expect 7.0p1 ? :) Actually there is already 7.0-R-p1 for the SSH vulnerability, note that this is not a kernel vulnerability so if you use binary update then the version number would not show up :) [lixin@builder] ~> uname -sr FreeBSD 7.0-RELEASE-p1 Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgaBZ4ACgkQi+vbBBjt66BWAQCeP/j4VGsHL458f5/LG2pXoPju 0qUAoJdJBCp5jIw8pGxpp2B4I24uVJ4E =JWjo -----END PGP SIGNATURE----- From delphij at delphij.net Thu May 1 18:14:52 2008 From: delphij at delphij.net (Xin LI) Date: Thu May 1 18:14:55 2008 Subject: What does system do after "Uptime: "? In-Reply-To: <481A059E.5020503@delphij.net> References: <481560AC.90109@delphij.net> <1209376409.59233.14.camel@buffy.york.ac.uk> <4818BF27.2080209@delphij.net> <200804301544.20802.jhb@freebsd.org> <1209660552.68622.53.camel@buffy.york.ac.uk> <4819F6D3.80104@delphij.net> <4819FA26.7050703@moneybookers.com> <481A059E.5020503@delphij.net> Message-ID: <481A088E.3020808@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So I think it was 1.141.2.4 of sys/netinet/tcp_output.c. The change on tcp_var.h was reverted after this as it is no longer necessary. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgaCI4ACgkQi+vbBBjt66APqgCeJxDEzOoXeX0WNVpBywbiCuh7 bOoAoIfJHdrqKnIkWEWR954XOXu0fj5s =ZJ/C -----END PGP SIGNATURE----- From arno at heho.snv.jussieu.fr Thu May 1 18:55:13 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Thu May 1 18:55:17 2008 Subject: nfs-server silent data corruption In-Reply-To: References: <20080421094718.GY25623@hub.freebsd.org> <200804211537.m3LFbaZA086977@lava.sentex.ca> <200804221501.m3MF1guW092221@lava.sentex.ca> <200804221741.m3MHfYjO092795@lava.sentex.ca> <200804221807.m3MI73bN092981@lava.sentex.ca> <200804222155.m3MLtoKt093783@lava.sentex.ca> Message-ID: Hello, > [ .. stuff deleted .. ] > > I have recompiled the kernel with ULE, and it seems fine as well. I > > ran 160 iterations of a 300MB file and there was no corruption. Same > > process - copy a junk random file over nfs mount, unmount the nfs > > mount, remount it copy it back, compare the files. > > > Let me summarise my investigations till now : > [ .. more stuff deleted .. ] > - it does *not* seem to depend on : > > - the interface : I could produce it using nfe0, nfe1 and > re0 using some netgear pci-card > > - the distribution of the 4Gig memory : installing 4G at > CPU1 or 1G at CPU1 and 2G at CPU2 produces same results > (NB, all memory passed memtest.iso in both situtations > for complete run) > > - the frequency control method : easier to produce with > cpufreq/powerd, but finally I can reproduce the cooruption > as well using acpi_ppc > > - the nfs-client and options (not exhaustively tested, but different > test include i386-releng6, amd64-releng6 and linux, and quite > a set of different try and see mounf_nfs options > > I am testing right now with a fixed frequency of 1Ghz. I cannot reproduce it at fixed cpu-frequency with cpufreq loaded (I ran my test for three days without prob, normally a couple of hours was enough). But I looked again at the corrupted copies : # for i in raid5/xps/SAVE/1 raid5/pxe/SAVE/1 raid5/pxe/SAVE/2 raid5/pxe/SAVE/3 raid5/blockhead/SAVE/1 scsi/pxe/SAVE/1 scsi/blockhead/SAVE/1 scsi/blockhead/SAVE/2 scsi/blockhead/SAVE/3 scsi/blockhead/SAVE/4; do ls -l $i/BIG; cmp -x $i/BIG $i/BIG2; echo; done -rw-r--r-- 1 root wheel 144703488 Apr 26 16:06 raid5/xps/SAVE/1/BIG 004fd908 18 00 02c9e6c8 11 00 034ab6c8 90 00 037e4648 09 00 039e85c8 91 01 04484408 00 09 06115cc8 00 81 06e5d148 01 91 07016048 18 00 074307c8 08 19 07aa45c8 29 20 080bfb88 00 11 -rw-r--r-- 1 root wheel 144703488 Apr 20 14:07 raid5/pxe/SAVE/1/BIG 03869a48 09 00 -rw-r--r-- 1 root wheel 144703488 Apr 20 14:47 raid5/pxe/SAVE/2/BIG 05209d88 09 00 -rw-r--r-- 1 root wheel 39845888 Apr 20 15:17 raid5/pxe/SAVE/3/BIG 01777148 09 00 -rw-r--r-- 1 root wheel 144703488 Apr 20 14:54 raid5/blockhead/SAVE/1/BIG 00f10f88 09 00 -rw-r--r-- 1 root wheel 39845888 Apr 20 16:08 scsi/pxe/SAVE/1/BIG 01f4c4c8 11 00 -rw-r--r-- 1 root wheel 144703488 Apr 20 15:38 scsi/blockhead/SAVE/1/BIG 06c3d6c8 11 00 -rw-r--r-- 1 root wheel 144703488 Apr 20 16:11 scsi/blockhead/SAVE/2/BIG 0725ca48 18 00 -rw-r--r-- 1 root wheel 144703488 Apr 20 17:32 scsi/blockhead/SAVE/3/BIG 01608008 09 00 -rw-r--r-- 1 root wheel 144703488 Apr 23 19:26 scsi/blockhead/SAVE/4/BIG 00f3b888 18 00 The output from raid5/xps/SAVE/1/BIG is after installing at a lab with without doubt more sophisticated switches than I use and the first I was able to produce with more that just one byte corrupted, but still with the same pattern : it looks like the position always is 2^3 * 'somethin without power of two' (e.g. factor(hex2dec('00f10f88')) = 2 2 2 809 2441 factor(hex2dec('01f4c4c8')) = 2 2 2 317 12941 ) and the corruption is one out of the following half-byte transitions : 1 -> 0 8 -> 0 9 -> 0 0 -> 1 0 -> 8 0 -> 9 8 -> 9 Maybe this gives a hint to someone ... Best, Arno From sclark46 at earthlink.net Thu May 1 19:15:58 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu May 1 19:16:03 2008 Subject: reboot after panic In-Reply-To: References: <4819BB3A.6000407@earthlink.net> Message-ID: <481A16E7.8040709@earthlink.net> Matthew X. Economou wrote: > Steve, > > I recall having to set dumpdev in /etc/rc.conf before I could get > FreeBSD to reboot automatically after a panic. I have dumpdev=AUTO > set on all of my headless servers. If you are feeling especially > brave, you can also set fsck_y_enable=YES and background_fsck=NO. > > Good luck! ;) > Hmmm... I have that set. It only seems to not reboot on one system I have. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From cliftonr at lava.net Thu May 1 21:02:36 2008 From: cliftonr at lava.net (Clifton Royston) Date: Thu May 1 21:02:39 2008 Subject: reboot after panic In-Reply-To: <481A16E7.8040709@earthlink.net> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> Message-ID: <20080501210233.GA15528@lava.net> On Thu, May 01, 2008 at 03:15:51PM -0400, Stephen Clark wrote: > Matthew X. Economou wrote: > >Steve, > > > >I recall having to set dumpdev in /etc/rc.conf before I could get > >FreeBSD to reboot automatically after a panic. I have dumpdev=AUTO > >set on all of my headless servers. If you are feeling especially > >brave, you can also set fsck_y_enable=YES and background_fsck=NO. > > > >Good luck! ;) > > > Hmmm... I have that set. It only seems to not reboot on one > system I have. FWIW, I've had problems with 6.2 not rebooting reliably on several SMP P4 Xeon systems; the problem seems to be that sometimes while dumping it either freezes completely or double-faults and hangs at that point until physically reset. This problem appeared simultaneously on several SMP servers when they were upgraded to 6.2, after they had run reliably for years on FreeBSD 4.x. Adding insult to injury, when it does dump successfully, I don't reliably get an image saved in /var/crash. (And if I did, it doesn't appear that it would do me any good as nobody is interested any longer in problems with 6.2.) Thankfully, via a combination of adding RAM and tuning kernel parameters I eventually got them to where they'll reliably stay up for reasonably long stretches, certainly more than the 20 days uptime I was getting when I first upgraded them. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From lambert at lambertfam.org Thu May 1 21:19:48 2008 From: lambert at lambertfam.org (Scott Lambert) Date: Thu May 1 21:19:53 2008 Subject: restore issues "Header with wrong dumpdate." and "getfile: lost data" Message-ID: <20080501205214.GA14922@sysmon.tcworks.net> We have upgraded our AMANDA server from FreeBSD 4.x to FreeBSD 7.0-RELEASE. We still have several 4.x boxes and are having issues when we try to restore files on the AMANDA server for any of the 4.x servers. We see the following errors running amrecover: Header with wrong dumpdate. Header with wrong dumpdate. getfile: lost data abort? [yn] n Header with wrong dumpdate. Header with wrong dumpdate. Header with wrong dumpdate. Header with wrong dumpdate. getfile: lost data abort? [yn] n Header with wrong dumpdate. Header with wrong dumpdate. Header with wrong dumpdate. Header with wrong dumpdate. Header with wrong dumpdate. Header with wrong dumpdate. Header with wrong dumpdate. Header with wrong dumpdate. getfile: lost data abort? [yn] y So long as I keep saying no to the amanda abort prompt, the files are successfully restored. I've seen http://www.freebsd.org/cgi/query-pr.cgi?pr=120881 which seems to apply to the "getfile: lost data" lines. There is also http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/118087 which seems to apply to "Header with wrong dumpdate." 118087 seems to have been applied to CVS in rev 1.51 of tape.c by mckusick a couple of weeks ago. I don't think it has been merged to 7-STABLE yet. 120881 seems not to have been applied to CVS just yet. Does anyone have a guess as to when restore will be fixed in -STABLE? -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From gaijin.k at gmail.com Thu May 1 23:18:10 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Thu May 1 23:18:15 2008 Subject: Packet-corruption with re(4) In-Reply-To: <20080429225855.c0bd48fe.torfinn.ingolfsen@broadpark.no> References: <20080429120834.GB44737@eos.sc1.parodius.com> <20080429225855.c0bd48fe.torfinn.ingolfsen@broadpark.no> Message-ID: <1209683837.3651.14.camel@RabbitsDen> On Tue, 2008-04-29 at 22:58 +0200, Torfinn Ingolfsen wrote: > On Tue, 29 Apr 2008 05:08:34 -0700 > Jeremy Chadwick wrote: > > > I'd recommend staying away from Realtek NICs. Pick up an Intel > > Pro/1000 GT or PT. Realtek has a well-known history of issues. > > I hear that story very often, so often that I almost think it's a fairy > tale. :-) > Most of the times the "RealTek NIC" story is told, it isn't backed up > with any references to evidence. Draw your own conclusions. Well, my latest encounter with "Netgear GA311 Rev. A1 (RTL8169S-32) Gigabit Ethernet" falls neatly into the "fairy tale" category -- it has jittery bit in the chip ID register and will advertise itself as 8129 or 8169 depending on the phase of the moon. While it is not fair to judge the whole product line based on the single specimen, it took me some time to figure it out, and, on top of that, I have wasted time of some people, valuable to the FreeBSD project, who were kind enough to review submitted PR and close it. I am not planning on buying more of these to get representative statistics, though ;) The card in question was purchased as the replacement for the 'fxp', which was sitting in that system for a long while, so I think I am in my right to blame the card and not the system. -- Alexandre "Sunny" Kovalenko (????????? ?????????) From kamikaze at bsdforen.de Fri May 2 09:03:20 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Fri May 2 09:03:25 2008 Subject: ubsa speed limit Message-ID: <481AD8D1.7090004@bsdforen.de> When I download a single file it seems that the download speed is limited to 32k (raw data as shown by netstat). Under Windows I can reach values around 60k. I can achieve more throughput (though not as much as under Windows), when downloading several files at once. From mcdouga9 at egr.msu.edu Fri May 2 12:10:46 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Fri May 2 12:10:50 2008 Subject: ubsa speed limit In-Reply-To: <481AD8D1.7090004@bsdforen.de> References: <481AD8D1.7090004@bsdforen.de> Message-ID: <481AF29C.9080706@egr.msu.edu> Dominic Fandrey wrote: > When I download a single file it seems that the download speed is > limited to 32k (raw data as shown by netstat). Under Windows I can > reach values around 60k. I can achieve more throughput (though not as > much as under Windows), when downloading several files at once. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Try this hack, its using concepts I gathered from people patching the Linux driver, basically increasing the block size of transfers. Edit ubsa.c and recompile/reload the ubsa driver. Its located around line 362. Basically replace UGETW(ed->wMaxPacketSize); or UGETW(ed->wMaxPacketSize); with 2048. I think the default is 512 and you can play with different values to evaluate its effect on speed. I realized a large performance boost from 2048, I think at least 80k/sec transfer rate. } else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN && UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) { ucom->sc_bulkin_no = ed->bEndpointAddress; - ucom->sc_ibufsize = UGETW(ed->wMaxPacketSize); + ucom->sc_ibufsize = 2048; + // ucom->sc_ibufsize = UGETW(ed->wMaxPacketSize); } else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_OUT && UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) { ucom->sc_bulkout_no = ed->bEndpointAddress; - ucom->sc_obufsize = UGETW(ed->wMaxPacketSize); + ucom->sc_obufsize = 2048; + // ucom->sc_obufsize = UGETW(ed->wMaxPacketSize); } } From kamikaze at bsdforen.de Fri May 2 12:29:09 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Fri May 2 12:29:13 2008 Subject: ubsa speed limit In-Reply-To: <481AF29C.9080706@egr.msu.edu> References: <481AD8D1.7090004@bsdforen.de> <481AF29C.9080706@egr.msu.edu> Message-ID: <481B0904.40403@bsdforen.de> Adam McDougall wrote: > Dominic Fandrey wrote: >> When I download a single file it seems that the download speed is >> limited to 32k (raw data as shown by netstat). Under Windows I can >> reach values around 60k. I can achieve more throughput (though not as >> much as under Windows), when downloading several files at once. >> > Try this hack, its using concepts I gathered from people patching the > Linux driver, basically increasing the block size of transfers. > > Edit ubsa.c and recompile/reload the ubsa driver. Its located around > line 362. Basically replace UGETW(ed->wMaxPacketSize); or > UGETW(ed->wMaxPacketSize); with 2048. I think the default is 512 and > you can play with different values to evaluate its effect on speed. I > realized a large performance boost from 2048, I think at least 80k/sec > transfer rate. > > } else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN && > UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) { > ucom->sc_bulkin_no = ed->bEndpointAddress; > - ucom->sc_ibufsize = UGETW(ed->wMaxPacketSize); > + ucom->sc_ibufsize = 2048; > + // ucom->sc_ibufsize = UGETW(ed->wMaxPacketSize); > } else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_OUT && > UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) { > ucom->sc_bulkout_no = ed->bEndpointAddress; > - ucom->sc_obufsize = UGETW(ed->wMaxPacketSize); > + ucom->sc_obufsize = 2048; > + // ucom->sc_obufsize = UGETW(ed->wMaxPacketSize); > } > } Thanks a lot. This improves the situation a lot. However I found the improvement somewhat unsteady. I think that a 2k or 4k buffer is still not sufficient if the answering time is high. A 16k buffer leads to a much more steady data stream for me. I think the best solution would be dynamic buffer allocation similar to what is done on layer 4. From sclark46 at earthlink.net Fri May 2 13:40:24 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Fri May 2 13:40:28 2008 Subject: reboot after panic In-Reply-To: <20080501210233.GA15528@lava.net> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> Message-ID: <481B19C4.1040806@earthlink.net> Clifton Royston wrote: > On Thu, May 01, 2008 at 03:15:51PM -0400, Stephen Clark wrote: >> Matthew X. Economou wrote: >>> Steve, >>> >>> I recall having to set dumpdev in /etc/rc.conf before I could get >>> FreeBSD to reboot automatically after a panic. I have dumpdev=AUTO >>> set on all of my headless servers. If you are feeling especially >>> brave, you can also set fsck_y_enable=YES and background_fsck=NO. >>> >>> Good luck! ;) >>> >> Hmmm... I have that set. It only seems to not reboot on one >> system I have. > > FWIW, I've had problems with 6.2 not rebooting reliably on several > SMP P4 Xeon systems; the problem seems to be that sometimes while > dumping it either freezes completely or double-faults and hangs at that > point until physically reset. > > This problem appeared simultaneously on several SMP servers when they > were upgraded to 6.2, after they had run reliably for years on FreeBSD > 4.x. Adding insult to injury, when it does dump successfully, I don't > reliably get an image saved in /var/crash. (And if I did, it doesn't > appear that it would do me any good as nobody is interested any longer > in problems with 6.2.) > > Thankfully, via a combination of adding RAM and tuning kernel > parameters I eventually got them to where they'll reliably stay up for > reasonably long stretches, certainly more than the 20 days uptime I was > getting when I first upgraded them. > -- Clifton > Thank Clifton, Mine is a nvidia 6300 mb with a dual core amd processor. I am causing the panic while trying to develope a DD for a EVDO usb modem - so it is not a great problem - I was just surprised it wasn't rebooting. This is a 6.1 system. Yes it is sort of discouraging that it is hard to get answers when you aren't running the latest and greatest kernel. In our case we have over 500 units in the field running a mix of 4.9 and 6.1 and it is not feasible to continually upgrade them, especially since there is no documented way to reliably upgrade a remote installation. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From dwmalone at maths.tcd.ie Fri May 2 14:33:08 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Fri May 2 14:33:11 2008 Subject: restore issues "Header with wrong dumpdate." and "getfile: lost data" In-Reply-To: <20080501205214.GA14922@sysmon.tcworks.net> References: <20080501205214.GA14922@sysmon.tcworks.net> Message-ID: <20080502143303.GA27742@walton.maths.tcd.ie> On Thu, May 01, 2008 at 03:52:14PM -0500, Scott Lambert wrote: > I've seen http://www.freebsd.org/cgi/query-pr.cgi?pr=120881 which > seems to apply to the "getfile: lost data" lines. There is also > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/118087 which seems to > apply to "Header with wrong dumpdate." I believe these are basically harmless. I don't know if Kirk plans to merge the fix, but I can do it if he wants. > 120881 seems not to have been applied to CVS just yet. Ah - I'd missed 120881. This seems to relate to a more recent change of Kirk's. Kirk - do you want to look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=120881 or would you prefer if I had a look at it? David. From stefan.lambrev at moneybookers.com Fri May 2 17:19:11 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Fri May 2 17:19:14 2008 Subject: mpd5.1 and HUAWEI 3g card (ubsa) Message-ID: <481B4D08.7030507@moneybookers.com> Greetings, I'm trying to get my 3g card working under FreeBSD7. So far using usb4bsd the card is recognized and do not panic the kernel when removed. Unfortunately I'm stuck with mpd configuration. Here is my config: startup: # configure mpd users set user user pass admin # configure the console set console self 127.0.0.1 5005 set console open # configure the web server set web self 127.0.0.1 5006 set web open set web disable auth default: load client1 client1: create bundle template B1 create link static L1 modem set modem device /dev/cuaU0 set modem speed 115200 set modem script DialPeer set modem idle-script AnswerCall set modem var $DialPrefix "DT" set modem var $Telephone "*99***1#" set link no pap chap eap set link accept pap set auth authname "MyLogin" set auth password "MyPassword" set link max-redial 1 set link action bundle B1 open To be able to dial I first have to sent the PIN code, which I do manually by connection to /dev/cuaU0 and typing AT+CPIN=XXXX I know this is successful because the blinking led changes it's color from green to blue :) Next when I start mpd it seems to connect, but immediately drops the connection. Here is the log: May 2 20:04:10 laptop mpd: Multi-link PPP daemon for FreeBSD May 2 20:04:10 laptop mpd: May 2 20:04:10 laptop mpd: process 2285 started, version 5.1 (root@laptop.laptops.org 13:31 2-May-2008) May 2 20:04:10 laptop mpd: CONSOLE: listening on 127.0.0.1 5005 May 2 20:04:10 laptop mpd: web: listening on 0.0.0.0 5006 May 2 20:04:10 laptop mpd: [L1] Link: OPEN event May 2 20:04:10 laptop mpd: [L1] LCP: Open event May 2 20:04:10 laptop mpd: [L1] LCP: state change Initial --> Starting May 2 20:04:10 laptop mpd: [L1] LCP: LayerStart May 2 20:04:10 laptop kernel: ubsa_cfg_request: device request failed, err=USBD_ERR_STALLED (ignored) May 2 20:04:10 laptop last message repeated 7 times May 2 20:04:10 laptop mpd: [L1] chat: Detected Hayes compatible modem. May 2 20:04:10 laptop mpd: [L1] chat: Dialing server at *99***1#... May 2 20:04:10 laptop mpd: [L1] chat: Connected at an unknown speed. May 2 20:04:10 laptop mpd: [L1] chat: Initiating auto-login... May 2 20:04:15 laptop mpd: [L1] chat: Auto-login timeout. May 2 20:04:15 laptop mpd: [L1] MODEM: chat script succeeded May 2 20:04:15 laptop mpd: [L1] Link: UP event May 2 20:04:15 laptop mpd: [L1] Link: origination is local May 2 20:04:15 laptop mpd: [L1] LCP: Up event May 2 20:04:15 laptop mpd: [L1] LCP: state change Starting --> Req-Sent May 2 20:04:15 laptop mpd: [L1] LCP: SendConfigReq #1 May 2 20:04:15 laptop mpd: [L1] ACFCOMP May 2 20:04:15 laptop mpd: [L1] PROTOCOMP May 2 20:04:15 laptop mpd: [L1] ACCMAP 0x000a0000 May 2 20:04:15 laptop mpd: [L1] MRU 1500 May 2 20:04:15 laptop mpd: [L1] MAGICNUM 597dcb60 May 2 20:04:15 laptop mpd: [L1] LCP: rec'd Configure Request #0 (Req-Sent) May 2 20:04:15 laptop mpd: [L1] ACCMAP 0x00000000 May 2 20:04:15 laptop mpd: [L1] AUTHPROTO CHAP MD5 May 2 20:04:15 laptop mpd: [L1] MAGICNUM 00b4d370 May 2 20:04:15 laptop mpd: [L1] PROTOCOMP May 2 20:04:15 laptop mpd: [L1] ACFCOMP May 2 20:04:15 laptop mpd: [L1] LCP: SendConfigNak #0 May 2 20:04:15 laptop mpd: [L1] AUTHPROTO PAP May 2 20:04:15 laptop mpd: [L1] LCP: rec'd Configure Ack #1 (Req-Sent) May 2 20:04:15 laptop mpd: [L1] ACFCOMP May 2 20:04:15 laptop mpd: [L1] PROTOCOMP May 2 20:04:15 laptop mpd: [L1] ACCMAP 0x000a0000 May 2 20:04:15 laptop mpd: [L1] MRU 1500 May 2 20:04:15 laptop mpd: [L1] MAGICNUM 597dcb60 May 2 20:04:15 laptop mpd: [L1] LCP: state change Req-Sent --> Ack-Rcvd May 2 20:04:15 laptop mpd: [L1] LCP: rec'd Configure Request #1 (Ack-Rcvd) May 2 20:04:15 laptop mpd: [L1] ACCMAP 0x00000000 May 2 20:04:15 laptop mpd: [L1] AUTHPROTO PAP May 2 20:04:15 laptop mpd: [L1] MAGICNUM 00b4d370 May 2 20:04:15 laptop mpd: [L1] PROTOCOMP May 2 20:04:15 laptop mpd: [L1] ACFCOMP May 2 20:04:15 laptop mpd: [L1] LCP: SendConfigAck #1 May 2 20:04:15 laptop mpd: [L1] ACCMAP 0x00000000 May 2 20:04:15 laptop mpd: [L1] AUTHPROTO PAP May 2 20:04:15 laptop mpd: [L1] MAGICNUM 00b4d370 May 2 20:04:15 laptop mpd: [L1] PROTOCOMP May 2 20:04:15 laptop mpd: [L1] ACFCOMP May 2 20:04:15 laptop mpd: [L1] LCP: state change Ack-Rcvd --> Opened May 2 20:04:15 laptop mpd: [L1] LCP: auth: peer wants PAP, I want nothing May 2 20:04:15 laptop mpd: [L1] PAP: using authname "MyLogin" May 2 20:04:15 laptop mpd: [L1] PAP: sending REQUEST #1 len: 23 May 2 20:04:15 laptop mpd: [L1] LCP: LayerUp May 2 20:04:15 laptop mpd: [L1] LCP: rec'd Discard Request #2 (Opened) May 2 20:04:15 laptop mpd: [L1] PAP: rec'd ACK #1 len: 5 May 2 20:04:15 laptop mpd: [L1] LCP: authorization successful May 2 20:04:15 laptop mpd: [L1] Link: Matched action 'bundle "B1" ""' May 2 20:04:15 laptop mpd: [L1] Creating new bundle using template "B1". May 2 20:04:15 laptop mpd: [B1-1] Bundle: Interface ng0 created May 2 20:04:15 laptop mpd: [L1] Link: Join bundle "B1-1" May 2 20:04:15 laptop mpd: [B1-1] Bundle: Status update: up 1 link, total bandwidth 28800 bps May 2 20:04:15 laptop mpd: [B1-1] IPCP: Open event May 2 20:04:15 laptop mpd: [B1-1] IPCP: state change Initial --> Starting May 2 20:04:15 laptop mpd: [B1-1] IPCP: LayerStart May 2 20:04:15 laptop mpd: [B1-1] IPCP: Up event May 2 20:04:15 laptop mpd: [B1-1] IPCP: state change Starting --> Req-Sent May 2 20:04:15 laptop mpd: [B1-1] IPCP: SendConfigReq #1 May 2 20:04:15 laptop mpd: [B1-1] IPADDR 10.1.1.2 May 2 20:04:15 laptop mpd: [B1-1] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid May 2 20:04:16 laptop mpd: [L1] MODEM: carrier detect (CD) signal lost May 2 20:04:16 laptop mpd: [L1] Link: DOWN event May 2 20:04:16 laptop mpd: [L1] LCP: Down event Btw why I see 10.1.1.2 - this is the IP of my LAN card ? Another issues is that after the first attempt to dial the modem freezes for few seconds and I see lot of those messages: May 2 20:04:10 laptop kernel: ubsa_cfg_request: device request failed, err=USBD_ERR_STALLED (ignored) but this should go to -usb probably :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From tinderbox at freebsd.org Sat May 3 03:17:53 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 3 03:17:58 2008 Subject: [releng_7 tinderbox] failure on sparc64/sparc64 Message-ID: <20080503031752.74FA01B5078@freebsd-stable.sentex.ca> TB --- 2008-05-03 01:52:12 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-05-03 01:52:12 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-05-03 01:52:12 - cleaning the object tree TB --- 2008-05-03 01:52:28 - cvsupping the source tree TB --- 2008-05-03 01:52:28 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2008-05-03 01:52:36 - building world (CFLAGS=-O2 -pipe) TB --- 2008-05-03 01:52:36 - cd /src TB --- 2008-05-03 01:52:36 - /usr/bin/make -B buildworld >>> World build started on Sat May 3 01:52:38 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 3 02:51:59 UTC 2008 TB --- 2008-05-03 02:51:59 - generating LINT kernel config TB --- 2008-05-03 02:51:59 - cd /src/sys/sparc64/conf TB --- 2008-05-03 02:51:59 - /usr/bin/make -B LINT TB --- 2008-05-03 02:52:00 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 02:52:00 - cd /src TB --- 2008-05-03 02:52:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 3 02:52:00 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat May 3 03:11:29 UTC 2008 TB --- 2008-05-03 03:11:29 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 03:11:29 - cd /src TB --- 2008-05-03 03:11:29 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 3 03:11:29 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh GENERIC cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel.debug e1000_api.o(.text+0x1288): In function `e1000_setup_init_funcs': /src/sys/dev/em/e1000_api.c:352: undefined reference to `e1000_init_function_pointers_82575' *** Error code 1 Stop in /obj/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-05-03 03:17:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-05-03 03:17:52 - ERROR: failed to build GENERIC kernel TB --- 2008-05-03 03:17:52 - tinderbox aborted TB --- 4521.23 user 412.47 system 5140.14 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From jfvogel at gmail.com Sat May 3 07:41:29 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sat May 3 07:41:33 2008 Subject: MFC of em/igb drivers Message-ID: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> I got the new drivers in Friday afternoon for those that don't see CVS messages. The igb driver is for 82575 and 82576 adapters, it has multiqueue support and MSIX, there will be more server type enhancements in that driver as I get the time. The em driver now will be client oriented, the latest hardware support however is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, that actually also has MSIX. This first released support for it will use 3 interrupt vectors, one for TX, one for RX, and Link. The hardware actually supports 5 vectors, so I am planning to add support for another RX and TX queue as my schedule allows. Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver provides init and an ioctl interface to use that facility, I hope we see software support follow on soon. This is an early announcement, I am not sure on exact dates for availability but they should be soon. As ever, issues and bugs should be sent to me. Cheers everyone! Jack From eugen at kuzbass.ru Sat May 3 08:33:36 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sat May 3 08:33:42 2008 Subject: MFC of em/igb drivers In-Reply-To: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> Message-ID: <20080503083332.GB2866@svzserv.kemerovo.su> On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > I got the new drivers in Friday afternoon for those that don't see CVS > messages. [skip] > As ever, issues and bugs should be sent to me. Cheers everyone! It seems the MFC to RELENG_7 has broken build of static kernels having device em but not having device igb: linking kernel.debug e1000_api.o(.text+0xcc6): In function `e1000_setup_init_funcs': /usr/local/obj/src/sys/dev/em/e1000_api.c:352: undefined reference to `e1000_init_function_pointers_82575' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error Eugene Grosbein From tinderbox at freebsd.org Sat May 3 10:27:31 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 3 10:27:36 2008 Subject: [releng_7 tinderbox] failure on amd64/amd64 Message-ID: <20080503102730.0990C1B5078@freebsd-stable.sentex.ca> TB --- 2008-05-03 08:26:43 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-05-03 08:26:43 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2008-05-03 08:26:43 - cleaning the object tree TB --- 2008-05-03 08:27:19 - cvsupping the source tree TB --- 2008-05-03 08:27:19 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2008-05-03 08:27:27 - building world (CFLAGS=-O2 -pipe) TB --- 2008-05-03 08:27:27 - cd /src TB --- 2008-05-03 08:27:27 - /usr/bin/make -B buildworld >>> World build started on Sat May 3 08:27:29 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat May 3 09:57:02 UTC 2008 TB --- 2008-05-03 09:57:03 - generating LINT kernel config TB --- 2008-05-03 09:57:03 - cd /src/sys/amd64/conf TB --- 2008-05-03 09:57:03 - /usr/bin/make -B LINT TB --- 2008-05-03 09:57:03 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 09:57:03 - cd /src TB --- 2008-05-03 09:57:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 3 09:57:03 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat May 3 10:18:58 UTC 2008 TB --- 2008-05-03 10:18:58 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 10:18:58 - cd /src TB --- 2008-05-03 10:18:58 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 3 10:18:58 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh GENERIC cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/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 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror vers.c linking kernel.debug e1000_api.o(.text+0xabb): In function `e1000_setup_init_funcs': /src/sys/dev/em/e1000_api.c:352: undefined reference to `e1000_init_function_pointers_82575' *** Error code 1 Stop in /obj/amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-05-03 10:27:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-05-03 10:27:29 - ERROR: failed to build GENERIC kernel TB --- 2008-05-03 10:27:29 - tinderbox aborted TB --- 6060.49 user 618.46 system 7246.26 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full From dfr at rabson.org Sat May 3 10:42:16 2008 From: dfr at rabson.org (Doug Rabson) Date: Sat May 3 10:42:19 2008 Subject: samba build failure on 6-STABLE In-Reply-To: <4819D621.9090901@jellydonut.org> References: <20080501132724.GD840@core.byshenk.net> <4819D621.9090901@jellydonut.org> Message-ID: <4FA0DF7D-EC80-4B2F-B7E5-86442BA23DA3@rabson.org> On 1 May 2008, at 15:39, Michael Proto wrote: > > Greg Byshenk wrote: >> I'm posting this to freebsd-stable even though it is a problem with >> a port, >> because the port itself has not changed, but a rebuild fails (on a >> system >> and with a configuration that worked before my most recent system >> updates). >> >> Basically my problem is that the current Samba3 (samba-3.0.28,1) >> won't build >> on a recent 6-STABLE system (I noticed it with sources csup'd 24 >> April, and >> it continues with sources csup'd today, 1 May). The strange thing >> is that >> this is a version of samba that has previously built successfully, >> on the >> machine and with the configuration that is now failing. (I was >> attempting >> to rebuild because I saw some strange library errors.) This at least >> suggests to me that the problem is _not_ due to something changing >> with Samba, >> but to some other change that is being reflected in the Samba build. >> >> >> The system in question is built from sources csup'd today (1 May >> 2008), with >> all installed ports current as of today. The same Samba did build >> successfully >> with a source and ports tree csup'd on 7 March 2008. >> >> As a test to see if there is some problem with the ports >> dependencies, I've >> tried a 'portupgrade -fR samba'; all of the dependencies built >> fine, but then >> I got the same error when attempting to build Samba itself. It is not >> definitive, but this suggests to me that this is not a ports >> problem (per se), >> but a kernel/world problem. >> >> This latter is highlighted by the fact that Samba builds without >> error on a >> system with sources csup'd on 17 April. That is, if I take the >> exact same >> system on which the build fails, revert my world/kernel to a build >> from >> 17 April (leaving everything else exactly the same), then the error >> disappears and Samba builds successfully. >> >> >> The actual error is below. Any ideas are welcome. I have a machine >> that I can >> play with if someone would like me to try anything. >> >> -greg >> >> >> Compiling smbd/oplock_linux.c >> smbd/oplock_linux.c: In function `signal_handler': >> smbd/oplock_linux.c:73: error: structure has no member named `si_fd' >> The following command failed: >> cc -I. -I/usr/ports/net/samba3/work/samba-3.0.28/source -O2 -fno- >> strict-aliasing -pipe -D_SAMBA_BUILD_=3 -I/usr/local/include -I/ >> usr/ports/net/samba3/work/samba-3.0.28/source/iniparser/src - >> Iinclude -I./include -I. -I. -I./lib/replace -I./lib/talloc -I./ >> tdb/include -I./libaddns -I./librpc -DHAVE_CONFIG_H -I/usr/local/ >> include -DLDAP_DEPRECATED -I/usr/ports/net/samba3/work/ >> samba-3.0.28/source/lib -D_SAMBA_BUILD_=3 -fPIC -DPIC -c smbd/ >> oplock_linux.c -o smbd/oplock_linux.o >> *** Error code 1 >> >> Stop in /usr/ports/net/samba3/work/samba-3.0.28/source. >> *** Error code 1 >> >> Stop in /usr/ports/net/samba3. >> *** Error code 1 >> >> Stop in /usr/ports/net/samba3. >> > > I can confirm this on a 6-STABLE system last SUPed (kernel and world > rebuilt) to 20080428 11:23 EDT. samba-3.0.28,1 built fine on this box > when it was 6.3-RELEASE, and now fails in exactly the same place when > trying to rebuild on 6-STABLE. The attached patch should fix the problem -------------- next part -------------- A non-text attachment was scrubbed... Name: syscall.diff Type: application/octet-stream Size: 3621 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080503/c27c7b6b/syscall.obj -------------- next part -------------- From tinderbox at freebsd.org Sat May 3 10:55:02 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 3 10:55:12 2008 Subject: [releng_7 tinderbox] failure on i386/i386 Message-ID: <20080503105501.1882B1B5078@freebsd-stable.sentex.ca> TB --- 2008-05-03 09:18:12 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-05-03 09:18:12 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-05-03 09:18:12 - cleaning the object tree TB --- 2008-05-03 09:18:36 - cvsupping the source tree TB --- 2008-05-03 09:18:36 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-05-03 09:18:45 - building world (CFLAGS=-O2 -pipe) TB --- 2008-05-03 09:18:45 - cd /src TB --- 2008-05-03 09:18:45 - /usr/bin/make -B buildworld >>> World build started on Sat May 3 09:18:46 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 3 10:21:19 UTC 2008 TB --- 2008-05-03 10:21:19 - generating LINT kernel config TB --- 2008-05-03 10:21:19 - cd /src/sys/i386/conf TB --- 2008-05-03 10:21:19 - /usr/bin/make -B LINT TB --- 2008-05-03 10:21:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 10:21:19 - cd /src TB --- 2008-05-03 10:21:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 3 10:21:19 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat May 3 10:46:09 UTC 2008 TB --- 2008-05-03 10:46:09 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 10:46:09 - cd /src TB --- 2008-05-03 10:46:09 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 3 10:46:10 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh GENERIC cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror vers.c linking kernel.debug e1000_api.o(.text+0xbce): In function `e1000_setup_init_funcs': /src/sys/dev/em/e1000_api.c:352: undefined reference to `e1000_init_function_pointers_82575' *** Error code 1 Stop in /obj/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-05-03 10:55:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-05-03 10:55:00 - ERROR: failed to build GENERIC kernel TB --- 2008-05-03 10:55:00 - tinderbox aborted TB --- 5014.81 user 467.65 system 5808.75 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From kostikbel at gmail.com Sat May 3 11:45:36 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat May 3 11:45:41 2008 Subject: MFC of em/igb drivers In-Reply-To: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> Message-ID: <20080503114529.GD18958@deviant.kiev.zoral.com.ua> On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > I got the new drivers in Friday afternoon for those that don't see CVS > messages. > > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and > MSIX, there will be more server type enhancements in that driver as I get the > time. > > The em driver now will be client oriented, the latest hardware support however > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, > that actually also has MSIX. This first released support for it will > use 3 interrupt > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 > vectors, so I am planning to add support for another RX and TX queue as my > schedule allows. > > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver > provides init and an ioctl interface to use that facility, I hope we > see software > support follow on soon. This is an early announcement, I am not sure on > exact dates for availability but they should be soon. > > As ever, issues and bugs should be sent to me. Cheers everyone! Besides the broken tinderbox, you did not connected the igb module to the module build. Is this intentional ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080503/2850b0c4/attachment.pgp From tinderbox at freebsd.org Sat May 3 11:58:16 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 3 11:58:27 2008 Subject: [releng_7 tinderbox] failure on i386/pc98 Message-ID: <20080503115815.099CB1B5078@freebsd-stable.sentex.ca> TB --- 2008-05-03 10:27:30 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-05-03 10:27:30 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2008-05-03 10:27:30 - cleaning the object tree TB --- 2008-05-03 10:27:45 - cvsupping the source tree TB --- 2008-05-03 10:27:45 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2008-05-03 10:27:52 - building world (CFLAGS=-O2 -pipe) TB --- 2008-05-03 10:27:52 - cd /src TB --- 2008-05-03 10:27:52 - /usr/bin/make -B buildworld >>> World build started on Sat May 3 10:27:53 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 3 11:29:48 UTC 2008 TB --- 2008-05-03 11:29:48 - generating LINT kernel config TB --- 2008-05-03 11:29:48 - cd /src/sys/pc98/conf TB --- 2008-05-03 11:29:48 - /usr/bin/make -B LINT TB --- 2008-05-03 11:29:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 11:29:48 - cd /src TB --- 2008-05-03 11:29:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 3 11:29:48 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat May 3 11:51:22 UTC 2008 TB --- 2008-05-03 11:51:22 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 11:51:22 - cd /src TB --- 2008-05-03 11:51:22 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 3 11:51:23 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh GENERIC cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding vers.c linking kernel.debug e1000_api.o(.text+0xbce): In function `e1000_setup_init_funcs': /src/sys/dev/em/e1000_api.c:352: undefined reference to `e1000_init_function_pointers_82575' *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-05-03 11:58:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-05-03 11:58:14 - ERROR: failed to build GENERIC kernel TB --- 2008-05-03 11:58:14 - tinderbox aborted TB --- 4668.25 user 459.38 system 5444.75 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From tinderbox at freebsd.org Sat May 3 12:55:45 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 3 12:55:53 2008 Subject: [releng_7 tinderbox] failure on ia64/ia64 Message-ID: <20080503125544.72D5C1B5078@freebsd-stable.sentex.ca> TB --- 2008-05-03 10:55:01 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-05-03 10:55:01 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2008-05-03 10:55:01 - cleaning the object tree TB --- 2008-05-03 10:55:19 - cvsupping the source tree TB --- 2008-05-03 10:55:19 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2008-05-03 10:55:25 - building world (CFLAGS=-O2 -pipe) TB --- 2008-05-03 10:55:25 - cd /src TB --- 2008-05-03 10:55:25 - /usr/bin/make -B buildworld >>> World build started on Sat May 3 10:55:26 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 3 12:18:59 UTC 2008 TB --- 2008-05-03 12:18:59 - generating LINT kernel config TB --- 2008-05-03 12:18:59 - cd /src/sys/ia64/conf TB --- 2008-05-03 12:18:59 - /usr/bin/make -B LINT TB --- 2008-05-03 12:18:59 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 12:18:59 - cd /src TB --- 2008-05-03 12:18:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 3 12:18:59 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat May 3 12:46:33 UTC 2008 TB --- 2008-05-03 12:46:33 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 12:46:33 - cd /src TB --- 2008-05-03 12:46:33 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 3 12:46:33 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh GENERIC cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vers.c linking kernel.debug e1000_api.o(.text+0x28a2): In function `e1000_setup_init_funcs': /src/sys/dev/em/e1000_api.c:352: undefined reference to `e1000_init_function_pointers_82575' *** Error code 1 Stop in /obj/ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-05-03 12:55:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-05-03 12:55:44 - ERROR: failed to build GENERIC kernel TB --- 2008-05-03 12:55:44 - tinderbox aborted TB --- 6432.80 user 456.12 system 7242.88 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From tinderbox at freebsd.org Sat May 3 14:21:24 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat May 3 14:21:28 2008 Subject: [releng_7 tinderbox] failure on sparc64/sparc64 Message-ID: <20080503142123.686981B5078@freebsd-stable.sentex.ca> TB --- 2008-05-03 12:55:44 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-05-03 12:55:44 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-05-03 12:55:44 - cleaning the object tree TB --- 2008-05-03 12:55:59 - cvsupping the source tree TB --- 2008-05-03 12:55:59 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2008-05-03 12:56:05 - building world (CFLAGS=-O2 -pipe) TB --- 2008-05-03 12:56:05 - cd /src TB --- 2008-05-03 12:56:05 - /usr/bin/make -B buildworld >>> World build started on Sat May 3 12:56:07 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat May 3 13:55:33 UTC 2008 TB --- 2008-05-03 13:55:33 - generating LINT kernel config TB --- 2008-05-03 13:55:33 - cd /src/sys/sparc64/conf TB --- 2008-05-03 13:55:33 - /usr/bin/make -B LINT TB --- 2008-05-03 13:55:33 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 13:55:33 - cd /src TB --- 2008-05-03 13:55:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 3 13:55:33 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat May 3 14:15:02 UTC 2008 TB --- 2008-05-03 14:15:02 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-05-03 14:15:02 - cd /src TB --- 2008-05-03 14:15:02 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 3 14:15:02 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh GENERIC cc -c -O2 -pipe -fno-strict-aliasing -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel.debug e1000_api.o(.text+0x1288): In function `e1000_setup_init_funcs': /src/sys/dev/em/e1000_api.c:352: undefined reference to `e1000_init_function_pointers_82575' *** Error code 1 Stop in /obj/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-05-03 14:21:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-05-03 14:21:23 - ERROR: failed to build GENERIC kernel TB --- 2008-05-03 14:21:23 - tinderbox aborted TB --- 4519.30 user 411.14 system 5138.83 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From jfvogel at gmail.com Sat May 3 16:39:56 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sat May 3 16:40:01 2008 Subject: MFC of em/igb drivers In-Reply-To: <20080503114529.GD18958@deviant.kiev.zoral.com.ua> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <20080503114529.GD18958@deviant.kiev.zoral.com.ua> Message-ID: <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov wrote: > On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > > > > I got the new drivers in Friday afternoon for those that don't see CVS > > messages. > > > > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and > > MSIX, there will be more server type enhancements in that driver as I get the > > time. > > > > The em driver now will be client oriented, the latest hardware support however > > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, > > that actually also has MSIX. This first released support for it will > > use 3 interrupt > > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 > > vectors, so I am planning to add support for another RX and TX queue as my > > schedule allows. > > > > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver > > provides init and an ioctl interface to use that facility, I hope we > > see software > > support follow on soon. This is an early announcement, I am not sure on > > exact dates for availability but they should be soon. > > > > As ever, issues and bugs should be sent to me. Cheers everyone! > > Besides the broken tinderbox, you did not connected the igb module to > the module build. Is this intentional ? > No, not intentional, both issues are now fixed, sorry, was tired yesterday afternoon :) Jack From freebsd at byshenk.net Sat May 3 17:23:06 2008 From: freebsd at byshenk.net (Greg Byshenk) Date: Sat May 3 17:23:08 2008 Subject: samba build failure on 6-STABLE In-Reply-To: <4FA0DF7D-EC80-4B2F-B7E5-86442BA23DA3@rabson.org> References: <20080501132724.GD840@core.byshenk.net> <4819D621.9090901@jellydonut.org> <4FA0DF7D-EC80-4B2F-B7E5-86442BA23DA3@rabson.org> Message-ID: <20080503172303.GH840@core.byshenk.net> On Sat, May 03, 2008 at 11:42:14AM +0100, Doug Rabson wrote: > On 1 May 2008, at 15:39, Michael Proto wrote: > >Greg Byshenk wrote: > >>[...] Basically my problem is that the current Samba3 (samba-3.0.28,1) > >>won't build on a recent 6-STABLE system (I noticed it with sources > >>csup'd 24 April, and it continues with sources csup'd today, 1 May). > >>The strange thing is that this is a version of samba that has > >>previously built successfully, on the machine and with the > >>configuration that is now failing. (I was attempting > >>to rebuild because I saw some strange library errors.) This at least > >>suggests to me that the problem is _not_ due to something changing > >>with Samba, but to some other change that is being reflected in the > >>Samba build. [...] > >I can confirm this on a 6-STABLE system last SUPed (kernel and world > >rebuilt) to 20080428 11:23 EDT. samba-3.0.28,1 built fine on this box > >when it was 6.3-RELEASE, and now fails in exactly the same place when > >trying to rebuild on 6-STABLE. > The attached patch should fix the problem. It appears that it does. I've applied the patch on a test machine, and Samba now builds successfully. I've also done a reinstall of Samba, and the rebuild version appears to be working properly (though I have not yet done any extensive testing). Thanks, -greg -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From scottl at samsco.org Sat May 3 17:40:06 2008 From: scottl at samsco.org (Scott Long) Date: Sat May 3 17:40:10 2008 Subject: MFC of em/igb drivers In-Reply-To: <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <20080503114529.GD18958@deviant.kiev.zoral.com.ua> <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> Message-ID: <481C9FB1.4060407@samsco.org> Jack Vogel wrote: > On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov wrote: >> On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: >> >> >>> I got the new drivers in Friday afternoon for those that don't see CVS >> > messages. >> > >> > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and >> > MSIX, there will be more server type enhancements in that driver as I get the >> > time. >> > >> > The em driver now will be client oriented, the latest hardware support however >> > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, >> > that actually also has MSIX. This first released support for it will >> > use 3 interrupt >> > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 >> > vectors, so I am planning to add support for another RX and TX queue as my >> > schedule allows. >> > >> > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver >> > provides init and an ioctl interface to use that facility, I hope we >> > see software >> > support follow on soon. This is an early announcement, I am not sure on >> > exact dates for availability but they should be soon. >> > >> > As ever, issues and bugs should be sent to me. Cheers everyone! >> >> Besides the broken tinderbox, you did not connected the igb module to >> the module build. Is this intentional ? >> > > No, not intentional, both issues are now fixed, sorry, was tired yesterday > afternoon :) > Is it still true that support for the 575 moved from em to igb? If so, please put an entry in src/UPDATING about it and ask the re/docs team to make sure it's documented in the next release notes. Scott From dfr at rabson.org Sat May 3 18:58:21 2008 From: dfr at rabson.org (Doug Rabson) Date: Sat May 3 18:58:24 2008 Subject: samba build failure on 6-STABLE In-Reply-To: <20080503172303.GH840@core.byshenk.net> References: <20080501132724.GD840@core.byshenk.net> <4819D621.9090901@jellydonut.org> <4FA0DF7D-EC80-4B2F-B7E5-86442BA23DA3@rabson.org> <20080503172303.GH840@core.byshenk.net> Message-ID: On 3 May 2008, at 18:23, Greg Byshenk wrote: > On Sat, May 03, 2008 at 11:42:14AM +0100, Doug Rabson wrote: >> On 1 May 2008, at 15:39, Michael Proto wrote: >>> Greg Byshenk wrote: > >>>> [...] Basically my problem is that the current Samba3 >>>> (samba-3.0.28,1) >>>> won't build on a recent 6-STABLE system (I noticed it with sources >>>> csup'd 24 April, and it continues with sources csup'd today, 1 >>>> May). >>>> The strange thing is that this is a version of samba that has >>>> previously built successfully, on the machine and with the >>>> configuration that is now failing. (I was attempting >>>> to rebuild because I saw some strange library errors.) This at >>>> least >>>> suggests to me that the problem is _not_ due to something changing >>>> with Samba, but to some other change that is being reflected in the >>>> Samba build. [...] > >>> I can confirm this on a 6-STABLE system last SUPed (kernel and world >>> rebuilt) to 20080428 11:23 EDT. samba-3.0.28,1 built fine on this >>> box >>> when it was 6.3-RELEASE, and now fails in exactly the same place >>> when >>> trying to rebuild on 6-STABLE. > >> The attached patch should fix the problem. > > It appears that it does. > > I've applied the patch on a test machine, and Samba now builds > successfully. > I've also done a reinstall of Samba, and the rebuild version appears > to be > working properly (though I have not yet done any extensive testing). Great, thanks for testing. From mckusick at mckusick.com Sat May 3 20:36:27 2008 From: mckusick at mckusick.com (Kirk McKusick) Date: Sat May 3 20:36:30 2008 Subject: restore issues "Header with wrong dumpdate." and "getfile: lost data" Message-ID: <200805032013.m43KD0qZ027534@chez.mckusick.com> > Date: Fri, 2 May 2008 15:33:03 +0100 > From: David Malone > To: stable@freebsd.org > Cc: mckusick@mckusick.com > Subject: Re: restore issues "Header with wrong dumpdate." and "getfile: lost data" > > On Thu, May 01, 2008 at 03:52:14PM -0500, Scott Lambert wrote: > > I've seen http://www.freebsd.org/cgi/query-pr.cgi?pr=120881 which > > seems to apply to the "getfile: lost data" lines. There is also > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/118087 which seems to > > apply to "Header with wrong dumpdate." > > I believe these are basically harmless. I don't know if Kirk plans > to merge the fix, but I can do it if he wants. I put in the fix for "Header with wrong dumpdate" when I came across it. I never realized that there was an outstanding PR. I am happy to have you MFC the fix and close the PR with an appropriate note that it has been fixed. > > 120881 seems not to have been applied to CVS just yet. > > Ah - I'd missed 120881. This seems to relate to a more recent change > of Kirk's. Kirk - do you want to look at: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=120881 > > or would you prefer if I had a look at it? > > David. I have taken a look at it and can make the following observations on the proposed fix: It seems that the culprit is the following sequence in tape.c if (curblk > 0) panic("getfile: lost data\n"); This was introduced in version 1.48 Version 1.44.2.1 of tape.c shipped with FreeBSD 6.2 has a different handler: if (curblk > 0) (*fill)((char *)buf, (long)((curblk * TP_BSIZE) + size)); which doesn't panic. The 1.48 change added support for restoring extended attributes. This change was never MFC'ed to FreeBSD 6 as it required updates of and . There was concern that too many folks would get compile errors in `make world' and not understand what needed to be done to fix them. So the if (curblk > 0) (*fill)((char *)buf, (long)((curblk * TP_BSIZE) + size)); code in 1.44.2.1 is correct for that version of restore because it does not support extended attributes. I put the panic in for 1.48 because I believed that I would always have skipped over any extra blocks at the end of a file (or extended attribute) and thus there should never have been any left. Obviously, I missed some case :-( So, while the proposed fix does get rid of the panic, my concern is that it will instead put some spurious data at the end of a file or extended attribute. Ideally, I would like to get a copy of the dump (or really just the first part of it needed to reproduce the problem) so that I can analyze it to figure out what I am doing wrong. Kirk McKusick From jfvogel at gmail.com Sat May 3 20:39:32 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sat May 3 20:39:37 2008 Subject: MFC of em/igb drivers In-Reply-To: <481C9FB1.4060407@samsco.org> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <20080503114529.GD18958@deviant.kiev.zoral.com.ua> <2a41acea0805030939ua3022ceq7939aea0754e9e71@mail.gmail.com> <481C9FB1.4060407@samsco.org> Message-ID: <2a41acea0805031339n3ff84f37i3aa815168d14dd94@mail.gmail.com> On Sat, May 3, 2008 at 10:24 AM, Scott Long wrote: > > Jack Vogel wrote: > > > On Sat, May 3, 2008 at 4:45 AM, Kostik Belousov > wrote: > > > > > On Sat, May 03, 2008 at 12:14:32AM -0700, Jack Vogel wrote: > > > > > > > > > > > > > I got the new drivers in Friday afternoon for those that don't see CVS > > > > > > > > messages. > > > > > > > > The igb driver is for 82575 and 82576 adapters, it has multiqueue > support and > > > > MSIX, there will be more server type enhancements in that driver as I > get the > > > > time. > > > > > > > > The em driver now will be client oriented, the latest hardware > support however > > > > is for 82574, Hartwell, which is a really nice low cost PCIE > dual-port adapter, > > > > that actually also has MSIX. This first released support for it will > > > > use 3 interrupt > > > > vectors, one for TX, one for RX, and Link. The hardware actually > supports 5 > > > > vectors, so I am planning to add support for another RX and TX queue > as my > > > > schedule allows. > > > > > > > > Hartwell is also the first adapter that has IEEE 1588 PTP support, > the driver > > > > provides init and an ioctl interface to use that facility, I hope we > > > > see software > > > > support follow on soon. This is an early announcement, I am not sure > on > > > > exact dates for availability but they should be soon. > > > > > > > > As ever, issues and bugs should be sent to me. Cheers everyone! > > > > > > Besides the broken tinderbox, you did not connected the igb module to > > > the module build. Is this intentional ? > > > > > > > > > > No, not intentional, both issues are now fixed, sorry, was tired yesterday > > afternoon :) > > > > > > Is it still true that support for the 575 moved from em to igb? If so, > please put an entry in src/UPDATING about it and ask the re/docs team to > make sure it's documented in the next release notes. > > Scott > Ahhh yes, I forgot about that, will do Scott. Jack From lambert at lambertfam.org Sat May 3 23:49:47 2008 From: lambert at lambertfam.org (Scott Lambert) Date: Sat May 3 23:49:50 2008 Subject: restore issues "Header with wrong dumpdate." and "getfile: lost data" In-Reply-To: <200805032013.m43KD0qZ027534@chez.mckusick.com> References: <200805032013.m43KD0qZ027534@chez.mckusick.com> Message-ID: <20080503234939.GB68354@sysmon.tcworks.net> On Sat, May 03, 2008 at 01:13:00PM -0700, Kirk McKusick wrote: > > Date: Fri, 2 May 2008 15:33:03 +0100 > > From: David Malone > > To: stable@freebsd.org > > Cc: mckusick@mckusick.com > > Subject: Re: restore issues "Header with wrong dumpdate." and "getfile: lost data" > > > > On Thu, May 01, 2008 at 03:52:14PM -0500, Scott Lambert wrote: > > > 120881 seems not to have been applied to CVS just yet. > > > > Ah - I'd missed 120881. This seems to relate to a more recent change > > of Kirk's. Kirk - do you want to look at: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=120881 > > > > or would you prefer if I had a look at it? > > I have taken a look at it and can make the following observations > on the proposed fix: > > It seems that the culprit is the following sequence in tape.c > if (curblk > 0) > panic("getfile: lost data\n"); > This was introduced in version 1.48 > Version 1.44.2.1 of tape.c shipped with FreeBSD 6.2 has a different > handler: > if (curblk > 0) > (*fill)((char *)buf, (long)((curblk * TP_BSIZE) + size)); > which doesn't panic. > > The 1.48 change added support for restoring extended attributes. > This change was never MFC'ed to FreeBSD 6 as it required updates > of and . There was concern > that too many folks would get compile errors in `make world' and not > understand what needed to be done to fix them. So the > if (curblk > 0) > (*fill)((char *)buf, (long)((curblk * TP_BSIZE) + size)); > code in 1.44.2.1 is correct for that version of restore because it > does not support extended attributes. I put the panic in for 1.48 > because I believed that I would always have skipped over any extra > blocks at the end of a file (or extended attribute) and thus there > should never have been any left. Obviously, I missed some case :-( > So, while the proposed fix does get rid of the panic, my concern is > that it will instead put some spurious data at the end of a file or > extended attribute. Ideally, I would like to get a copy of the dump > (or really just the first part of it needed to reproduce the problem) > so that I can analyze it to figure out what I am doing wrong. I have had the problem with dumps made on any of my FreeBSD 4.x systems. If you don't still have a 4.x system laying around, I can send you a link to a test dump. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From jonathan at kc8onw.net Sun May 4 09:13:01 2008 From: jonathan at kc8onw.net (jonathan@kc8onw.net) Date: Sun May 4 09:13:06 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> Message-ID: <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> [snip discussion] Sorry to all for the noise, turns out that with a motherboard BIOS update the card is recognized and initialized fine. For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I updated to the 1001 version. Jonathan Stewart From jfvogel at gmail.com Sun May 4 18:42:15 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun May 4 18:42:19 2008 Subject: em1: Unable to allocate bus resource: memory In-Reply-To: <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> Message-ID: <2a41acea0805041142q286f605bm3bf2fac5065db246@mail.gmail.com> On Sun, May 4, 2008 at 2:13 AM, wrote: > [snip discussion] > > Sorry to all for the noise, turns out that with a motherboard BIOS update > the card is recognized and initialized fine. > > For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I > updated to the 1001 version. > > Jonathan Stewart Excellent, glad to hear that it now works, and thanks the most for getting back on this Jonathan, always good for future searching to have closure :) Jack From cliftonr at lava.net Sun May 4 23:48:57 2008 From: cliftonr at lava.net (Clifton Royston) Date: Sun May 4 23:48:59 2008 Subject: FreeBSD 6.2 kernel parameters (Was Re: reboot after panic) In-Reply-To: <481B19C4.1040806@earthlink.net> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> Message-ID: <20080504234854.GB20269@lava.net> I got a couple requests for the tuning settings I've been using; it seems I'm not the only one who's had problems with FreeBSD 6.x stability as compared to 4.x. I don't understand the kernel well enough to say whether any of these are to any extent "right", but despite being pure voodoo, they seem to have helped substantially in performance and stability. I picked some of them off the discussion about tuning required to get ZFS running stably, ditto for discussion of ggatec/ggated. (The first 3 settings in sysctl - through kern.ipc.somaxconn - were carried over from my 4.x config.) Here's what I've got, and any solid recommendations from the kernel developers will I'm sure get close attention, and not only from me. I.e. if you can authoritatively tell me I'm an idiot, and some of these aren't really helping, or tell me what will, great. As I say, they seem to help. Ditto if someone can really say authoritatively whether 6.3 is in practice more stable and higher performance than 6.2; with all the discussed problems on list, and the discussions of known fixes not being committed, I have not felt confident about making such a move. /boot/loader.conf: kern.ipc.nmbclusters="32768" vm.kmem_size="512M" vm.kmem_size_max="512M" kern.maxvnodes="400000" /etc/sysctl.conf: # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # TUNING VALUES confirmed by Cal's mailserver testing kern.maxfiles=16384 kern.maxfilesperproc=16384 # Speculative: enlarge listen queue for large number of incoming TCP conns # Default listen queue size = 128, 1024 recommended for busy webservers kern.ipc.somaxconn=1024 # From FreeBSD mailing list, reported on improving stability with # ggatec/ggated. net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576 kern.ipc.maxsockbuf=2049152 # Disable hyperthreading "logical CPUs" machdep.hlt_logical_cpus=1 -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From Ingeborg.Hellemo at cc.uit.no Mon May 5 08:31:07 2008 From: Ingeborg.Hellemo at cc.uit.no (Ingeborg Hellemo) Date: Mon May 5 08:31:11 2008 Subject: PCI serial card works on 6.2 but not on 6.3 Message-ID: <200805050831.m458V4cJ069367@barnetv.cc.uit.no> We have upgraded a box from 6.2 to 6.3-RELEASE. Afterwards the box does not recognize its ST Lab I-160 serial card with Netmos 9845 Chipset. It worked flawlessly on 6.2 with puc(4) driver. >From dmesg: pci1: at device 8.0 (no driver attached) ~# pciconf -l -v | grep -B 4 UART none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 rev=0x01 hdr=0x00 vendor = 'MosChip Semiconductors (Was: Netmos Technology)' device = 'Nm9845 Parallel/Serial Port Adapter' class = simple comms subclass = UART Kernel-config includes device puc device sio ~# kldstat -v | grep puc 184 pccard/puc 185 pci/puc 186 cardbus/puc 196 puc/sio 354 puc/ppc Any ideas? --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg@cc.uit.no (Univ. of Troms?, Norway) From koitsu at freebsd.org Mon May 5 08:54:53 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 5 08:54:55 2008 Subject: PCI serial card works on 6.2 but not on 6.3 In-Reply-To: <200805050831.m458V4cJ069367@barnetv.cc.uit.no> References: <200805050831.m458V4cJ069367@barnetv.cc.uit.no> Message-ID: <20080505085452.GA48510@eos.sc1.parodius.com> On Mon, May 05, 2008 at 10:31:04AM +0200, Ingeborg Hellemo wrote: > We have upgraded a box from 6.2 to 6.3-RELEASE. Afterwards the box does not > recognize its ST Lab I-160 serial card with Netmos 9845 Chipset. It worked > flawlessly on 6.2 with puc(4) driver. > > Any ideas? Try loading the uart(4) driver, which can also replace sio(4) if I remember correctly. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From Ingeborg.Hellemo at cc.uit.no Mon May 5 09:01:28 2008 From: Ingeborg.Hellemo at cc.uit.no (Ingeborg Hellemo) Date: Mon May 5 09:01:33 2008 Subject: PCI serial card works on 6.2 but not on 6.3 In-Reply-To: Your message of "Mon, 05 May 2008 01:54:52 PDT." <20080505085452.GA48510@eos.sc1.parodius.com> Message-ID: <200805050901.m4591Pgh070794@barnetv.cc.uit.no> koitsu@freebsd.org said: > Try loading the uart(4) driver, which can also replace sio(4) if I remember > correctly. With puc(4) and sio(4) you have to make sure that both are either compiled into the kernel or loaded as a module. Do you know if this applies to uart(4) as well? --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg@cc.uit.no (Univ. of Troms?, Norway) From attilio at freebsd.org Mon May 5 17:04:40 2008 From: attilio at freebsd.org (Attilio Rao) Date: Mon May 5 17:04:44 2008 Subject: [HEADS UP] lockmgr needing of sys/lockmgr.h on thirdy part codes Message-ID: <3bbf2fe10805050938u4c48acacj673f59b013fd9efc@mail.gmail.com> Hello, after MFC'ed the usage of LOCK_FILE and LOCK_LINE for lockmgr(9), now thirdy part code needs to include sys/lock.h just priorior than sys/lockmgr. Even if the patch doesn't break ABI / KPI (so it doesn't need thirdy part KLD to be recompiled), it worths noting that the new code needs this extra-care in order to be fully compliant. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From xcllnt at mac.com Mon May 5 19:17:18 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon May 5 19:17:22 2008 Subject: PCI serial card works on 6.2 but not on 6.3 In-Reply-To: <200805050901.m4591Pgh070794@barnetv.cc.uit.no> References: <200805050901.m4591Pgh070794@barnetv.cc.uit.no> Message-ID: <1794FA69-FF9D-4BEF-BC93-934F39498702@mac.com> On May 5, 2008, at 2:01 AM, Ingeborg Hellemo wrote: > > koitsu@freebsd.org said: >> Try loading the uart(4) driver, which can also replace sio(4) if I >> remember >> correctly. > > With puc(4) and sio(4) you have to make sure that both are either > compiled > into the kernel or loaded as a module. Do you know if this applies > to uart(4) > as well? Yes. It's a problem/quirk of the kernel module infrastructure, not of drivers. Note that it's save to compile-in puc(4) but have sio(4) or uart(4) loaded as a module. Not the other way around... -- Marcel Moolenaar xcllnt@mac.com From ghelmer at palisadesys.com Mon May 5 23:18:11 2008 From: ghelmer at palisadesys.com (Guy Helmer) Date: Mon May 5 23:18:15 2008 Subject: Puzzling VM behavior in 6.3 Message-ID: <481F8C9B.1080508@palisadesys.com> I'm trying to track down a performance regression in a memory-hungry application that seems to be related to switching from FreeBSD 6 as of 2007-01-04 (6.2-ish) to a checkout as of 2007-10-04 (6.3-ish). With these two systems running identical software under load side-by-side on identical hardware, we've observed that the disk is busier on the 6.3 system under the same load, but there shouldn't be much file activity other than logging and the swap usage stays at 0. In trying to track this down, we've found the most significant differences are in statistics from parts of the VM system. A partial snapshot of "systat -vm" shows this: 6-STABLE 2007-10-04 sample Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 2174196 16428 2489520 29168 166416 count All 2340816 28304 6887896 45636 pages 6-STABLE 2007-01-04 sample Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 2092808 15184 2439012 25424 202272 count All 3949748 20856157408972 34392 pages We've also noticed large differences in some sysctl vm stats: 6-STABLE 2007-01-04 6-STABLE 2007-10-04 vm.stats.vm.v_forkpages: 660926510 1607169036 vm.stats.vm.v_pdpages: 608941 1793198 Does this information give anyone a clue as to where I should look next? Thanks for any help, Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. From bfriesen at simple.dallas.tx.us Tue May 6 00:43:15 2008 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue May 6 00:43:19 2008 Subject: static vs shared vs modules Message-ID: Mikhail Teterin requested that I forward this tidbit of info to the list. The GraphicsMagick build currently distributed with FreeBSD 7.0 uses shared libraries but not loadable modules. Some testing I did today shows that FreeBSD is much slower at starting GraphicsMagick as a large static executable (with shared lib dependencies) than it is for a shared library, which itself much slower than the case where parts of the needed code are loaded using modules. This may imply that FreeBSD is abnormally slow at initializing large applications (e.g. Solaris 10 does not exhibit this anomaly since timings vary only by a few percent). For the timings below, I execute the command using this simple shell script: #!/bin/bash i=1 count=1000 time while test $i -lt $count do eval "$@" let i=i+1 done Here is the original email content sent to Mikhail Teterin: I performed some timings for executing a minimal GraphicsMagick command 'gm convert -size 1x1 'xc:#F00' null:' 1000 times. This is under FreeBSD. Static build: real 0m39.558s user 0m24.825s sys 0m14.853s Shared build: real 0m27.828s user 0m18.367s sys 0m9.728s Modules build: real 0m11.041s user 0m4.785s sys 0m6.737s I find it interesting that FreeBSD is not very efficient at starting large (mostly) static programs. Solaris is a lot better at this. Probably much of the difference in performance has to do with how the run-time linker works, and the amount of initialized data which needs to be set. With the static build I can push the generated image size to to 500x500 without much impact on the total run time. The execution overhead is that great. These differences may seem small but if gm is invoked from a simple shell script, it can make the difference between processing 25 small images per second or 90 images per second. Also, the consumed user and system time is dramatically less. Bob ====================================== Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From webmaster at kibab.com Tue May 6 10:25:02 2008 From: webmaster at kibab.com (Ilya Bakulin) Date: Tue May 6 10:25:07 2008 Subject: MFC Candidate: convert ffs_softdep.c over to callout(9) In-Reply-To: <1209417467.33102.10.camel@localhost> References: <1209417467.33102.10.camel@localhost> Message-ID: <20080506142458.d7c02db1.webmaster@kibab.com> On Mon, 28 Apr 2008 17:17:47 -0400 Coleman Kane wrote: > Ilya, > > Yes just go ahead and apply the patch that was attached. Then rebuild > your kernel. Make sure that your softupdates are enabled on the UFS > partition(s). > > Then try hammering it with some sort of file test on that partition > (e.g. unpack a somewhat large source tarball and try building it). > > The kernel did build fine for me when I built it. Unfortunately, due to > my hardware, RELENG_7 doesn't "just work" for me from vanilla sources, > so I'd like to see some testers on better "supported" hardware. > > -- > Coleman Kane So, everything is working pretty good. Kernel build succeeded today on machine running patched version of ffs_softdep and GENERIC kernel. =================================================== kibab@media%uname -a FreeBSD media.home 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue May 6 10:56:39 MSD 2008 root@kibab-main.home:/usr/_OBJDIR/usr/src/sys/GENERIC i386 kibab@media%mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, NFS exported, local, soft-updates) /dev/ad0s1e on /var (ufs, local, soft-updates) =================================================== -- Ilya Bakulin From freebsd at scottevil.com Tue May 6 12:42:17 2008 From: freebsd at scottevil.com (Scott Oertel) Date: Tue May 6 12:42:22 2008 Subject: reboot after panic In-Reply-To: <4819BB3A.6000407@earthlink.net> References: <4819BB3A.6000407@earthlink.net> Message-ID: <48204E4F.7010402@scottevil.com> Stephen Clark wrote: > Hello List > > How do I get my freebsd 6.1 box to automatically reboot after a panic? > > Thanks, > Steve According to the handbook this is the default behavior unless you have KBD option enabled in your kernel, in which case adding KDB_UNATTENDED would cause the machine not to break to the debugger and to reboot after a panic. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html -Scott Oertel From koitsu at freebsd.org Tue May 6 12:59:39 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Tue May 6 12:59:44 2008 Subject: reboot after panic In-Reply-To: <481B19C4.1040806@earthlink.net> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> Message-ID: <20080506125938.GA8831@eos.sc1.parodius.com> On Fri, May 02, 2008 at 09:40:20AM -0400, Stephen Clark wrote: > Mine is a nvidia 6300 mb with a dual core amd processor. I am causing the panic > while trying to develope a DD for a EVDO usb modem - so it is not a great > problem - I was just surprised it wasn't rebooting. This is a 6.1 system. > > Yes it is sort of discouraging that it is hard to get answers when you > aren't running the latest and greatest kernel. In our case we have over 500 > units in > the field running a mix of 4.9 and 6.1 and it is not feasible to > continually upgrade them, especially since there is no documented way to > reliably upgrade > a remote installation. Does the system reboot OK if you issue the "reboot" command? If not, then the problem is likely with the reboot method being used (ACPI vs. non-ACPI) or ACPI tweakage prior to reboot, and not anything to do with panics. See the following two sysctls: hw.acpi.disable_on_reboot hw.acpi.handle_reboot -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From Ingeborg.Hellemo at cc.uit.no Tue May 6 13:05:10 2008 From: Ingeborg.Hellemo at cc.uit.no (Ingeborg Hellemo) Date: Tue May 6 13:05:15 2008 Subject: PCI serial card works on 6.2 but not on 6.3 In-Reply-To: Your message of "Mon, 05 May 2008 01:54:52 PDT." <20080505085452.GA48510@eos.sc1.parodius.com> Message-ID: <200805061305.m46D57EF097186@barnetv.cc.uit.no> koitsu@freebsd.org said: > Try loading the uart(4) driver, which can also replace sio(4) if I remember > correctly. I have now tried both loading the uart4) -driver and kompiled it into the kernel, but the card is still unrecognized: pci1: at device 8.0 (no driver attached) ~# pciconf -l -v | grep -B 4 UART none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 rev=0x01 hdr=0x00 vendor = 'MosChip Semiconductors (Was: Netmos Technology)' device = 'Nm9845 Parallel/Serial Port Adapter' class = simple comms subclass = UART --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg@cc.uit.no (Univ. of Troms?, Norway) From sclark46 at earthlink.net Tue May 6 13:48:01 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Tue May 6 13:48:06 2008 Subject: reboot after panic In-Reply-To: <20080506125938.GA8831@eos.sc1.parodius.com> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> <20080506125938.GA8831@eos.sc1.parodius.com> Message-ID: <4820618F.3070009@earthlink.net> Jeremy Chadwick wrote: > On Fri, May 02, 2008 at 09:40:20AM -0400, Stephen Clark wrote: >> Mine is a nvidia 6300 mb with a dual core amd processor. I am causing the panic >> while trying to develope a DD for a EVDO usb modem - so it is not a great >> problem - I was just surprised it wasn't rebooting. This is a 6.1 system. >> >> Yes it is sort of discouraging that it is hard to get answers when you >> aren't running the latest and greatest kernel. In our case we have over 500 >> units in >> the field running a mix of 4.9 and 6.1 and it is not feasible to >> continually upgrade them, especially since there is no documented way to >> reliably upgrade >> a remote installation. > > Does the system reboot OK if you issue the "reboot" command? > > If not, then the problem is likely with the reboot method being used > (ACPI vs. non-ACPI) or ACPI tweakage prior to reboot, and not anything > to do with panics. See the following two sysctls: > > hw.acpi.disable_on_reboot > hw.acpi.handle_reboot > It reboots fine when I "shutdown -r now". It is only after a panic that it hangs. I have it set to save the crash dump: dumpdev="AUTO" # Device to crashdump to (device name, AUTO, or NO). dumpdir="/var/crash" # Directory where crash dumps are to be stored but there is never one. It is like it hangs trying to dump the memory image. This mother board has both sata and pata controllers but I am using only pata drives. dmesg from boot. Copyright (c) 1992-2006 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 6.1-STABLE #36: Fri May 2 09:02:26 EDT 2008 root@J301002.nwv01.com:/mnt/src/sys/i386/compile/WOLFPAC6SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2410.99-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 real memory = 938409984 (894 MB) avail memory = 908926976 (866 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard 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 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: reservation of 1bf00000, 100000 (3) failed acpi0: reservation of 2bf00000, 100000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 4.0 on pci0 pci3: on pcib3 pci0: at device 5.0 (no driver attached) pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff at device 11.1 on pci0 ehci0: [GIANT-LOCKED] usb1: waiting for BIOS to give up control usb1: timed out waiting for BIOS usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 8 ports with 8 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400 -0xf40f at device 13.0 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70- 0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 22 at device 14.0 on pci0 ata2: on atapci1 ata3: on atapci1 pcib4: at device 16.0 on pci0 pci4: on pcib4 rl0: port 0xac00-0xacff mem 0xfdaff000-0xfdaff0ff irq 18 at device 6. 0 on pci4 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:fc:fb:1e:82 rl1: port 0xa800-0xa8ff mem 0xfdafe000-0xfdafe0ff irq 16 at device 8. 0 on pci4 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:50:fc:f9:60:24 nve0: port 0xdc00-0xdc07 mem 0xfe02c000-0xfe02cfff irq 2 3 at device 20.0 on pci0 nve0: Ethernet address 00:e0:4c:ea:6b:6d miibus2: on nve0 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:e0:4c:ea:6b:6d acpi_tz0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 4.000 msec Fast IPsec: Initialized Security Association Processing. IP Filter: v4.1.28np1 initialized. Default = pass all, Logging = enabled ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, lo gging unlimited ad0: 38166MB at ata0-master UDMA100 ad2: 38166MB at ata1-master UDMA100 SMP: AP CPU #1 Launched! -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From koitsu at freebsd.org Tue May 6 13:56:42 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Tue May 6 13:56:46 2008 Subject: reboot after panic In-Reply-To: <4820618F.3070009@earthlink.net> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> <20080506125938.GA8831@eos.sc1.parodius.com> <4820618F.3070009@earthlink.net> Message-ID: <20080506135642.GA10543@eos.sc1.parodius.com> On Tue, May 06, 2008 at 09:47:59AM -0400, Stephen Clark wrote: > Jeremy Chadwick wrote: >> On Fri, May 02, 2008 at 09:40:20AM -0400, Stephen Clark wrote: >>> Mine is a nvidia 6300 mb with a dual core amd processor. I am causing the panic >>> while trying to develope a DD for a EVDO usb modem - so it is not a great >>> problem - I was just surprised it wasn't rebooting. This is a 6.1 system. >>> >>> Yes it is sort of discouraging that it is hard to get answers when you >>> aren't running the latest and greatest kernel. In our case we have over >>> 500 units in >>> the field running a mix of 4.9 and 6.1 and it is not feasible to >>> continually upgrade them, especially since there is no documented way to >>> reliably upgrade >>> a remote installation. >> >> Does the system reboot OK if you issue the "reboot" command? >> >> If not, then the problem is likely with the reboot method being used >> (ACPI vs. non-ACPI) or ACPI tweakage prior to reboot, and not anything >> to do with panics. See the following two sysctls: >> >> hw.acpi.disable_on_reboot >> hw.acpi.handle_reboot > > It reboots fine when I "shutdown -r now". It is only after a panic > that it hangs. I have it set to save the crash dump: > dumpdev="AUTO" # Device to crashdump to (device name, AUTO, or NO). > dumpdir="/var/crash" # Directory where crash dumps are to be stored > > but there is never one. It is like it hangs trying to dump the memory image. > > This mother board has both sata and pata controllers but I am using only pata > drives. A kernel panic causes the kernel to dump all memory contents (from start to end) to whatever swap device is available. It's written to the disk in a fairly "raw" format, with some header data of some sort I think. After it's done, the system should reboot. My guess is that you either don't have any swap defined, swap is defined incorrectly (disklabel -r output would be useful), or your swap space is smaller than your total amount of memory. (Swap should usually be 2x RAM). dumpdir and dumpdev are used during the startup process, where savecore(8) is called. The memory dump on the swap device is extracted and stored in a file in $dumpdir, which you can examine later. Keep in mind that savecore(8) will use /dev/dumpdev, which is a symlink to whatever device your swap lives on -- and that's determined by reading /etc/fstab. Does this help? :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bsam at ipt.ru Tue May 6 14:10:34 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Tue May 6 14:10:41 2008 Subject: PCI serial card works on 6.2 but not on 6.3 In-Reply-To: <200805061305.m46D57EF097186@barnetv.cc.uit.no> (Ingeborg Hellemo's message of "Tue, 06 May 2008 15:05:07 +0200") References: <200805061305.m46D57EF097186@barnetv.cc.uit.no> Message-ID: <29591840@serv3.int.kfs.ru> On Tue, 06 May 2008 15:05:07 +0200 Ingeborg Hellemo wrote: > koitsu@freebsd.org said: > > Try loading the uart(4) driver, which can also replace sio(4) if I remember > > correctly. > I have now tried both loading the uart4) -driver and kompiled it into the > kernel, but the card is still unrecognized: > pci1: at device 8.0 (no driver attached) > ~# pciconf -l -v | grep -B 4 UART > none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 rev=0x01 > hdr=0x00 > vendor = 'MosChip Semiconductors (Was: Netmos Technology)' > device = 'Nm9845 Parallel/Serial Port Adapter' > class = simple comms > subclass = UART You may be interested in kern/58953 (the last followup with the patch): http://www.freebsd.org/cgi/query-pr.cgi?pr=58953 WBR -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? From sclark46 at earthlink.net Tue May 6 15:49:42 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Tue May 6 15:49:48 2008 Subject: reboot after panic In-Reply-To: <20080506135642.GA10543@eos.sc1.parodius.com> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> <20080506125938.GA8831@eos.sc1.parodius.com> <4820618F.3070009@earthlink.net> <20080506135642.GA10543@eos.sc1.parodius.com> Message-ID: <48207E12.9010009@earthlink.net> Jeremy Chadwick wrote: > On Tue, May 06, 2008 at 09:47:59AM -0400, Stephen Clark wrote: >> Jeremy Chadwick wrote: >>> On Fri, May 02, 2008 at 09:40:20AM -0400, Stephen Clark wrote: >>>> Mine is a nvidia 6300 mb with a dual core amd processor. I am causing the panic >>>> while trying to develope a DD for a EVDO usb modem - so it is not a great >>>> problem - I was just surprised it wasn't rebooting. This is a 6.1 system. >>>> >>>> Yes it is sort of discouraging that it is hard to get answers when you >>>> aren't running the latest and greatest kernel. In our case we have over >>>> 500 units in >>>> the field running a mix of 4.9 and 6.1 and it is not feasible to >>>> continually upgrade them, especially since there is no documented way to >>>> reliably upgrade >>>> a remote installation. >>> Does the system reboot OK if you issue the "reboot" command? >>> >>> If not, then the problem is likely with the reboot method being used >>> (ACPI vs. non-ACPI) or ACPI tweakage prior to reboot, and not anything >>> to do with panics. See the following two sysctls: >>> >>> hw.acpi.disable_on_reboot >>> hw.acpi.handle_reboot >> It reboots fine when I "shutdown -r now". It is only after a panic >> that it hangs. I have it set to save the crash dump: >> dumpdev="AUTO" # Device to crashdump to (device name, AUTO, or NO). >> dumpdir="/var/crash" # Directory where crash dumps are to be stored >> >> but there is never one. It is like it hangs trying to dump the memory image. >> >> This mother board has both sata and pata controllers but I am using only pata >> drives. > > A kernel panic causes the kernel to dump all memory contents (from start > to end) to whatever swap device is available. It's written to the disk > in a fairly "raw" format, with some header data of some sort I think. > After it's done, the system should reboot. > > My guess is that you either don't have any swap defined, swap is defined > incorrectly (disklabel -r output would be useful), or your swap space is > smaller than your total amount of memory. (Swap should usually be 2x > RAM). > > dumpdir and dumpdev are used during the startup process, where > savecore(8) is called. The memory dump on the swap device is extracted > and stored in a file in $dumpdir, which you can examine later. Keep in > mind that savecore(8) will use /dev/dumpdev, which is a symlink to > whatever device your swap lives on -- and that's determined by reading > /etc/fstab. > > Does this help? :-) > Hi Jeremy, Thanks for the response but I think I have everything set up OK. from top: Mem: 33M Active, 19M Inact, 56M Wired, 54M Buf, 762M Free Swap: 2048M Total, 2048M Free $ sudo disklabel /dev/ad0s1 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 204800 0 4.2BSD 1024 8192 23 b: 4194304 204800 swap c: 78156162 0 unused 0 0 # "raw" part, don't edit d: 45879682 4399104 4.2BSD 2048 16384 89 e: 409600 50278786 4.2BSD 2048 16384 97 f: 2097152 50688386 4.2BSD 2048 16384 89 g: 12685312 52785538 4.2BSD 2048 16384 89 h: 12685312 65470850 4.2BSD 2048 16384 89 J301002:~ 1 gig of memory $ sysctl -a |grep physmem hw.physmem: 929439744 $ ls -al /dev/dumpdev lrwxr-xr-x 1 root wheel 11 May 6 05:39 /dev/dumpdev -> /dev/ad0s1b $ less /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b none swap sw 0 0 Any other ideas? Regards, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From xcllnt at mac.com Tue May 6 16:54:02 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue May 6 16:54:06 2008 Subject: PCI serial card works on 6.2 but not on 6.3 In-Reply-To: <200805061305.m46D57EF097186@barnetv.cc.uit.no> References: <200805061305.m46D57EF097186@barnetv.cc.uit.no> Message-ID: <770A639E-DDE0-4464-B8A3-1D63EBFA6B65@mac.com> On May 6, 2008, at 6:05 AM, Ingeborg Hellemo wrote: > > koitsu@freebsd.org said: >> Try loading the uart(4) driver, which can also replace sio(4) if I >> remember >> correctly. > > I have now tried both loading the uart4) -driver and kompiled it > into the > kernel, but the card is still unrecognized: > > pci1: at device 8.0 (no driver attached) > > ~# pciconf -l -v | grep -B 4 UART > none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 > rev=0x01 > hdr=0x00 > vendor = 'MosChip Semiconductors (Was: Netmos Technology)' > device = 'Nm9845 Parallel/Serial Port Adapter' > class = simple comms > subclass = UART The problem seems to be puc(4). This appears to be a multi-port card, which means puc(4) needs to attach. This is not happening. The problem seems to be revision 1.51.2.3 of src/sys/dev/puc/pucdata.c Could you try the following patch? Index: pucdata.c =================================================================== RCS file: /volume/apg-bbuild09-b/marcelm/ncvs/src/sys/dev/puc/ pucdata.c,v retrieving revision 1.51.2.3 diff -u -r1.51.2.3 pucdata.c --- pucdata.c 15 Dec 2006 22:31:37 -0000 1.51.2.3 +++ pucdata.c 6 May 2008 16:51:02 -0000 @@ -946,7 +946,7 @@ /* NetMos 4S0P PCI: 4S, 0P */ { "NetMos NM9845 Quad UART", - { 0x9710, 0x9845, 0, 0x0014 }, + { 0x9710, 0x9845, 0, 0x0004 }, { 0xffff, 0xffff, 0, 0xffff }, { { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, -- Marcel Moolenaar xcllnt@mac.com From cliftonr at lava.net Tue May 6 17:18:31 2008 From: cliftonr at lava.net (Clifton Royston) Date: Tue May 6 17:18:34 2008 Subject: reboot after panic In-Reply-To: <20080506135642.GA10543@eos.sc1.parodius.com> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> <20080506125938.GA8831@eos.sc1.parodius.com> <4820618F.3070009@earthlink.net> <20080506135642.GA10543@eos.sc1.parodius.com> Message-ID: <20080506171829.GA6784@lava.net> On Tue, May 06, 2008 at 06:56:42AM -0700, Jeremy Chadwick wrote: > On Tue, May 06, 2008 at 09:47:59AM -0400, Stephen Clark wrote: ... > > but there is never one. It is like it hangs trying to dump the memory image. > > > > This mother board has both sata and pata controllers but I am using only pata > > drives. > > A kernel panic causes the kernel to dump all memory contents (from start > to end) to whatever swap device is available. It's written to the disk > in a fairly "raw" format, with some header data of some sort I think. > After it's done, the system should reboot. > > My guess is that you either don't have any swap defined, swap is defined > incorrectly (disklabel -r output would be useful), or your swap space is > smaller than your total amount of memory. (Swap should usually be 2x > RAM). > > dumpdir and dumpdev are used during the startup process, where > savecore(8) is called. The memory dump on the swap device is extracted > and stored in a file in $dumpdir, which you can examine later. Keep in > mind that savecore(8) will use /dev/dumpdev, which is a symlink to > whatever device your swap lives on -- and that's determined by reading > /etc/fstab. > > Does this help? :-) You might consider the possibility that he is correct in what he has said, rather precisely, is going on. FreeBSD 6.2 (and apparently 6.1) can indeed double-fault or hang during the panic dump in which case no reboot occurs and there is nothing successfully dumped to analyze for debugging, either. It is likely that it only occurs with certain hardware conditions or configurations, which is why not everyone would see it, but that's not the same thing as it being a hardware problem. I've been seeing this on all of my SMP machines since October, and have reported it onlist, and I've been successfully running FreeBSD for nearly 10 years (starting with 3.3) and BSD/OS for years before that. It ain't necessarily PEBKAC. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From mail25 at bzerk.org Wed May 7 08:10:25 2008 From: mail25 at bzerk.org (Ruben de Groot) Date: Wed May 7 08:10:29 2008 Subject: Panics in kern_timeout.c (7-STABLE) Message-ID: <20080507073840.GA1824@ei.bzerk.org> Hi, I've experienced 2 panics in the last couple of days after upgrading to 7-stable sources of about 2 weeks ago: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x9608 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05f095f stack pointer = 0x28:0xd4ceec80 frame pointer = 0x28:0xd4ceecbc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 13 (swi4: clock sio) trap number = 12 panic: page fault cpuid = 0 Uptime: 3d6h24m45s Physical memory: 503 MB Dumping 96 MB: 81 65 49 33 17 1 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) list *0xc05f095f 0xc05f095f is in softclock (/usr/src/sys/kern/kern_timeout.c:203). 198 curticks = softticks; 199 bucket = &callwheel[curticks & callwheelmask]; 200 c = TAILQ_FIRST(bucket); 201 while (c) { 202 depth++; 203 if (c->c_time != curticks) { 204 c = TAILQ_NEXT(c, c_links.tqe); 205 ++steps; 206 if (steps >= MAX_SOFTCLOCK_STEPS) { 207 nextsoftcheck = c; The backtrace doesn't look very informative to me, but I'll include it here for completeness: (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc05de987 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05dec49 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc08961cc in trap_fatal (frame=0xd4ceec40, eva=38408) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0896b4f in trap (frame=0xd4ceec40) at /usr/src/sys/i386/i386/trap.c:280 #5 0xc087cb8b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc05f095f in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:202 #7 0xc05bf55b in ithread_loop (arg=0xc2997280) at /usr/src/sys/kern/kern_intr.c:1036 #8 0xc05bc339 in fork_exit (callout=0xc05bf3b0 , arg=0xc2997280, frame=0xd4ceed38) at /usr/src/sys/kern/kern_fork.c:783 #9 0xc087cc00 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 Can anyone offer a hand in how to debug this further? cheers, Ruben From saper at system.pl Wed May 7 16:01:09 2008 From: saper at system.pl (Marcin Cieslak) Date: Wed May 7 16:01:16 2008 Subject: mpd5.1 and HUAWEI 3g card (ubsa) In-Reply-To: <481B4D08.7030507@moneybookers.com> References: <481B4D08.7030507@moneybookers.com> Message-ID: <4821D229.1000300@system.pl> Stefan Lambrev wrote: > client1: > create bundle template B1 > > create link static L1 modem > set modem device /dev/cuaU0 > set modem speed 115200 > set modem script DialPeer > set modem idle-script AnswerCall > set modem var $DialPrefix "DT" > set modem var $Telephone "*99***1#" > set link no pap chap eap > set link accept pap > set auth authname "MyLogin" > set auth password "MyPassword" > set link max-redial 1 > set link action bundle B1 > open Here's my config for another GPRS/UMTS provider: startup: default: eranet: log ipcp ipcp2 create bundle static B1 set iface route default set ipcp ranges 0.0.0.0/0 10.6.6.6/0 set ipcp disable req-pri-dns req-sec-dns < you probably don'want this set ipcp disable req-pri-nbns req-sec-nbns < you probably don'want this create link static L1 modem set modem device /dev/cuaU0 set modem speed 921600 set modem script GprsDial set modem watch -cd < ignore CD set link disable chap pap set link accept chap pap set link action bundle B1 set auth authname erainternet open My modem script: GprsDial: set $dialResult "FAIL" set $ConnectionSpeed "" if $ConnectTimeout == "" set $ConnectTimeout 45 print "AT+CGDCONT=1,\"ip\",\"erainternet\"\r\n" << provider specific match "ERR" DialErrorInit wait 5 print "AT+CGATT=1\r\n" match "ERR" DialErrorInit wait 5 print "ATDT*99#\r\n" match "NO CARRIER" DialAbortNoCar match "NO DIAL" DialAbortNoDial match "BUSY" DialAbortBusy regex "CONNECT *([0-9]*).*$" DialConnect match "ERR" DialErrorInit wait $ConnectTimeout log "No response from the modem after dialing." failure > Another issues is that after the first attempt to dial the modem freezes > for few seconds and I see lot of those messages: > May 2 20:04:10 laptop kernel: ubsa_cfg_request: device request failed, > err=USBD_ERR_STALLED (ignored) > but this should go to -usb probably :) This may be related to the driver. I am using stock ubsa (with patches for Option GTMAX) without problems. One thing that may make things easier, can you change "link enable pap" to "link enable pap chap" ? --Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080507/5db5fe7f/signature.pgp From yani at pi-greece.eu Wed May 7 17:19:35 2008 From: yani at pi-greece.eu (Yani Karydis) Date: Wed May 7 17:19:40 2008 Subject: Kernel panic - em0 culprit? In-Reply-To: <20080506120014.60FED10656C9@hub.freebsd.org> References: <20080506120014.60FED10656C9@hub.freebsd.org> Message-ID: <4821DC99.1050008@pi-greece.eu> Hello, My server is experiencing occasional kernel panics when under moderate load. I'm attaching a crash dump and the dmesg output. I'm not sure how to read the kernel backtrace but it looks like the Intel NIC (em0) caused the problem. Occasionally, I used to get a "em0: watchdog timeout -- resetting" error message, but I never had a kernel panic. The problem started last week when I updated the server to the latest 7-STABLE. Can anyone help pinpoint the problem? Thanks, Yani kgdb output: [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". There is no member named pathname. Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/miibus.ko...Reading symbols from /boot/kernel/miibus.ko.symbols...done. done. Loaded symbols for /boot/kernel/miibus.ko Reading symbols from /boot/kernel/if_vr.ko...Reading symbols from /boot/kernel/if_vr.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_vr.ko Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/bridgestp.ko...Reading symbols from /boot/kernel/bridgestp.ko.symbols...done. done. Loaded symbols for /boot/kernel/bridgestp.ko Reading symbols from /boot/kernel/if_bridge.ko...Reading symbols from /boot/kernel/if_bridge.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_bridge.ko Reading symbols from /boot/kernel/wlan_wep.ko...Reading symbols from /boot/kernel/wlan_wep.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_wep.ko Reading symbols from /boot/kernel/wlan_tkip.ko...Reading symbols from /boot/kernel/wlan_tkip.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_tkip.ko Reading symbols from /boot/kernel/wlan_ccmp.ko...Reading symbols from /boot/kernel/wlan_ccmp.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_ccmp.ko Reading symbols from /boot/kernel/wlan_xauth.ko...Reading symbols from /boot/kernel/wlan_xauth.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_xauth.ko Reading symbols from /boot/kernel/wlan_acl.ko...Reading symbols from /boot/kernel/wlan_acl.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_acl.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/nfslockd.ko...Reading symbols from /boot/kernel/nfslockd.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfslockd.ko Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/kernel/krpc.ko.symbols...done. done. Loaded symbols for /boot/kernel/krpc.ko Unread portion of the kernel message buffer: em0: watchdog timeout -- resetting <5>em0: link state changed to DOWN kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05bc167 stack pointer = 0x28:0xe403ec10 frame pointer = 0x28:0xe403ec2c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 23 (em0 taskq) trap number = 12 panic: page fault Uptime: 1d2h53m51s Physical memory: 1015 MB Dumping 224 MB: 209 193 177 161 145 129 113 97 81 65 49 33 17 1 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list 190 static __inline struct thread * 191 __curthread(void) 192 { 193 struct thread *td; 194 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); 196 return (td); 197 } 198 #define curthread (__curthread()) 199 (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc058ad84 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc058af84 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc07ccb5c in trap_fatal (frame=0xe403ebd0, eva=20) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc07cd4dd in trap (frame=0xe403ebd0) at /usr/src/sys/i386/i386/trap.c:280 #5 0xc07b721b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc05bc167 in propagate_priority (td=0xc3ab7880) at /usr/src/sys/kern/subr_turnstile.c:272 #7 0xc05bcab8 in turnstile_wait (ts=0xc3a9d370, owner=0xc3ab7880, queue=Variable "queue" is not available. ) at /usr/src/sys/kern/subr_turnstile.c:739 #8 0xc057e88d in _mtx_lock_sleep (m=0xc3baa2f4, tid=3283517440, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:416 #9 0xc04b02d7 in em_handle_rxtx (context=0xc3baa000, pending=1) at /usr/src/sys/dev/em/if_em.c:1666 #10 0xc05bb032 in taskqueue_run (queue=0xc3b94100) at /usr/src/sys/kern/subr_taskqueue.c:255 #11 0xc05bb20d in taskqueue_thread_loop (arg=0xc3baa368) at /usr/src/sys/kern/subr_taskqueue.c:374 #12 0xc0569d34 in fork_exit (callout=0xc05bb190 , arg=0xc3baa368, frame=0xe403ed38) at /usr/src/sys/kern/kern_fork.c:783 #13 0xc07b7290 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 dmesg: Copyright (c) 1992-2008 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 7.0-STABLE #11: Tue May 6 15:34:11 EEST 2008 root@techserver.pi-greece.eu:/usr/obj/usr/src/sys/TECHSERVER7 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) 2300+ (1585.75-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0480800 real memory = 1073676288 (1023 MB) avail memory = 1041485824 (993 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 32M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa000-0xa0ff mem 0xd0000000-0xd7ffffff,0xe0000000-0xe000ffff at device 0.0 on pci1 em0: port 0xb000-0xb03f mem 0xe1000000-0xe101ffff,0xe1020000-0xe103ffff irq 17 at device 9.0 on pci0 em0: [FILTER] em0: Ethernet address: 00:07:e9:49:18:b3 aac0: mem 0xd8000000-0xdbffffff irq 18 at device 10.0 on pci0 aac0: Enable Raw I/O aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 2610SA, aac driver 2.0.0-1 ahc0: port 0xb400-0xb4ff mem 0xe1042000-0xe1042fff irq 19 at device 11.0 on pci0 ahc0: [ITHREAD] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs ral0: mem 0xe1040000-0xe1041fff irq 17 at device 13.0 on pci0 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 ral0: Ethernet address: 00:11:50:14:b7:66 ral0: [ITHREAD] atapci0: port 0xb800-0xb807,0xbc00-0xbc03,0xc000-0xc007,0xc400-0xc403,0xc800-0xc80f,0xcc00-0xccff irq 20 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xd400-0xd41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd800-0xd81f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xdc00-0xdc1f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe000-0xe01f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xe1043000-0xe10430ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0xe400-0xe4ff mem 0xe1044000-0xe10440ff irq 23 at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x78 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:0f:ea:e0:eb:cc vr0: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcc000-0xccfff,0xcd000-0xd0fff,0xd1000-0xd17ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] Timecounter "TSC" frequency 1585747239 Hz quality 800 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle ad0: 305244MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 aacd0: on aac0 aacd0: 953812MB (1953406976 sectors) sa0 at ahc0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-3 device sa0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted bridge0: Ethernet address: 86:5b:d2:24:75:72 em0: link state changed to UP From karl at denninger.net Thu May 8 05:06:20 2008 From: karl at denninger.net (Karl Denninger) Date: Thu May 8 05:06:24 2008 Subject: Best-performing disk I/O options for a DBMS server on 7-STABLE Message-ID: <20080508050550.GA76170@FS.denninger.net> What's the best option? Assume PCI/Express bus, having to buy a card AND disk(s) are fine. I assume SCSI is the best path forward (either SA/SCSI or traditional) but have been out of the loop on the card(s) that work properly for a good long while. What's my best option? -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.com Musings Of A Sentient Mind From kometen at gmail.com Thu May 8 06:28:46 2008 From: kometen at gmail.com (Claus Guttesen) Date: Thu May 8 06:28:50 2008 Subject: Best-performing disk I/O options for a DBMS server on 7-STABLE In-Reply-To: <20080508050550.GA76170@FS.denninger.net> References: <20080508050550.GA76170@FS.denninger.net> Message-ID: > What's the best option? > > Assume PCI/Express bus, having to buy a card AND disk(s) are fine. > > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > have been out of the loop on the card(s) that work properly for a good long > while. > > What's my best option? I have a HP DL360 G5 with an addon p800-controller with battery-backed cache, a msa70-cabinet and 11 2,5" sas-disks @ 15K in raid-6 and one hotspare. The controller has 512 MB and is performing satisfactory. This is on FreeBSD 7.0 release and postgresql 8.3.1. I've heard many positive remarks on areca's raid-controllers as well, vendor-support on FreeBSD and good performance. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From andrew at modulus.org Thu May 8 06:30:45 2008 From: andrew at modulus.org (Andrew Snow) Date: Thu May 8 06:30:51 2008 Subject: Best-performing disk I/O options for a DBMS server on 7-STABLE In-Reply-To: <20080508050550.GA76170@FS.denninger.net> References: <20080508050550.GA76170@FS.denninger.net> Message-ID: <48229E0F.90004@modulus.org> Karl Denninger wrote: > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > have been out of the loop on the card(s) that work properly for a good long > while. I've used several of the new 3ware SATA PCI-express cards: 2, 4 and 16 ports. They always work really well under FreeBSD 6 and 7, and are very fast. I haven't tried their SAS cards personally but I understand that it is equally good. FWIW, I have had bad experiences with Areca. - Andrew From Ingeborg.Hellemo at cc.uit.no Thu May 8 07:27:36 2008 From: Ingeborg.Hellemo at cc.uit.no (Ingeborg Hellemo) Date: Thu May 8 07:27:41 2008 Subject: PCI serial card works on 6.2 but not on 6.3 In-Reply-To: Your message of "Tue, 06 May 2008 09:53:42 PDT." <770A639E-DDE0-4464-B8A3-1D63EBFA6B65@mac.com> Message-ID: <200805080727.m487RWtp052442@barnetv.cc.uit.no> xcllnt@mac.com said: > The problem seems to be revision 1.51.2.3 of src/sys/dev/puc/pucdata.c > Could you try the following patch? Thank you, it worked! --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg@cc.uit.no (Univ. of Troms?, Norway) From stefan.lambrev at moneybookers.com Thu May 8 07:30:14 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Thu May 8 07:30:22 2008 Subject: cvsup.uk.FreeBSD.org Message-ID: <4822ABFF.3050700@moneybookers.com> Greetings, cvsup.uk.FreeBSD.org is outdated. I know this is not the proper list, but which one is? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From roberto at keltia.freenix.fr Thu May 8 07:35:42 2008 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Thu May 8 07:35:47 2008 Subject: cvsup.uk.FreeBSD.org In-Reply-To: <4822ABFF.3050700@moneybookers.com> References: <4822ABFF.3050700@moneybookers.com> Message-ID: <20080508073540.GA95771@keltia.freenix.fr> Stefan Lambrev disait : > cvsup.uk.FreeBSD.org is outdated. > I know this is not the proper list, but which one is? freebsd-hubs is, redirected. I've noticed that recently but I should have send a mail about it, sorry. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; i386 From paul.koch at statseeker.com Thu May 8 08:26:03 2008 From: paul.koch at statseeker.com (Paul Koch) Date: Thu May 8 08:26:07 2008 Subject: flock incorrectly detects deadlock on 7-stable and current Message-ID: <200805081812.24692.paul.koch@statseeker.com> Hi, We have been trying to track down a problem with one of our apps which does a lot of flock(2) calls. flock returns errno 11 (Resource deadlock avoided) under certain scenarios. Our app works fine on 7-Release, but fails on 7-stable and -current. The problem appears to be when we have at least three processes doing flock() on a file, and one is trying to upgrade a shared lock to an exclusive lock but fails with a deadlock avoided. Attached is a simple flock() test program. a. Process 1 requests and gets a shared lock b. Process 2 requests and blocks for an exclusive lock c. Process 3 requests and gets a shared lock d. Process 3 requests an upgrade to an exclusive lock but fails (errno 11) If we change 'd' to Process 3 requests unlock, then requests exclusive lock, it works. The manual page says: "A shared lock may be upgraded to an exclusive lock, and vice versa, simply by specifying the appropriate lock type; this results in the previous lock being released and the new lock applied (possibly after other processes have gained and released the lock)." The manual page doesn't mention that flock() can fail with a deadlock. Our test environment is: - 8 core Intel machine running i386 stable - 4 core Intel machine running amd64 current (20080508) - 4 core Intel machine running amd64 stable (20080508) - 2 core AMD machine running i386 stable (20080418) - 2 core AMD machine running i386 stable (20080418) - single core (no hyperthreading) i386 stable (20080418) There appears to have been changes to kern_lockf.c and other stuff around the 10th April to do with deadlock detection. We don't see the problem on 6.2-stable, 7-Release, or 7-stable pre ~10th April. Paul. From dfr at rabson.org Thu May 8 08:37:02 2008 From: dfr at rabson.org (Doug Rabson) Date: Thu May 8 08:37:05 2008 Subject: flock incorrectly detects deadlock on 7-stable and current In-Reply-To: <200805081812.24692.paul.koch@statseeker.com> References: <200805081812.24692.paul.koch@statseeker.com> Message-ID: <1B6FCF23-413B-452A-B66D-3CCD6257F7BD@rabson.org> On 8 May 2008, at 09:12, Paul Koch wrote: > Hi, > > We have been trying to track down a problem with one of our apps which > does a lot of flock(2) calls. flock returns errno 11 (Resource > deadlock avoided) under certain scenarios. Our app works fine on > 7-Release, but fails on 7-stable and -current. > > The problem appears to be when we have at least three processes doing > flock() on a file, and one is trying to upgrade a shared lock to an > exclusive lock but fails with a deadlock avoided. > > Attached is a simple flock() test program. > > a. Process 1 requests and gets a shared lock > b. Process 2 requests and blocks for an exclusive lock > c. Process 3 requests and gets a shared lock > d. Process 3 requests an upgrade to an exclusive lock but fails (errno > 11) > > If we change 'd' to > Process 3 requests unlock, then requests exclusive lock, it works. Could you possibly try this patch and tell me if it helps: ==== //depot/user/dfr/lockd/sys/kern/kern_lockf.c#57 - /tank/projects/ lockd/src/sys/kern/kern_lockf.c ==== @@ -1370,6 +1370,18 @@ } /* + * For flock type locks, we must first remove + * any shared locks that we hold before we sleep + * waiting for an exclusive lock. + */ + if ((lock->lf_flags & F_FLOCK) && + lock->lf_type == F_WRLCK) { + lock->lf_type = F_UNLCK; + lf_activate_lock(state, lock); + lock->lf_type = F_WRLCK; + } + + /* * We are blocked. Create edges to each blocking lock, * checking for deadlock using the owner graph. For * simplicity, we run deadlock detection for all @@ -1389,17 +1401,6 @@ } /* - * For flock type locks, we must first remove - * any shared locks that we hold before we sleep - * waiting for an exclusive lock. - */ - if ((lock->lf_flags & F_FLOCK) && - lock->lf_type == F_WRLCK) { - lock->lf_type = F_UNLCK; - lf_activate_lock(state, lock); - lock->lf_type = F_WRLCK; - } - /* * We have added edges to everything that blocks * us. Sleep until they all go away. */ From petefrench at ticketswitch.com Thu May 8 09:30:03 2008 From: petefrench at ticketswitch.com (Pete French) Date: Thu May 8 09:30:06 2008 Subject: Best-performing disk I/O options for a DBMS server on 7-STABLE In-Reply-To: <20080508050550.GA76170@FS.denninger.net> Message-ID: > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > have been out of the loop on the card(s) that work properly for a good long > while. HP P400 cards are PCI express and SAS - they work very well under FreeBSD. I've also used the cheaper E200 and that appears to be fine too, though I havent run it for as long as the 400's. http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html -pete. From news at streetsoul.lv Thu May 8 09:46:46 2008 From: news at streetsoul.lv (Streetsoul) Date: Thu May 8 09:46:50 2008 Subject: New Arrivals: New brand - Analog Clothing Message-ID: STREETSOUL.EU - Streetwear Clothing Online Store Newsletter ***************************************************************** Sunny Greetings to Ya all!!! New Arrivals - New Brand - Analog Cloting!!! Press here to view new arrivals from Analog Clothing! or copy the link in a browser: http://www.streetsoul.eu/zoom_brand/31 More About Analog Clothing: It's written in our DNA. It's woven into the fabric of our constitution. It was in Trevor Andrew's first Analog I-Pod jacket and it's scratched on the bottom of Nathan Fletcher's 4-fin. It's the ultra-thin thread that ties together surfing, skateboarding and snowboarding. It's the fearless voice calling you to Liberate, Unify, Mobilize and Resolve. It's non-digital, low-technology. It's the new elitism. It's Analogic. Since the beginning of the action sports market, influential kids have gravitated towards progressive and creative movements within snowboarding, skateboarding and surfing. Analog is a clothing company born in outerwear, raised at the beach and entrenched in cities everywhere. Analog is an invitation to take a stand, make a point, challenge a value and open a few minds. Check our internet store or if you happen to be in Riga, you're welcome to visit us @ 85 Terbatas st. :) http://www.streetsoul.eu/streetstore Cheers! streetsoul.eu ----------------------------------------------------------------------------------------------------------------------------------------------------------- streetsoul brands: 667 | Adidas Originals | Airbag | ALAKAZAM! | Alprausch | Amos | BICO | Creative Recreation | Emily The Strange | Encore | Five Four | Goorin Brothers | gsus | Irie Daily | King Apparel | Levi's Engineered Jeans? | Levi's? | Mazine | My Zoo | Nike | OAKLEY | pa:nuu | Reebok | Saddler | Schlepp | Streetsoul | Stussy | Sweet & Toxic | T.U.K. * To no longer receive these messages, please send a blank email to unsubscribe@streetsoul.eu From petefrench at ticketswitch.com Thu May 8 11:37:02 2008 From: petefrench at ticketswitch.com (Pete French) Date: Thu May 8 11:37:06 2008 Subject: Dreadful gmirror performance - suggested changes to 'prefer' Message-ID: I am just looking at this again, and am in a bit of a mood for writing some patches, so I wanted to run the following idea past people as regards the priority system in the 'prefer' balancing method. Just to recap, creating a gmirror creates the first device with priority zero. Adding extra devices lets you set their priorities, but you cant set negative values. The upshot is that the first device in the mirror always has the lowest priority - so you cannot (for example) create a mirror with a local disc, subsequently add a remote disc, but then set the mirror up to prefer the local drive. I am thinking of a couple of changes - the first being the patch prroposed from Andrew Snow which would create the mirror with the priority at something other than zero (128 would be my preference) so that extra devices can be inserted both above and below it. This solves the problem for newly created mirrors as the priority can then be set as appropiate. The other change I wanted to make was to add a second 'prefer' mode to gmirror though - one which would prefer the *lowest* priority instead of the highest priority. I would probably rename the existing mode to 'prefer-high' (keeping 'prefer' as a synonym for backward compatibility) and add a 'prefer-low' as well. As an existing gmirror can have it's load balance algorithm changed on the fly, this lets you change which of the drives is preferred in an existing installationg. This is precisely what you need when switching between two machines so that the local and remote drives become reversed. I havent looked at the code in detail, but I can't see that it would be too difficult. What do people think ? -pete. From ivoras at freebsd.org Thu May 8 12:41:55 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu May 8 12:42:01 2008 Subject: Dreadful gmirror performance - suggested changes to 'prefer' In-Reply-To: References: Message-ID: Pete French wrote: > I am just looking at this again, and am in a bit of a mood > for writing some patches, so I wanted to run the following idea past people > as regards the priority system in the 'prefer' balancing method. > > Just to recap, creating a gmirror creates the first device with priority > zero. Adding extra devices lets you set their priorities, but you cant > set negative values. The upshot is that the first device in the mirror > always has the lowest priority - so you cannot (for example) create a mirror > with a local disc, subsequently add a remote disc, but then set the mirror > up to prefer the local drive. Ok. > I am thinking of a couple of changes - the first being the patch prroposed > from Andrew Snow which would create the mirror with the priority at something > other than zero (128 would be my preference) so that extra devices can be > inserted both above and below it. This solves the problem for newly > created mirrors as the priority can then be set as appropiate. > > The other change I wanted to make was to add a second 'prefer' mode to gmirror > though - one which would prefer the *lowest* priority instead of the > highest priority. I would probably rename the existing mode to 'prefer-high' > (keeping 'prefer' as a synonym for backward compatibility) and add > a 'prefer-low' as well. As an existing gmirror can have it's load balance > algorithm changed on the fly, this lets you change which of the drives > is preferred in an existing installationg. This is precisely what you need > when switching between two machines so that the local and remote drives > become reversed. > > I havent looked at the code in detail, but I can't see that it would be too > difficult. What do people think ? Couple of ideas: - Don't use "128" as the default since it will lead people to think there's an 8-bit quantity behind the setting (and subsequently develop weird theories about how the setting works), when it isn't so. Use 100 or 1000. - Why not go all the way and make another argument or a switch that will specify exactly which drive to prefer, so you could say "prefer N", where N is any drive / component, not only the one with lowest/highest priority? This is slightly more complex and will probably require an addition to the metadata (which isn't complicated but you have to be careful) and a workaround so the old semantics of the "plain" setting is supported. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080508/18de25df/signature.pgp From petefrench at ticketswitch.com Thu May 8 13:18:25 2008 From: petefrench at ticketswitch.com (Pete French) Date: Thu May 8 13:18:31 2008 Subject: Dreadful gmirror performance - suggested changes to 'prefer' In-Reply-To: Message-ID: > Couple of ideas: > > - Don't use "128" as the default since it will lead people to think > there's an 8-bit quantity behind the setting (and subsequently develop > weird theories about how the setting works), when it isn't so. Use 100 > or 1000. Are you sure it isn't an 8 bit value underneath ? I know it is defined as an int, but trying to set it to anything outside the range 0-255 results in it wrapping round (e.g. you try making the defalt 1000 and it comes out as 232). I havent looked in detail as *why* thats happening, but it certainly behaves like it is 8 bits, hence my choice of default. > - Why not go all the way and make another argument or a switch that will > specify exactly which drive to prefer, so you could say "prefer N", > where N is any drive / component, not only the one with lowest/highest > priority? This is slightly more complex and will probably require an > addition to the metadata (which isn't complicated but you have to be > careful) and a workaround so the old semantics of the "plain" setting is > supported. I thought about that, but the priority scheme doesnt just specify one drive, it specifies a whole set - effectively you find the highest usable drive. Just defining one isn't sufficient, you need to have a defined way of falling back if that one isn't active. Secondly I want to avoid having to search the whole list event time. Currently the list of drives is created in priority order (no matter what the balance algorithm) so the 'prefer' algorithm simply traverses the list looking for the first active drive. I wanted to keep that and thus simply convert the list to a tailq so I can traverse it both ways, rather than having to seek the whole list every time. It keeps the code as close to the current code as possible. I'll get an initial version out and then maybe take a look at doing something more complex though. cheers, -pete. From ivoras at freebsd.org Thu May 8 13:37:54 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu May 8 13:38:01 2008 Subject: Dreadful gmirror performance - suggested changes to 'prefer' In-Reply-To: References: Message-ID: Pete French wrote: >> Couple of ideas: >> >> - Don't use "128" as the default since it will lead people to think >> there's an 8-bit quantity behind the setting (and subsequently develop >> weird theories about how the setting works), when it isn't so. Use 100 >> or 1000. > > Are you sure it isn't an 8 bit value underneath ? I know it is defined as > an int, but trying to set it to anything outside the range 0-255 results > in it wrapping round (e.g. you try making the defalt 1000 and it comes > out as 232). I havent looked in detail as *why* thats happening, but it > certainly behaves like it is 8 bits, hence my choice of default. Ah, I see; It's defined as u_int d_priority; /* Disk priority. */ in struct g_mirror_disk but as uint8_t md_priority; /* Disk priority. */ in struct g_mirror_metadata. Ok, 128 looks reasonable now. > I thought about that, but the priority scheme doesnt just specify one > drive, it specifies a whole set - effectively you find the highest usable > drive. Just defining one isn't sufficient, you need to have a defined > way of falling back if that one isn't active. Secondly I want to avoid > having to search the whole list event time. Currently the list of drives > is created in priority order (no matter what the balance algorithm) so > the 'prefer' algorithm simply traverses the list looking for the first > active drive. I wanted to keep that and thus simply convert the list to > a tailq so I can traverse it both ways, rather than having to seek the > whole list every time. It keeps the code as close to the current code > as possible. Hmm, it would seem you need "N-and-upper" and "N-and-lower", but this is inconvenient. Your original idea is probably better. > I'll get an initial version out and then maybe take a look at doing > something more complex though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080508/f89b189c/signature.pgp From petefrench at ticketswitch.com Thu May 8 14:15:47 2008 From: petefrench at ticketswitch.com (Pete French) Date: Thu May 8 14:15:49 2008 Subject: Dreadful gmirror performance - suggested changes to 'prefer' In-Reply-To: Message-ID: > Hmm, it would seem you need "N-and-upper" and "N-and-lower", but this is > inconvenient. Your original idea is probably better. Certainly simpler to implement. Ideally, of course, you could change the priority on the fly (which would solve all of this) but the fact that it is stored in priority order makes that a bit of a pain too I would imagine. Do you have any thoughts on dumping by the way ? I initially implemnted the code to chheck for 'prefer-low' and dump to the last disc instead of the first. But the manual page suggests ways of working with prefer which may well be broken doing it that way, so I took the change out in order to make the manpage advice still correct. I have a working implementation here now if anyone wants to test by the way - I ended up simply adding a 'prefer-low' and changing the default priority. Everything else behaves the same as it always did. -pete. From petefrench at ticketswitch.com Thu May 8 14:37:31 2008 From: petefrench at ticketswitch.com (Pete French) Date: Thu May 8 14:37:35 2008 Subject: Dreadful gmirror performance - suggested changes to 'prefer' In-Reply-To: Message-ID: O.K., heres an initial version of the patch - relative to 7.0 release. Please test and let me know if there are any problems. Patch should apply cleanly if you are in '/usr'. cheers, -pete. begin 644 gmirror.patch.gz M'XL("",/(T@"`V=M:7)R;W(N<&%T8V@`W3O[4]M(TC_+?\6$JRQV;($D/P!S MX5L6G,1U8/:,DTV^U%0DW'?+?N@4A%H>GJF M>_H]+"P`_X&YU^/S(1>B?` MBBS+^Z&6-$4YD96VK+:9IG:U=E?M'"GQ#ZLKJJ)4ZO7ZSEM`A*>(4#EE:@NP M=9O-%83??\_DUDGCA-7Y_]]_7V$5%D9&Y)C,G!D!ICPS4\T_[\?^PU M.P@7KA,=-)CI>Q-GN@SL_+#G>_;!>8+%\:*Y\4V/!*;0=4P;P%K*62>+(GXO MJ^<5N3C5\4([B/1%X``[HT<`4\XK]>U0JG9ZGB'HB^]8C-BCSPW'JX91L#0C M-C4C5P_LG]DK^*_!EE[H3#W;8A/7F(:U\]+YAADY7XS(+L4!A4$Y M'LRE&]8N!=M/^&!H5M2.KFJRI3#WM-I6N MEE=490?-SR)+M+[=5=2NTBK5>E5MH]K3`T7SJ!^QJSFI:85=!39(-S.$O(/H MC&8V\P,+1,N?@.+.%Z#G7A0R!_[!'T%D>%&#C6W30%$T4I##C"0"\-@(0;=\ MCSDP>>&'3N3X7D6&(S2"R/&F;!+X)QRG@QMPZ*U MH_)%7?\KKNGZAG64L#!>9.OLXI:!Y!P*&=!7ZEO1A'/#=?-XXJT$_M*SY,`' MJ:FP]W`NF1SKS/;`WOMP&L#L=(G(9R`'&=*X[2_1FL>0A#(6QX+'7#M< MT)2U<,([=D"R&I!7E,)ONK`NWX6F M?!&:NNN;8(GO/^HW=U=_ZUVCA0&K=]._'^EO[H:]RZMW533)#19/P+_"!K-T MS_X6H:FM2Z/+_LW?=P47!@S]$5A!]);LG__D9E^^L/3D-?^EAM"25Z^?<[?# MJ3KE.D^/[51]?&:R8CK0EX`_L(B"P(Z6@4>CM926UJG&PQ;^X*XU-,$Q)+SP M)Y%YOC=]P][MW8>>V*_8X'E"CA@MTI$'9E(L;[K]!91(-]'2N.G^^0D2AAD$ M+T@K'^-^-_N>#=[?W%`HT5;/P"35Z<&IG2X`0("CL![(Q M"ZQ%X#\F4#"+.VP>%_`HXC6C\^X/[T=Y@FOG%&>\B/<'D0S\;)M%8I%=0(C( M#BO4LRNLGR9$*18!'KZQ[UZS?[W5;_O#X=U0O^[?_TU_MQ2)4>V"K?<"@>Y\=S7HYY^>37J?^B141B#6WI(C4'[C.DXAO#1,QV+#'S* ML-X/[]]650C4K^TOF%.]#+N,(-EX.5]`0`1>_>7R"$)X@<>+)ZQS)Q.]3M87\I@?G=ZH7D3.W_64D M5",Y"<=R;9[*_@8L>['=5)F^!RG,TN;Z7R8J:)E>AH`YEID:FQO!`T@+Y/"F M:QL>"`PQI\G-'#V(.<2;\Q5N*)E7D"A&^E>(]'$`F0BN#A]_2H993@`)D&"8 MJFC-AMJ$E([_THF#WN-7O!3"?K+3$A2S0$4Q_0$=Q:QJX@204B6Y4)K:1C/( M+)/W5,CYZK@N`%#"B3X8TR9$QI.T0TKG#E?3SB.:WI^LR^UFSDI2:RZ#`&#< M1U1$V+YGFY%MB7W8M!7/CW`[QAB$021Q'!W2R(Q)!($A_AG88Q\@X9B<**:! M$"5XF>%9W'_,`M]S_@$O7#C'X(A=&1XN9_DL]"%FFB&U8SN"L?^A*M4OY@ED M^)S#EDV(9G"L1!!DJ1";+2*RI.;,-A\XYL,T7SY$(4#:#(M+!^2YF/US1'/8 M\L*8XEHNXS/"^+3Q8/U)NBNDFJC#E;\:/!DF+#SV`(!'9G]SPH@R9A(B`VL9 M(:33CCF#C;FP'Q(7VLP1'#3AR,O0^E-=`W!%G3Z@FTB*K/J#'7BVR^E]58NW@-%Z MG/[`!/G"M;TIB-A%;I-)L;`F3$.;>QIX%H-&F,%>F>,%;0'^^EEW/`<2R)^7 M]M*N_1',)NR>5TE-%P1,!Q*JXX7(552UU:3*7ZM3<".L2E72@-?=,H=,!60^ M9'O6R@"K)R^(];\C%N7CD%5.):5PA4KA2<:`VA'8/Z=E<:H0GH$?:6.-\*S3 MT*BH_U2X8ZC("1)`L`3[K9-9J1:S$JXR[%5H8CT_E3TXJTK]/\;1P*L1=""S MVL9TE'*B=!38$R[G8$M>F8OS'V55.!I>4_40%<]"] M%\=)Z>H0:]:E)V:[X")6-Z`/>Q]ZP_M>^4:F\U]K2Q0"QWBR^:O0CE@C;3QK M'%>$X6N=\-JFVCJ-BYOH#-XXH-@&%5G(?^5*RZ+"+3R`L-YQ_2*7"EHW0:JBK^8LM0G*IHLCCB3$5'7H?LQV'O36_8Y89AK6F,$=8W8]'?]=^^ZW*= MVHRJP511QTI5;R/BF[N?=L.KY,E>R\/AW?O!-?S_0W^PAI7\1D?G-SHI`_A1 M=9ITQ==I)8I.82/W];W!W6WO%N-C#^-D#'AYL@F*@A=(DE#U<@G>4X3WEF$) MO2_(X'?96@UQ+(3T`:Q37L3C:7DFKLAZEZY!E!;=@RCMA#%3B!$7ONM/'_6E MAS<$U5I):4?)EG8@9%Y"``WFI/IR>?QR6<.ZS@+T/UO428[+XV3R$]J@BVEA M*(Z"?S=EH))`*AJ\3(Q/ZQ MTDKL:6K$GE8[:]1X^)*]4^+)14X^0T<*-"LWU^^Z6TBI,$BKLIE(>\> M<\MY\5?!B_B05\QL*BX'5TF5I%#S&P?^@^V!/CPX"RSS442H MSI^5D>0FX/F%I'`9<2%V)\0EV5@Y>$YP3H3@G#8SU!_3S6C`6ZVR)@%>+PKA M_&])-X2J.<)S<6FY92&JZ090:ZI*:C5+BL?O>8>+55)"-D)(?P[(=*+E,&';U[G+PMG==%?5DJ1"[9=B#A\E9U+O]5XLZ6M,VD;1CV&*V^& MR?=KY!9Y2CW;(FVZDHM$7[X9]89K:R4<>)IW9UIVH^0I$S@ M_U!#\4Y(.+/U%BKGV+@>QQK842C8ZJCI!P1;.J92(T6!B"P_BWW:H=&+LT\< M*C5,JA1,G6JM+96"\)O^C?^5;3-,^OUBBRZ<1"8)ZGWH7_5$3UKO?C2\^U3C M[>K8;T$M7^N-$F<$@FPP,6G::I@!A)6(F!GFU_17&W\EB1:U8DJ_J?7-CWP& MUCGFQTF+^)%F\YGZD%@YL*=+U\"S=XU'VZJ=ET(YWL1UIK-HS3#/D5,,7-S]WZDW_Z(25.L-&JW"3I%;61=WK^A26A+H009V%0Z7`Z;RDDBA[@ZR>^+ MM'Y04K^[,CR\3#I?_%LB<0,J>2B[>+_;N!U`+/RDD]:YRQ>EN)&XU7)I1<'4CJ!CB\ MII$D;0/$_8\W_9$D-2OR6A"Z_Y!@E_4M,/SR91>XF[N?I/:&7=T"7:MO!W># MWH9]WEY^E-:MN&%+FZ;A1C'J69EI?BP=+^JT]$AB(C4]Q\M0D$3^O97ATM>-1U096H+WBB0$I3HD@F*;W6&( MA3J;^II8_UJ`E^4@EE]&0L!Z/AIVIN>DTXD]2; M;P1B3^K<(C[ER0+^(@ETRVT!SU3.5,.DL+8^2<3-]UG1!)Y*UI(GY) MQ\55F^!63`5/U1JLL,/8L*>$<+BT$6`M?'(,26#,SV%`WW/Z$U$>67\$V`3" MV\K/!<&:B,V5I%3.NS]IB;0K-+\T?Q52^I@A(+-Q[J'XSBDL6B65WF^C(I"2TIB*(H"6TN&?_RBG\0+$Z4SGT MTGOP_*\>UCF?8C%I\>0&O.?)'XF7ORXK!7\D;*'"]NK=8RC=C-PMWST2R&ZQ M%,'^5^*I%%424S7Q<^-V^3>0)[RB?I)V1^[T)9WX0#'PS/FB2O'RP;%E?SF& MY*DM[O90$G"(U5^S]O/>V2;-;;E*3JZN6P:>>I1T(MT[B-M(+74I\2V+DI04 MGIZ'1)\[W])+ECUOJG?[A@ZV=T73A4T^5>B3S/0*9JI/`ILJ1N(+J/2#A5^? M*]LK/D_T,0#NOD-ML?001YF3BZ>5PE6VV)WI[Y#5VN^JH(6E*5&J*A2G_@TF '>\7K!44````` ` end From andrew at modulus.org Thu May 8 14:53:13 2008 From: andrew at modulus.org (Andrew Snow) Date: Thu May 8 14:53:18 2008 Subject: Dreadful gmirror performance - suggested changes to 'prefer' In-Reply-To: References: Message-ID: <482313CE.8000805@modulus.org> > I havent looked at the code in detail, but I can't see that it would be too > difficult. What do people think ? If the first drive is always priority=0, then it is going to be stuck at the highest priority, or under your plan, the lower priority. My original idea OTOH (starting the counting at 100) solves the problem with aone-line patch. Call me biased but this is what I prefer :-) - Andrew From mi at symbion.zaytman.com Thu May 8 17:40:41 2008 From: mi at symbion.zaytman.com (Mikhail Teterin) Date: Thu May 8 17:40:45 2008 Subject: panic dd-ing from a USB "disk" Message-ID: <200805081730.m48HUNjh001532@symbion.zaytman.com> Hello! I had some troubles mounting the filesystem from: da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 3886MB (7959552 512 byte sectors: 255H 63S/T 495C) and decided to just dd the entire da0 to a file, so that the camera can be disconnected: dd if=/dev/da0 of=/home/mi/da0.dd bs=16384 The dd-ing was proceeding slowly (600Kb/s) and I stopped watching it... The machine paniced about an hour later (at 0:52). The timestamp on /home/mi/da0.dd was 23:45, it was only about 500Mb in size. The stack is below. Would anybody like to look at the complete vmcore dump? The hardware is a quad Opteron with 8Gb RAM. Only 4Gb of these are used, because it runs 7.x/i386 from April 5th (without PAE) -- for the sake of NVidia's card. Please, advise. Thanks! -mi [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". There is no member named pathname. Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /opt/modules/fuse.ko...done. Loaded symbols for /opt/modules/fuse.ko Unread portion of the kernel message buffer: umass0: at uhub0 port 6 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc0449702 stack pointer = 0x28:0xeb74b8bc frame pointer = 0x28:0xeb74b8dc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13989 (dd) trap number = 12 panic: page fault cpuid = 3 Uptime: 12d10h52m16s (da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x34, scsi status == 0xc8 Physical memory: 3054 MB Dumping 334 MB: (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) #0 doadump () at pcpu.h:195 #1 0xc0599f7b in boot (howto=260) at /ibm/src/sys/kern/kern_shutdown.c:418 #2 0xc059a449 in panic (fmt=0x104
) at /ibm/src/sys/kern/kern_shutdown.c:572 #3 0xc077f60d in trap_fatal (frame=0xeb74b87c, eva=40) at /ibm/src/sys/i386/i386/trap.c:899 #4 0xc077f9aa in trap_pfault (frame=0xeb74b87c, usermode=0, eva=0) at /ibm/src/sys/i386/i386/trap.c:812 #5 0xc078035c in trap (frame=0xeb74b87c) at /ibm/src/sys/i386/i386/trap.c:490 #6 0xc076637b in calltrap () at /ibm/src/sys/i386/i386/exception.s:139 #7 0xc0449702 in xpt_done (done_ccb=0xc690a000) at /ibm/src/sys/cam/cam_xpt.c:4856 #8 0xc044b15c in xpt_action (start_ccb=0xc690a000) at /ibm/src/sys/cam/cam_xpt.c:3057 #9 0xc04462b6 in cam_periph_runccb (ccb=0xc690a000, error_routine=0, camflags=CAM_FLAG_NONE, sense_flags=1, ds=0xc6aea690) at /ibm/src/sys/cam/cam_periph.c:878 #10 0xc0453aa1 in daclose (dp=0xcc862600) at /ibm/src/sys/cam/scsi/scsi_da.c:714 #11 0xc0549b2e in g_disk_access (pp=0xc7e12680, r=0, w=0, e=Variable "e" is not available.) at /ibm/src/sys/geom/geom_disk.c:152 #12 0xc054ec4d in g_access (cp=0xc8a90380, dcr=-1, dcw=0, dce=0) at /ibm/src/sys/geom/geom_subr.c:748 #13 0xc05490f3 in g_dev_close (dev=0xca1dad00, flags=Variable "flags" is not available.) at /ibm/src/sys/geom/geom_dev.c:217 #14 0xc0531f69 in devfs_close (ap=0xeb74ba94) at /ibm/src/sys/fs/devfs/devfs_vnops.c:372 #15 0xc0623e86 in vn_close (vp=0xcc8c1dd0, flags=1, file_cred=0xca36e700, td=0xc8552000) at vnode_if.h:228 #16 0xc0623f37 in vn_closefile (fp=0xca19bdc8, td=0xc8552000) at /ibm/src/sys/kern/vfs_vnops.c:868 #17 0xc0568b14 in fdrop (fp=0xca19bdc8, td=0xc8552000) at file.h:297 #18 0xc056a3c2 in closef (fp=0xca19bdc8, td=0xc8552000) at /ibm/src/sys/kern/kern_descrip.c:1958 #19 0xc056b371 in fdfree (td=0xc8552000) at /ibm/src/sys/kern/kern_descrip.c:1668 #20 0xc05775fa in exit1 (td=0xc8552000, rv=256) at /ibm/src/sys/kern/kern_exit.c:272 #21 0xc0578e1d in sys_exit (td=Could not find the frame base for "sys_exit". ) at /ibm/src/sys/kern/kern_exit.c:98 #22 0xc077fb90 in syscall (frame=0xeb74bd38) at /ibm/src/sys/i386/i386/trap.c:1035 #23 0xc07663e0 in Xint0x80_syscall () at /ibm/src/sys/i386/i386/exception.s:196 #24 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From delphij at delphij.net Thu May 8 20:59:11 2008 From: delphij at delphij.net (Xin LI) Date: Thu May 8 20:59:16 2008 Subject: amd64/123495: 7.0 AMD64 doesn't install on a Dell SC1435 In-Reply-To: References: <200805071621.m47GLbCD018315@www.freebsd.org> <48221188.3020708@wenks.ch> Message-ID: <48236995.4060707@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Randy, Randy Schultz wrote: | On Wed, 7 May 2008, Fabian Wenk spaketh thusly: | | -}Hello Randy | -} | -}On 07.05.08 18:21, Randy Schultz wrote: | -}> FBSD 6.x AMD64 works great on this system, as does centos linux. | -}> When I try to install 7.0 (AMD64 of course), on boot (off the | -}> cdrom) I notice: | -}> ad4: DMA limited to UDMA33, device found non-ATA66 cable | -}> | -}> Not sure if that is an important clue but it seems to be. I | -}> know my cables are SATA-II, FWIW. | -} | -}Somewhere in the BIOS settings should be an option to switch the SATA disks to | -}AHCI, maybe this helps. | -} | -}On most BIOS this setting is in the P-ATA mode, which is a slower | -}compatibility mode and is needed for the Redmond OS to work. | | Hey Fabian, | | Tnx for the tip. Unfortunately there is no such setting on this system. My | choices are "OFF" or "AUTO". In auto mode they appear to be correctly | identified, giving the make and model #. Could you please show your 'pciconf -lv | grep -A3 ata' output? My 1435 says: atapci1@pci0:2:1: class=0x01018a card=0x01eb1028 chip=0x02141166 rev=0x00 hdr=0x00 ~ vendor = 'ServerWorks (Was: Reliance Computer Corp)' ~ class = mass storage ~ subclass = ATA - -- atapci0@pci3:14:0: class=0x01018f card=0x01eb1028 chip=0x024b1166 rev=0x00 hdr=0x00 ~ vendor = 'ServerWorks (Was: Reliance Computer Corp)' ~ class = mass storage ~ subclass = ATA But it's an SC1435 with SAS disks I believe, so things may different. Also, will it be possible if you find some output from vmstat -i? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkgjaZUACgkQi+vbBBjt66CfogCfQvmKaLUmzw/ua4YMjRZlrCOj 2+MAoJbt2l3vRlhRY2qPU+WA7F6qcGZ3 =oEqd -----END PGP SIGNATURE----- From saper at system.pl Thu May 8 22:31:18 2008 From: saper at system.pl (Marcin Cieslak) Date: Thu May 8 22:31:24 2008 Subject: Toshiba PMCIA floppy fdc0: does not respond on pcmcia(4) with 7.0-STABLE Message-ID: Hello, I have tried to plug a Toshiba PCMCIA floppy drive (PA2612U) on to the 7.0-STABLE and I got "fdc0: does not respond": ACPI set debug layer 'ACPI_HARDWARE' level 'ACPI_LV_ALL_EXCEPTIONS' Copyright (c) 1992-2008 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 7.0-STABLE #5: Thu May 8 23:14:51 CEST 2008 saper@radziecki.saper.info:/usr/obj/usr/src/sys/VAIO Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (1833.48-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f2 Stepping = 2 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 2122555392 (2024 MB) avail memory = 2046763008 (1951 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard hwacpi-0182 [05] HwSetMode : Attempting to enable ACPI mode hwacpi-0218 [05] HwSetMode : Mode 1 successfully enabled acpi0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 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 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xf8300000-0xf837ffff,0xd0000000-0xdfffffff,0xf8400000-0xf843ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M acpi_video0: on vgapci0 vgapci1: mem 0xf8380000-0xf83fffff at device 2.1 on pci0 pcm0: mem 0xf8440000-0xf8443fff irq 21 at device 27.0 on pci0 pcm0: [ITHREAD] pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci6: on pcib2 wpi0: mem 0xf8100000-0xf8100fff irq 17 at device 0.0 on pci6 wpi0: Ethernet address: 00:1b:77:bc:a5:44 wpi0: [ITHREAD] pcib3: irq 18 at device 28.2 on pci0 pci7: on pcib3 mskc0: port 0x3000-0x30ff mem 0xf8000000-0xf8003fff irq 18 at device 0.0 on pci7 msk0: on mskc0 msk0: Ethernet address: 00:1a:80:55:25:5e miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto mskc0: [FILTER] pcib4: irq 19 at device 28.3 on pci0 pci8: on pcib4 uhci0: port 0x1820-0x183f irq 19 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] uhci0: LegSup = 0x003b usb0: on uhci0 usb0: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] uhci1: LegSup = 0x0010 usb1: on uhci1 usb1: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 19 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] uhci2: LegSup = 0x0010 usb2: on uhci2 usb2: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 19 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] uhci3: LegSup = 0x0010 usb3: on uhci3 usb3: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xf8644000-0xf86443ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered uhub5: on uhub4 uhub5: single transaction translator uhub5: 4 ports with 0 removable, self powered ehci_activate_qh: unexpected next ptr QH(0xffffffffd6679f00) at 0x034f9f00: sqtd=0xffffffffd667ae00 inactivesqtd=0xffffffffd667af80 link=0x034ed282 endp=0x80012102 addr=0x02 inact=0 endpt=1 eps=2 dtc=0 hrecl=0 mpl=0x1 ctl=0 nrl=8 endphub=0x41811c01 smask=0x01 cmask=0x1c huba=0x01 port=3 mult=1 curqtd=0x00000001 Overlay qTD: next=0x034faf80<> altnext=0x00000001 status=0x00000000: toggle=0 bytes=0x0 ioc=0 c_page=0x0 cerr=0 pid=0 stat=0x0 buffer[0]=0x00000000 buffer[1]=0x00000000 buffer[2]=0x00000000 buffer[3]=0x00000000 buffer[4]=0x00000000 QTD(0xffffffffd667ae00) at 0x034fae00: next=0x034faf80<> altnext=0x034faf80<> status=0x00018d00: toggle=0 bytes=0x1 ioc=1 c_page=0x0 cerr=3 pid=1 stat=0x0 buffer[0]=0x0350b418 buffer[1]=0x00000000 buffer[2]=0x00000000 buffer[3]=0x00000000 buffer[4]=0x00000000 QTD(0xffffffffd667af80) at 0x034faf80: next=0x00000001 altnext=0x00000001 status=0x00000000: toggle=0 bytes=0x0 ioc=0 c_page=0x0 cerr=0 pid=0 stat=0x0 buffer[0]=0x00000000 buffer[1]=0x00000000 buffer[2]=0x00000000 buffer[3]=0x00000000 buffer[4]=0x00000000 ucardman0: on uhub5 ucardman attach: sc = 0xffffff0003538000 umass0: on uhub5 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 uscanner0: on uhub5 umass1: on uhub4 umass1: SCSI over Bulk-Only; quirks = 0x0000 umass1:1:1:-1: Attached to scbus1 ugen0: on uhub4 pcib5: at device 30.0 on pci0 pci9: on pcib5 cbb0: at device 4.0 on pci9 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: <1394 Open Host Controller Interface> mem 0xf8205000-0xf82057ff,0xf8200000-0xf8203fff irq 21 at device 4.1 on pci9 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 08:00:46:03:02:91:b4:4d fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7b7e8000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 0a:00:46:91:b4:4d fwe0: Ethernet address: 0a:00:46:91:b4:4d fwip0: on firewire0 fwip0: Firewire address: 08:00:46:03:02:91:b4:4d @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode pci9: at device 4.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xf8644400-0xf86447ff irq 22 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: port not implemented ata5: [ITHREAD] ichsmb0: port 0x18e0-0x18ff at device 31.3 on pci0 ichsmb0: can't get IRQ device_attach: ichsmb0 attach returned 6 acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 acpi_sony0: on acpi0 acpi_sony0: PID 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 orm0: at iomem 0xc0000-0xcffff,0xdc000-0xdffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ums0: on uhub0 ums0: 8 buttons and Z dir. ubt0: on uhub3 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ZFS filesystem version 6 ZFS storage pool version 6 acd0: DVDR at ata0-master UDMA33 ad4: 114473MB at ata2-master SATA150 CIS is too long -- truncating pccard0: Allocation failed for cfe 1 pccard0: Allocation failed for cfe 2 pccard0: Allocation failed for cfe 3 pccard0: (manufacturer=0xffffffff, product=0xffffffff, function_type=-1) at function 0 pccard0: CIS info: Y-E DATA, External FDD, Controller, 2.00 pcm0: pcm0: GEOM_LABEL: Label for provider acd0 is iso9660/DoerteKopie. GEOM_LABEL: Label for provider ad4s1 is ntfs/Recovery. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [1085232 x 2048 byte records] da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da4 at umass-sim1 bus 1 target 0 lun 0 da4: Removable Direct Access SCSI-0 device da4: 40.000MB/s transfers da4: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from zfs:tank can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND Status is 0x30000510 cbb0: card inserted: event=0x00000000, state=30000510 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: 5V pccard0: read_cis cis mem map 0xd9deb000 (resource: 0xf8210000) pccard0: CIS tuple chain: CISTPL_DEVICE type=funcspec speed=100ns 01 02 dc ff CISTPL_VERS_1 15 29 04 01 59 2d 45 20 44 41 54 41 00 45 78 74 65 72 6e 61 6c 20 46 44 44 00 43 6f 6e 74 72 6f 6c 6c 65 72 00 32 2e 30 30 00 ff unhandled CISTPL 14 CISTPL_NO_LINK 14 00 CISTPL_CONFIG 1a 06 01 22 f0 07 0f ff CISTPL_CFTABLE_ENTRY 1b 11 c1 51 19 11 55 4d 5d 06 06 06 a0 20 07 30 ff ff ff CISTPL_CFTABLE_ENTRY 1b 08 02 08 aa 60 c8 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 03 08 aa 60 c0 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 04 08 aa 60 a8 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 05 08 aa 60 a0 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 06 08 aa 60 88 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 07 08 aa 60 80 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 08 08 aa 60 68 03 07 ff unhandled CISTPL 4c 4c 1b 08 09 08 aa 60 60 03 07 ff 1b 08 0a 08 aa 60 48 03 07 ff 1b 08 0b 08 aa 60 40 03 unhandled CISTPL 7 07 ff 1b 08 0c 08 aa 60 28 03 07 ff 1b 08 0d 08 aa 60 20 03 07 ff 1b 08 0e 08 aa 60 08 03 07 ff 1b 08 0f 08 aa 60 00 03 07 ff 1b 08 10 08 aa 60 e8 02 07 ff 1b 08 11 08 aa 60 e0 02 07 ff 1b 08 12 08 aa 60 c8 02 07 ff 1b 08 13 08 aa 60 c0 02 07 ff 1b 08 14 08 aa 60 a8 02 07 ff 1b 08 15 08 aa 60 a0 02 07 ff 1b 08 16 08 aa 60 88 02 07 ff 1b 08 17 08 aa 60 80 02 07 ff 1b 08 18 08 aa 60 68 02 07 ff 1b 08 19 08 aa 60 60 02 07 ff 1b 08 1a 08 aa 60 48 02 07 ff 1b 08 1b 08 aa 60 40 02 07 ff 1b 08 1c 08 aa 60 28 02 07 ff 1b 08 1d 08 aa 60 20 02 07 ff 1b 08 1e 08 aa 60 08 02 07 ff 1b 08 1f 08 aa 60 00 02 07 ff 1b 13 61 18 aa 60 f8 03 07 26 ff 48 4f 53 54 5f 44 4d 41 00 ff 1b 12 22 08 aa 60 70 03 07 ff 48 4f 53 54 5f 44 4d 41 00 ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 TOO MANY CIS_NONE unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 40 40 20 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 CIS is too long -- truncating CISTPL_END ff pccard0: check_cis_quirks pccard0: CIS version PCCARD 2.0 or 2.1 pccard0: CIS info: Y-E DATA, External FDD, Controller, 2.00 pccard0: Manufacturer code 0xffffffff, product 0xffffffff pccard0: function 0: unspecified, ccr addr 7f0 mask f pccard0: function 0, config table entry 1: I/O card; irq mask 40; iomask 1d, iospace 0-1fffffff; rdybsy_active bvd_active io16 pccard0: function 0, config table entry 2: I/O card; irq mask 40; iomask a, iospace 3c8-3cf; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 3: I/O card; irq mask 40; iomask a, iospace 3c0-3c7; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 4: I/O card; irq mask 40; iomask a, iospace 3a8-3af; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 5: I/O card; irq mask 40; iomask a, iospace 3a0-3a7; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 6: I/O card; irq mask 40; iomask a, iospace 388-38f; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 7: I/O card; irq mask 40; iomask a, iospace 380-387; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 8: I/O card; irq mask 40; iomask a, iospace 368-36f; rdybsy_active bvd_active io8 pccard0: functions scanning pccard0: Card has 1 functions. pccard_mfc is 0 pccard0: I/O rid 0 start 0 end ffffffffffffffff pccard0: Allocation failed for cfe 1 pccard0: I/O rid 0 start 3c8 end 3cf pccard0: Allocation failed for cfe 2 pccard0: I/O rid 0 start 3c0 end 3c7 pccard0: Allocation failed for cfe 3 pccard0: I/O rid 0 start 3a8 end 3af cbb_pcic_socket_enable: pccard0: ccr_res == f8207000-f82073ff, base=7f0 pccard0: function 0 CCR at 0 offset 7f0: 44 20 e 0, 0 0 0 0, 0 fdc0: at port 0x3a8-0x3af irq 20 function 0 config 4 on pccard0 fdc0: does not respond device_attach: fdc0 attach returned 6 file revisions: fdc.c: $FreeBSD: src/sys/dev/fdc/fdc.c,v 1.317.2.1 2008/01/18 09:39:35 kib Exp $ fdc_acpi.c: $FreeBSD: src/sys/dev/fdc/fdc_acpi.c,v 1.12 2006/02/21 03:19:24 njl Exp $ fdc_isa.c: $FreeBSD: src/sys/dev/fdc/fdc_isa.c,v 1.22 2005/03/15 08:02:47 imp Exp $ fdc_pccard.c: $FreeBSD: src/sys/dev/fdc/fdc_pccard.c,v 1.13 2005/06/24 14:36:52 imp Exp $ fdcvar.h: $FreeBSD: src/sys/dev/fdc/fdcvar.h,v 1.9 2005/01/19 07:46:38 imp Exp $ card_if.m: $FreeBSD: src/sys/dev/pccard/card_if.m,v 1.31 2005/09/25 01:39:04 imp Exp $ pccard.c: $NetBSD: pcmcia.c,v 1.23 2000/07/28 19:17:02 drochner Exp $ $FreeBSD: src/sys/dev/pccard/pccard.c,v 1.119 2007/06/16 23:33:57 imp Exp $ pccard_cis.c: $NetBSD: pcmcia_cis.c,v 1.17 2000/02/10 09:01:52 chopps Exp $ $FreeBSD: src/sys/dev/pccard/pccard_cis.c,v 1.40 2007/02/27 17:23:28 jhb Exp $ pccard_cis.h: $FreeBSD: src/sys/dev/pccard/pccard_cis.h,v 1.4 2005/07/13 14:59:06 imp Exp $ pccard_cis_quirks.c: $NetBSD: pcmcia_cis_quirks.c,v 1.6 2000/04/12 21:07:55 scw Exp $ $FreeBSD: src/sys/dev/pccard/pccard_cis_quirks.c,v 1.16.2.1 2007/10/30 10:17:11 remko Exp $ pccard_device.c: $FreeBSD: src/sys/dev/pccard/pccard_device.c,v 1.3 2005/09/21 20:08:24 imp Exp $ pccarddevs: $FreeBSD: src/sys/dev/pccard/pccarddevs,v 1.129.2.1 2007/10/30 10:17:11 remko Exp $ $NetBSD: pcmciadevs,v 1.186 2003/09/16 08:26:37 onoe Exp $ $OpenBSD: pcmciadevs,v 1.93 2002/06/21 08:31:10 henning Exp $ pccardreg.h: $NetBSD: pcmciareg.h,v 1.7 1998/10/29 09:45:52 enami Exp $ $FreeBSD: src/sys/dev/pccard/pccardreg.h,v 1.3 2005/01/06 01:43:03 imp Exp $ pccardvar.h: $NetBSD: pcmciavar.h,v 1.12 2000/02/08 12:51:31 enami Exp $ $FreeBSD: src/sys/dev/pccard/pccardvar.h,v 1.61 2005/09/25 01:38:02 imp Exp $ pccardvarp.h: $FreeBSD: src/sys/dev/pccard/pccardvarp.h,v 1.4 2007/05/31 19:29:20 piso Exp $ power_if.m: $FreeBSD: src/sys/dev/pccard/power_if.m,v 1.4 2005/01/06 01:43:03 imp Exp $ Any hints? --Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080508/b59fb016/signature.pgp From jcw at highperformance.net Fri May 9 03:34:28 2008 From: jcw at highperformance.net (Jason C. Wells) Date: Fri May 9 03:35:10 2008 Subject: Release Schedule 7.1 Message-ID: <4823BFF7.6060106@highperformance.net> What are the hoped for release dates for 7.1? (plus or minus a month) I'm debating on running 7.0 vs 7.1 and timing is a consideration. Regards, Jason From paul.koch at statseeker.com Fri May 9 06:07:28 2008 From: paul.koch at statseeker.com (Paul Koch) Date: Fri May 9 06:07:31 2008 Subject: flock incorrectly detects deadlock on 7-stable and current In-Reply-To: <1B6FCF23-413B-452A-B66D-3CCD6257F7BD@rabson.org> References: <200805081812.24692.paul.koch@statseeker.com> <1B6FCF23-413B-452A-B66D-3CCD6257F7BD@rabson.org> Message-ID: <200805091607.23035.paul.koch@statseeker.com> On Thu, 8 May 2008 06:37:00 pm Doug Rabson wrote: > On 8 May 2008, at 09:12, Paul Koch wrote: > > Hi, > > > > We have been trying to track down a problem with one of our apps > > which does a lot of flock(2) calls. flock returns errno 11 > > (Resource deadlock avoided) under certain scenarios. Our app works > > fine on 7-Release, but fails on 7-stable and -current. > > > > The problem appears to be when we have at least three processes > > doing flock() on a file, and one is trying to upgrade a shared lock > > to an exclusive lock but fails with a deadlock avoided. > > > > Attached is a simple flock() test program. > > > > a. Process 1 requests and gets a shared lock > > b. Process 2 requests and blocks for an exclusive lock > > c. Process 3 requests and gets a shared lock > > d. Process 3 requests an upgrade to an exclusive lock but fails > > (errno 11) > > > > If we change 'd' to > > Process 3 requests unlock, then requests exclusive lock, it > > works. > > Could you possibly try this patch and tell me if it helps: > > ==== //depot/user/dfr/lockd/sys/kern/kern_lockf.c#57 - > /tank/projects/ lockd/src/sys/kern/kern_lockf.c ==== > @@ -1370,6 +1370,18 @@ > } > > /* > + * For flock type locks, we must first remove > + * any shared locks that we hold before we sleep > + * waiting for an exclusive lock. > + */ > + if ((lock->lf_flags & F_FLOCK) && > + lock->lf_type == F_WRLCK) { > + lock->lf_type = F_UNLCK; > + lf_activate_lock(state, lock); > + lock->lf_type = F_WRLCK; > + } > + > + /* > * We are blocked. Create edges to each blocking lock, > * checking for deadlock using the owner graph. For > * simplicity, we run deadlock detection for all > @@ -1389,17 +1401,6 @@ > } > > /* > - * For flock type locks, we must first remove > - * any shared locks that we hold before we sleep > - * waiting for an exclusive lock. > - */ > - if ((lock->lf_flags & F_FLOCK) && > - lock->lf_type == F_WRLCK) { > - lock->lf_type = F_UNLCK; > - lf_activate_lock(state, lock); > - lock->lf_type = F_WRLCK; > - } > - /* > * We have added edges to everything that blocks > * us. Sleep until they all go away. > */ Manually applied the patch to stable kern_lockf.c 1.57.2.1. Ran the flock_test program on many of our architectures and it works fine. Have also been testing our app on a single core i386 machine today with no locking problems. Just setup a quad core -stable amd64 build and it also appears to be running fine now. Thanks Paul. From dfr at rabson.org Fri May 9 08:50:31 2008 From: dfr at rabson.org (Doug Rabson) Date: Fri May 9 08:50:34 2008 Subject: flock incorrectly detects deadlock on 7-stable and current In-Reply-To: <200805091607.23035.paul.koch@statseeker.com> References: <200805081812.24692.paul.koch@statseeker.com> <1B6FCF23-413B-452A-B66D-3CCD6257F7BD@rabson.org> <200805091607.23035.paul.koch@statseeker.com> Message-ID: <62B7297F-8795-456F-8611-40658DF327FB@rabson.org> On 9 May 2008, at 07:07, Paul Koch wrote: > On Thu, 8 May 2008 06:37:00 pm Doug Rabson wrote: >> >> >> Could you possibly try this patch and tell me if it helps: >> ... >> > Manually applied the patch to stable kern_lockf.c 1.57.2.1. Ran the > flock_test program on many of our architectures and it works fine. > > Have also been testing our app on a single core i386 machine today > with > no locking problems. Just setup a quad core -stable amd64 build and > it > also appears to be running fine now. Thanks for that. I'll get the patch committed to current today - it will turn up in 7-stable in a couple of days. From tevans.uk at googlemail.com Fri May 9 08:56:51 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri May 9 08:56:57 2008 Subject: Release Schedule 7.1 In-Reply-To: <4823BFF7.6060106@highperformance.net> References: <4823BFF7.6060106@highperformance.net> Message-ID: <1210323401.75986.3.camel@localhost> On Thu, 2008-05-08 at 20:07 -0700, Jason C. Wells wrote: > What are the hoped for release dates for 7.1? (plus or minus a month) > I'm debating on running 7.0 vs 7.1 and timing is a consideration. > > Regards, > Jason Scheduled releases are listed on the release engineering page. http://www.freebsd.org/releng/index.html You might notice there aren't any. RELENG_7 / 7-STABLE is as close as you will get to 7.1 for a long while. Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080509/21e6607f/attachment.pgp From schulra at earlham.edu Fri May 9 12:45:15 2008 From: schulra at earlham.edu (Randy Schultz) Date: Fri May 9 12:45:20 2008 Subject: amd64/123495: 7.0 AMD64 doesn't install on a Dell SC1435 In-Reply-To: <48236995.4060707@delphij.net> References: <200805071621.m47GLbCD018315@www.freebsd.org> <48221188.3020708@wenks.ch> <48236995.4060707@delphij.net> Message-ID: On Thu, 8 May 2008, Xin LI spaketh thusly: -}Could you please show your 'pciconf -lv | grep -A3 ata' output? -} -}My 1435 says: -} -}atapci1@pci0:2:1: class=0x01018a card=0x01eb1028 chip=0x02141166 -}rev=0x00 hdr=0x00 -}~ vendor = 'ServerWorks (Was: Reliance Computer Corp)' -}~ class = mass storage -}~ subclass = ATA -}- -- -}atapci0@pci3:14:0: class=0x01018f card=0x01eb1028 chip=0x024b1166 -}rev=0x00 hdr=0x00 -}~ vendor = 'ServerWorks (Was: Reliance Computer Corp)' -}~ class = mass storage -}~ subclass = ATA -} -}But it's an SC1435 with SAS disks I believe, so things may different. -}Also, will it be possible if you find some output from vmstat -i? Certainly. The system is up on 6.3 right now so this is simple. ;> Dude ? pciconf -lv | grep -A3 ata atapci1@pci0:2:1: class=0x01018a card=0x01eb1028 chip=0x02141166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'HT1000 Legacy IDE controller' class = mass storage -- atapci0@pci3:14:0: class=0x01018f card=0x01eb1028 chip=0x024b1166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5785 (HT1000) PATA/IDE Mode' class = mass storage I had the SAS card in it but I needed to pull it because I needed to put a SCSI card in for the autochanger(testing fbsd with bacula). Here's the vmstat output: Dude ? vmstat -i interrupt total rate irq1: atkbd0 18 0 irq6: atapci0 1543 0 irq9: acpi0 2 0 irq11: ohci0 ohci+ 12 0 irq14: ata0 47 0 irq33: bge0 14935 7 irq38: ahc0 138 0 irq39: ahc1 23 0 cpu0: timer 4127540 1998 Total 4144258 2006 I wasn't aware of the pciconf command. It's kinda cool. Now I'm wondering if I can use it to write the proper data to the configuration register telling it to not be in PATA mode. OTOH, the potential to do improper things seems great so this is a bit scary. I wonder if the dell is feeding bogus data to fbsd 7, or fbsd 7 is misinterpreting what it's getting from the dell? -- Randy (schulra@earlham.edu) 765.983.1283 <*> Love with your heart, think with your head; not the other way around. From ari at ish.com.au Sat May 10 02:53:21 2008 From: ari at ish.com.au (Aristedes Maniatis) Date: Sat May 10 02:53:26 2008 Subject: LOR on sleepqueue chain locks, Was: LOR sleepq/scrlock In-Reply-To: <200804221334.35001.jhb@freebsd.org> References: <77E81AD6-FBCC-4D30-A5CB-A9B918D4793F@ish.com.au> <200804181314.24974.jhb@freebsd.org> <200804221334.35001.jhb@freebsd.org> Message-ID: <0DB3A235-DF87-4413-90ED-E38BC44CA2B3@ish.com.au> On 23/04/2008, at 3:34 AM, John Baldwin wrote: >>> The >>> real problem at the bottom of the screen though is a real issue. >>> It's a LOR >>> of two different sleepqueue chain locks. The problem is that when >>> setrunnable() encounters a swapped out thread it tries to wakeup >>> proc0, but >>> if proc0 is asleep (which is typical) then its thread lock is a >>> sleep queue >>> chain lock, so waking up a swapped out thread from wakeup() will >>> usually >>> trigger this LOR. >>> >>> I think the best fix is to not have setrunnable() kick proc0 >>> directly. >>> Perhaps setrunnable() should return an int and return true if proc0 >>> needs to >>> be awakened and false otherwise. Then the the sleepq code (b/c only >>> sleeping >>> threads can be swapped out anyway) can return that value from >>> sleepq_resume_thread() and can call kick_proc0() directly once it >>> has dropped >>> all of its own locks. >>> >>> -- >>> John Baldwin >> >> The way you describe it, it almost sounds like this LOR should be >> happening for everyone, all the time. To try and eliminate the >> factors >> which trigger it for us, we tried the following: removed PAE from >> kernel, disabled PF. Neither of these things made any difference and >> the error is fairly quickly reproducible (within a couple of hours >> running various things to load the machine). The one thing we did not >> test yet is removing ZFS from the picture. Note also that this box >> ran >> for years and years on FreeBSD 4.x without a hiccup (non PAE, ipfw >> instead of pf and no ZFS of course). > > There are two things. 1) Most people who run witness (that I know > of) don't > run it on spinlocks because of the overhead, so LORs of spin locks > are less > well-reported than LORs of other locks (mutexes, rwlocks, etc.). 2) > You have > to have enough load on the box to swap out active processes to get > into this > situation. Between those I think that is why this is not more widely > reported. Hi John, Thanks for your efforts so far to track this LOR down. I've been keeping an eye on cvs logs, but haven't seen anything which looks like a patch for this. * is this still outstanding? * or will it be addressed soon? * if not, should I create a PR so that it doesn't get forgotten? * in our case, although we can trigger it quickly with some load, the problem occurs (and causes a complete machine lock) even under < 10% load. Not sure if the combination of PAE/ZFS/SCHED ULE exacerbates that in any way compared to a 'standard' build. Thank you Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From stefan.lambrev at moneybookers.com Sat May 10 15:18:52 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Sat May 10 15:18:55 2008 Subject: /usr/bin/ksu and missing suid bit Message-ID: <4825BCD6.4080001@moneybookers.com> Greetings, What the reason /usr/bin/ksu to be without setuid bit? Are there any security concerns? I'm asking because the only way to get ksu working is adding by hand the suid bit. For example when you install heimdal from ports it activate the setuid bit on $prefix/bin/su. And my second question - is there a option that I can define in src.conf or make.conf, next time when I build/installworld ksu to have setuid bit ? (in manual I found only knobs for disabling kerberos) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From david at catwhisker.org Sat May 10 15:45:36 2008 From: david at catwhisker.org (David Wolfskill) Date: Sat May 10 15:45:40 2008 Subject: /usr/bin/ksu and missing suid bit In-Reply-To: <4825BCD6.4080001@moneybookers.com> References: <4825BCD6.4080001@moneybookers.com> Message-ID: <20080510153052.GX66703@bunrab.catwhisker.org> On Sat, May 10, 2008 at 06:18:46PM +0300, Stefan Lambrev wrote: > ... > And my second question - is there a option that I can define in src.conf > or make.conf, next time when I build/installworld > ksu to have setuid bit ? (in manual I found only knobs for disabling > kerberos) Define ENABLE_SUID_K5SU to be true. Ref. the stanza from /usr/share/examples/etc/make.conf: # Kerberos 5 su (k5su) # If you want to use the k5su utility, define this to have it installed # set-user-ID. #ENABLE_SUID_K5SU= Peace, david -- David H. Wolfskill david@catwhisker.org I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080510/a0d2e64c/attachment.pgp From joe at tao.org.uk Sun May 11 10:45:30 2008 From: joe at tao.org.uk (Dr Joe Karthauser) Date: Sun May 11 11:16:15 2008 Subject: cvsup.uk.FreeBSD.org In-Reply-To: <20080508073540.GA95771@keltia.freenix.fr> Message-ID: <20080511102730.DBD0A600F@mailhost.tao.org.uk> ------- Original message ------- From: Ollivier Robert Cc: freebsd-hubs@freebsd.org Sent: 8.5.'08, 8:35 > Stefan Lambrev disait : > > cvsup.uk.FreeBSD.org is outdated. > > I know this is not the proper list, but which one is? > > freebsd-hubs is, redirected. > > I've noticed that recently but I should have send a mail about it, sorry. > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr > Darwin sidhe.keltia.net Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; i386 > Hey guys. I have reclassified this faulty mirror as cvsup1 and made cvsup a cname to cvsup3, which is the most recent addition and best hardware available. In the future we will always point to the most available machine in this way. Joe From bms at incunabulum.net Sun May 11 12:51:01 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun May 11 12:51:11 2008 Subject: Automounting USB sticks - questions Message-ID: <4826E7C9.9030407@incunabulum.net> I got this working quite easily with the amd daemon. Thanks to Alfred for your excellent work on this. I wonder what the status of autofs is? It would be great if we could ship FreeBSD out of the box, ready to automount removable media. This would be useful to all users, but particularly for novices and people who just wanna get on and use the beast. Since the move to /media for a place to put removable mount points I'd imagine all of this gets a lot easier. However I can understand there are real issues with this: * /etc/amd.conf. We don't ship one in /etc by default. Maybe we should? * /etc/amd.map. We ship one which contains defaults and nothing more. Perhaps commented out examples? * There doesn't appear to be a tool to tell amd about new maps at runtime. Is there such a beast? UPDATE: I just read code, and it seems SIGHUP can be sent, but this isn't in the man page and I haven't tried it. * devd doesn't have any hooks into GEOM, which makes it difficult to generate mount lines without retroactively parsing dmesg output. devd as I understand it sits on top of NEWBUS. Is there any way I can get a list of the disk devices, from userland, in the default install, which correspond to a given NEWBUS device? * I wonder if there's any way we can get a notification about media being inserted into a CDROM drive, without polling it? I had a brief discussion online with phk@ about doing dynamic mounts, and it seems that there are still problems dealing with blowing away mounts when the device goes away. From ericlin at tamama.org Sun May 11 12:56:08 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Sun May 11 12:56:12 2008 Subject: TMPFS does not support unix socket file? Message-ID: <47713ee10805110528s1d2152cby3099d4ceda15864a@mail.gmail.com> Hi, I am trying to replace my /tmp to TMPFS. Everything is fine, but I found that MySQL does not run. The error log shows that it cannot bind /tmp/mysql.sock. Does TMPFS support unix socket file? From aragon at phat.za.net Sun May 11 14:28:39 2008 From: aragon at phat.za.net (Aragon Gouveia) Date: Sun May 11 14:28:44 2008 Subject: sound hosed on 7.0-STABLE/amd64 ? Message-ID: <20080511140022.GA6067@phat.za.net> Hi, I'm running an amd64 install of 7.0-STABLE. Sound is behaving strangely. I'm trying to get either uaudio or snd_hda working, but am not having joy with either. The kernel detects the devices, but /dev/dsp* entries aren't created or take a long time to appear. And, of course, sound playback doesn't work either. Kernel output attached. Anyone know what could be up? Thanks, Aragon May 11 15:31:49 igor kernel: uaudio0: on uhub4 May 11 15:31:49 igor kernel: uaudio0: audio rev 1.00 May 11 15:31:49 igor kernel: pcm0: on uaudio0 May 11 15:49:09 igor kernel: pcm1: mem 0xe0320000-0xe0323fff irq 22 at device 27.0 on pci0 May 11 15:49:09 igor kernel: pcm1: [ITHREAD] May 11 15:49:09 igor kernel: pcm1: May 11 15:49:09 igor kernel: pcm1: May 11 15:49:09 igor kernel: pcm2: mem 0xe0210000-0xe0213fff irq 17 at device 0.1 on pci1 May 11 15:49:09 igor kernel: pcm2: [ITHREAD] May 11 15:49:09 igor kernel: pcm2: May 11 15:49:09 igor kernel: pcm2: From pluknet at gmail.com Sun May 11 17:18:20 2008 From: pluknet at gmail.com (pluknet) Date: Sun May 11 17:18:24 2008 Subject: TMPFS does not support unix socket file? In-Reply-To: <47713ee10805110528s1d2152cby3099d4ceda15864a@mail.gmail.com> References: <47713ee10805110528s1d2152cby3099d4ceda15864a@mail.gmail.com> Message-ID: 2008/5/11 Lin Jui-Nan Eric : > Hi, > > I am trying to replace my /tmp to TMPFS. > Everything is fine, but I found that MySQL does not run. The error log > shows that it cannot bind /tmp/mysql.sock. > Does TMPFS support unix socket file? I've just checked tmpfs with unix with simple test case on my stable and it works. maybe permissions issue? wbr, pluknet From ericlin at tamama.org Sun May 11 17:27:05 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Sun May 11 17:27:09 2008 Subject: TMPFS does not support unix socket file? In-Reply-To: References: <47713ee10805110528s1d2152cby3099d4ceda15864a@mail.gmail.com> Message-ID: <47713ee10805111027h256286det6d20efcf78bf6e0c@mail.gmail.com> On Mon, May 12, 2008 at 1:18 AM, pluknet wrote: > 2008/5/11 Lin Jui-Nan Eric : >> Hi, >> >> I am trying to replace my /tmp to TMPFS. >> Everything is fine, but I found that MySQL does not run. The error log >> shows that it cannot bind /tmp/mysql.sock. >> Does TMPFS support unix socket file? > > I've just checked tmpfs with unix with simple test case on my stable > and it works. > maybe permissions issue? It's a permission issue! Thank you very much. From aragon at phat.za.net Sun May 11 18:30:30 2008 From: aragon at phat.za.net (Aragon Gouveia) Date: Sun May 11 18:30:33 2008 Subject: sound hosed on 7.0-STABLE/amd64 ? In-Reply-To: <20080511140022.GA6067@phat.za.net> References: <20080511140022.GA6067@phat.za.net> Message-ID: <20080511183028.GA24596@phat.za.net> Hi again, I guess I should have spent more time troubleshooting. Sound is working now. I spent the last 30 minutes testing it with 6.3-RELEASE and 7.0-RELEASE livecds on two different machines. Ended up tracing my uaudio dysfunctionality to a dodgy USB hub! Onboard HDA was just a matter of setting the right options in the BIOS. All's good on both fronts. Sorry for the false alarm. Regards, Aragon | By Aragon Gouveia | [ 2008-05-11 16:29 +0200 ] > Hi, > > I'm running an amd64 install of 7.0-STABLE. Sound is behaving strangely. > I'm trying to get either uaudio or snd_hda working, but am not having joy > with either. The kernel detects the devices, but /dev/dsp* entries aren't > created or take a long time to appear. And, of course, sound playback > doesn't work either. > > Kernel output attached. Anyone know what could be up? > > > Thanks, > Aragon > > > May 11 15:31:49 igor kernel: uaudio0: on uhub4 > May 11 15:31:49 igor kernel: uaudio0: audio rev 1.00 > May 11 15:31:49 igor kernel: pcm0: on uaudio0 > May 11 15:49:09 igor kernel: pcm1: mem 0xe0320000-0xe0323fff irq 22 at device 27.0 on pci0 > May 11 15:49:09 igor kernel: pcm1: [ITHREAD] > May 11 15:49:09 igor kernel: pcm1: > May 11 15:49:09 igor kernel: pcm1: > May 11 15:49:09 igor kernel: pcm2: mem 0xe0210000-0xe0213fff irq 17 at device 0.1 on pci1 > May 11 15:49:09 igor kernel: pcm2: [ITHREAD] > May 11 15:49:09 igor kernel: pcm2: > May 11 15:49:09 igor kernel: pcm2: > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From jhary at unsane.co.uk Sun May 11 20:10:43 2008 From: jhary at unsane.co.uk (Vince Hoffman) Date: Sun May 11 20:10:45 2008 Subject: Automounting USB sticks - questions In-Reply-To: <4826E7C9.9030407@incunabulum.net> References: <4826E7C9.9030407@incunabulum.net> Message-ID: <482752C0.8040401@unsane.co.uk> Bruce M Simpson wrote: > I got this working quite easily with the amd daemon. > Thanks to Alfred for your excellent work on this. I wonder what the > status of autofs is? > > It would be great if we could ship FreeBSD out of the box, ready to > automount removable media. This would be useful to all users, but > particularly for novices and people who just wanna get on and use the > beast. > > Since the move to /media for a place to put removable mount points I'd > imagine all of this gets a lot easier. > > However I can understand there are real issues with this: > > * /etc/amd.conf. We don't ship one in /etc by default. Maybe we should? > Speaking as someone who's never looked at amd before last week, this would be great, or at least in /usr/share/examples/etc. > * /etc/amd.map. We ship one which contains defaults and nothing more. > Perhaps commented out examples? > Again I'd find that helpful. I spent 5 or 10 minutes looking into setting up amd (Hardly indepth I know) and gave up because at the moment its easier to manually mount my devices ;) > * There doesn't appear to be a tool to tell amd about new maps at > runtime. Is there such a beast? > UPDATE: I just read code, and it seems SIGHUP can be sent, but this > isn't in the man page and I haven't tried it. > > * devd doesn't have any hooks into GEOM, which makes it difficult to > generate mount lines without retroactively parsing dmesg output. devd as > I understand it sits on top of NEWBUS. > Is there any way I can get a list of the disk devices, from userland, > in the default install, which correspond to a given NEWBUS device? > > * I wonder if there's any way we can get a notification about media > being inserted into a CDROM drive, without polling it? > > I had a brief discussion online with phk@ about doing dynamic mounts, > and it seems that there are still problems dealing with blowing away > mounts when the device goes away. > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From jonathan at kc8onw.net Mon May 12 01:23:53 2008 From: jonathan at kc8onw.net (jonathan@kc8onw.net) Date: Mon May 12 01:23:57 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol Message-ID: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> Has any work been done recently towards adding SATA Native Command Queueing as well as ATA APM and acoustic management to FreeBSD? I found this PR (with patch) to add APM and acoustic management control to atacontrol. The PR was opened in May 2005 has not been changed since December 2006 and is still open. http://www.freebsd.org/cgi/query-pr.cgi?pr=81692&cat= I have not been able to find much of anything on SATA NCQ in FreeBSD newer than 2005 or 2006 does anyone know anything newer? Thanks, Jonathan Stewart From koitsu at freebsd.org Mon May 12 03:06:47 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 03:06:50 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> Message-ID: <20080512030647.GA93725@eos.sc1.parodius.com> On Sun, May 11, 2008 at 09:08:51PM -0400, jonathan@kc8onw.net wrote: > Has any work been done recently towards adding SATA Native Command > Queueing as well as ATA APM and acoustic management to FreeBSD? > > I found this PR (with patch) to add APM and acoustic management control to > atacontrol. The PR was opened in May 2005 has not been changed since > December 2006 and is still open. > http://www.freebsd.org/cgi/query-pr.cgi?pr=81692&cat= > > I have not been able to find much of anything on SATA NCQ in FreeBSD newer > than 2005 or 2006 does anyone know anything newer? I believe NCQ is supported, assuming that your controller is operating in AHCI mode and your disk supports NCQ. This mainly applies to Intel ICHx controllers, but there are others which support it as well. There's also NCQ support in non-AHCI drivers like hptmv(4), rr232x(4), hptrr(4), and mpt(4) with SATA disks. I do see some code that explicitly disables NCQ on some nVidia chipsets, and I believe that's because the NCQ details for the nF4 chipset are unavailable; possibly Linux has them. atacontrol, on the other hand, I believe always spits out "-" as to whether or not it's enabled. I'd have to go look at the code to be sure, but I'm guessing it just says "-" no matter what. An example: Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 0/0x00 automatic acoustic management yes no 254/0xFE 128/0x80 Finally, I read a while back that NCQ on SATA does not provide a substantial improvement in overall disk I/O or under heavy load. It's not entirely marketing hype, but the benefits are like 3-4%, with added CPU utilisation. SATA TCQ is a different matter. SCSI uses TCQ, and as we all know, it works beautifully. SATA TCQ has a significantly larger queue depth than SATA NCQ (2^64 vs. 31). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dikshie at gmail.com Mon May 12 04:46:25 2008 From: dikshie at gmail.com (dikshie) Date: Mon May 12 04:46:29 2008 Subject: any available patches for sata: "ad4: warning - setfeatures set transfer mode taskqueue timeout - completing request directly" Message-ID: <910e60e80805112117j1ecb83b4s4cdb62eafbdf748f@mail.gmail.com> Hi, I got : -------------------------------- ad4: warning - setfeatures set transfer mode taskqueue timeout - completing request directly ad4: warning - setfeatures enable rcache taskqueue timeout - completing request directly ad4: warning - setfeatures enable wcache taskqueue timeout - completing request directly ad4: timeout - flushcache retrying (0 retries left) geom_journal: flush cache of ad4s1d: error=5 ad4: timeout - write_dma retrying (1 retry left) LBA=4139103 ------------------------------- I read: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues and strange output from dmesg: ad4: 305245MB at ata2-master UDMA33 ^^^^^^^^^^^ any available patches ? best regards, -dikshie- -------------------------------- Copyright (c) 1992-2008 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 7.0-STABLE #19: Sat May 10 15:41:00 JST 2008 dikshie@dhcp-143-221.sfc.wide.ad.jp:/usr/obj/usr/src/sys/BARU Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2333.34-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 2000646144 (1907 MB) avail memory = 1926553600 (1837 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero address or length: 0 0/1 [20070320] ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 100000, 7fdf0000 (3) failed acpi0: reservation of 0, a0000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 72a072a0600072a device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 72a072a0600072a device_attach: est1 attach returned 6 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 2.0 (no driver attached) isab0: at device 3.0 on pci0 isa0: on isab0 pci0: at device 3.1 (no driver attached) pci0: at device 3.2 (no driver attached) pci0: at device 3.4 (no driver attached) ohci0: mem 0xeffff000-0xefffffff irq 21 at device 4.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xefffe000-0xefffe0ff irq 22 at device 4.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered umass0: on uhub1 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 8.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 9.0 (no driver attached) pcib1: at device 10.0 on pci0 pci1: on pcib1 pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 13.0 on pci0 pci4: on pcib4 re0: port 0xde00-0xdeff mem 0xefdff000-0xefdfffff irq 16 at device 0.0 on pci4 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:e0:4d:66:7a:72 re0: [FILTER] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem 0xefff8000-0xefff9fff irq 20 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] vgapci0: mem 0xed000000-0xedffffff,0xd0000000-0xdfffffff,0xee000000-0xeeffffff irq 21 at device 16.0 on pci0 acpi_tz0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] orm0: at iomem 0xd0000-0xd3fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] orm0: at iomem 0xd0000-0xd3fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: on uhub0 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ad4: 305245MB at ata2-master UDMA33 acd0: DVDR at ata3-slave UDMA33 GEOM_JOURNAL: Journal 3398879317: ad4s1d contains data. GEOM_JOURNAL: Journal 3398879317: ad4s1d contains journal. GEOM_JOURNAL: Journal ad4s1d clean. GEOM_JOURNAL: Journal 2420032810: ad4s1e contains data. GEOM_JOURNAL: Journal 2420032810: ad4s1e contains journal. GEOM_JOURNAL: Journal ad4s1e clean. GEOM_JOURNAL: Journal 2035336235: ad4s1f contains data. GEOM_JOURNAL: Journal 2035336235: ad4s1f contains journal. GEOM_JOURNAL: Journal ad4s1f clean. GEOM_JOURNAL: Journal 811662893: ad4s1g contains data. GEOM_JOURNAL: Journal 811662893: ad4s1g contains journal. GEOM_JOURNAL: Journal ad4s1g clean. SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s1a ----------------------------------------------------------- From daniels_intrepid at yahoo.ie Mon May 12 05:01:29 2008 From: daniels_intrepid at yahoo.ie (John Daniels) Date: Mon May 12 05:01:34 2008 Subject: 7.0 issues fixed? upgrade timing? Message-ID: <339469.80542.qm@web26912.mail.ukl.yahoo.com> 1. I have a realtek network card and am using a cable modem router. Does anyone know if fixes for problems with these (see below) have been backported from HEAD to RELENG_7? 2. Is this a good time to upgrade to RELENG_7? 3. I read a post last week that advised that 7.1 is a long way off. Appreciate any advice on use of ULE 3.0 and ZFS prior to 7.1 and a comment on what is holding up 7.1. Thanks >From FreeBSD 7.0 errata notes: [20080229] Instances of packet corruption and instability have been observed with the re(4) network driver. Some users have reported that using a newer version of this driver (on HEAD) has solved their problems, or at least mitigated them. [20080229] A change in the way that FreeBSD sends TCP options has been reported to cause odd interactions with some cable modem routers. While this issue is still under investigation, a change has been committed to HEAD that returns the option processing to that of FreeBSD 6. So far, this change has shown some promising results. Send instant messages to your online friends http://uk.messenger.yahoo.com From koitsu at freebsd.org Mon May 12 05:11:43 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 05:11:47 2008 Subject: any available patches for sata: "ad4: warning - setfeatures set transfer mode taskqueue timeout - completing request directly" In-Reply-To: <910e60e80805112117j1ecb83b4s4cdb62eafbdf748f@mail.gmail.com> References: <910e60e80805112117j1ecb83b4s4cdb62eafbdf748f@mail.gmail.com> Message-ID: <20080512051142.GA99535@eos.sc1.parodius.com> On Mon, May 12, 2008 at 01:17:16PM +0900, dikshie wrote: > and strange output from dmesg: > ad4: 305245MB at ata2-master UDMA33 > ^^^^^^^^^^^ > any available patches ? What's strange about this? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From smithi at nimnet.asn.au Mon May 12 05:26:51 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon May 12 05:26:55 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> Message-ID: On Sun, 11 May 2008 jonathan@kc8onw.net wrote: > Has any work been done recently towards adding SATA Native Command > Queueing as well as ATA APM and acoustic management to FreeBSD? > > I found this PR (with patch) to add APM and acoustic management control to > atacontrol. The PR was opened in May 2005 has not been changed since > December 2006 and is still open. > http://www.freebsd.org/cgi/query-pr.cgi?pr=81692&cat= > > I have not been able to find much of anything on SATA NCQ in FreeBSD newer > than 2005 or 2006 does anyone know anything newer? Jeremy has addressed the NCQ issue, about which I know nothing. As for APM and AAM, that functionality is handled by sysutils/ataidle, which that PR appears - on a quick glance - to pretty well duplicate. I see phk@ recently added an 'atacontrol spindown' command to HEAD and RELENG_7 that appears to offer similar functionality to 'ataidle -S standby_mins' or 'ataidle -I idle_mins', though specified in seconds instead. However this doesn't address acoustic management. Or is ataidle broken for SATA disks? cheers, Ian From cswiger at mac.com Mon May 12 05:30:17 2008 From: cswiger at mac.com (Chuck Swiger) Date: Mon May 12 05:30:25 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <339469.80542.qm@web26912.mail.ukl.yahoo.com> References: <339469.80542.qm@web26912.mail.ukl.yahoo.com> Message-ID: <42C08C65-F0F6-42E5-B20C-D76035F111D7@mac.com> On May 11, 2008, at 9:34 PM, John Daniels wrote: > 1. I have a realtek network card and am using a cable modem > router. Does anyone know if fixes for problems with these (see > below) have been backported from HEAD to RELENG_7? The most useful thing to do would be to test the fixes out yourself and report back whether they help, assuming you encounter problems. > 2. Is this a good time to upgrade to RELENG_7? On a test machine, sure. It's been a long time since I've run a production environment off of a .0 release at all, much less without testing it first. :-) > 3. I read a post last week that advised that 7.1 is a long way off. > Appreciate any advice on use of ULE 3.0 and ZFS prior to 7.1 and a > comment on what is holding up 7.1. Respectively: ULE seems to be a solid improvement. ZFS is still beta. Nothing...be patient, or make more active contributions to help move things forwards. -- -Chuck From bu7cher at yandex.ru Mon May 12 05:31:01 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Mon May 12 05:31:06 2008 Subject: any available patches for sata: "ad4: warning - setfeatures set transfer mode taskqueue timeout - completing request directly" In-Reply-To: <910e60e80805112117j1ecb83b4s4cdb62eafbdf748f@mail.gmail.com> References: <910e60e80805112117j1ecb83b4s4cdb62eafbdf748f@mail.gmail.com> Message-ID: <4827D60A.6040200@yandex.ru> dikshie wrote: > atapci1: port > 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem > 0xefff8000-0xefff9fff irq 20 at device 14.0 on pci0 It seems your controller detected as generic ATA. Can you show `pciconf -l` output from your system? -- WBR, Andrey V. Elsukov From unixmania at gmail.com Mon May 12 05:43:59 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Mon May 12 05:44:03 2008 Subject: burncd: ioctl(CDIOCEJECT): Input/output error Message-ID: Hello, I get "burncd: ioctl(CDIOCEJECT): Input/output error" each time I attempt to blank a CDRW with burncd -f /dev/acd0 blank eject I noticed that this does not happen when I write a data cd with burncd -f /dev/acd0 data cd-image.iso fixate eject I have seen the same bahavior on 4 different computers that have DVD-RW units. Applying the attached patch to /usr/src/usr.sbin/burncd/burncd.c solves the problem. It make burncd attempt to eject the CD five times, sleeping for one second after each unccessful try. I'd like to get some opinions on this before submitting a PR. Thanks in advance. -- Carlos A. M. dos Santos -------------- next part -------------- A non-text attachment was scrubbed... Name: burncd_eject.patch Type: application/octet-stream Size: 559 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080512/0ccbb6a4/burncd_eject.obj From koitsu at freebsd.org Mon May 12 05:46:24 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 05:46:26 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <339469.80542.qm@web26912.mail.ukl.yahoo.com> References: <339469.80542.qm@web26912.mail.ukl.yahoo.com> Message-ID: <20080512054624.GA660@eos.sc1.parodius.com> On Mon, May 12, 2008 at 05:34:47AM +0100, John Daniels wrote: > 1. I have a realtek network card and am using a cable modem router. > Does anyone know if fixes for problems with these (see below) have > been backported from HEAD to RELENG_7? I'd recommend downloading a RELENG_7 bootonly image, or possibly the livefs image (which will give you utilities and a working read-only filesystem), and see how your hardware looks on that. Meaning, if you have a test scenario which can be easily reproduced and can be done from livefs, give that a try. RELENG_7 snapshots (meaning 7.0-STABLE vs. 7.0-RELEASE) are here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200804 > 2. Is this a good time to upgrade to RELENG_7? That's entirely up to you. RELENG_6 will be decomissioned quicker than RELENG_5 was, from what I've read, so testing compatibility now would be a good idea. > 3. I read a post last week that advised that 7.1 is a long way off. > Appreciate any advice on use of ULE 3.0 and ZFS prior to 7.1 and a > comment on what is holding up 7.1. Regarding ULE 3.0, I think you're referring to the ULE that's actually in RELENG_7 presently, which actually works (compared to the ULE that was in RELENG_5 and RELENG_6, which had major bugs). Or are you referring to an even newer scheduler (something -CURRENT might have)? ZFS is in a state of... well... my opinion is: use it at your own risk. The "experimental!" warning is very applicable. There are known problems with ZFS when performing lots of I/O between a ZFS pool and a UFS fs. > [20080229] Instances of packet corruption and instability have been observed with the re(4) network driver. Some users have reported that using a newer version of this driver (on HEAD) has solved their problems, or at least mitigated them. I believe this has been fixed, based on commits I've seen to the driver. Pyun YongHyeon would be able to confirm/deny this. > [20080229] A change in the way that FreeBSD sends TCP options has been reported to cause odd interactions with some cable modem routers. While this issue is still under investigation, a change has been committed to HEAD that returns the option processing to that of FreeBSD 6. So far, this change has shown some promising results. Do you have more details on this? Open PR, or a thread I can read? I'm thinking it might be related to the net.inet.tcp.rfc1323 sysctl, but I'm not sure. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at freebsd.org Mon May 12 05:54:07 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 05:54:12 2008 Subject: any available patches for sata: "ad4: warning - setfeatures set transfer mode taskqueue timeout - completing request directly" In-Reply-To: <910e60e80805112214p5a03b6fcn73ea1c5ebf70baab@mail.gmail.com> References: <910e60e80805112117j1ecb83b4s4cdb62eafbdf748f@mail.gmail.com> <20080512051142.GA99535@eos.sc1.parodius.com> <910e60e80805112214p5a03b6fcn73ea1c5ebf70baab@mail.gmail.com> Message-ID: <20080512055406.GA1333@eos.sc1.parodius.com> On Mon, May 12, 2008 at 02:14:37PM +0900, dikshie wrote: > On Mon, May 12, 2008 at 2:11 PM, Jeremy Chadwick wrote: > > On Mon, May 12, 2008 at 01:17:16PM +0900, dikshie wrote: > >> and strange output from dmesg: > >> ad4: 305245MB at ata2-master UDMA33 > >> ^^^^^^^^^^^ > >> any available patches ? > > > > What's strange about this? > > i mean for "UDMA33" it should be SATA300 > do have to upgrade BIOS? Your carets are pointing to the drive firmware revision, which is why I was confused. :-) Yes, it should say either SATA150 or SATA300 (more on that in a moment), but based on your dmesg output, it appears your SATA controller does not have an attached driver, thus is operating generically. Andrey recommended showing pciconf -lv output; please do. Your drive is *probably* operating in SATA150/300 mode, despite UDMA33 being printed, however. Assuming you know your disk can push >33MB/sec, you could try some simple read I/O and use gstat to watch the speed. dd if=/dev/ad4 of=/dev/null bs=1m should suffice. Regarding SATA150 vs. SATA300: your drive has a physical jumper, labelled OPT1 in the below photo, which limits the drive to SATA150 capability. You can remove this jumper and get SATA300. This doesn't explain the UDMA33 issue, though. http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=1400&p_created=1134597011 Also, please don't remove the mailing list from the CC; others need to know what information you've provided, and future users may find this thread useful. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bu7cher at yandex.ru Mon May 12 05:57:35 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Mon May 12 05:57:40 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <20080512030647.GA93725@eos.sc1.parodius.com> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <20080512030647.GA93725@eos.sc1.parodius.com> Message-ID: <4827D531.7000603@yandex.ru> Jeremy Chadwick wrote: > I believe NCQ is supported, assuming that your controller is operating > in AHCI mode and your disk supports NCQ. This mainly applies to Intel > ICHx controllers, but there are others which support it as well. > There's also NCQ support in non-AHCI drivers like hptmv(4), rr232x(4), > hptrr(4), and mpt(4) with SATA disks. No. ata(4) driver currently doesn't support/use NCQ. -- WBR, Andrey V. Elsukov From koitsu at freebsd.org Mon May 12 06:00:17 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 06:00:21 2008 Subject: any available patches for sata: "ad4: warning - setfeatures set transfer mode taskqueue timeout - completing request directly" In-Reply-To: <910e60e80805112242w57a6e932tbf48e482d96dc452@mail.gmail.com> References: <910e60e80805112117j1ecb83b4s4cdb62eafbdf748f@mail.gmail.com> <4827D60A.6040200@yandex.ru> <910e60e80805112236r105b5894r285b68f0d28105b1@mail.gmail.com> <910e60e80805112242w57a6e932tbf48e482d96dc452@mail.gmail.com> Message-ID: <20080512060017.GB1333@eos.sc1.parodius.com> On Mon, May 12, 2008 at 02:42:40PM +0900, dikshie wrote: > i just phone computer store and check together the BIOS. > it seems my computer store put the disk on IDE mode NOT on AHCI mode. > after change to AHCI now FreeBSD can detect SATA 300 (for WDC) and > SATA 150 (for DVD-R). Great, there you go. :-) > BUT sometimes I still getting: > ad4: warning - setfeatures set transfer mode taskqueue timeout -completing request directly > ad4: warning - setfeatures enable rcache taskqueue timeout - completing request directly > ad4: warning - setfeatures enable wcache taskqueue timeout - completing request directly > ad4: timeout - flushcache retrying (0 retries left) > geom_journal: flush cache of ad4s1d: error=5 > ad4: timeout - write_dma retrying (1 retry left) LBA=4139103 1) Have you checked SMART statistics of the drive, or run SMART tests? Install ports/sysutils/smartmontools and use smartctl -a /dev/ad4, and provide the output. 2) Is the error always on ad4? If so, is the error always at LBA 4139103, or "around there" (give or take a few thousand addressing blocks)? If so, the ad4 disk may be going bad. Otherwise, I would say this is probably the issue I've documented on my Common Issues page. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at freebsd.org Mon May 12 06:09:38 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 06:09:44 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <4827D531.7000603@yandex.ru> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <20080512030647.GA93725@eos.sc1.parodius.com> <4827D531.7000603@yandex.ru> Message-ID: <20080512060938.GA2007@eos.sc1.parodius.com> On Mon, May 12, 2008 at 09:27:13AM +0400, Andrey V. Elsukov wrote: > Jeremy Chadwick wrote: >> I believe NCQ is supported, assuming that your controller is operating >> in AHCI mode and your disk supports NCQ. This mainly applies to Intel >> ICHx controllers, but there are others which support it as well. >> There's also NCQ support in non-AHCI drivers like hptmv(4), rr232x(4), >> hptrr(4), and mpt(4) with SATA disks. > > No. ata(4) driver currently doesn't support/use NCQ. Thanks for this information -- I had no idea! I'll add this to my Common Issues page, although it's not so much an "issue" but more so a feature. I was always under the impression that AHCI included automatic support for negotiation and use of extensions like NCQ and TCQ: http://en.wikipedia.org/wiki/Native_Command_Queuing http://www.seagate.com/content/docs/pdf/whitepaper/D2c_tech_paper_intc-stx_sata_ncq.pdf -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bu7cher at yandex.ru Mon May 12 06:14:42 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Mon May 12 06:14:48 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <20080512060938.GA2007@eos.sc1.parodius.com> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <20080512030647.GA93725@eos.sc1.parodius.com> <4827D531.7000603@yandex.ru> <20080512060938.GA2007@eos.sc1.parodius.com> Message-ID: <4827E049.4030500@yandex.ru> Jeremy Chadwick wrote: >> No. ata(4) driver currently doesn't support/use NCQ. > > Thanks for this information -- I had no idea! I'll add this to my > Common Issues page, although it's not so much an "issue" but more so a > feature. > > I was always under the impression that AHCI included automatic support > for negotiation and use of extensions like NCQ and TCQ: > > http://en.wikipedia.org/wiki/Native_Command_Queuing > http://www.seagate.com/content/docs/pdf/whitepaper/D2c_tech_paper_intc-stx_sata_ncq.pdf AHCI has standart method to determine presence of NCQ support. But FreeBSD's driver needs some code to work with NCQ. Soren said to me that he is going to work with NCQ support after merging PM support, but I don't know about current status. -- WBR, Andrey V. Elsukov From dikshie at gmail.com Mon May 12 06:38:47 2008 From: dikshie at gmail.com (dikshie) Date: Mon May 12 06:38:51 2008 Subject: any available patches for sata: "ad4: warning - setfeatures set transfer mode taskqueue timeout - completing request directly" In-Reply-To: <20080512060017.GB1333@eos.sc1.parodius.com> References: <910e60e80805112117j1ecb83b4s4cdb62eafbdf748f@mail.gmail.com> <4827D60A.6040200@yandex.ru> <910e60e80805112236r105b5894r285b68f0d28105b1@mail.gmail.com> <910e60e80805112242w57a6e932tbf48e482d96dc452@mail.gmail.com> <20080512060017.GB1333@eos.sc1.parodius.com> Message-ID: <910e60e80805112338m6edf555fr3b7693f2c81bac5f@mail.gmail.com> On Mon, May 12, 2008 at 3:00 PM, Jeremy Chadwick wrote: > 1) Have you checked SMART statistics of the drive, or run SMART tests? > Install ports/sysutils/smartmontools and use smartctl -a /dev/ad4, and > provide the output. > > 2) Is the error always on ad4? If so, is the error always at LBA > 4139103, or "around there" (give or take a few thousand addressing > blocks)? If so, the ad4 disk may be going bad. Otherwise, I would say > this is probably the issue I've documented on my Common Issues page. dhcp-143-221# smartctl -a /dev/ad4 smartctl version 5.38 [amd64-portbld-freebsd7.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Second Generation Serial ATA family Device Model: WDC WD3200AAKS-00VYA0 Serial Number: WD-WCARW2314765 Firmware Version: 12.01B02 User Capacity: 320,072,933,376 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Mon May 12 15:27:24 2008 JST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (8760) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 104) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x303f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0003 155 155 021 Pre-fail Always - 5233 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 11 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 940 10 Spin_Retry_Count 0x0012 100 253 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0012 100 253 051 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 11 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 8 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 11 194 Temperature_Celsius 0x0022 114 108 000 Old_age Always - 33 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. errors always on ad4 with random LBA blocks numbers. with best regards, -dikshie- From jonathan at kc8onw.net Mon May 12 07:16:12 2008 From: jonathan at kc8onw.net (jonathan@kc8onw.net) Date: Mon May 12 07:16:16 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> Message-ID: <53004.80.91.220.50.1210576570.squirrel@www.kc8onw.net> On Mon, May 12, 2008 00:52, Ian Smith wrote: > On Sun, 11 May 2008 jonathan@kc8onw.net wrote: > >> I found this PR (with patch) to add APM and acoustic management control >> to atacontrol. The PR was opened in May 2005 has not been changed since >> December 2006 and is still open. >> http://www.freebsd.org/cgi/query-pr.cgi?pr=81692&cat= >> >> I have not been able to find much of anything on SATA NCQ in FreeBSD >> newer than 2005 or 2006 does anyone know anything newer? > > As for APM and AAM, that functionality is handled by sysutils/ataidle, > which that PR appears - on a quick glance - to pretty well duplicate. > > I see phk@ recently added an 'atacontrol spindown' command to HEAD and > RELENG_7 that appears to offer similar functionality to 'ataidle -S > standby_mins' or 'ataidle -I idle_mins', though specified in seconds > instead. However this doesn't address acoustic management. > > Or is ataidle broken for SATA disks? I think the idea was to put the ability to control it where people see it first. I expected to be able to control NCQ, APM, and acoustic management from atacontrol considering it listed whether they were enabled or not. ataidle is easy enough to find, I won't deny, but why make users do the google search and install a port when there is (what looks to me) a fairly simple patch that can be added to the base system. Either way it would be good to get the PR closed one way or the other considering the backlog... Jonathan Stewart From koitsu at freebsd.org Mon May 12 07:23:17 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 07:23:24 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <53004.80.91.220.50.1210576570.squirrel@www.kc8onw.net> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <53004.80.91.220.50.1210576570.squirrel@www.kc8onw.net> Message-ID: <20080512072316.GA3845@eos.sc1.parodius.com> On Mon, May 12, 2008 at 03:16:10AM -0400, jonathan@kc8onw.net wrote: > On Mon, May 12, 2008 00:52, Ian Smith wrote: > > On Sun, 11 May 2008 jonathan@kc8onw.net wrote: > > > >> I found this PR (with patch) to add APM and acoustic management control > >> to atacontrol. The PR was opened in May 2005 has not been changed since > >> December 2006 and is still open. > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=81692&cat= > >> > >> I have not been able to find much of anything on SATA NCQ in FreeBSD > >> newer than 2005 or 2006 does anyone know anything newer? > > > > As for APM and AAM, that functionality is handled by sysutils/ataidle, > > which that PR appears - on a quick glance - to pretty well duplicate. > > > > I see phk@ recently added an 'atacontrol spindown' command to HEAD and > > RELENG_7 that appears to offer similar functionality to 'ataidle -S > > standby_mins' or 'ataidle -I idle_mins', though specified in seconds > > instead. However this doesn't address acoustic management. > > > > Or is ataidle broken for SATA disks? > > I think the idea was to put the ability to control it where people see it > first. I expected to be able to control NCQ, APM, and acoustic management > from atacontrol considering it listed whether they were enabled or not. Well, atacontrol(8) does let you control many things, but most pertain to ataraid(4). Otherwise, it acts purely as an ATA/SATA information utility; maybe it should be renamed atainfo(8)? The expectation that the tool should be able to control those things is legitimate, but if this is something you absolutely *need*, then I would recommend going with Linux instead. Their libata has support for all of the above, and has userland applications to control said features. > ataidle is easy enough to find, I won't deny, but why make users do the > google search and install a port when there is (what looks to me) a fairly > simple patch that can be added to the base system. Either way it would be > good to get the PR closed one way or the other considering the backlog... There are a "decent" number of PRs pertaining to ATA/SATA stuff in FreeBSD, some going back over 2 years which fix very severe bugs in RAID (see my Common Issues list for examples). Your cries are heard by some, but I'm left believing Soren is just super busy with real life. I consider this even more justification that the ATA layer in FreeBSD needs additional eyes familiar with it, and not just a single person. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jonathan at kc8onw.net Mon May 12 07:36:52 2008 From: jonathan at kc8onw.net (jonathan@kc8onw.net) Date: Mon May 12 07:36:57 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <20080512072316.GA3845@eos.sc1.parodius.com> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <53004.80.91.220.50.1210576570.squirrel@www.kc8onw.net> <20080512072316.GA3845@eos.sc1.parodius.com> Message-ID: <58131.80.91.220.50.1210577810.squirrel@www.kc8onw.net> On Mon, May 12, 2008 03:23, Jeremy Chadwick wrote: > On Mon, May 12, 2008 at 03:16:10AM -0400, jonathan@kc8onw.net wrote: > >> On Mon, May 12, 2008 00:52, Ian Smith wrote: >> >>> On Sun, 11 May 2008 jonathan@kc8onw.net wrote: >>> >>>> I found this PR (with patch) to add APM and acoustic management >>>> control to atacontrol. The PR was opened in May 2005 has not been >>>> changed since December 2006 and is still open. >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=81692&cat= >>> >>> As for APM and AAM, that functionality is handled by >>> sysutils/ataidle, which that PR appears - on a quick glance - to >>> pretty well duplicate. >>> >>> I see phk@ recently added an 'atacontrol spindown' command to HEAD >>> and RELENG_7 that appears to offer similar functionality to 'ataidle >>> -S >>> standby_mins' or 'ataidle -I idle_mins', though specified in seconds >>> instead. However this doesn't address acoustic management. >>> >>> Or is ataidle broken for SATA disks? >>> >> >> I think the idea was to put the ability to control it where people see >> it first. I expected to be able to control NCQ, APM, and acoustic >> management from atacontrol considering it listed whether they were >> enabled or not. > > Well, atacontrol(8) does let you control many things, but most pertain > to ataraid(4). Otherwise, it acts purely as an ATA/SATA information > utility; maybe it should be renamed atainfo(8)? That would probably confuse more existing users than it would help new ones. I don't think it would be worth renaming it unless the raid functionality was moved to a separate command, which would be a pointless bunch of work. > The expectation that the tool should be able to control those things is > legitimate, but if this is something you absolutely *need*, then I would > recommend going with Linux instead. Their libata has support for all of > the above, and has userland applications to control said features. Nope, I'm happy with FreeBSD. This is more of a minor quirk than anything else for me. I figured I would see if anything had changed since the last mailing list messages I found where well over a year old. >> ataidle is easy enough to find, I won't deny, but why make users do the >> google search and install a port when there is (what looks to me) a >> fairly simple patch that can be added to the base system. Either way it >> would be good to get the PR closed one way or the other considering the >> backlog... > > There are a "decent" number of PRs pertaining to ATA/SATA stuff in > FreeBSD, some going back over 2 years which fix very severe bugs in RAID > (see my Common Issues list for examples). Where is this list? I did a quick search but couldn't find it. > Your cries are heard by some, but I'm left believing Soren is just super > busy with real life. I consider this even more justification that the ATA > layer in FreeBSD needs additional eyes familiar with it, and not just a > single person. No argument here. Soren does an incredible job maintaining ATA as it is and I am very grateful that he has put as much of his time into the project as he has. (Thanks Soren!) Jonathan Stewart From koitsu at freebsd.org Mon May 12 07:45:41 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 07:45:44 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <58131.80.91.220.50.1210577810.squirrel@www.kc8onw.net> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <53004.80.91.220.50.1210576570.squirrel@www.kc8onw.net> <20080512072316.GA3845@eos.sc1.parodius.com> <58131.80.91.220.50.1210577810.squirrel@www.kc8onw.net> Message-ID: <20080512074541.GA4667@eos.sc1.parodius.com> On Mon, May 12, 2008 at 03:36:50AM -0400, jonathan@kc8onw.net wrote: > On Mon, May 12, 2008 03:23, Jeremy Chadwick wrote: > > On Mon, May 12, 2008 at 03:16:10AM -0400, jonathan@kc8onw.net wrote: > >> ataidle is easy enough to find, I won't deny, but why make users do the > >> google search and install a port when there is (what looks to me) a > >> fairly simple patch that can be added to the base system. Either way it > >> would be good to get the PR closed one way or the other considering the > >> backlog... > > > > There are a "decent" number of PRs pertaining to ATA/SATA stuff in > > FreeBSD, some going back over 2 years which fix very severe bugs in RAID > > (see my Common Issues list for examples). > > Where is this list? I did a quick search but couldn't find it. http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Your cries are heard by some, but I'm left believing Soren is just super > > busy with real life. I consider this even more justification that the ATA > > layer in FreeBSD needs additional eyes familiar with it, and not just a > > single person. > > No argument here. Soren does an incredible job maintaining ATA as it is > and I am very grateful that he has put as much of his time into the > project as he has. (Thanks Soren!) I am too, but PRs that are 2 years old which include patches for severe bugs that affect reliability of RAID is (in my opinion) not acceptable. I've been spanked over saying this before ("you don't understand how open source works"), but necessity easily supercedes idealism. Linux's libata has evolved very quickly and very well, and has multiple eyes familiar with the code (in the case the author takes vacation, etc.). It has the upper hand here. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From markir at paradise.net.nz Mon May 12 08:16:05 2008 From: markir at paradise.net.nz (Mark Kirkwood) Date: Mon May 12 08:16:10 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <20080512074541.GA4667@eos.sc1.parodius.com> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <53004.80.91.220.50.1210576570.squirrel@www.kc8onw.net> <20080512072316.GA3845@eos.sc1.parodius.com> <58131.80.91.220.50.1210577810.squirrel@www.kc8onw.net> <20080512074541.GA4667@eos.sc1.parodius.com> Message-ID: <4827F91E.60102@paradise.net.nz> Jeremy Chadwick wrote: > > I am too, but PRs that are 2 years old which include patches for severe > bugs that affect reliability of RAID is (in my opinion) not acceptable. > I've been spanked over saying this before ("you don't understand how > open source works"), but necessity easily supercedes idealism. > > Linux's libata has evolved very quickly and very well, and has multiple > eyes familiar with the code (in the case the author takes vacation, > etc.). It has the upper hand here. > > Linux has more eyes period, which helps a lot. In addition Linux has more commercial sponsorship - having said that, I've no idea if libdata development has had any such sponsorship... However. I do agree that we (that is FreeBSD) need more folks brave enough to help Soren out with the (S)ATA layer - that means people like you or me deciding to get our hands dirty with this code... best wishes Mark From fbsd-stable at mawer.org Mon May 12 08:37:11 2008 From: fbsd-stable at mawer.org (Antony Mawer) Date: Mon May 12 08:37:14 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <20080512054624.GA660@eos.sc1.parodius.com> References: <339469.80542.qm@web26912.mail.ukl.yahoo.com> <20080512054624.GA660@eos.sc1.parodius.com> Message-ID: <4827FA43.1050006@mawer.org> Jeremy Chadwick wrote: ... >> [20080229] A change in the way that FreeBSD sends TCP options has been reported to cause odd interactions with some cable modem routers. While this issue is still under investigation, a change has been committed to HEAD that returns the option processing to that of FreeBSD 6. So far, this change has shown some promising results. > > Do you have more details on this? Open PR, or a thread I can read? I'm > thinking it might be related to the net.inet.tcp.rfc1323 sysctl, but I'm > not sure. See here: http://groups.google.com/group/mailing.freebsd.net/browse_thread/thread/03e3965192fbc64c/48e037ab2717c7dd?lnk=raot It's fixed in RELENG_7 as far as I'm aware: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c#rev1.141.2.5 but there was talk of it being an errata candidate for RELENG_7_0, which doesn't look like has happened just yet. --Antony From bu7cher at yandex.ru Mon May 12 08:52:33 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Mon May 12 08:52:38 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <4827F91E.60102@paradise.net.nz> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <53004.80.91.220.50.1210576570.squirrel@www.kc8onw.net> <20080512072316.GA3845@eos.sc1.parodius.com> <58131.80.91.220.50.1210577810.squirrel@www.kc8onw.net> <20080512074541.GA4667@eos.sc1.parodius.com> <4827F91E.60102@paradise.net.nz> Message-ID: <4828053E.9080301@yandex.ru> Mark Kirkwood wrote: > Linux has more eyes period, which helps a lot. In addition Linux has > more commercial sponsorship - having said that, I've no idea if libdata > development has had any such sponsorship... As I know the most of active libata developers have full-time job in Linux companies, e.g. in Red Hat. -- WBR, Andrey V. Elsukov From torfinn.ingolfsen at broadpark.no Mon May 12 09:38:22 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Mon May 12 09:38:29 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <339469.80542.qm@web26912.mail.ukl.yahoo.com> References: <339469.80542.qm@web26912.mail.ukl.yahoo.com> Message-ID: <20080512113753.67295481.torfinn.ingolfsen@broadpark.no> On Mon, 12 May 2008 05:34:47 +0100 (BST) John Daniels wrote: > 1. I have a realtek network card and am using a cable modem > router. Does anyone know if fixes for problems with these (see > below) have been backported from HEAD to RELENG_7? FWIW, I had major troubles with re(4) around 7.0-release, and a while later (I had to use patches). After upgrading to 7-stable on 2008-04-12, re(4) is working for me without patches. HTH -- Regards, Torfinn Ingolfsen From petefrench at ticketswitch.com Mon May 12 11:06:00 2008 From: petefrench at ticketswitch.com (Pete French) Date: Mon May 12 11:06:03 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <20080512113753.67295481.torfinn.ingolfsen@broadpark.no> Message-ID: > FWIW, I had major troubles with re(4) around 7.0-release, and a while > later (I had to use patches). After upgrading to 7-stable on > 2008-04-12, re(4) is working for me without patches. I havent tried a recent 'sup, but I also had problems which were fixed by turning off some stuff using "-tso -lro -vlanhwtag -txcsum -rxcsum" in the ifconfig line. I would liek to test a recent patch, but political problems with ohysiucal access to the machine means I am pretty much scared to reboot it :-( Having said that, I;ve tried the patches on a test setup and they seem to work very nicely. -pete. From torfinn.ingolfsen at broadpark.no Mon May 12 11:44:25 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Mon May 12 11:44:30 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <20080512113753.67295481.torfinn.ingolfsen@broadpark.no> References: <339469.80542.qm@web26912.mail.ukl.yahoo.com> <20080512113753.67295481.torfinn.ingolfsen@broadpark.no> Message-ID: <20080512134422.6dbe127c.torfinn.ingolfsen@broadpark.no> On Mon, 12 May 2008 11:37:53 +0200 Torfinn Ingolfsen wrote: > FWIW, I had major troubles with re(4) around 7.0-release, and a while > later (I had to use patches). After upgrading to 7-stable on > 2008-04-12, re(4) is working for me without patches. (sigh).. it seems that I spoke to soon. Murphy just showed up. I still get ssh disconnects (see below) on connections _to_ the machine when transferring largish amounts of data (like when upgrading a port). Here is one example (portupgrading the jdk port): /usr/bin/gcc -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -Damd64 -DARCH='"amd64"' -DRELEASE='"1.6.0_03-p4"' -DFULL_VERSION='"1.6.0_03-p4-root_12_may_2008_13_25-b00"' -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D_ALLBSD_SOURCE -D_LP64=1 -I. -I/usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/javavm/include -I../../../src/solaris/javavm/include -I../../../src/share/native/sun/management -I../../../src/solaris/hpi/include -I../../../src/share/native/common -I../../../src/solaris/native/common -I../../../src/share/native/java/lang/management -I../../../src/solaris/native/java/lang/management -c -o /usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/obj64/ClassLoadingImpl.o ../../../src/share/native/sun/management/ClassLoadingImpl.c Disconnecting: Bad packet length 3601161525. The machine is running: tingo@kg-vm$ uname -a FreeBSD kg-vm.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #10: Sat Apr 12 21:42:55 CEST 2008 root@kg-vm.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 and has been up for about 14 days: tingo@kg-vm$ uptime 1:36PM up 14 days, 17:42, 7 users, load averages: 2.15, 1.85, 1.34 I see that if_re.c for RELENG_7 has been updated on April 22nd, so I'll upgrade the machine to latest -stable and see if that works better. -- Regards, Torfinn Ingolfsen From koitsu at freebsd.org Mon May 12 12:32:07 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 12:32:14 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <20080512134422.6dbe127c.torfinn.ingolfsen@broadpark.no> References: <339469.80542.qm@web26912.mail.ukl.yahoo.com> <20080512113753.67295481.torfinn.ingolfsen@broadpark.no> <20080512134422.6dbe127c.torfinn.ingolfsen@broadpark.no> Message-ID: <20080512123207.GA12255@eos.sc1.parodius.com> On Mon, May 12, 2008 at 01:44:22PM +0200, Torfinn Ingolfsen wrote: > On Mon, 12 May 2008 11:37:53 +0200 > Torfinn Ingolfsen wrote: > > > FWIW, I had major troubles with re(4) around 7.0-release, and a while > > later (I had to use patches). After upgrading to 7-stable on > > 2008-04-12, re(4) is working for me without patches. > > (sigh).. it seems that I spoke to soon. Murphy just showed up. I still > get ssh disconnects (see below) on connections _to_ the machine when > transferring largish amounts of data (like when upgrading a port). > Here is one example (portupgrading the jdk port): > /usr/bin/gcc -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -Damd64 -DARCH='"amd64"' -DRELEASE='"1.6.0_03-p4"' -DFULL_VERSION='"1.6.0_03-p4-root_12_may_2008_13_25-b00"' -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D_ALLBSD_SOURCE -D_LP64=1 -I. -I/usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/javavm/include -I../../../src/solaris/javavm/include -I../../../src/share/native/sun/management -I../../../src/solaris/hpi/include -I../../../src/share/native/common -I../../../src/solaris/native/common -I../../../src/share/native/java/lang/management -I../../../src/solaris/native/java/lang/management -c -o /usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/obj64/ClassLoadingImpl.o ../../../src/share/native/sun/management/ClassLoadingImpl.c > Disconnecting: Bad packet length 3601161525. > > The machine is running: > tingo@kg-vm$ uname -a > FreeBSD kg-vm.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #10: Sat Apr 12 > 21:42:55 CEST 2008 root@kg-vm.kg4.no:/usr/obj/usr/src/sys/GENERIC > amd64 > > and has been up for about 14 days: > tingo@kg-vm$ uptime > 1:36PM up 14 days, 17:42, 7 users, load averages: 2.15, 1.85, 1.34 > > I see that if_re.c for RELENG_7 has been updated on April 22nd, so I'll upgrade the machine to latest -stable and see if that works better. Is this machine using pf(4) at all? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From scottl at samsco.org Mon May 12 14:11:27 2008 From: scottl at samsco.org (Scott Long) Date: Mon May 12 14:11:31 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <4827F91E.60102@paradise.net.nz> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <53004.80.91.220.50.1210576570.squirrel@www.kc8onw.net> <20080512072316.GA3845@eos.sc1.parodius.com> <58131.80.91.220.50.1210577810.squirrel@www.kc8onw.net> <20080512074541.GA4667@eos.sc1.parodius.com> <4827F91E.60102@paradise.net.nz> Message-ID: <48284C32.5060707@samsco.org> Mark Kirkwood wrote: > Jeremy Chadwick wrote: >> >> I am too, but PRs that are 2 years old which include patches for severe >> bugs that affect reliability of RAID is (in my opinion) not acceptable. >> I've been spanked over saying this before ("you don't understand how >> open source works"), but necessity easily supercedes idealism. >> >> Linux's libata has evolved very quickly and very well, and has multiple >> eyes familiar with the code (in the case the author takes vacation, >> etc.). It has the upper hand here. >> >> > Linux has more eyes period, which helps a lot. In addition Linux has > more commercial sponsorship - having said that, I've no idea if libdata > development has had any such sponsorship... > > However. I do agree that we (that is FreeBSD) need more folks brave > enough to help Soren out with the (S)ATA layer - that means people like > you or me deciding to get our hands dirty with this code... > I'm working on adding ATA/SATA support to CAM. Scott From koitsu at freebsd.org Mon May 12 14:15:52 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Mon May 12 14:15:58 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <48284C32.5060707@samsco.org> References: <29626.214.13.212.30.1210554531.squirrel@www.kc8onw.net> <53004.80.91.220.50.1210576570.squirrel@www.kc8onw.net> <20080512072316.GA3845@eos.sc1.parodius.com> <58131.80.91.220.50.1210577810.squirrel@www.kc8onw.net> <20080512074541.GA4667@eos.sc1.parodius.com> <4827F91E.60102@paradise.net.nz> <48284C32.5060707@samsco.org> Message-ID: <20080512141552.GA14963@eos.sc1.parodius.com> On Mon, May 12, 2008 at 07:54:58AM -0600, Scott Long wrote: > Mark Kirkwood wrote: >> Jeremy Chadwick wrote: >>> >>> I am too, but PRs that are 2 years old which include patches for severe >>> bugs that affect reliability of RAID is (in my opinion) not acceptable. >>> I've been spanked over saying this before ("you don't understand how >>> open source works"), but necessity easily supercedes idealism. >>> >>> Linux's libata has evolved very quickly and very well, and has multiple >>> eyes familiar with the code (in the case the author takes vacation, >>> etc.). It has the upper hand here. >>> >>> >> Linux has more eyes period, which helps a lot. In addition Linux has more >> commercial sponsorship - having said that, I've no idea if libdata >> development has had any such sponsorship... >> >> However. I do agree that we (that is FreeBSD) need more folks brave enough >> to help Soren out with the (S)ATA layer - that means people like you or me >> deciding to get our hands dirty with this code... >> > > I'm working on adding ATA/SATA support to CAM. ! Wow... I had no idea you were working on such! Ideally that'd be the best implementation. Thanks a ton for working on it! If you need someone to test patches (I figure they'll be for -CURRENT, but our test boxes run RELENG_7), let me know and I'll be more than happy to give them a shot. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dot at dotat.at Mon May 12 16:38:28 2008 From: dot at dotat.at (Tony Finch) Date: Mon May 12 16:38:33 2008 Subject: cvsup.uk.FreeBSD.org In-Reply-To: <20080511102730.DBD0A600F@mailhost.tao.org.uk> References: <20080511102730.DBD0A600F@mailhost.tao.org.uk> Message-ID: On Sun, 11 May 2008, Dr Joe Karthauser wrote: > > I have reclassified this faulty mirror as cvsup1 and made cvsup a cname to > cvsup3, which is the most recent addition and best hardware available. In > the future we will always point to the most available machine in this way. Looks like I'm getting a bit more traffic than before - peaking at over 100 logins an hour. Tony. -- f.anthony.n.finch http://dotat.at/ FORTIES CROMARTY FORTH TYNE DOGGER: NORTHEAST 4 OR 5, OCCASIONALLY 6 AT FIRST IN CROMARTY. MODERATE. EXTENSIVE FOG AT FIRST IN TYNE, OTHERWISE FOG PATCHES, THEN FAIR. MODERATE OR GOOD, OCCASIONALLY VERY POOR. From torfinn.ingolfsen at broadpark.no Mon May 12 18:43:54 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Mon May 12 18:44:00 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <20080512123207.GA12255@eos.sc1.parodius.com> References: <339469.80542.qm@web26912.mail.ukl.yahoo.com> <20080512113753.67295481.torfinn.ingolfsen@broadpark.no> <20080512134422.6dbe127c.torfinn.ingolfsen@broadpark.no> <20080512123207.GA12255@eos.sc1.parodius.com> Message-ID: <20080512204352.e889411e.torfinn.ingolfsen@broadpark.no> On Mon, 12 May 2008 05:32:07 -0700 Jeremy Chadwick wrote: > Is this machine using pf(4) at all? No. Not intentionally, and not in any way that I can tell: root@kg-vm# uname -a FreeBSD kg-vm.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #11: Mon May 12 16:39:19 CEST 2008 root@kg-vm.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 root@kg-vm# ls -l /dev/pf ls: /dev/pf: No such file or directory root@kg-vm# kldstat Id Refs Address Size Name 1 18 0xffffffff80100000 b09578 kernel 2 1 0xffffffff80c0a000 1a070 snd_hda.ko 3 2 0xffffffff80c25000 68a40 sound.ko 4 1 0xffffffff80c8e000 5100 atapicam.ko 5 1 0xffffffffb1a0f000 1256a ng_btsocket.ko 6 5 0xffffffffb1a22000 92b4 netgraph.ko 7 3 0xffffffffb1a2c000 89a ng_bluetooth.ko 8 1 0xffffffffb1a32000 35e2 vkbd.ko 9 1 0xffffffffb1a36000 aefa fuse.ko 10 1 0xffffffffb1aa5000 56b2 aio.ko 11 1 0xffffffffb1c4b000 268dc kqemu.ko 12 1 0xffffffffb1af0000 4266 ng_ubt.ko 13 1 0xffffffffb1cc7000 8e1a ng_hci.ko 14 1 0xffffffffb1cd0000 ba78 ng_l2cap.ko 15 1 0xffffffffb1ace000 1a9a ng_socket.ko (as you can see, the machine is now updated to latest 7-stable) -- Regards, Torfinn Ingolfsen From stevefranks at ieee.org Mon May 12 20:38:53 2008 From: stevefranks at ieee.org (Steve Franks) Date: Mon May 12 20:38:55 2008 Subject: umass causes panic on 7 amd64 In-Reply-To: <20080429214640.GA85715@slackbox.xs4all.nl> References: <539c60b90804111420kcb73e6do8a20dce574d13864@mail.gmail.com> <20080412213225.GB24224@slackbox.xs4all.nl> <539c60b90804141549u6a138ad9u9c77bbfcbbad0ff3@mail.gmail.com> <20080415175347.GA29045@slackbox.xs4all.nl> <539c60b90804291032v4a7e80d0w205354d4bf1be842@mail.gmail.com> <20080429214640.GA85715@slackbox.xs4all.nl> Message-ID: <539c60b90805121338n439c1a62sab5be6f6ea9485ff@mail.gmail.com> I have added options USB DEBUG to my kernconf file ("DYSTANT"). Here is the backtrace: Steve [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo kgdb kernel.debug /var/crash/vmcore.6 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: umass0: on uhub2 umass0: SCSI over (unknown 0x00); quirks = 0x0100 panic: /usr/src/sys/dev/usb/umass.c:1453: Unknown proto 0x100 cpuid = 0 Uptime: 3m1s Physical memory: 1002 MB Dumping 97 MB: 82 66 50 34 18 2 #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff8049d169 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff8049d56d in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff80412ee7 in umass_attach (self=0xffffff00014ae300) at /usr/src/sys/dev/usb/umass.c:1452 #5 0xffffffff804bf9c4 in device_attach (dev=0xffffff00014ae300) at device_if.h:178 #6 0xffffffff8041b8e1 in usbd_new_device (parent=0xffffff0001246000, bus=0xffffffff80e49000, depth=Variable "depth" is not available. ) at /usr/src/sys/dev/usb/usb_subr.c:932 #7 0xffffffff8040ebb2 in uhub_explore (dev=0xffffff0001245c00) at /usr/src/sys/dev/usb/uhub.c:523 #8 0xffffffff804177da in usb_discover (v=0xffffff000126e680) at /usr/src/sys/dev/usb/usb.c:724 #9 0xffffffff80418990 in usb_event_thread (arg=Variable "arg" is not available. ) at /usr/src/sys/dev/usb/usb.c:440 #10 0xffffffff8047e883 in fork_exit (callout=0xffffffff80418880 , arg=0xffffff000126e680, frame=0xffffffffa035ac80) at /usr/src/sys/kern/kern_fork.c:781 #11 0xffffffff8073b4ae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:415 #12 0x0000000000000000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000001 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000dd8000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000004 in ?? () #39 0xffffff00012788d0 in ?? () #40 0xffffff0001087340 in ?? () #41 0xffffff0001258680 in ?? () #42 0xffffffffa0359c48 in ?? () #43 0xffffff0001258680 in ?? () #44 0xffffffff804bae29 in sched_switch (td=0xffffff000126e680, newtd=0xffffffff80418880, flags=0) at /usr/src/sys/kern/sched_4bsd.c:905 #45 0x0000000000000000 in ?? () #46 0x0000000000000000 in ?? () #47 0x0000000000000000 in ?? () #48 0x0000000000000000 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () #113 0x0000000000000000 in ?? () #114 0x0000000000000000 in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () #117 0x01263f4001263f80 in ?? () #118 0x01263ec001263f00 in ?? () #119 0x01263e4001263e80 in ?? () #120 0x01263dc001263e00 in ?? () #121 0x01263d4001263d80 in ?? () #122 0x01263cc001263d00 in ?? () #123 0x01263c4001263c80 in ?? () #124 0x01263bc001263c00 in ?? () #125 0x01263b4001263b80 in ?? () #126 0x01263ac001263b00 in ?? () #127 0x01263a4001263a80 in ?? () #128 0x012639c001263a00 in ?? () #129 0x0126394001263980 in ?? () #130 0x012638c001263900 in ?? () #131 0x0126384001263880 in ?? () #132 0x012637c001263800 in ?? () #133 0x0126374001263780 in ?? () #134 0x012636c001263700 in ?? () #135 0x0126364001263680 in ?? () #136 0x012635c001263600 in ?? () #137 0x0126354001263580 in ?? () #138 0x012634c001263500 in ?? () #139 0x0126344001263480 in ?? () #140 0x012633c001263400 in ?? () #141 0x0126334001263380 in ?? () #142 0x012632c001263300 in ?? () #143 0x0126324001263280 in ?? () #144 0x012631c001263200 in ?? () #145 0x0126314001263180 in ?? () #146 0x012630c001263100 in ?? () ---Type to continue, or q to quit--- #147 0x0126304001263080 in ?? () #148 0x01265fc001263000 in ?? () #149 0x01265f4001265f80 in ?? () #150 0x01265ec001265f00 in ?? () #151 0x01265e4001265e80 in ?? () #152 0x01265dc001265e00 in ?? () #153 0x01265d4001265d80 in ?? () #154 0x01265cc001265d00 in ?? () #155 0x01265c4001265c80 in ?? () #156 0x01265bc001265c00 in ?? () #157 0x01265b4001265b80 in ?? () #158 0x01265ac001265b00 in ?? () #159 0x01265a4001265a80 in ?? () #160 0x012659c001265a00 in ?? () #161 0x0126594001265980 in ?? () #162 0x012658c001265900 in ?? () #163 0x0126584001265880 in ?? () #164 0x012657c001265800 in ?? () #165 0x0126574001265780 in ?? () #166 0x012656c001265700 in ?? () #167 0x0126564001265680 in ?? () #168 0x012655c001265600 in ?? () #169 0x0126554001265580 in ?? () #170 0x012654c001265500 in ?? () #171 0x0126544001265480 in ?? () #172 0x012653c001265400 in ?? () #173 0x0126534001265380 in ?? () #174 0x012652c001265300 in ?? () #175 0x0126524001265280 in ?? () #176 0x012651c001265200 in ?? () #177 0x0126514001265180 in ?? () #178 0x012650c001265100 in ?? () #179 0x0126504001265080 in ?? () #180 0x01267fc001265000 in ?? () #181 0x01263f4001263f80 in ?? () #182 0x01263ec001263f00 in ?? () #183 0x01263e4001263e80 in ?? () #184 0x01263dc001263e00 in ?? () #185 0x01263d4001263d80 in ?? () #186 0x01263cc001263d00 in ?? () #187 0x01263c4001263c80 in ?? () #188 0x01263bc001263c00 in ?? () #189 0x01263b4001263b80 in ?? () #190 0x01263ac001263b00 in ?? () #191 0x01263a4001263a80 in ?? () #192 0x012639c001263a00 in ?? () #193 0x0126394001263980 in ?? () #194 0x012638c001263900 in ?? () #195 0x0126384001263880 in ?? () #196 0x012637c001263800 in ?? () #197 0x0126374001263780 in ?? () #198 0x012636c001263700 in ?? () #199 0x0126364001263680 in ?? () #200 0x012635c001263600 in ?? () #201 0x0126354001263580 in ?? () #202 0x012634c001263500 in ?? () #203 0x0126344001263480 in ?? () #204 0x012633c001263400 in ?? () #205 0x0126334001263380 in ?? () #206 0x012632c001263300 in ?? () #207 0x0126324001263280 in ?? () #208 0x012631c001263200 in ?? () #209 0x0126314001263180 in ?? () #210 0x012630c001263100 in ?? () #211 0x0126304001263080 in ?? () #212 0x01265fc001263000 in ?? () #213 0x01265f4001265f80 in ?? () #214 0x01265ec001265f00 in ?? () #215 0x01265e4001265e80 in ?? () #216 0x01265dc001265e00 in ?? () From rsmith at xs4all.nl Mon May 12 22:50:52 2008 From: rsmith at xs4all.nl (Roland Smith) Date: Mon May 12 22:50:56 2008 Subject: umass causes panic on 7 amd64 In-Reply-To: <539c60b90805121338n439c1a62sab5be6f6ea9485ff@mail.gmail.com> References: <539c60b90804111420kcb73e6do8a20dce574d13864@mail.gmail.com> <20080412213225.GB24224@slackbox.xs4all.nl> <539c60b90804141549u6a138ad9u9c77bbfcbbad0ff3@mail.gmail.com> <20080415175347.GA29045@slackbox.xs4all.nl> <539c60b90804291032v4a7e80d0w205354d4bf1be842@mail.gmail.com> <20080429214640.GA85715@slackbox.xs4all.nl> <539c60b90805121338n439c1a62sab5be6f6ea9485ff@mail.gmail.com> Message-ID: <20080512225049.GA35802@slackbox.xs4all.nl> On Mon, May 12, 2008 at 01:38:51PM -0700, Steve Franks wrote: > I have added options USB DEBUG to my kernconf file ("DYSTANT"). Here > is the backtrace: > > Steve > > [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo kgdb kernel.debug > /var/crash/vmcore.6 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > umass0: on uhub2 > umass0: SCSI over (unknown 0x00); quirks = 0x0100 > panic: /usr/src/sys/dev/usb/umass.c:1453: Unknown proto 0x100 It looks like the camera is not returning a wire protocol. You definitely need to take this to the -usb list. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080512/95aaffb5/attachment.pgp From stevefranks at ieee.org Mon May 12 23:19:28 2008 From: stevefranks at ieee.org (Steve Franks) Date: Mon May 12 23:19:34 2008 Subject: umass causes panic on 7 amd64 In-Reply-To: <20080512225049.GA35802@slackbox.xs4all.nl> References: <539c60b90804111420kcb73e6do8a20dce574d13864@mail.gmail.com> <20080412213225.GB24224@slackbox.xs4all.nl> <539c60b90804141549u6a138ad9u9c77bbfcbbad0ff3@mail.gmail.com> <20080415175347.GA29045@slackbox.xs4all.nl> <539c60b90804291032v4a7e80d0w205354d4bf1be842@mail.gmail.com> <20080429214640.GA85715@slackbox.xs4all.nl> <539c60b90805121338n439c1a62sab5be6f6ea9485ff@mail.gmail.com> <20080512225049.GA35802@slackbox.xs4all.nl> Message-ID: <539c60b90805121619g3d7afe70yd7e733fea012ae9d@mail.gmail.com> On Mon, May 12, 2008 at 3:50 PM, Roland Smith wrote: > On Mon, May 12, 2008 at 01:38:51PM -0700, Steve Franks wrote: > > I have added options USB DEBUG to my kernconf file ("DYSTANT"). Here > > is the backtrace: > > > > Steve > > > > [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo kgdb kernel.debug > > /var/crash/vmcore.6 > > [GDB will not be able to debug user-mode threads: > > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "amd64-marcel-freebsd". > > > > Unread portion of the kernel message buffer: > > umass0: on uhub2 > > umass0: SCSI over (unknown 0x00); quirks = 0x0100 > > panic: /usr/src/sys/dev/usb/umass.c:1453: Unknown proto 0x100 > > It looks like the camera is not returning a wire protocol. > You definitely need to take this to the -usb list. > > > > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) > Still shouldn't cause a panic, should it? Steve From bazzoola at gmail.com Tue May 13 01:22:39 2008 From: bazzoola at gmail.com (bazzoola) Date: Tue May 13 01:23:07 2008 Subject: kqemu support: not compiled Message-ID: Greetings, I just cant get kqemu to work on my AMD64 SMP! I setenv WITH_KQEMU I compiled the port with make -DWITH_KQEMU I edited src.conf and added WITH_KQEMU=yes I make config and checked KQEMU ALPHA support I am running #uname -a FreeBSD Aa.bsd 7.0-STABLE FreeBSD 7.0-STABLE #3: Mon Apr 21 05:56:16 CDT 2008 root@Aa.bsd:/usr/obj/usr/src/sys/GENERIC amd64 #pkg_info | grep qemu kqemu-kmod-1.3.0.p11_6 qemu-devel-0.9.1s.20080302_6 latest as you as see ^^^ any ideas? From alex.kovalenko at verizon.net Tue May 13 02:03:44 2008 From: alex.kovalenko at verizon.net (Alexandre "Sunny" Kovalenko) Date: Tue May 13 02:03:49 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 Message-ID: <1210640542.1008.33.camel@RabbitsDen> I seem to be able to lock my machine by going into wpa_cli and asking it to 'reassoc'. The reason for question mark after "hard" is that debug information (caused by wlandebug and athdebug) is being printed on the console. The only way to get machine's attention is to hold power button for 8 seconds. Note: manual reassociation is just the handy way to reproduce the problem -- I have had machine locking up on me the whole day long completely on its own. Below are, what I think, relevant pieces of information. If anything is missing, please, chastise me appropriately and will do my best to provide. I have rigged firewire console, but am unable to break into the debugger locally or remotely. While I am on the subject, I would appreciate couple of the troubleshooting suggestions: * is there any way to get sysctl dev.ath.0.debug to appear, other then defining ATH_DEBUG in something like /usr/src/sys/dev/ath/ah_osdep.h? * is there minimal, but still usable mask for athdebug and wlandebug? I have started with 0xFFFFFFFF and kept trimming likely high-volume settings until output slowed down to the reasonable pace. * what facility does wpa_supplicant use, when forced to syslog by -s switch? ======================================================================= * OS: RELENG_7 cvsup'ed on May 11th @ 15:30EST, if_ath is loaded as the module * HW: ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212 Atheros AR5212 802.11abg wireless' class = network subclass = ethernet ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: xx:xx:xx:xx:xx:xx ath0: mac 10.3 phy 6.1 radio 10.2 * Debug settings: net.wlan.0.debug: 0xdfffffff<11n,debug,crypto,input,xrate,elemid,node,assoc,auth,scan,output,state,power,dot1x,dot1xsm,radius,raddump,radkeys,wpa,acl,wme,superg,doth,inact,roam,rate> dev.ath.0.debug: 0xffef8ff0 * Console output (somewhat trimmed) is attached -- last group of messages keeps repeating until I power down the machine. * Output of 'wpa_supplicant -Dbsd -iath0 -d -d -K -c/etc/wpa_supplicant.conf' (hand transcribed) is: Starting AP scan (specific SSID) Scan SSID = hexdump_ascii (len = NN) xx xx xx xx xx xx * /etc/wpa_supplicant.conf is attached * Setup: two stations with the identical SSID: Linksys WRT54Gv8 (running dd-wrt micro) at about 50' and Zyxel P-330W at about 20'. -- Alexandre "Sunny" Kovalenko (????????? ?????????) -------------- next part -------------- # # $Log$ # ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="xxxxxxxxxxx" scan_ssid=1 priority=1 key_mgmt=WPA-PSK psk="xxxxxxxxxxxxxxxxxxxxxxxxxx" } From sam at freebsd.org Tue May 13 02:33:10 2008 From: sam at freebsd.org (Sam Leffler) Date: Tue May 13 02:33:14 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <1210640542.1008.33.camel@RabbitsDen> References: <1210640542.1008.33.camel@RabbitsDen> Message-ID: <4828FDE5.8090409@freebsd.org> Alexandre "Sunny" Kovalenko wrote: > I seem to be able to lock my machine by going into wpa_cli and asking it > to 'reassoc'. The reason for question mark after "hard" is that debug > information (caused by wlandebug and athdebug) is being printed on the > console. The only way to get machine's attention is to hold power button > for 8 seconds. So this is just livelock due to console debug msgs. > > Note: manual reassociation is just the handy way to reproduce the > problem -- I have had machine locking up on me the whole day long > completely on its own. > > Below are, what I think, relevant pieces of information. If anything is > missing, please, chastise me appropriately and will do my best to > provide. I have rigged firewire console, but am unable to break into the > debugger locally or remotely. I see no log msgs. > > While I am on the subject, I would appreciate couple of the > troubleshooting suggestions: > * is there any way to get sysctl dev.ath.0.debug to appear, other then > defining ATH_DEBUG in something like /usr/src/sys/dev/ath/ah_osdep.h? options ATH_DEBUG > * is there minimal, but still usable mask for athdebug and wlandebug? I > have started with 0xFFFFFFFF and kept trimming likely high-volume > settings until output slowed down to the reasonable pace. Why do you want debug msgs from ath? The debug msgs from wlandebug depend on what you're trying to debug. I suggest that when debugging you start from the highest layer and move downward. If you can't find what you need in a wpa_supplicant log then turn on msgs in net80211 with wlandebug. If that doesn't tell you what you need then move to the driver. Blindly turning everything on can easily livelock your system. For high volume msgs I often do something like: athdebug +intr; sleep 1; athdebug -intr or athdebug +intr; read x; athdebug -intr so a carriage return will disable msgs. > * what facility does wpa_supplicant use, when forced to syslog by -s > switch? trouble% cd /data/freebsd/head/contrib/wpa_supplicant/ trouble% grep openlog *.c common.c: openlog("wpa_supplicant", LOG_PID | LOG_NDELAY, LOG_DAEMON); > > ======================================================================= > > * OS: > RELENG_7 cvsup'ed on May 11th @ 15:30EST, if_ath is loaded as the module > > * HW: > ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01 > hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR5212 Atheros AR5212 802.11abg wireless' > class = network > subclass = ethernet > ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on > pci3 > ath0: [ITHREAD] > ath0: using obsoleted if_watchdog interface > ath0: Ethernet address: xx:xx:xx:xx:xx:xx > ath0: mac 10.3 phy 6.1 radio 10.2 > > * Debug settings: > net.wlan.0.debug: > 0xdfffffff<11n,debug,crypto,input,xrate,elemid,node,assoc,auth,scan,output,state,power,dot1x,dot1xsm,radius,raddump,radkeys,wpa,acl,wme,superg,doth,inact,roam,rate> > dev.ath.0.debug: > 0xffef8ff0 > > * Console output (somewhat trimmed) is attached -- last group of > messages keeps repeating until I power down the machine. > > * Output of 'wpa_supplicant -Dbsd -iath0 -d -d -K > -c/etc/wpa_supplicant.conf' (hand transcribed) is: > > Starting AP scan (specific SSID) > Scan SSID = hexdump_ascii (len = NN) > xx xx xx xx xx xx > > * /etc/wpa_supplicant.conf is attached > > * Setup: two stations with the identical SSID: Linksys WRT54Gv8 (running > dd-wrt micro) at about 50' and Zyxel P-330W at about 20'. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From bazzoola at gmail.com Tue May 13 03:34:32 2008 From: bazzoola at gmail.com (bazzoola) Date: Tue May 13 03:34:40 2008 Subject: kqemu support: not compiled In-Reply-To: <20080513022054.5607C5B4B@mail.bitblocks.com> References: <20080513022054.5607C5B4B@mail.bitblocks.com> Message-ID: <86C46F8C-0F2F-4E80-8737-BF5BFF324C93@gmail.com> On May 12, 2008, at 10:20 PM, Bakul Shah wrote: >> I just cant get kqemu to work on my AMD64 SMP! > > echo kqemu_enable=YES >> /etc/rc.conf > /usr/local/etc/rc.d/kqemu start Is this documented anywhere? Also, I volunteered to update the wiki and the author was grateful for that but I didn't get access. If anyone cares. I can just send the updates here via email. Thanks! From bazzoola at gmail.com Tue May 13 04:18:38 2008 From: bazzoola at gmail.com (bazzoola) Date: Tue May 13 04:18:42 2008 Subject: kqemu support: not compiled In-Reply-To: <20080513022054.5607C5B4B@mail.bitblocks.com> References: <20080513022054.5607C5B4B@mail.bitblocks.com> Message-ID: On May 12, 2008, at 10:20 PM, Bakul Shah wrote: >> I just cant get kqemu to work on my AMD64 SMP! > > echo kqemu_enable=YES >> /etc/rc.conf > /usr/local/etc/rc.d/kqemu start I looked at the rc script and all it does is kldload aio and kqemu. I already have them loaded by default. This still does not help me with my problem. I press Ctrl + Alt + 2 then I type info kqemu I get "kqemu support: not compiled" From pldrouin at pldrouin.net Tue May 13 04:42:20 2008 From: pldrouin at pldrouin.net (Pierre-Luc Drouin) Date: Tue May 13 04:42:25 2008 Subject: Status of ZFS in -stable? Message-ID: <48291889.8030406@pldrouin.net> Hi, I would like to know if the memory allocation problem with zfs has been fixed in -stable? Is zfs considered to be more "stable" now? Thanks! Pierre-Luc Drouin From bazzoola at gmail.com Tue May 13 04:43:23 2008 From: bazzoola at gmail.com (bazzoola) Date: Tue May 13 04:43:28 2008 Subject: kqemu support: not compiled In-Reply-To: References: <20080513022054.5607C5B4B@mail.bitblocks.com> Message-ID: <4FCC3D24-8F38-420E-A251-182C50E08476@gmail.com> On May 13, 2008, at 12:24 AM, Brandon S. Allbery KF8NH wrote: > > On 2008 May 13, at 0:18, bazzoola wrote: > >> I press Ctrl + Alt + 2 >> then I type info kqemu >> I get "kqemu support: not compiled" > > > Without looking, I'd guess this means the qemu binary was built > without kqemu support enabled. > as I stated before (which u omitted) I DID enabled kqemu everywhere and then built qemu but still I get that error not compiled. setenv WITH_KQEMU edited src.conf and added WITH_KQEMU=yes did make config and checked KQEMU ALPHA support compiled the port with make -DWITH_KQEMU how do you compile qemu binary with kqemu? other than the 4 things above? > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university > KF8NH > > From allbery at ece.cmu.edu Tue May 13 04:52:35 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue May 13 04:52:39 2008 Subject: kqemu support: not compiled In-Reply-To: References: <20080513022054.5607C5B4B@mail.bitblocks.com> Message-ID: On 2008 May 13, at 0:18, bazzoola wrote: > I press Ctrl + Alt + 2 > then I type info kqemu > I get "kqemu support: not compiled" Without looking, I'd guess this means the qemu binary was built without kqemu support enabled. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bakul at bitblocks.com Tue May 13 05:11:13 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Tue May 13 05:11:16 2008 Subject: kqemu support: not compiled In-Reply-To: Your message of "Tue, 13 May 2008 00:18:32 EDT." Message-ID: <20080513045159.1563C5B4B@mail.bitblocks.com> On Tue, 13 May 2008 00:18:32 EDT bazzoola wrote: > > On May 12, 2008, at 10:20 PM, Bakul Shah wrote: > > >> I just cant get kqemu to work on my AMD64 SMP! > > > > echo kqemu_enable=YES >> /etc/rc.conf > > /usr/local/etc/rc.d/kqemu start This should probably be described in pkg-message. > I looked at the rc script and all it does is kldload aio and kqemu. I > already have them loaded by default. You didn't provide information so I had to guess. > This still does not help me with my problem. > > I press Ctrl + Alt + 2 > then I type info kqemu > I get "kqemu support: not compiled" Are you running qemu? It is an i386 emulator and won't use kqemu on amd64. You need to run qemu-system-x86_64. I know, this is a bit confusing. If you are still having problems provide the *exact sequence* of commands you used to build and run qemu. BTW, to build you don't need to muck with environ. var. or -DWITH_KQEMU. Just do make config && make From pldrouin at pldrouin.net Tue May 13 05:32:37 2008 From: pldrouin at pldrouin.net (Pierre-Luc Drouin) Date: Tue May 13 05:32:42 2008 Subject: Status of ZFS in -stable? Message-ID: <482927F3.20409@pldrouin.net> Hi, I would like to know if the memory allocation problem with zfs has been fixed in -stable? Is zfs considered to be more "stable" now? Thanks! Pierre-Luc Drouin From bazzoola at gmail.com Tue May 13 05:33:36 2008 From: bazzoola at gmail.com (bazzoola) Date: Tue May 13 05:33:42 2008 Subject: kqemu support: not compiled In-Reply-To: <20080513045159.1563C5B4B@mail.bitblocks.com> References: <20080513045159.1563C5B4B@mail.bitblocks.com> Message-ID: Thanks for your quick reply I appreciate that! Please see below: On May 13, 2008, at 12:51 AM, Bakul Shah wrote: > On Tue, 13 May 2008 00:18:32 EDT bazzoola wrote: >> >> On May 12, 2008, at 10:20 PM, Bakul Shah wrote: >> >>>> I just cant get kqemu to work on my AMD64 SMP! >>> >>> echo kqemu_enable=YES >> /etc/rc.conf >>> /usr/local/etc/rc.d/kqemu start > > This should probably be described in pkg-message. It is not there. > > >> I looked at the rc script and all it does is kldload aio and kqemu. I >> already have them loaded by default. > > You didn't provide information so I had to guess. My problem lies in qemu not being compiled with kqemu > > >> This still does not help me with my problem. >> >> I press Ctrl + Alt + 2 >> then I type info kqemu >> I get "kqemu support: not compiled" > > Are you running qemu? It is an i386 emulator and won't use > kqemu on amd64. You need to run qemu-system-x86_64. I know, > this is a bit confusing. I thought qemu on x64 runs that directly. My bad.. Note I had to run qemu-system-x86_64 -kernel-kqemu to get kernel mode virtz to work otherwise it will just load it in user mode. Thanks again for your help! > > > If you are still having problems provide the *exact sequence* > of commands you used to build and run qemu. BTW, to build > you don't need to muck with environ. var. or -DWITH_KQEMU. > Just do > > make config && make From rsmith at xs4all.nl Tue May 13 06:18:19 2008 From: rsmith at xs4all.nl (Roland Smith) Date: Tue May 13 06:18:24 2008 Subject: umass causes panic on 7 amd64 In-Reply-To: <539c60b90805121619g3d7afe70yd7e733fea012ae9d@mail.gmail.com> References: <539c60b90804111420kcb73e6do8a20dce574d13864@mail.gmail.com> <20080412213225.GB24224@slackbox.xs4all.nl> <539c60b90804141549u6a138ad9u9c77bbfcbbad0ff3@mail.gmail.com> <20080415175347.GA29045@slackbox.xs4all.nl> <539c60b90804291032v4a7e80d0w205354d4bf1be842@mail.gmail.com> <20080429214640.GA85715@slackbox.xs4all.nl> <539c60b90805121338n439c1a62sab5be6f6ea9485ff@mail.gmail.com> <20080512225049.GA35802@slackbox.xs4all.nl> <539c60b90805121619g3d7afe70yd7e733fea012ae9d@mail.gmail.com> Message-ID: <20080513054230.GA47218@slackbox.xs4all.nl> On Mon, May 12, 2008 at 04:19:27PM -0700, Steve Franks wrote: > On Mon, May 12, 2008 at 3:50 PM, Roland Smith wrote: > > On Mon, May 12, 2008 at 01:38:51PM -0700, Steve Franks wrote: > > > I have added options USB DEBUG to my kernconf file ("DYSTANT"). Here > > > is the backtrace: > > > > > > Steve > > > > > > [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo kgdb kernel.debug > > > /var/crash/vmcore.6 > > > [GDB will not be able to debug user-mode threads: > > > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and you are > > > welcome to change it and/or distribute copies of it under certain conditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > > This GDB was configured as "amd64-marcel-freebsd". > > > > > > Unread portion of the kernel message buffer: > > > umass0: on uhub2 > > > umass0: SCSI over (unknown 0x00); quirks = 0x0100 > > > panic: /usr/src/sys/dev/usb/umass.c:1453: Unknown proto 0x100 > > > > It looks like the camera is not returning a wire protocol. > > You definitely need to take this to the -usb list. > > Still shouldn't cause a panic, should it? Yes it should. It calls the 'panic' function. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080513/1e2cfb36/attachment.pgp From danger at FreeBSD.org Tue May 13 08:42:16 2008 From: danger at FreeBSD.org (Daniel Gerzo) Date: Tue May 13 08:42:20 2008 Subject: Status of ZFS in -stable? In-Reply-To: <48291889.8030406@pldrouin.net> References: <48291889.8030406@pldrouin.net> Message-ID: <1618815695.20080513104205@rulez.sk> Hello Pierre-Luc, Tuesday, May 13, 2008, 6:26:49 AM, you wrote: > Hi, > I would like to know if the memory allocation problem with zfs has been > fixed in -stable? Is zfs considered to be more "stable" now? It's still an experimental feature in FreeBSD, though the memory allocation issues might have been already fixed (I don't know personally). Many people have reported success stories when using ZFS on FreeBSD, however there's also plenty of them who are reporting substantial issues when using ZFS. It's up to your own decision whether ZFS will be feasible for you; you might want to test it before deploying it to the production environment. -- Best regards, Daniel mailto:danger@FreeBSD.org From hugo at barafranca.com Tue May 13 12:08:57 2008 From: hugo at barafranca.com (Hugo Silva) Date: Tue May 13 12:09:07 2008 Subject: Status of ZFS in -stable? In-Reply-To: <1618815695.20080513104205@rulez.sk> References: <48291889.8030406@pldrouin.net> <1618815695.20080513104205@rulez.sk> Message-ID: <4829735A.6080103@barafranca.com> Daniel Gerzo wrote: > Hello Pierre-Luc, > > Tuesday, May 13, 2008, 6:26:49 AM, you wrote: > > >> Hi, >> > > >> I would like to know if the memory allocation problem with zfs has been >> fixed in -stable? Is zfs considered to be more "stable" now? >> > > It's still an experimental feature in FreeBSD, though the memory > allocation issues might have been already fixed (I don't know > personally). > > Many people have reported success stories when using ZFS on FreeBSD, > however there's also plenty of them who are reporting substantial issues > when using ZFS. It's up to your own decision whether ZFS will be > feasible for you; you might want to test it before deploying it to the > production environment. > > FWIW, I've been using ZFS on two "jail servers" for months without any visible issues. 7.0-RELEASE/amd64. Hugo From petefrench at ticketswitch.com Tue May 13 14:18:38 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue May 13 14:18:44 2008 Subject: Changing an installed system from i386 to amd64 Message-ID: I have a box currently running i386 which I want to change over to run amd64. I have installed a second drive into the machine on which I have put a basic install of amd64, and have compiled up the world and kertnel from source. Can I simply switch the original partition over by mounting it up and doin a 'make installworld' with an approrpiate DESTDIR set ? I guess what I am asking is if anything else is different between the two versions aside from the actual binaries themselves (i.e. directory layout and the like). -pete. From saper at system.pl Tue May 13 14:29:24 2008 From: saper at system.pl (Marcin Cieslak) Date: Tue May 13 14:29:34 2008 Subject: Status of ZFS in -stable? In-Reply-To: <4829735A.6080103@barafranca.com> References: <48291889.8030406@pldrouin.net> <1618815695.20080513104205@rulez.sk> <4829735A.6080103@barafranca.com> Message-ID: <4829A5AF.9070102@system.pl> Hugo Silva wrote: > Daniel Gerzo wrote: >> Hello Pierre-Luc, >> >> Tuesday, May 13, 2008, 6:26:49 AM, you wrote: >> >> >>> Hi, >>> >> >> >>> I would like to know if the memory allocation problem with zfs has been >>> fixed in -stable? Is zfs considered to be more "stable" now? I am using ZFS on my laptop as a typical, heavily used desktop system. I experience some concurrency issues (the machine "locks up" for a moment while the system is doing some work). I am doing some heavy tasks like compiling OpenOffice in my free time. I experience very strange behaviour when running out of space (one of the applications dumped a huge core file that could not be rm(1)'ed because of.... "Not enough space"!). In my personal opinion, the stability of FreeBSD 7.0-stable with ZFS (and maybe other features are at fault, e.g. wpi driver, my ACPI) is not very good. I experience strange hangs and hick-ups, sometimes panics. The good thing about ZFS is that no matter how hard it dies it usually comes up good (once I had to wait a while to let it recover after reboot and reboot the system again cleanly since some files were missing and just re-appeared later). I am bound to use ZFS because it saves me a lot of space (no need for partition split), but as soon as I setup some more external disk space for my laptop I may consider not using it anymore. --Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080513/757c63d7/signature.pgp From saper at system.pl Tue May 13 14:56:49 2008 From: saper at system.pl (Marcin Cieslak) Date: Tue May 13 14:56:53 2008 Subject: Status of ZFS in -stable? In-Reply-To: <4829735A.6080103@barafranca.com> References: <48291889.8030406@pldrouin.net> <1618815695.20080513104205@rulez.sk> <4829735A.6080103@barafranca.com> Message-ID: <4829A5AF.9070102@system.pl> Hugo Silva wrote: > Daniel Gerzo wrote: >> Hello Pierre-Luc, >> >> Tuesday, May 13, 2008, 6:26:49 AM, you wrote: >> >> >>> Hi, >>> >> >> >>> I would like to know if the memory allocation problem with zfs has been >>> fixed in -stable? Is zfs considered to be more "stable" now? I am using ZFS on my laptop as a typical, heavily used desktop system. I experience some concurrency issues (the machine "locks up" for a moment while the system is doing some work). I am doing some heavy tasks like compiling OpenOffice in my free time. I experience very strange behaviour when running out of space (one of the applications dumped a huge core file that could not be rm(1)'ed because of.... "Not enough space"!). In my personal opinion, the stability of FreeBSD 7.0-stable with ZFS (and maybe other features are at fault, e.g. wpi driver, my ACPI) is not very good. I experience strange hangs and hick-ups, sometimes panics. The good thing about ZFS is that no matter how hard it dies it usually comes up good (once I had to wait a while to let it recover after reboot and reboot the system again cleanly since some files were missing and just re-appeared later). I am bound to use ZFS because it saves me a lot of space (no need for partition split), but as soon as I setup some more external disk space for my laptop I may consider not using it anymore. --Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 273 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080513/757c63d7/signature-0001.pgp From petefrench at ticketswitch.com Tue May 13 15:28:05 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue May 13 15:28:14 2008 Subject: Changing an installed system from i386 to amd64 In-Reply-To: <4829AEA6.9080306@gmail.com> Message-ID: > I did roughly the same but slightly different method: ah, and did it work o.k. ? -pete. From aryeh.friedman at gmail.com Tue May 13 15:29:11 2008 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Tue May 13 15:29:19 2008 Subject: Changing an installed system from i386 to amd64 In-Reply-To: References: Message-ID: <4829B3BF.6090201@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pete French wrote: |> I did roughly the same but slightly different method: | | ah, and did it work o.k. ? | | -pete. | Yes and I have been using the system for almost 8 months now as my primary desktop -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgps78ACgkQk8GFzCrQm4DjkwCgg6MUz2w73LZwKV2RorIyxeT7 sjAAn1Wh9NBQsBuR1Ftm2ashZEtc5SEk =W4Z2 -----END PGP SIGNATURE----- From aryeh.friedman at gmail.com Tue May 13 15:37:41 2008 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Tue May 13 15:37:46 2008 Subject: Changing an installed system from i386 to amd64 In-Reply-To: References: Message-ID: <4829AEA6.9080306@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pete French wrote: | I have a box currently running i386 which I want to change over to | run amd64. I have installed a second drive into the machine on which | I have put a basic install of amd64, and have compiled up the world | and kertnel from source. | | Can I simply switch the original partition over by mounting it up | and doin a 'make installworld' with an approrpiate DESTDIR set ? | I guess what I am asking is if anything else is different between | the two versions aside from the actual binaries themselves (i.e. | directory layout and the like). I did roughly the same but slightly different method: 0. Deinstall all ports but record what they are 1. FTP the enitre kernel and base system from what ever version you want 2. Install the kernel with (this assumes 7/8-current): ~ ./install.sh generic 3. Install the base system ~ ./install.sh 4. Reboot (optional) 4a. Get the most recent sources and remake the system with those (optional) 4b. Get and install any other sysinstall distfiles you wish (optional) 4c. Run make delete-old and make delete-old-libs 5. Reinstall all your ports Note: ./install.sh done from what ever dir you put the distfiles in (*DO NOT* intermix kernel and base) 4c is almost not optional -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgprqUACgkQk8GFzCrQm4CtVACeJg9f0SnPG1I1nix/948kHJit GCkAoO8U2D/WCvPJ1Mz3icCCQaQD6180 =o5mP -----END PGP SIGNATURE----- From bakul at bitblocks.com Tue May 13 15:51:13 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Tue May 13 15:51:16 2008 Subject: Changing an installed system from i386 to amd64 In-Reply-To: Your message of "Tue, 13 May 2008 15:18:36 BST." Message-ID: <20080513153303.35BFA5B55@mail.bitblocks.com> On Tue, 13 May 2008 15:18:36 BST Pete French wrote: > I have a box currently running i386 which I want to change over to > run amd64. I have installed a second drive into the machine on which > I have put a basic install of amd64, and have compiled up the world > and kertnel from source. > > Can I simply switch the original partition over by mounting it up > and doin a 'make installworld' with an approrpiate DESTDIR set ? > I guess what I am asking is if anything else is different between > the two versions aside from the actual binaries themselves (i.e. > directory layout and the like). In the 64 bit FreeBSD world, /usr/lib32 contains libraries for the x86 binaries and /lib, /usr/lib contain 64 bit libraries so a straight install may mess things up. At the very least you should backup your 32 bit root partition -- but I have a feeling my advice is already too late :-) Ideally a simple perl script can automate most of this job. May be all you have to do is something like this: for a in lib usr/lib usr/local/lib do mv $DESTDIR/$a $DESTDIR/${a}32 done echo 'ldconfig32_paths="/usr/lib32 /usr/local/lib32"' >> $DESTIDIR/etc/rc.conf Most all old 32 bit ports should work but upgrading them can mess things up. All the new compiles will generate 64 bit binaries but any port dependencies on a shared library will be wrong. Also, not all 32 bit ports work on 64 bit. May be the trick is to save port directory names for all installed ports (e.g. shell/zsh), then blow them all away (after saving a copy somewhere) and then install them again. This really needs to be part of sysinstall. PS: the following may come in handy. Save it in ~/bin/ldd32. #!/bin/sh # ldd for i386 binaries for i in ${1+"$@"} do echo "$i": env LD_32_TRACE_LOADED_OBJECTS=1 "$i" done From petefrench at ticketswitch.com Tue May 13 15:59:12 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue May 13 15:59:15 2008 Subject: Changing an installed system from i386 to amd64 In-Reply-To: <20080513153303.35BFA5B55@mail.bitblocks.com> Message-ID: > In the 64 bit FreeBSD world, /usr/lib32 contains libraries > for the x86 binaries and /lib, /usr/lib contain 64 bit > libraries so a straight install may mess things up. At the > very least you should backup your 32 bit root partition -- > but I have a feeling my advice is already too late :-) heh, not too late, am not *that* impulsive - but I don't see why this will mess things up ? Surely thats exactly what I want to happen, for /usr/lib to become 64 bit to go with the binaries which will aalso become 64 bit. This isn't a running system bear in mind - it a disc from another system which is mounted on a separte machine running 64 bitA, so theres no issue with the binaries needing to run during the changeover. > Most all old 32 bit ports should work but upgrading them can > mess things up. All the new compiles will generate 64 bit > binaries but any port dependencies on a shared library will there are no ports on the amchine so this shouldnt be an issue. > PS: the following may come in handy. Save it in ~/bin/ldd32. thats useful, thanks! -pete. From bakul at bitblocks.com Tue May 13 16:30:16 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Tue May 13 16:30:23 2008 Subject: Changing an installed system from i386 to amd64 In-Reply-To: Your message of "Tue, 13 May 2008 16:59:11 BST." Message-ID: <20080513163015.153205B55@mail.bitblocks.com> On Tue, 13 May 2008 16:59:11 BST Pete French wrote: > > In the 64 bit FreeBSD world, /usr/lib32 contains libraries > > for the x86 binaries and /lib, /usr/lib contain 64 bit > > libraries so a straight install may mess things up. At the > > very least you should backup your 32 bit root partition -- > > but I have a feeling my advice is already too late :-) > > heh, not too late, am not *that* impulsive - but I don't > see why this will mess things up ? Surely thats exactly what > I want to happen, for /usr/lib to become 64 bit to go > with the binaries which will aalso become 64 bit. If you run only the latest standard binaries you are right but typically one acquires useful things over time and it is not always possible to recompile them and also, why bother. From hartzell at alerce.com Tue May 13 16:47:18 2008 From: hartzell at alerce.com (George Hartzell) Date: Tue May 13 16:47:24 2008 Subject: good/best practices for gmirror and gjournal on a pair of disks? Message-ID: <18473.48984.31132.91673@almost.alerce.com> I've been running many of my systems for some time now using gmirror on a pair of identical disks, as described by Ralf at: http://people.freebsd.org/~rse/mirror/ Each disk has single slice that covers almost all of the disk. These slices are combined into the gmirror device (gm0), which is then carved up by bsdlabel into gm0a (/), gm0b (swap), gm0d (/var), gm0e (/tmp), and gm0f (/usr). My latest machine is using Seagate 1TB disks so I thought I should add gjournal to the mix to avoid ugly fsck's if/when the machine doesn't shut down cleanly. I ended up just creating a gm0f.journal and using it for /usr, which basically seems to be working. I'm left with a couple of questions though: - I've read in the gjournal man page that when it is "... configured on top of gmirror(8) or graid3(8) providers, it also keeps them in a consistent state..." I've been trying to figure out if this simply falls out of how gjournal works or if there's explicity collusion with gmirror/graid3 but can't come up with a satisfactory explanation. Can someone walk me through it? Since I'm only gjournal'ing a portion of the underlying gmirror device I assume that I don't get this benefit? - I've also read in the gjournal man page "... that sync(2) and fsync(2) system calls do not work as expected anymore." Does this invalidate any of the assumptions made by various database packages such as postgresql, sqlite, berkeley db, etc.... about if/when/whether their data is safely on the disk? - What's the cleanest gjournal adaptation of rse's two-disk-mirror-everything setup that would be able to avoid tedious gmirror sync's. The best I've come up with is to do two slices per disk, combine the slices into a pair of gmirror devices, bsdlabel the first into gm0a (/), gm0b (swap), gm0d (/var) and gm0e (/tmp) and bsdlabel the second into a gm1f which gets a gjournal device. Alternatively, would it work and/or make sense to give each disk a single slice, combine them into a gmirror, put a gjournal on top of that, then use bsdlabel to slice it up into partitions? Is anyone using gjournal and gmirror for all of the system on a pair of disks in some other configuration? Thanks, g. From minimarmot at gmail.com Tue May 13 16:50:09 2008 From: minimarmot at gmail.com (Ben Kaduk) Date: Tue May 13 16:50:38 2008 Subject: 7.0 issues fixed? upgrade timing? Message-ID: <47d0403c0805130922x62fc479cs47b8a03f41598e00@mail.gmail.com> Hi all, I only just now subscribed, so my apologies if this has been covered and my cursory search missed it. I am seeing a similar issue to the one described in the email below (pasted from a web listing of this list). That is, my ssh connection will occasionally be dropped with the message Disconnecting: Bad packet length 3190815048. (the number is not always the same). I can reliably reproduce this with `cat < /dev/urandom | od -c` from a FreeBSD-current box (a few weeks old, actually, since the build was broken when I last tried to update) as well as from a mac running OS X 10.4 . The system that is killing my connections is: FreeBSD periphrasis.mit.edu 7.0-STABLE FreeBSD 7.0-STABLE #3: Tue Mar 25 14:53:51 EDT 2008 kaduk@periphrasis.mit.edu:/usr/obj/usr/src/sys/PERIPHRASIS amd64 Any thoughts would be appreciated. -Ben Kaduk ------------------ random message from this thread, for some context ------------- * From: Jeremy Chadwick * Date: Mon, 12 May 2008 05:32:07 -0700 On Mon, May 12, 2008 at 01:44:22PM +0200, Torfinn Ingolfsen wrote: On Mon, 12 May 2008 11:37:53 +0200 Torfinn Ingolfsen wrote: FWIW, I had major troubles with re(4) around 7.0-release, and a while later (I had to use patches). After upgrading to 7-stable on 2008-04-12, re(4) is working for me without patches. (sigh).. it seems that I spoke to soon. Murphy just showed up. I still get ssh disconnects (see below) on connections _to_ the machine when transferring largish amounts of data (like when upgrading a port). Here is one example (portupgrading the jdk port): /usr/bin/gcc -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -Damd64 -DARCH='"amd64"' -DRELEASE='"1.6.0_03-p4"' -DFULL_VERSION='"1.6.0_03-p4-root_12_may_2008_13_25-b00"' -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D_ALLBSD_SOURCE -D_LP64=1 -I. -I/usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/javavm/include -I../../../src/solaris/javavm/include -I../../../src/share/native/sun/management -I../../../src/solaris/hpi/include -I../../../src/share/native/common -I../../../src/solaris/native/common -I../../../src/share/native/java/lang/management -I../../../src/solaris/native/java/lang/management -c -o /usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/obj64/ClassLoadingImpl.o ../../../src/share/native/sun/management/ClassLoadingImpl.c Disconnecting: Bad packet length 3601161525. The machine is running: tingo@kg-vm$ uname -a FreeBSD kg-vm.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #10: Sat Apr 12 21:42:55 CEST 2008 root@xxxxxxxxxxxx:/usr/obj/usr/src/sys/GENERIC amd64 and has been up for about 14 days: tingo@kg-vm$ uptime 1:36PM up 14 days, 17:42, 7 users, load averages: 2.15, 1.85, 1.34 I see that if_re.c for RELENG_7 has been updated on April 22nd, so I'll upgrade the machine to latest -stable and see if that works better. Is this machine using pf(4) at all? From alex.kovalenko at verizon.net Tue May 13 16:53:42 2008 From: alex.kovalenko at verizon.net (Alexandre "Sunny" Kovalenko) Date: Tue May 13 16:53:47 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <4828FDE5.8090409@freebsd.org> References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> Message-ID: <1210696676.985.18.camel@RabbitsDen> On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote: > Alexandre "Sunny" Kovalenko wrote: > > I seem to be able to lock my machine by going into wpa_cli and asking it > > to 'reassoc'. The reason for question mark after "hard" is that debug > > information (caused by wlandebug and athdebug) is being printed on the > > console. The only way to get machine's attention is to hold power button > > for 8 seconds. > > So this is just livelock due to console debug msgs. I am not sure, I have parsed this well enough, so I will try to clarify: machine becomes unresponsive *without* any debugging turned on, to an extent that pressing the power button twice *does not* generate ACPI console message (something to the tune of "going into S5 already -- gimme a break"). If I turn ath debugging on, I do see those messages, and only them, scrolling on the console. > > > > > Note: manual reassociation is just the handy way to reproduce the > > problem -- I have had machine locking up on me the whole day long > > completely on its own. > > > > Below are, what I think, relevant pieces of information. If anything is > > missing, please, chastise me appropriately and will do my best to > > provide. I have rigged firewire console, but am unable to break into the > > debugger locally or remotely. > > I see no log msgs. I am sorry -- mailman must have eaten it up -- I have posted them here now: http://members.verizon.net/~akovalenko/Misc/reassoc.log.gz > > > > > While I am on the subject, I would appreciate couple of the > > troubleshooting suggestions: > > * is there any way to get sysctl dev.ath.0.debug to appear, other then > > defining ATH_DEBUG in something like /usr/src/sys/dev/ath/ah_osdep.h? > > options ATH_DEBUG That does not seem to work for if_ath built as the module, sorry for not being clear in that respect. > > > * is there minimal, but still usable mask for athdebug and wlandebug? I > > have started with 0xFFFFFFFF and kept trimming likely high-volume > > settings until output slowed down to the reasonable pace. > > Why do you want debug msgs from ath? The debug msgs from wlandebug > depend on what you're trying to debug. Because neither wpa_supplicant (quoted below), nor wlandebug (in the URL above) gave me the answer -- it looks like we are going into the scan with the specific SSID in mind and never come back, so I went for the next level. However, could you, please, clarify that I understood you correctly -- you *do not* want to see mix of wlandebug and athdebug messages in the report, and I should turn wlandebug off before turning athdebug on, right? > > I suggest that when debugging you start from the highest layer and move > downward. If you can't find what you need in a wpa_supplicant log then > turn on msgs in net80211 with wlandebug. If that doesn't tell you what > you need then move to the driver. Blindly turning everything on can > easily livelock your system. That's what I did -- what I have posted is the end result of the walking down that chain, and I assumed, possibly incorrectly, that you would want result of all three to put things in context. I do apologize for the misunderstanding. > For high volume msgs I often do something > like: > > athdebug +intr; sleep 1; athdebug -intr > > or > > athdebug +intr; read x; athdebug -intr > > so a carriage return will disable msgs. Thank you for the suggestion. > > > > * what facility does wpa_supplicant use, when forced to syslog by -s > > switch? > > trouble% cd /data/freebsd/head/contrib/wpa_supplicant/ > trouble% grep openlog *.c > common.c: openlog("wpa_supplicant", LOG_PID | LOG_NDELAY, LOG_DAEMON); Thank you, should have done this myself, sorry. -- Alexandre "Sunny" Kovalenko (????????? ?????????) From petefrench at ticketswitch.com Tue May 13 16:59:39 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue May 13 16:59:44 2008 Subject: Changing an installed system from i386 to amd64 In-Reply-To: <20080513163015.153205B55@mail.bitblocks.com> Message-ID: > If you run only the latest standard binaries you are right > but typically one acquires useful things over time and it is > not always possible to recompile them and also, why bother. true, but in this case I want to change a more or less vanilla 7-STABLE/i386 to a more or less vanilla 7-STABLE/amd74, just preserving all my user data and config files. It sounds like it should work then, and I'll give it a shot, thanks. -pete. From gaijin.k at gmail.com Tue May 13 17:45:56 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Tue May 13 17:46:01 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: References: Message-ID: <1210699165.2238.1.camel@RabbitsDen> On Mon, 2008-05-12 at 14:52 +1000, Ian Smith wrote: > On Sun, 11 May 2008 jonathan@kc8onw.net wrote: > > Has any work been done recently towards adding SATA Native Command > > Queueing as well as ATA APM and acoustic management to FreeBSD? > > > > I found this PR (with patch) to add APM and acoustic management control to > > atacontrol. The PR was opened in May 2005 has not been changed since > > December 2006 and is still open. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=81692&cat= > > > > I have not been able to find much of anything on SATA NCQ in FreeBSD newer > > than 2005 or 2006 does anyone know anything newer? > > Jeremy has addressed the NCQ issue, about which I know nothing. > > As for APM and AAM, that functionality is handled by sysutils/ataidle, > which that PR appears - on a quick glance - to pretty well duplicate. > > I see phk@ recently added an 'atacontrol spindown' command to HEAD and > RELENG_7 that appears to offer similar functionality to 'ataidle -S > standby_mins' or 'ataidle -I idle_mins', though specified in seconds > instead. However this doesn't address acoustic management. > > Or is ataidle broken for SATA disks? Does not look broken here (RELENG_7): RabbitsDen# ataidle /dev/ad4 Device Info: Model: HTS541010G9SA00 Serial: MP2ZM4X0JWY6WH Firmware Rev: MBZIC60H ATA revision: ATA-7 LBA 48: yes Geometry: 16383 cyls, 16 heads, 63 spt Capacity: 93GB SMART Supported: yes SMART Enabled: yes APM Supported: yes APM Enabled: yes AAM Supported: yes AAM Enabled: yes Current AAM: 1 Vendor Recommends AAM: 1 APM Value: 16638 RabbitsDen# atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 Serial ATA v1.0 Slave: no device present ATA channel 3: Master: no device present Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present atacontrol: ioctl(IOCATADEVICES): Device not configured RabbitsDen# uname -a FreeBSD RabbitsDen.RabbitsLawn.verizon.net 7.0-STABLE FreeBSD 7.0-STABLE #1: Sun May 11 20:31:21 EDT 2008 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/src/sys/i386/compile/TPX60 i386 RabbitsDen# > > cheers, Ian > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Alexandre "Sunny" Kovalenko (????????? ?????????) From bsam at ipt.ru Tue May 13 18:31:38 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Tue May 13 18:31:43 2008 Subject: kqemu support: not compiled In-Reply-To: (bazzoola@gmail.com's message of "Mon\, 12 May 2008 20\:56\:20 -0400") References: Message-ID: <18780206@ipt.ru> On Mon, 12 May 2008 20:56:20 -0400 bazzoola wrote: > I just cant get kqemu to work on my AMD64 SMP! > I setenv WITH_KQEMU > I compiled the port with make -DWITH_KQEMU > I edited src.conf and added WITH_KQEMU=yes > I make config and checked KQEMU ALPHA support > I am running > #uname -a > FreeBSD Aa.bsd 7.0-STABLE FreeBSD 7.0-STABLE #3: Mon Apr 21 05:56:16 > CDT 2008 root@Aa.bsd:/usr/obj/usr/src/sys/GENERIC amd64 > #pkg_info | grep qemu > kqemu-kmod-1.3.0.p11_6 > qemu-devel-0.9.1s.20080302_6 > latest as you as see ^^^ > any ideas? You didn't show the actual command and an error message. -- WBR, bsam From nox at jelal.kn-bremen.de Tue May 13 19:00:49 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Tue May 13 19:00:53 2008 Subject: kqemu support: not compiled In-Reply-To: <20080513045159.1563C5B4B@mail.bitblocks.com> References: Message-ID: <200805131835.m4DIZQZq010014@saturn.kn-bremen.de> In article <20080513045159.1563C5B4B@mail.bitblocks.com> you write: >On Tue, 13 May 2008 00:18:32 EDT bazzoola wrote: >> >> On May 12, 2008, at 10:20 PM, Bakul Shah wrote: >> >> >> I just cant get kqemu to work on my AMD64 SMP! >> > >> > echo kqemu_enable=YES >> /etc/rc.conf >> > /usr/local/etc/rc.d/kqemu start > >This should probably be described in pkg-message. > >> I looked at the rc script and all it does is kldload aio and kqemu. I >> already have them loaded by default. > >You didn't provide information so I had to guess. > >> This still does not help me with my problem. >> >> I press Ctrl + Alt + 2 >> then I type info kqemu >> I get "kqemu support: not compiled" > >Are you running qemu? It is an i386 emulator and won't use >kqemu on amd64. You need to run qemu-system-x86_64. I know, >this is a bit confusing. I just added notes about these two things to the pkg-message(s)... Juergen From peterjeremy at optushome.com.au Tue May 13 19:01:12 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue May 13 19:01:18 2008 Subject: Changing an installed system from i386 to amd64 In-Reply-To: <20080513153303.35BFA5B55@mail.bitblocks.com> References: <20080513153303.35BFA5B55@mail.bitblocks.com> Message-ID: <20080513190057.GH64804@server.vk2pj.dyndns.org> On 2008-May-13 08:33:03 -0700, Bakul Shah wrote: >Most all old 32 bit ports should work but upgrading them can >mess things up. All the new compiles will generate 64 bit >binaries but any port dependencies on a shared library will >be wrong. It's actually somewhat worse than this: When compiling a new port with dependencies, the internal foo_DEPENDS logic will detect the i386 .so but the port's own configuration tools or build process will normally die in interesting ways when they can't actually use that .so. -- 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080513/82ed29cb/attachment.pgp From ben at altus-escon.com Tue May 13 19:36:59 2008 From: ben at altus-escon.com (Ben Stuyts) Date: Tue May 13 19:37:03 2008 Subject: Panic after hung rsync, probably zfs related Message-ID: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> Hi, While doing an rsync from a zfs filesystem to an external usb hd (also zfs), the rsync processes hung in zfs state. I could not kill these processes, although the rest of the server seemingly continued to run fine. The reboot command did not work. Next I tried a shutdown now command. This caused a panic: ... Stopping dhcpd. Shutting down local daemons:. Stopping named. Waiting for PIDS: 106830 second watchdog timeout expired. Shutdown terminated. Tue May 13 21:02:50 CEST 2008 May 13 21:02:50 mars init: /bin/sh on /etc/rc.shutdown terminated abnormally, going to single user mode panic: vrele: negative ref cnt cpuid = 6 Uptime: 8d3h8m21s Physical memory: 8178 MB Dumping 3679 MB: 3664 3648 3632 3616 3600 3584 3568 3552 3536 3520 3504 3488 3472 3456 3440 3424 3408 3392 3376 3360 3344 3328 3312 3296 3280 3264 3248 atl trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fau =Fta tvailr tduoaulb laed dfraeuslst = r0ixp8 v f0axuflftf fcfofdfef 8 0=6 esbuap9e3r girssopr =r e0axdf fifnfsftfrfufcftbi5o4n8,f fp0a er bnpo t= p0rxe1s0e0n0t xipnusitdr u=c t0i;o na ppioci nitde r= =0 00 8:0x8 stack pointer = 0x10:0xfffffffff8c50a50 frame pointer = 0x10:0xfffffffffb54c450 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 44 (irq19: uhci1+) trap number = 12 Yes, it printed all that gibberish. ("double fault" I think it says?) At this point, the server completely hung, and I could not do a bt unfortunately. I had to reset the server. After reboot, savecore did not find a kernel dump. I ran the rsync again and could not reproduce the problem. Although I've had zfs related problems before, this one was new to me. Any idea what happened here? Other info on this machine follows below. Thanks, Ben [mars:~]133: uname -a FreeBSD mars.altus-escon.com 7.0-STABLE FreeBSD 7.0-STABLE #2: Mon Apr 21 08:45:56 CEST 2008 root@mars.altus-escon.com:/usr/obj/usr/src/ sys/MARS amd64 [mars:~]134: cat /boot/loader.conf console="comconsole" zfs_load="YES" vfs.root.mountfrom="zfs:tank" vfs.zfs.prefetch_disable=1 vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_max="768M" [mars:~]135: dmesg Copyright (c) 1992-2008 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 7.0-STABLE #2: Mon Apr 21 08:45:56 CEST 2008 root@mars.altus-escon.com:/usr/obj/usr/src/sys/MARS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (2000.08-MHz K8- class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features = 0xbfebfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE ,CX8 ,APIC ,SEP ,MTRR ,PGE ,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2 =0x4e33d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 8575598592 (8178 MB) avail memory = 8285937664 (7902 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 cpu2: on acpi0 p4tcc2: on cpu2 cpu3: on acpi0 p4tcc3: on cpu3 cpu4: on acpi0 p4tcc4: on cpu4 cpu5: on acpi0 p4tcc5: on cpu5 cpu6: on acpi0 p4tcc6: on cpu6 cpu7: on acpi0 p4tcc7: on cpu7 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: irq 18 at device 2.0 on pci2 pci5: on pcib5 em0: port 0x2000-0x201f mem 0xd8000000-0xd801ffff irq 18 at device 0.0 on pci5 em0: Using MSI interrupt em0: Ethernet address: 00:30:48:7b:88:7e em0: [FILTER] em1: port 0x2020-0x203f mem 0xd8020000-0xd803ffff irq 19 at device 0.1 on pci5 em1: Using MSI interrupt em1: Ethernet address: 00:30:48:7b:88:7f em1: [FILTER] pcib6: at device 0.3 on pci1 pci6: on pcib6 puc0: port 0x3030-0x3037,0x3028-0x302f,0x3020-0x3027,0x3018-0x301f, 0x3010-0x3017,0x3000-0x300f irq 24 at device 1.0 on pci6 puc0: [FILTER] uart0: on puc0 uart0: [FILTER] uart1: on puc0 uart1: [FILTER] ppc0: on puc0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: cannot reserve interrupt, failed. lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 pcib7: at device 4.0 on pci0 pci7: on pcib7 pcib8: at device 6.0 on pci0 pci8: on pcib8 pci0: at device 8.0 (no driver attached) uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd8500000-0xd85003ff irq 17 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered umass0: on uhub3 ums0: on uhub3 ums0: X report 0x0022 not supported device_attach: ums0 attach returned 6 pcib9: at device 30.0 on pci0 pci9: on pcib9 vgapci0: port 0x4000-0x40ff mem 0xd0000000-0xd7ffffff,0xd8220000-0xd822ffff irq 18 at device 1.0 on pci9 em2: port 0x4400-0x443f mem 0xd8200000-0xd821ffff irq 16 at device 2.0 on pci9 em2: Ethernet address: 00:30:48:44:1a:ab em2: [FILTER] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x1890-0x1897,0x1884-0x1887,0x1888-0x188f,0x1880-0x1883,0x1870-0x187f mem 0xd8500400-0xd85007ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio1: type 16550A, console sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forwarding disabled, default to deny, logging limited to 50 packets/ entry by default ZFS filesystem version 6 ZFS storage pool version 6 acd0: DMA limited to UDMA33, controller found non-ATA66 cable acd0: DVDROM at ata0-slave UDMA33 ad4: 143089MB at ata2-master SATA150 ad6: 143089MB at ata3-master SATA150 SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #7 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-3 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from zfs:tank em1: link state changed to UP em0: link state changed to UP em0: link state changed to DOWN em0: link state changed to UP umass1: on uhub3 da1 at umass-sim1 bus 1 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) From delphij at delphij.net Tue May 13 19:53:37 2008 From: delphij at delphij.net (Xin LI) Date: Tue May 13 19:53:47 2008 Subject: Panic after hung rsync, probably zfs related In-Reply-To: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> References: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> Message-ID: <4829F1B8.1000707@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ben Stuyts wrote: | Hi, | | While doing an rsync from a zfs filesystem to an external usb hd (also | zfs), the rsync processes hung in zfs state. I could not kill these | processes, although the rest of the server seemingly continued to run | fine. The reboot command did not work. Next I tried a shutdown now | command. This caused a panic: Sound like you somehow run out of memory, there is an known issue with ZFS which causes livelock when there is memory pressure. Which rsync version are you using? With rsync 3.x the memory usage would drop drastically which would help to prevent this from happening. Cheers, - -- ** Help China's quake relief at http://www.redcross.org.cn/ |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkgp8bcACgkQi+vbBBjt66DQQgCfSObZqsQNCteT9SsjDTIqAa2E xfgAnAs9reRKfjaJdS9RAco0cnD7JZp0 =J4+1 -----END PGP SIGNATURE----- From mcdouga9 at egr.msu.edu Tue May 13 20:36:25 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Tue May 13 20:36:29 2008 Subject: good/best practices for gmirror and gjournal on a pair of disks? In-Reply-To: <18473.48984.31132.91673@almost.alerce.com> References: <18473.48984.31132.91673@almost.alerce.com> Message-ID: <4829FBC8.5040101@egr.msu.edu> George Hartzell wrote: > I've been running many of my systems for some time now using gmirror > on a pair of identical disks, as described by Ralf at: > > http://people.freebsd.org/~rse/mirror/ > > Each disk has single slice that covers almost all of the disk. These > slices are combined into the gmirror device (gm0), which is then > carved up by bsdlabel into gm0a (/), gm0b (swap), gm0d (/var), gm0e > (/tmp), and gm0f (/usr). > > My latest machine is using Seagate 1TB disks so I thought I should add > gjournal to the mix to avoid ugly fsck's if/when the machine doesn't > shut down cleanly. I ended up just creating a gm0f.journal and using > it for /usr, which basically seems to be working. > > I'm left with a couple of questions though: > > - I've read in the gjournal man page that when it is "... configured > on top of gmirror(8) or graid3(8) providers, it also keeps them in > a consistent state..." I've been trying to figure out if this > simply falls out of how gjournal works or if there's explicity > collusion with gmirror/graid3 but can't come up with a > satisfactory explanation. Can someone walk me through it? > > Since I'm only gjournal'ing a portion of the underlying gmirror > device I assume that I don't get this benefit? > > - I've also read in the gjournal man page "... that sync(2) and > fsync(2) system calls do not work as expected anymore." Does this > invalidate any of the assumptions made by various database > packages such as postgresql, sqlite, berkeley db, etc.... about > if/when/whether their data is safely on the disk? > > - What's the cleanest gjournal adaptation of rse's > two-disk-mirror-everything setup that would be able to avoid > tedious gmirror sync's. The best I've come up with is to do two > slices per disk, combine the slices into a pair of gmirror > devices, bsdlabel the first into gm0a (/), gm0b (swap), gm0d > (/var) and gm0e (/tmp) and bsdlabel the second into a gm1f which > gets a gjournal device. > > Alternatively, would it work and/or make sense to give each disk a > single slice, combine them into a gmirror, put a gjournal on top > of that, then use bsdlabel to slice it up into partitions? > > Is anyone using gjournal and gmirror for all of the system on a pair > of disks in some other configuration? > > Thanks, > > g. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > I am pasting below the instructions I would use to convert a recently installed system with only / (root) and swap to be using gmirror+gjournal. It is in mediawiki markup format so it could be pasted into one if desired. I based my gmirror steps on the instructions from http://people.freebsd.org/~rse/mirror/ so thats why some of the words sound familiar. I also have similar instructions for setting up a gmirrored da0s1a and da0s1b alongside a zfs mirror containing the rest. I decided to journal /usr /var /tmp and leave / as a standard UFS partition because it is so small, fsck doesn't take long anyway and hopefully doesn't get written to enough to cause damage by an abrupt reboot. Because I'm not journaling the root partition, I chose to ignore the possibility of gjournal marking the mirror clean. Sudden reboots don't happen enough on servers for me to care. And all my servers got abruptly rebooted this sunday and they all came up fine :) I believe gjournal uses 1G for journal (2x512) which seemed to be sufficient on all of the systems where I have used the default, but I quickly found that using a smaller journal is a bad idea and leads to panics that I was unable to avoid with tuning. Considering 1G was such a close value, I chose to go several times above the default journal size (disk is cheap and I want to be sure) but I ran into problems using gjournal label -s (size) rejecting my sizes or wrapping the value around to something too low. As a workaround I chose to use a separate partition for each journal. I quickly ran out of partitions in a bsd disklabel so I decided to partition each disk into two slices; the first for data and the second for journals. This also made it easier to line up disk devices so they made more sense as a pair, for example: gm0s1d(data) + gm0s2d(journal) = /usr. I will note that if you accidentally put a gjournal label in the 'wrong' spot on your disk, you might make a tough situation for yourself getting rid of it. I have had plenty of times where I applied a gjournal label, discovered something unideal with it, but every time I did 'gjournal stop foo' the label would automatically get detected as a child of a different part of the disk because it could be seen and I could not unload it. That is part of why I use -h for gjournal label, and use slices+partitions, and the first partition is at offset 16, some of which may have been for gmirror's sake too. ==Software raid on 72G disks with gjournal== 5 min to setup, around 30 min to sync ===Prepare=== *Clear any old mirror config including old gmirror labels sysctl kern.geom.debugflags=16 gmirror clear da0 gmirror clear da1 sysctl kern.geom.debugflags=0 dd if=/dev/zero of=/dev/da1 bs=512 count=79 *place a GEOM mirror label onto second disk gmirror label -v -n -b round-robin gm0 /dev/da1 *activate GEOM mirror kernel layer gmirror load ===Partition=== *place a PC MBR onto the second disk to make it bootable. Also partition it with the majority of space as partition 1, and enough for your journal partitions as partition 2. '''You might get an error, such as "fdisk: Geom not found". If the next steps work, ignore the error.''' fdisk -v -B -I /dev/mirror/gm0 *Partition it into two slices. I think there is an easier way but I cannot remember how. Maybe I used a different method of using fdisk and ignored the end cyl values since they dont seem to make much sense anyway. sysinstall or sade could be used as an alternative. fdisk -i /dev/mirror/gm0 Do you want to change our idea of what BIOS thinks ? '''[n]''' The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 143363997 (70001 Meg), flag 80 (active) '' ^^^^^^^^^ A = 143363997'' beg: cyl 0/ head 1/ sector 1; end: cyl 731/ head 254/ sector 63 Do you want to change it? [n] '''y'''
''We want to make partitions approx 60G(data) and 10G(journals).'' ''So take variable A, divide by 7 and multiply by 6 to get var B.'' ''B = 122883426''
Supply a decimal value for "sysid (165=FreeBSD)" '''[165]''' Supply a decimal value for "start" '''[63]''' Supply a decimal value for "size" [143363997] '''122883426''' ''^^^^^^^^^'' ''put B here'' fdisk: WARNING: partition does not end on a cylinder boundary fdisk: WARNING: this may confuse the BIOS or some operating systems Correct this automatically? [n] '''y''' fdisk: WARNING: adjusting size of partition to 122881122 Explicitly specify beg/end address ? '''[n]''' sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 122881122 (60000 Meg), flag 80 (active) ''^^^^^^^^^'' ''C = 122881122'' ''D = C + 63 = 122881122 + 63 = 122881185'' ''E = A - C = 143363997 - 122881185 = 20482812''
beg: cyl 0/ head 1/ sector 1; end: cyl 480/ head 254/ sector 63 Are we happy with this entry? [n] '''y''' The data for partition 2 is: Do you want to change it? [n] '''y''' Supply a decimal value for "sysid (165=FreeBSD)" [0] '''165''' Supply a decimal value for "start" [0] '''122881185''' ''^^^^^^^^^'' ''put D here '' Supply a decimal value for "size" [0] '''20482812''' ''^^^^^^^^'' ''put E here'' Explicitly specify beg/end address ? '''[n]''' Are we happy with this entry? [n] '''y''' The data for partition 3 is: Do you want to change it? '''[n]''' The data for partition 4 is: Do you want to change it? '''[n]''' Partition 1 is marked active Do you want to change the active partition? '''[n]''' Should we write new partition table? [n] '''y''' '''You might get an error, such as "fdisk: Geom not found". If the next steps work, ignore the error.''' ===Disklabel=== *place a BSD disklabel onto the mirrors bsdlabel -w -B /dev/mirror/gm0s1 bsdlabel -w /dev/mirror/gm0s2 NOTICE: figure out what partitions you want by referring to bsdlabel /dev/da0s1 and/or running bsdlabel /dev/mirror/gm0s1 on a different server that has already been mirrored and partition to your liking. Size can be specified with ##M, ##G or * for remainder, and offset should be * to make it calculate it. Paste the output into the editor and make whatever changes you want as long as it includes: start "a" partition at offset 16, "c" partition at offset 0) *Partition 1: bsdlabel -e /dev/mirror/gm0s1 Example: # size offset fstype [fsize bsize bps/cpg] a: 1G 16 4.2BSD b: 4G * swap c: * 0 unused # "raw" part, don't edit d: 10G * 4.2BSD e: * * 4.2BSD f: 4G * 4.2BSD *Partition 2: bsdlabel -e /dev/mirror/gm0s2 Example: # size offset fstype [fsize bsize bps/cpg] c: * 0 unused # "raw" part, don't edit d: 4G 16 4.2BSD e: 4G * 4.2BSD f: * * 4.2BSD ===Gjournal label=== *Label the data and journals so the journaled partition is available. gjournal label -f -h mirror/gm0s1d mirror/gm0s2d gjournal label -f -h mirror/gm0s1e mirror/gm0s2e gjournal label -f -h mirror/gm0s1f mirror/gm0s2f *Load the kernel module so the journaled partitions are detected: gjournal load ===Newfs=== *Format the devices with journaling support in UFS: newfs /dev/mirror/gm0s1a newfs -J /dev/mirror/gm0s1d.journal newfs -J /dev/mirror/gm0s1e.journal newfs -J /dev/mirror/gm0s1f.journal ===Mount=== *Mount them temporarily: mount /dev/mirror/gm0s1a /mnt mkdir -p /mnt/usr /mnt/var /mnt/tmp mount -o async /dev/mirror/gm0s1d.journal /mnt/usr mount -o async /dev/mirror/gm0s1e.journal /mnt/var mount -o async /dev/mirror/gm0s1f.journal /mnt/tmp ===Copy Data=== *Install rsync, if not already: pkg_add -r rsync *Copy the original boot drive to the new device: rehash rsync -avHSx --progress / /mnt/ (This will take about 1 minute.) ===Prepare mirror for booting=== *Edit '''/mnt/etc/fstab''' replacing the following mountpoints: vi /mnt/etc/fstab Old: # Device Mountpoint FStype Options Dump Pass# /dev/da0s1b none swap sw 0 0 /dev/da0s1a / ufs rw 1 1 /dev/cd0 /cdrom cd9660 ro,noauto 0 0 /dev/acd0 /cdrom1 cd9660 ro,noauto 0 0 New: # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0s1b none swap sw 0 0 /dev/mirror/gm0s1a / ufs rw 1 1 /dev/mirror/gm0s1d.journal /usr ufs rw,async 2 2 /dev/mirror/gm0s1e.journal /var ufs rw,async 2 2 /dev/mirror/gm0s1f.journal /tmp ufs rw,async 2 2 /dev/cd0 /cdrom cd9660 ro,noauto 0 0 /dev/acd0 /cdrom1 cd9660 ro,noauto 0 0 *Load necessary kernel modules at boot: echo 'geom_journal_load="YES"' >> /mnt/boot/loader.conf echo 'geom_mirror_load="YES"' >> /mnt/boot/loader.conf *instruct boot stage 2 loader on first disk to boot with the boot stage 3 loader from the second disk (mainly because BIOS might not allow easy booting from second ATA disk or at least requires manual intervention on the console) echo "1:da(1,a)/boot/loader" >/boot.config *We're done with the first stage, reboot: reboot ===Check results=== *Login and run df. Should look like this: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/gm0s1a 1012974 201898 730040 22% / devfs 1 1 0 100% /dev /dev/mirror/gm0s1d.journal 10154156 144920 9196904 2% /usr /dev/mirror/gm0s1e.journal 40209204 322 36992146 0% /var /dev/mirror/gm0s1f.journal 4058060 12 3733404 0% /tmp ===Configure second disk into mirror=== *Add the original boot disk to the mirror. Make sure the first disk is treated as a really fresh one dd if=/dev/zero of=/dev/da0 bs=512 count=79 *switch GEOM mirror to auto-synchronization and add first disk (first disk is now immediately synchronized with the second disk content) gmirror configure -a gm0 gmirror insert gm0 /dev/da0 *Wait for the GEOM mirror synchronization to complete, or check it manually with ''gmirror list'' sh -c 'while [ ".`gmirror list | grep SYNCHRONIZING`" != . ]; do sleep 1; done' *Reboot into the final two-disk GEOM mirror setup (now actually boots with the MBR and boot stages on first disk as it was synchronized from second disk) reboot ===Mirror check script=== *Enable daily_status_gmirror_enable in /etc/periodic.conf or write your own script to monitor gmirror status From hartzell at alerce.com Tue May 13 21:17:56 2008 From: hartzell at alerce.com (George Hartzell) Date: Tue May 13 21:18:02 2008 Subject: good/best practices for gmirror and gjournal on a pair of disks? In-Reply-To: <4829FBC8.5040101@egr.msu.edu> References: <18473.48984.31132.91673@almost.alerce.com> <4829FBC8.5040101@egr.msu.edu> Message-ID: <18474.1410.744898.778947@almost.alerce.com> Adam McDougall writes: > [...] > I believe gjournal uses 1G for journal (2x512) which seemed to be > sufficient on all of the systems where I have used the default, but I > quickly found that using a smaller journal is a bad idea and leads to > panics that I was unable to avoid with tuning. Considering 1G was such > a close value, I chose to go several times above the default journal > size (disk is cheap and I want to be sure) but I ran into problems using > gjournal label -s (size) rejecting my sizes or wrapping the value around > to something too low. [...] I also stumbled on this and was unable to find any mention of it in the pr database. One of my todo items is to make sure I'm not messing up somehow, dig further into the PR db for an existing report, and file one if I can't find one? I tried -s 2147483648 and it was found to be "too small". A quick read of the source led me to find that jsize is an intmax_t and that gctl_get_intmax() should be returning an intmax_t and that intmax_ ought to be an __int64_t (I'm on amd64), which left me confused. Has anyone else seen/reported a problem with gjournal -s and values > 1G? g. From hartzell at alerce.com Tue May 13 21:48:14 2008 From: hartzell at alerce.com (George Hartzell) Date: Tue May 13 21:48:18 2008 Subject: good/best practices for gmirror and gjournal on a pair of disks? In-Reply-To: <4829FBC8.5040101@egr.msu.edu> References: <18473.48984.31132.91673@almost.alerce.com> <4829FBC8.5040101@egr.msu.edu> Message-ID: <18474.3218.145536.664367@almost.alerce.com> Adam McDougall writes: > George Hartzell wrote: > >[...] > > - I've read in the gjournal man page that when it is "... configured > > on top of gmirror(8) or graid3(8) providers, it also keeps them in > > a consistent state..." I've been trying to figure out if this > > simply falls out of how gjournal works or if there's explicity > > collusion with gmirror/graid3 but can't come up with a > > satisfactory explanation. Can someone walk me through it? > > > > Since I'm only gjournal'ing a portion of the underlying gmirror > > device I assume that I don't get this benefit? > >[...] > [...] > I decided to journal /usr /var /tmp and leave / as a standard UFS > partition because it is so small, fsck doesn't take long anyway and > hopefully doesn't get written to enough to cause damage by an abrupt > reboot. Because I'm not journaling the root partition, I chose to > ignore the possibility of gjournal marking the mirror clean. Sudden > reboots don't happen enough on servers for me to care. And all my > servers got abruptly rebooted this sunday and they all came up fine :) > [...] So you're confirming my belief that setting up gjournal on a bsdlabel'ed partition of a gmirror does *not* provide the consistency guarantee and that I should leave autosynchronization enabled. Right? g. From cjd.wong at gmail.com Tue May 13 23:29:54 2008 From: cjd.wong at gmail.com (Christian J. Wong Cruz) Date: Tue May 13 23:29:58 2008 Subject: problems with ia64 Message-ID: <5a054730805131604l73ae3623se6d5ad28eb5e40c1@mail.gmail.com> Hello, I'm trying to download the ia64 distribution CDs from ftp://ftp.freebsd.org/pub/FreeBSD/releases/ia64/ISO-IMAGES/7.0/ and the list is [FILE] 7.0-RELEASE-ia64-bootonly.iso. . Feb 25 18:10 62M [VIEW] [DOWNLOAD] [FILE] 7.0-RELEASE-ia64-disc1.iso . . . Feb 25 18:11 429M [VIEW] [DOWNLOAD] [FILE] 7.0-RELEASE-ia64-disc2.iso . . . Feb 25 18:11 364K [VIEW] [DOWNLOAD] [FILE] 7.0-RELEASE-ia64-disc3.iso . . . Feb 25 18:11 364K [VIEW] [DOWNLOAD] [FILE] 7.0-RELEASE-ia64-docs.iso. . . . Feb 25 18:11 238M [VIEW] [DOWNLOAD] [FILE] 7.0-RELEASE-ia64-livefs.iso. . . Feb 25 18:12 371M [VIEW] [DOWNLOAD] [FILE] CHECKSUM.MD5 . . . . . . . . . . Feb 25 18:10 411 [VIEW] [DOWNLOAD] [FILE] CHECKSUM.SHA256. . . . . . . . . Feb 25 18:10 621 [VIEW] [DOWNLOAD] if you look at the disc 2 and 3, the size is 364K is it ok?. I'd like to install freebsd in a intel core 2 duo. Should I instal this ia64? Thanks for your help. From msaad at datapipe.com Tue May 13 23:47:50 2008 From: msaad at datapipe.com (Mark Saad) Date: Tue May 13 23:47:54 2008 Subject: : Re: Socket leak (Was: Re: What triggers "No BufferSpace), ?Available" Message-ID: <482A2639.7000401@datapipe.com> Hello All This issue goes back some time, but I do not see a solution. Sorry about the cross post not sure where this belongs. Here is an overview of my issue which is similar and I hope someone can point me in the direction of a solution. I have experiencing an odd socket related issue on a few servers i manage. They are fairly large ftp servers for popular north american news agency. They handle 1000's of ftp transactions per hour. Currently they are running FreeBSD 6.3-Release-p1 . I have verified this happened on FreeBSD 6.1-Release 6.1-Stable 6.2-Release 6.2-Stable and 7.0-Release all 32bit installs and in both SMP an UP kernels. Oddly this issue did not happen on FreeBSD 4.x . I have a similar setup that has a 1400+ Day uptime running FreeBSD 4.x-Release. The issue is after 7 to 14 days the servers lock up and will not create any new tcp sockets. The system used proftp with mysql for authentication of the ftp accounts. The system is also running Apache 2.2.x , Postfix, Cyrus, clam-av, Diablo JDK 1.5 for Resin Appserver and daemontools . The only sysctls that seem to help are kern.ipc.maxsockets and kern.maxusers . Currently they are set to 65535 and 1024 . Changing kern.ipc.maxsockbuf did not have any effect I tried bumping this up to 2Meg, In any case I started work on logging everything we could think of to see what was happening. I started logging the values of kern.ipc.numopensockets and I noticed that something is leaking sockets. Here is a sample of the log 2008-04-29--15:04.10 ____ kern.ipc.numopensockets: 1501 2008-04-29--16:04.01 ____ kern.ipc.numopensockets: 1535 2008-04-29--17:04.00 ____ kern.ipc.numopensockets: 1617 2008-04-29--18:04.00 ____ kern.ipc.numopensockets: 1710 This continues until kern.ipc.maxsockets its reached or the box is rebooted. The other thing we looked at was the output from vmstat -z The first thing was the high amount of malloc 128 bucket failures 128 Bucket: 524, 0, 2489, 80, 8364, 23055239 I also logged the mbuf clusters, we never reached the max mbuf clusters Its almost like there are stale sockets. Here is a snapshot of the server now ewr# sockstat -4u |wc -l 139 ewr# sysctl kern.ipc.numopensockets kern.ipc.numopensockets: 13935 ewr# uptime 7:30PM up 6 days, 26 mins, 3 users, load averages: 0.18, 0.25, 0.17 My questions. 1. If I can not identify who / what is consuming all my tcp sockets what will happen if I double or triple the value of kern.ipc.maxsockets ? 2. Could this be an issue with a low kern.maxusers . Its currently set to 1024 . Also at times when I can not create a new socket I am not pinned on mbuf clusters . I was able to verify this in the past. 3. I installed a debugging kernel, which I built on the server. I was able to get a coredump of the server at the point in time we last had an issue. But I am not sure what I can do with this, kernel debugging is way beyond what I am capable of doing . Do I want to even pursue this ? 4. Does anyone have any system tunings you could recommend for a high volume ftp site ? What does ftp.freebsd.org have ? -- Mark Saad msaad@datapipe.com From msaad at datapipe.com Tue May 13 23:48:26 2008 From: msaad at datapipe.com (Mark Saad) Date: Tue May 13 23:48:33 2008 Subject: : Re: Socket leak (Was: Re: What triggers "No BufferSpace), ?Available" Message-ID: <482A2668.8070209@datapipe.com> Hello All This issue goes back some time, but I do not see a solution. Sorry about the cross post not sure where this belongs. Here is an overview of my issue which is similar and I hope someone can point me in the direction of a solution. I have experiencing an odd socket related issue on a few servers i manage. They are fairly large ftp servers for popular north american news agency. They handle 1000's of ftp transactions per hour. Currently they are running FreeBSD 6.3-Release-p1 . I have verified this happened on FreeBSD 6.1-Release 6.1-Stable 6.2-Release 6.2-Stable and 7.0-Release all 32bit installs and in both SMP an UP kernels. Oddly this issue did not happen on FreeBSD 4.x . I have a similar setup that has a 1400+ Day uptime running FreeBSD 4.x-Release. The issue is after 7 to 14 days the servers lock up and will not create any new tcp sockets. The system used proftp with mysql for authentication of the ftp accounts. The system is also running Apache 2.2.x , Postfix, Cyrus, clam-av, Diablo JDK 1.5 for Resin Appserver and daemontools . The only sysctls that seem to help are kern.ipc.maxsockets and kern.maxusers . Currently they are set to 65535 and 1024 . Changing kern.ipc.maxsockbuf did not have any effect I tried bumping this up to 2Meg, In any case I started work on logging everything we could think of to see what was happening. I started logging the values of kern.ipc.numopensockets and I noticed that something is leaking sockets. Here is a sample of the log 2008-04-29--15:04.10 ____ kern.ipc.numopensockets: 1501 2008-04-29--16:04.01 ____ kern.ipc.numopensockets: 1535 2008-04-29--17:04.00 ____ kern.ipc.numopensockets: 1617 2008-04-29--18:04.00 ____ kern.ipc.numopensockets: 1710 This continues until kern.ipc.maxsockets its reached or the box is rebooted. The other thing we looked at was the output from vmstat -z The first thing was the high amount of malloc 128 bucket failures 128 Bucket: 524, 0, 2489, 80, 8364, 23055239 I also logged the mbuf clusters, we never reached the max mbuf clusters Its almost like there are stale sockets. Here is a snapshot of the server now ewr# sockstat -4u |wc -l 139 ewr# sysctl kern.ipc.numopensockets kern.ipc.numopensockets: 13935 ewr# uptime 7:30PM up 6 days, 26 mins, 3 users, load averages: 0.18, 0.25, 0.17 My questions. 1. If I can not identify who / what is consuming all my tcp sockets what will happen if I double or triple the value of kern.ipc.maxsockets ? 2. Could this be an issue with a low kern.maxusers . Its currently set to 1024 . Also at times when I can not create a new socket I am not pinned on mbuf clusters . I was able to verify this in the past. 3. I installed a debugging kernel, which I built on the server. I was able to get a coredump of the server at the point in time we last had an issue. But I am not sure what I can do with this, kernel debugging is way beyond what I am capable of doing . Do I want to even pursue this ? 4. Does anyone have any system tunings you could recommend for a high volume ftp site ? What does ftp.freebsd.org have ? -- Mark Saad msaad@datapipe.com From pyunyh at gmail.com Wed May 14 00:17:43 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed May 14 00:17:47 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <47d0403c0805130922x62fc479cs47b8a03f41598e00@mail.gmail.com> References: <47d0403c0805130922x62fc479cs47b8a03f41598e00@mail.gmail.com> Message-ID: <20080514001734.GA3634@cdnetworks.co.kr> On Tue, May 13, 2008 at 12:22:10PM -0400, Ben Kaduk wrote: > Hi all, > > I only just now subscribed, so my apologies if this has been covered > and my cursory search missed it. > > I am seeing a similar issue to the one described in the email below > (pasted from a web listing of this list). > > That is, my ssh connection will occasionally be dropped with the > message > Disconnecting: Bad packet length 3190815048. > (the number is not always the same). > > I can reliably reproduce this with `cat < /dev/urandom | od -c` > from a FreeBSD-current box (a few weeks old, actually, since > the build was broken when I last tried to update) as well > as from a mac running OS X 10.4 . > > The system that is killing my connections is: > FreeBSD periphrasis.mit.edu 7.0-STABLE FreeBSD 7.0-STABLE #3: Tue Mar > 25 14:53:51 EDT 2008 > kaduk@periphrasis.mit.edu:/usr/obj/usr/src/sys/PERIPHRASIS amd64 > > > Any thoughts would be appreciated. > There had been large changes to enhance re(4) stablility and many users reported positive results. But it still seems to have issues for certain models. See kern/123202, kern/123563. If you encounter issues on latest re(4), please try patch in kern/123563 and let me know how it goes. > -Ben Kaduk > > > > > > > > ------------------ random message from this thread, for some context > ------------- > > * From: Jeremy Chadwick > * Date: Mon, 12 May 2008 05:32:07 -0700 > > On Mon, May 12, 2008 at 01:44:22PM +0200, Torfinn Ingolfsen wrote: > > On Mon, 12 May 2008 11:37:53 +0200 > Torfinn Ingolfsen wrote: > > FWIW, I had major troubles with re(4) around 7.0-release, and a while > later (I had to use patches). After upgrading to 7-stable on > 2008-04-12, re(4) is working for me without patches. > > > (sigh).. it seems that I spoke to soon. Murphy just showed up. I still > get ssh disconnects (see below) on connections _to_ the machine when > transferring largish amounts of data (like when upgrading a port). > Here is one example (portupgrading the jdk port): > /usr/bin/gcc -fno-strict-aliasing -fPIC -W -Wall -Wno-unused > -Wno-parentheses -pipe -Damd64 -DARCH='"amd64"' > -DRELEASE='"1.6.0_03-p4"' > -DFULL_VERSION='"1.6.0_03-p4-root_12_may_2008_13_25-b00"' > -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D_ALLBSD_SOURCE -D_LP64=1 > -I. -I/usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/CClassHeaders > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/javavm/include > -I../../../src/solaris/javavm/include > -I../../../src/share/native/sun/management > -I../../../src/solaris/hpi/include -I../../../src/share/native/common > -I../../../src/solaris/native/common > -I../../../src/share/native/java/lang/management > -I../../../src/solaris/native/java/lang/management -c -o > /usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/obj64/ClassLoadingImpl.o > ../../../src/share/native/sun/management/ClassLoadingImpl.c > Disconnecting: Bad packet length 3601161525. > > The machine is running: > tingo@kg-vm$ uname -a > FreeBSD kg-vm.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #10: Sat Apr 12 > 21:42:55 CEST 2008 root@xxxxxxxxxxxx:/usr/obj/usr/src/sys/GENERIC > amd64 > > and has been up for about 14 days: > tingo@kg-vm$ uptime > 1:36PM up 14 days, 17:42, 7 users, load averages: 2.15, 1.85, 1.34 > > I see that if_re.c for RELENG_7 has been updated on April 22nd, so > I'll upgrade the machine to latest -stable and see if that works > better. > > > Is this machine using pf(4) at all? -- Regards, Pyun YongHyeon From cswiger at mac.com Wed May 14 00:18:59 2008 From: cswiger at mac.com (Chuck Swiger) Date: Wed May 14 00:19:28 2008 Subject: problems with ia64 In-Reply-To: <5a054730805131604l73ae3623se6d5ad28eb5e40c1@mail.gmail.com> References: <5a054730805131604l73ae3623se6d5ad28eb5e40c1@mail.gmail.com> Message-ID: On May 13, 2008, at 4:04 PM, Christian J. Wong Cruz wrote: > Hello, I'm trying to download the ia64 distribution CDs from > ftp://ftp.freebsd.org/pub/FreeBSD/releases/ia64/ISO-IMAGES/7.0/ and > the list > is > [ ... ] > if you look at the disc 2 and 3, the size is 364K is it ok?. I'd > like to > install freebsd in a intel core 2 duo. Should I instal this ia64? Why, no. ia64 is for the Itanium processor line which uses a different architecture and is not compatible with the standard x86 32- bit or 64-bit platforms. What you want instead is the amd64 platform, which is known as "EM64T" for the Intel Xeon/P4/Core/Core2 chips: http://www.FreeBSD.org/releases/7.0R/hardware.html#PROC-AMD64 ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/7.0/ Regards, -- -Chuck From mcdouga9 at egr.msu.edu Wed May 14 00:37:03 2008 From: mcdouga9 at egr.msu.edu (mcdouga9) Date: Wed May 14 00:37:09 2008 Subject: good/best practices for gmirror and gjournal on a pair of disks? In-Reply-To: <18474.3218.145536.664367@almost.alerce.com> References: <18473.48984.31132.91673@almost.alerce.com> <4829FBC8.5040101@egr.msu.edu> <18474.3218.145536.664367@almost.alerce.com> Message-ID: <482A342B.1020606@egr.msu.edu> George Hartzell wrote: > Adam McDougall writes: > > George Hartzell wrote: > > >[...] > > > - I've read in the gjournal man page that when it is "... configured > > > on top of gmirror(8) or graid3(8) providers, it also keeps them in > > > a consistent state..." I've been trying to figure out if this > > > simply falls out of how gjournal works or if there's explicity > > > collusion with gmirror/graid3 but can't come up with a > > > satisfactory explanation. Can someone walk me through it? > > > > > > Since I'm only gjournal'ing a portion of the underlying gmirror > > > device I assume that I don't get this benefit? > > >[...] > > [...] > > I decided to journal /usr /var /tmp and leave / as a standard UFS > > partition because it is so small, fsck doesn't take long anyway and > > hopefully doesn't get written to enough to cause damage by an abrupt > > reboot. Because I'm not journaling the root partition, I chose to > > ignore the possibility of gjournal marking the mirror clean. Sudden > > reboots don't happen enough on servers for me to care. And all my > > servers got abruptly rebooted this sunday and they all came up fine :) > > [...] > > So you're confirming my belief that setting up gjournal on a > bsdlabel'ed partition of a gmirror does *not* provide the consistency > guarantee and that I should leave autosynchronization enabled. Right? > > g. > I forgot to address that. I think to gain that, you have to (re)label the mirror using -F (see man gmirror). I believe without using -F, the mirrors will still be synced (but probably don't need to). Otherwise, look for initial mail list announcements (freebsd-current?) of gjournal which may explain. From minimarmot at gmail.com Wed May 14 05:12:30 2008 From: minimarmot at gmail.com (Ben Kaduk) Date: Wed May 14 05:12:34 2008 Subject: 7.0 issues fixed? upgrade timing? In-Reply-To: <20080514001734.GA3634@cdnetworks.co.kr> References: <47d0403c0805130922x62fc479cs47b8a03f41598e00@mail.gmail.com> <20080514001734.GA3634@cdnetworks.co.kr> Message-ID: <47d0403c0805132212i72c63776t1bca3d2e77be4bf3@mail.gmail.com> On 5/13/08, Pyun YongHyeon wrote: > > > There had been large changes to enhance re(4) stablility and many > users reported positive results. But it still seems to have issues > for certain models. See kern/123202, kern/123563. > If you encounter issues on latest re(4), please try patch in > kern/123563 and let me know how it goes. > > > > -Ben Kaduk > > Pyun, Thanks for the reminder -- I saw the changes go in, but forgot that this box was using re(4). Attempting to csup while running the March 25 driver made me sad, but a kernel.old from February worked well. I'm now running with if_re.c v 1.95.2.18 and I'm not seeing any packet loss or terminated ssh sessions. Thanks for all the good work! -Ben Kaduk From smithi at nimnet.asn.au Wed May 14 05:36:48 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed May 14 05:36:54 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: <1210699165.2238.1.camel@RabbitsDen> Message-ID: On Tue, 13 May 2008, Alexandre "Sunny" Kovalenko wrote: > On Mon, 2008-05-12 at 14:52 +1000, Ian Smith wrote: > > On Sun, 11 May 2008 jonathan@kc8onw.net wrote: > > > Has any work been done recently towards adding SATA Native Command > > > Queueing as well as ATA APM and acoustic management to FreeBSD? > > > > > > I found this PR (with patch) to add APM and acoustic management control to > > > atacontrol. The PR was opened in May 2005 has not been changed since > > > December 2006 and is still open. > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=81692&cat= > > > > > > I have not been able to find much of anything on SATA NCQ in FreeBSD newer > > > than 2005 or 2006 does anyone know anything newer? > > > > Jeremy has addressed the NCQ issue, about which I know nothing. > > > > As for APM and AAM, that functionality is handled by sysutils/ataidle, > > which that PR appears - on a quick glance - to pretty well duplicate. > > > > I see phk@ recently added an 'atacontrol spindown' command to HEAD and > > RELENG_7 that appears to offer similar functionality to 'ataidle -S > > standby_mins' or 'ataidle -I idle_mins', though specified in seconds > > instead. However this doesn't address acoustic management. > > > > Or is ataidle broken for SATA disks? > Does not look broken here (RELENG_7): > > RabbitsDen# ataidle /dev/ad4 > Device Info: > > Model: HTS541010G9SA00 > Serial: MP2ZM4X0JWY6WH > Firmware Rev: MBZIC60H > ATA revision: ATA-7 > LBA 48: yes > Geometry: 16383 cyls, 16 heads, 63 spt > Capacity: 93GB > SMART Supported: yes > SMART Enabled: yes > APM Supported: yes > APM Enabled: yes > AAM Supported: yes > AAM Enabled: yes > Current AAM: 1 > Vendor Recommends AAM: 1 > APM Value: 16638 Thanks for the confirmation Alexandre. I take Jonathan's point that it would be nice to have this functionality in atacontrol, though perhaps the BUGS section in ataidle(8) precludes merging that? cc'ing Bruce Cran in case he wants to add something .. > RabbitsDen# atacontrol list [..] > ATA channel 2: > Master: ad4 Serial ATA v1.0 > Slave: no device present Regarding the spindown thing, I always used to use APM (set in BIOS) to do that on this old laptop, until I found that I'd already consumed 25% of a new 40GB drive's 2 million Load_Cycle_Count in a year, following a thread warning about that last year, so now I run ataidle from rc.conf: ataidle_enable="YES" ataidle_device="ad0" ataidle_ad0="-P 0 0 0" but then found it necessary to again disable disk APM in rc.resume: /usr/local/sbin/ataidle -P 0 0 0 cheers, Ian From bruce at cran.org.uk Wed May 14 06:37:54 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Wed May 14 06:37:57 2008 Subject: ATA APM and NCQ support in FreeBSD atacontrol In-Reply-To: References: Message-ID: <482A88A5.4060108@cran.org.uk> Ian Smith wrote: > I take Jonathan's point that it would be nice to have this functionality > in atacontrol, though perhaps the BUGS section in ataidle(8) precludes > merging that? cc'ing Bruce Cran in case he wants to add something .. ataidle is at the moment quite dumb about sending commands: it doesn't check that the drive actually supports APM/AAM before sending the commands, and that's an easy check to do. If this was being added to atacontrol I think I'd want to do quite a bit of work first to make it more robust. However I don't think the code from ataidle could ever just be merged in to atacontrol because the code styles are quite different; however since the interface to the ATA driver is quite straightforward it should be trivial to re-implement or copy the bits needed. -- Bruce From kris at FreeBSD.org Wed May 14 08:15:19 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed May 14 08:15:25 2008 Subject: Panic after hung rsync, probably zfs related In-Reply-To: <4829F1B8.1000707@delphij.net> References: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> <4829F1B8.1000707@delphij.net> Message-ID: <482A9F99.4040500@FreeBSD.org> Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ben Stuyts wrote: > | Hi, > | > | While doing an rsync from a zfs filesystem to an external usb hd (also > | zfs), the rsync processes hung in zfs state. I could not kill these > | processes, although the rest of the server seemingly continued to run > | fine. The reboot command did not work. Next I tried a shutdown now > | command. This caused a panic: > > Sound like you somehow run out of memory, there is an known issue with > ZFS which causes livelock when there is memory pressure. Which rsync > version are you using? With rsync 3.x the memory usage would drop > drastically which would help to prevent this from happening. This isn't known to cause a double fault though. Unfortunately we probably need more information than was available in order to proceed. Kris From ben at altus-escon.com Wed May 14 08:40:58 2008 From: ben at altus-escon.com (Ben Stuyts) Date: Wed May 14 08:41:05 2008 Subject: Panic after hung rsync, probably zfs related In-Reply-To: <4829F1B8.1000707@delphij.net> References: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> <4829F1B8.1000707@delphij.net> Message-ID: <11D2E346-752B-4F61-979E-1D64FB34ED34@altus-escon.com> On 13 mei 2008, at 21:53, Xin LI wrote: > | While doing an rsync from a zfs filesystem to an external usb hd > (also > | zfs), the rsync processes hung in zfs state. I could not kill these > | processes, although the rest of the server seemingly continued to > run > | fine. The reboot command did not work. Next I tried a shutdown now > | command. This caused a panic: > > Sound like you somehow run out of memory, there is an known issue with > ZFS which causes livelock when there is memory pressure. Which rsync > version are you using? With rsync 3.x the memory usage would drop > drastically which would help to prevent this from happening. I'm running rsync 3.0.0. Two weeks ago I already increased the memory in this machine from 4 to 8 GB, but I did not change any loader.conf variables. BTW, The wired memory goes all over the place in this machine: even when it's mostly idle it varies between 300 MB and 3.5 GB. That's why I added 4 more GB. Ben From kostikbel at gmail.com Wed May 14 08:50:57 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed May 14 08:51:01 2008 Subject: Panic after hung rsync, probably zfs related In-Reply-To: <11D2E346-752B-4F61-979E-1D64FB34ED34@altus-escon.com> References: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> <4829F1B8.1000707@delphij.net> <11D2E346-752B-4F61-979E-1D64FB34ED34@altus-escon.com> Message-ID: <20080514085025.GL18958@deviant.kiev.zoral.com.ua> On Wed, May 14, 2008 at 10:39:36AM +0200, Ben Stuyts wrote: > > On 13 mei 2008, at 21:53, Xin LI wrote: > > >| While doing an rsync from a zfs filesystem to an external usb hd > >(also > >| zfs), the rsync processes hung in zfs state. I could not kill these > >| processes, although the rest of the server seemingly continued to > >run > >| fine. The reboot command did not work. Next I tried a shutdown now > >| command. This caused a panic: > > > >Sound like you somehow run out of memory, there is an known issue with > >ZFS which causes livelock when there is memory pressure. Which rsync > >version are you using? With rsync 3.x the memory usage would drop > >drastically which would help to prevent this from happening. > > I'm running rsync 3.0.0. Two weeks ago I already increased the memory > in this machine from 4 to 8 GB, but I did not change any loader.conf > variables. > > BTW, The wired memory goes all over the place in this machine: even > when it's mostly idle it varies between 300 MB and 3.5 GB. That's why > I added 4 more GB. 3.5Gb wired ? Do you run amd64 ? Does wired memory drops lower after you change the load ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080514/834eadde/attachment.pgp From christian.baer at uni-dortmund.de Wed May 14 10:15:09 2008 From: christian.baer at uni-dortmund.de (Christian Baer) Date: Wed May 14 10:15:14 2008 Subject: Panic after hung rsync, probably zfs related In-Reply-To: <20080514085025.GL18958@deviant.kiev.zoral.com.ua> References: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> <4829F1B8.1000707@delphij.net> <11D2E346-752B-4F61-979E-1D64FB34ED34@altus-escon.com> <20080514085025.GL18958@deviant.kiev.zoral.com.ua> Message-ID: Kostik Belousov wrote: >> BTW, The wired memory goes all over the place in this machine: even >> when it's mostly idle it varies between 300 MB and 3.5 GB. That's why >> I added 4 more GB. > 3.5Gb wired ? Do you run amd64 ? > Does wired memory drops lower after you change the load ? Either that or some other 64bit Plattform (alpha, sparc64 etc.). Regards Chris From ben at altus-escon.com Wed May 14 11:48:57 2008 From: ben at altus-escon.com (Ben Stuyts) Date: Wed May 14 11:49:02 2008 Subject: Panic after hung rsync, probably zfs related In-Reply-To: <20080514085025.GL18958@deviant.kiev.zoral.com.ua> References: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> <4829F1B8.1000707@delphij.net> <11D2E346-752B-4F61-979E-1D64FB34ED34@altus-escon.com> <20080514085025.GL18958@deviant.kiev.zoral.com.ua> Message-ID: On 14 mei 2008, at 10:50, Kostik Belousov wrote: >> BTW, The wired memory goes all over the place in this machine: even >> when it's mostly idle it varies between 300 MB and 3.5 GB. That's why >> I added 4 more GB. > 3.5Gb wired ? Do you run amd64 ? > > Does wired memory drops lower after you change the load ? Yes, it was in my original message. Ben From ben at altus-escon.com Wed May 14 11:49:54 2008 From: ben at altus-escon.com (Ben Stuyts) Date: Wed May 14 11:49:58 2008 Subject: Panic after hung rsync, probably zfs related In-Reply-To: <482A9F99.4040500@FreeBSD.org> References: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> <4829F1B8.1000707@delphij.net> <482A9F99.4040500@FreeBSD.org> Message-ID: <6E930383-27FE-470A-96D8-3E61DD21B2BC@altus-escon.com> On 14 mei 2008, at 10:15, Kris Kennaway wrote: >> | While doing an rsync from a zfs filesystem to an external usb hd >> (also >> | zfs), the rsync processes hung in zfs state. I could not kill these >> | processes, although the rest of the server seemingly continued to >> run >> | fine. The reboot command did not work. Next I tried a shutdown now >> | command. This caused a panic: >> Sound like you somehow run out of memory, there is an known issue >> with >> ZFS which causes livelock when there is memory pressure. Which rsync >> version are you using? With rsync 3.x the memory usage would drop >> drastically which would help to prevent this from happening. > > This isn't known to cause a double fault though. Unfortunately we > probably need more information than was available in order to proceed. Yes, I agree. But I don't know what to do in this sort of case where the machine is completely wedged. Ben From ben at altus-escon.com Wed May 14 11:52:49 2008 From: ben at altus-escon.com (Ben Stuyts) Date: Wed May 14 11:52:55 2008 Subject: Panic after hung rsync, probably zfs related In-Reply-To: <20080514085025.GL18958@deviant.kiev.zoral.com.ua> References: <7A0780B6-AD8E-440B-BFDB-EC2C4ACA1A70@altus-escon.com> <4829F1B8.1000707@delphij.net> <11D2E346-752B-4F61-979E-1D64FB34ED34@altus-escon.com> <20080514085025.GL18958@deviant.kiev.zoral.com.ua> Message-ID: <6BFEEFEA-46AD-46F6-9485-0A9105593B04@altus-escon.com> On 14 mei 2008, at 10:50, Kostik Belousov wrote: > 3.5Gb wired ? Do you run amd64 ? Yes. > Does wired memory drops lower after you change the load ? Sorry, forgot to answer this in my previous msg. It is very unpredictable, and I have not found a pattern. It is a small business server, and both during non-office and regular office hours the wired memory varies between the numbers above. Ben From mvoorhis at eressea.wpi.edu Wed May 14 13:25:03 2008 From: mvoorhis at eressea.wpi.edu (Michael Voorhis) Date: Wed May 14 13:25:14 2008 Subject: Automounting USB sticks - questions In-Reply-To: <4826E7C9.9030407@incunabulum.net> References: <4826E7C9.9030407@incunabulum.net> Message-ID: <18474.52780.461861.985895@eressea.wpi.edu> >>>>> "bms" == Bruce M Simpson writes: bms> It would be great if we could ship FreeBSD out of the box, ready bms> to automount removable media. This would be useful to all users, bms> but particularly for novices and people who just wanna get on bms> and use the beast. I think this would be nice, so long as it isn't enabled by default. I've always enjoyed how FreeBSD shuns the feature-creep that infects other operating systems. Wouldn't it also be nice to have automatic printer discovery, automatic WEP/WPA network setup via a nice GUI, etc etc. FreeBSD's documentation is really wonderful, and newbies should be encouraged to read the rich documentation to find out how to (among other things) enable automounting. They'll find out many other great things on the way. Mike V. From lists at lozenetz.org Wed May 14 14:38:28 2008 From: lists at lozenetz.org (Anton - Valqk) Date: Wed May 14 14:38:35 2008 Subject: nscd strange behaviour Message-ID: <482AF959.1000800@lozenetz.org> Hi there group, I have nscd running on 6.3 with backports patches, but maybe this will apply to the 7.0? What's the problem: i have nss setup with nss_pg module and authenticates passing through pam pg module. I have nscd running so I can make fewer queries to the pg server when system retrieves uid<->userid. But when I change the password in pg database, I can't get authenticated on the machine running nscd. When I restart it, the new password is retrieved as it should be and authentication goes ok. my config is: moser# cat /etc/nscd.conf # # Default caching daemon configuration file # $FreeBSD: src/etc/nscd.conf,v 1.2.2.1 2007/10/19 00:09:54 bushman Exp $ # enable-cache passwd yes enable-cache group yes enable-cache hosts no enable-cache services no enable-cache protocols no enable-cache rpc no enable-cache networks no #custom threads 25 So my question: Is this a suggested behaviour and shouldn't nscd cache all in passwd struct but password itself? any suggestions, opinions and comments are welcome! cheers, valqk. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From avg at icyb.net.ua Wed May 14 15:17:47 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed May 14 15:17:59 2008 Subject: thread scheduling at mutex unlock Message-ID: <482B0297.2050300@icyb.net.ua> I am trying the small attached program on FreeBSD 6.3 (amd64, SCHED_4BSD) and 7-STABLE (i386, SCHED_ULE), both with libthr as threads library and on both it produces "BROKEN" message. I compile this program as follows: cc sched_test.c -o sched_test -pthread I believe that the behavior I observe is broken because: if thread #1 releases a mutex and then tries to re-acquire it while thread #2 was already blocked waiting on that mutex, then thread #1 should be "queued" after thread #2 in mutex waiter's list. Is there any option (thread scheduler, etc) that I could try to achieve "good" behavior? P.S. I understand that all this is subject to (thread) scheduler policy, but I think that what I expect is more reasonable, at least it is more reasonable for my application. -- Andriy Gapon From vivek at khera.org Wed May 14 15:25:44 2008 From: vivek at khera.org (Vivek Khera) Date: Wed May 14 15:25:51 2008 Subject: how much memory does increasing max rules for IPFW take up? Message-ID: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> I had a box run out of dynamic state space yesterday. I found I can increase the number of dynamic rules by increasing the sysctl parameter net.inet.ip.fw.dyn_max. I can't find, however, how this affects memory usage on the system. Is it dyanamically allocated and de-allocated, or is it a static memory buffer? Thanks! From uspoerlein at gmail.com Wed May 14 15:44:31 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Wed May 14 15:44:52 2008 Subject: RELENG_6 regression: ums0: X report 0x0002 not supported Message-ID: <7ad7ddd90805140844p9950dc8yf9f24c966a996fbc@mail.gmail.com> Hi, after updating an Intel S5000PAL system from 6.2 to 6.3, ums(4) is no longer attaching correctly. Here's an dmesg diff between 6.2 and 6.3 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xe8d00000-0xe8d003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered ukbd0: Avocent Avocent Embedded DVC 1.0, rev 2.00/0.00, addr 2, iclass 3/1 kbd2 at ukbd0 ums0: Avocent Avocent Embedded DVC 1.0, rev 2.00/0.00, addr 2, iclass 3/1 -ums0: 3 buttons and Z dir. -uhid0: Avocent Avocent Embedded DVC 1.0, rev 2.00/0.00, addr 2, iclass 3/1 -uhid0: could not read endpoint descriptor -device_attach: uhid0 attach returned 6 +ums0: X report 0x0002 not supported +device_attach: ums0 attach returned 6 Attached is the full 6.3 dmesg. Looks weird to me, anything I can try on this hardware? Uli -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.boot Type: application/octet-stream Size: 8389 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080514/dbf548a7/dmesg.obj From uspoerlein at gmail.com Wed May 14 15:58:49 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Wed May 14 15:58:53 2008 Subject: RELENG_6 regression: panic: vm_fault on nofault entry, addr: c8000000 Message-ID: <7ad7ddd90805140832p23b70cb6s731e5d5bf907114b@mail.gmail.com> Hi, there's a regression going from 6.2 to 6.3, where it will panic upon booting the kernel within vm_fault. This problem has been discussed before, but I'm seeing it reliably on a RELENG_6 checkout from 5th of May. It affects multiple (but identical) systems, here's an verbose boot leading to the panic. Please note that 6.2 was running fine on these machines, they also boot "normally" if I disable ACPI (but this is not really an option). SMAP type=01 base=0000000000000000 len=000000000009d800 SMAP type=02 base=000000000009d800 len=0000000000002800 SMAP type=02 base=00000000000ce000 len=0000000000002000 SMAP type=02 base=00000000000e4000 len=000000000001c000 SMAP type=01 base=0000000000100000 len=00000000cfe60000 SMAP type=03 base=00000000cff60000 len=0000000000009000 SMAP type=04 base=00000000cff69000 len=0000000000017000 SMAP type=02 base=00000000cff80000 len=0000000000080000 SMAP type=02 base=00000000e0000000 len=0000000010000000 SMAP type=02 base=00000000fec00000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ff000000 len=0000000001000000 SMAP type=01 base=0000000100000000 len=0000000030000000 786432K of memory above 4GB ignored Copyright (c) 1992-2008 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.3-20080505-SNAP #0: Mon May 5 11:42:32 UTC 2008 root@fbsdbuild.1822direkt.com:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc1051000. Preloaded mfs_root "/boot/mfsroot" at 0xc10511e8. Preloaded elf module "/boot/modules/acpi.ko" at 0xc105122c. MP Configuration Table version 1.4 found at 0xc009dd71 Table 'FACP' at 0xcff68e48 Table 'APIC' at 0xcff68ebc MADT: Found table at 0xcff68ebc APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled MADT: Found CPU APIC ID 4 ACPI ID 1: enabled MADT: Found CPU APIC ID 2 ACPI ID 2: enabled MADT: Found CPU APIC ID 6 ACPI ID 3: enabled ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193204 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3000122064 Hz CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 Features=0xbfebfbff Features2=0xe4bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Logical CPUs per core: 2 real memory = 3489005568 (3327 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001425000 - 0x00000000cc488fff, 3406184448 bytes (831588 pages) avail memory = 3405979648 (3248 MB) bios32: Found BIOS32 Service Directory header at 0xc00f5960 bios32: Entry = 0xfd520 (c00fd520) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd520+0x247 pnpbios: Found PnP BIOS data at 0xc00f59e0 pnpbios: Entry = f0000:af28 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 9, Interrupt 24 at 0xfec80000 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic4: Routing NMI -> LINT1 lapic4: LINT1 trigger: edge lapic4: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic6: Routing NMI -> LINT1 lapic6: LINT1 trigger: edge lapic6: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0xff000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 ath_rate: version 1.2 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (May 5 2008 11:42:16) hptrr: HPT RocketRAID controller driver v1.1 (May 5 2008 11:42:14) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80008058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25d88086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.PIRX -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.PIRY -> bus 0 dev 31 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xdca93000 pa 0x9c000 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.REGS -> bus 0 dev 31 func 0 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 6 7 10 11 14 15 Validation 0 7 N 0 3 4 5 6 7 10 11 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 4 5 6 7 10 11 14 15 Validation 0 255 N 0 4 5 6 7 10 11 14 15 After Disable 0 255 N 0 4 5 6 7 10 11 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 4 5 6 7 10 11 14 15 Validation 0 255 N 0 4 5 6 7 10 11 14 15 After Disable 0 255 N 0 4 5 6 7 10 11 14 15 cpu0: on acpi0 panic: vm_fault: fault on nofault entry, addr: c8000000 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... What to do? Uli From gavin at FreeBSD.org Wed May 14 18:21:08 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Wed May 14 18:21:13 2008 Subject: RELENG_6 regression: panic: vm_fault on nofault entry, addr: c8000000 In-Reply-To: <7ad7ddd90805140832p23b70cb6s731e5d5bf907114b@mail.gmail.com> References: <7ad7ddd90805140832p23b70cb6s731e5d5bf907114b@mail.gmail.com> Message-ID: <1210787367.29891.80.camel@buffy.york.ac.uk> On Wed, 2008-05-14 at 17:32 +0200, Ulrich Spoerlein wrote: > Hi, > > there's a regression going from 6.2 to 6.3, where it will panic upon > booting the kernel within vm_fault. This problem has been discussed > before, but I'm seeing it reliably on a RELENG_6 checkout from 5th of > May. > > It affects multiple (but identical) systems, here's an verbose boot > leading to the panic. Please note that 6.2 was running fine on these > machines, they also boot "normally" if I disable ACPI (but this is not > really an option). [snip dmesg output] > What to do? If you don't get any suggestions from people as to what it may be, and you have a system you can afford to reboot a few times, the easiest thing to do is to take the system back to 6.2, and then update your source to a date midway between 6.2 and 6.3 and see if that crashes. Use this in your supfile: *default tag=RELENG_6 *default date=2007.07.01.00.00.00 (For reference, 6.2 was released on 2007.01.15, with 6.3 on 2008.01.18) >From then, go half way again either forwards or backwards, to narrow down the window when the problem was introduced - with only eight kernel recompiles you should be able to narrow it down to a one-day window, and looking at the spec of the machine you should be able to do that in a morning :). Once you've got it down to a window of a couple of days or less, give csup the "-L 2" option, and it'll give you a list of files changed between dates. Obviously this is dependant on you being able to take one of the affected machines down for a few hours, but if you can, this may well be the quickest way of establishing when the problem was introduced. Out of interest, what type of hardware is this? Gavin From avg at icyb.net.ua Wed May 14 18:50:31 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed May 14 18:50:34 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482B0297.2050300@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> Message-ID: <482B3475.6060803@icyb.net.ua> on 14/05/2008 18:17 Andriy Gapon said the following: > I am trying the small attached program on FreeBSD 6.3 (amd64, > SCHED_4BSD) and 7-STABLE (i386, SCHED_ULE), both with libthr as threads > library and on both it produces "BROKEN" message. > > I compile this program as follows: > cc sched_test.c -o sched_test -pthread > > I believe that the behavior I observe is broken because: if thread #1 > releases a mutex and then tries to re-acquire it while thread #2 was > already blocked waiting on that mutex, then thread #1 should be "queued" > after thread #2 in mutex waiter's list. > > Is there any option (thread scheduler, etc) that I could try to achieve > "good" behavior? > > P.S. I understand that all this is subject to (thread) scheduler policy, > but I think that what I expect is more reasonable, at least it is more > reasonable for my application. > > Daniel Eischen has just kindly notified me that the code (as an attachment) didn't make it to the list, so here it is inline. #include #include #include #include pthread_mutex_t mutex; int count = 0; static void * thrfunc(void * arg) { while (1) { pthread_mutex_lock(&mutex); count++; if (count > 10) { fprintf(stderr, "you have a BROKEN thread scheduler!!!\n"); exit(1); } sleep(1); pthread_mutex_unlock(&mutex); } } int main(void) { pthread_t thr; #if 0 pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE_NP); pthread_mutex_init(&mutex, &attr); #else pthread_mutex_init(&mutex, NULL); #endif pthread_create(&thr, NULL, thrfunc, NULL); sleep(2); pthread_mutex_lock(&mutex); count = 0; printf("you have good thread scheduler\n"); pthread_mutex_unlock(&mutex); return 0; } -- Andriy Gapon From aragon at phat.za.net Wed May 14 20:20:44 2008 From: aragon at phat.za.net (Aragon Gouveia) Date: Wed May 14 20:20:48 2008 Subject: instability with gmirror and atacontrol spindown Message-ID: <20080514202042.GA23704@phat.za.net> Hi, I eagerly started using atacontrol's new spindown command the other day. There's a gmirror volume running on top of the two disks that get spundown. I find that often when the drives are spun back up to serve a disk request, one of the ata devices times out and my system goes into a never ending loop of retrying. At that point I'm lucky if I'm able to shutdown gracefully. This is what is logged on the console after the disk spin up message: ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad8: WARNING - SET_MULTI taskqueue timeout - completing request directly ad8: TIMEOUT - READ_DMA retrying (1 retry left) LBA=20047817 ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad8: WARNING - SET_MULTI taskqueue timeout - completing request directly ad8: TIMEOUT - READ_DMA retrying (0 retries left) LBA=20047817 I can only reproduce it when my gmirror volume is running. Any ideas? Thanks, Aragon From ubm at u-boot-man.de Wed May 14 20:35:23 2008 From: ubm at u-boot-man.de (Marc UBM Bocklet) Date: Wed May 14 20:35:28 2008 Subject: Status of ZFS in -stable? In-Reply-To: <48291889.8030406@pldrouin.net> References: <48291889.8030406@pldrouin.net> Message-ID: <20080514223515.84553317.ubm@u-boot-man.de> On Tue, 13 May 2008 00:26:49 -0400 Pierre-Luc Drouin wrote: > Hi, > > I would like to know if the memory allocation problem with zfs has > been fixed in -stable? Is zfs considered to be more "stable" now? > > Thanks! > Pierre-Luc Drouin We just set up a zfs based fileserver in our home. It's accessed via samba and ftp, connected via an em 1gb card. FreeBSD is installed on an 80GB ufs2 disk, the zpool consists of two 750GB disks, set up as raidz (my mistake, mirror would probably have been the better choice). We've been using it for about 2 weeks now and there have been no problems (transferred lots of big and small files off/on it, maxing out disk speed). System is amd64, 4gb of ram. FreeBSD blah 7.0-STABLE-200804 FreeBSD 7.0-STABLE-200804 #0: Thu Apr 10 16:32:11 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Bye Marc -- "A sudden blow: the great wings beating still Above the staggering girl, her thighs caressed By the dark webs, her nape caught in his bill, He holds her helpless breast upon his breast." W.B. Yeats, Leda and the Swan From yurtesen at ispro.net Wed May 14 21:05:41 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Wed May 14 21:06:08 2008 Subject: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. Message-ID: <482B4DEE.3050705@ispro.net> Hello, I have a FreeBSD 7.0-STABLE amd64 box which gives this message with apache 2.2 very often. Previously the contents of the box was on 6.3-STABLE x86 and I had no such problems. This started right away when we moved to 7, 64bit. FreeBSD web.XXXXX.com 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Apr 22 02:13:30 UTC 2008 yurtesen@web.XXXXX.com:/usr/obj/usr/src/sys/WEB amd64 Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. I have increased vm.pmap.shpgperproc to 2000 and this seemed to stop complaints for a little while but they occur again... ipcs -a return nothing web:/root#ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME web:/root# Here are the active sysctl values: vm.pmap.pmap_collect_active: 0 vm.pmap.pmap_collect_inactive: 0 vm.pmap.pv_entry_spare: 7366 vm.pmap.pv_entry_allocs: 93953399357 vm.pmap.pv_entry_frees: 93953160939 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pc_chunk_frees: 559631374 vm.pmap.pc_chunk_allocs: 559632837 vm.pmap.pc_chunk_count: 1463 vm.pmap.pv_entry_count: 238418 vm.pmap.shpgperproc: 2000 vm.pmap.pv_entry_max: 13338058 The box is lightly loaded, it is an 8 core box with load average about 0.2-0.4 Any ideas about what to check/do next? I only could find a post which suggests using: kern.ipc.shm_use_phys: 1 But I already set it and it has no effect...box has 4gb of memory: CPU: 0.1% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.9% idle Mem: 180M Active, 1584M Inact, 467M Wired, 131M Cache, 214M Buf, 1578M Free Swap: 8192M Total, 8548K Used, 8184M Free I have the following in make.conf CPUTYPE?=core2 CFLAGS= -O2 -fno-strict-aliasing -pipe CXXFLAGS+= -fconserve-space COPTFLAGS= -O -pipe NO_GAMES=true NO_PROFILE=true WITHOUT_X11=true below is the kernel config file: cpu HAMMER ident WEB options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols #options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI #options AUDIT # Security event auditing # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device twa # 3ware 9000 series PATA/SATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # My Additions # Statically Link in accept filters options ACCEPT_FILTER_DATA options ACCEPT_FILTER_HTTP # Other Devices & Options device snp #Snoop device - to look at pty/vty/etc.. Any ideas on what might be going on? Thanks, Evren From davids at webmaster.com Thu May 15 00:40:37 2008 From: davids at webmaster.com (David Schwartz) Date: Thu May 15 00:40:43 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482B0297.2050300@icyb.net.ua> Message-ID: > I am trying the small attached program on FreeBSD 6.3 (amd64, > SCHED_4BSD) and 7-STABLE (i386, SCHED_ULE), both with libthr as threads > library and on both it produces "BROKEN" message. > > I compile this program as follows: > cc sched_test.c -o sched_test -pthread > > I believe that the behavior I observe is broken because: if thread #1 > releases a mutex and then tries to re-acquire it while thread #2 was > already blocked waiting on that mutex, then thread #1 should be "queued" > after thread #2 in mutex waiter's list. > > Is there any option (thread scheduler, etc) that I could try to achieve > "good" behavior? > > P.S. I understand that all this is subject to (thread) scheduler policy, > but I think that what I expect is more reasonable, at least it is more > reasonable for my application. > > -- > Andriy Gapon Are you out of your mind?! You are specifically asking for the absolute worst possible behavior! If you have fifty tiny things to do on one side of the room and fifty tiny things to do on the other side, do you cross the room after each one? Of course not. That would be *ludicrous*. If you want/need strict alternation, feel free to code it. But it's the maximally inefficient scheduler behavior, and it sure as hell had better not be the default. DS From koitsu at FreeBSD.org Thu May 15 01:00:28 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu May 15 01:00:32 2008 Subject: instability with gmirror and atacontrol spindown In-Reply-To: <20080514202042.GA23704@phat.za.net> References: <20080514202042.GA23704@phat.za.net> Message-ID: <20080515010028.GA84942@eos.sc1.parodius.com> On Wed, May 14, 2008 at 10:20:42PM +0200, Aragon Gouveia wrote: > This is what is logged on the console after the disk spin up message: > > ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing > request directly > ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing > request directly > ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing > request directly > ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing > request directly > ad8: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad8: TIMEOUT - READ_DMA retrying (1 retry left) LBA=20047817 > ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing > request directly > ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing > request directly > ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing > request directly > ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing > request directly > ad8: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad8: TIMEOUT - READ_DMA retrying (0 retries left) LBA=20047817 > > > I can only reproduce it when my gmirror volume is running. > > Any ideas? http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Thu May 15 01:03:47 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu May 15 01:03:52 2008 Subject: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. In-Reply-To: <482B4DEE.3050705@ispro.net> References: <482B4DEE.3050705@ispro.net> Message-ID: <20080515010347.GA85202@eos.sc1.parodius.com> On Wed, May 14, 2008 at 11:39:10PM +0300, Evren Yurtesen wrote: > Approaching the limit on PV entries, consider increasing either the > vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. > Approaching the limit on PV entries, consider increasing either the > vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. I've seen this message on one of our i386 RELENG_7 boxes, which has a medium load (webserver with PHP) and 2GB RAM. Our counters, for comparison: vm.pmap.pmap_collect_active: 0 vm.pmap.pmap_collect_inactive: 0 vm.pmap.pv_entry_spare: 7991 vm.pmap.pv_entry_allocs: 807863761 vm.pmap.pv_entry_frees: 807708792 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pc_chunk_frees: 2580082 vm.pmap.pc_chunk_allocs: 2580567 vm.pmap.pc_chunk_count: 485 vm.pmap.pv_entry_count: 154969 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 1745520 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From davidxu at freebsd.org Thu May 15 04:20:46 2008 From: davidxu at freebsd.org (David Xu) Date: Thu May 15 04:20:48 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482B0297.2050300@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> Message-ID: <482BBA77.8000704@freebsd.org> Andriy Gapon wrote: > I am trying the small attached program on FreeBSD 6.3 (amd64, > SCHED_4BSD) and 7-STABLE (i386, SCHED_ULE), both with libthr as threads > library and on both it produces "BROKEN" message. > > I compile this program as follows: > cc sched_test.c -o sched_test -pthread > > I believe that the behavior I observe is broken because: if thread #1 > releases a mutex and then tries to re-acquire it while thread #2 was > already blocked waiting on that mutex, then thread #1 should be "queued" > after thread #2 in mutex waiter's list. > > Is there any option (thread scheduler, etc) that I could try to achieve > "good" behavior? > > P.S. I understand that all this is subject to (thread) scheduler policy, > but I think that what I expect is more reasonable, at least it is more > reasonable for my application. > In fact, libthr is trying to avoid this conveying, if thread #1 hands off the ownership to thread #2, it will cause lots of context switch, in the idea world, I would let thread #1 to run until it exhausts its time slice, and at the end of its time slices, thread #2 will get the mutex ownership, of course it is difficult to make this work on SMP, but on UP, I would expect the result will be close enough if thread scheduler is sane, so we don't raise priority in kernel umtx code if a thread is blocked, this gives thread #1 some times to re-acquire the mutex without context switches, increases throughput. Regards, David Xu From b.j.casavant at ieee.org Thu May 15 05:56:59 2008 From: b.j.casavant at ieee.org (Brent Casavant) Date: Thu May 15 05:57:07 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482B0297.2050300@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> Message-ID: On Wed, 14 May 2008, Andriy Gapon wrote: > I believe that the behavior I observe is broken because: if thread #1 > releases a mutex and then tries to re-acquire it while thread #2 was > already blocked waiting on that mutex, then thread #1 should be "queued" > after thread #2 in mutex waiter's list. The behavior of scheduling with respect to mutex contention (apart from pthread_mutexattr_setprotocol()) is not specified by POSIX, to the best of my knowledge, and thus is left to the discretion of the implementation. > Is there any option (thread scheduler, etc) that I could try to achieve > "good" behavior? No portable mechanism, and not any mechanism in the operating systems with which I am familiar. That said, as the behavior is not specified by POSIX, there would be nothing preventing an implementation from providing this as an optional behavior through a custom pthread_mutexattr_???_np() interface. > P.S. I understand that all this is subject to (thread) scheduler policy, > but I think that what I expect is more reasonable, at least it is more > reasonable for my application. As other responders have indicated, the behavior you desire is as unoptimal as possible for the general case. If your application would truly benefit from this sort of queuing behavior, I'd suggest that either you need to implement your own mechanism to accomplish the queueing (probably the easier fix), or that the threading architecture of your application could be designed in a different manner that avoids this problem (probably the more difficult fix). Brent -- Brent Casavant Dance like everybody should be watching. www.angeltread.org KD5EMB, EN34lv From bazzoola at gmail.com Thu May 15 07:06:30 2008 From: bazzoola at gmail.com (bazzoola) Date: Thu May 15 07:06:34 2008 Subject: Auto bridge for qemu network [was: kqemu support: not compiled] In-Reply-To: <20080513054223.2CAC95B4B@mail.bitblocks.com> References: <20080513054223.2CAC95B4B@mail.bitblocks.com> Message-ID: <6601D6DC-AD09-4028-A25A-59899C9A57E4@gmail.com> Thanks for updating the port! I have few suggestions: #cat /etc/rc.conf [...] #KQEMU for qemu kqemu_enable="YES" #Bridge for qemu cloned_interfaces="bridge0" ifconfig_bridge0="up addm sk0" autobridge_interfaces="bridge0" autobridge_bridge0="tap*" This should take care of the network connection between qemu virtual host and the host instead of doing it manually. Assuming that qemu is using tap and the default "if" on the host is sk0. Also, is it possible to update this page, it has some outdated info: http://people.freebsd.org/~maho/qemu/qemu.html *It is the 1st answer from google when asked "freebsd qemu" From yurtesen at ispro.net Thu May 15 07:17:05 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Thu May 15 07:17:11 2008 Subject: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. In-Reply-To: <20080515010347.GA85202@eos.sc1.parodius.com> References: <482B4DEE.3050705@ispro.net> <20080515010347.GA85202@eos.sc1.parodius.com> Message-ID: <482BE398.8010203@ispro.net> Jeremy Chadwick wrote: > On Wed, May 14, 2008 at 11:39:10PM +0300, Evren Yurtesen wrote: >> Approaching the limit on PV entries, consider increasing either the >> vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. >> Approaching the limit on PV entries, consider increasing either the >> vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. > > I've seen this message on one of our i386 RELENG_7 boxes, which has a > medium load (webserver with PHP) and 2GB RAM. Our counters, for > comparison: > > vm.pmap.pmap_collect_active: 0 > vm.pmap.pmap_collect_inactive: 0 > vm.pmap.pv_entry_spare: 7991 > vm.pmap.pv_entry_allocs: 807863761 > vm.pmap.pv_entry_frees: 807708792 > vm.pmap.pc_chunk_tryfail: 0 > vm.pmap.pc_chunk_frees: 2580082 > vm.pmap.pc_chunk_allocs: 2580567 > vm.pmap.pc_chunk_count: 485 > vm.pmap.pv_entry_count: 154969 > vm.pmap.shpgperproc: 200 > vm.pmap.pv_entry_max: 1745520 > I guess one good question is, how can one see the number of PV entries used by a process? shouldnt these appear in the output of ipcs -a command? Another good question is, in many places there is references to rebooting after putting a new vm.pmap.shpgperproc value to loader.conf. However I just changed this on a running system, has it really been changed or was I suppose to reboot? In either case, I already increased vm.pmap.shpgperproc to 2000 (from 200) and still the error occurs, there is not so much load on this box, maybe there is a leak somewhere? Thanks, Evren From avg at icyb.net.ua Thu May 15 08:36:02 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu May 15 08:36:10 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482BBA77.8000704@freebsd.org> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> Message-ID: <482BF5EA.5010806@icyb.net.ua> on 15/05/2008 07:22 David Xu said the following: > In fact, libthr is trying to avoid this conveying, if thread #1 > hands off the ownership to thread #2, it will cause lots of context > switch, in the idea world, I would let thread #1 to run until it > exhausts its time slice, and at the end of its time slices, > thread #2 will get the mutex ownership, of course it is difficult to > make this work on SMP, but on UP, I would expect the result will > be close enough if thread scheduler is sane, so we don't raise > priority in kernel umtx code if a thread is blocked, this gives > thread #1 some times to re-acquire the mutex without context switches, > increases throughput. Brent, David, thank you for the responses. I think I incorrectly formulated my original concern. It is not about behavior at mutex unlock but about behavior at mutex re-lock. You are right that waking waiters at unlock would hurt performance. But I think that it is not "fair" that at re-lock former owner gets the lock immediately and the thread that waited on it for longer time doesn't get a chance. Here's a more realistic example than the mock up code. Say you have a worker thread that processes queued requests and the load is such that there is always something on the queue. Thus the worker thread doesn't ever have to block waiting on it. And let's say that there is a GUI thread that wants to convey some information to the worker thread. And for that it needs to acquire some mutex and "do something". With current libthr behavior the GUI thread would never have a chance to get the mutex as worker thread would always be a winner (as my small program shows). Or even more realistic: there should be a feeder thread that puts things on the queue, it would never be able to enqueue new items until the queue becomes empty if worker thread's code looks like the following: while(1) { pthread_mutex_lock(&work_mutex); while(queue.is_empty()) pthread_cond_wait(...); //dequeue item ... pthread_mutex_unlock(&work mutex); //perform some short and non-blocking processing of the item ... } Because the worker thread (while the queue is not empty) would never enter cond_wait and would always re-lock the mutex shortly after unlocking it. So while improving performance on small scale this mutex re-acquire-ing unfairness may be hurting interactivity and thread concurrency and thus performance in general. E.g. in the above example queue would always be effectively of depth 1. Something about "lock starvation" comes to mind. So, yes, this is not about standards, this is about reasonable expectations about thread concurrency behavior in a particular implementation (libthr). I see now that performance advantage of libthr over libkse came with a price. I think that something like queued locks is needed. They would clearly reduce raw throughput performance, so maybe that should be a new (non-portable?) mutex attribute. -- Andriy Gapon From marcolz at stack.nl Thu May 15 08:51:55 2008 From: marcolz at stack.nl (Marc Olzheim) Date: Thu May 15 08:52:01 2008 Subject: bin/40278: mktime returns -1 for certain dates/timezones when it should normalize Message-ID: <20080515085154.GA72314@stack.nl> With the testcode I put on http://www.stack.nl/~marcolz/FreeBSD/pr-bin-40278/40278.c I can reproduce it on FreeBSD 4.11: output on 4.11-STABLE ------ Init: mktime: 1014944400 Fri Mar 1 02:00:00 CET 2002 1: mktime: 4294967295 Fri Apr 0 02:00:00 CET 2002 Init: mktime: 1014944400 Fri Mar 1 02:00:00 CET 2002 2a: mktime: 1017622800 Mon Apr 1 03:00:00 CEST 2002 2b: mktime: 1017536400 Sun Mar 31 03:00:00 CEST 2002 Init: mktime: 1014944400 Fri Mar 1 02:00:00 CET 2002 3a: mktime: 1014858000 Thu Feb 28 02:00:00 CET 2002 3b: mktime: 1017277200 Thu Mar 28 02:00:00 CET 2002 ------ But it is fixed on my FreeBSD 6.x and up systems: output on 6.3-PRERELEASE: ------ Init: mktime: 1014944400 Fri Mar 1 02:00:00 CET 2002 1: mktime: 1017536400 Sun Mar 31 03:00:00 CEST 2002 Init: mktime: 1014944400 Fri Mar 1 02:00:00 CET 2002 2a: mktime: 1017622800 Mon Apr 1 03:00:00 CEST 2002 2b: mktime: 1017536400 Sun Mar 31 03:00:00 CEST 2002 Init: mktime: 1014944400 Fri Mar 1 02:00:00 CET 2002 3a: mktime: 1014858000 Thu Feb 28 02:00:00 CET 2002 3b: mktime: 1017277200 Thu Mar 28 02:00:00 CET 2002 ------ So it looks like it has been fixed in the mean time and that this PR can be closed. Marc From avg at icyb.net.ua Thu May 15 09:01:17 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu May 15 09:01:34 2008 Subject: thread scheduling at mutex unlock References: Message-ID: <482BFBDA.6060705@icyb.net.ua> David Schwartz wrote: > Are you out of your mind?! You are specifically asking for the absolute = > worst possible behavior! > > If you have fifty tiny things to do on one side of the room and fifty = > tiny things to do on the other side, do you cross the room after each = > one? Of course not. That would be *ludicrous*. > > If you want/need strict alternation, feel free to code it. But it's the = > maximally inefficient scheduler behavior, and it sure as hell had better = > not be the default. David, what if you have an infinite number of items on one side and finite number on the other, and you want to process them all (in infinite time, of course). Would you still try to finish everything on one side (the infinite one) or would you try to look at what you have on the other side? I am sorry about fuzzy wording of my original report, I should have mentioned "starvation" somewhere in it. -- Andriy Gapon From davidxu at freebsd.org Thu May 15 09:04:09 2008 From: davidxu at freebsd.org (David Xu) Date: Thu May 15 09:04:17 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482BF5EA.5010806@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> Message-ID: <482BFCE3.7080704@freebsd.org> Andriy Gapon wrote: > Brent, David, > > thank you for the responses. > I think I incorrectly formulated my original concern. > It is not about behavior at mutex unlock but about behavior at mutex > re-lock. You are right that waking waiters at unlock would hurt > performance. But I think that it is not "fair" that at re-lock former > owner gets the lock immediately and the thread that waited on it for > longer time doesn't get a chance. > > Here's a more realistic example than the mock up code. > Say you have a worker thread that processes queued requests and the load > is such that there is always something on the queue. Thus the worker > thread doesn't ever have to block waiting on it. > And let's say that there is a GUI thread that wants to convey some > information to the worker thread. And for that it needs to acquire some > mutex and "do something". > With current libthr behavior the GUI thread would never have a chance to > get the mutex as worker thread would always be a winner (as my small > program shows). > Or even more realistic: there should be a feeder thread that puts things > on the queue, it would never be able to enqueue new items until the > queue becomes empty if worker thread's code looks like the following: > > while(1) > { > pthread_mutex_lock(&work_mutex); > while(queue.is_empty()) > pthread_cond_wait(...); > //dequeue item > ... > pthread_mutex_unlock(&work mutex); > //perform some short and non-blocking processing of the item > ... > } > > Because the worker thread (while the queue is not empty) would never > enter cond_wait and would always re-lock the mutex shortly after > unlocking it. > > So while improving performance on small scale this mutex re-acquire-ing > unfairness may be hurting interactivity and thread concurrency and thus > performance in general. E.g. in the above example queue would always be > effectively of depth 1. > Something about "lock starvation" comes to mind. > > So, yes, this is not about standards, this is about reasonable > expectations about thread concurrency behavior in a particular > implementation (libthr). > I see now that performance advantage of libthr over libkse came with a > price. I think that something like queued locks is needed. They would > clearly reduce raw throughput performance, so maybe that should be a new > (non-portable?) mutex attribute. > You forgot that default scheduling policy is time-sharing, after thread #2 has blocked on the mutex for a while, when thread #1 unlocks the mutex and unblocks thread #1, the thread #2's priority will be raised and it preempts thread #1, the thread #2 then acquires the mutex, that's how it balances between fairness and performance. Regards, David Xu From avg at icyb.net.ua Thu May 15 09:27:36 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu May 15 09:27:43 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482BFCE3.7080704@freebsd.org> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> <482BFCE3.7080704@freebsd.org> Message-ID: <482C0206.1050206@icyb.net.ua> on 15/05/2008 12:05 David Xu said the following: > Andriy Gapon wrote: > >> Brent, David, >> >> thank you for the responses. >> I think I incorrectly formulated my original concern. >> It is not about behavior at mutex unlock but about behavior at mutex >> re-lock. You are right that waking waiters at unlock would hurt >> performance. But I think that it is not "fair" that at re-lock former >> owner gets the lock immediately and the thread that waited on it for >> longer time doesn't get a chance. >> >> Here's a more realistic example than the mock up code. >> Say you have a worker thread that processes queued requests and the >> load is such that there is always something on the queue. Thus the >> worker thread doesn't ever have to block waiting on it. >> And let's say that there is a GUI thread that wants to convey some >> information to the worker thread. And for that it needs to acquire >> some mutex and "do something". >> With current libthr behavior the GUI thread would never have a chance >> to get the mutex as worker thread would always be a winner (as my >> small program shows). >> Or even more realistic: there should be a feeder thread that puts >> things on the queue, it would never be able to enqueue new items until >> the queue becomes empty if worker thread's code looks like the following: >> >> while(1) >> { >> pthread_mutex_lock(&work_mutex); >> while(queue.is_empty()) >> pthread_cond_wait(...); >> //dequeue item >> ... >> pthread_mutex_unlock(&work mutex); >> //perform some short and non-blocking processing of the item >> ... >> } >> >> Because the worker thread (while the queue is not empty) would never >> enter cond_wait and would always re-lock the mutex shortly after >> unlocking it. >> >> So while improving performance on small scale this mutex >> re-acquire-ing unfairness may be hurting interactivity and thread >> concurrency and thus performance in general. E.g. in the above example >> queue would always be effectively of depth 1. >> Something about "lock starvation" comes to mind. >> >> So, yes, this is not about standards, this is about reasonable >> expectations about thread concurrency behavior in a particular >> implementation (libthr). >> I see now that performance advantage of libthr over libkse came with a >> price. I think that something like queued locks is needed. They would >> clearly reduce raw throughput performance, so maybe that should be a >> new (non-portable?) mutex attribute. >> > > You forgot that default scheduling policy is time-sharing, after thread > #2 has blocked on the mutex for a while, when thread #1 unlocks the > mutex and unblocks thread #1, the thread #2's priority will be raised > and it preempts thread #1, the thread #2 then acquires the mutex, > that's how it balances between fairness and performance. Maybe. But that's not what I see with my small example program. One thread releases and re-acquires a mutex 10 times in a row while the other doesn't get it a single time. I think that there is a very slim chance of a blocked thread preempting a running thread in this circumstances. Especially if execution time between unlock and re-lock is very small. I'd rather prefer to have an option to have FIFO fairness in mutex lock rather than always avoiding context switch at all costs and depending on scheduler to eventually do priority magic. -- Andriy Gapon From Nick.Barnes at pobox.com Thu May 15 09:29:45 2008 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Thu May 15 09:29:56 2008 Subject: syslog console log not logging SCSI problems Message-ID: <60281.1210842841@thrush.ravenbrook.com> One of our FreeBSD boxes has a SCSI controller and disk, which showed problems earlier this week. There was a lot of of chatter from the SCSI driver in /var/log/messages and to the console. However, the console is unattended and we only discovered the problem subsequently because /var/log/console.log didn't show any of the chatter. console.log is otherwise working, and very helpful (e.g. it shows /etc/rc output at boot which lets us spot daemon failures). We've rebuilt the machine now (fan failure leading to boot disk failure), so I can't report the SCSI chatter in question, but here is the dmesg and syslog.conf. Any suggestions? (yes, I know this is 6.2-RELEASE; I'm partway through cvsupping; the failure was under 6.2p11). Thanks in advance, Nick Barnes dmesg: 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-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3006.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 Features=0xbfebfbff Features2=0x649d> AMD Features=0x20100000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 2137440256 (2038 MB) avail memory = 2086498304 (1989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 cpu1: on acpi0 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 2.0 (no driver attached) pci0: at device 27.0 (no driver attached) pcib1: at device 28.0 on pci0 pci1: on pcib1 pcib2: at device 28.2 on pci0 pci2: on pcib2 pcib3: at device 28.3 on pci0 pci3: on pcib3 uhci0: port 0x2080-0x209f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0x901c4000-0x901c43ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 ahc0: port 0x1000-0x10ff mem 0x90000000-0x90000fff irq 21 at device 0.0 on pci4 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs fxp0: port 0x1100-0x113f mem 0x90001000-0x90001fff irq 20 at device 8.0 on pci4 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:16:76:1c:01:2f isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20b0-0x20bf irq 18 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af irq 19 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 ad4: 238475MB at ata2-master SATA150 Waiting 5 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0: 35074MB (71833096 512 byte sectors: 255H 63S/T 4471C) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a syslog.conf: # $FreeBSD: src/etc/syslog.conf,v 1.28 2005/03/12 12:31:16 glebius Exp $ # # Spaces ARE valid field separators in this file. However, # other *nix-like systems still insist on using tabs as field # separators. If you are sharing this file between systems, you # may want to use only tabs as field separators here. # Consult the syslog.conf(5) manpage. *.err;kern.warning;auth.notice;mail.crit /dev/console *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.*;auth.* /var/log/security auth.info;authpriv.info /var/log/auth.log mail.info /var/log/maillog lpr.info /var/log/lpd-errs ftp.info /var/log/xferlog cron.* /var/log/cron *.=debug /var/log/debug.log *.emerg * console.* /var/log/console.log # uncomment this to enable logging of all log messages to /var/log/all.log # touch /var/log/all.log and chmod it to mode 600 before it will work #*.* /var/log/all.log # uncomment this to enable logging to a remote loghost named loghost #*.* @loghost # uncomment these if you're running inn # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice !startslip *.* /var/log/slip.log !ppp *.* /var/log/ppp.log From koitsu at FreeBSD.org Thu May 15 09:46:33 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu May 15 09:46:41 2008 Subject: syslog console log not logging SCSI problems In-Reply-To: <60281.1210842841@thrush.ravenbrook.com> References: <60281.1210842841@thrush.ravenbrook.com> Message-ID: <20080515094632.GA2738@eos.sc1.parodius.com> On Thu, May 15, 2008 at 10:14:01AM +0100, Nick Barnes wrote: > One of our FreeBSD boxes has a SCSI controller and disk, which showed > problems earlier this week. There was a lot of of chatter from the > SCSI driver in /var/log/messages and to the console. However, the > console is unattended and we only discovered the problem subsequently > because /var/log/console.log didn't show any of the chatter. > > console.log is otherwise working, and very helpful (e.g. it shows > /etc/rc output at boot which lets us spot daemon failures). > > We've rebuilt the machine now (fan failure leading to boot disk > failure), so I can't report the SCSI chatter in question, but here is > the dmesg and syslog.conf. Any suggestions? /boot/loader.conf, /boot.config, and /etc/make.conf would also be useful. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bu7cher at yandex.ru Thu May 15 09:52:40 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Thu May 15 09:52:51 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> Message-ID: <482C07DE.3090504@yandex.ru> Vivek Khera wrote: > I had a box run out of dynamic state space yesterday. I found I can > increase the number of dynamic rules by increasing the sysctl parameter > net.inet.ip.fw.dyn_max. I can't find, however, how this affects memory > usage on the system. Is it dyanamically allocated and de-allocated, or > is it a static memory buffer? Each dynamic rule allocated dynamically. Be careful, too many dynamic rules will work very slow. -- WBR, Andrey V. Elsukov From Nick.Barnes at pobox.com Thu May 15 09:55:53 2008 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Thu May 15 09:56:00 2008 Subject: syslog console log not logging SCSI problems In-Reply-To: <20080515094632.GA2738@eos.sc1.parodius.com> from Jeremy Chadwick of "Thu, 15 May 2008 02:46:32 -0700" Message-ID: <60461.1210845350@thrush.ravenbrook.com> At 2008-05-15 09:46:32+0000, Jeremy Chadwick writes: > On Thu, May 15, 2008 at 10:14:01AM +0100, Nick Barnes wrote: > > One of our FreeBSD boxes has a SCSI controller and disk, which showed > > problems earlier this week. There was a lot of of chatter from the > > SCSI driver in /var/log/messages and to the console. However, the > > console is unattended and we only discovered the problem subsequently > > because /var/log/console.log didn't show any of the chatter. > > > > console.log is otherwise working, and very helpful (e.g. it shows > > /etc/rc output at boot which lets us spot daemon failures). > > > > We've rebuilt the machine now (fan failure leading to boot disk > > failure), so I can't report the SCSI chatter in question, but here is > > the dmesg and syslog.conf. Any suggestions? > > /boot/loader.conf, /boot.config, and /etc/make.conf would also be > useful. All empty, except setting kern.maxdsiz in /boot/loader.conf. Running GENERIC. If this happens again, I will retain a copy of /var/log/messages so I can report the SCSI messages in question, but they aren't as interesting to me as the fact that they didn't appear in console.log. Nick B From koitsu at FreeBSD.org Thu May 15 10:02:03 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu May 15 10:02:07 2008 Subject: syslog console log not logging SCSI problems In-Reply-To: <60461.1210845350@thrush.ravenbrook.com> References: <20080515094632.GA2738@eos.sc1.parodius.com> <60461.1210845350@thrush.ravenbrook.com> Message-ID: <20080515100203.GA3303@eos.sc1.parodius.com> On Thu, May 15, 2008 at 10:55:50AM +0100, Nick Barnes wrote: > At 2008-05-15 09:46:32+0000, Jeremy Chadwick writes: > > On Thu, May 15, 2008 at 10:14:01AM +0100, Nick Barnes wrote: > > > One of our FreeBSD boxes has a SCSI controller and disk, which showed > > > problems earlier this week. There was a lot of of chatter from the > > > SCSI driver in /var/log/messages and to the console. However, the > > > console is unattended and we only discovered the problem subsequently > > > because /var/log/console.log didn't show any of the chatter. > > > > > > console.log is otherwise working, and very helpful (e.g. it shows > > > /etc/rc output at boot which lets us spot daemon failures). > > > > > > We've rebuilt the machine now (fan failure leading to boot disk > > > failure), so I can't report the SCSI chatter in question, but here is > > > the dmesg and syslog.conf. Any suggestions? > > > > /boot/loader.conf, /boot.config, and /etc/make.conf would also be > > useful. > > All empty, except setting kern.maxdsiz in /boot/loader.conf. Running > GENERIC. > > If this happens again, I will retain a copy of /var/log/messages so I > can report the SCSI messages in question, but they aren't as > interesting to me as the fact that they didn't appear in console.log. I've seen odd behaviour with syslog before, but it's hard to explain. I don't use the console.info entry in /etc/syslog.conf, so I can't tell you what's going on there. Another thing I can think of would be your kernel configuration. Can you provide it? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bms at FreeBSD.org Thu May 15 10:03:56 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu May 15 10:04:03 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <482C07DE.3090504@yandex.ru> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> Message-ID: <482C0A89.104@FreeBSD.org> Andrey V. Elsukov wrote: > Vivek Khera wrote: >> I had a box run out of dynamic state space yesterday. I found I can >> increase the number of dynamic rules by increasing the sysctl >> parameter net.inet.ip.fw.dyn_max. I can't find, however, how this >> affects memory usage on the system. Is it dyanamically allocated and >> de-allocated, or is it a static memory buffer? > > Each dynamic rule allocated dynamically. Be careful, too many dynamic > rules will work very slow. Got any figures for this? I took a quick glance and it looks like it just uses a hash over dst/src/dport/sport. If there are a lot of raw IP or ICMP flows then that's going to result in hash collisions. It might be a good project for someone to optimize if it isn't scaling for folk. "Bloomier" filters are probably worth a look -- bloom filters are a class of probabilistic hash which may return a false positive, "bloomier" filters are a refinement which tries to limit the false positives. Having said that the default tunable of 256 state entries is probably quite low for use cases other than "home/small office NAT gateway". cheers BMS From Nick.Barnes at pobox.com Thu May 15 10:21:54 2008 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Thu May 15 10:22:10 2008 Subject: syslog console log not logging SCSI problems In-Reply-To: <20080515100203.GA3303@eos.sc1.parodius.com> from Jeremy Chadwick of "Thu, 15 May 2008 03:02:03 -0700" Message-ID: <60574.1210846911@thrush.ravenbrook.com> At 2008-05-15 10:02:03+0000, Jeremy Chadwick writes: > Another thing I can think of would be your kernel configuration. Can > you provide it? Just GENERIC. By the way, the need to set kern.maxdsiz - for really big processes - doesn't seem to be documented anywhere. I could have sworn it used to be in the Handbook, but I don't see it there. I guess it should be both there and in tuning(7). Rediscovering this switch took me 30 minutes yesterday. Nick B From davidxu at freebsd.org Thu May 15 12:57:21 2008 From: davidxu at freebsd.org (David Xu) Date: Thu May 15 12:57:35 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482C0206.1050206@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> <482BFCE3.7080704@freebsd.org> <482C0206.1050206@icyb.net.ua> Message-ID: <482C3333.1070205@freebsd.org> Andriy Gapon wrote: > > Maybe. But that's not what I see with my small example program. One > thread releases and re-acquires a mutex 10 times in a row while the > other doesn't get it a single time. > I think that there is a very slim chance of a blocked thread > preempting a running thread in this circumstances. Especially if > execution time between unlock and re-lock is very small. It does not depends on how many times your thread acquires or re-acquires mutex, or how small the region the mutex is protecting. as long as current thread runs too long, other threads will have higher priorities and the ownership definitely will be transfered, though there will be some extra context switchings. > I'd rather prefer to have an option to have FIFO fairness in mutex > lock rather than always avoiding context switch at all costs and > depending on scheduler to eventually do priority magic. > It is better to implement this behavior in your application code, if it is implemented in thread library, you still can not control how many times acquiring and re-acquiring can be allowed for a thread without context switching, a simple FIFO as you said here will cause dreadful performance problem. From deischen at freebsd.org Thu May 15 13:45:51 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Thu May 15 13:46:01 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482BF5EA.5010806@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> Message-ID: On Thu, 15 May 2008, Andriy Gapon wrote: > Or even more realistic: there should be a feeder thread that puts things on > the queue, it would never be able to enqueue new items until the queue > becomes empty if worker thread's code looks like the following: > > while(1) > { > pthread_mutex_lock(&work_mutex); > while(queue.is_empty()) > pthread_cond_wait(...); > //dequeue item > ... > pthread_mutex_unlock(&work mutex); > //perform some short and non-blocking processing of the item > ... > } > > Because the worker thread (while the queue is not empty) would never enter > cond_wait and would always re-lock the mutex shortly after unlocking it. Well in theory, the kernel scheduler will let both threads run fairly with regards to their cpu usage, so this should even out the enqueueing and dequeueing threads. You could also optimize the above a little bit by dequeueing everything in the queue instead of one at a time. > So while improving performance on small scale this mutex re-acquire-ing > unfairness may be hurting interactivity and thread concurrency and thus > performance in general. E.g. in the above example queue would always be > effectively of depth 1. > Something about "lock starvation" comes to mind. > > So, yes, this is not about standards, this is about reasonable expectations > about thread concurrency behavior in a particular implementation (libthr). > I see now that performance advantage of libthr over libkse came with a price. > I think that something like queued locks is needed. They would clearly reduce > raw throughput performance, so maybe that should be a new (non-portable?) > mutex attribute. -- DE From lightguard.jp at gmail.com Thu May 15 14:59:07 2008 From: lightguard.jp at gmail.com (Jason Porter) Date: Thu May 15 14:59:12 2008 Subject: Upgrade path from 5.5? Message-ID: <699477f60805150731p1f396bbaj27fc9ed49e69a916@mail.gmail.com> I have an old sandbox (obviously if it's 5.5) that I was thinking of upgrading. Is there an upgrade path I should think about taking, or would it be best to backup my /home directory and install from scratch? Note, I'm currently not subscribed to the list. -- --Jason Porter Real Programmers think better when playing Adventure or Rogue. PGP key id: 926CCFF5 PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5 PGP key available at: keyserver.net, pgp.mit.edu From gavin at FreeBSD.org Thu May 15 15:10:49 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu May 15 15:11:03 2008 Subject: bin/40278: mktime returns -1 for certain dates/timezones when it should normalize In-Reply-To: <20080515085154.GA72314@stack.nl> References: <20080515085154.GA72314@stack.nl> Message-ID: <1210864245.29891.93.camel@buffy.york.ac.uk> On Thu, 2008-05-15 at 10:51 +0200, Marc Olzheim wrote: > With the testcode I put on > http://www.stack.nl/~marcolz/FreeBSD/pr-bin-40278/40278.c I can > reproduce it on FreeBSD 4.11: [snip] > But it is fixed on my FreeBSD 6.x and up systems: [snip] Many thanks for going to the effort of testing this. I've closed the PR. Gavin From vivek at khera.org Thu May 15 16:09:40 2008 From: vivek at khera.org (Vivek Khera) Date: Thu May 15 16:09:44 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <482C0A89.104@FreeBSD.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> <482C0A89.104@FreeBSD.org> Message-ID: <6ADAB997-FAA4-43B8-AB57-3CC4A04F3700@khera.org> On May 15, 2008, at 6:03 AM, Bruce M. Simpson wrote: > Having said that the default tunable of 256 state entries is > probably quite low for use cases other than "home/small office NAT > gateway". The deafult on my systems seems to be 4096. My steady state on a pretty popular web server is about 400, on a busy inbound mail server, around 800 states. I need to account for peaks much higher, though. Luckily most of my connections are short-lived. Thanks for the answers! From koitsu at FreeBSD.org Thu May 15 16:20:56 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu May 15 16:20:59 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <482C0A89.104@FreeBSD.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> <482C0A89.104@FreeBSD.org> Message-ID: <20080515162056.GA17187@eos.sc1.parodius.com> On Thu, May 15, 2008 at 11:03:53AM +0100, Bruce M. Simpson wrote: > Andrey V. Elsukov wrote: >> Vivek Khera wrote: >>> I had a box run out of dynamic state space yesterday. I found I can >>> increase the number of dynamic rules by increasing the sysctl parameter >>> net.inet.ip.fw.dyn_max. I can't find, however, how this affects memory >>> usage on the system. Is it dyanamically allocated and de-allocated, or >>> is it a static memory buffer? >> >> Each dynamic rule allocated dynamically. Be careful, too many dynamic >> rules will work very slow. > > Got any figures for this? I took a quick glance and it looks like it just > uses a hash over dst/src/dport/sport. If there are a lot of raw IP or ICMP > flows then that's going to result in hash collisions. > > It might be a good project for someone to optimize if it isn't scaling for > folk. "Bloomier" filters are probably worth a look -- bloom filters are a > class of probabilistic hash which may return a false positive, "bloomier" > filters are a refinement which tries to limit the false positives. > > Having said that the default tunable of 256 state entries is probably quite > low for use cases other than "home/small office NAT gateway". It's far too low for home/small office. Standard Linux NAT routers, such as the Linksys WRT54G/GL, come with a default state table count of 2048, and often is increased by third-party firmwares to 8192 based on justified necessity. Search for "conntrack" below: http://www.polarcloud.com/firmware 256 can easily be exhausted by more than one user loading multiple HTTP 1.0 web pages at one time (such is the case with many users now have browsers that load 7-8 web pages into separate tabs during startup). And if that's not enough reason, consider torrents, which is quite often what results in a home or office router exhausting its state table. Bottom line: the 256 default is too low. It needs to be increased to at least 2048. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From serg at tmn.ru Thu May 15 16:33:25 2008 From: serg at tmn.ru (Sergey N. Voronkov) Date: Thu May 15 16:33:29 2008 Subject: Upgrade path from 5.5? In-Reply-To: <699477f60805150731p1f396bbaj27fc9ed49e69a916@mail.gmail.com> References: <699477f60805150731p1f396bbaj27fc9ed49e69a916@mail.gmail.com> Message-ID: <20080515161436.GA52741@tmn.ru> On Thu, May 15, 2008 at 08:31:06AM -0600, Jason Porter wrote: > I have an old sandbox (obviously if it's 5.5) that I was thinking of > upgrading. Is there an upgrade path I should think about taking, or would > it be best to backup my /home directory and install from scratch? Note, I'm > currently not subscribed to the list. Source upgrade 5.5 -> 6.2 -> 6.3 works fine for me. Serg N. Voronkov, Sibitex JSC. From petefrench at ticketswitch.com Thu May 15 17:39:38 2008 From: petefrench at ticketswitch.com (Pete French) Date: Thu May 15 17:39:42 2008 Subject: cron hanging on to child processes Message-ID: I have a process which is run daily from cron that stops mysql, does some stuff, and starts it again. The scriput outputs a number of lines which are emailed to me in the output of the cron job. What I have noticed is that my emials actually lag by a day - it turns out that the cron job appears to not send the email until mysql is sut down the following day. I can only assume that when mysql is restarted, cron sees it as a child process, and thus does not terminate until that process does. Which happens when a new cron job shuts it down again 24 hours later. Any suggestions on fixing this ? I wouldn't have thought that stopping and starting a daemon was a particularly unusual thing to want to do from a cron job. -pete. From deischen at freebsd.org Thu May 15 17:54:12 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Thu May 15 17:54:20 2008 Subject: thread scheduling at mutex unlock In-Reply-To: References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> Message-ID: On Thu, 15 May 2008, Daniel Eischen wrote: > On Thu, 15 May 2008, Andriy Gapon wrote: > >> Or even more realistic: there should be a feeder thread that puts things on >> the queue, it would never be able to enqueue new items until the queue >> becomes empty if worker thread's code looks like the following: >> >> while(1) >> { >> pthread_mutex_lock(&work_mutex); >> while(queue.is_empty()) >> pthread_cond_wait(...); >> //dequeue item >> ... >> pthread_mutex_unlock(&work mutex); >> //perform some short and non-blocking processing of the item >> ... >> } >> >> Because the worker thread (while the queue is not empty) would never enter >> cond_wait and would always re-lock the mutex shortly after unlocking it. > > Well in theory, the kernel scheduler will let both threads run fairly > with regards to their cpu usage, so this should even out the enqueueing > and dequeueing threads. > > You could also optimize the above a little bit by dequeueing everything > in the queue instead of one at a time. I suppose you could also enforce your own scheduling with something like the following: pthread_cond_t writer_cv; pthread_cond_t reader_cv; pthread_mutex_t q_mutex; ... thingy_q_t thingy_q; int writers_waiting = 0; int readers_waiting = 0; ... void enqueue(thingy_t *thingy) { pthread_mutex_lock(q_mutex); /* Insert into thingy q */ ... if (readers_waiting > 0) { pthread_cond_broadcast(&reader_cv, &q_mutex); readers_waiting = 0; } while (thingy_q.size > ENQUEUE_THRESHOLD_HIGH) { writers_waiting++; pthread_cond_wait(&writer_cv, &q_mutex); } pthread_mutex_unlock(&q_mutex); } thingy_t * dequeue(void) { thingy_t *thingy; pthread_mutex_lock(&q_mutex); while (thingy_q.size == 0) { readers_waiting++; pthread_cond_wait(&reader_cv, &q_mutex); } /* Dequeue thingy */ ... if ((writers_waiting > 0) && thingy_q.size < ENQUEUE_THRESHOLD_LOW)) { /* Wakeup the writers. */ pthread_cond_broadcast(&writer_cv, &q_mutex); writers_waiting = 0; } pthread_mutex_unlock(&q_mutex); return (thingy); } The above is completely untested and probably contains some bugs ;-) You probably shouldn't need anything like that if the kernel scheduler is scheduling your threads fairly. -- DE From davids at webmaster.com Thu May 15 19:30:18 2008 From: davids at webmaster.com (David Schwartz) Date: Thu May 15 19:30:21 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482BFBDA.6060705@icyb.net.ua> Message-ID: > what if you have an infinite number of items on one side and finite > number on the other, and you want to process them all (in infinite time, > of course). Would you still try to finish everything on one side (the > infinite one) or would you try to look at what you have on the other side? > > I am sorry about fuzzy wording of my original report, I should have > mentioned "starvation" somewhere in it. There is no such thing as a "fair share" when comparing an infinite quantity to a finite quantity. It is just as sensible to do 1 then 1 as 10 then 10 or a billion then 1. What I would do in this case is work on one side for one timeslice then the other side for one timeslice, continuuing until either side was finished, then I'd work exclusively on the other side. This is precisely the purpose for having timeslices in a scheduler. The timeslice is carefully chosen so that it's not so long that you ignore a side for too long. It's also carefully chosen so that it's not so short that you spend all your time switching swides. What sane schedulers do is assume that you want to make as much forward progress as quickly as possible. This means getting as many work units done per unit time as possible. This means as few context switches as possible. A scheduler that switches significantly more often than once per timeslice with a load like this is *broken*. The purpose of the timeslice is to place an upper bound on the number of context switches in cases where forward progress can be made on more than one process. An ideal scheduler would not switch more often than once per timeslice unless it could not make further forward progress. Real-world schedulers actually may allow one side to pre-empt the other, and may switch a bit more often than a scheduler that's "ideal" in the sense described above. This is done in an attempt to boost interactive performance. But your basic assumption that strict alternation is desirable is massively wrong. That's the *worst* *possible* outcome. DS From b.j.casavant at ieee.org Thu May 15 19:51:27 2008 From: b.j.casavant at ieee.org (Brent Casavant) Date: Thu May 15 19:51:35 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482BF5EA.5010806@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> Message-ID: On Thu, 15 May 2008, Andriy Gapon wrote: > With current libthr behavior the GUI thread would never have a chance to get > the mutex as worker thread would always be a winner (as my small program > shows). The example you gave indicates an incorrect mechanism being used for the GUI to communicate with this worker thread. For the behavior you desire, you need a common condition that lets both the GUI and the work item generator indicate that there is something for the worker to do, *and* you need seperate mechanisms for the GUI and work item generator to add to their respective queues. Something like this (could be made even better with a little effor): struct worker_queues_s { pthread_mutex_t work_mutex; struct work_queue_s work_queue; pthread_mutex_t gui_mutex; struct gui_queue_s gui_queue; pthread_mutex_t stuff_mutex; int stuff_todo; pthread_cond_t stuff_cond; }; struct worker_queue_s wq; int main(int argc, char *argv[]) { // blah blah init_worker_queue(&wq); // blah blah } void gui_callback(...) { // blah blah // Set up GUI message pthread_mutex_lock(&wq.gui_mutex); // Add GUI message to queue pthread_mutex_unlock(&wq.gui_mutex); pthread_mutex_lock(&wq.stuff_mutex); wq.stuff_todo++; pthread_cond_signal(&wq.stuff_cond); pthread_mutex_unlock(&wq.stuff_mutex); // blah blah } void* work_generator_thread(void*) { // blah blah while (1) { // Set up work to do pthread_mutex_lock(&wq.work_mutex); // Add work item to queue pthread_mutex_unlock(&wq.work_mutex); pthread_mutex_lock(&wq.stuff_mutex); wq.stuff_todo++; pthread_cond_signal(&wq.stuff_cond); pthread_mutex_unlock(&wq.stuff_mutex); } // blah blah } void* worker_thread(void* arg) { // blah blah while (1) { // Wait for there to be something to do pthread_mutex_lock(&wq.stuff_mutex); while (wq.stuff_todo < 1) { pthread_cond_wait(&wq.stuff_cond, &wq.stuff_mutex); } pthread_mutex_unlock(&wq.stuff_mutex); // Handle GUI messages pthread_mutex_lock(&wq.gui_mutex); while (!gui_queue_empty(&wq.gui_queue) { // dequeue and process GUI messages pthread_mutex_lock(&wq.stuff_mutex); wq.stuff_todo--; pthread_mutex_unlock(&wq.stuff_mutex); } pthread_mutex_unlock(&wq.gui_mutex); // Handle work items pthread_mutex_lock(&wq.work_mutex); while (!work_queue_empty(&wq.work_queue)) { // dequeue and process work item pthread_mutex_lock(&wq.stuff_mutex); wq.stuff_todo--; pthread_mutex_unlock(&wq.stuff_mutex); } pthread_mutex_unlock(&wq.work_mutex); } // blah blah } This should accomplish what you desire. Caution that I haven't compiled, run, or tested it, but I'm pretty sure it's a solid solution. The key here is unifying the two input sources (the GUI and work queues) without blocking on either one of them individually. The value of (wq.stuff_todo < 1) becomes a proxy for the value of (gui_queue_empty(...) && work_queue_empty(...)). I hope that helps, Brent -- Brent Casavant Dance like everybody should be watching. www.angeltread.org KD5EMB, EN34lv From davids at webmaster.com Thu May 15 20:26:38 2008 From: davids at webmaster.com (David Schwartz) Date: Thu May 15 20:26:42 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482BF5EA.5010806@icyb.net.ua> Message-ID: > Brent, David, > > thank you for the responses. > I think I incorrectly formulated my original concern. > It is not about behavior at mutex unlock but about behavior at mutex > re-lock. You are right that waking waiters at unlock would hurt > performance. But I think that it is not "fair" that at re-lock former > owner gets the lock immediately and the thread that waited on it for > longer time doesn't get a chance. You are correct, but fairness is not the goal, performance is. If you want fairness, you are welcome to code it. But threads don't file union grievances, and it would be absolute foolishness for a scheduler to sacrifice performance to make threads happier. The scheduler decides which thread runs, you decide what the running thread does. You are expected to use your control over that latter part to exercise whatever your application notion of "fairness" is. Your test program is a classic example of a case where the use of a mutex is inappropriate. > Here's a more realistic example than the mock up code. > Say you have a worker thread that processes queued requests and the load > is such that there is always something on the queue. Thus the worker > thread doesn't ever have to block waiting on it. > And let's say that there is a GUI thread that wants to convey some > information to the worker thread. And for that it needs to acquire some > mutex and "do something". > With current libthr behavior the GUI thread would never have a chance to > get the mutex as worker thread would always be a winner (as my small > program shows). Nonsense. The worker thread would be doing work most of the time and wouldn't be holding the mutex. > Or even more realistic: there should be a feeder thread that puts things > on the queue, it would never be able to enqueue new items until the > queue becomes empty if worker thread's code looks like the following: > > while(1) > { > pthread_mutex_lock(&work_mutex); > while(queue.is_empty()) > pthread_cond_wait(...); > //dequeue item > ... > pthread_mutex_unlock(&work mutex); > //perform some short and non-blocking processing of the item > ... > } > > Because the worker thread (while the queue is not empty) would never > enter cond_wait and would always re-lock the mutex shortly after > unlocking it. So what? The feeder thread could get the mutex after the mutex is unlocked before the worker thread goes to do work. The only reason your test code encountered a "problem" was because you yielded the CPU while you held the mutex and never used up a timeslice. > So while improving performance on small scale this mutex re-acquire-ing > unfairness may be hurting interactivity and thread concurrency and thus > performance in general. E.g. in the above example queue would always be > effectively of depth 1. > Something about "lock starvation" comes to mind. Nope. You have to create a situation where the mutex is held much more often than not held to get this behavior. That's a pathological case where the use of a mutex is known to be inappropriate. > So, yes, this is not about standards, this is about reasonable > expectations about thread concurrency behavior in a particular > implementation (libthr). > I see now that performance advantage of libthr over libkse came with a > price. I think that something like queued locks is needed. They would > clearly reduce raw throughput performance, so maybe that should be a new > (non-portable?) mutex attribute. If you want queued locks, feel free to code them and use them. But you have to work very hard to create a case where they are useful. If you find you're holding the mutex more often than not, you're doing something *very* wrong. DS From avg at icyb.net.ua Thu May 15 20:48:34 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu May 15 20:48:38 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482C3333.1070205@freebsd.org> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> <482BFCE3.7080704@freebsd.org> <482C0206.1050206@icyb.net.ua> <482C3333.1070205@freebsd.org> Message-ID: <482CA191.1030004@icyb.net.ua> on 15/05/2008 15:57 David Xu said the following: > Andriy Gapon wrote: >> >> Maybe. But that's not what I see with my small example program. One >> thread releases and re-acquires a mutex 10 times in a row while the >> other doesn't get it a single time. >> I think that there is a very slim chance of a blocked thread >> preempting a running thread in this circumstances. Especially if >> execution time between unlock and re-lock is very small. > It does not depends on how many times your thread acquires or > re-acquires mutex, or > how small the region the mutex is protecting. as long as current thread > runs too long, > other threads will have higher priorities and the ownership definitely > will be transfered, > though there will be some extra context switchings. David, did you examine or try the small program that I sent before? The "lucky" thread slept for 1 second each time it held mutex. So in total it spent about 8 seconds sleeping and holding the mutex. And the "unlucky" thread, consequently, spent 8 seconds blocked waiting for that mutex. And it didn't get "lucky". Yes, technically the "lucky" thread was not running while holding the mutex, so probably this is why scheduling algorithm didn't immediately work. I did more testing and see that the "unlucky" thread eventually gets a chance (eventually means after very many lock/unlock cycles), but I think that it is penalized too much still. I wonder if with current code it is possible and easy to make this behavior more deterministic. Maybe something like the following: if (oldest_waiter.wait_time < X) do what we do now... else go into kernel for possible switch I have very little idea about unit and value of X. >> I'd rather prefer to have an option to have FIFO fairness in mutex >> lock rather than always avoiding context switch at all costs and >> depending on scheduler to eventually do priority magic. >> > It is better to implement this behavior in your application code, if it > is implemented in thread library, you still can not control how many > times acquiring and re-acquiring can be allowed for a thread without > context switching, a simple FIFO as you said here will cause dreadful > performance problem. I almost agree. But I still wouldn't take your last statement for a fact. "Dreadful performance" - on micro-scale maybe, not necessarily on macro scale. After all, never switching context would be the best performance for a single CPU-bound task, but you wouldn't think that this is the best performance for the whole system. As a data point: it seems that current Linux threading library is not significantly worse than libthr, but my small test program on Fedora 7 works to my expectations. -- Andriy Gapon From andrew at modulus.org Thu May 15 20:51:14 2008 From: andrew at modulus.org (Andrew Snow) Date: Thu May 15 20:51:19 2008 Subject: thread scheduling at mutex unlock In-Reply-To: References: Message-ID: <482CA235.6090400@modulus.org> > But I think that it is not "fair" that at re-lock former > owner gets the lock immediately and the thread that waited on it for > longer time doesn't get a chance. I believe this is what yield() is for. Before attempting a re-lock you should call yield() to allow other threads a chance to run. (Side note: On FreeBSD, I believe only high priority threads will run when you yield(). As a workaround, I think you have to lower the thread's priority before yield() and then raise it again afterwards.) - Andrew From avg at icyb.net.ua Thu May 15 20:56:21 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu May 15 20:56:28 2008 Subject: thread scheduling at mutex unlock In-Reply-To: References: Message-ID: <482CA372.3000400@icyb.net.ua> on 15/05/2008 22:29 David Schwartz said the following: >> what if you have an infinite number of items on one side and finite >> number on the other, and you want to process them all (in infinite >> time, of course). Would you still try to finish everything on one >> side (the infinite one) or would you try to look at what you have >> on the other side? >> >> I am sorry about fuzzy wording of my original report, I should have >> mentioned "starvation" somewhere in it. > > There is no such thing as a "fair share" when comparing an infinite > quantity to a finite quantity. It is just as sensible to do 1 then 1 > as 10 then 10 or a billion then 1. > > What I would do in this case is work on one side for one timeslice > then the other side for one timeslice, continuuing until either side > was finished, then I'd work exclusively on the other side. This is > precisely the purpose for having timeslices in a scheduler. > > The timeslice is carefully chosen so that it's not so long that you > ignore a side for too long. It's also carefully chosen so that it's > not so short that you spend all your time switching swides. > > What sane schedulers do is assume that you want to make as much > forward progress as quickly as possible. This means getting as many > work units done per unit time as possible. This means as few context > switches as possible. > > A scheduler that switches significantly more often than once per > timeslice with a load like this is *broken*. The purpose of the > timeslice is to place an upper bound on the number of context > switches in cases where forward progress can be made on more than one > process. An ideal scheduler would not switch more often than once per > timeslice unless it could not make further forward progress. > > Real-world schedulers actually may allow one side to pre-empt the > other, and may switch a bit more often than a scheduler that's > "ideal" in the sense described above. This is done in an attempt to > boost interactive performance. > > But your basic assumption that strict alternation is desirable is > massively wrong. That's the *worst* *possible* outcome. David, thank you for the tutorial, it is quite enlightening. But first of all, did you take a look at my small test program? There are 1 second sleeps in it, this is not about timeslices and scheduling at that level at all. This is about basic expectation about fairness of acquiring a lock at macro level. I know that when one thread acquires and releases and reacquires a mutex during 10 seconds while the other thread is blocked on that mutex for 10 seconds, then this is not about timeslices. -- Andriy Gapon From avg at icyb.net.ua Thu May 15 21:02:46 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu May 15 21:02:52 2008 Subject: thread scheduling at mutex unlock In-Reply-To: References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> Message-ID: <482CA4F3.6090501@icyb.net.ua> on 15/05/2008 22:51 Brent Casavant said the following: > On Thu, 15 May 2008, Andriy Gapon wrote: > >> With current libthr behavior the GUI thread would never have a chance to get >> the mutex as worker thread would always be a winner (as my small program >> shows). > > The example you gave indicates an incorrect mechanism being used for the > GUI to communicate with this worker thread. For the behavior you desire, > you need a common condition that lets both the GUI and the work item > generator indicate that there is something for the worker to do, *and* > you need seperate mechanisms for the GUI and work item generator to add > to their respective queues. Brent, that was just an example. Probably a quite bad example. I should only limit myself to the program that I sent and I should repeat that the result that it produces is not what I would call reasonably expected. And I will repeat that I understand that the behavior is not prohibited by standards (well, never letting other threads to run is probably not prohibited either). > Something like this (could be made even better with a little effor): > > struct worker_queues_s { > pthread_mutex_t work_mutex; > struct work_queue_s work_queue; > > pthread_mutex_t gui_mutex; > struct gui_queue_s gui_queue; > > pthread_mutex_t stuff_mutex; > int stuff_todo; > pthread_cond_t stuff_cond; > }; > struct worker_queue_s wq; > > int > main(int argc, char *argv[]) { > // blah blah > init_worker_queue(&wq); > // blah blah > } > > void > gui_callback(...) { > // blah blah > > // Set up GUI message > > pthread_mutex_lock(&wq.gui_mutex); > // Add GUI message to queue > pthread_mutex_unlock(&wq.gui_mutex); > > pthread_mutex_lock(&wq.stuff_mutex); > wq.stuff_todo++; > pthread_cond_signal(&wq.stuff_cond); > pthread_mutex_unlock(&wq.stuff_mutex); > > // blah blah > } > > void* > work_generator_thread(void*) { > // blah blah > > while (1) { > // Set up work to do > > pthread_mutex_lock(&wq.work_mutex); > // Add work item to queue > pthread_mutex_unlock(&wq.work_mutex); > > pthread_mutex_lock(&wq.stuff_mutex); > wq.stuff_todo++; > pthread_cond_signal(&wq.stuff_cond); > pthread_mutex_unlock(&wq.stuff_mutex); > } > > // blah blah > } > > void* > worker_thread(void* arg) { > // blah blah > > while (1) { > // Wait for there to be something to do > pthread_mutex_lock(&wq.stuff_mutex); > while (wq.stuff_todo < 1) { > pthread_cond_wait(&wq.stuff_cond, > &wq.stuff_mutex); > } > pthread_mutex_unlock(&wq.stuff_mutex); > > // Handle GUI messages > pthread_mutex_lock(&wq.gui_mutex); > while (!gui_queue_empty(&wq.gui_queue) { > // dequeue and process GUI messages > pthread_mutex_lock(&wq.stuff_mutex); > wq.stuff_todo--; > pthread_mutex_unlock(&wq.stuff_mutex); > } > pthread_mutex_unlock(&wq.gui_mutex); > > // Handle work items > pthread_mutex_lock(&wq.work_mutex); > while (!work_queue_empty(&wq.work_queue)) { > // dequeue and process work item > pthread_mutex_lock(&wq.stuff_mutex); > wq.stuff_todo--; > pthread_mutex_unlock(&wq.stuff_mutex); > } > pthread_mutex_unlock(&wq.work_mutex); > } > > // blah blah > } > > This should accomplish what you desire. Caution that I haven't > compiled, run, or tested it, but I'm pretty sure it's a solid > solution. > > The key here is unifying the two input sources (the GUI and work queues) > without blocking on either one of them individually. The value of > (wq.stuff_todo < 1) becomes a proxy for the value of > (gui_queue_empty(...) && work_queue_empty(...)). > > I hope that helps, > Brent > -- Andriy Gapon From b.j.casavant at ieee.org Thu May 15 22:23:55 2008 From: b.j.casavant at ieee.org (Brent Casavant) Date: Thu May 15 22:24:02 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482CA4F3.6090501@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> <482CA4F3.6090501@icyb.net.ua> Message-ID: On Fri, 16 May 2008, Andriy Gapon wrote: > that was just an example. Probably a quite bad example. > I should only limit myself to the program that I sent and I should repeat that > the result that it produces is not what I would call reasonably expected. And > I will repeat that I understand that the behavior is not prohibited by > standards (well, never letting other threads to run is probably not prohibited > either). Well, I don't know what to tell you at this point. I believe I understand the nature of the problem you're encountering, and I believe there are perfectly workable mechanisms in Pthreads to allow you to accomplish what you desire without depending on implementation-specific details. Yes, it's more work on your part, but if done well it's one-time work. The behavior you desire is useful only in limited situations, and can be implemented at the application level through the use of Pthreads primitives. If Pthreads behaved as you apparently expect, it would be impossible to implement the current behavior at the application level. Queueing mutexes are innappropriate in the majority of code designs. I'll take your word that it is appropriate in your particular case, but that does not make it appropriate for more typical designs. Several solutions have been presented, including one from me. If you choose not to implement such solutions, then best of luck to you. OK, I'm a sucker for punishment. So use this instead of Pthreads mutexes. This should work on both FreeBSD and Linux (FreeBSD has some convenience routines in the sys/queue.h package that Linux doesn't): #include #include struct thread_queue_entry_s { TAILQ_ENTRY(thread_queue_entry_s) tqe_list; pthread_cond_t tqe_cond; pthread_mutex_t tqe_mutex; int tqe_wakeup; }; TAILQ_HEAD(thread_queue_s, thread_queue_entry_s); typedef struct { struct thread_queue_s qm_queue; pthread_mutex_t qm_queue_lock; unsigned int qm_users; } queued_mutex_t; int queued_mutex_init(queued_mutex_t *qm) { TAILQ_INIT(&qm->qm_queue); qm->qm_users = 0; return pthread_mutex_init(&qm->qm_queue_lock, NULL); } int queued_mutex_lock(queued_mutex_t *qm) { struct thread_queue_entry_s waiter; pthread_mutex_lock(&qm->qm_queue_lock); qm->qm_users++; if (1 == qm->qm_users) { /* Nobody was waiting for mutex, we own it. * Fast path out. */ pthread_mutex_unlock(&qm->qm_queue_lock); return 0; } /* There are others waiting for the mutex. Slow path. */ /* Initialize this thread's wait structure */ pthread_cond_init(&waiter->tqe_cond, NULL); pthread_mutex_init(&waiter->tqe_mutex, NULL); pthread_mutex_lock(&waiter->tqe_mutex); waiter->tqe_wakeup = 0; /* Add this thread's wait structure to queue */ TAILQ_INSERT_TAIL(&qm->qm_queue, &waiter, tqe_list); pthread_mutex_unlock(&qm->qm_queue_lock); /* Wait for somebody to hand the mutex to us */ while (!waiter->tqe_wakeup) { pthread_cond_wait(&waiter->tqe_cond, &waiter->tqe_mutex); } /* Destroy this thread's wait structure */ pthread_mutex_unlock(&waiter->tqe_mutex); pthread_mutex_destroy(&waiter->tqe_mutex); pthread_cond_destroy(&waiter->tqe_cond); /* We own the queued mutex (handed to us by unlock) */ return 0; } int queued_mutex_unlock(queued_mutex_t *qm) { struct thread_queue_entry_s *waiter; pthread_mutex_lock(&qm->qm_queue_lock); qm->qm_users--; if (0 == qm->qm_users) { /* No waiters to wake up. Fast path out. */ pthread_mutex_unlock(&qm->qm_queue_lock); return 0; } /* Wake up first waiter. Slow path. */ /* Remove the first waiting thread. */ waiter = qm->qm_queue.tqh_first; TAILQ_REMOVE(&qm->qm_queue, waiter, tqe_list); pthread_mutex_unlock(&qm->qm_queue_lock); /* Wake up the thread. */ pthread_mutex_lock(&waiter->tqe_mutex); waiter->tqe_wakeup = 1; pthread_cond_signal(&waiter->tqe_cond); pthread_mutex_unlock(&waiter->tqe_mutex); return 0; } int queued_mutex_destroy(queued_mutex_t *qm) { pthread_mutex_lock(&qm->qm_queue_lock); if (qm->qm_users > 1) { pthread_mutex_unlock(&qm->qm_queue_lock); return EBUSY; } return pthread_mutex_destroy(&qm->qm_queue_lock); } These queued_mutex_t mutexes should have the behavior you're looking for, and will be portable to any platform with Pthreads and sys/queue.h. Be warned that I haven't compiled, run, or debugged this, but the code should be pretty solid (typos aside). Of course, in production code I'd check a bunch of return values, but those would just get in the way of this illustration. So use something this or change the application's threading model (like my previous post showed). There's no use complaining about the Pthreads implementation in this regard because your application's use of mutexes is the exception, not the rule. The fact that Linux behaves as you expect is irrelevant, as POSIX doesn't speak to this facet of implementation, so both Linux and BSD are correct. Relying on this behavior in Linux is ill-advised as it is non-portable, and likely to break in future releases. Brent -- Brent Casavant Dance like everybody should be watching. www.angeltread.org KD5EMB, EN34lv From davids at webmaster.com Thu May 15 22:37:43 2008 From: davids at webmaster.com (David Schwartz) Date: Thu May 15 22:37:47 2008 Subject: thread scheduling at mutex unlock In-Reply-To: <482CA372.3000400@icyb.net.ua> Message-ID: > David, > thank you for the tutorial, it is quite enlightening. > But first of all, did you take a look at my small test program? Yes. It demonstrates the classic example of mutex abuse. A mutex is not an appropriate synchronization mechanism when it's going to be held most of the time and released briefly. > There are 1 second sleeps in it, this is not about timeslices and > scheduling at that level at all. This is about basic expectation about > fairness of acquiring a lock at macro level. I know that when one thread > acquires and releases and reacquires a mutex during 10 seconds while the > other thread is blocked on that mutex for 10 seconds, then this is not > about timeslices. I guess it comes down to what your test program is supposed to test. Threading primitives can always be made to look bad in toy test programs that don't even remotely reflect real-world use cases. No sane person optimizes for such toys. The reason your program behaves the way it does is because the thread that holds the mutex relinquishes the CPU while it holds it. As such, it appears to be very nice and is its dynamic priority level rises. In a real-world case, the threads waiting for the mutex will have their priorities rise while the thread holding the mutex will use up its timeslice working. This is simply not appropriate use of a mutex. It would be absolute foolishness to encumber the platform's default mutex implementation with any attempt to make such abuses do more what you happen to expect them to do. In fact, the behavior I expect is the behavior seen. So the defect is in your unreasonable expectations. The scheduler's goal is to allow the running thread to make forward progress, and it does this perfectly. DS From joe at tao.org.uk Thu May 15 23:25:29 2008 From: joe at tao.org.uk (Dr Josef Karthauser) Date: Thu May 15 23:25:33 2008 Subject: cvsup.uk.FreeBSD.org In-Reply-To: References: <20080511102730.DBD0A600F@mailhost.tao.org.uk> Message-ID: <07f101c8b6e2$f4b13f20$de13bd60$@org.uk> > -----Original Message----- > From: owner-freebsd-hubs@freebsd.org [mailto:owner-freebsd- > hubs@freebsd.org] On Behalf Of Tony Finch > Sent: 12 May 2008 17:06 > To: Dr Joe Karthauser > Cc: freebsd-hubs@freebsd.org; freebsd-stable@freebsd.org > Subject: Re: cvsup.uk.FreeBSD.org > > On Sun, 11 May 2008, Dr Joe Karthauser wrote: > > > > I have reclassified this faulty mirror as cvsup1 and made cvsup a > cname to > > cvsup3, which is the most recent addition and best hardware > available. In > > the future we will always point to the most available machine in this > way. > > Looks like I'm getting a bit more traffic than before - peaking at over > 100 logins an hour. As a matter of interest, do you know what the peak bandwidth usage is? Joe From jan6146 at gmail.com Fri May 16 00:12:37 2008 From: jan6146 at gmail.com (Rob Lytle) Date: Fri May 16 00:12:43 2008 Subject: today's build is causing errors for me Message-ID: <784966050805151644m43b9a5e1qe8a4568576fc081f@mail.gmail.com> First I am running 7.0-Stable and just cvsup'd today. Then I built the system, new kernel, and installed them. Second I am using the GENERIC KERNEL. Sysctl.conf is empty. I will put my /etc/rc.conf at the end. I tried to do a very careful job of merging /usr/src/etc with /etc. I didn't touch any files that I or the computer configured. But I am getting these errors upon bootup: 1. eval: /etc/rc.d/cleanvar: Permission Denied 2. syslogd: bind: Can't assign requested address. (repeated twice) 3. syslogd: child pid 134 exited with return code 1 4. /etc/rc: Warning: Dump device does not exist. Savecore will not run. (this always worked before) 5. /etc/rc.d/securelevel: /etc/rc.d/sysctl: Permission denied. 6. My computer says "Amnesiac" yet the host name is clearly in rc.conf 7. My WiFi no longer starts up by myself. I have to do it all manually using ifconfig and dhclient. Any help would be appreciated. I'm kind of lost as some of it makes no sense to me, esp #6 and 7. Has the default rc.conf format changed??? Thanks, Sincerely, Rob ------------------------------------------ My rc.conf file # -- sysinstall generated deltas -- # Sun Oct 28 11:36:26 2007 # Created: Sun Oct 28 11:36:26 2007 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. hostname="xenon" # "" for DHCP linux_enable="YES" #moused_enable="YES" sshd_enable="YES" usbd_enable="YES" lpd_enable="YES" kern_securelevel_enable="NO" dumpdev="AUTO" dumpdir="/var/crash" cron_enable="YES" performance_cx_lowest="LOW" performance_cpu_freq="HIGH" economy_cx_lowest="LOW" economy_cpu_freq="LOW" ipfilter_enable="YES" ipfilter_rules="/etc/ipfw.rules" ipmon_enable="YES" ipmon_flags="-Ds" watchdogd_enable="YES" powerd_enable="YES" mixer_enable="YES" #ifconfig_ath0="WPA DHCP channel 3" #ifconfig_msk0="DHCP" ifconfig_ath0="DHCP ssid leighmorlock channel 6" # added by mergebase.sh local_startup="/usr/local/etc/rc.d" From smithi at nimnet.asn.au Fri May 16 04:20:40 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri May 16 04:20:43 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <20080515162056.GA17187@eos.sc1.parodius.com> Message-ID: On Thu, 15 May 2008, Jeremy Chadwick wrote: > On Thu, May 15, 2008 at 11:03:53AM +0100, Bruce M. Simpson wrote: > > Andrey V. Elsukov wrote: > >> Vivek Khera wrote: > >>> I had a box run out of dynamic state space yesterday. I found I can > >>> increase the number of dynamic rules by increasing the sysctl parameter > >>> net.inet.ip.fw.dyn_max. I can't find, however, how this affects memory > >>> usage on the system. Is it dyanamically allocated and de-allocated, or > >>> is it a static memory buffer? > >> > >> Each dynamic rule allocated dynamically. Be careful, too many dynamic > >> rules will work very slow. > > > > Got any figures for this? I took a quick glance and it looks like it just > > uses a hash over dst/src/dport/sport. If there are a lot of raw IP or ICMP > > flows then that's going to result in hash collisions. > > > > It might be a good project for someone to optimize if it isn't scaling for > > folk. "Bloomier" filters are probably worth a look -- bloom filters are a > > class of probabilistic hash which may return a false positive, "bloomier" > > filters are a refinement which tries to limit the false positives. > > > > Having said that the default tunable of 256 state entries is probably quite > > low for use cases other than "home/small office NAT gateway". > > It's far too low for home/small office. Standard Linux NAT routers, > such as the Linksys WRT54G/GL, come with a default state table count of > 2048, and often is increased by third-party firmwares to 8192 based on > justified necessity. Search for "conntrack" below: > > http://www.polarcloud.com/firmware > > 256 can easily be exhausted by more than one user loading multiple HTTP > 1.0 web pages at one time (such is the case with many users now have > browsers that load 7-8 web pages into separate tabs during startup). > > And if that's not enough reason, consider torrents, which is quite often > what results in a home or office router exhausting its state table. > > Bottom line: the 256 default is too low. It needs to be increased to at > least 2048. I think there may be some confusion in terms. Looking at defaults on my older 5.5 system - sure, call it a "home/small office NAT gateway": net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_count: 212 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.static_count: 153 What defaults to 256 is the number of hash table buckets, not the max number of dynamic rules, here 4096 (though the 5.5 manual says 8192). On hash collisions, a linked list is used for duplicate hashes of: i = (id->dst_ip) ^ (id->src_ip) ^ (id->dst_port) ^ (id->src_port); i &= (curr_dyn_buckets - 1); So while 256 may well be too few buckets for many systems, and like Bruce I wonder about the effectiveness of the xor hash for raw IP & ICMP and wouldn't mind seeing some stats on bucket use vs linked list lengths for various workloads, it doesn't determine the max no. of dynamic rules available, which is adjustable up without any apparent static memory allocation, and is moderated by the various expiry timeout sysctls. For reference, I admin a 4.8 filtering bridge with up to 20 boxes behind it, that has only very rarely reported exceeding the max no. of dynamic rules with the (4.8) default net.inet.ip.fw.dyn_max of 1000 .. however it only keeps state for UDP connections (and yes, it only ever hits that limit on torrents or skype, which are generally admin. prohib. :) cheers, Ian (not subscribed to -ipfw) From bu7cher at yandex.ru Fri May 16 04:33:18 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Fri May 16 04:33:27 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <482C0A89.104@FreeBSD.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> <482C0A89.104@FreeBSD.org> Message-ID: <482D0E87.6000003@yandex.ru> Bruce M. Simpson wrote: > Got any figures for this? I took a quick glance and it looks like it > just uses a hash over dst/src/dport/sport. If there are a lot of raw IP > or ICMP flows then that's going to result in hash collisions. It's my guess, i haven't any figures.. Yes, hash collisions will trigger many searching in buckets lists. And increasing only dyn_max without increasing dyn_buckets will grow collisions. > It might be a good project for someone to optimize if it isn't scaling > for folk. "Bloomier" filters are probably worth a look -- bloom filters > are a class of probabilistic hash which may return a false positive, > "bloomier" filters are a refinement which tries to limit the false > positives. There were some ideas from Vadim Goncharov about rewriting dynamic rules implementation.. -- WBR, Andrey V. Elsukov From koitsu at FreeBSD.org Fri May 16 04:34:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri May 16 04:34:17 2008 Subject: today's build is causing errors for me In-Reply-To: <784966050805151644m43b9a5e1qe8a4568576fc081f@mail.gmail.com> References: <784966050805151644m43b9a5e1qe8a4568576fc081f@mail.gmail.com> Message-ID: <20080516043411.GA44491@eos.sc1.parodius.com> On Thu, May 15, 2008 at 04:44:57PM -0700, Rob Lytle wrote: > First I am running 7.0-Stable and just cvsup'd today. Then I built the > system, new kernel, and installed them. Second I am using the GENERIC > KERNEL. Sysctl.conf is empty. I will put my /etc/rc.conf at the end. I > tried to do a very careful job of merging /usr/src/etc with /etc. I didn't > touch any files that I or the computer configured. > > But I am getting these errors upon bootup: > > 1. eval: /etc/rc.d/cleanvar: Permission Denied > 2. syslogd: bind: Can't assign requested address. (repeated twice) > 3. syslogd: child pid 134 exited with return code 1 > 4. /etc/rc: Warning: Dump device does not exist. Savecore will not > run. (this always worked before) > 5. /etc/rc.d/securelevel: /etc/rc.d/sysctl: Permission denied. > 6. My computer says "Amnesiac" yet the host name is clearly in rc.conf > 7. My WiFi no longer starts up by myself. I have to do it all manually > using ifconfig and dhclient. You should have followed the instructions in /usr/src/Makefile. You don't "merge things by hand". You can use mergemaster for that. Please use it, as I'm willing to bet there's a portion of your rc framework which is broken in some way. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jan6146 at gmail.com Fri May 16 06:04:35 2008 From: jan6146 at gmail.com (Rob Lytle) Date: Fri May 16 06:04:39 2008 Subject: today's build is causing errors for me In-Reply-To: <20080516043411.GA44491@eos.sc1.parodius.com> References: <784966050805151644m43b9a5e1qe8a4568576fc081f@mail.gmail.com> <20080516043411.GA44491@eos.sc1.parodius.com> Message-ID: <784966050805152304t1827c53bi6988ae9c8f837f32@mail.gmail.com> Hi Jeremy, I used Mergemaster. Thats what I mean't when I said that I carefully "merged" /usr/src/etc/ with /etc. But like I said, no files were replaced that contained my own configuration, e.g. group. I will say this- that I have always considered Mergemaster a confusing mess, despite the dogma on the lists. I have been running FreeBSD and installing it since 1998, so I have some experience- but this is new behavior beyond my previous experiences. Sincerely, Rob. On 5/15/08, Jeremy Chadwick wrote: > On Thu, May 15, 2008 at 04:44:57PM -0700, Rob Lytle wrote: >> First I am running 7.0-Stable and just cvsup'd today. Then I built the >> system, new kernel, and installed them. Second I am using the GENERIC >> KERNEL. Sysctl.conf is empty. I will put my /etc/rc.conf at the end. I >> tried to do a very careful job of merging /usr/src/etc with /etc. I >> didn't >> touch any files that I or the computer configured. >> >> But I am getting these errors upon bootup: >> >> 1. eval: /etc/rc.d/cleanvar: Permission Denied >> 2. syslogd: bind: Can't assign requested address. (repeated twice) >> 3. syslogd: child pid 134 exited with return code 1 >> 4. /etc/rc: Warning: Dump device does not exist. Savecore will not >> run. (this always worked before) >> 5. /etc/rc.d/securelevel: /etc/rc.d/sysctl: Permission denied. >> 6. My computer says "Amnesiac" yet the host name is clearly in rc.conf >> 7. My WiFi no longer starts up by myself. I have to do it all manually >> using ifconfig and dhclient. > > You should have followed the instructions in /usr/src/Makefile. You > don't "merge things by hand". You can use mergemaster for that. Please > use it, as I'm willing to bet there's a portion of your rc framework > which is broken in some way. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From koitsu at FreeBSD.org Fri May 16 06:17:25 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri May 16 06:17:29 2008 Subject: today's build is causing errors for me In-Reply-To: <784966050805152304t1827c53bi6988ae9c8f837f32@mail.gmail.com> References: <784966050805151644m43b9a5e1qe8a4568576fc081f@mail.gmail.com> <20080516043411.GA44491@eos.sc1.parodius.com> <784966050805152304t1827c53bi6988ae9c8f837f32@mail.gmail.com> Message-ID: <20080516061724.GA47953@eos.sc1.parodius.com> On Thu, May 15, 2008 at 11:04:34PM -0700, Rob Lytle wrote: > Hi Jeremy, > > I used Mergemaster. Thats what I mean't when I said that I carefully > "merged" /usr/src/etc/ with /etc. But like I said, no files were > replaced that contained my own configuration, e.g. group. I will say > this- that I have always considered Mergemaster a confusing mess, > despite the dogma on the lists. I have been running FreeBSD and > installing it since 1998, so I have some experience- but this is new > behavior beyond my previous experiences. "Permission denied" could imply that the rc scripts aren't set to executable. Possibly a umask problem? Additionally, mergemaster isn't a confusing mess. If anything, it's one of the most simple tools there is for managing /etc. The part you probably find "confusing", which is the same part I did when I started using it, is the side-by-side interactive diff. It's very easy to use; "r" means use the text shown on the right, and "l" means use the text shown on the left. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jan6146 at gmail.com Fri May 16 06:22:31 2008 From: jan6146 at gmail.com (Rob Lytle) Date: Fri May 16 06:22:35 2008 Subject: today's build is causing errors for me / Fixed for now Message-ID: <784966050805152322n5e03b67bhc29d912860c0c3c3@mail.gmail.com> Hi Jeremy, I always back up /etc before I upgrade the system. The old /etc works just fine. I will eventually go back in and check out the new /etc to see what is wrong. Sincerely, Rob. On Thu, May 15, 2008 at 11:17 PM, Jeremy Chadwick wrote: > On Thu, May 15, 2008 at 11:04:34PM -0700, Rob Lytle wrote: > > Hi Jeremy, > > > > I used Mergemaster. Thats what I mean't when I said that I carefully > > "merged" /usr/src/etc/ with /etc. But like I said, no files were > > replaced that contained my own configuration, e.g. group. I will say > > this- that I have always considered Mergemaster a confusing mess, > > despite the dogma on the lists. I have been running FreeBSD and > > installing it since 1998, so I have some experience- but this is new > > behavior beyond my previous experiences. > > "Permission denied" could imply that the rc scripts aren't set to > executable. Possibly a umask problem? > > Additionally, mergemaster isn't a confusing mess. If anything, it's one > of the most simple tools there is for managing /etc. The part you > probably find "confusing", which is the same part I did when I started > using it, is the side-by-side interactive diff. It's very easy to use; > "r" means use the text shown on the right, and "l" means use the text > shown on the left. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From jan6146 at gmail.com Fri May 16 07:02:47 2008 From: jan6146 at gmail.com (Rob Lytle) Date: Fri May 16 07:02:52 2008 Subject: today's build is causing errors for me In-Reply-To: <20080516061724.GA47953@eos.sc1.parodius.com> References: <784966050805151644m43b9a5e1qe8a4568576fc081f@mail.gmail.com> <20080516043411.GA44491@eos.sc1.parodius.com> <784966050805152304t1827c53bi6988ae9c8f837f32@mail.gmail.com> <20080516061724.GA47953@eos.sc1.parodius.com> Message-ID: <784966050805160002g63defc51j11465f0d51025a0d@mail.gmail.com> Hi Jeremy, You were correct. Somehow some files in /etc/rc.d had permissions of 644. Setting the new permissions to that of the old fixed the problem. Thanks. Rob. On Thu, May 15, 2008 at 11:17 PM, Jeremy Chadwick wrote: > On Thu, May 15, 2008 at 11:04:34PM -0700, Rob Lytle wrote: > > Hi Jeremy, > > > > I used Mergemaster. Thats what I mean't when I said that I carefully > > "merged" /usr/src/etc/ with /etc. But like I said, no files were > > replaced that contained my own configuration, e.g. group. I will say > > this- that I have always considered Mergemaster a confusing mess, > > despite the dogma on the lists. I have been running FreeBSD and > > installing it since 1998, so I have some experience- but this is new > > behavior beyond my previous experiences. > > "Permission denied" could imply that the rc scripts aren't set to > executable. Possibly a umask problem? > > Additionally, mergemaster isn't a confusing mess. If anything, it's one > of the most simple tools there is for managing /etc. The part you > probably find "confusing", which is the same part I did when I started > using it, is the side-by-side interactive diff. It's very easy to use; > "r" means use the text shown on the right, and "l" means use the text > shown on the left. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From jan6146 at gmail.com Fri May 16 07:13:25 2008 From: jan6146 at gmail.com (Rob Lytle) Date: Fri May 16 07:13:28 2008 Subject: just one last question about /etc/rc.d file permissions Message-ID: <784966050805160013w7d3ec31euc95be9e4a0a68fa9@mail.gmail.com> Hi Jeremy, I noticed that most all of the files in my old /etc/rc.d had 555 permissions. There were 4 or 5 that had 644 permissions in my old /etc/rc.d. What I am wondering is if all the files in rc.d should be 555? So far I am not experiencing any problems with anything with a very few 644 files. Thanks, Rob. On 5/16/08, Rob Lytle wrote: > Hi Jeremy, > > You were correct. Somehow some files in /etc/rc.d had permissions of 644. > Setting the new permissions to that of the old fixed the problem. Thanks. > > Rob. > From emikulic at gmail.com Fri May 16 07:39:35 2008 From: emikulic at gmail.com (Emil Mikulic) Date: Fri May 16 07:39:42 2008 Subject: ciss(4) not coping with large arrays? Message-ID: <20080516073932.GA39803@dmr.ath.cx> Hi all, Running today's RELENG_7 (although 7.0-RELEASE has the same problem), GENERIC kernel on an amd64 and I can't seem to get a da(4) device for any arrays bigger than 2TB. dmesg: <...> ciss0: port 0x4000-0x40ff mem 0xfdf00000-0xfdffffff,0xfdef 0000-0xfdef0fff irq 16 at device 0.0 on pci10 ciss0: [ITHREAD] <...> da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: 953837MB (1953459632 512 byte sectors: 255H 32S/T 65535C) da1 at ciss0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 135.168MB/s transfers da1: 953837MB (1953459632 512 byte sectors: 255H 32S/T 65535C) da2 at ciss0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 135.168MB/s transfers da2: 1907675MB (3906918832 512 byte sectors: 255H 32S/T 65535C) (da3:ciss0:0:3:0): got CAM status 0x4 (da3:ciss0:0:3:0): fatal error, failed to attach to device (da3:ciss0:0:3:0): lost device (da3:ciss0:0:3:0): removing device entry (da4:ciss0:0:4:0): got CAM status 0x4 (da4:ciss0:0:4:0): fatal error, failed to attach to device (da4:ciss0:0:4:0): lost device (da4:ciss0:0:4:0): removing device entry <...> The arrays I'm testing with: da1 = 1 x 1TB da2 = 2 x 1TB da3 = 3 x 1TB da4 = 4 x 1TB Also: # camcontrol devlist at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus0 target 2 lun 0 (pass2,da2) at scbus0 target 3 lun 0 (pass3) at scbus0 target 4 lun 0 (pass4) # camcontrol readcap pass2 Last Block: 3906918831, Block Length: 512 bytes # camcontrol readcap pass3 (pass3:ciss0:0:3:0): SERVICE ACTION IN(16). CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0 (pass3:ciss0:0:3:0): CAM Status: CCB request completed with an error Is it possible to get FreeBSD to recognize arrays > 2TB? Are there any further diagnostics I can provide? --Emil From kometen at gmail.com Fri May 16 07:50:13 2008 From: kometen at gmail.com (Claus Guttesen) Date: Fri May 16 07:50:18 2008 Subject: ciss(4) not coping with large arrays? In-Reply-To: <20080516073932.GA39803@dmr.ath.cx> References: <20080516073932.GA39803@dmr.ath.cx> Message-ID: > Running today's RELENG_7 (although 7.0-RELEASE has the same problem), > GENERIC kernel on an amd64 and I can't seem to get a da(4) device for > any arrays bigger than 2TB. In earlier releases (5 and 6 at least) you couldn't create partitions larger than 2 TB. I don't know whether work has been to circumvent this in 7 but tools like fsck has to be changed as well. Have you tried zfs? > dmesg: > <...> > ciss0: port 0x4000-0x40ff mem 0xfdf00000-0xfdffffff,0xfdef > 0000-0xfdef0fff irq 16 at device 0.0 on pci10 > ciss0: [ITHREAD] > <...> > da0 at ciss0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 135.168MB/s transfers > da0: 953837MB (1953459632 512 byte sectors: 255H 32S/T 65535C) > da1 at ciss0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 135.168MB/s transfers > da1: 953837MB (1953459632 512 byte sectors: 255H 32S/T 65535C) > da2 at ciss0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-5 device > da2: 135.168MB/s transfers > da2: 1907675MB (3906918832 512 byte sectors: 255H 32S/T 65535C) > (da3:ciss0:0:3:0): got CAM status 0x4 > (da3:ciss0:0:3:0): fatal error, failed to attach to device > (da3:ciss0:0:3:0): lost device > (da3:ciss0:0:3:0): removing device entry > (da4:ciss0:0:4:0): got CAM status 0x4 > (da4:ciss0:0:4:0): fatal error, failed to attach to device > (da4:ciss0:0:4:0): lost device > (da4:ciss0:0:4:0): removing device entry > <...> > > The arrays I'm testing with: > da1 = 1 x 1TB > da2 = 2 x 1TB > da3 = 3 x 1TB > da4 = 4 x 1TB > > Also: > # camcontrol devlist > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 1 lun 0 (pass1,da1) > at scbus0 target 2 lun 0 (pass2,da2) > at scbus0 target 3 lun 0 (pass3) > at scbus0 target 4 lun 0 (pass4) > # camcontrol readcap pass2 > Last Block: 3906918831, Block Length: 512 bytes > # camcontrol readcap pass3 > (pass3:ciss0:0:3:0): SERVICE ACTION IN(16). CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0 > (pass3:ciss0:0:3:0): CAM Status: CCB request completed with an error > > Is it possible to get FreeBSD to recognize arrays > 2TB? > Are there any further diagnostics I can provide? > > --Emil > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From ps at mu.org Fri May 16 08:19:34 2008 From: ps at mu.org (Paul Saab) Date: Fri May 16 08:19:38 2008 Subject: ciss(4) not coping with large arrays? In-Reply-To: <5c0ff6a70805160103o75461976wce04f697975a176c@mail.gmail.com> References: <20080516073932.GA39803@dmr.ath.cx> <5c0ff6a70805160103o75461976wce04f697975a176c@mail.gmail.com> Message-ID: <5c0ff6a70805160119n2f8361c4y7b3c1451f36d3c6e@mail.gmail.com> On Fri, May 16, 2008 at 1:03 AM, Paul Saab wrote: > On Fri, May 16, 2008 at 12:50 AM, Claus Guttesen > wrote: > >> > Running today's RELENG_7 (although 7.0-RELEASE has the same problem), >> > GENERIC kernel on an amd64 and I can't seem to get a da(4) device for >> > any arrays bigger than 2TB. >> >> In earlier releases (5 and 6 at least) you couldn't create partitions >> larger than 2 TB. I don't know whether work has been to circumvent >> this in 7 but tools like fsck has to be changed as well. Have you >> tried zfs? > > > zfs has nothing to do with this. The driver is not properly dealing with > the large volume. > > set the kernel tunable in loader.conf > > kern.cam.da.3.minimum_cmd_size=16 > kern.cam.da.4.minimum_cmd_size=16 > > Actually, this has nothing to do with it either.. Please try the following patch: http://yogurt.org/FreeBSD/ciss_large.diff From ps at mu.org Fri May 16 08:27:23 2008 From: ps at mu.org (Paul Saab) Date: Fri May 16 08:27:26 2008 Subject: ciss(4) not coping with large arrays? In-Reply-To: References: <20080516073932.GA39803@dmr.ath.cx> Message-ID: <5c0ff6a70805160103o75461976wce04f697975a176c@mail.gmail.com> On Fri, May 16, 2008 at 12:50 AM, Claus Guttesen wrote: > > Running today's RELENG_7 (although 7.0-RELEASE has the same problem), > > GENERIC kernel on an amd64 and I can't seem to get a da(4) device for > > any arrays bigger than 2TB. > > In earlier releases (5 and 6 at least) you couldn't create partitions > larger than 2 TB. I don't know whether work has been to circumvent > this in 7 but tools like fsck has to be changed as well. Have you > tried zfs? zfs has nothing to do with this. The driver is not properly dealing with the large volume. set the kernel tunable in loader.conf kern.cam.da.3.minimum_cmd_size=16 kern.cam.da.4.minimum_cmd_size=16 From freebsdlists at bsdunix.ch Fri May 16 08:34:00 2008 From: freebsdlists at bsdunix.ch (Thomas Vogt) Date: Fri May 16 08:34:05 2008 Subject: Timedia 8 port serial pci card problem Message-ID: <65DED12A-0263-4281-ADAC-CBF2A7857D5E@bsdunix.ch> Hello I run FreeBSD 7-Stable on my soekris net 5501 with a "8 Port Timedia Serial PCI Card". It's also know as SUNIX 4066 card. My Kernel Config is like Generic exept this two added options: options CPU_SOEKRIS device puc FreeBSD detects it with: "puc0: port 0xe500-0xe51f,0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f, 0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0" . But it only adds 3 uart ports instead of 8. Any idea what i can do? Maybe useful informations: FreeBSD a2.test.lan 7.0-STABLE FreeBSD 7.0-STABLE #4: Thu May 15 16:27:54 CEST 2008 pciconf: puc0@pci0:0:14:0: class=0x070002 card=0x50661409 chip=0x71681409 rev=0x01 hdr=0x00 vendor = 'Timedia Technology Co Ltd' device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' class = simple comms subclass = UART puc/uart: puc0: port 0xe500-0xe51f, 0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f,0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xe500 puc0: Lazy allocation of 0x4 bytes rid 0x11 type 4 at 0x1000 puc0: Lazy allocation of 0x4 bytes rid 0x12 type 4 at 0x1004 puc0: Lazy allocation of 0x4 bytes rid 0x13 type 4 at 0x1008 puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe520 puc0: Lazy allocation of 0x4 bytes rid 0x15 type 4 at 0x100c puc0: [FILTER] uart0: on puc0 uart0: [FILTER] uart0: fast interrupt uart1: <16550 or compatible> on puc0 uart1: [FILTER] uart1: fast interrupt uart2: on puc0 uart2: [FILTER] uart2: fast interrupt Complete dmesg: Copyright (c) 1992-2008 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 7.0-STABLE #4: Thu May 15 16:27:54 CEST 2008 root@bert.mlan.solnet.ch:/usr/obj/usr/src/sys/ULL Preloaded elf kernel "/boot/kernel/kernel" at 0xc0905000. Calibrating clock(s) ... i8254 clock: 1193155 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 499904707 Hz CPU: Geode(TM) Integrated Processor by AMD PCS (499.90-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 Data TLB: 16 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 32 bytes/line, 1 lines/tag, 16-way associative L1 instruction cache: 64 kbytes, 32 bytes/line, 1 lines/tag, 16-way associative L2 internal cache: 128 kbytes, 32 bytes/line, 1 lines/tag, 4-way associative Write Allocate Disable real memory = 536870912 (512 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001f6bbfff, 514420736 bytes (125591 pages) avail memory = 515969024 (492 MB) bios32: Found BIOS32 Service Directory header at 0xc00fac00 bios32: Entry = 0xfac40 (c00fac40) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xac61 Other BIOS signatures found: ULE: setup cpu 0 kbd: new array size 4 kbd1 at kbdmux0 nfslock: pseudo-device random: mem: K6-family MTRR support enabled (2 registers) io: null: npx0: INT 16 interface cpu0 on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 1 [class=060000] [hdr=80] is there (id=20801022) pcibios: BIOS version 2.01 pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1022, dev=0x2080, revid=0x31 domain=0, bus=0, slot=1, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0220, cachelnsz=8 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x2082, revid=0x00 domain=0, bus=0, slot=1, func=2 class=10-10-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0220, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type Memory, range 32, base 0xa0000000, size 14, enabled found-> vendor=0x1106, dev=0x3053, revid=0x96 domain=0, bus=0, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xe100, size 8, enabled map[14]: type Memory, range 32, base 0xa0004000, size 8, enabled found-> vendor=0x1106, dev=0x3053, revid=0x96 domain=0, bus=0, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xe200, size 8, enabled map[14]: type Memory, range 32, base 0xa0004100, size 8, enabled found-> vendor=0x1106, dev=0x3053, revid=0x96 domain=0, bus=0, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=9 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xe300, size 8, enabled map[14]: type Memory, range 32, base 0xa0004200, size 8, enabled found-> vendor=0x1106, dev=0x3053, revid=0x96 domain=0, bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xe400, size 8, enabled map[14]: type Memory, range 32, base 0xa0004300, size 8, enabled found-> vendor=0x1409, dev=0x7168, revid=0x01 domain=0, bus=0, slot=14, func=0 class=07-00-02, hdrtype=0x00, mfdev=0 cmdreg=0x0181, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type I/O Port, range 32, base 0xe500, size 5, enabled map[14]: type I/O Port, range 32, base 0xe520, size 4, enabled map[18]: type I/O Port, range 32, base 0xe530, size 3, enabled map[1c]: type I/O Port, range 32, base 0xe538, size 3, enabled map[20]: type I/O Port, range 32, base 0xe540, size 3, enabled map[24]: type I/O Port, range 32, base 0xe548, size 3, enabled found-> vendor=0x1022, dev=0x2090, revid=0x03 domain=0, bus=0, slot=20, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0009, statreg=0x02a0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type I/O Port, range 32, base 0x6000, size 13, enabled map[14]: type I/O Port, range 32, base 0x6100, size 8, enabled map[18]: type I/O Port, range 32, base 0x6200, size 9, enabled found-> vendor=0x1022, dev=0x209a, revid=0x01 domain=0, bus=0, slot=20, func=2 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02a0, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type I/O Port, range 32, base 0xe000, size 4, enabled found-> vendor=0x1022, dev=0x2094, revid=0x02 domain=0, bus=0, slot=21, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 map[10]: type Memory, range 32, base 0xa0005000, size 12, enabled found-> vendor=0x1022, dev=0x2095, revid=0x02 domain=0, bus=0, slot=21, func=1 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 map[10]: type Memory, range 32, base 0xa0006000, size 12, enabled pci0: at device 1.2 (no driver attached) vr0: port 0xe100-0xe1ff mem 0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0 vr0: Quirks: 0x6 vr0: Revision: 0x96 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe100 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x004063, model 0x0034, rev. 3 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 00:00:24:ca:0a:d8 vr0: [MPSAFE] vr0: [ITHREAD] vr1: port 0xe200-0xe2ff mem 0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0 vr1: Quirks: 0x6 vr1: Revision: 0x96 vr1: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe200 miibus1: on vr1 ukphy1: PHY 1 on miibus1 ukphy1: OUI 0x004063, model 0x0034, rev. 3 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: bpf attached vr1: Ethernet address: 00:00:24:ca:0a:d9 vr1: [MPSAFE] vr1: [ITHREAD] vr2: port 0xe300-0xe3ff mem 0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0 vr2: Quirks: 0x6 vr2: Revision: 0x96 vr2: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe300 miibus2: on vr2 ukphy2: PHY 1 on miibus2 ukphy2: OUI 0x004063, model 0x0034, rev. 3 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr2: bpf attached vr2: Ethernet address: 00:00:24:ca:0a:da vr2: [MPSAFE] vr2: [ITHREAD] vr3: port 0xe400-0xe4ff mem 0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0 vr3: Quirks: 0x6 vr3: Revision: 0x96 vr3: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400 miibus3: on vr3 ukphy3: PHY 1 on miibus3 ukphy3: OUI 0x004063, model 0x0034, rev. 3 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr3: bpf attached vr3: Ethernet address: 00:00:24:ca:0a:db vr3: [MPSAFE] vr3: [ITHREAD] puc0: port 0xe500-0xe51f, 0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f,0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xe500 puc0: Lazy allocation of 0x4 bytes rid 0x11 type 4 at 0x1000 puc0: Lazy allocation of 0x4 bytes rid 0x12 type 4 at 0x1004 puc0: Lazy allocation of 0x4 bytes rid 0x13 type 4 at 0x1008 puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe520 puc0: Lazy allocation of 0x4 bytes rid 0x15 type 4 at 0x100c puc0: [FILTER] uart0: on puc0 uart0: [FILTER] uart0: fast interrupt uart1: <16550 or compatible> on puc0 uart1: [FILTER] uart1: fast interrupt uart2: on puc0 uart2: [FILTER] uart2: fast interrupt isab0: at device 20.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 20.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe000 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ata1: [MPSAFE] ata1: [ITHREAD] ohci0: mem 0xa0005000-0xa0005fff irq 15 at device 21.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xa0005000 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered ehci0: mem 0xa0006000-0xa0006fff irq 15 at device 21.1 on pci0 ehci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xa0006000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 4 ports with 4 removable, self powered ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd27ff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x1f0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:004d psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sc0: no video adapter found. sc0: failed to probe on isa0 sio0: irq maps: 0x8001 0x8011 0x8001 0x8001 sio0: irq maps: 0x8001 0x8011 0x8001 0x8001 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio0: [FILTER] sio1: irq maps: 0x8001 0x8009 0x8001 0x8001 sio1: irq maps: 0x8001 0x8009 0x8001 0x8001 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: [FILTER] sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: failed to probe on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 499904707 Hz quality 800 Timecounters tick every 6.666 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 100 packets/ entry by default lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire atapicam: atapicam0 already exists; skipping it ad0: setting PIO4 on CS5536 chip ad0: setting WDMA2 on CS5536 chip ad0: 1953MB at ata0-master WDMA2 ad0: 4001760 sectors [3970C/16H/63S] 4 sectors/interrupt 1 depth queue GEOM: new disk ad0 Trying to mount root from ufs:/dev/ad0s1a Invalid time in clock: check and reset the date! start_init: trying /sbin/init 15.fe8155ebfe6e5152 too short 15.fe8168502ce320aa too short Regards, Thomas Vogt From kometen at gmail.com Fri May 16 08:46:51 2008 From: kometen at gmail.com (Claus Guttesen) Date: Fri May 16 08:46:56 2008 Subject: ciss(4) not coping with large arrays? In-Reply-To: <5c0ff6a70805160103o75461976wce04f697975a176c@mail.gmail.com> References: <20080516073932.GA39803@dmr.ath.cx> <5c0ff6a70805160103o75461976wce04f697975a176c@mail.gmail.com> Message-ID: >> In earlier releases (5 and 6 at least) you couldn't create partitions >> larger than 2 TB. I don't know whether work has been to circumvent >> this in 7 but tools like fsck has to be changed as well. Have you >> tried zfs? > > zfs has nothing to do with this. The driver is not properly dealing with > the large volume. > set the kernel tunable in loader.conf > kern.cam.da.3.minimum_cmd_size=16 > kern.cam.da.4.minimum_cmd_size=16 Yes, of course. I was off-course. :-) -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From koitsu at FreeBSD.org Fri May 16 09:37:11 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri May 16 09:37:16 2008 Subject: just one last question about /etc/rc.d file permissions In-Reply-To: <784966050805160013w7d3ec31euc95be9e4a0a68fa9@mail.gmail.com> References: <784966050805160013w7d3ec31euc95be9e4a0a68fa9@mail.gmail.com> Message-ID: <20080516093711.GA55422@eos.sc1.parodius.com> On Fri, May 16, 2008 at 12:13:19AM -0700, Rob Lytle wrote: > Hi Jeremy, > > I noticed that most all of the files in my old /etc/rc.d had 555 > permissions. There were 4 or 5 that had 644 permissions in my old > /etc/rc.d. What I am wondering is if all the files in rc.d should be > 555? So far I am not experiencing any problems with anything with a > very few 644 files. Yes, they all should be. On our RELENG_6 and RELENG_7 systems they are. I wonder if part of the problem is that your umask was set oddly before running mergemaster, or possibly even when doing your csup. It should be 022. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From xcllnt at mac.com Fri May 16 10:53:27 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri May 16 10:53:32 2008 Subject: Timedia 8 port serial pci card problem In-Reply-To: <65DED12A-0263-4281-ADAC-CBF2A7857D5E@bsdunix.ch> References: <65DED12A-0263-4281-ADAC-CBF2A7857D5E@bsdunix.ch> Message-ID: <7C738CA6-9F66-44B4-A1AF-9CC3F80DB6BC@mac.com> On May 16, 2008, at 1:17 AM, Thomas Vogt wrote: > FreeBSD detects it with: "puc0: > port 0xe500-0xe51f,0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f, > 0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0" . But it > only adds 3 uart ports instead of 8. Any idea what i can do? Can you try the following (white-space corrupted) patch: Index: pucdata.c =================================================================== RCS file: /home/ncvs/src/sys/dev/puc/pucdata.c,v retrieving revision 1.59.2.1 diff -u -r1.59.2.1 pucdata.c --- pucdata.c 26 Feb 2008 09:33:57 -0000 1.59.2.1 +++ pucdata.c 16 May 2008 10:48:25 -0000 @@ -1116,7 +1116,7 @@ *res = (port == 1 || port == 3) ? 8 : 0; return (0); case PUC_CFG_GET_RID: - *res = 0x10 + ((port > 3) ? port - 2 : port >> 1); + *res = 0x10 + ((port > 3) ? port - 2 : port >> 1) * 4; return (0); case PUC_CFG_GET_TYPE: *res = PUC_TYPE_SERIAL; -- Marcel Moolenaar xcllnt@mac.com From lev at FreeBSD.org Fri May 16 10:59:00 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Fri May 16 10:59:05 2008 Subject: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs": problems with second one, UDP timeouts and ICMP ports unreach?! Message-ID: <482D6492.8080209@FreeBSD.org> I have two hosts: host A (FreeBSD 6.3-S) and host B (FreeBSD 7.0-S, freshly installed). Host A exports "/usr/ports" to host B via NFS. Mount with "mount_nfs" works well: b# mount_nfs a:/usr/ports /usr/ports b# ls /usr/ports [---SKIPPED---= b# But mount with "mount -t nfs" FAILS: b# mount -t nfs a:/usr/ports /usr/ports [udp] a:/usr/ports: NFSPROC_NULL: RPC: Timed out [udp] a:/usr/ports: NFSPROC_NULL: RPC: Timed out ^C b# tcpdump on A shows VERY strange picture: b.960 > a.sunrpc: UDP, length 56 a.sunrpc > b.960: UDP, length 28 b.820 > a.nfs: 40 null a.nfs > b.820: reply ok 24 b > a: ICMP b udp port 820 unreachable, length 36 b.912 > a.sunrpc: UDP, length 56 a.sunrpc > b.912: UDP, length 28 b.973 > a.nfs: 40 null a.nfs > b.973: reply ok 24 b > a: ICMP b udp port 973 unreachable, length 36 You see? b answer with "UDP port unreachable" on each RPC reply! There is NO any firewalls on B. And, I repeat, it WORKS when I call mount_nfs directly in a moment! Main problem is, that "/etc/fstab" is processed by mount, and NFS mount hangs up on boot, as shown above :( -- // Lev Serebryakov From Willy at Offermans.Rompen.nl Fri May 16 12:12:02 2008 From: Willy at Offermans.Rompen.nl (Willy Offermans) Date: Fri May 16 12:12:07 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <20080421201047.GB6884@slackbox.xs4all.nl> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> Message-ID: <20080516121414.GD4618@wiz.vpn.offrom.nl> Hello Roland and FreeBSD friends, I'm sorry to be so quite for a while, but I went away for a vacation. But now I'm back, I like to solve this issue. On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: > On Mon, Apr 21, 2008 at 09:04:03PM +0200, Willy Offermans wrote: > > Dear FreeBSD friends, > > > > It is already the third time that I report this error. Can someone help > > me in solving this issue? > > Probably the reason that you hear so little is that you provide so > little information. Most of us are not clairvoyant. > > > Over and over again and always after heavy disk I/O I see the following > > errors in the log files. If I force ar0s1g to unmount the machine > > spontaneously reboots. Nothing seriously seems to be damaged by this > > act, but anyway I cannot afford something bad happening to this > > production machine. > > Why would you force an unmount? Otherwise the device keeps on reporting to be unavailable and cannot be unmounted: sun# umount /share/ umount: unmount of /share failed: Resource temporarily unavailable > > > Apr 18 20:02:19 sun kernel: g_vfs_done():ar0s1g[WRITE(offset=290725068800, length=4096)]error = 5 > > > > I have no clue what the errors mean, since offsets of 290725068800, > > 290725072896, and 290725074944 seem to be ridiculous. Does anybody > > have a clue what is going on? > > For starters, how big is ar0s1g? If the offset is in bytes, it is around > 270 GB, which is not that unusual in this day and age. I have to admit that I was a bit confused by an offset value of 290725068800. There is no indication of a unit, so I assumed that it was sector but probably it is simply bytes and then indeed the number does make sense. > > > I'm using FreeBSD 7.0, but found the error being reported before with > > previous versions of FreeBSD. I can and will provide more details on > > demand. > > What does 'df' say? Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ar0s1a 20308398 230438 18453290 1% / devfs 1 1 0 100% /dev /dev/ar0s1d 21321454 3814482 15801256 19% /usr /dev/ar0s1e 50777034 5331686 41383186 11% /var /dev/ar0s1f 101554150 18813760 74616058 20% /home /dev/ar0s1g 274977824 34564876 218414724 14% /share pretty normal I would say. > > Did you notice any file corruption in the filesystem on ar0s1g? No the two disks are brand new and I did not encounter any noticeable file corruption. However I assume that nowadays bad sectors on HD are handled by the hardware and do not need any user interaction to correct this. But maybe I'm totally wrong. > > Unmount the filesystem and run fsck(8) on it. Does it report any errors? sun# fsck /dev/ar0s1g ** /dev/ar0s1g ** Last Mounted on /share ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=34788357 (272 should be 264) CORRECT? [yn] y INCORRECT BLOCK COUNT I=34789217 (296 should be 288) CORRECT? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 blocks, 0.0% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** The usual stuff I would say. > > > Any hints are very much appreciated. > > Did you manage to create a partition larger than the disk is (using > newfs's -s switch)? In that case it could be that you're trying to write > past the end of the device. No, look to the following output: sun# bsdlabel -A /dev/ar0s1 # /dev/ar0s1: type: unknown disk: amnesiac label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 60799 sectors/unit: 976751937 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 41943040 0 4.2BSD 0 0 0 b: 8388608 41943040 swap c: 976751937 0 unused 0 0 # "raw" part, don't edit d: 44040192 50331648 4.2BSD 2048 16384 28552 e: 104857600 94371840 4.2BSD 2048 16384 28552 f: 209715200 199229440 4.2BSD 2048 16384 28552 g: 567807297 408944640 4.2BSD 2048 16384 28552 /dev/ar0s1g starts after 408944640*512/1024/1024=199680MB So I have to conclude that the write error message does make sense and that something seems to be wrong with the disks. The next question is what can I do about it? Should I return the disks to the shop and ask for new ones? However other people that I have contacted and who had a similar problem before have solved it by using software raid setup instead of a hardware raid setup. This seems to indicate that there is some bug in the FreeBSD code. Another peculiarity that I have to mention is the following. If I use sysinstall and if I try to ``Label allocated disk partitions'', I cannot see the partitions on ar0. However the partitions can be visualised by bsdlabel as shown above. What is going on and what should I do? > > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 653 27 16 23 e-mail: Willy@Offermans.Rompen.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From koitsu at FreeBSD.org Fri May 16 12:27:59 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri May 16 12:28:26 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <20080516121414.GD4618@wiz.vpn.offrom.nl> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> Message-ID: <20080516122759.GA61346@eos.sc1.parodius.com> On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote: > On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: > > Did you notice any file corruption in the filesystem on ar0s1g? > > No the two disks are brand new and I did not encounter any noticeable > file corruption. However I assume that nowadays bad sectors on HD are > handled by the hardware and do not need any user interaction to correct > this. But maybe I'm totally wrong. You're right, but it depends on the type of disk. SCSI disks will report bad blocks to the OS regardless if it is about to mark the block as a grown defect or not. PATA and SATA disks, on the other hand, will report bad blocks to the OS only if the internal bad block list (which it manages itself -- this is what you're thinking of) is full. There are still many conditions where PATA and SATA disks can induce errors in the OS. If the disk is attempting to work around a bad block, and there's a physical error (servo problem, head crash, repetitive re-reads of the block due to dust, whatever -- something that "ties up" the disk for long periods of time), ATA subsystem timeouts may be seen, DMA errors, or whatever else. SMART stats will show this kind of problem. > > Unmount the filesystem and run fsck(8) on it. Does it report any errors? > > sun# fsck /dev/ar0s1g > ** /dev/ar0s1g > ** Last Mounted on /share > ** Phase 1 - Check Blocks and Sizes > INCORRECT BLOCK COUNT I=34788357 (272 should be 264) > CORRECT? [yn] y > > INCORRECT BLOCK COUNT I=34789217 (296 should be 288) > CORRECT? [yn] y > > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? [yn] y > > SUMMARY INFORMATION BAD > SALVAGE? [yn] y > > BLK(S) MISSING IN BIT MAPS > SALVAGE? [yn] y > > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 > blocks, 0.0% fragmentation) > > ***** FILE SYSTEM MARKED CLEAN ***** > > ***** FILE SYSTEM WAS MODIFIED ***** > > The usual stuff I would say. How is this usual?. It appears to me you did have some filesystem corruption. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pldrouin at pldrouin.net Fri May 16 12:38:06 2008 From: pldrouin at pldrouin.net (Pierre-Luc Drouin) Date: Fri May 16 12:38:12 2008 Subject: Status of ZFS in -stable? Message-ID: <482917B0.9040302@pldrouin.net> Hi, I would like to know memory allocation problem eith zfs has been fixed in -stable since the release of 7.0? Is zfs more "stable From kris at FreeBSD.org Fri May 16 12:43:23 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Fri May 16 12:43:29 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <20080516121414.GD4618@wiz.vpn.offrom.nl> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> Message-ID: <482D816C.4060402@FreeBSD.org> Willy Offermans wrote: > Hello Roland and FreeBSD friends, > > I'm sorry to be so quite for a while, but I went away for a vacation. > But now I'm back, I like to solve this issue. > > > On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: >> On Mon, Apr 21, 2008 at 09:04:03PM +0200, Willy Offermans wrote: >>> Dear FreeBSD friends, >>> >>> It is already the third time that I report this error. Can someone help >>> me in solving this issue? >> Probably the reason that you hear so little is that you provide so >> little information. Most of us are not clairvoyant. >> >>> Over and over again and always after heavy disk I/O I see the following >>> errors in the log files. If I force ar0s1g to unmount the machine >>> spontaneously reboots. Nothing seriously seems to be damaged by this >>> act, but anyway I cannot afford something bad happening to this >>> production machine. >> Why would you force an unmount? > > Otherwise the device keeps on reporting to be unavailable and cannot be > unmounted: > > sun# umount /share/ > umount: unmount of /share failed: Resource temporarily unavailable > >>> Apr 18 20:02:19 sun kernel: g_vfs_done():ar0s1g[WRITE(offset=290725068800, length=4096)]error = 5 >>> >>> I have no clue what the errors mean, since offsets of 290725068800, >>> 290725072896, and 290725074944 seem to be ridiculous. Does anybody >>> have a clue what is going on? >> For starters, how big is ar0s1g? If the offset is in bytes, it is around >> 270 GB, which is not that unusual in this day and age. > > I have to admit that I was a bit confused by an offset value of > 290725068800. There is no indication of a unit, so I assumed that it > was sector but probably it is simply bytes and then indeed the number > does make sense. >>> I'm using FreeBSD 7.0, but found the error being reported before with >>> previous versions of FreeBSD. I can and will provide more details on >>> demand. >> What does 'df' say? > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ar0s1a 20308398 230438 18453290 1% / > devfs 1 1 0 100% /dev > /dev/ar0s1d 21321454 3814482 15801256 19% /usr > /dev/ar0s1e 50777034 5331686 41383186 11% /var > /dev/ar0s1f 101554150 18813760 74616058 20% /home > /dev/ar0s1g 274977824 34564876 218414724 14% /share > > pretty normal I would say. > >> Did you notice any file corruption in the filesystem on ar0s1g? > > No the two disks are brand new and I did not encounter any noticeable > file corruption. However I assume that nowadays bad sectors on HD are > handled by the hardware and do not need any user interaction to correct > this. But maybe I'm totally wrong. > >> Unmount the filesystem and run fsck(8) on it. Does it report any errors? > > sun# fsck /dev/ar0s1g > ** /dev/ar0s1g > ** Last Mounted on /share > ** Phase 1 - Check Blocks and Sizes > INCORRECT BLOCK COUNT I=34788357 (272 should be 264) > CORRECT? [yn] y > > INCORRECT BLOCK COUNT I=34789217 (296 should be 288) > CORRECT? [yn] y > > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? [yn] y > > SUMMARY INFORMATION BAD > SALVAGE? [yn] y > > BLK(S) MISSING IN BIT MAPS > SALVAGE? [yn] y > > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 > blocks, 0.0% fragmentation) > > ***** FILE SYSTEM MARKED CLEAN ***** > > ***** FILE SYSTEM WAS MODIFIED ***** > > The usual stuff I would say. No, any form of filesystem corruption is not usual. > >>> Any hints are very much appreciated. >> Did you manage to create a partition larger than the disk is (using >> newfs's -s switch)? In that case it could be that you're trying to write >> past the end of the device. > > No, look to the following output: > > sun# bsdlabel -A /dev/ar0s1 > # /dev/ar0s1: > type: unknown > disk: amnesiac > label: > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 60799 > sectors/unit: 976751937 > rpm: 3600 > interleave: 1 > trackskew: 0 > cylinderskew: 0 > headswitch: 0 # milliseconds > track-to-track seek: 0 # milliseconds > drivedata: 0 > > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 41943040 0 4.2BSD 0 0 0 > b: 8388608 41943040 swap > c: 976751937 0 unused 0 0 # "raw" > part, don't edit > d: 44040192 50331648 4.2BSD 2048 16384 28552 > e: 104857600 94371840 4.2BSD 2048 16384 28552 > f: 209715200 199229440 4.2BSD 2048 16384 28552 > g: 567807297 408944640 4.2BSD 2048 16384 28552 > > /dev/ar0s1g starts after 408944640*512/1024/1024=199680MB > > > So I have to conclude that the write error message does make sense and > that something seems to be wrong with the disks. The next question is > what can I do about it? Should I return the disks to the shop and ask > for new ones? #define EIO 5 /* Input/output error */ At least one of your disks is toast. Kris From freebsdlists at bsdunix.ch Fri May 16 13:36:27 2008 From: freebsdlists at bsdunix.ch (Thomas Vogt) Date: Fri May 16 13:36:34 2008 Subject: Timedia 8 port serial pci card problem In-Reply-To: <7C738CA6-9F66-44B4-A1AF-9CC3F80DB6BC@mac.com> References: <65DED12A-0263-4281-ADAC-CBF2A7857D5E@bsdunix.ch> <7C738CA6-9F66-44B4-A1AF-9CC3F80DB6BC@mac.com> Message-ID: <81B25D8A-5EE6-4C18-A170-15ADACA8B3C7@bsdunix.ch> Hi Marcel Am 16.05.2008 um 12:53 schrieb Marcel Moolenaar: > > On May 16, 2008, at 1:17 AM, Thomas Vogt wrote: > >> FreeBSD detects it with: "puc0: >> port 0xe500-0xe51f,0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f, >> 0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0" . But it >> only adds 3 uart ports instead of 8. Any idea what i can do? > > Can you try the following (white-space corrupted) patch: > > Index: pucdata.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/puc/pucdata.c,v > retrieving revision 1.59.2.1 > diff -u -r1.59.2.1 pucdata.c > --- pucdata.c 26 Feb 2008 09:33:57 -0000 1.59.2.1 > +++ pucdata.c 16 May 2008 10:48:25 -0000 > @@ -1116,7 +1116,7 @@ > *res = (port == 1 || port == 3) ? 8 : 0; > return (0); > case PUC_CFG_GET_RID: > - *res = 0x10 + ((port > 3) ? port - 2 : port >> 1); > + *res = 0x10 + ((port > 3) ? port - 2 : port >> 1) * 4; > return (0); > case PUC_CFG_GET_TYPE: > *res = PUC_TYPE_SERIAL; Thats it. It works with your patch dmesg: puc0: port 0xe500-0xe51f, 0xe520-0xe52f,0xe530-0xe537,0xe538-0xe53f,0xe540-0xe547,0xe548-0xe54f irq 10 at device 14.0 on pci0 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xe500 puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe520 puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe530 puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe538 puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe540 puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe548 puc0: [FILTER] uart0: on puc0 uart0: [FILTER] uart0: fast interrupt uart1: on puc0 uart1: [FILTER] uart1: fast interrupt uart2: on puc0 uart2: [FILTER] uart2: fast interrupt uart3: on puc0 uart3: [FILTER] uart3: fast interrupt uart4: on puc0 uart4: [FILTER] uart4: fast interrupt uart5: on puc0 uart5: [FILTER] uart5: fast interrupt uart6: on puc0 uart6: [FILTER] uart6: fast interrupt uart7: on puc0 uart7: [FILTER] uart7: fast interrupt Thank you, Thomas From brd at FreeBSD.org Fri May 16 13:43:51 2008 From: brd at FreeBSD.org (Brad Davis) Date: Fri May 16 13:43:56 2008 Subject: FreeBSD Status Reports for the First Quarter of 2008 Message-ID: <20080516134346.GB1844@valentine.liquidneon.com> Hi Everyone, The FreeBSD Status Reports for the First Quarter of 2008 are now available at: http://www.freebsd.org/news/status/report-2008-01-2008-03.html Regards, Brad Davis From steve at mouf.net Fri May 16 13:54:00 2008 From: steve at mouf.net (Steve Wills) Date: Fri May 16 13:54:28 2008 Subject: cfservd crashing on 7.0 Message-ID: <9A673D2F-8758-44D9-A41A-382610B377BA@mouf.net> Hi, I just moved my cfservd (a part of sysutils/cfengine) from a 6.2 server to a 7.0 server. Ever since, cfservd crashes regularly. The backtrace is below, although obviously it is missing a lot. If anyone has clues or suggestions, I'd really appreciate it. # gdb /usr/local/sbin/cfservd cfservd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `cfservd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libdb-4.6.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdb-4.6.so.0 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libcrypto.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.5 Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x283214e0 in sha1_block_data_order () from /lib/libcrypto.so.5 [New Thread 0x28501600 (LWP 100725)] [New Thread 0x28501500 (LWP 100723)] [New Thread 0x28501c00 (LWP 100289)] [New Thread 0x28501a00 (LWP 100722)] [New Thread 0x28501900 (LWP 100505)] [New Thread 0x28501400 (LWP 100726)] [New Thread 0x28501100 (LWP 100614)] (gdb) bt #0 0x283214e0 in sha1_block_data_order () from /lib/libcrypto.so.5 #1 0x28323112 in SHA1_Update () from /lib/libcrypto.so.5 #2 0x283114fe in EVP_sha512 () from /lib/libcrypto.so.5 #3 0x2952e080 in ?? () #4 0x28391cf4 in ?? () from /lib/libcrypto.so.5 #5 0xffffff6b in ?? () #6 0x28311b65 in EVP_DigestInit_ex () from /lib/libcrypto.so.5 #7 0x2831161f in EVP_DigestUpdate () from /lib/libcrypto.so.5 #8 0x282f38ef in RAND_SSLeay () from /lib/libcrypto.so.5 #9 0xbf8f5d20 in ?? () #10 0x28391cf4 in ?? () from /lib/libcrypto.so.5 #11 0xffffff6b in ?? () #12 0x000001c2 in ?? () #13 0x00000100 in ?? () #14 0xbf8f5d38 in ?? () #15 0x2836aad0 in RSA_version () from /lib/libcrypto.so.5 #16 0xbf8f5d0c in ?? () #17 0xbf8f5d30 in ?? () #18 0x0000000a in ?? () #19 0x000003ff in ?? () #20 0x00000001 in ?? () #21 0xfffffc0b in ?? () #22 0x9479e4c0 in ?? () #23 0x907484c9 in ?? () ---Type to continue, or q to quit--- #24 0x99437746 in ?? () #25 0xde61d2b4 in ?? () #26 0xaab0b47e in ?? () #27 0x2838cc20 in ASN1_OCTET_STRING_NDEF_it () from /lib/libcrypto.so.5 #28 0x00000000 in ?? () #29 0x00000000 in ?? () #30 0x2952e080 in ?? () #31 0x0000952a in ?? () #32 0x000036ea in ?? () #33 0x00000000 in ?? () #34 0x2838f08c in ?? () from /lib/libcrypto.so.5 #35 0x29512080 in ?? () #36 0x2952a102 in ?? () #37 0xbf8f5d68 in ?? () #38 0x282f2eac in RAND_bytes () from /lib/libcrypto.so.5 Previous frame identical to this frame (corrupt stack?) (gdb) Thanks, Steve From lev at FreeBSD.org Fri May 16 13:58:30 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Fri May 16 13:58:36 2008 Subject: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs": problems with second one, UDP timeouts and ICMP ports unreach?! In-Reply-To: <482D6492.8080209@FreeBSD.org> References: <482D6492.8080209@FreeBSD.org> Message-ID: <482D92D4.20908@FreeBSD.org> Lev Serebryakov wrote: > You see? b answer with "UDP port unreachable" on each RPC reply! Additional info. ktrace from "mount -t nfs": ============================================================= 65962 mount_nfs 0.006679 RET sendto 40/0x28 65962 mount_nfs 0.006682 CALL kevent(0x4,0x638110,0x1,0x7fffffffe2d0,0x1,0x7fffffffe310) 65962 mount_nfs 10.218001 GIO fd 4 wrote 32 bytes 65962 mount_nfs 10.218018 GIO fd 4 read 0 bytes "" 65962 mount_nfs 10.218023 RET kevent 0 65962 mount_nfs 10.218029 CALL gettimeofday(0x7fffffffe320,0) 65962 mount_nfs 10.218035 RET gettimeofday 0 65962 mount_nfs 10.218040 CALL close(0x4) 65962 mount_nfs 10.218049 RET close 0 65962 mount_nfs 10.218077 CALL close(0x3) 65962 mount_nfs 10.218087 RET close 0 65962 mount_nfs 10.218101 CALL write(0x2,0x7fffffffdd40,0x37) 65962 mount_nfs 10.218117 GIO fd 2 wrote 55 bytes "[udp] gateway:/usr/ports: NFSPROC_NULL: RPC: Timed out " ============================================================= ktrace (same piece) from "mount_nfs": ============================================================= 93109 mount_nfs 0.005458 RET sendto 40/0x28 93109 mount_nfs 0.005462 CALL kevent(0x4,0x638110,0x1,0x7fffffffe2a0,0x1,0x7fffffffe2e0) 93109 mount_nfs 0.005724 GIO fd 4 wrote 32 bytes 93109 mount_nfs 0.005738 GIO fd 4 read 32 bytes 93109 mount_nfs 0.005743 RET kevent 1 93109 mount_nfs 0.005748 CALL recvfrom(0x3,0x638134,0x2260,0,0,0) 93109 mount_nfs 0.005756 GIO fd 3 read 24 bytes 93109 mount_nfs 0.005761 RET recvfrom 24/0x18 93109 mount_nfs 0.005767 CALL close(0x4) 93109 mount_nfs 0.005775 RET close 0 93109 mount_nfs 0.005781 CALL close(0x3) 93109 mount_nfs 0.005788 RET close 0 ============================================================= From dot at dotat.at Fri May 16 14:26:30 2008 From: dot at dotat.at (Tony Finch) Date: Fri May 16 14:26:35 2008 Subject: cvsup.uk.FreeBSD.org In-Reply-To: <07f101c8b6e2$f4b13f20$de13bd60$@org.uk> References: <20080511102730.DBD0A600F@mailhost.tao.org.uk> <07f101c8b6e2$f4b13f20$de13bd60$@org.uk> Message-ID: On Fri, 16 May 2008, Dr Josef Karthauser wrote: > > As a matter of interest, do you know what the peak bandwidth usage is? Based on the cvsupd log the peak is around 600KB/sec in and 360KB/sec out at about 2am. The university's bandwidth accounting system says: date host in (MB) out (MB) total 2008-05-09 131.111.008.041 1902.863 2890.291 4793.155 2008-05-10 131.111.008.041 9278.231 5287.797 14566.028 2008-05-11 131.111.008.041 9214.064 4059.799 13273.863 2008-05-12 131.111.008.041 9248.677 4458.978 13707.655 2008-05-13 131.111.008.041 8818.575 4651.896 13470.471 2008-05-14 131.111.008.041 9254.688 5833.494 15088.182 2008-05-15 131.111.008.041 9116.638 4715.182 13831.820 Tony. -- f.anthony.n.finch http://dotat.at/ VIKING: NORTHERLY 4 OR 5 INCREASING 6 OR 7, PERHAPS GALE 8 LATER. MODERATE BECOMING ROUGH. SHOWERS. MODERATE OR GOOD. From vivek at khera.org Fri May 16 14:53:08 2008 From: vivek at khera.org (Vivek Khera) Date: Fri May 16 14:53:16 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: <6ADAB997-FAA4-43B8-AB57-3CC4A04F3700@khera.org> References: <04EA1C34-AB7D-4A85-8A91-DED03E987706@khera.org> <482C07DE.3090504@yandex.ru> <482C0A89.104@FreeBSD.org> <6ADAB997-FAA4-43B8-AB57-3CC4A04F3700@khera.org> Message-ID: How are the buckets used? Are they hashed per rule number or some other mechanism? Nearly all of my states are from the same rule (eg, on a mail server for the SMTP port rule). How should I scale the buckets with the max rules? The default seems to be 4096 rules and 256 buckets. Should I maintain that ratio? From lists-fbsdstable at shadypond.com Fri May 16 15:11:02 2008 From: lists-fbsdstable at shadypond.com (Pollywog) Date: Fri May 16 15:11:10 2008 Subject: today's build is causing errors for me In-Reply-To: <20080516061724.GA47953@eos.sc1.parodius.com> References: <784966050805151644m43b9a5e1qe8a4568576fc081f@mail.gmail.com> <784966050805152304t1827c53bi6988ae9c8f837f32@mail.gmail.com> <20080516061724.GA47953@eos.sc1.parodius.com> Message-ID: <200805161442.51667.lists-fbsdstable@shadypond.com> On Friday 16 May 2008 06:17:24 Jeremy Chadwick wrote: > > Additionally, mergemaster isn't a confusing mess. If anything, it's one > of the most simple tools there is for managing /etc. The part you > probably find "confusing", which is the same part I did when I started > using it, is the side-by-side interactive diff. It's very easy to use; > "r" means use the text shown on the right, and "l" means use the text > shown on the left. That is certainly the part that confused me until I referred to the "Absolute FreeBSD" book. From lists-fbsdstable at shadypond.com Fri May 16 15:11:02 2008 From: lists-fbsdstable at shadypond.com (Pollywog) Date: Fri May 16 15:11:11 2008 Subject: today's build is causing errors for me In-Reply-To: <784966050805152304t1827c53bi6988ae9c8f837f32@mail.gmail.com> References: <784966050805151644m43b9a5e1qe8a4568576fc081f@mail.gmail.com> <20080516043411.GA44491@eos.sc1.parodius.com> <784966050805152304t1827c53bi6988ae9c8f837f32@mail.gmail.com> Message-ID: <200805161441.24237.lists-fbsdstable@shadypond.com> On Friday 16 May 2008 06:04:34 Rob Lytle wrote: > Hi Jeremy, > > I used Mergemaster. Thats what I mean't when I said that I carefully > "merged" /usr/src/etc/ with /etc. But like I said, no files were > replaced that contained my own configuration, e.g. group. I will say > this- that I have always considered Mergemaster a confusing mess, > despite the dogma on the lists. I have been running FreeBSD and > installing it since 1998, so I have some experience- but this is new > behavior beyond my previous experiences. I have only been using FreeBSD for almost one year and I am still a little confused by Mergemaster, but what helped me with it was the book "Absolute FreeBSD". I would not have been able to deal with it without the book. From lev at FreeBSD.org Fri May 16 15:23:15 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Fri May 16 15:23:24 2008 Subject: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs": problems with second one, UDP timeouts and ICMP ports unreach?! In-Reply-To: <482D6492.8080209@FreeBSD.org> References: <482D6492.8080209@FreeBSD.org> Message-ID: <482DA6A5.4060103@FreeBSD.org> Lev Serebryakov wrote: > Main problem is, that "/etc/fstab" is processed by mount, and NFS > mount hangs up on boot, as shown above :( Mounting with "mount -t nfs" with 7.0 server (host B) and 6.3 client (host A) works... -- // Lev Serebryakov From Willy at Offermans.Rompen.nl Fri May 16 15:35:34 2008 From: Willy at Offermans.Rompen.nl (Willy Offermans) Date: Fri May 16 15:35:40 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <20080516122759.GA61346@eos.sc1.parodius.com> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> <20080516122759.GA61346@eos.sc1.parodius.com> Message-ID: <20080516153755.GA9388@wiz.vpn.offrom.nl> Hello Jeremy and FreeBSD friends, On Fri, May 16, 2008 at 05:27:59AM -0700, Jeremy Chadwick wrote: > On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote: > > On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: > > > Did you notice any file corruption in the filesystem on ar0s1g? > > > > No the two disks are brand new and I did not encounter any noticeable > > file corruption. However I assume that nowadays bad sectors on HD are > > handled by the hardware and do not need any user interaction to correct > > this. But maybe I'm totally wrong. > > You're right, but it depends on the type of disk. SCSI disks will > report bad blocks to the OS regardless if it is about to mark the block > as a grown defect or not. PATA and SATA disks, on the other hand, will > report bad blocks to the OS only if the internal bad block list (which > it manages itself -- this is what you're thinking of) is full. > > There are still many conditions where PATA and SATA disks can induce > errors in the OS. If the disk is attempting to work around a bad block, > and there's a physical error (servo problem, head crash, repetitive > re-reads of the block due to dust, whatever -- something that "ties up" > the disk for long periods of time), ATA subsystem timeouts may be seen, > DMA errors, or whatever else. SMART stats will show this kind of > problem. > > > > Unmount the filesystem and run fsck(8) on it. Does it report any errors? > > > > sun# fsck /dev/ar0s1g > > ** /dev/ar0s1g > > ** Last Mounted on /share > > ** Phase 1 - Check Blocks and Sizes > > INCORRECT BLOCK COUNT I=34788357 (272 should be 264) > > CORRECT? [yn] y > > > > INCORRECT BLOCK COUNT I=34789217 (296 should be 288) > > CORRECT? [yn] y > > > > ** Phase 2 - Check Pathnames > > ** Phase 3 - Check Connectivity > > ** Phase 4 - Check Reference Counts > > ** Phase 5 - Check Cyl groups > > FREE BLK COUNT(S) WRONG IN SUPERBLK > > SALVAGE? [yn] y > > > > SUMMARY INFORMATION BAD > > SALVAGE? [yn] y > > > > BLK(S) MISSING IN BIT MAPS > > SALVAGE? [yn] y > > > > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 > > blocks, 0.0% fragmentation) > > > > ***** FILE SYSTEM MARKED CLEAN ***** > > > > ***** FILE SYSTEM WAS MODIFIED ***** > > > > The usual stuff I would say. > > How is this usual?. It appears to me you did have some filesystem > corruption. > What kind of filesystem corruption and how to solve that? I see these messages frequently if a FreeBSD machine unexpectedly reboots. Not only on this system but also on others. I never worried about it. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 653 27 16 23 e-mail: Willy@Offermans.Rompen.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From Willy at Offermans.Rompen.nl Fri May 16 15:39:46 2008 From: Willy at Offermans.Rompen.nl (Willy Offermans) Date: Fri May 16 15:39:52 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <482D816C.4060402@FreeBSD.org> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> <482D816C.4060402@FreeBSD.org> Message-ID: <20080516154206.GB9388@wiz.vpn.offrom.nl> Hello Kris, On Fri, May 16, 2008 at 02:43:24PM +0200, Kris Kennaway wrote: > Willy Offermans wrote: > >Hello Roland and FreeBSD friends, > > > >I'm sorry to be so quite for a while, but I went away for a vacation. > >But now I'm back, I like to solve this issue. > > > > > >On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: > >>On Mon, Apr 21, 2008 at 09:04:03PM +0200, Willy Offermans wrote: > >>>Dear FreeBSD friends, > >>> > >>>It is already the third time that I report this error. Can someone help > >>>me in solving this issue? > >>Probably the reason that you hear so little is that you provide so > >>little information. Most of us are not clairvoyant. > >> > >>>Over and over again and always after heavy disk I/O I see the following > >>>errors in the log files. If I force ar0s1g to unmount the machine > >>>spontaneously reboots. Nothing seriously seems to be damaged by this > >>>act, but anyway I cannot afford something bad happening to this > >>>production machine. > >>Why would you force an unmount? > > > >Otherwise the device keeps on reporting to be unavailable and cannot be > >unmounted: > > > >sun# umount /share/ > >umount: unmount of /share failed: Resource temporarily unavailable > > > >>>Apr 18 20:02:19 sun kernel: > >>>g_vfs_done():ar0s1g[WRITE(offset=290725068800, length=4096)]error = 5 > >>> > >>>I have no clue what the errors mean, since offsets of 290725068800, > >>>290725072896, and 290725074944 seem to be ridiculous. Does anybody > >>>have a clue what is going on? > >>For starters, how big is ar0s1g? If the offset is in bytes, it is around > >>270 GB, which is not that unusual in this day and age. > > > >I have to admit that I was a bit confused by an offset value of > >290725068800. There is no indication of a unit, so I assumed that it > >was sector but probably it is simply bytes and then indeed the number > >does make sense. > >>>I'm using FreeBSD 7.0, but found the error being reported before with > >>>previous versions of FreeBSD. I can and will provide more details on > >>>demand. > >>What does 'df' say? > > > >Filesystem 1K-blocks Used Avail Capacity Mounted on > >/dev/ar0s1a 20308398 230438 18453290 1% / > >devfs 1 1 0 100% /dev > >/dev/ar0s1d 21321454 3814482 15801256 19% /usr > >/dev/ar0s1e 50777034 5331686 41383186 11% /var > >/dev/ar0s1f 101554150 18813760 74616058 20% /home > >/dev/ar0s1g 274977824 34564876 218414724 14% /share > > > >pretty normal I would say. > > > >>Did you notice any file corruption in the filesystem on ar0s1g? > > > >No the two disks are brand new and I did not encounter any noticeable > >file corruption. However I assume that nowadays bad sectors on HD are > >handled by the hardware and do not need any user interaction to correct > >this. But maybe I'm totally wrong. > > > >>Unmount the filesystem and run fsck(8) on it. Does it report any errors? > > > >sun# fsck /dev/ar0s1g > >** /dev/ar0s1g > >** Last Mounted on /share > >** Phase 1 - Check Blocks and Sizes > >INCORRECT BLOCK COUNT I=34788357 (272 should be 264) > >CORRECT? [yn] y > > > >INCORRECT BLOCK COUNT I=34789217 (296 should be 288) > >CORRECT? [yn] y > > > >** Phase 2 - Check Pathnames > >** Phase 3 - Check Connectivity > >** Phase 4 - Check Reference Counts > >** Phase 5 - Check Cyl groups > >FREE BLK COUNT(S) WRONG IN SUPERBLK > >SALVAGE? [yn] y > > > >SUMMARY INFORMATION BAD > >SALVAGE? [yn] y > > > >BLK(S) MISSING IN BIT MAPS > >SALVAGE? [yn] y > > > >182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 > >blocks, 0.0% fragmentation) > > > >***** FILE SYSTEM MARKED CLEAN ***** > > > >***** FILE SYSTEM WAS MODIFIED ***** > > > >The usual stuff I would say. > > No, any form of filesystem corruption is not usual. > > > > >>>Any hints are very much appreciated. > >>Did you manage to create a partition larger than the disk is (using > >>newfs's -s switch)? In that case it could be that you're trying to write > >>past the end of the device. > > > >No, look to the following output: > > > >sun# bsdlabel -A /dev/ar0s1 > ># /dev/ar0s1: > >type: unknown > >disk: amnesiac > >label: > >flags: > >bytes/sector: 512 > >sectors/track: 63 > >tracks/cylinder: 255 > >sectors/cylinder: 16065 > >cylinders: 60799 > >sectors/unit: 976751937 > >rpm: 3600 > >interleave: 1 > >trackskew: 0 > >cylinderskew: 0 > >headswitch: 0 # milliseconds > >track-to-track seek: 0 # milliseconds > >drivedata: 0 > > > >8 partitions: > ># size offset fstype [fsize bsize bps/cpg] > > a: 41943040 0 4.2BSD 0 0 0 > > b: 8388608 41943040 swap > > c: 976751937 0 unused 0 0 # "raw" > >part, don't edit > > d: 44040192 50331648 4.2BSD 2048 16384 28552 > > e: 104857600 94371840 4.2BSD 2048 16384 28552 > > f: 209715200 199229440 4.2BSD 2048 16384 28552 > > g: 567807297 408944640 4.2BSD 2048 16384 28552 > > > >/dev/ar0s1g starts after 408944640*512/1024/1024=199680MB > > > > > >So I have to conclude that the write error message does make sense and > >that something seems to be wrong with the disks. The next question is > >what can I do about it? Should I return the disks to the shop and ask > >for new ones? > > #define EIO 5 /* Input/output error */ > > At least one of your disks is toast. > > Kris > I doubt it, but you could be right. Do you have any suggestions to investigate any further? Since this is a production machine I have to operate extremely carefully. I will transfer the data to other disks and will reboot and run the system from the other disks. Then I will reformat the disks again and restore the data. Lets see what happens. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 653 27 16 23 e-mail: Willy@Offermans.Rompen.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From koitsu at FreeBSD.org Fri May 16 15:59:38 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri May 16 15:59:42 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <20080516153755.GA9388@wiz.vpn.offrom.nl> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> <20080516122759.GA61346@eos.sc1.parodius.com> <20080516153755.GA9388@wiz.vpn.offrom.nl> Message-ID: <20080516155938.GA71548@eos.sc1.parodius.com> On Fri, May 16, 2008 at 05:37:56PM +0200, Willy Offermans wrote: > > > sun# fsck /dev/ar0s1g > > > ** /dev/ar0s1g > > > ** Last Mounted on /share > > > ** Phase 1 - Check Blocks and Sizes > > > INCORRECT BLOCK COUNT I=34788357 (272 should be 264) > > > CORRECT? [yn] y > > > > > > INCORRECT BLOCK COUNT I=34789217 (296 should be 288) > > > CORRECT? [yn] y > > > > > > ** Phase 2 - Check Pathnames > > > ** Phase 3 - Check Connectivity > > > ** Phase 4 - Check Reference Counts > > > ** Phase 5 - Check Cyl groups > > > FREE BLK COUNT(S) WRONG IN SUPERBLK > > > SALVAGE? [yn] y > > > > > > SUMMARY INFORMATION BAD > > > SALVAGE? [yn] y > > > > > > BLK(S) MISSING IN BIT MAPS > > > SALVAGE? [yn] y > > > > > > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 > > > blocks, 0.0% fragmentation) > > > > > > ***** FILE SYSTEM MARKED CLEAN ***** > > > > > > ***** FILE SYSTEM WAS MODIFIED ***** > > > > > > The usual stuff I would say. > > > > How is this usual?. It appears to me you did have some filesystem > > corruption. > > What kind of filesystem corruption and how to solve that? That's difficult to answer, for a lot of reasons. Your original post stated that you were seeing g_vfs_done errors on the console, and you were worried about what they implied. Then someone asked you "have you fsck'd the filesystem?", and you hadn't. Then you did fsck it, and as can be seen above, the filesystem had errors. When combined with your below comment, it's very difficult to figure out what's going on with your system over there, or what information you're not disclosing. Additionally, kris@ has stated that it looks like you may have a hard disk that's gone bad, and that's a strong possibility as well. SMART statistics of the drives in your RAID array would be useful. > I see these messages frequently if a FreeBSD machine unexpectedly reboots. Not only on this > system but also on others. I never worried about it. Are you saying the above errors experienced were caused by an unexpected crash or reboot? If so, the filesystem should have been automatically fsck'd shortly (60-120 seconds) after getting a "login:" prompt on the console. Is your filesystem UFS2 with softupdates enabled? If so, and the automatic fsck didn't happen, then that's something separate to look into -- it should happen automatically with softupdates enabled. More importantly, though, would be the explanation for why your system is crashing/rebooting/power-cycling. Data corruption can happen in those situations, especially the latter, but any form of non-clean shutdown should induce a fsck on UFS2+softupdate filesystems. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From zkolic at sbb.co.yu Fri May 16 16:03:17 2008 From: zkolic at sbb.co.yu (Zoran Kolic) Date: Fri May 16 16:03:27 2008 Subject: udf Message-ID: <20080516154848.GA1127@faust.net> Howdy! What is the experience regarding udf on cd/dvd on 7.0? I saw netbsd mail few days ago having those steps: newfs_udf and mount_udf. Best regards Zoran From stefan.lambrev at moneybookers.com Fri May 16 16:08:16 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Fri May 16 16:08:20 2008 Subject: udf In-Reply-To: <20080516154848.GA1127@faust.net> References: <20080516154848.GA1127@faust.net> Message-ID: <482DB16B.2070402@moneybookers.com> Zoran Kolic wrote: > Howdy! > What is the experience regarding udf on cd/dvd on 7.0? > I saw netbsd mail few days ago having those steps: > newfs_udf and mount_udf. > Best regards > From man mount_udf (FreeBSD7) HISTORY The mount_udf utility first appeared in FreeBSD 5.0. FreeBSD 7.0 March 23, 2002 FreeBSD 7.0 I have no idea for newfs_udf , and what is supposed this to do :) > Zoran > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From koitsu at FreeBSD.org Fri May 16 16:10:17 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri May 16 16:10:21 2008 Subject: udf In-Reply-To: <482DB16B.2070402@moneybookers.com> References: <20080516154848.GA1127@faust.net> <482DB16B.2070402@moneybookers.com> Message-ID: <20080516161017.GA72242@eos.sc1.parodius.com> On Fri, May 16, 2008 at 07:08:11PM +0300, Stefan Lambrev wrote: > From man mount_udf (FreeBSD7) > > HISTORY > The mount_udf utility first appeared in FreeBSD 5.0. > > FreeBSD 7.0 March 23, 2002 FreeBSD > 7.0 > > I have no idea for newfs_udf , and what is supposed this to do :) It creates a UDF (commonly DVD/DVD Audio) filesystem. NetBSD and Solaris 10 both have this. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sam at freebsd.org Fri May 16 16:23:29 2008 From: sam at freebsd.org (Sam Leffler) Date: Fri May 16 16:23:34 2008 Subject: Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7 In-Reply-To: <1210696676.985.18.camel@RabbitsDen> References: <1210640542.1008.33.camel@RabbitsDen> <4828FDE5.8090409@freebsd.org> <1210696676.985.18.camel@RabbitsDen> Message-ID: <482DB4FE.3010300@freebsd.org> Alexandre "Sunny" Kovalenko wrote: > On Mon, 2008-05-12 at 19:33 -0700, Sam Leffler wrote: >> Alexandre "Sunny" Kovalenko wrote: >>> I seem to be able to lock my machine by going into wpa_cli and asking it >>> to 'reassoc'. The reason for question mark after "hard" is that debug >>> information (caused by wlandebug and athdebug) is being printed on the >>> console. The only way to get machine's attention is to hold power button >>> for 8 seconds. >> So this is just livelock due to console debug msgs. > I am not sure, I have parsed this well enough, so I will try to clarify: > machine becomes unresponsive *without* any debugging turned on, to an > extent that pressing the power button twice *does not* generate ACPI > console message (something to the tune of "going into S5 already -- > gimme a break"). If I turn ath debugging on, I do see those messages, > and only them, scrolling on the console. Guess I misunderstood you. >>> Note: manual reassociation is just the handy way to reproduce the >>> problem -- I have had machine locking up on me the whole day long >>> completely on its own. >>> >>> Below are, what I think, relevant pieces of information. If anything is >>> missing, please, chastise me appropriately and will do my best to >>> provide. I have rigged firewire console, but am unable to break into the >>> debugger locally or remotely. >> I see no log msgs. > I am sorry -- mailman must have eaten it up -- I have posted them here > now: > > http://members.verizon.net/~akovalenko/Misc/reassoc.log.gz All I see in the log is normal scanning. > >>> While I am on the subject, I would appreciate couple of the >>> troubleshooting suggestions: >>> * is there any way to get sysctl dev.ath.0.debug to appear, other then >>> defining ATH_DEBUG in something like /usr/src/sys/dev/ath/ah_osdep.h? >> options ATH_DEBUG > That does not seem to work for if_ath built as the module, sorry for not > being clear in that respect. If you are build a module then you must edit the Makefile to add the option. Feel free to provide a patch to improve this situation. > >>> * is there minimal, but still usable mask for athdebug and wlandebug? I >>> have started with 0xFFFFFFFF and kept trimming likely high-volume >>> settings until output slowed down to the reasonable pace. >> Why do you want debug msgs from ath? The debug msgs from wlandebug >> depend on what you're trying to debug. > Because neither wpa_supplicant (quoted below), nor wlandebug (in the URL > above) gave me the answer -- it looks like we are going into the scan > with the specific SSID in mind and never come back, so I went for the > next level. However, could you, please, clarify that I understood you > correctly -- you *do not* want to see mix of wlandebug and athdebug > messages in the report, and I should turn wlandebug off before turning > athdebug on, right? wlandebug msgs are typically low duty and can be left enabled when you add driver-level debug msgs. But I can't see from the log you sent what is going on. Try reducing the noise by eliminating all the ath debug msgs; maybe provide one log w/ only wlan msgs and one w/ wlan+ath. > >> I suggest that when debugging you start from the highest layer and move >> downward. If you can't find what you need in a wpa_supplicant log then >> turn on msgs in net80211 with wlandebug. If that doesn't tell you what >> you need then move to the driver. Blindly turning everything on can >> easily livelock your system. > That's what I did -- what I have posted is the end result of the walking > down that chain, and I assumed, possibly incorrectly, that you would > want result of all three to put things in context. I do apologize for > the misunderstanding. > >> For high volume msgs I often do something >> like: >> >> athdebug +intr; sleep 1; athdebug -intr >> >> or >> >> athdebug +intr; read x; athdebug -intr >> >> so a carriage return will disable msgs. > Thank you for the suggestion. > >> >>> * what facility does wpa_supplicant use, when forced to syslog by -s >>> switch? >> trouble% cd /data/freebsd/head/contrib/wpa_supplicant/ >> trouble% grep openlog *.c >> common.c: openlog("wpa_supplicant", LOG_PID | LOG_NDELAY, LOG_DAEMON); > Thank you, should have done this myself, sorry. > From scottl at samsco.org Fri May 16 16:48:11 2008 From: scottl at samsco.org (Scott Long) Date: Fri May 16 16:48:17 2008 Subject: udf In-Reply-To: <20080516161017.GA72242@eos.sc1.parodius.com> References: <20080516154848.GA1127@faust.net> <482DB16B.2070402@moneybookers.com> <20080516161017.GA72242@eos.sc1.parodius.com> Message-ID: <482DBAC4.30101@samsco.org> Jeremy Chadwick wrote: > On Fri, May 16, 2008 at 07:08:11PM +0300, Stefan Lambrev wrote: >> From man mount_udf (FreeBSD7) >> >> HISTORY >> The mount_udf utility first appeared in FreeBSD 5.0. >> >> FreeBSD 7.0 March 23, 2002 FreeBSD >> 7.0 >> >> I have no idea for newfs_udf , and what is supposed this to do :) > > It creates a UDF (commonly DVD/DVD Audio) filesystem. NetBSD and > Solaris 10 both have this. > There is no write support in UDF in FreeBSD. When I wrote the fs code, packet writing was the only way to do discrete writes, and it's very hard to make that work with a traditional VM system. Now with DVD+R, it's probably worth someone's time to look at it (though the append-only nature of +R means that there are still some nasty VM complications to deal with). Until that happens, mkisofs can be used to create a static UDF filesystem. Scott From tom.hurst at clara.net Fri May 16 18:20:47 2008 From: tom.hurst at clara.net (Thomas Hurst) Date: Fri May 16 18:20:53 2008 Subject: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. In-Reply-To: <482BE398.8010203@ispro.net> References: <482B4DEE.3050705@ispro.net> <20080515010347.GA85202@eos.sc1.parodius.com> <482BE398.8010203@ispro.net> Message-ID: <20080516182044.GA5921@voi.aagh.net> * Evren Yurtesen (yurtesen@ispro.net) wrote: > I guess one good question is, how can one see the number of PV entries > used by a process? shouldnt these appear in the output of ipcs -a > command? No, PV entries are a VM thing, not limited to SysV IPC. > Another good question is, in many places there is references to > rebooting after putting a new vm.pmap.shpgperproc value to > loader.conf. However I just changed this on a running system, has it > really been changed or was I suppose to reboot? Looking at the code it should be fine, the limit's just a couple of integers. > In either case, I already increased vm.pmap.shpgperproc to 2000 (from > 200) and still the error occurs, there is not so much load on this > box, maybe there is a leak somewhere? What sort of load is there? Do you have a bunch of big processes sharing significant chunks of memory in any way? -- Thomas 'Freaky' Hurst http://hur.st/ From yurtesen at ispro.net Fri May 16 18:35:25 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Fri May 16 18:35:29 2008 Subject: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. In-Reply-To: <20080516182044.GA5921@voi.aagh.net> References: <482B4DEE.3050705@ispro.net> <20080515010347.GA85202@eos.sc1.parodius.com> <482BE398.8010203@ispro.net> <20080516182044.GA5921@voi.aagh.net> Message-ID: <482DD410.6090102@ispro.net> Thomas Hurst wrote: >> In either case, I already increased vm.pmap.shpgperproc to 2000 (from >> 200) and still the error occurs, there is not so much load on this >> box, maybe there is a leak somewhere? > > What sort of load is there? Do you have a bunch of big processes > sharing significant chunks of memory in any way? > How do I see what process is sharing memory and how much memory? There are a bunch of apache 2.2 processes working normally about 20-30 processes. This box doesnt do much more than that... I just checked the machine and here is what it looks like: 2:32PM up 18 days, 5:40, 3 users, load averages: 0.41, 0.36, 0.27 web:/root#ps ax |grep http 21429 ?? Ss 0:18.08 /usr/local/sbin/httpd 86473 ?? S 0:00.09 /usr/local/sbin/httpd 86659 ?? S 0:00.09 /usr/local/sbin/httpd 86851 ?? S 0:00.07 /usr/local/sbin/httpd 86857 ?? S 0:00.04 /usr/local/sbin/httpd 86912 ?? S 0:00.04 /usr/local/sbin/httpd 86918 ?? S 0:00.03 /usr/local/sbin/httpd 86919 ?? S 0:00.03 /usr/local/sbin/httpd 86996 ?? S 0:00.04 /usr/local/sbin/httpd 87023 ?? S 0:00.02 /usr/local/sbin/httpd 87028 ?? S 0:00.03 /usr/local/sbin/httpd 87059 ?? S 0:00.01 /usr/local/sbin/httpd 87060 ?? S 0:00.01 /usr/local/sbin/httpd 87062 ?? S 0:00.02 /usr/local/sbin/httpd 87065 ?? S 0:00.03 /usr/local/sbin/httpd 87074 ?? S 0:00.01 /usr/local/sbin/httpd 87076 ?? S 0:00.02 /usr/local/sbin/httpd 87077 ?? S 0:00.03 /usr/local/sbin/httpd 87079 ?? S 0:00.04 /usr/local/sbin/httpd 87081 ?? S 0:00.03 /usr/local/sbin/httpd 87083 ?? S 0:00.03 /usr/local/sbin/httpd 87085 ?? S 0:00.04 /usr/local/sbin/httpd 87090 ?? S 0:00.02 /usr/local/sbin/httpd 87190 p1 R+ 0:00.00 grep http web:/root# Although I see now that for 2 days the PV entries error did not appear. I wonder if it is spooling up somehow... There is a cron job restarting apache everyday at midnight so it cant be apache leaking perhaps. Thanks, Evren From rsmith at xs4all.nl Fri May 16 19:07:20 2008 From: rsmith at xs4all.nl (Roland Smith) Date: Fri May 16 19:07:25 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <20080516121414.GD4618@wiz.vpn.offrom.nl> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> Message-ID: <20080516190718.GA73178@slackbox.xs4all.nl> On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote: > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ar0s1a 20308398 230438 18453290 1% / > devfs 1 1 0 100% /dev > /dev/ar0s1d 21321454 3814482 15801256 19% /usr > /dev/ar0s1e 50777034 5331686 41383186 11% /var > /dev/ar0s1f 101554150 18813760 74616058 20% /home > /dev/ar0s1g 274977824 34564876 218414724 14% /share > > pretty normal I would say. Yes. > > Did you notice any file corruption in the filesystem on ar0s1g? > > No the two disks are brand new and I did not encounter any noticeable > file corruption. However I assume that nowadays bad sectors on HD are > handled by the hardware and do not need any user interaction to correct > this. But maybe I'm totally wrong. Every ATA disk has spare sectors, and they usually don't report bad blocks untill the spares are exhausted. In which case it is prudent to replace the disk. > > Unmount the filesystem and run fsck(8) on it. Does it report any errors? > > sun# fsck /dev/ar0s1g > ** /dev/ar0s1g > ** Last Mounted on /share > ** Phase 1 - Check Blocks and Sizes > INCORRECT BLOCK COUNT I=34788357 (272 should be 264) > CORRECT? [yn] y > > INCORRECT BLOCK COUNT I=34789217 (296 should be 288) > CORRECT? [yn] y > > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? [yn] y > > SUMMARY INFORMATION BAD > SALVAGE? [yn] y > > BLK(S) MISSING IN BIT MAPS > SALVAGE? [yn] y > > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 > blocks, 0.0% fragmentation) > > ***** FILE SYSTEM MARKED CLEAN ***** > > ***** FILE SYSTEM WAS MODIFIED ***** > > The usual stuff I would say. Disk corruption is never normal. It can be explained by if the machine crashed or was power-cycles before the disks were unmounted, but it can also indicate hardware troubles. > > > Any hints are very much appreciated. > So I have to conclude that the write error message does make sense and > that something seems to be wrong with the disks. The next question is > what can I do about it? Should I return the disks to the shop and ask > for new ones? Install sysutils/smartmontools, and run 'smartctl -A /dev/adX|less', where X are the numbers of the drives in the RAID array. In the output, look at the values for Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable, which is the last number that you see on each line. A small number for Reallocated_Sector_Ct is allowable. But non-zero counts for Current_Pending_Sector or Offline_Uncorrectable means it's time to get a new disk. > However other people that I have contacted and who had a similar > problem before have solved it by using software raid setup instead of a > hardware raid setup. This seems to indicate that there is some bug in > the FreeBSD code. The RAID support that you find on most desktop motherboards _is_ software RAID. See ataraid(4). Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080516/e444d986/attachment.pgp From lev at FreeBSD.org Fri May 16 19:11:10 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Fri May 16 19:11:14 2008 Subject: FreeBSD 7.0-STABLE: "mount_nfs" vs "mount -t nfs": problems with second one, UDP timeouts and ICMP ports unreach?! In-Reply-To: <482D6492.8080209@FreeBSD.org> References: <482D6492.8080209@FreeBSD.org> Message-ID: <625532066.20080516231116@serebryakov.spb.ru> Hello, freebsd-stable. You wrote 16 ??? 2008 ?., 14:40:18: > There is NO any firewalls on B. And, I repeat, it WORKS when I call > mount_nfs directly in a moment! Adding `-o -c' to mount (to pass `-c' to mount_nfs) helps. But I'm very curious WHY mount_nfs, called directly, work WITHOUT `-c'... -- // Black Lion AKA Lev Serebryakov From tom.hurst at clara.net Sat May 17 00:53:07 2008 From: tom.hurst at clara.net (Thomas Hurst) Date: Sat May 17 00:53:15 2008 Subject: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. In-Reply-To: <482DD410.6090102@ispro.net> References: <482B4DEE.3050705@ispro.net> <20080515010347.GA85202@eos.sc1.parodius.com> <482BE398.8010203@ispro.net> <20080516182044.GA5921@voi.aagh.net> <482DD410.6090102@ispro.net> Message-ID: <20080517005304.GA63122@voi.aagh.net> * Evren Yurtesen (yurtesen@ispro.net) wrote: > How do I see what process is sharing memory and how much memory? Guessing is normally sufficient; typically it's processes with the same name and similar size/res. On 7-STABLE you can use procstat -v to look at the VM mappings for a process, but typically that'll be overkill. > There are a bunch of apache 2.2 processes working normally about 20-30 > processes. This box doesnt do much more than that... > > I just checked the machine and here is what it looks like: > 2:32PM up 18 days, 5:40, 3 users, load averages: 0.41, 0.36, 0.27 > > web:/root#ps ax |grep http > 21429 ?? Ss 0:18.08 /usr/local/sbin/httpd > 86473 ?? S 0:00.09 /usr/local/sbin/httpd > 86659 ?? S 0:00.09 /usr/local/sbin/httpd > > Although I see now that for 2 days the PV entries error did not appear. I > wonder if it is spooling up somehow... They do look a bit small to be triggering it; assuming they're sharing most of that, that's still only about 400k pv entries; 5MB or so (12 bytes per entry). The systems I've seen pv entries run out on run to a couple of orders of magnitude more than that. > There is a cron job restarting apache everyday at midnight so it cant > be apache leaking perhaps. Load spikes maybe? Child count running into the stratosphere? Big PHP opcode cache? -- Thomas 'Freaky' Hurst http://hur.st/ From emikulic at gmail.com Sat May 17 05:38:33 2008 From: emikulic at gmail.com (Emil Mikulic) Date: Sat May 17 05:38:38 2008 Subject: ciss(4) not coping with large arrays? In-Reply-To: <5c0ff6a70805160119n2f8361c4y7b3c1451f36d3c6e@mail.gmail.com> References: <20080516073932.GA39803@dmr.ath.cx> <5c0ff6a70805160103o75461976wce04f697975a176c@mail.gmail.com> <5c0ff6a70805160119n2f8361c4y7b3c1451f36d3c6e@mail.gmail.com> Message-ID: <20080517053829.GA73251@dmr.ath.cx> On Fri, May 16, 2008 at 01:19:33AM -0700, Paul Saab wrote: > Emil: > > Running today's RELENG_7 (although 7.0-RELEASE has the same problem), > > GENERIC kernel on an amd64 and I can't seem to get a da(4) device for > > any arrays bigger than 2TB. > > Please try the following patch: > > http://yogurt.org/FreeBSD/ciss_large.diff This works a treat! da4 at ciss0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-5 device da4: 135.168MB/s transfers da4: 3815350MB (7813837232 512 byte sectors: 255H 32S/T 65535C) Double thanks for committing it, and for merging to RELENG_7! --Emil From Willy at Offermans.Rompen.nl Sat May 17 07:50:01 2008 From: Willy at Offermans.Rompen.nl (Willy Offermans) Date: Sat May 17 07:50:08 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <20080516190718.GA73178@slackbox.xs4all.nl> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> <20080516190718.GA73178@slackbox.xs4all.nl> Message-ID: <20080517075222.GA4250@wiz.vpn.offrom.nl> Hello Roland and FreeBSD friends, On Fri, May 16, 2008 at 09:07:18PM +0200, Roland Smith wrote: > On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote: > > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > /dev/ar0s1a 20308398 230438 18453290 1% / > > devfs 1 1 0 100% /dev > > /dev/ar0s1d 21321454 3814482 15801256 19% /usr > > /dev/ar0s1e 50777034 5331686 41383186 11% /var > > /dev/ar0s1f 101554150 18813760 74616058 20% /home > > /dev/ar0s1g 274977824 34564876 218414724 14% /share > > > > pretty normal I would say. > > Yes. > > > > Did you notice any file corruption in the filesystem on ar0s1g? > > > > No the two disks are brand new and I did not encounter any noticeable > > file corruption. However I assume that nowadays bad sectors on HD are > > handled by the hardware and do not need any user interaction to correct > > this. But maybe I'm totally wrong. > > Every ATA disk has spare sectors, and they usually don't report bad > blocks untill the spares are exhausted. In which case it is prudent to > replace the disk. > > > > Unmount the filesystem and run fsck(8) on it. Does it report any errors? > > > > sun# fsck /dev/ar0s1g > > ** /dev/ar0s1g > > ** Last Mounted on /share > > ** Phase 1 - Check Blocks and Sizes > > INCORRECT BLOCK COUNT I=34788357 (272 should be 264) > > CORRECT? [yn] y > > > > INCORRECT BLOCK COUNT I=34789217 (296 should be 288) > > CORRECT? [yn] y > > > > ** Phase 2 - Check Pathnames > > ** Phase 3 - Check Connectivity > > ** Phase 4 - Check Reference Counts > > ** Phase 5 - Check Cyl groups > > FREE BLK COUNT(S) WRONG IN SUPERBLK > > SALVAGE? [yn] y > > > > SUMMARY INFORMATION BAD > > SALVAGE? [yn] y > > > > BLK(S) MISSING IN BIT MAPS > > SALVAGE? [yn] y > > > > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 > > blocks, 0.0% fragmentation) > > > > ***** FILE SYSTEM MARKED CLEAN ***** > > > > ***** FILE SYSTEM WAS MODIFIED ***** > > > > The usual stuff I would say. > > Disk corruption is never normal. It can be explained by if the machine > crashed or was power-cycles before the disks were unmounted, but it can > also indicate hardware troubles. > > > > > Any hints are very much appreciated. > > > So I have to conclude that the write error message does make sense and > > that something seems to be wrong with the disks. The next question is > > what can I do about it? Should I return the disks to the shop and ask > > for new ones? > > Install sysutils/smartmontools, and run 'smartctl -A /dev/adX|less', where X > are the numbers of the drives in the RAID array. > > In the output, look at the values for Reallocated_Sector_Ct, > Current_Pending_Sector, Offline_Uncorrectable, which is the last number > that you see on each line. > > A small number for Reallocated_Sector_Ct is allowable. But non-zero counts > for Current_Pending_Sector or Offline_Uncorrectable means it's time to > get a new disk. sun# atacontrol status ar0 ar0: ATA RAID1 status: READY subdisks: 0 ad4 ONLINE 1 ad6 ONLINE So ad4 and ad6 are the HDs of the array. sun# smartctl -A /dev/ad6 smartctl version 5.38 [i386-portbld-freebsd7.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 3 3 Spin_Up_Time 0x0007 100 100 015 Pre-fail Always - 7232 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 31 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1478 10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 253 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 31 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 439070649 187 Reported_Uncorrect 0x0032 253 253 000 Old_age Always - 0 188 Unknown_Attribute 0x0032 253 253 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 062 060 000 Old_age Always - 38 194 Temperature_Celsius 0x0022 124 115 000 Old_age Always - 38 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 439070649 196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 202 TA_Increase_Count 0x0032 253 253 000 Old_age Always - 0 un# smartctl -A /dev/ad4 smartctl version 5.38 [i386-portbld-freebsd7.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 109 3 Spin_Up_Time 0x0007 100 100 015 Pre-fail Always - 7360 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 32 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1478 10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 253 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 31 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 835531250 187 Reported_Uncorrect 0x0032 253 253 000 Old_age Always - 0 188 Unknown_Attribute 0x0032 253 253 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 062 060 000 Old_age Always - 38 194 Temperature_Celsius 0x0022 124 118 000 Old_age Always - 38 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 835531250 196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 253 253 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 202 TA_Increase_Count 0x0032 253 253 000 Old_age Always - 0 The critical values you have mentioned are all zero, but maybe you notice some other oddities. > > > However other people that I have contacted and who had a similar > > problem before have solved it by using software raid setup instead of a > > hardware raid setup. This seems to indicate that there is some bug in > > the FreeBSD code. > > The RAID support that you find on most desktop motherboards _is_ > software RAID. See ataraid(4). Well then read motherboard supported raid instead of hardware raid! What I meant was that Toomas noticed a similar problem and turned to gmirror to ``solve'' the issue. But somewhere is something weird going on. I'm not the first one to discover this and would be nice to nail it down, so that in the future no one has to suffer anymore from this. > > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 653 27 16 23 e-mail: Willy@Offermans.Rompen.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From koitsu at FreeBSD.org Sat May 17 10:16:28 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat May 17 10:16:32 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <20080517075222.GA4250@wiz.vpn.offrom.nl> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> <20080516190718.GA73178@slackbox.xs4all.nl> <20080517075222.GA4250@wiz.vpn.offrom.nl> Message-ID: <20080517101627.GA42928@eos.sc1.parodius.com> On Sat, May 17, 2008 at 09:52:23AM +0200, Willy Offermans wrote: > sun# atacontrol status ar0 > ar0: ATA RAID1 status: READY > subdisks: > 0 ad4 ONLINE > 1 ad6 ONLINE What ataraid(4) method are you using? Promise FastTrak? Adaptec HostRAID? Intel MatrixRAID? Please let us know, as there are some known long-standing bugs with ataraid(4) that could (no guarantee) explain what's going on. > So ad4 and ad6 are the HDs of the array. > > sun# smartctl -A /dev/ad6 This excludes the brand/model of hard disks you have. Can you please tell us this? Different hard disk manufacturers do different things with SMART statistics. Your SMART statistics look okay, but depending upon what drive model and manufacturer is being used, they could be indicative of a problem. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From yurtesen at ispro.net Sat May 17 12:43:25 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Sat May 17 12:43:30 2008 Subject: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. In-Reply-To: <20080517005304.GA63122@voi.aagh.net> References: <482B4DEE.3050705@ispro.net> <20080515010347.GA85202@eos.sc1.parodius.com> <482BE398.8010203@ispro.net> <20080516182044.GA5921@voi.aagh.net> <482DD410.6090102@ispro.net> <20080517005304.GA63122@voi.aagh.net> Message-ID: <482ED30C.3030802@ispro.net> Thomas Hurst wrote: > * Evren Yurtesen (yurtesen@ispro.net) wrote: > >> How do I see what process is sharing memory and how much memory? > > Guessing is normally sufficient; typically it's processes with the same > name and similar size/res. On 7-STABLE you can use procstat -v to look > at the VM mappings for a process, but typically that'll be overkill. Thanks, I will try to check procstat -v when I start seeing the error message coming. When the system is showing "Approaching the limit on PV entries" is it related to number of allocations I see in procstat -v output? Is each line an PV entry? How can one obtain same information from 6.x i386? (just asking to compare similar systems) >> There are a bunch of apache 2.2 processes working normally about 20-30 >> processes. This box doesnt do much more than that... >> >> I just checked the machine and here is what it looks like: >> 2:32PM up 18 days, 5:40, 3 users, load averages: 0.41, 0.36, 0.27 >> >> web:/root#ps ax |grep http >> 21429 ?? Ss 0:18.08 /usr/local/sbin/httpd >> 86473 ?? S 0:00.09 /usr/local/sbin/httpd >> 86659 ?? S 0:00.09 /usr/local/sbin/httpd >> >> Although I see now that for 2 days the PV entries error did not appear. I >> wonder if it is spooling up somehow... > > They do look a bit small to be triggering it; assuming they're sharing > most of that, that's still only about 400k pv entries; 5MB or so (12 > bytes per entry). The systems I've seen pv entries run out on run to a > couple of orders of magnitude more than that. >> There is a cron job restarting apache everyday at midnight so it cant >> be apache leaking perhaps. > > Load spikes maybe? Child count running into the stratosphere? Big PHP > opcode cache? The machine is primarily serving perl pages through mod_perl2 and there are a few PHP sites too but they are negligible. It is just that I never saw this kind of message coming out on 6.3-stable i386 with the same sites which is kind of weird. However a load spike might be the cause of course, I will try to catch this when PV entry warning appear. Now that I know that procstat can show me more info, I can try to collect some info to see if something looks weird. I will let you guys know of my findings. Thanks for the great help! This information was very useful. Thanks, Evren From johan at stromnet.se Sat May 17 14:48:56 2008 From: johan at stromnet.se (=?ISO-8859-1?Q?Johan_Str=F6m?=) Date: Sat May 17 14:49:03 2008 Subject: connect(): Operation not permitted Message-ID: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> Hello I got a FreeBSD 7 machine running mail services (among other things). This machine recently replaced a FreeBSD 6.2 machine doing the same tasks. Now and then I need to send alot of mail to customers (mailing list), and one thing i've noticed now after the change is that when I use a lot of connections subsequently (high connection rate, even if they are very shortlived) inside a jail (dunno if that has anything to do with it though), I start to get Operation not permitted in return to connect(). I've seen this in the PHP app that sends mail, when it tried to connect to localhost, as well as from postfix when it have been trying to connect to amavisd on localhost, but also from postfix when it has tried to connect to remote SMTP servers. I do have PF for filtering, but there are no max-src-conn-rate limits enabled for any rules that is used for this. However, from one of the jail I do have a hfsc queue limiting the outgoing mail traffic from one jailed IP. But I'm not sure that this would be the problem, since I've also seen the problem when doing localhost connects in the jail, and also in other jails on an entierly different IP that is not affected. Does anyone have any clues about what I can look at and tune to fix this? Thanks! -- Johan Str?m Stromnet johan@stromnet.se http://www.stromnet.se/ From koitsu at FreeBSD.org Sat May 17 15:23:48 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat May 17 15:23:52 2008 Subject: connect(): Operation not permitted In-Reply-To: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> Message-ID: <20080517152348.GA64850@eos.sc1.parodius.com> On Sat, May 17, 2008 at 04:33:20PM +0200, Johan Str?m wrote: > Hello > > I got a FreeBSD 7 machine running mail services (among other things). This > machine recently replaced a FreeBSD 6.2 machine doing the same tasks. > Now and then I need to send alot of mail to customers (mailing list), and > one thing i've noticed now after the change is that when I use a lot of > connections subsequently (high connection rate, even if they are very > shortlived) inside a jail (dunno if that has anything to do with it > though), I start to get Operation not permitted in return to connect(). > I've seen this in the PHP app that sends mail, when it tried to connect to > localhost, as well as from postfix when it have been trying to connect to > amavisd on localhost, but also from postfix when it has tried to connect to > remote SMTP servers. > > I do have PF for filtering, but there are no max-src-conn-rate limits > enabled for any rules that is used for this. However, from one of the jail > I do have a hfsc queue limiting the outgoing mail traffic from one jailed > IP. But I'm not sure that this would be the problem, since I've also seen > the problem when doing localhost connects in the jail, and also in other > jails on an entierly different IP that is not affected. > > Does anyone have any clues about what I can look at and tune to fix this? Operation not permitted is most commonly seen on machines using pf(4), where there are rules blocking certain outbound traffic. I believe this has nothing to do with max-src-conn-rate. Chances are some of your pf(4) rules are wrong. There is also the possibility that jails are causing your problem. I have no experience with jails, so I cannot comment on that. I'd consider re-posting your problem to freebsd-pf@freebsd.org, and include your entire pf ruleset, so people could analyse it. Output from "pfctl -s info" would also be benefitial. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From alex at trull.org Sat May 17 15:36:54 2008 From: alex at trull.org (Alex Trull) Date: Sat May 17 15:36:59 2008 Subject: connect(): Operation not permitted In-Reply-To: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> Message-ID: <1211037564.6326.27.camel@porksoda> Hi Johan and List, In my case a few months ago it was pahu. Don't give that fine fellow an account on your precious system ! But seriously, I had a pf-firewalled jail being being used for DNS testing, with large numbers of udp "connections" hanging around in pf state. While the default udp timeout settings in PF are lower than those of the tcp timeouts, it is was still too high for it to to remove the states in time before hitting the default 10k state limit! If this is the case with you - run 'pfctl -s state | wc -l' - when there is traffic load you may see that hitting 10k states if you've not tuned that variable. What to do next - up the state limit or lower the state timeouts. I did both, to be safe. in /etc/pf.conf these must be at the very top of the file: # options # 10k is insanely low, lets raise it.. set limit { frags 16384, states 32768 } # timeouts - see 'pfctl -s timeouts' for options - you will want to # change the tcp ones rather than the udp ones for your smtp setup. # but these are mine, I set them for the dns traffic. set timeout { udp.first 15, udp.single 5, udp.multiple 30 } don't forget to: $ /etc/rc.d/pf check && ?/etc/rc.d/pf reload HTH, Alex On Sat, 2008-05-17 at 16:33 +0200, Johan Str?m wrote: > Hello > > I got a FreeBSD 7 machine running mail services (among other things). > This machine recently replaced a FreeBSD 6.2 machine doing the same > tasks. > Now and then I need to send alot of mail to customers (mailing list), > and one thing i've noticed now after the change is that when I use a > lot of connections subsequently (high connection rate, even if they > are very shortlived) inside a jail (dunno if that has anything to do > with it though), I start to get Operation not permitted in return to > connect(). > I've seen this in the PHP app that sends mail, when it tried to > connect to localhost, as well as from postfix when it have been trying > to connect to amavisd on localhost, but also from postfix when it has > tried to connect to remote SMTP servers. > > I do have PF for filtering, but there are no max-src-conn-rate limits > enabled for any rules that is used for this. However, from one of the > jail I do have a hfsc queue limiting the outgoing mail traffic from > one jailed IP. But I'm not sure that this would be the problem, since > I've also seen the problem when doing localhost connects in the jail, > and also in other jails on an entierly different IP that is not > affected. > > Does anyone have any clues about what I can look at and tune to fix > this? > > Thanks! > > -- > Johan Str?m > Stromnet > johan@stromnet.se > http://www.stromnet.se/ > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080517/32b9a1b0/attachment.pgp From Willy at Offermans.Rompen.nl Sat May 17 15:41:45 2008 From: Willy at Offermans.Rompen.nl (Willy Offermans) Date: Sat May 17 15:41:50 2008 Subject: g_vfs_done error third part--PLEASE HELP! In-Reply-To: <20080517101627.GA42928@eos.sc1.parodius.com> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> <20080516190718.GA73178@slackbox.xs4all.nl> <20080517075222.GA4250@wiz.vpn.offrom.nl> <20080517101627.GA42928@eos.sc1.parodius.com> Message-ID: <20080517154411.GA9504@wiz.vpn.offrom.nl> Hello Jeremy and FreeBSD friends, On Sat, May 17, 2008 at 03:16:27AM -0700, Jeremy Chadwick wrote: > On Sat, May 17, 2008 at 09:52:23AM +0200, Willy Offermans wrote: > > sun# atacontrol status ar0 > > ar0: ATA RAID1 status: READY > > subdisks: > > 0 ad4 ONLINE > > 1 ad6 ONLINE > > What ataraid(4) method are you using? Promise FastTrak? Adaptec > HostRAID? Intel MatrixRAID? Please let us know, as there are some > known long-standing bugs with ataraid(4) that could (no guarantee) > explain what's going on. > > > So ad4 and ad6 are the HDs of the array. > > > > sun# smartctl -A /dev/ad6 > > This excludes the brand/model of hard disks you have. Can you please > tell us this? Different hard disk manufacturers do different things > with SMART statistics. > > Your SMART statistics look okay, but depending upon what drive model and > manufacturer is being used, they could be indicative of a problem. > > -- >From /var/run/dmesg.boot: ar0: 476837MB status: READY ad4: 476940MB at ata2-master SATA150 ad6: 476940MB at ata3-master SATA150 I hope this is the information you are asking for. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 653 27 16 23 e-mail: Willy@Offermans.Rompen.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From johan at stromnet.se Sat May 17 16:01:19 2008 From: johan at stromnet.se (=?ISO-8859-1?Q?Johan_Str=F6m?=) Date: Sat May 17 16:01:26 2008 Subject: connect(): Operation not permitted In-Reply-To: <1211037564.6326.27.camel@porksoda> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> Message-ID: <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> First of all, for freebsd-pf subscribers, I posted my original problem (in the bottom) to freebsd-net earlier, but replies seems to point to PF so I'll CC there too.. On May 17, 2008, at 5:19 PM, Alex Trull wrote: > Hi Johan and List, > > In my case a few months ago it was pahu. Don't give that fine fellow > an > account on your precious system ! > > > But seriously, I had a pf-firewalled jail being being used for DNS > testing, with large numbers of udp "connections" hanging around in pf > state. While the default udp timeout settings in PF are lower than > those > of the tcp timeouts, it is was still too high for it to to remove the > states in time before hitting the default 10k state limit! > > If this is the case with you - run 'pfctl -s state | wc -l' - when > there > is traffic load you may see that hitting 10k states if you've not > tuned > that variable. > > What to do next - up the state limit or lower the state timeouts. I > did > both, to be safe. > > in /etc/pf.conf these must be at the very top of the file: > > # options > # 10k is insanely low, lets raise it.. > set limit { frags 16384, states 32768 } > # timeouts - see 'pfctl -s timeouts' for options - you will want to > # change the tcp ones rather than the udp ones for your smtp setup. > # but these are mine, I set them for the dns traffic. > set timeout { udp.first 15, udp.single 5, udp.multiple 30 } > > > don't forget to: > > $ /etc/rc.d/pf check && /etc/rc.d/pf reload Ok, looked over the PF states now, but I'm not quite sure thats what causing it. I have default limit on 10k states, normally I seem to have around ~800 states, and when I start my test script that tries to send as many mails as possible (using PHP's Pear::Mail, creating a connection, sending, disconnecting, creating new connection.. and so on), I can clearly see the PF state counter (pfctl -vsi) increase, but the script aborts with Operation not permitted way before I hit 10k, its rather around 3-4k.. If I then wait a few seconds and run the script again, I can see the number of states increase even more, and if I do this enough times I finally hit around 9700 states. But at this point (states exhausted), I don't get Operation not permitted, instead it just seems that the script blocks up a few seconds while states clear up, then continues running until it gets a Operation not permitted. So, from the above results, I cant say that it looks like its the states? Just tried to disable the altq rule now too, no changes (not that I expected one, since its on bce0 not lo0). Another thing, which might be more approriate in freebsd-pf though.. Why would it create states at all for this traffic, when my pf.conf rule is "pass on lo0 inet from $jail to $jail" (i have a block drop in rule to drop all traffic)? A check with pfctl -vsr reveals that the actual rule inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags S/SA keep state". Where did that "keep state" come from? Thanks for ideas :) > > > HTH, > > Alex > > On Sat, 2008-05-17 at 16:33 +0200, Johan Str?m wrote: >> Hello >> >> I got a FreeBSD 7 machine running mail services (among other things). >> This machine recently replaced a FreeBSD 6.2 machine doing the same >> tasks. >> Now and then I need to send alot of mail to customers (mailing list), >> and one thing i've noticed now after the change is that when I use a >> lot of connections subsequently (high connection rate, even if they >> are very shortlived) inside a jail (dunno if that has anything to do >> with it though), I start to get Operation not permitted in return to >> connect(). >> I've seen this in the PHP app that sends mail, when it tried to >> connect to localhost, as well as from postfix when it have been >> trying >> to connect to amavisd on localhost, but also from postfix when it has >> tried to connect to remote SMTP servers. >> >> I do have PF for filtering, but there are no max-src-conn-rate limits >> enabled for any rules that is used for this. However, from one of the >> jail I do have a hfsc queue limiting the outgoing mail traffic from >> one jailed IP. But I'm not sure that this would be the problem, since >> I've also seen the problem when doing localhost connects in the jail, >> and also in other jails on an entierly different IP that is not >> affected. >> >> Does anyone have any clues about what I can look at and tune to fix >> this? >> >> Thanks! >> >> -- >> Johan Str?m >> Stromnet >> johan@stromnet.se >> http://www.stromnet.se/ >> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >> " From fbsd-ml at scrapper.ca Sat May 17 19:18:19 2008 From: fbsd-ml at scrapper.ca (Norbert Papke) Date: Sat May 17 19:18:23 2008 Subject: Apache seg faults -- Possible problem with libc? Message-ID: <200805171118.16482.fbsd-ml@scrapper.ca> Environment: FreeBSD 7.0 Stable (as of Apr 30), apache-2.0.63 I am experiencing Apache crashes on a fairly consistent and frequent basis. The crash occurs in strncmp(). To help with the diagnosis, I have rebuilt libc with debug symbols. Here is a typical stack dump: #0 strncmp () at /usr/src/lib/libc/i386/string/strncmp.S:69 #1 0x2832558c in getenv (name=0x28338648 "TZ") at /usr/src/lib/libc/stdlib/getenv.c:144 #2 0x2830ce3a in tzset_basic (rdlocked=0) at /usr/src/lib/libc/stdtime/localtime.c:1013 #3 0x2830d42f in localtime (timep=0xbfbfc1d4) at /usr/src/lib/libc/stdtime/localtime.c:1158 #4 0x28220e6c in explode_time () from /usr/local/lib/apache2/libapr-0.so.9 #5 0x28220f13 in apr_time_exp_lt () from /usr/local/lib/apache2/libapr-0.so.9 #6 0x08070227 in cached_explode () #7 0x28374519 in log_request_time () from /usr/local/libexec/apache2/mod_log_config.so #8 0x2837358d in config_log_transaction () from /usr/local/libexec/apache2/mod_log_config.so #9 0x28373654 in multi_log_transaction () from /usr/local/libexec/apache2/mod_log_config.so #10 0x08074519 in ap_run_log_transaction () #11 0x08063d62 in ap_process_request () #12 0x0805e718 in ap_process_http_connection () #13 0x08070817 in ap_run_process_connection () #14 0x08064fde in child_main () #15 0x08065283 in make_child () #16 0x08065a51 in ap_mpm_run () #17 0x0806bfb8 in main () Frames 0 - 4 are present in all crash scenarios. However, similar crashes occur with different paths into explode_time(). (gdb) frame 0 #0 strncmp () at /usr/src/lib/libc/i386/string/strncmp.S:69 69 movb (%eax),%bl (gdb) p/x $eax $70 = 0x883a4bc (gdb) p/x *$eax Cannot access memory at address 0x883a4bc eax contains the first string to be compared. This is an invalid memory location. (gdb) frame 1 #1 0x2832558c in getenv (name=0x28338648 "TZ") at /usr/src/lib/libc/stdlib/getenv.c:144 144 if (strncmp(nameValue, name, nameLen) == 0 && nameValue[nameLen] == '=') Current language: auto; currently c (gdb) p envVarsTotal $71 = 57 (gdb) p envVars[56] $72 = {nameLen = 4294967295, valueSize = 4294967295, name = 0x883a4bc
, value = 0x0, active = true, putenv = true} (gdb) p envVars[55] $73 = {nameLen = 16, valueSize = 4, name = 0x8303f20 "KDE_FULL_SESSION=true", value = 0x8303f31 "true", active = true, putenv = false} Because of the inline functions used in getenv(), gdb's location information is somewhat incomplete. However, I believe that line 144 was called by __findenv(), The fault occurs when __findenv() tries to access what appears to be an invalid environment variable. Most likely, envVarsTotal is too big by one. For reference, here is the code for __findenv(). The calling line is marked. static inline char * __findenv(const char *name, size_t nameLen, int *envNdx, bool onlyActive) { int ndx; /* * Find environment variable from end of array (more likely to be * active). A variable created by putenv is always active or it is not * tracked in the array. */ for (ndx = *envNdx; ndx >= 0; ndx--) if (envVars[ndx].putenv) { /* ==> */ if (strncmpeq(envVars[ndx].name, name, nameLen)) { *envNdx = ndx; return (envVars[ndx].name + nameLen + sizeof ("=") - 1); } } else if ((!onlyActive || envVars[ndx].active) && (envVars[ndx].nameLen == nameLen && strncmpeq(envVars[ndx].name, name, nameLen))) { *envNdx = ndx; return (envVars[ndx].value); } return (NULL); } which is called by char * getenv(const char *name) { int envNdx; size_t nameLen; /* Check for malformed name. */ if (name == NULL || (nameLen = __strleneq(name)) == 0) { errno = EINVAL; return (NULL); } /* * Find environment variable via environ if no changes have been made * via a *env() call or environ has been replaced by a running program, * otherwise, use the rebuilt environment. */ if (envVars == NULL || environ != intEnviron) return (__findenv_environ(name, nameLen)); else { envNdx = envVarsTotal - 1; /* ==> */ return (__findenv(name, nameLen, &envNdx, true)); } } Any suggestions on how I could nail down the cause? Cheers, -- Norbert. From m.seaman at infracaninophile.co.uk Sun May 18 07:19:37 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Sun May 18 07:19:41 2008 Subject: connect(): Operation not permitted In-Reply-To: <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> Message-ID: <482FD877.6050707@infracaninophile.co.uk> Johan Str?m wrote: > drop all traffic)? A check with pfctl -vsr reveals that the actual rule > inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 > flags S/SA keep state". Where did that "keep state" come from? 'flags S/SA keep state' is the default now for tcp filter rules -- that was new in 7.0 reflecting the upstream changes made between the 4.0 and 4.1 releases of OpenBSD. If you want a stateless rule, append 'no state'. http://www.openbsd.org/faq/pf/filter.html#state Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080518/3ba12348/signature.pgp From smithi at nimnet.asn.au Sun May 18 07:26:48 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun May 18 07:26:54 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: Message-ID: On Fri, 16 May 2008, Vivek Khera wrote: > How are the buckets used? Are they hashed per rule number or some > other mechanism? Nearly all of my states are from the same rule (eg, > on a mail server for the SMTP port rule). /sys/netinet/ip_fw.h /sys/netinet/ip_fw2.c Hashed per flow, (srcip^destip^srcport^dstport) mod curr_dyn_buckets, so packets for both directions of a given flow hash to the same bucket. In the case you mention, you could likely expect reasonable distribution by src_ip/src_port. The rule number doesn't contribute to the hash, but is contained in the dynamic rule entry, ie a matched flow resolves to its rule at the first check_state or keep_state rule encountered. Try searching for '_STATE'. Each bucket just contains a pointer, so on i386 I'd expect 1KB per 256 buckets, see realloc_dynamic_table. The 'pointees', ipfw_dyn_rule, are around 70? bytes each with 32-bit pointers, so 4K current dynamic rules should use around 280KB? Somebody yell if I'm badly miscalculating .. > How should I scale the buckets with the max rules? The default seems > to be 4096 rules and 256 buckets. Should I maintain that ratio? Sounds reasonable. Extra buckets look cheap, if I'm reading it right, and memory otherwise appears to be only allocated on use, per new flow, but I'm ignorant of any other memory allocation overheads. caveats: 5.5 sources; C is read-only here; not subscribed to -ipfw cheers, Ian From johan at stromnet.se Sun May 18 10:33:58 2008 From: johan at stromnet.se (=?ISO-8859-1?Q?Johan_Str=F6m?=) Date: Sun May 18 10:34:05 2008 Subject: connect(): Operation not permitted In-Reply-To: <482FD877.6050707@infracaninophile.co.uk> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> Message-ID: On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: > Johan Str?m wrote: > >> drop all traffic)? A check with pfctl -vsr reveals that the actual >> rule inserted is "pass on lo0 inet from 123.123.123.123 to >> 123.123.123.123 flags S/SA keep state". Where did that "keep state" >> come from? > > 'flags S/SA keep state' is the default now for tcp filter rules -- > that > was new in 7.0 reflecting the upstream changes made between the 4.0 > and 4.1 > releases of OpenBSD. If you want a stateless rule, append 'no state'. > > http://www.openbsd.org/faq/pf/filter.html#state Thanks! I was actually looking around in the pf.conf manpage but failed to find it yesterday, but looking closer today I now saw it. Applied the no state (and quick) to the rule, and now no state is created. And the problem I had in the first place seems to have been resolved too now, even though it didn't look like a state problem.. (started to deny new connections much earlier than the states was full, altough maybee i wasnt looking for updates fast enough or something). Anyways, thanks to all helping me out, and of course thanks to everybody involved in FreeBSD/pf and all for great products! Cannot be said enough times ;) From joao at matik.com.br Sun May 18 13:57:24 2008 From: joao at matik.com.br (JoaoBR) Date: Sun May 18 13:57:29 2008 Subject: possible zfs bug? lost all pools Message-ID: <200805180956.18211.joao@matik.com.br> after trying to mount my zfs pools in single user mode I got the following message for each: May 18 09:09:36 gw kernel: ZFS: WARNING: pool 'cache1' could not be loaded as it was last accessed by another system (host: gw.bb1.matik.com.br hostid: 0xbefb4a0f). See: http://www.sun.com/msg/ZFS-8000-EY any zpool cmd returned nothing else as not existing zfs, seems the zfs info on disks was gone to double-check I recreated them, rebooted in single user mode and repeated the story, same thing, trying to /etc/rc.d/zfs start returnes the above msg and pools are gone ... I guess this is kind of wrong -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From freebsd at byshenk.net Sun May 18 14:11:41 2008 From: freebsd at byshenk.net (Greg Byshenk) Date: Sun May 18 14:11:45 2008 Subject: possible zfs bug? lost all pools In-Reply-To: <200805180956.18211.joao@matik.com.br> References: <200805180956.18211.joao@matik.com.br> Message-ID: <20080518141138.GD808@core.byshenk.net> On Sun, May 18, 2008 at 09:56:17AM -0300, JoaoBR wrote: > after trying to mount my zfs pools in single user mode I got the following > message for each: > > May 18 09:09:36 gw kernel: ZFS: WARNING: pool 'cache1' could not be loaded as > it was last accessed by another system (host: gw.bb1.matik.com.br hostid: > 0xbefb4a0f). See: http://www.sun.com/msg/ZFS-8000-EY > > any zpool cmd returned nothing else as not existing zfs, seems the zfs info on > disks was gone > > to double-check I recreated them, rebooted in single user mode and repeated > the story, same thing, trying to /etc/rc.d/zfs start returnes the above msg > and pools are gone ... > > I guess this is kind of wrong I think that the problem is related to the absence of a hostid when in single-user. Try running '/etc/rc.d/hostid start' before mouning. http://lists.freebsd.org/pipermail/freebsd-current/2007-July/075001.html -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From torfinn.ingolfsen at broadpark.no Sun May 18 14:13:06 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sun May 18 14:13:10 2008 Subject: possible zfs bug? lost all pools In-Reply-To: <200805180956.18211.joao@matik.com.br> References: <200805180956.18211.joao@matik.com.br> Message-ID: <20080518161253.019d1721.torfinn.ingolfsen@broadpark.no> On Sun, 18 May 2008 09:56:17 -0300 JoaoBR wrote: > after trying to mount my zfs pools in single user mode I got the > following message for each: > > May 18 09:09:36 gw kernel: ZFS: WARNING: pool 'cache1' could not be > loaded as it was last accessed by another system (host: > gw.bb1.matik.com.br hostid: 0xbefb4a0f). See: > http://www.sun.com/msg/ZFS-8000-EY Did you run '/etc/rc.d.hostid start' first? IIRC, it is needed before zfs will mount in single-user mode. HTH -- Regards, Torfinn Ingolfsen From daniel at skytek.it Sun May 18 14:28:31 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun May 18 14:28:36 2008 Subject: Disk access/MPT under ESX3.5 Message-ID: <48303A1B.9000103@skytek.it> Hello, i'm running some tests with FreeBSD6.3 and FreeBSD7-Stable, using both AMD64 and I386 arch with both schedulers (ULE and 4BSD) on VmWare ESX3.5 server. Everything runs almost fine, except for disk access. Performance is quite OK (around 60mb/sec), but when accessing disks, System (kernel) CPU load goes up to 70%. This doesn't look normal. The same behavior is present on all test configurations. monitor# dmesg | grep mpt mpt0: port 0x1080-0x10ff mem 0xf4810000-0xf4810fff irq 17 at device 16.0 on pci0 mpt0: [ITHREAD] mpt0: MPI Version=1.2.0.0 da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 3.300MB/s transfers da0: Command Queueing Enabled da0: 34816MB (71303168 512 byte sectors: 255H 63S/T 4438C) Any suggestions? Thanks, Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From joao at matik.com.br Sun May 18 15:17:56 2008 From: joao at matik.com.br (JoaoBR) Date: Sun May 18 15:18:03 2008 Subject: possible zfs bug? lost all pools In-Reply-To: <20080518141138.GD808@core.byshenk.net> References: <200805180956.18211.joao@matik.com.br> <20080518141138.GD808@core.byshenk.net> Message-ID: <200805181220.33599.joao@matik.com.br> On Sunday 18 May 2008 11:11:38 Greg Byshenk wrote: > On Sun, May 18, 2008 at 09:56:17AM -0300, JoaoBR wrote: > > after trying to mount my zfs pools in single user mode I got the > > following message for each: > > > > May 18 09:09:36 gw kernel: ZFS: WARNING: pool 'cache1' could not be > > loaded as it was last accessed by another system (host: > > gw.bb1.matik.com.br hostid: 0xbefb4a0f). See: > > http://www.sun.com/msg/ZFS-8000-EY > > > > any zpool cmd returned nothing else as not existing zfs, seems the zfs > > info on disks was gone > > > > to double-check I recreated them, rebooted in single user mode and > > repeated the story, same thing, trying to /etc/rc.d/zfs start returnes > > the above msg and pools are gone ... > > > > I guess this is kind of wrong > > I think that the problem is related to the absence of a hostid when in > single-user. Try running '/etc/rc.d/hostid start' before mouning. > well, obviously that came to my mind after seeing the msg ... anyway the pools should not vanish don't you agree? and if necessary /etc/rc.d/zfs should start hostid or at least set REQUIRE different and warn thank's -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From koitsu at FreeBSD.org Sun May 18 15:39:11 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun May 18 15:39:15 2008 Subject: possible zfs bug? lost all pools In-Reply-To: <200805181220.33599.joao@matik.com.br> References: <200805180956.18211.joao@matik.com.br> <20080518141138.GD808@core.byshenk.net> <200805181220.33599.joao@matik.com.br> Message-ID: <20080518153911.GA22300@eos.sc1.parodius.com> On Sun, May 18, 2008 at 12:20:33PM -0300, JoaoBR wrote: > On Sunday 18 May 2008 11:11:38 Greg Byshenk wrote: > > On Sun, May 18, 2008 at 09:56:17AM -0300, JoaoBR wrote: > > > after trying to mount my zfs pools in single user mode I got the > > > following message for each: > > > > > > May 18 09:09:36 gw kernel: ZFS: WARNING: pool 'cache1' could not be > > > loaded as it was last accessed by another system (host: > > > gw.bb1.matik.com.br hostid: 0xbefb4a0f). See: > > > http://www.sun.com/msg/ZFS-8000-EY > > > > > > any zpool cmd returned nothing else as not existing zfs, seems the zfs > > > info on disks was gone > > > > > > to double-check I recreated them, rebooted in single user mode and > > > repeated the story, same thing, trying to /etc/rc.d/zfs start returnes > > > the above msg and pools are gone ... > > > > > > I guess this is kind of wrong > > > > I think that the problem is related to the absence of a hostid when in > > single-user. Try running '/etc/rc.d/hostid start' before mouning. > > well, obviously that came to my mind after seeing the msg ... > > anyway the pools should not vanish don't you agree? > > and if necessary /etc/rc.d/zfs should start hostid or at least set REQUIRE > different and warn I've been in the same boat you are, and I was told the same thing. I've documented the situation on my Wiki, and the necessary workarounds. http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues This sort of thing needs to get hammered out before ZFS can be considered "usable" from a system administration perspective. Expecting people to remember to run an rc.d startup script before they can use any of their filesystems borders on unrealistic. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kian.mohageri at gmail.com Sun May 18 17:56:24 2008 From: kian.mohageri at gmail.com (Kian Mohageri) Date: Sun May 18 17:56:28 2008 Subject: connect(): Operation not permitted In-Reply-To: References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> Message-ID: On Sun, May 18, 2008 at 3:33 AM, Johan Str?m wrote: > On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: > >> Johan Str?m wrote: >> >>> drop all traffic)? A check with pfctl -vsr reveals that the actual rule >>> inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags >>> S/SA keep state". Where did that "keep state" come from? >> >> 'flags S/SA keep state' is the default now for tcp filter rules -- that >> was new in 7.0 reflecting the upstream changes made between the 4.0 and >> 4.1 >> releases of OpenBSD. If you want a stateless rule, append 'no state'. >> >> http://www.openbsd.org/faq/pf/filter.html#state > > Thanks! I was actually looking around in the pf.conf manpage but failed to > find it yesterday, but looking closer today I now saw it. > Applied the no state (and quick) to the rule, and now no state is created. > And the problem I had in the first place seems to have been resolved too > now, even though it didn't look like a state problem.. (started to deny new > connections much earlier than the states was full, altough maybee i wasnt > looking for updates fast enough or something). > I'd be willing to bet it's because you're reusing the source port on a new connection before the old state expires. You'll know if you check the state-mismatch counter. Anyway, glad you found a resolution. -Kian From joao at matik.com.br Sun May 18 18:12:39 2008 From: joao at matik.com.br (JoaoBR) Date: Sun May 18 18:12:44 2008 Subject: possible zfs bug? lost all pools In-Reply-To: <20080518153911.GA22300@eos.sc1.parodius.com> References: <200805180956.18211.joao@matik.com.br> <200805181220.33599.joao@matik.com.br> <20080518153911.GA22300@eos.sc1.parodius.com> Message-ID: <200805181511.56646.joao@matik.com.br> On Sunday 18 May 2008 12:39:11 Jeremy Chadwick wrote: > On Sun, May 18, 2008 at 12:20:33PM -0300, JoaoBR wrote: > > On Sunday 18 May 2008 11:11:38 Greg Byshenk wrote: > > > On Sun, May 18, 2008 at 09:56:17AM -0300, JoaoBR wrote: > > > > after trying to mount my zfs pools in single user mode I got the > > > > following message for each: > > > > > > > > May 18 09:09:36 gw kernel: ZFS: WARNING: pool 'cache1' could not be > > > > loaded as it was last accessed by another system (host: > > > > gw.bb1.matik.com.br hostid: 0xbefb4a0f). See: > > > > http://www.sun.com/msg/ZFS-8000-EY > > > > > > > > any zpool cmd returned nothing else as not existing zfs, seems the > > > > zfs info on disks was gone > > > > > > > > to double-check I recreated them, rebooted in single user mode and > > > > repeated the story, same thing, trying to /etc/rc.d/zfs start > > > > returnes the above msg and pools are gone ... > > > > > > > > I guess this is kind of wrong > > > > > > I think that the problem is related to the absence of a hostid when in > > > single-user. Try running '/etc/rc.d/hostid start' before mouning. > > > > well, obviously that came to my mind after seeing the msg ... > > > > anyway the pools should not vanish don't you agree? > > > > and if necessary /etc/rc.d/zfs should start hostid or at least set > > REQUIRE different and warn > > I've been in the same boat you are, and I was told the same thing. I've > documented the situation on my Wiki, and the necessary workarounds. > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > nice work this page, thanks > This sort of thing needs to get hammered out before ZFS can be > considered "usable" from a system administration perspective. Expecting > people to remember to run an rc.d startup script before they can use any > of their filesystems borders on unrealistic. yes but on the other side we know it is new stuff and sometimes the price is what happens to me this morning but then it also helps to make things better anyway, a little fix to rc.d/zfs like if [ ! "`sysctl -n kern.hostiid 2>/dev/null`" ]; then echo "zfs needs hostid first"; exit 0; fi or something as precmd or first in zfs_start_main should fix this issue talking about there are more things, I experienced still not working swapon|off from rc.d/zfs script does not work either not sure what it is because same part of script run as root works, adding a dash to #!/bin/sh does not help either, from rc.d/zfs the state returns a dash do not see sense in rc.d/zfs `zfs share` since it is the default when sharenfs property is enabled man page tipo tells swap -a ... not swapon -a subcommands volini and volfini not in manual at all man page thar zfs can not be a dump device, not sure if I understand it as meant but I can dump to zfs very well and fast as long as recordsize=128 but at the end, for the short time zfs is there it gives me respectable performance results and it is stable for me as well -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From cliftonr at lava.net Sun May 18 18:28:30 2008 From: cliftonr at lava.net (Clifton Royston) Date: Sun May 18 18:28:34 2008 Subject: Disk access/MPT under ESX3.5 In-Reply-To: <48303A1B.9000103@skytek.it> References: <48303A1B.9000103@skytek.it> Message-ID: <20080518182827.GA18109@lava.net> On Sun, May 18, 2008 at 04:15:55PM +0200, Daniel Ponticello wrote: > Hello, > i'm running some tests with FreeBSD6.3 and FreeBSD7-Stable, using both > AMD64 and I386 arch > with both schedulers (ULE and 4BSD) on VmWare ESX3.5 server. > Everything runs almost fine, except for disk access. Performance is > quite OK (around 60mb/sec), > but when accessing disks, System (kernel) CPU load goes up to 70%. This > doesn't look > normal. The same behavior is present on all test configurations. ... > da0 at mpt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 3.300MB/s transfers > da0: Command Queueing Enabled > da0: 34816MB (71303168 512 byte sectors: 255H 63S/T 4438C) > > Any suggestions? If you are accessing a software emulation of a SCSI disk, I would offhand expect the CPU load to go up substantially when you are reading or writing it at the maximum achievable bandwidth. You can't expect normal relative load results under an emulator, and while most application or kernel code runs natively, I/O under VMWare will zoom in and out of the emulator a lot. I'm afraid I can't give you a definitive answer as I have VMWare but haven't set up FreeBSD under it yet. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From fbsd-ml at scrapper.ca Sun May 18 20:05:14 2008 From: fbsd-ml at scrapper.ca (Norbert Papke) Date: Sun May 18 20:05:18 2008 Subject: Apache seg faults -- Possible problem with libc? [solved] In-Reply-To: <200805171118.16482.fbsd-ml@scrapper.ca> References: <200805171118.16482.fbsd-ml@scrapper.ca> Message-ID: <200805181305.10243.fbsd-ml@scrapper.ca> On May 17, 2008, Norbert Papke wrote: > Environment: FreeBSD 7.0 Stable (as of Apr 30), apache-2.0.63 > > I am experiencing Apache crashes on a fairly consistent and frequent basis. > The crash occurs in strncmp(). To help with the diagnosis, I have rebuilt > libc with debug symbols. Here is a typical stack dump: > > #0 strncmp () at /usr/src/lib/libc/i386/string/strncmp.S:69 > #1 0x2832558c in getenv (name=0x28338648 "TZ") > at /usr/src/lib/libc/stdlib/getenv.c:144 > #2 0x2830ce3a in tzset_basic (rdlocked=0) > at /usr/src/lib/libc/stdtime/localtime.c:1013 > #3 0x2830d42f in localtime (timep=0xbfbfc1d4) > at /usr/src/lib/libc/stdtime/localtime.c:1158 The problem is not in libc. Instead it is caused by Apache's PHP5 module. Under certain circumstances, the module will allocate memory for an environment variable, pass this variable to putenv(), and then immediately free the memory. putenv(), of course, requires the environment variable to remain valid. The seg fault occurs at a subsequent getenv() invocation. I have contacted the PHP5 maintainer with this information. Best, -- Norbert. From daniel at skytek.it Sun May 18 20:45:13 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun May 18 20:45:16 2008 Subject: Disk access/MPT under ESX3.5 In-Reply-To: <20080518182827.GA18109@lava.net> References: <48303A1B.9000103@skytek.it> <20080518182827.GA18109@lava.net> Message-ID: <4830956A.80000@skytek.it> Clifton Royston ha scritto: > > If you are accessing a software emulation of a SCSI disk, I would > offhand expect the CPU load to go up substantially when you are reading > or writing it at the maximum achievable bandwidth. You can't expect > normal relative load results under an emulator, and while most > application or kernel code runs natively, I/O under VMWare will zoom in > and out of the emulator a lot. I'm afraid I can't give you a > definitive answer as I have VMWare but haven't set up FreeBSD under it > yet. > > -- Clifton > Thanks Clifton, my problem is that system (console) becomes very unresponsive when I/O is writing at maximum bandwidth. Anyway, system becomes more responsive when using ULE scheduler instead of 4BSD during I/O. Is there a way to limit the maximum I/O bandwidth used by the controller? Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From peter at pean.org Sun May 18 21:07:53 2008 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Sun May 18 21:07:58 2008 Subject: Packet-corruption with re(4) In-Reply-To: <20080429120834.GB44737@eos.sc1.parodius.com> References: <20080429120834.GB44737@eos.sc1.parodius.com> Message-ID: On Apr 29, 2008, at 2:08 PM, Jeremy Chadwick wrote: >> > > > I'd recommend staying away from Realtek NICs. Pick up an Intel Pro/ > 1000 > GT or PT. Realtek has a well-known history of issues. > > Just wanted to tell you guys that so far a em(4) seems to have fixed the problem. -- Peter Ankerst?l peter@pean.org From zbeeble at gmail.com Mon May 19 00:40:21 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Mon May 19 00:40:24 2008 Subject: Status of ZFS in -stable? In-Reply-To: <20080514223515.84553317.ubm@u-boot-man.de> References: <48291889.8030406@pldrouin.net> <20080514223515.84553317.ubm@u-boot-man.de> Message-ID: <5f67a8c40805181740v6f655fdjdfaec3312681b5c9@mail.gmail.com> On Wed, May 14, 2008 at 4:35 PM, Marc UBM Bocklet wrote: > On Tue, 13 May 2008 00:26:49 -0400 > Pierre-Luc Drouin wrote: > > > I would like to know if the memory allocation problem with zfs has > > been fixed in -stable? Is zfs considered to be more "stable" now? > > > > Thanks! > > Pierre-Luc Drouin > > We just set up a zfs based fileserver in our home. It's accessed via > samba and ftp, connected via an em 1gb card. > FreeBSD is installed on an 80GB ufs2 disk, the zpool consists of two > 750GB disks, set up as raidz (my mistake, mirror would probably have > been the better choice). > We've been using it for about 2 weeks now and there have been no > problems (transferred lots of big and small files off/on it, maxing out > disk speed). For standard filestore, Samba/NFS has worked fine. However, when using Norton Ghost to make backup snapshots, the files (on ZFS) come out corrupt.They are not corrupt on UFS backed SAMBA service. From chat95 at mac.com Mon May 19 03:21:36 2008 From: chat95 at mac.com (Maho NAKATA) Date: Mon May 19 03:22:02 2008 Subject: Auto bridge for qemu network In-Reply-To: <6601D6DC-AD09-4028-A25A-59899C9A57E4@gmail.com> References: <20080513054223.2CAC95B4B@mail.bitblocks.com> <6601D6DC-AD09-4028-A25A-59899C9A57E4@gmail.com> Message-ID: <20080519.115646.189719592.chat95@mac.com> From: bazzoola Subject: Auto bridge for qemu network [was: kqemu support: not compiled] Date: Thu, 15 May 2008 03:06:25 -0400 > Also, is it possible to update this page, it has some outdated info: > http://people.freebsd.org/~maho/qemu/qemu.html > *It is the 1st answer from google when asked "freebsd qemu" Sorry i have been very lazy for this ... I'll update (migrate to wiki) hopefully soon... -- Nakata Maho http://accc.riken.jp/maho/ From spork at bway.net Mon May 19 04:22:50 2008 From: spork at bway.net (Charles Sprickman) Date: Mon May 19 04:23:09 2008 Subject: possible zfs bug? lost all pools In-Reply-To: <20080518161253.019d1721.torfinn.ingolfsen@broadpark.no> References: <200805180956.18211.joao@matik.com.br> <20080518161253.019d1721.torfinn.ingolfsen@broadpark.no> Message-ID: On Sun, 18 May 2008, Torfinn Ingolfsen wrote: > On Sun, 18 May 2008 09:56:17 -0300 > JoaoBR wrote: > >> after trying to mount my zfs pools in single user mode I got the >> following message for each: >> >> May 18 09:09:36 gw kernel: ZFS: WARNING: pool 'cache1' could not be >> loaded as it was last accessed by another system (host: >> gw.bb1.matik.com.br hostid: 0xbefb4a0f). See: >> http://www.sun.com/msg/ZFS-8000-EY > > Did you run '/etc/rc.d.hostid start' first? > IIRC, it is needed before zfs will mount in single-user mode. Just curious, as I've been wanting to fiddle around with ZFS in my spare time... what is the solution here if you have failed hardware and you want to move your ZFS disks to another system (with a different host id)? Thanks, Charles > HTH > -- > Regards, > Torfinn Ingolfsen > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From shino at fornext.org Mon May 19 04:22:51 2008 From: shino at fornext.org (Shunsuke SHINOMIYA) Date: Mon May 19 04:23:10 2008 Subject: Disk access/MPT under ESX3.5 In-Reply-To: <48303A1B.9000103@skytek.it> References: <48303A1B.9000103@skytek.it> Message-ID: <20080519130031.8978.A2D40D1E@fornext.org> > da0 at mpt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 3.300MB/s transfers > da0: Command Queueing Enabled > da0: 34816MB (71303168 512 byte sectors: 255H 63S/T 4438C) Can you re-negotiate transfer rate, using camcontrol? `camcontrol negotiate 0:0 -W 16' might improve that transfer settings. camcontrol needs passthrough device support in a kernel. -- Shunsuke SHINOMIYA From kometen at gmail.com Mon May 19 06:56:52 2008 From: kometen at gmail.com (Claus Guttesen) Date: Mon May 19 06:56:55 2008 Subject: possible zfs bug? lost all pools In-Reply-To: References: <200805180956.18211.joao@matik.com.br> <20080518161253.019d1721.torfinn.ingolfsen@broadpark.no> Message-ID: >> Did you run '/etc/rc.d.hostid start' first? >> IIRC, it is needed before zfs will mount in single-user mode. > > Just curious, as I've been wanting to fiddle around with ZFS in my spare > time... what is the solution here if you have failed hardware and you want > to move your ZFS disks to another system (with a different host id)? 'zpool import' possible with a -f. man 1m zpool. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From admin at gyrec.cz Mon May 19 07:14:34 2008 From: admin at gyrec.cz (Karel Rous) Date: Mon May 19 07:14:38 2008 Subject: ubench on v6 a v7 Message-ID: <48312000.9030102@gyrec.cz> My home computer (no internet access, cannot share results :-) is single processor Athlon 64 on 2250 Mhz/512 KB L2. Visually I have seen that on stable it doesn't behave as speedily as on FreeBSD number 6. I have checked utility in subject (which is probably not the best alternative) and it shows me on memory test half of the speed that was in v6 while using default MALLOC_OPTIONS at each version. There could be certain speed up changing it but IMHO there can not be any we to make it as fast as in previous version. Is there anyone who could make a logical explanation? (I think it has something to do with new malloc optimization for multi processor systems but I might compiled also libc on FreeBSD 7 with wrong options). Even using simple compat6x libc (with libmap.conf) helps to speed up things there. All those measurement are my just my non generalized opinion and I hope I am wrong :-) Karel From daniel at skytek.it Mon May 19 09:02:34 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Mon May 19 09:02:36 2008 Subject: Disk access/MPT under ESX3.5 In-Reply-To: <20080519130031.8978.A2D40D1E@fornext.org> References: <48303A1B.9000103@skytek.it> <20080519130031.8978.A2D40D1E@fornext.org> Message-ID: <48314227.3080101@skytek.it> Hello, monitor# camcontrol negotiate 0:0 -W 16 Current Parameters: (pass0:mpt0:0:0:0): sync parameter: 0 (pass0:mpt0:0:0:0): offset: 0 (pass0:mpt0:0:0:0): bus width: 8 bits (pass0:mpt0:0:0:0): disconnection is enabled (pass0:mpt0:0:0:0): tagged queueing is enabled monitor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 32.421679 secs (32341817 bytes/sec) monitor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 20.355797 secs (51512402 bytes/sec) No improvements. But it looks like it did not renegotiated the transfers data rate that for some odd reasons are setted as 3.3MB/S instead of 320mb/s. I made some tests using linux 2.18 (debian): debiantest:/home/daniel# uname -a Linux debiantest 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686 GNU/Linux scsi0 : ioc0: LSI53C1030, FwRev=00000000h, Ports=1, MaxQ=128, IRQ=169 Vendor: VMware Model: Virtual disk Rev: 1.0 Type: Direct-Access ANSI SCSI revision: 02 target0:0:0: Beginning Domain Validation target0:0:0: Domain Validation skipping write tests target0:0:0: Ending Domain Validation target0:0:0: FAST-160 WIDE SCSI 320.0 MB/s DT IU RDSTRM RTI WRFLOW PCOMP (6.25 ns, offset 127) debiantest:/home/daniel# dd if=/dev/zero of=dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 5.01316 seconds, 209 MB/s =( Shunsuke SHINOMIYA ha scritto: >> da0 at mpt0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-2 device >> da0: 3.300MB/s transfers >> da0: Command Queueing Enabled >> da0: 34816MB (71303168 512 byte sectors: 255H 63S/T 4438C) >> > > Can you re-negotiate transfer rate, using camcontrol? > `camcontrol negotiate 0:0 -W 16' might improve that transfer settings. > > camcontrol needs passthrough device support in a kernel. > > > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From shino at fornext.org Mon May 19 09:30:51 2008 From: shino at fornext.org (Shunsuke SHINOMIYA) Date: Mon May 19 09:30:55 2008 Subject: Disk access/MPT under ESX3.5 In-Reply-To: <48314227.3080101@skytek.it> References: <20080519130031.8978.A2D40D1E@fornext.org> <48314227.3080101@skytek.it> Message-ID: <20080519181606.897C.A2D40D1E@fornext.org> Hello, Daniel Can you execute camcontrol with some parameters again? For example, `camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000'. -- Shunsuke SHINOMIYA From daniel at skytek.it Mon May 19 10:31:43 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Mon May 19 10:31:48 2008 Subject: Disk access/MPT under ESX3.5 In-Reply-To: <20080519181606.897C.A2D40D1E@fornext.org> References: <20080519130031.8978.A2D40D1E@fornext.org> <48314227.3080101@skytek.it> <20080519181606.897C.A2D40D1E@fornext.org> Message-ID: <4831570E.8050202@skytek.it> Much better: endevor# camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000 Current Parameters: (pass0:mpt0:0:0:0): sync parameter: 8 (pass0:mpt0:0:0:0): frequency: 160.000MHz (pass0:mpt0:0:0:0): offset: 127 (pass0:mpt0:0:0:0): bus width: 16 bits (pass0:mpt0:0:0:0): disconnection is enabled (pass0:mpt0:0:0:0): tagged queueing is enabled endevor# camcontrol inquiry da0 pass0: Fixed Direct Access SCSI-2 device pass0: 80.000MB/s transfers (40.000MHz, offset 127, 16bit), Command Queueing Enabled endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 20.364577 secs (51490193 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 11.525560 secs (90978311 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 11.833996 secs (88607094 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 12.779979 secs (82048335 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 11.812926 secs (88765137 bytes/sec) Also CPU system load is lower: 40% instead of 70% on dual cpu, and 23% instead of 50% on quad cpu. Still not as fast as debian, but really really usable now =) how i can make it mantain these settings at boot? Also, do you know why the first dd was slower? Thanks, Daniel Shunsuke SHINOMIYA ha scritto: > Hello, Daniel > > Can you execute camcontrol with some parameters again? > For example, `camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000'. > > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From daniel at skytek.it Mon May 19 10:42:14 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Mon May 19 10:42:17 2008 Subject: Disk access/MPT under ESX3.5 In-Reply-To: <4831570E.8050202@skytek.it> References: <20080519130031.8978.A2D40D1E@fornext.org> <48314227.3080101@skytek.it> <20080519181606.897C.A2D40D1E@fornext.org> <4831570E.8050202@skytek.it> Message-ID: <48315984.9020808@skytek.it> Oh, btw, this make improvements only on 7.0-Release and Stable using ULE scheduler. - Using 4BSD Scheduler will improve disk access speed but no cpu usage. - On FreeBSD 6.2 and 6.3 this make no difference on cpu usage/speed (about 60mb/sec maximum using 100% cpu). Thanks, Daniel Daniel Ponticello ha scritto: > > Much better: > > endevor# camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000 > Current Parameters: > (pass0:mpt0:0:0:0): sync parameter: 8 > (pass0:mpt0:0:0:0): frequency: 160.000MHz > (pass0:mpt0:0:0:0): offset: 127 > (pass0:mpt0:0:0:0): bus width: 16 bits > (pass0:mpt0:0:0:0): disconnection is enabled > (pass0:mpt0:0:0:0): tagged queueing is enabled > endevor# camcontrol inquiry da0 > pass0: Fixed Direct Access SCSI-2 device > pass0: 80.000MB/s transfers (40.000MHz, offset 127, 16bit), Command > Queueing Enabled > endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 20.364577 secs (51490193 bytes/sec) > endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 11.525560 secs (90978311 bytes/sec) > endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 11.833996 secs (88607094 bytes/sec) > endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 12.779979 secs (82048335 bytes/sec) > endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 11.812926 secs (88765137 bytes/sec) > > Also CPU system load is lower: 40% instead of 70% on dual cpu, and 23% > instead of 50% on quad cpu. > > Still not as fast as debian, but really really usable now =) > > how i can make it mantain these settings at boot? > > Also, do you know why the first dd was slower? > > Thanks, > > Daniel > > > Shunsuke SHINOMIYA ha scritto: >> Hello, Daniel >> >> Can you execute camcontrol with some parameters again? >> For example, `camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000'. >> >> > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From sweetnavelorange at gmail.com Mon May 19 10:50:11 2008 From: sweetnavelorange at gmail.com (James Butler) Date: Mon May 19 10:50:15 2008 Subject: Suspend/resume on IBM X31 Message-ID: Greetings I am having trouble with suspend/resume on my Thinkpad X31, running 7.0-STABLE as of April 23. Any help would be appreciated. First problem: When I run "acpiconf -s3" from mulituser mode, the system suspends immediately, without executing /etc/rc.suspend (which has mode 755); then on resume, I get a panic. Second problem: When the system panics, I don't get a dump (or textdump for that matter, when I turn them on); in the boot messages, I see "kernel dumps on /dev/ad0s2b" and then later (from memory), "Looking for core dumps on /dev/ad0s2b.... savecore: no dumps found" or somesuch. I know from trying out textdumps that dumping works in other circumstances. These issues together make it hard to debug further, but I did a few tests in single-user mode. First, with no services running, "acpiconf -s3" seems to work OK (although /etc/rc.suspend is still not executed) - I can suspend and resume and the machine keeps working. See: http://homepages.ihug.co.nz/~sweetnavelorange/dmesg.1 for my dmesg after one successful cycle - there are a few warnings to do with firewire. However if I start powerd before suspending, I get the following extra kernel messages (hand transcribed): acpi_ec0: warning: EC done before starting event wait subdisk0: detached ad0: detached and any subsequent attempts to access the disk (eg. dmesg>/some/file, kldstat) produce errors of the form: g_vfs_done(): ad0s2e[READ(offset=8478572544, length=16384)] error=6 and eventually another panic. Of course if /etc/rc.suspend worked, I could disable powerd before suspending :-/. If anyone has any ideas, I'd love to hear them, and I'll provide any more info that's needed. Other than this, I'm really pleased with FreeBSD 7 - thanks all! -James Butler From koitsu at FreeBSD.org Mon May 19 11:15:34 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon May 19 11:15:40 2008 Subject: Suspend/resume on IBM X31 In-Reply-To: References: Message-ID: <20080519111533.GA64088@eos.sc1.parodius.com> On Mon, May 19, 2008 at 10:24:43PM +1200, James Butler wrote: > Second problem: When the system panics, I don't get a dump (or > textdump for that matter, when I turn them on); in the boot messages, > I see "kernel dumps on /dev/ad0s2b" and then later (from memory), > "Looking for core dumps on /dev/ad0s2b.... savecore: no dumps found" > or somesuch. I know from trying out textdumps that dumping works in > other circumstances. This is a known problem, but is difficult to solve (chicken-and-egg situation). There's an open PR for it. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From avg at icyb.net.ua Mon May 19 14:15:55 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon May 19 14:16:00 2008 Subject: udf In-Reply-To: <1210969383.00071003.1210956601@10.7.7.3> References: <1210965790.00070991.1210954202@10.7.7.3> <1210965791.00070995.1210954203@10.7.7.3> <1210965792.00070997.1210954803@10.7.7.3> <1210969383.00071003.1210956601@10.7.7.3> Message-ID: <48318B97.5090200@icyb.net.ua> on 16/05/2008 19:48 Scott Long said the following: > There is no write support in UDF in FreeBSD. When I wrote the fs code, > packet writing was the only way to do discrete writes, and it's very > hard to make that work with a traditional VM system. Now with DVD+R, > it's probably worth someone's time to look at it (though the append-only > nature of +R means that there are still some nasty VM complications to > deal with). Until that happens, mkisofs can be used to create a static > UDF filesystem. BTW, Remko has kindly notified me that Reinoud Zandijk has completed his long work on UDF write support in NetBSD. I think that porting his work is our best chance to get write support in FreeBSD too. -- Andriy Gapon From scottl at samsco.org Mon May 19 14:21:31 2008 From: scottl at samsco.org (Scott Long) Date: Mon May 19 14:21:37 2008 Subject: udf In-Reply-To: <48318B97.5090200@icyb.net.ua> References: <1210965790.00070991.1210954202@10.7.7.3> <1210965791.00070995.1210954203@10.7.7.3> <1210965792.00070997.1210954803@10.7.7.3> <1210969383.00071003.1210956601@10.7.7.3> <48318B97.5090200@icyb.net.ua> Message-ID: <48318CE7.10507@samsco.org> Andriy Gapon wrote: > on 16/05/2008 19:48 Scott Long said the following: >> There is no write support in UDF in FreeBSD. When I wrote the fs code, >> packet writing was the only way to do discrete writes, and it's very >> hard to make that work with a traditional VM system. Now with DVD+R, >> it's probably worth someone's time to look at it (though the append-only >> nature of +R means that there are still some nasty VM complications to >> deal with). Until that happens, mkisofs can be used to create a static >> UDF filesystem. > > BTW, Remko has kindly notified me that Reinoud Zandijk has completed his > long work on UDF write support in NetBSD. I think that porting his work > is our best chance to get write support in FreeBSD too. > I think you'll find that implementing VOPs and filling in UDF data structures will be easy, while interacting with the VM will be many orders of magnitude harder. Still it should be a fun challenge for someone to do. Scott From duhring at charter.net Mon May 19 15:35:06 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 15:35:10 2008 Subject: Buildworld Fails RELENG_7 Message-ID: <20080519151739.GA50653@charter.net> Sources checked out yesterday, updated this morning using cvsup and repository at cvsup12.freebsd.org. The build fails in /usr/src/lib/libc /usr/bin/gcc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/fcntl.c /usr/src/lib/libc/sys/fcntl.c: In function 'fcntl': /usr/src/lib/libc/sys/fcntl.c:42: error: storage size of 'ofl' isn't known /usr/src/lib/libc/sys/fcntl.c:67: error: 'F_OGETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:67: error: (Each undeclared identifier is reported only once /usr/src/lib/libc/sys/fcntl.c:67: error: for each function it appears in.) /usr/src/lib/libc/sys/fcntl.c:74: error: 'struct flock' has no member named 'l_sysid' /usr/src/lib/libc/sys/fcntl.c:79: error: 'F_OSETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:82: error: 'F_OSETLKW' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:42: warning: unused variable 'ofl' *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 From dfr at rabson.org Mon May 19 16:07:11 2008 From: dfr at rabson.org (Doug Rabson) Date: Mon May 19 16:07:18 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519151739.GA50653@charter.net> References: <20080519151739.GA50653@charter.net> Message-ID: <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? On 19 May 2008, at 16:17, Dave Uhring wrote: > Sources checked out yesterday, updated this morning using cvsup and > repository at cvsup12.freebsd.org. The build fails in /usr/src/lib/ > libc > > /usr/bin/gcc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -I/ > usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/ > src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../ > contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/ > libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES - > DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING - > DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno- > uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/fcntl.c > /usr/src/lib/libc/sys/fcntl.c: In function 'fcntl': > /usr/src/lib/libc/sys/fcntl.c:42: error: storage size of 'ofl' isn't > known > /usr/src/lib/libc/sys/fcntl.c:67: error: 'F_OGETLK' undeclared > (first use in this function) > /usr/src/lib/libc/sys/fcntl.c:67: error: (Each undeclared identifier > is reported only once > /usr/src/lib/libc/sys/fcntl.c:67: error: for each function it > appears in.) > /usr/src/lib/libc/sys/fcntl.c:74: error: 'struct flock' has no > member named 'l_sysid' > /usr/src/lib/libc/sys/fcntl.c:79: error: 'F_OSETLK' undeclared > (first use in this function) > /usr/src/lib/libc/sys/fcntl.c:82: error: 'F_OSETLKW' undeclared > (first use in this function) > /usr/src/lib/libc/sys/fcntl.c:42: warning: unused variable 'ofl' > *** Error code 1 > > Stop in /usr/src/lib/libc. > *** Error code 1 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " From vivek at khera.org Mon May 19 16:13:21 2008 From: vivek at khera.org (Vivek Khera) Date: Mon May 19 16:13:28 2008 Subject: how much memory does increasing max rules for IPFW take up? In-Reply-To: References: Message-ID: <43327C1A-AF98-4076-AAE4-3A59F6FC074E@khera.org> On May 18, 2008, at 3:26 AM, Ian Smith wrote: > Hashed per flow, (srcip^destip^srcport^dstport) mod > curr_dyn_buckets, so > packets for both directions of a given flow hash to the same > bucket. In > the case you mention, you could likely expect reasonable > distribution by > src_ip/src_port. Thanks for the detailed info. This really helps. From freebsd-listen at fabiankeil.de Mon May 19 16:14:35 2008 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Mon May 19 16:14:41 2008 Subject: possible zfs bug? lost all pools In-Reply-To: <200805181511.56646.joao@matik.com.br> References: <200805180956.18211.joao@matik.com.br> <200805181220.33599.joao@matik.com.br> <20080518153911.GA22300@eos.sc1.parodius.com> <200805181511.56646.joao@matik.com.br> Message-ID: <20080519180056.59624805@fabiankeil.de> JoaoBR wrote: > man page thar zfs can not be a dump device, not sure if I understand it > as meant but I can dump to zfs very well and fast as long as > recordsize=128 I assume you tried dump(8), while the sentence in the man page is about using a ZFS volume as dumpon(8) target: %sudo dumpon -v /dev/zvol/tank/swap dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080519/6a0ac495/signature.pgp From duhring at charter.net Mon May 19 16:38:25 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 16:38:31 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> Message-ID: <20080519163825.GA32372@charter.net> On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: > This symbol has been added to fcntl.h recently. It appears as if your build > is picking up the installed header rather than the one from the source > tree. Are you using 'make buildworld'? Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to continue. [root@maxwell /usr/include/sys]# ls *.orig fcntl.h.orig tree.h.orig umtx.h.orig Just got another stoppage in /usr/src/gnu/lib/libstdc++. /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory The #include declaration has that header file in the local directory. It exists in /usr/obj, however. From koitsu at FreeBSD.org Mon May 19 16:42:22 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon May 19 16:42:25 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519163825.GA32372@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> Message-ID: <20080519164221.GA76691@eos.sc1.parodius.com> On Mon, May 19, 2008 at 11:38:25AM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: > > This symbol has been added to fcntl.h recently. It appears as if your build > > is picking up the installed header rather than the one from the source > > tree. Are you using 'make buildworld'? > > Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean > build. > > The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I > have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to > continue. > > [root@maxwell /usr/include/sys]# ls *.orig > fcntl.h.orig tree.h.orig umtx.h.orig > > Just got another stoppage in /usr/src/gnu/lib/libstdc++. > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > > The #include declaration has that header file in the local directory. It exists in > /usr/obj, however. Is there some reason you're using -DNO_CLEAN, and haven't just nuked /usr/obj/* and done buildworld normally? I can't reproduce any of this behaviour on any of our RELENG_7 systems. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dfr at rabson.org Mon May 19 16:43:00 2008 From: dfr at rabson.org (Doug Rabson) Date: Mon May 19 16:43:06 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519163825.GA32372@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> Message-ID: On 19 May 2008, at 17:38, Dave Uhring wrote: > On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: >> This symbol has been added to fcntl.h recently. It appears as if >> your build >> is picking up the installed header rather than the one from the >> source >> tree. Are you using 'make buildworld'? > > Yes, although at this point is it 'make -DNO_CLEAN buildworld' until > I get a clean > build. > > The header files in /usr/include/sys are those from 7.0 RELEASE, > however, and I > have had to copy 3 files (so far) from /usr/src/sys/sys to get the > build to > continue. You should never have to copy any header files to /usr/include to get a buildworld to work. Try without the -DNO_CLEAN and if that still fails, clean your /usr/obj (e.g. with rm -rf /usr/obj/*). From dillon at apollo.backplane.com Mon May 19 16:44:36 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Mon May 19 16:44:40 2008 Subject: udf References: <1210965790.00070991.1210954202@10.7.7.3> <1210965791.00070995.1210954203@10.7.7.3> <1210965792.00070997.1210954803@10.7.7.3> <1210969383.00071003.1210956601@10.7.7.3> <48318B97.5090200@icyb.net.ua> <48318CE7.10507@samsco.org> Message-ID: <200805191632.m4JGWZix002576@apollo.backplane.com> :> BTW, Remko has kindly notified me that Reinoud Zandijk has completed his :> long work on UDF write support in NetBSD. I think that porting his work :> is our best chance to get write support in FreeBSD too. :> : :I think you'll find that implementing VOPs and filling in UDF data :structures will be easy, while interacting with the VM will be many :orders of magnitude harder. Still it should be a fun challenge for :someone to do. : :Scott One avenue that can be persued would be to finish the UIO_NOCOPY support in the vm/vnode_pager.c. You have UIO_NOCOPY support for the putpages code but not the getpages code. If that were done the VFS can simply use VMIO-backed buffer cache buffers (they have to be VMIO-backed for UIO_NOCOPY to work properly)... and not have to deal with getpages or putpages at all. The vnode pager would convert them to a UIO_NOCOPY VOP_READ or VOP_WRITE as appropriate. The entire VM coding burden winds up being in the kernel proper and not in the VFS at all. IMHO implementing per-VFS getpages/putpages is an exercise in frustration, to be avoided at all costs. Plus once you have a generic getpages/putpages layer in vm/vnode_pager.c the VFS code no longer has to mess with VM pages anywhere and winds up being far more portable. I did the necessary work in DragonFly in order to avoid having to mess with VM pages in HAMMER. Primary work: * It is a good idea to require that all vnode-based buffer cache buffers be B_VMIO backed (aka have a VM object). It ensures a clean interface and avoids confusion, and also cleans up numerous special cases that are simply not needed in this day and age. * Add support for UIO_NOCOPY in generic getpages. Get rid of all the special cases for small-block filesystems in getpages. Make it completely generic and simply issue the UIO_NOCOPY VOP_READ/VOP_WRITE. * Make minor adjustments to existing VFSs (but nothing prevents them from still rolling their own getpages/putpages so no major changes are needed). And then enjoy the greatly simplified VFS interactions that result. I would also recommend removing the VOP_BMAP() from the generic getpages/putpages code and simply letting the VFS's VOP_READ/VOP_WRITE deal with it. The BMAP calls were being made from getpages/putpages to check for discontiguous blocks, to avoid unnecessary disk seeks. Those checks are virtually worthless on today's modern hardware particularly since filesystems already localize most data accesses. In other words, if your filesystem is fragmented you are going to be doing the seeks anyway, probably. -Matt Matthew Dillon From duhring at charter.net Mon May 19 16:54:24 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 16:54:29 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> Message-ID: <20080519165421.GA62264@charter.net> On Mon, May 19, 2008 at 05:42:56PM +0100, Doug Rabson wrote: > > On 19 May 2008, at 17:38, Dave Uhring wrote: > >> On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: >>> This symbol has been added to fcntl.h recently. It appears as if your >>> build >>> is picking up the installed header rather than the one from the source >>> tree. Are you using 'make buildworld'? >> >> Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get >> a clean >> build. >> >> The header files in /usr/include/sys are those from 7.0 RELEASE, however, >> and I >> have had to copy 3 files (so far) from /usr/src/sys/sys to get the build >> to >> continue. > > You should never have to copy any header files to /usr/include to get a > buildworld to work. Try without the -DNO_CLEAN and if that still fails, > clean your /usr/obj (e.g. with rm -rf /usr/obj/*). The build is going nowhere without the correct header files in /usr/include/sys. I have repeatedly cleaned /usr/obj to no avail, but I have a better method for doing that: umount /usr/obj newfs /dev/da4s2f mount /usr/obj From duhring at charter.net Mon May 19 16:58:07 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 16:58:12 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519164221.GA76691@eos.sc1.parodius.com> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> Message-ID: <20080519165807.GB62264@charter.net> On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: > > Is there some reason you're using -DNO_CLEAN, and haven't just nuked > /usr/obj/* and done buildworld normally? I can't reproduce any of this > behaviour on any of our RELENG_7 systems. I have repeately nuked /usr/obj. That is not going to put updated header files where they need to be. I'm using -DNO_CLEAN in order to get the system to a point where a build just might succeed without -DNO_CLEAN and I'm not getting there without some header files being in the right place. Remember I'm starting from a RELEASE userland. This is just about as bad as jumping from one full release to the next :( From koitsu at FreeBSD.org Mon May 19 16:59:25 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon May 19 16:59:31 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519165421.GA62264@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> Message-ID: <20080519165925.GA77907@eos.sc1.parodius.com> On Mon, May 19, 2008 at 11:54:21AM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 05:42:56PM +0100, Doug Rabson wrote: > > > > On 19 May 2008, at 17:38, Dave Uhring wrote: > > > >> On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: > >>> This symbol has been added to fcntl.h recently. It appears as if your > >>> build > >>> is picking up the installed header rather than the one from the source > >>> tree. Are you using 'make buildworld'? > >> > >> Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get > >> a clean > >> build. > >> > >> The header files in /usr/include/sys are those from 7.0 RELEASE, however, > >> and I > >> have had to copy 3 files (so far) from /usr/src/sys/sys to get the build > >> to > >> continue. > > > > You should never have to copy any header files to /usr/include to get a > > buildworld to work. Try without the -DNO_CLEAN and if that still fails, > > clean your /usr/obj (e.g. with rm -rf /usr/obj/*). > > The build is going nowhere without the correct header files in /usr/include/sys. Is there breakage of some sort being caused by your make.conf or (less probable) your src.conf? Any filesystem corruption (boot single user and force fsck on all the filesystems)? In all the years I've used FreeBSD, I've never had to copy include files from parts of /usr/src to get buildworld to work, so this is very odd behaviour. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dfr at rabson.org Mon May 19 17:00:41 2008 From: dfr at rabson.org (Doug Rabson) Date: Mon May 19 17:00:44 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519165807.GB62264@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> Message-ID: <7AA1551A-D04D-4817-8028-E9CB6A87C0EA@rabson.org> On 19 May 2008, at 17:58, Dave Uhring wrote: > On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: >> >> Is there some reason you're using -DNO_CLEAN, and haven't just nuked >> /usr/obj/* and done buildworld normally? I can't reproduce any of >> this >> behaviour on any of our RELENG_7 systems. > > I have repeately nuked /usr/obj. That is not going to put updated > header files > where they need to be. > > I'm using -DNO_CLEAN in order to get the system to a point where a > build just > might succeed without -DNO_CLEAN and I'm not getting there without > some header > files being in the right place. > > Remember I'm starting from a RELEASE userland. This is just about > as bad as > jumping from one full release to the next :( The thing is that a working buildworld doesn't depend on headers from / usr/include. One of the first thing it does is install a set of new headers in somewhere like /usr/obj/usr/src/tmp. At this point, it might be useful to see a log of a failed buildworld attempt to see what is going wrong. From duhring at charter.net Mon May 19 17:03:37 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 17:03:43 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519165925.GA77907@eos.sc1.parodius.com> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519165925.GA77907@eos.sc1.parodius.com> Message-ID: <20080519170334.GA74159@charter.net> On Mon, May 19, 2008 at 09:59:25AM -0700, Jeremy Chadwick wrote: > > Is there breakage of some sort being caused by your make.conf or (less > probable) your src.conf? Any filesystem corruption (boot single user > and force fsck on all the filesystems)? [duhring@maxwell /etc]$ grep -v ^# make.conf CPUTYPE?=athlon64 CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 CXXFLAGS+= -fconserve-space MAKE_SHELL?=sh COPTFLAGS= -O -pipe INSTALL=install -C MTREE_FOLLOWS_SYMLINKS= -L ENABLE_SUID_SSH= NO_SENDMAIL= NO_PROFILE= DOC_LANG= en_US.ISO8859-1 src.conf is untouched. > In all the years I've used FreeBSD, I've never had to copy include files > from parts of /usr/src to get buildworld to work, so this is very odd > behaviour. Start with a clean RELEASE userland and try to build RELENG_7 today :) From koitsu at FreeBSD.org Mon May 19 17:04:28 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon May 19 17:04:34 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519165807.GB62264@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> Message-ID: <20080519170428.GB77907@eos.sc1.parodius.com> On Mon, May 19, 2008 at 11:58:07AM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: > > > > Is there some reason you're using -DNO_CLEAN, and haven't just nuked > > /usr/obj/* and done buildworld normally? I can't reproduce any of this > > behaviour on any of our RELENG_7 systems. > > I have repeately nuked /usr/obj. That is not going to put updated header files > where they need to be. It's apparent you don't quite understand. The "updated header files" reside in /usr/src, and ***remain there*** until installworld is done. The buildworld process will include the "updated header files", trumping most of those which are in /usr/include. You do not need to copy any files from /usr/src/sys/sys to /usr/include or anywhere else to get buildworld to work. If you're having to do that, the problem is very likely elsewhere. > I'm using -DNO_CLEAN in order to get the system to a point where a build just > might succeed without -DNO_CLEAN and I'm not getting there without some header > files being in the right place. > > Remember I'm starting from a RELEASE userland. This is just about as bad as > jumping from one full release to the next :( Okay, so you installed 7.0-RELEASE on a machine. Did you choose to install src from the CD/DVD when installing? (If so, you will need to "adopt" the version you installed to the current version, see the cvsup FAQ here: http://www.cvsup.org/faq.html#caniadopt -- and you'll need to do this for ports if you installed the ports tree off the CD/DVD as well) If you csup'd, what tag did you use? RELENG_7? I'm assuming so. Did you use src-all, or are you using a custom supfile? We use /usr/share/examples/cvsup/stable-supfile. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Mon May 19 17:06:19 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon May 19 17:06:24 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519170334.GA74159@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519165925.GA77907@eos.sc1.parodius.com> <20080519170334.GA74159@charter.net> Message-ID: <20080519170619.GC77907@eos.sc1.parodius.com> On Mon, May 19, 2008 at 12:03:34PM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 09:59:25AM -0700, Jeremy Chadwick wrote: > > > > Is there breakage of some sort being caused by your make.conf or (less > > probable) your src.conf? Any filesystem corruption (boot single user > > and force fsck on all the filesystems)? > > [duhring@maxwell /etc]$ grep -v ^# make.conf > CPUTYPE?=athlon64 > CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 > CXXFLAGS+= -fconserve-space > MAKE_SHELL?=sh > COPTFLAGS= -O -pipe > INSTALL=install -C > MTREE_FOLLOWS_SYMLINKS= -L > ENABLE_SUID_SSH= > NO_SENDMAIL= > NO_PROFILE= > DOC_LANG= en_US.ISO8859-1 Can you please comment out all of the above and see if the problem persists? > > In all the years I've used FreeBSD, I've never had to copy include files > > from parts of /usr/src to get buildworld to work, so this is very odd > > behaviour. > > Start with a clean RELEASE userland and try to build RELENG_7 today :) Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money is on that I won't be able to reproduce the problem. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From duhring at charter.net Mon May 19 17:45:38 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 17:45:42 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519170619.GC77907@eos.sc1.parodius.com> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519165925.GA77907@eos.sc1.parodius.com> <20080519170334.GA74159@charter.net> <20080519170619.GC77907@eos.sc1.parodius.com> Message-ID: <20080519174537.GA55020@charter.net> On Mon, May 19, 2008 at 10:06:19AM -0700, Jeremy Chadwick wrote: > On Mon, May 19, 2008 at 12:03:34PM -0500, Dave Uhring wrote: > > > > [duhring@maxwell /etc]$ grep -v ^# make.conf > > CPUTYPE?=athlon64 > > CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 > > CXXFLAGS+= -fconserve-space > > MAKE_SHELL?=sh > > COPTFLAGS= -O -pipe > > INSTALL=install -C > > MTREE_FOLLOWS_SYMLINKS= -L > > ENABLE_SUID_SSH= > > NO_SENDMAIL= > > NO_PROFILE= > > DOC_LANG= en_US.ISO8859-1 > > Can you please comment out all of the above and see if the problem > persists? Sure, but that is not going to put the correct headers where the sources are looking for them. Nor is it going to put groff headers into a directory where the #include "driver.h" is declared within a source file and the directory contains *no* headers. In particular, /usr/src/contrib/groff/src/libs/libdriver has no header files at all, yet input.cpp in that directory has these declarations: #include "driver.h" #include "device.h" > > Start with a clean RELEASE userland and try to build RELENG_7 today :) > > Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money > is on that I won't be able to reproduce the problem. VMware? Give me a break! From duhring at charter.net Mon May 19 17:53:58 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 17:54:05 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519170223.GH7468@bunrab.catwhisker.org> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> Message-ID: <20080519175358.GB55020@charter.net> On Mon, May 19, 2008 at 10:02:23AM -0700, David Wolfskill wrote: > On Mon, May 19, 2008 at 11:54:21AM -0500, Dave Uhring wrote: > > > > The build is going nowhere without the correct header files in /usr/include/sys. > > That appears to indicate that your build environment is fundamentally > broken.. > > You might consider doing the build within script(1), then making the > resulting script file available for folks to examine. I posted the relevant output from "make buildworld". Copying the 3 new header files from /usr/src/sys/sys to /usr/include/sys solved my original problem. I'm sure that after a successful buildworld and installworld that the original problem will go away. The problem now is in the build of groff: [root@maxwell /usr/src/contrib/groff/src/devices/grodvi]# ls *.h ls: *.h: No such file or directory However, dvi.cpp in that directory has this: #include "driver.h" #include "nonposix.h" #include "paper.h" From koitsu at FreeBSD.org Mon May 19 18:00:28 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon May 19 18:00:32 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519170619.GC77907@eos.sc1.parodius.com> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519165925.GA77907@eos.sc1.parodius.com> <20080519170334.GA74159@charter.net> <20080519170619.GC77907@eos.sc1.parodius.com> Message-ID: <20080519180028.GA79392@eos.sc1.parodius.com> On Mon, May 19, 2008 at 10:06:19AM -0700, Jeremy Chadwick wrote: > Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money > is on that I won't be able to reproduce the problem. Something I thought of while doing the above: there's been reports in the past of problems with buildworld (or building software in general) bombing out or behaving oddly due to clock issues on the local machine. If you don't use ntpd, consider doing so. Otherwise, at least use ntpdate once to set your clock to something sane. Anyway. I've completed the above using VMware. Installation was 7.0-RELEASE i386. fdisk and label were defaults, and for distributions I chose base, kernels, dict, doc, games, info, man, and catman. (I do not pick src and ports because I don't care to deal with the "adoption" method.) I also configured the network (nothing out of the ordinary; pure DHCP), and the time zone (PDT). Immediately after the system was up, I did the following: # csup -h cvsup4.freebsd.org -g -L 2 -4 /usr/share/examples/cvsup/stable-supfile This picked up src-all using the RELENG_7 tag. I then attempted a buildworld (cd /usr/src && time make -j2 buildworld). It's just begun stage 2.3, but so far no issues. I'll report back in about 30 minutes or so, when it has a chance to finish. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From duhring at charter.net Mon May 19 18:21:08 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 18:21:13 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519170428.GB77907@eos.sc1.parodius.com> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> <20080519170428.GB77907@eos.sc1.parodius.com> Message-ID: <20080519182107.GC55020@charter.net> On Mon, May 19, 2008 at 10:04:28AM -0700, Jeremy Chadwick wrote: > On Mon, May 19, 2008 at 11:58:07AM -0500, Dave Uhring wrote: > > > > I have repeately nuked /usr/obj. That is not going to put updated header files > > where they need to be. > > It's apparent you don't quite understand. The "updated header files" > reside in /usr/src, and ***remain there*** until installworld is done. That is as it should be. > The buildworld process will include the "updated header files", trumping > most of those which are in /usr/include. Does not happen. The header files included were those from /usr/include/sys, not /usr/src/sys/sys. The errors would not have occurred if the header files in /usr/src/sys/sys were being referenced by In any case, that problem has been solved by putting the updated header files in /usr/include/sys and will be properly fixed when I can finally make installworld. > > Remember I'm starting from a RELEASE userland. This is just about as bad as > > jumping from one full release to the next :( > > Okay, so you installed 7.0-RELEASE on a machine. Did you choose to > install src from the CD/DVD when installing? (If so, you will need to > "adopt" the version you installed to the current version, see the cvsup > FAQ here: http://www.cvsup.org/faq.html#caniadopt -- and you'll need to > do this for ports if you installed the ports tree off the CD/DVD as > well) > > If you csup'd, what tag did you use? RELENG_7? I'm assuming so. Did > you use src-all, or are you using a custom supfile? We use > /usr/share/examples/cvsup/stable-supfile. Whatever tag was in /usr/share/examples/cvsup/stable-supfile. In fact it is: *default release=cvs tag=RELENG_7 > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From duhring at charter.net Mon May 19 18:23:08 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 18:23:13 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <7AA1551A-D04D-4817-8028-E9CB6A87C0EA@rabson.org> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> <7AA1551A-D04D-4817-8028-E9CB6A87C0EA@rabson.org> Message-ID: <20080519182307.GD55020@charter.net> On Mon, May 19, 2008 at 06:00:39PM +0100, Doug Rabson wrote: > > The thing is that a working buildworld doesn't depend on headers from > /usr/include. One of the first thing it does is install a set of new > headers in somewhere like /usr/obj/usr/src/tmp. At this point, it might be > useful to see a log of a failed buildworld attempt to see what is going > wrong. Putting the updated header files in /usr/include/sys solved that problem. Whether is was the correct solution or not is moot since the build continued from the previous stoppage in libc. From duhring at charter.net Mon May 19 18:31:14 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 18:31:21 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519180028.GA79392@eos.sc1.parodius.com> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519165925.GA77907@eos.sc1.parodius.com> <20080519170334.GA74159@charter.net> <20080519170619.GC77907@eos.sc1.parodius.com> <20080519180028.GA79392@eos.sc1.parodius.com> Message-ID: <20080519183113.GA55295@charter.net> On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote: > > Something I thought of while doing the above: there's been reports in > the past of problems with buildworld (or building software in general) > bombing out or behaving oddly due to clock issues on the local machine. > If you don't use ntpd, consider doing so. Otherwise, at least use > ntpdate once to set your clock to something sane. I hadn't yet started ntpd but [root@maxwell /etc]# ntpdate newton 19 May 13:29:22 ntpdate[55524]: step time server 192.168.0.8 offset -1.044724 sec I doubt that a second off would make any difference. From duhring at charter.net Mon May 19 18:36:20 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 18:36:25 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519180201.GI7468@bunrab.catwhisker.org> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> Message-ID: <20080519183614.GB55295@charter.net> On Mon, May 19, 2008 at 11:02:01AM -0700, David Wolfskill wrote: > On Mon, May 19, 2008 at 12:53:58PM -0500, Dave Uhring wrote: > > > > I posted the relevant output from "make buildworld". Copying the 3 new header > > files from /usr/src/sys/sys to /usr/include/sys solved my original problem. > > s/solved/circumvented/ :) Whatever, libc does build now. > freebeast(8.0-C)[52] ls -l usr/src/contrib/groff/src/devices/grodvi/*.h > ls: No match. > freebeast(8.0-C)[53] grep '#include "' usr/src/contrib/groff/src/devices/grodvi/dvi.cpp > #include "driver.h" > #include "nonposix.h" > #include "paper.h" > freebeast(8.0-C)[54] > > The compilation of dvi.cpp uses > "-I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../../../../contrib/groff/src/include > -I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../src/include" > (among other things); I expect you will find the needed header files > in those directories. If a -I/some/directory is used as a CFLAG then the *include directive must read #include , *not* #include "driver.h". The latter demands that the header file be in the same directory as the source file. From freebsd-stable-local at be-well.ilk.org Mon May 19 19:05:29 2008 From: freebsd-stable-local at be-well.ilk.org (Lowell Gilbert) Date: Mon May 19 19:05:33 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519183614.GB55295@charter.net> (Dave Uhring's message of "Mon\, 19 May 2008 13\:36\:14 -0500") References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> Message-ID: <448wy6yviw.fsf@be-well.ilk.org> Dave Uhring writes: > On Mon, May 19, 2008 at 11:02:01AM -0700, David Wolfskill wrote: >> On Mon, May 19, 2008 at 12:53:58PM -0500, Dave Uhring wrote: >> > >> > I posted the relevant output from "make buildworld". Copying the 3 new header >> > files from /usr/src/sys/sys to /usr/include/sys solved my original problem. >> >> s/solved/circumvented/ > > :) Whatever, libc does build now. > >> freebeast(8.0-C)[52] ls -l usr/src/contrib/groff/src/devices/grodvi/*.h >> ls: No match. >> freebeast(8.0-C)[53] grep '#include "' usr/src/contrib/groff/src/devices/grodvi/dvi.cpp >> #include "driver.h" >> #include "nonposix.h" >> #include "paper.h" >> freebeast(8.0-C)[54] >> >> The compilation of dvi.cpp uses >> "-I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../../../../contrib/groff/src/include >> -I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../src/include" >> (among other things); I expect you will find the needed header files >> in those directories. > > If a -I/some/directory is used as a CFLAG then the *include directive must read > > #include , *not* #include "driver.h". The latter demands that the > header file be in the same directory as the source file. Not that it necessarily affects what you're going through, but that last statement is incorrect. The double quotes are (according to the C standard) implementation defined, and gcc (like many other compilers) will prefer the local directory for the double quotes, but will search the entire search path if it doesn't find the file there. It also has some really wacky command-line parameters to control which directories are searched (by *both* #include syntaxes) down to a ridiculously fine level. The only use I've ever had for such things was in cross-compile environments targeting multiple architectures in a single build tree, and even then it isn't really necessary. - Lowell -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ From koitsu at FreeBSD.org Mon May 19 19:16:46 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon May 19 19:16:50 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519180028.GA79392@eos.sc1.parodius.com> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519165925.GA77907@eos.sc1.parodius.com> <20080519170334.GA74159@charter.net> <20080519170619.GC77907@eos.sc1.parodius.com> <20080519180028.GA79392@eos.sc1.parodius.com> Message-ID: <20080519191646.GA82513@eos.sc1.parodius.com> On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote: > This picked up src-all using the RELENG_7 tag. I then attempted a > buildworld (cd /usr/src && time make -j2 buildworld). It's just begun > stage 2.3, but so far no issues. I'll report back in about 30 minutes > or so, when it has a chance to finish. The compile has finished successfully. Took 1 hour 15 minutes. Another user also mailed me (privately) adding that he too cannot reproduce this problem. I will attempt the same with your make.conf to see if it's any different. But at this point, it appears the issue is with your system or system configuration. I just wish I knew what was doing it. Any odd filesystem mount flags (output of "mount")? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kutulu at kutulu.org Mon May 19 19:50:35 2008 From: kutulu at kutulu.org (Mike Edenfield) Date: Mon May 19 19:50:41 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519183614.GB55295@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> Message-ID: <4831CC6E.4040101@kutulu.org> Dave Uhring wrote: > If a -I/some/directory is used as a CFLAG then the *include directive must read > > #include , *not* #include "driver.h". The latter demands that the > header file be in the same directory as the source file. Absolutely not true. Directly from the gcc online manual: "GCC looks for headers requested with #include "file" first in the directory containing the current file, then in the directories as specified by -iquote options, then in the same places it would have looked for a header requested with angle brackets. For example, if /usr/include/sys/stat.h contains #include "types.h", GCC looks for types.h first in /usr/include/sys, then in its usual search path." From lev at FreeBSD.org Mon May 19 19:59:01 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Mon May 19 19:59:08 2008 Subject: geom_raid5 + FreeBSD 7.0-STABLE + 5x500Gb (1.8T UFS volume) -- crashes :( Message-ID: <461480861.20080519234220@serebryakov.spb.ru> Hello, Arne. I try to build storage server for my home (I have a LOT of media files) with FreeBSD 7, 5xHDD (WD 500Gb) and geom_raid5 ("simple" version from perforce, beacuse http://home.tiscali.de/cmdr_faako/geom_raid5.tbz is not patched for FreeBSD7). Array & FS were created with default arguments: # graid5 label storage ad6 ad8 ad10 ad12 ad14 # newfs -O2 -U /dev/raid5/storage # mount /dev/raid5/storage /usr/home/storage I use additional (sixth) HDD for system, labeled ins tandard way. So, raid is used only for data, not for swap or booting. I've started from simple tests: building world with /usr/src on system disk and obj (MAKEOBJDIRPREFIX) on RAID5. After first build I've run `rm -rf ${MAKEOBJDIRPREFIX}'. It returns to shell pretty quickly, and to be sure, that FS is synced I've tried `umount /usr/home/storage'. I've got DEVICE BUSY! I've called `df -h' and it shows, that I have NEGATIVE amount of space on /usr/home/storage (about -14Mb of 1.8Tb). After calling "sync && sync && sycn", umount finished without errors, but second later system CRASHED with "ffs freed free frag". After reboot, RAID5 becomes REBUILDING HOT and system crashed again when fsck start to checks filesystem on RAID :( And again :( So, I boot to single-user and remove auto-mount of RAID volume... Manual run of fsck fails with "fsck_ufs: bad inode number 32360448 to nextinode"... Is it problem of UFS or graid5 or what? -- // Black Lion AKA Lev Serebryakov From duhring at charter.net Mon May 19 20:03:51 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 20:03:55 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519191646.GA82513@eos.sc1.parodius.com> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519165925.GA77907@eos.sc1.parodius.com> <20080519170334.GA74159@charter.net> <20080519170619.GC77907@eos.sc1.parodius.com> <20080519180028.GA79392@eos.sc1.parodius.com> <20080519191646.GA82513@eos.sc1.parodius.com> Message-ID: <20080519200342.GA79130@charter.net> On Mon, May 19, 2008 at 12:16:46PM -0700, Jeremy Chadwick wrote: > On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote: > > This picked up src-all using the RELENG_7 tag. I then attempted a > > buildworld (cd /usr/src && time make -j2 buildworld). It's just begun > > stage 2.3, but so far no issues. I'll report back in about 30 minutes > > or so, when it has a chance to finish. That is what I did after the first build using the original RELEASE sources and updated using csup. I blew away /usr/src and cvsupped a fresh RELENG_7 source tree. > The compile has finished successfully. Took 1 hour 15 minutes. Another > user also mailed me (privately) adding that he too cannot reproduce this > problem. Last time I succeeded in building world on another box it took 47 minutes :-) That's still a long way from years back when RELENG_4 built in 30 minutes on a machine with an Athlon Tbird 1.2GHz processor. Double the processor speed and quadruple the memory and the build takes 50% longer. > I will attempt the same with your make.conf to see if it's any > different. But at this point, it appears the issue is with your system > or system configuration. I just wish I knew what was doing it. Any odd > filesystem mount flags (output of "mount")? [root@maxwell /usr/src/contrib/groff]# mount /dev/ad4s2a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad4s2h on /home (ufs, local, soft-updates) /dev/ad4s2e on /usr (ufs, local, soft-updates) /dev/ad4s2g on /usr/local (ufs, local, soft-updates) /dev/ad4s2d on /var (ufs, local, soft-updates) /dev/md0 on /tmp (ufs, local, soft-updates) /dev/ad4s2f on /usr/obj (ufs, asynchronous, local, noatime) [root@maxwell /usr/src/contrib/groff]# Not even an NFS mount. I'm trying to update to FreeBSD-STABLE to use on my home file server. At present it has OpenSolaris installed but that OS does not have the Ethernet driver I need and I want to be able to use 2 Adaptec 29160N HBAs in the system. But I only have 2 PCI slots and I would like to remove the Intel NIC and use the system's on-board nfe NIC. I'll blow away /usr/src and /usr/obj, cvsup the entire RELENG_7 source tree again and once more attempt to buildworld. If that fails, Solaris stays on the server. From lev at FreeBSD.org Mon May 19 20:05:29 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Mon May 19 20:05:33 2008 Subject: geom_raid5 + FreeBSD 7.0-STABLE + 5x500Gb (1.8T UFS volume) -- crashes :( In-Reply-To: <461480861.20080519234220@serebryakov.spb.ru> References: <461480861.20080519234220@serebryakov.spb.ru> Message-ID: <18910350694.20080520000527@serebryakov.spb.ru> Hello, Arne. You wrote 19 ??? 2008 ?., 23:42:20: > I've called `df -h' and it shows, that I have NEGATIVE amount of > space on /usr/home/storage (about -14Mb of 1.8Tb). Negative amount of USED space, sorry. -- // Black Lion AKA Lev Serebryakov From duhring at charter.net Mon May 19 20:14:19 2008 From: duhring at charter.net (Dave Uhring) Date: Mon May 19 20:14:25 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <448wy6yviw.fsf@be-well.ilk.org> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> <448wy6yviw.fsf@be-well.ilk.org> Message-ID: <20080519201408.GD79130@charter.net> On Mon, May 19, 2008 at 02:54:31PM -0400, Lowell Gilbert wrote: > Dave Uhring writes: > > > > If a -I/some/directory is used as a CFLAG then the *include directive must read > > > > #include , *not* #include "driver.h". The latter demands that the > > header file be in the same directory as the source file. > > Not that it necessarily affects what you're going through, but that > last statement is incorrect. The double quotes are (according to the > C standard) implementation defined, and gcc (like many other > compilers) will prefer the local directory for the double quotes, but > will search the entire search path if it doesn't find the file there. The problem is that gcc is *not* finding the file in the directory referenced by the -I cflag. If I copy the header files to the directory where the error occurs the header file is found and used to compile the source file. From cliftonr at lava.net Tue May 20 00:01:59 2008 From: cliftonr at lava.net (Clifton Royston) Date: Tue May 20 00:02:02 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519201408.GD79130@charter.net> References: <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> <448wy6yviw.fsf@be-well.ilk.org> <20080519201408.GD79130@charter.net> Message-ID: <20080520000147.GA2824@lava.net> On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 02:54:31PM -0400, Lowell Gilbert wrote: > > Dave Uhring writes: > > > > > > If a -I/some/directory is used as a CFLAG then the *include directive must read > > > > > > #include , *not* #include "driver.h". The latter demands that the > > > header file be in the same directory as the source file. > > > > Not that it necessarily affects what you're going through, but that > > last statement is incorrect. The double quotes are (according to the > > C standard) implementation defined, and gcc (like many other > > compilers) will prefer the local directory for the double quotes, but > > will search the entire search path if it doesn't find the file there. > > The problem is that gcc is *not* finding the file in the directory > referenced by the -I cflag. If I copy the header files to the directory > where the error occurs the header file is found and used to compile the > source file. This starts to narrow down the problem you're having a bit, I think. Given that this is different from the expected behavior and the behavior others are seeing, this sounds to me like either 1) the wrong compiler or version of the compiler is being found and used in place of the desired gcc instance, or 2) something in your shell or environment is somehow getting into the buildworld environment and causing make or the inner shell to misparse the commandline to gcc. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From duhring at charter.net Tue May 20 00:02:38 2008 From: duhring at charter.net (Dave Uhring) Date: Tue May 20 00:02:42 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> <20080519170428.GB77907@eos.sc1.parodius.com> <20080519182107.GC55020@charter.net> Message-ID: <20080520000236.GA1260@charter.net> On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: > On May 19, 2008, at 1:21 PM, Dave Uhring wrote: > >> In any case, that problem has been solved by putting the updated header >> files >> in /usr/include/sys and will be properly fixed when I can finally make >> installworld. > > I did not have to manually move or copy any header files. > >> *default release=cvs tag=RELENG_7 > > My build on that, csupped just after seeing your first message in this > thread, has just completed. make buildworld worked just fine without > error. I'm also on athlon64. All the headers that I needed were in the > right places in /usr/src Did you start from a RELEASE source tree and userland? > So all I can say is that things worked for me. I really suspect that you > got /usr/src and /usr/obj into some sort of inconsistent state. I completely removed both, cvsupped a new RELENG_7 source tree, removed /etc/make.conf and got this: /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: 'asm' operand has impossible constraints *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. real 8m58.524s user 7m18.995s sys 1m22.150s Solaris Nevada b_87 is installing on the server this minute instead of FreeBSD. From jeffrey at goldmark.org Tue May 20 00:04:20 2008 From: jeffrey at goldmark.org (Jeffrey Goldberg) Date: Tue May 20 00:04:37 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519182107.GC55020@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> <20080519170428.GB77907@eos.sc1.parodius.com> <20080519182107.GC55020@charter.net> Message-ID: On May 19, 2008, at 1:21 PM, Dave Uhring wrote: > In any case, that problem has been solved by putting the updated > header files > in /usr/include/sys and will be properly fixed when I can finally > make installworld. I did not have to manually move or copy any header files. > *default release=cvs tag=RELENG_7 My build on that, csupped just after seeing your first message in this thread, has just completed. make buildworld worked just fine without error. I'm also on athlon64. All the headers that I needed were in the right places in /usr/src So all I can say is that things worked for me. I really suspect that you got /usr/src and /usr/obj into some sort of inconsistent state. Cheers, -j -- Jeffrey Goldberg http://www.goldmark.org/jeff/ From peterjeremy at optushome.com.au Tue May 20 00:11:20 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue May 20 00:11:25 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519163825.GA32372@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> Message-ID: <20080519192207.GM1469@server.vk2pj.dyndns.org> On 2008-May-19 11:38:25 -0500, Dave Uhring wrote: >Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean >build. You have this backwards. If you are getting wierd buildworld errors, your first step should be to delete /usr/obj and then run 'make clean'. My guess is that you have some cruft in your /usr/src. -- 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080520/683850b1/attachment-0001.pgp From jeffrey at goldmark.org Tue May 20 01:03:59 2008 From: jeffrey at goldmark.org (Jeffrey Goldberg) Date: Tue May 20 01:04:05 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520000236.GA1260@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> <20080519170428.GB77907@eos.sc1.parodius.com> <20080519182107.GC55020@charter.net> <20080520000236.GA1260@charter.net> Message-ID: On May 19, 2008, at 7:02 PM, Dave Uhring wrote: > On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: > >> I did not have to manually move or copy any header files. > Did you start from a RELEASE source tree and userland? No. I was upgrading from STABLE last built about on April 29. However near the beginning of April I did move from RELEASE to STABLE. So several builds ago, I had moved from RELEASE to STABLE. >> So all I can say is that things worked for me. I really suspect >> that you >> got /usr/src and /usr/obj into some sort of inconsistent state. > > I completely removed both, cvsupped a new RELENG_7 source tree, > removed > /etc/make.conf and got this: > > /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ > lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ > libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ > lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - > DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ > lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o > eng_openssl.So > /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ > lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ > libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ > lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - > DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ > lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o > eng_padlock.So > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ > eng_padlock.c: In function 'padlock_xcrypt_ecb': > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ > eng_padlock.c:445: error: can't find a register in class > 'GENERAL_REGS' while reloading 'asm' > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ > eng_padlock.c:445: error: 'asm' operand has impossible constraints > *** Error code 1 > > Stop in /usr/src/secure/lib/libcrypto. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > real 8m58.524s > user 7m18.995s > sys 1m22.150s I have no idea of what the problem may be. I'm hoping that someone more knowledgeable will be able to help. What is interesting here is that this latest error does not appear to be the result of missing header files. Best of luck with this, -j From duhring at charter.net Tue May 20 01:38:37 2008 From: duhring at charter.net (Dave Uhring) Date: Tue May 20 01:38:41 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520000147.GA2824@lava.net> References: <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> <448wy6yviw.fsf@be-well.ilk.org> <20080519201408.GD79130@charter.net> <20080520000147.GA2824@lava.net> Message-ID: <20080520013825.GB1310@charter.net> On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: > On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: > > > > The problem is that gcc is *not* finding the file in the directory > > referenced by the -I cflag. If I copy the header files to the directory > > where the error occurs the header file is found and used to compile the > > source file. > > This starts to narrow down the problem you're having a bit, I think. > > Given that this is different from the expected behavior and the > behavior others are seeing, this sounds to me like either 1) the wrong > compiler or version of the compiler is being found and used in place of > the desired gcc instance, or 2) something in your shell or environment > is somehow getting into the buildworld environment and causing make or > the inner shell to misparse the commandline to gcc. The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 new header files that I placed from cvsupped sources into /usr/include/sys the entire system is 7.0 RELEASE. Prior to beginning the build I deliberately set # export CFLAGS="" Nothing else in my environment would have affected the compiler. From Mark_Andrews at isc.org Tue May 20 01:58:09 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue May 20 01:58:12 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: Your message of "Mon, 19 May 2008 20:38:25 EST." <20080520013825.GB1310@charter.net> Message-ID: <200805200158.m4K1w30H029689@drugs.dv.isc.org> > On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: > > On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: > > > > > > The problem is that gcc is *not* finding the file in the directory > > > referenced by the -I cflag. If I copy the header files to the directory > > > where the error occurs the header file is found and used to compile the > > > source file. > > > > This starts to narrow down the problem you're having a bit, I think. > > > > Given that this is different from the expected behavior and the > > behavior others are seeing, this sounds to me like either 1) the wrong > > compiler or version of the compiler is being found and used in place of > > the desired gcc instance, or 2) something in your shell or environment > > is somehow getting into the buildworld environment and causing make or > > the inner shell to misparse the commandline to gcc. > > The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 > new header files that I placed from cvsupped sources into /usr/include/sys > the entire system is 7.0 RELEASE. > > Prior to beginning the build I deliberately set > > # export CFLAGS="" This does NOT remove CFLAGS from the environment. env -i PATH=$PATH make ... will clear the enviornment and just add PATH. e.g. % env -i PATH="$PATH" SHELL="$SHELL" HOME="$HOME" printenv PATH=/home/marka/gnu/bin:/home/marka/bin/mask:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marka/bin:/usr/local/sbin SHELL=/bin/csh HOME=/home/marka % > Nothing else in my environment would have affected the compiler. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From kutulu at kutulu.org Tue May 20 01:58:24 2008 From: kutulu at kutulu.org (Mike Edenfield) Date: Tue May 20 01:58:29 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520013825.GB1310@charter.net> References: <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> <448wy6yviw.fsf@be-well.ilk.org> <20080519201408.GD79130@charter.net> <20080520000147.GA2824@lava.net> <20080520013825.GB1310@charter.net> Message-ID: <4832303D.6010103@kutulu.org> Dave Uhring wrote: > On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: > >> On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: >> >>> The problem is that gcc is *not* finding the file in the directory >>> referenced by the -I cflag. If I copy the header files to the directory >>> where the error occurs the header file is found and used to compile the >>> source file. >>> >> This starts to narrow down the problem you're having a bit, I think. >> >> Given that this is different from the expected behavior and the >> behavior others are seeing, this sounds to me like either 1) the wrong >> compiler or version of the compiler is being found and used in place of >> the desired gcc instance, or 2) something in your shell or environment >> is somehow getting into the buildworld environment and causing make or >> the inner shell to misparse the commandline to gcc. >> > > The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 > new header files that I placed from cvsupped sources into /usr/include/sys > the entire system is 7.0 RELEASE. > > Prior to beginning the build I deliberately set > > # export CFLAGS="" > > Nothing else in my environment would have affected the compiler > I suspect there is still *something* affecting your compiler, though where from I couldn't even guess. According to this message: http://gcc.gnu.org/ml/gcc-help/2007-04/msg00200.html the most recent error you posted, from inside OpenSSL, only happens if you compile the library at -O0, which is definitely not the default behavior. If you've already blown away your FreeBSD environment there's obviously not much more you can do to track down the problem, but it would be interesting to know what: make -V CFLAGS actually returned from within /usr/src. From mcdouga9 at egr.msu.edu Tue May 20 02:02:38 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Tue May 20 02:02:44 2008 Subject: Disk access/MPT under ESX3.5 In-Reply-To: <48314227.3080101@skytek.it> References: <48303A1B.9000103@skytek.it> <20080519130031.8978.A2D40D1E@fornext.org> <48314227.3080101@skytek.it> Message-ID: <20080520020236.GN39854@egr.msu.edu> On Mon, May 19, 2008 at 11:02:31AM +0200, Daniel Ponticello wrote: Hello, monitor# camcontrol negotiate 0:0 -W 16 Current Parameters: (pass0:mpt0:0:0:0): sync parameter: 0 (pass0:mpt0:0:0:0): offset: 0 (pass0:mpt0:0:0:0): bus width: 8 bits (pass0:mpt0:0:0:0): disconnection is enabled (pass0:mpt0:0:0:0): tagged queueing is enabled monitor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 32.421679 secs (32341817 bytes/sec) monitor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 20.355797 secs (51512402 bytes/sec) No improvements. But it looks like it did not renegotiated the transfers data rate that for some odd reasons are setted as 3.3MB/S instead of 320mb/s. I made some tests using linux 2.18 (debian): debiantest:/home/daniel# uname -a Linux debiantest 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686 GNU/Linux scsi0 : ioc0: LSI53C1030, FwRev=00000000h, Ports=1, MaxQ=128, IRQ=169 Vendor: VMware Model: Virtual disk Rev: 1.0 Type: Direct-Access ANSI SCSI revision: 02 target0:0:0: Beginning Domain Validation target0:0:0: Domain Validation skipping write tests target0:0:0: Ending Domain Validation target0:0:0: FAST-160 WIDE SCSI 320.0 MB/s DT IU RDSTRM RTI WRFLOW PCOMP (6.25 ns, offset 127) debiantest:/home/daniel# dd if=/dev/zero of=dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 5.01316 seconds, 209 MB/s For the Linux test, are you sure it didn't cache part of the write before returning? You may need to add some syncs and make it part of the elapsed time. Just checking because this seems to be my experience. From josh.carroll at gmail.com Tue May 20 02:08:23 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Tue May 20 02:08:27 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520013825.GB1310@charter.net> References: <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> <448wy6yviw.fsf@be-well.ilk.org> <20080519201408.GD79130@charter.net> <20080520000147.GA2824@lava.net> <20080520013825.GB1310@charter.net> Message-ID: <8cb6106e0805191908g2eb24babn4f4b3e532cc77f8e@mail.gmail.com> > The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 > new header files that I placed from cvsupped sources into /usr/include/sys > the entire system is 7.0 RELEASE. > > Prior to beginning the build I deliberately set > > # export CFLAGS="" > > Nothing else in my environment would have affected the compiler. You're not using make -j when building world are you? If so, remove that and see if it then builds properly. Josh From duhring at charter.net Tue May 20 02:51:32 2008 From: duhring at charter.net (Dave Uhring) Date: Tue May 20 02:51:38 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <200805200158.m4K1w30H029689@drugs.dv.isc.org> References: <20080520013825.GB1310@charter.net> <200805200158.m4K1w30H029689@drugs.dv.isc.org> Message-ID: <20080520025130.GA1373@charter.net> On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: > > > # export CFLAGS="" > > This does NOT remove CFLAGS from the environment. It does when you shell is bash. From josh.carroll at gmail.com Tue May 20 02:59:20 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Tue May 20 02:59:24 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520025130.GA1373@charter.net> References: <20080520013825.GB1310@charter.net> <200805200158.m4K1w30H029689@drugs.dv.isc.org> <20080520025130.GA1373@charter.net> Message-ID: <8cb6106e0805191959k943fa63l9117043d2f092ea5@mail.gmail.com> > On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: >> >> > # export CFLAGS="" >> >> This does NOT remove CFLAGS from the environment. > > It does when you shell is bash. I think what Mark was getting at is that simply setting CFLAGS to "" prior to make does not trump the setting of CFLAGS in make.conf/src.conf. So if you haven't removed/commented that from your make.conf, the export command above will do nothing for the actual build environment. Josh From duhring at charter.net Tue May 20 03:01:30 2008 From: duhring at charter.net (Dave Uhring) Date: Tue May 20 03:01:34 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <8cb6106e0805191908g2eb24babn4f4b3e532cc77f8e@mail.gmail.com> References: <20080519165421.GA62264@charter.net> <20080519170223.GH7468@bunrab.catwhisker.org> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> <448wy6yviw.fsf@be-well.ilk.org> <20080519201408.GD79130@charter.net> <20080520000147.GA2824@lava.net> <20080520013825.GB1310@charter.net> <8cb6106e0805191908g2eb24babn4f4b3e532cc77f8e@mail.gmail.com> Message-ID: <20080520030118.GC1373@charter.net> On Mon, May 19, 2008 at 10:08:22PM -0400, Josh Carroll wrote: > > The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 > > new header files that I placed from cvsupped sources into /usr/include/sys > > the entire system is 7.0 RELEASE. > > > > Prior to beginning the build I deliberately set > > > > # export CFLAGS="" > > > > Nothing else in my environment would have affected the compiler. > > You're not using make -j when building world are you? If so, remove > that and see if it then builds properly. No, even though it is a dual-core system. I did not want to chance a race condition. I simply executed 'make buildworld' initially, then 'make -DNO_CLEAN buildworld' when I encountered problems in the build. From josh.carroll at gmail.com Tue May 20 03:10:34 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Tue May 20 03:10:38 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520030118.GC1373@charter.net> References: <20080519165421.GA62264@charter.net> <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> <448wy6yviw.fsf@be-well.ilk.org> <20080519201408.GD79130@charter.net> <20080520000147.GA2824@lava.net> <20080520013825.GB1310@charter.net> <8cb6106e0805191908g2eb24babn4f4b3e532cc77f8e@mail.gmail.com> <20080520030118.GC1373@charter.net> Message-ID: <8cb6106e0805192010n4bf6afb5hac521f81ebf16b63@mail.gmail.com> > No, even though it is a dual-core system. I did not want to chance a > race condition. I simply executed 'make buildworld' initially, then > 'make -DNO_CLEAN buildworld' when I encountered problems in the build. Ok, it was worth asking, just to rule out the obvious. I'm still not sure where your logic in using -DNOCLEAN comes in, for a failed build. I would expect that to continue to fail in most circumstances if it were already failing. So I think in one of your other mails you said you're installing something else now? Solaris? If so, this thread is moot, since you aren't running FreeBSD on the box anymore, and no one has been able to reproduce your problem. I think the most likely culprits have already been mentioned in the thread so far anyway. Josh From Mark_Andrews at isc.org Tue May 20 03:25:03 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue May 20 03:25:06 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: Your message of "Mon, 19 May 2008 21:51:30 EST." <20080520025130.GA1373@charter.net> Message-ID: <200805200324.m4K3Ow5J030607@drugs.dv.isc.org> > On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: > > > > > # export CFLAGS="" > > > > This does NOT remove CFLAGS from the environment. > > It does when you shell is bash. bash is broken. Empty environment variables have meaning. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From duhring at charter.net Tue May 20 03:29:59 2008 From: duhring at charter.net (Dave Uhring) Date: Tue May 20 03:30:03 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <8cb6106e0805191959k943fa63l9117043d2f092ea5@mail.gmail.com> References: <20080520013825.GB1310@charter.net> <200805200158.m4K1w30H029689@drugs.dv.isc.org> <20080520025130.GA1373@charter.net> <8cb6106e0805191959k943fa63l9117043d2f092ea5@mail.gmail.com> Message-ID: <20080520032955.GA1428@charter.net> On Mon, May 19, 2008 at 10:59:18PM -0400, Josh Carroll wrote: > > On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: > >> > >> > # export CFLAGS="" > >> > >> This does NOT remove CFLAGS from the environment. > > > > It does when you shell is bash. > > I think what Mark was getting at is that simply setting CFLAGS to "" > prior to make does not trump the setting of CFLAGS in > make.conf/src.conf. So if you haven't removed/commented that from > your make.conf, the export command above will do nothing for the > actual build environment. Before that last build I had removed /etc/make.conf and had never touched src.conf. CFLAGS was empty. From Mark_Andrews at isc.org Tue May 20 03:33:19 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue May 20 03:33:22 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: Your message of "Tue, 20 May 2008 13:24:58 +1000." <200805200324.m4K3Ow5J030607@drugs.dv.isc.org> Message-ID: <200805200333.m4K3XF72030784@drugs.dv.isc.org> > > > On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: > > > > > > > # export CFLAGS="" > > > > > > This does NOT remove CFLAGS from the environment. > > > > It does when you shell is bash. > > bash is broken. Empty environment variables have meaning. > > Mark And when tested does behave the way you describe. Mark drugs:9.5.x 13:30 {4371} % bash [marka@drugs ~/cvs/9.5.x]$ printenv | grep FOO [marka@drugs ~/cvs/9.5.x]$ FOO=ll [marka@drugs ~/cvs/9.5.x]$ export FOO [marka@drugs ~/cvs/9.5.x]$ printenv | grep FOO FOO=ll [marka@drugs ~/cvs/9.5.x]$ FOO="" [marka@drugs ~/cvs/9.5.x]$ export FOO [marka@drugs ~/cvs/9.5.x]$ printenv | grep FOO FOO= [marka@drugs ~/cvs/9.5.x]$ env -i PATH=$PATH printenv | grep FOO [marka@drugs ~/cvs/9.5.x]$ > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From duhring at charter.net Tue May 20 03:37:51 2008 From: duhring at charter.net (Dave Uhring) Date: Tue May 20 03:37:58 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <8cb6106e0805192010n4bf6afb5hac521f81ebf16b63@mail.gmail.com> References: <20080519175358.GB55020@charter.net> <20080519180201.GI7468@bunrab.catwhisker.org> <20080519183614.GB55295@charter.net> <448wy6yviw.fsf@be-well.ilk.org> <20080519201408.GD79130@charter.net> <20080520000147.GA2824@lava.net> <20080520013825.GB1310@charter.net> <8cb6106e0805191908g2eb24babn4f4b3e532cc77f8e@mail.gmail.com> <20080520030118.GC1373@charter.net> <8cb6106e0805192010n4bf6afb5hac521f81ebf16b63@mail.gmail.com> Message-ID: <20080520033745.GB1428@charter.net> On Mon, May 19, 2008 at 11:10:32PM -0400, Josh Carroll wrote: > > No, even though it is a dual-core system. I did not want to chance a > > race condition. I simply executed 'make buildworld' initially, then > > 'make -DNO_CLEAN buildworld' when I encountered problems in the build. > > Ok, it was worth asking, just to rule out the obvious. > > I'm still not sure where your logic in using -DNOCLEAN comes in, for a > failed build. I would expect that to continue to fail in most > circumstances if it were already failing. If you fix what caused the build to break and want to find any other failure points there is little point in restarting the build from zero. > So I think in one of your other mails you said you're installing > something else now? Solaris? If so, this thread is moot, since you > aren't running FreeBSD on the box anymore, and no one has been able to > reproduce your problem. I think the most likely culprits have already > been mentioned in the thread so far anyway. I would still like to get FreeBSD on that server but with the latest improvements to ZFS. The release version is not going to do that for me and the only way that I can get up-to-date binaries is to build a new world and kernel. I'll give it another days' try and if that still fails Solaris will stay on the server. This BTW is not my first time building world on FreeBSD. I followed STABLE from 3.4 through the end of RELENG_4 and I never had such problems with a simple compile. From koitsu at FreeBSD.org Tue May 20 04:32:27 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue May 20 04:32:31 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519200342.GA79130@charter.net> References: <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519165925.GA77907@eos.sc1.parodius.com> <20080519170334.GA74159@charter.net> <20080519170619.GC77907@eos.sc1.parodius.com> <20080519180028.GA79392@eos.sc1.parodius.com> <20080519191646.GA82513@eos.sc1.parodius.com> <20080519200342.GA79130@charter.net> Message-ID: <20080520043227.GA7937@eos.sc1.parodius.com> On Mon, May 19, 2008 at 03:03:42PM -0500, Dave Uhring wrote: > [root@maxwell /usr/src/contrib/groff]# mount > /dev/ad4s2a on / (ufs, local, soft-updates) > devfs on /dev (devfs, local) > /dev/ad4s2h on /home (ufs, local, soft-updates) > /dev/ad4s2e on /usr (ufs, local, soft-updates) > /dev/ad4s2g on /usr/local (ufs, local, soft-updates) > /dev/ad4s2d on /var (ufs, local, soft-updates) > /dev/md0 on /tmp (ufs, local, soft-updates) > /dev/ad4s2f on /usr/obj (ufs, asynchronous, local, noatime) > [root@maxwell /usr/src/contrib/groff]# > > Not even an NFS mount. I'm trying to update to FreeBSD-STABLE to use on my > home file server. At present it has OpenSolaris installed but that OS does > not have the Ethernet driver I need and I want to be able to use 2 Adaptec > 29160N HBAs in the system. But I only have 2 PCI slots and I would like to > remove the Intel NIC and use the system's on-board nfe NIC. > > I'll blow away /usr/src and /usr/obj, cvsup the entire RELENG_7 source tree > again and once more attempt to buildworld. If that fails, Solaris stays on > the server. And please be sure to nuke /var/db/sup/src-all (or /usr/sup/src-all if you're using cvsup for some reason). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Tue May 20 04:35:23 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue May 20 04:35:27 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080519191646.GA82513@eos.sc1.parodius.com> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519165421.GA62264@charter.net> <20080519165925.GA77907@eos.sc1.parodius.com> <20080519170334.GA74159@charter.net> <20080519170619.GC77907@eos.sc1.parodius.com> <20080519180028.GA79392@eos.sc1.parodius.com> <20080519191646.GA82513@eos.sc1.parodius.com> Message-ID: <20080520043522.GA8158@eos.sc1.parodius.com> On Mon, May 19, 2008 at 12:16:46PM -0700, Jeremy Chadwick wrote: > I will attempt the same with your make.conf to see if it's any > different. I'll add that while I slept, I let a 'make buildworld' go with your exact make.conf flags -- it completed successfully. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ertr1013 at student.uu.se Tue May 20 06:14:29 2008 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Tue May 20 06:14:34 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520000236.GA1260@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> <20080519170428.GB77907@eos.sc1.parodius.com> <20080519182107.GC55020@charter.net> <20080520000236.GA1260@charter.net> Message-ID: <20080520055813.GA13031@owl.midgard.homeip.net> On Mon, May 19, 2008 at 07:02:36PM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: > > On May 19, 2008, at 1:21 PM, Dave Uhring wrote: > > > >> In any case, that problem has been solved by putting the updated header > >> files > >> in /usr/include/sys and will be properly fixed when I can finally make > >> installworld. > > > > I did not have to manually move or copy any header files. > > > >> *default release=cvs tag=RELENG_7 > > > > My build on that, csupped just after seeing your first message in this > > thread, has just completed. make buildworld worked just fine without > > error. I'm also on athlon64. All the headers that I needed were in the > > right places in /usr/src > > Did you start from a RELEASE source tree and userland? > > > So all I can say is that things worked for me. I really suspect that you > > got /usr/src and /usr/obj into some sort of inconsistent state. > > I completely removed both, cvsupped a new RELENG_7 source tree, removed > /etc/make.conf and got this: > If I were you I would suspect hardware problems. In particular bad memory - that is often the reason behind the kind of wierd errors you have been seeing. (Suspect number two would be overheating of some component.) In your place I would run memtest86 (for several full passes) to check the memory. > /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So > /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c: In function 'padlock_xcrypt_ecb': > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: 'asm' operand has impossible constraints > *** Error code 1 > > Stop in /usr/src/secure/lib/libcrypto. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > real 8m58.524s > user 7m18.995s > sys 1m22.150s > > Solaris Nevada b_87 is installing on the server this minute instead of > FreeBSD. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Erik Trulsson ertr1013@student.uu.se From peterjeremy at optushome.com.au Tue May 20 07:43:01 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue May 20 07:43:05 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520025130.GA1373@charter.net> References: <20080520013825.GB1310@charter.net> <200805200158.m4K1w30H029689@drugs.dv.isc.org> <20080520025130.GA1373@charter.net> Message-ID: <20080520074255.GT1469@server.vk2pj.dyndns.org> On 2008-May-19 21:51:30 -0500, Dave Uhring wrote: >On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: >> >> > # export CFLAGS="" >> >> This does NOT remove CFLAGS from the environment. > >It does when you shell is bash. As Mark pointed out, this just means bash is broken. Note that the FreeBSD build toolset is designed to work with sh - if you've managed to convince make to use bash, you may have run into an incompatibility that is causing your buildworld failures. -- 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080520/b9f9ef59/attachment.pgp From dfr at rabson.org Tue May 20 07:50:16 2008 From: dfr at rabson.org (Doug Rabson) Date: Tue May 20 07:50:20 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520000236.GA1260@charter.net> References: <20080519151739.GA50653@charter.net> <4AB77C7C-55F7-4CC3-B842-E684F6C899E3@rabson.org> <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> <20080519170428.GB77907@eos.sc1.parodius.com> <20080519182107.GC55020@charter.net> <20080520000236.GA1260@charter.net> Message-ID: <66004354-F227-4008-A453-7158430D769B@rabson.org> On 20 May 2008, at 01:02, Dave Uhring wrote: > On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: >> On May 19, 2008, at 1:21 PM, Dave Uhring wrote: >> >>> In any case, that problem has been solved by putting the updated >>> header >>> files >>> in /usr/include/sys and will be properly fixed when I can finally >>> make >>> installworld. >> >> I did not have to manually move or copy any header files. >> >>> *default release=cvs tag=RELENG_7 >> >> My build on that, csupped just after seeing your first message in >> this >> thread, has just completed. make buildworld worked just fine without >> error. I'm also on athlon64. All the headers that I needed were >> in the >> right places in /usr/src > > Did you start from a RELEASE source tree and userland? > >> So all I can say is that things worked for me. I really suspect >> that you >> got /usr/src and /usr/obj into some sort of inconsistent state. > > I completely removed both, cvsupped a new RELENG_7 source tree, > removed > /etc/make.conf and got this: > > /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ > lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ > libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ > lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - > DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ > lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o > eng_openssl.So > /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ > lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ > libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ > lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - > DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ > lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o > eng_padlock.So > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ > eng_padlock.c: In function 'padlock_xcrypt_ecb': > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ > eng_padlock.c:445: error: can't find a register in class > 'GENERAL_REGS' while reloading 'asm' > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ > eng_padlock.c:445: error: 'asm' operand has impossible constraints In this, your build is explicitly using '/usr/bin/gcc' for the build which is not the way buildworld normally works. In normal operation, buildworld first builds a compiler from source and then uses that compiler by adding to $PATH and building with just 'cc'. Are you overriding $CC in your environment? From duhring at charter.net Tue May 20 07:51:23 2008 From: duhring at charter.net (Dave Uhring) Date: Tue May 20 07:51:28 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <200805200333.m4K3XF72030784@drugs.dv.isc.org> References: <200805200324.m4K3Ow5J030607@drugs.dv.isc.org> <200805200333.m4K3XF72030784@drugs.dv.isc.org> Message-ID: <20080520075121.GA1512@charter.net> On Tue, May 20, 2008 at 01:33:15PM +1000, Mark Andrews wrote: > > And when tested does behave the way you describe. > > Mark > > drugs:9.5.x 13:30 {4371} % bash > [marka@drugs ~/cvs/9.5.x]$ printenv | grep FOO > [marka@drugs ~/cvs/9.5.x]$ FOO=ll > [marka@drugs ~/cvs/9.5.x]$ export FOO > [marka@drugs ~/cvs/9.5.x]$ printenv | grep FOO > FOO=ll > [marka@drugs ~/cvs/9.5.x]$ FOO="" > [marka@drugs ~/cvs/9.5.x]$ export FOO > [marka@drugs ~/cvs/9.5.x]$ printenv | grep FOO > FOO= > [marka@drugs ~/cvs/9.5.x]$ env -i PATH=$PATH printenv | grep FOO > [marka@drugs ~/cvs/9.5.x]$ This is Solaris but bash is bash: [duhring@einstein ~]$ printenv | grep CFLAGS CFLAGS=-xO3 -m32 -xarch=native -mt -I/usr/sfw/include -I/usr/X11/include -I/opt/sfw/include You have mail in /var/mail/duhring [duhring@einstein ~]$ export CFLAGS="" [duhring@einstein ~]$ printenv | grep CFLAGS CFLAGS= [duhring@einstein ~]$ export CFLAGS='-xO3 -m32 -xarch=native' [duhring@einstein ~]$ printenv | grep CFLAGS CFLAGS=-xO3 -m32 -xarch=native [duhring@einstein ~]$ export CFLAGS="" [duhring@einstein ~]$ printenv | grep CFLAGS CFLAGS= [duhring@einstein ~]$ env -i PATH=$PATH printenv | grep CFLAGS [duhring@einstein ~]$ When I tell you that CFLAGS="", CFLAGS="", and a cursory examination of my last compiler output would have shown you exactly that. From sweetnavelorange at gmail.com Tue May 20 09:55:33 2008 From: sweetnavelorange at gmail.com (James Butler) Date: Tue May 20 09:55:38 2008 Subject: Suspend/resume on IBM X31 In-Reply-To: <20080519111533.GA64088@eos.sc1.parodius.com> References: <20080519111533.GA64088@eos.sc1.parodius.com> Message-ID: On Mon, May 19, 2008 at 11:15 PM, Jeremy Chadwick wrote: > On Mon, May 19, 2008 at 10:24:43PM +1200, James Butler wrote: >> Second problem: When the system panics, I don't get a dump (or >> textdump for that matter, when I turn them on); in the boot messages, >> I see "kernel dumps on /dev/ad0s2b" and then later (from memory), >> "Looking for core dumps on /dev/ad0s2b.... savecore: no dumps found" >> or somesuch. I know from trying out textdumps that dumping works in >> other circumstances. > > This is a known problem, but is difficult to solve (chicken-and-egg > situation). There's an open PR for it. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > Thanks for the pointer, but this doesn't seem to exactly match my situation. I can boot to single-user after a panic, no swap, and savecore still tells me that there's no dump present; conversely (I should have made this clearer) kernel dumps work for me when the panic is triggered in other ways (eg. by switching vt's too quickly from X - don't know why). Maybe tomorrow I'll try manually transcribing some DDB output, but for me the more interesting problem is why /etc/rc.suspend is not executed. I haven't even thought about /etc/rc.resume yet :-) Thanks, -James Butler From duhring at charter.net Tue May 20 13:31:30 2008 From: duhring at charter.net (Dave Uhring) Date: Tue May 20 13:31:35 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: References: <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> <20080519170428.GB77907@eos.sc1.parodius.com> <20080519182107.GC55020@charter.net> <20080520000236.GA1260@charter.net> <66004354-F227-4008-A453-7158430D769B@rabson.org> <20080520112536.GB1637@charter.net> Message-ID: <20080520133120.GA1703@charter.net> On Tue, May 20, 2008 at 12:54:59PM +0100, Doug Rabson wrote: > > On 20 May 2008, at 12:25, Dave Uhring wrote: > >> On Tue, May 20, 2008 at 08:50:14AM +0100, Doug Rabson wrote: >>> >>> In this, your build is explicitly using '/usr/bin/gcc' for the build >>> which >>> is not the way buildworld normally works. In normal operation, buildworld >>> first builds a compiler from source and then uses that compiler by adding >>> to $PATH and building with just 'cc'. Are you overriding $CC in your >>> environment? >> >> I did not even have $CC in my environment. My environment had absolutely >> nothing involving the compiler and the compiler was the one shipped with >> FreeBSD-7.0-RELEASE. It is the *only* compiler on the system. >> > > Odd. Could you please send me the complete log of a failed build attempt. I did not maintain such a log. On that last build everything proceeded normally until it broke in an inline assembler piece of code. But I published not only the error but also the previous 4 or 5 compile lines. I'm building again with a virgin clean cvsupped source tree from cvsup4.freebsd.org, a clean /usr/obj, and I have reverted to /bin/csh for my root shell if that can possibly matter. /etc/make.conf sets the build shell as /bin/sh. This time I started the build using script. The entire log will be available. From duhring at charter.net Tue May 20 14:24:15 2008 From: duhring at charter.net (Dave Uhring) Date: Tue May 20 14:24:21 2008 Subject: Buildworld Fails RELENG_7 Message-ID: <20080520142411.GA18695@charter.net> Tried again this morning with a fresh cvsup from cvsup4.freebsd.org and the build went to completion. maxwell# grep -v ^# /etc/make.conf CPUTYPE?=k8 CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 CXXFLAGS+= -fconserve-space MAKE_SHELL?=sh COPTFLAGS= -O -pipe INSTALL=install -C MTREE_FOLLOWS_SYMLINKS= -L ENABLE_SUID_SSH= NO_SENDMAIL= NO_PROFILE= DOC_LANG= en_US.ISO8859-1 maxwell# printenv MACHTYPE=i386 USER=root MAIL=/var/mail/root SHLVL=2 VENDOR=intel HOME=/root PAGER=more GROUP=wheel LOGNAME=root TERM=xterm BLOCKSIZE=K WINDOWPATH=9 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin REMOTEHOST= DISPLAY=:0.0 XAUTHORITY=/root/.Xauthority HOST=maxwell.uhring.com SHELL=/bin/csh OSTYPE=FreeBSD PWD=/root FTP_PASSIVE_MODE=YES HOSTTYPE=FreeBSD EDITOR=vi WINDOWID=14680077 XTERM_VERSION=XTerm(235) XTERM_LOCALE=C TERMCAP=xterm|xterm-color|X11 terminal emulator:ti@:te@:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:kH=\EOF:@7=\EOF:kI=\E[2~:kh=\EOH:*6=\EOF:kP=\E[5~:kN=\E[6~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:Km=\E[M:li#24:co#80:am:kn#12:km:mi:ms:xn:AX:bl=^G:is=\E[!p\E[?3;4l\E[4l\E>:rs=\E[!p\E[?3;4l\E[4l\E>:le=^H:AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:al=\E[L:dc=\E[P:dl=\E[M:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:ho=\E[H:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l:ks=\E[?1h\E=:ke=\E[?1l\E>:kD=\E[3~:sf=\n:sr=\EM:st=\EH:ct=\E[3g:sc=\E7:rc=\E8:eA=\E(B\E)0:as=\E(0:ae=\E(B:ml=\El:mu=\Em:up=\E[A:nd=\E[C:md=\E[1m:me=\E[m:mr=\E[7m:so=\E[7m:se=\E[27m:us=\E[4m:ue=\E[24m:vi=\E[?25l:ve=\E[?25h:ut:Co#8:pa#64:op=\E[39;49m:AB=\E[4%dm:AF=\E[3%dm:kb=\010: XTERM_SHELL=/bin/csh Note the last line. Even if /etc/make.conf specifies the build shell, that is apparently ignored in the build process. The CPUTYPE in /etc/make.conf is also ignored and make chooses one from thin air apparently since the cflags used in the build are shown in the last line of the compile: cc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=\"/usr/share/zoneinfo\" -Demkdir=mkdir -I/usr/src/usr.sbin/zic/zdump/.. -I/usr/src/usr.sbin/zic/zdump/../../../lib/libc/stdtime -o zdump zdump.o ialloc.o scheck.o I specified CPUTYPE?=k8 but make chose -march=athlon-mp. Thanks to all who tried to help. From dfr at rabson.org Tue May 20 14:27:33 2008 From: dfr at rabson.org (Doug Rabson) Date: Tue May 20 14:27:37 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520133120.GA1703@charter.net> References: <20080519163825.GA32372@charter.net> <20080519164221.GA76691@eos.sc1.parodius.com> <20080519165807.GB62264@charter.net> <20080519170428.GB77907@eos.sc1.parodius.com> <20080519182107.GC55020@charter.net> <20080520000236.GA1260@charter.net> <66004354-F227-4008-A453-7158430D769B@rabson.org> <20080520112536.GB1637@charter.net> <20080520133120.GA1703@charter.net> Message-ID: <96F8BC8E-C933-4568-8AF6-83C7566EB6A1@rabson.org> On 20 May 2008, at 14:31, Dave Uhring wrote: > On Tue, May 20, 2008 at 12:54:59PM +0100, Doug Rabson wrote: >> >> On 20 May 2008, at 12:25, Dave Uhring wrote: >> >>> On Tue, May 20, 2008 at 08:50:14AM +0100, Doug Rabson wrote: >>>> >>>> In this, your build is explicitly using '/usr/bin/gcc' for the >>>> build >>>> which >>>> is not the way buildworld normally works. In normal operation, >>>> buildworld >>>> first builds a compiler from source and then uses that compiler >>>> by adding >>>> to $PATH and building with just 'cc'. Are you overriding $CC in >>>> your >>>> environment? >>> >>> I did not even have $CC in my environment. My environment had >>> absolutely >>> nothing involving the compiler and the compiler was the one >>> shipped with >>> FreeBSD-7.0-RELEASE. It is the *only* compiler on the system. >>> >> >> Odd. Could you please send me the complete log of a failed build >> attempt. > > I did not maintain such a log. On that last build everything > proceeded > normally until it broke in an inline assembler piece of code. But I > published not only the error but also the previous 4 or 5 compile > lines. > > I'm building again with a virgin clean cvsupped source tree from > cvsup4.freebsd.org, a clean /usr/obj, and I have reverted to /bin/ > csh for > my root shell if that can possibly matter. /etc/make.conf sets the > build > shell as /bin/sh. > > This time I started the build using script. The entire log will be > available. Excellent. Thanks for your help tracking this down. From koitsu at FreeBSD.org Tue May 20 14:33:14 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue May 20 14:33:19 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520142411.GA18695@charter.net> References: <20080520142411.GA18695@charter.net> Message-ID: <20080520143313.GA34595@eos.sc1.parodius.com> On Tue, May 20, 2008 at 09:24:11AM -0500, Dave Uhring wrote: > cc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=\"/usr/share/zoneinfo\" -Demkdir=mkdir -I/usr/src/usr.sbin/zic/zdump/.. -I/usr/src/usr.sbin/zic/zdump/../../../lib/libc/stdtime -o zdump zdump.o ialloc.o scheck.o > > I specified CPUTYPE?=k8 but make chose -march=athlon-mp. So? This is normal. Look at /usr/share/mk/bsd.cpu.mk. I see this code: . elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || ${CPUTYPE} == "k8" CPUTYPE = athlon-mp There's your answer for that. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ivoras at freebsd.org Tue May 20 14:38:29 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue May 20 14:38:36 2008 Subject: ubench on v6 a v7 In-Reply-To: <48312000.9030102@gyrec.cz> References: <48312000.9030102@gyrec.cz> Message-ID: Karel Rous wrote: > My home computer (no internet access, cannot share results :-) is > single processor Athlon 64 on 2250 Mhz/512 KB L2. Visually I have seen > that on stable it doesn't behave as speedily as on FreeBSD number 6. I > have checked utility in subject (which is probably not the best > alternative) and it shows me on memory test half of the speed that was > in v6 while using default MALLOC_OPTIONS at each version. There could be > certain speed up changing it but IMHO there can not be any we to make it > as fast as in previous version. Is there anyone who could make a logical > explanation? (I think it has something to do with new malloc > optimization for multi processor systems but I might compiled also libc > on FreeBSD 7 with wrong options). Even using simple compat6x libc (with > libmap.conf) helps to speed up things there. > All those measurement are my just my non generalized opinion and I > hope I am wrong :-) If you can confirm your results in a clean environment, you might want to talk to jasone@ about this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080520/8e949d4a/signature.pgp From ertr1013 at student.uu.se Tue May 20 14:41:20 2008 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Tue May 20 14:41:28 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520142411.GA18695@charter.net> References: <20080520142411.GA18695@charter.net> Message-ID: <20080520144114.GA15826@owl.midgard.homeip.net> On Tue, May 20, 2008 at 09:24:11AM -0500, Dave Uhring wrote: > Tried again this morning with a fresh cvsup from cvsup4.freebsd.org and the > build went to completion. > > maxwell# grep -v ^# /etc/make.conf > CPUTYPE?=k8 > CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 > CXXFLAGS+= -fconserve-space > MAKE_SHELL?=sh > COPTFLAGS= -O -pipe > INSTALL=install -C > MTREE_FOLLOWS_SYMLINKS= -L > ENABLE_SUID_SSH= > NO_SENDMAIL= > NO_PROFILE= > DOC_LANG= en_US.ISO8859-1 > > maxwell# printenv > MACHTYPE=i386 > USER=root > MAIL=/var/mail/root > SHLVL=2 > VENDOR=intel > HOME=/root > PAGER=more > GROUP=wheel > LOGNAME=root > TERM=xterm > BLOCKSIZE=K > WINDOWPATH=9 > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > REMOTEHOST= > DISPLAY=:0.0 > XAUTHORITY=/root/.Xauthority > HOST=maxwell.uhring.com > SHELL=/bin/csh > OSTYPE=FreeBSD > PWD=/root > FTP_PASSIVE_MODE=YES > HOSTTYPE=FreeBSD > EDITOR=vi > WINDOWID=14680077 > XTERM_VERSION=XTerm(235) > XTERM_LOCALE=C > TERMCAP=xterm|xterm-color|X11 terminal emulator:ti@:te@:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:kH=\EOF:@7=\EOF:kI=\E[2~:kh=\EOH:*6=\EOF:kP=\E[5~:kN=\E[6~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:Km=\E[M:li#24:co#80:am:kn#12:km:mi:ms:xn:AX:bl=^G:is=\E[!p\E[?3;4l\E[4l\E>:rs=\E[!p\E[?3;4l\E[4l\E>:le=^H:AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:al=\E[L:dc=\E[P:dl=\E[M:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:ho=\E[H:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l:ks=\E[?1h\E=:ke=\E[?1l\E>:kD=\E[3~:sf=\n:sr=\EM:st=\EH:ct=\E[3g:sc=\E7:rc=\E8:eA=\E(B\E)0:as=\E(0:ae=\E(B:ml=\El:mu=\Em:up=\E[A:nd=\E[C:md=\E[1m:me=\E[m:mr=\E[7m:so=\E[7m:se=\E[27m:us=\E[4m:ue=\E[24m:vi=\E[?25l:ve=\E[?25h:ut:Co#8:pa#64:op=\E[39;49m:AB=\E[4%dm:AF=\E[3%dm:kb=\010: > XTERM_SHELL=/bin/csh > > Note the last line. Even if /etc/make.conf specifies the build shell, that > is apparently ignored in the build process. I do not think the build process cares even slightly which shell is used for xterm. > > The CPUTYPE in /etc/make.conf is also ignored and make chooses one from thin > air apparently since the cflags used in the build are shown in the last line > of the compile: > > cc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=\"/usr/share/zoneinfo\" -Demkdir=mkdir -I/usr/src/usr.sbin/zic/zdump/.. -I/usr/src/usr.sbin/zic/zdump/../../../lib/libc/stdtime -o zdump zdump.o ialloc.o scheck.o > > I specified CPUTYPE?=k8 but make chose -march=athlon-mp. Yes, it is supposed to do that. It used to be the case that gcc did not have any specific -march or -mcpu flags or optimizations for the K8 architecture, so the make system chooses -march=athlon-mp since that is the closest architecture that can be specified. (Look in /usr/share/mk/bsd.cpu.mk too see how it chooses -march flags based on your setting of CPUTYPE.) I am fairly certain however that gcc 4.x does know about the K8 CPUs these days, so somebody should probably go through bsd.cpu.mk and update it for the latest gcc (at least for -CURRENT.) -- Erik Trulsson ertr1013@student.uu.se From kutulu at kutulu.org Tue May 20 14:41:40 2008 From: kutulu at kutulu.org (Mike Edenfield) Date: Tue May 20 14:41:45 2008 Subject: Buildworld Fails RELENG_7 In-Reply-To: <20080520142411.GA18695@charter.net> References: <20080520142411.GA18695@charter.net> Message-ID: <4832E319.7080102@kutulu.org> Dave Uhring wrote: > cc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=\"/usr/share/zoneinfo\" -Demkdir=mkdir -I/usr/src/usr.sbin/zic/zdump/.. -I/usr/src/usr.sbin/zic/zdump/../../../lib/libc/stdtime -o zdump zdump.o ialloc.o scheck.o > > I specified CPUTYPE?=k8 but make chose -march=athlon-mp. This part is behaving as expected for FreeBSD; the make process coverts any of the athlon64 cpu types into athlon-mp. Based on the gcc documentation I don't think it makes much difference; the only discrepancy between the two seems the presence of the 64-bit instruction set. From olli at lurza.secnetix.de Tue May 20 16:21:07 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue May 20 16:21:10 2008 Subject: syslog console log not logging SCSI problems In-Reply-To: <60281.1210842841@thrush.ravenbrook.com> Message-ID: <200805201621.m4KGL1WU067028@lurza.secnetix.de> Nick Barnes wrote: > One of our FreeBSD boxes has a SCSI controller and disk, which showed > problems earlier this week. There was a lot of of chatter from the > SCSI driver in /var/log/messages and to the console. However, the > console is unattended and we only discovered the problem subsequently > because /var/log/console.log didn't show any of the chatter. The console.* syslog facility only logs real console output, i.e. things written to /dev/console. That does _not_ include output from the kernel. For logging kernel output you have to use the kern.* syslog facility. 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 "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio From dick at nagual.nl Tue May 20 19:25:44 2008 From: dick at nagual.nl (Dick Hoogendijk) Date: Tue May 20 19:25:48 2008 Subject: Status of ZFS in -stable? In-Reply-To: <5f67a8c40805181740v6f655fdjdfaec3312681b5c9@mail.gmail.com> References: <48291889.8030406@pldrouin.net> <20080514223515.84553317.ubm@u-boot-man.de> <5f67a8c40805181740v6f655fdjdfaec3312681b5c9@mail.gmail.com> Message-ID: <20080520190804.GA17271@shire.nagual.nl> On 18 May Zaphod Beeblebrox wrote: > However, when using Norton Ghost to make backup snapshots, the files > (on ZFS) come out corrupt. They are not corrupt on UFS backed SAMBA > service. Since when does Norton Ghost claim to support ZFS? If not, how can you expect the files *not* to be corrupted? -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D ++ http://nagual.nl/ | SunOS 10u4 08/07 ++ From fjwcash at gmail.com Tue May 20 20:18:13 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Tue May 20 20:18:17 2008 Subject: Status of ZFS in -stable? In-Reply-To: <20080520190804.GA17271@shire.nagual.nl> References: <48291889.8030406@pldrouin.net> <5f67a8c40805181740v6f655fdjdfaec3312681b5c9@mail.gmail.com> <20080520190804.GA17271@shire.nagual.nl> Message-ID: <200805201249.39201.fjwcash@gmail.com> On May 20, 2008 12:08 pm Dick Hoogendijk wrote: > On 18 May Zaphod Beeblebrox wrote: > > However, when using Norton Ghost to make backup snapshots, the files > > (on ZFS) come out corrupt. They are not corrupt on UFS backed SAMBA > > service. > > Since when does Norton Ghost claim to support ZFS? > If not, how can you expect the files *not* to be corrupted? I believe he is using Samba to share the ZFS filesystem, and that Norton Ghost connects to the system via SMB/CIFS. When he configures the Samba share to use a UFS filesystem, everything works. When he configures the Samba share to use a ZFS filesystem, everything is corrupted. -- Freddie Cash fjwcash@gmail.com From zbeeble at gmail.com Wed May 21 00:47:59 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Wed May 21 00:48:02 2008 Subject: Status of ZFS in -stable? In-Reply-To: <200805201249.39201.fjwcash@gmail.com> References: <48291889.8030406@pldrouin.net> <5f67a8c40805181740v6f655fdjdfaec3312681b5c9@mail.gmail.com> <20080520190804.GA17271@shire.nagual.nl> <200805201249.39201.fjwcash@gmail.com> Message-ID: <5f67a8c40805201747p79e34870qaa842ab034e133d1@mail.gmail.com> On Tue, May 20, 2008 at 3:49 PM, Freddie Cash wrote: > On May 20, 2008 12:08 pm Dick Hoogendijk wrote: > > On 18 May Zaphod Beeblebrox wrote: > > > However, when using Norton Ghost to make backup snapshots, the files > > > (on ZFS) come out corrupt. They are not corrupt on UFS backed SAMBA > > > service. > > > > Since when does Norton Ghost claim to support ZFS? > > If not, how can you expect the files *not* to be corrupted? > > I believe he is using Samba to share the ZFS filesystem, and that Norton > Ghost connects to the system via SMB/CIFS. > > When he configures the Samba share to use a UFS filesystem, everything > works. > > When he configures the Samba share to use a ZFS filesystem, everything is > corrupted. Correct. If I don't use "verify" ... the backup proceeds normally, but it's corrupt. If I turn on verify, the backup stops when it detects the corruption (somewhere about halfway through). This is with XP using a Samba-shared ZFS filesystem. When XP uses a samba shared UFS filesystem, all is good. Additionally, I tried telling samba _not_ to use mmap() (there's an option), but this didn't fix things. From admin at gyrec.cz Wed May 21 07:45:57 2008 From: admin at gyrec.cz (Karel Rous) Date: Wed May 21 07:46:01 2008 Subject: ubench on v6 a v7 In-Reply-To: References: <48312000.9030102@gyrec.cz> Message-ID: <4833D332.5020800@gyrec.cz> It needs further exploration on different hw as well. I will try but it'll take quite a long time :-) Ivan Voras wrote: > Karel Rous wrote: >> My home computer (no internet access, cannot share results :-) is >> single processor Athlon 64 on 2250 Mhz/512 KB L2. Visually I have >> seen that on stable it doesn't behave as speedily as on FreeBSD >> number 6. I have checked utility in subject (which is probably not >> the best alternative) and it shows me on memory test half of the >> speed that was in v6 while using default MALLOC_OPTIONS at each >> version. There could be certain speed up changing it but IMHO there >> can not be any we to make it as fast as in previous version. Is there >> anyone who could make a logical explanation? (I think it has >> something to do with new malloc optimization for multi processor >> systems but I might compiled also libc on FreeBSD 7 with wrong >> options). Even using simple compat6x libc (with libmap.conf) helps to >> speed up things there. >> All those measurement are my just my non generalized opinion and I >> hope I am wrong :-) > > If you can confirm your results in a clean environment, you might want > to talk to jasone@ about this. > From votdev at gmx.de Wed May 21 08:28:38 2008 From: votdev at gmx.de (votdev@gmx.de) Date: Wed May 21 08:29:04 2008 Subject: Instant reboot with FreeBSD 6.3 and > 2GB RAM Message-ID: <20080521080156.209010@gmx.net> Hello, some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots on systems with > 2GB RAM (most of them use 4GB). The reboot occurs right after displaying the FreeBSD loader menu. Most of them told me that they can boot if they reduce RAM to <= 2GB. We are using the following kernel configuration which is based on GENERIC: http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291&view=markup I found out another problem that causes a reboot on my 2GB machine. We are using a image for the LiveCD which is 64MB great. If i change back mfs_root size to 63MB all works well, but all above 64MB causes a reboot. Is there any limitation? Could someone help me out of this problem? Regards Volker -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx From unixmania at gmail.com Wed May 21 12:44:57 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Wed May 21 12:45:01 2008 Subject: Is it possible to create a directory under /dev? Message-ID: I attempted this: # mkdir /dev/foo mkdir: /dev/foo: Operation not supported Any suggestions (besides creating it elsewhere, of course)? -- Carlos A. M. dos Santos From arnaud.houdelette at tzim.net Wed May 21 13:22:46 2008 From: arnaud.houdelette at tzim.net (Arnaud Houdelette) Date: Wed May 21 13:23:11 2008 Subject: ZFS on root and disk write caching. Message-ID: <48341CF9.3040008@tzim.net> I'm playing around with ZFS. Currently, I just use it for storage, with a zpool of 4 sata disks. The system and boot disk is still formatted with UFS. As I'm quite pleased with ZFS features, I'd like to try ZFS on root. The ZFS wiki is quite clear on how to proceed : if the boot and root are on the same disk, you'll have to use bsd labels. The thing is, I read somewhere that ZFS doesn't enable write caching on drives if not used on whole disks. 1. Is it still true on freebsd or just for opensolaris. 2. As the only other(s) label(s) on disk would be the (readonly) boot and swap label, I don't think write caching would be a problem. So how can I tell ZFS it's ok to enable it on the disk (or enable it manualy if necessary and of any use). 3. I'd like to keep the storage pool (zraid1) separated from the system pool (just one disk). The wiki states that we may encounter problems with more than one pool in use : is it still the case ? I know the whole ZFS thing is still experimental, but with it's overall performance, it would really be a shame not to give it its chance. Thanks for your comments. Arnaud Houdelette From vivek at khera.org Wed May 21 14:13:10 2008 From: vivek at khera.org (Vivek Khera) Date: Wed May 21 14:13:17 2008 Subject: Instant reboot with FreeBSD 6.3 and > 2GB RAM In-Reply-To: <20080521080156.209010@gmx.net> References: <20080521080156.209010@gmx.net> Message-ID: <96861789-550A-4F0B-A3AE-AC8538D125DC@khera.org> On May 21, 2008, at 4:01 AM, votdev@gmx.de wrote: > some users of FreeNAS which is based on FreeBSD 6.3 reported instant > reboots on systems with > 2GB RAM (most of them use 4GB). The reboot > occurs right after displaying the FreeBSD loader menu. Most of them > told me that they can boot if they reduce RAM to <= 2GB. For what it's worth, I have run several systems with 4GB RAM on FreeBSD/i386 6.3. The only i386 I have left with this much RAM was recently upgraded to 7.0; the rest of my large RAM systems run FreeBSD/ amd64. I didn't see anything obviously bad in your kernel config. By the way, thanks for making FreeNAS... I use it on my home NFS/AFP server to great success... the only thing I wish it included was the amrstat binary to test my LSI RAID controller status (I just copy it from another 6.3 system I have and it works). From koitsu at FreeBSD.org Wed May 21 14:15:01 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed May 21 14:15:03 2008 Subject: Instant reboot with FreeBSD 6.3 and > 2GB RAM In-Reply-To: <20080521080156.209010@gmx.net> References: <20080521080156.209010@gmx.net> Message-ID: <20080521141500.GA88498@eos.sc1.parodius.com> On Wed, May 21, 2008 at 10:01:56AM +0200, votdev@gmx.de wrote: > Hello, > > some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots on systems with > 2GB RAM (most of them use 4GB). The reboot occurs right after displaying the FreeBSD loader menu. Most of them told me that they can boot if they reduce RAM to <= 2GB. > > We are using the following kernel configuration which is based on GENERIC: > http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291&view=markup > > I found out another problem that causes a reboot on my 2GB machine. We are using a image for the LiveCD which is 64MB great. If i change back mfs_root size to 63MB all works well, but all above 64MB causes a reboot. > Is there any limitation? > > Could someone help me out of this problem? Is the mfsroot problem what I've documented here? http://jdc.parodius.com/freebsd/pxeboot_serial_install.html#step7 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From vivek at khera.org Wed May 21 14:15:04 2008 From: vivek at khera.org (Vivek Khera) Date: Wed May 21 14:15:09 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: References: Message-ID: On May 21, 2008, at 8:44 AM, Carlos A. M. dos Santos wrote: > I attempted this: > > # mkdir /dev/foo > mkdir: /dev/foo: Operation not supported > > Any suggestions (besides creating it elsewhere, of course)? Assuming you're using a modern FreeBSD (version number would be useful), /dev does not live on a file system. It exists as its own file system, controlled by devfs. Check the man page for devfs for details. From Nick.Barnes at pobox.com Wed May 21 14:16:38 2008 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Wed May 21 14:16:44 2008 Subject: syslog console log not logging SCSI problems In-Reply-To: <200805201621.m4KGL1WU067028@lurza.secnetix.de> from Oliver Fromme of "Tue, 20 May 2008 18:21:01 +0200" Message-ID: <74604.1211379394@thrush.ravenbrook.com> At 2008-05-20 16:21:01+0000, Oliver Fromme writes: > Nick Barnes wrote: > > One of our FreeBSD boxes has a SCSI controller and disk, which showed > > problems earlier this week. There was a lot of of chatter from the > > SCSI driver in /var/log/messages and to the console. However, the > > console is unattended and we only discovered the problem subsequently > > because /var/log/console.log didn't show any of the chatter. > > The console.* syslog facility only logs real console output, > i.e. things written to /dev/console. That does _not_ include > output from the kernel. > > For logging kernel output you have to use the kern.* syslog > facility. OK. So when syslogd directs output to the console, it does not also treat it as console.* output? Thanks for this explanation. I'll modify my syslog.conf accordingly. Nick B From olli at lurza.secnetix.de Wed May 21 17:00:22 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed May 21 17:00:25 2008 Subject: syslog console log not logging SCSI problems In-Reply-To: <74604.1211379394@thrush.ravenbrook.com> Message-ID: <200805211700.m4LH0DH9020843@lurza.secnetix.de> Nick Barnes wrote: > Oliver Fromme writes: > > Nick Barnes wrote: > > > One of our FreeBSD boxes has a SCSI controller and disk, which showed > > > problems earlier this week. There was a lot of of chatter from the > > > SCSI driver in /var/log/messages and to the console. However, the > > > console is unattended and we only discovered the problem subsequently > > > because /var/log/console.log didn't show any of the chatter. > > > > The console.* syslog facility only logs real console output, > > i.e. things written to /dev/console. That does _not_ include > > output from the kernel. > > > > For logging kernel output you have to use the kern.* syslog > > facility. > > OK. So when syslogd directs output to the console, it does not also > treat it as console.* output? That's correct. syslogd uses the LOG_CONSOLE flag to distinguish its own output from other console output, otherwise it would run into an infinite loop logging its own output. Best regards Oliver PS: If you're interested in source code, see the printsys() function in src/usr.sbin/syslogd/syslogd.c. -- 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 "The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly." -- RFC 2549 From olli at lurza.secnetix.de Wed May 21 17:06:04 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed May 21 17:06:08 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: Message-ID: <200805211706.m4LH61Zb021039@lurza.secnetix.de> Carlos A. M. dos Santos <> wrote: > I attempted this: > > # mkdir /dev/foo > mkdir: /dev/foo: Operation not supported DEVFS is a "virtual" filesystem, i.e. its contents are not stored on disk, but they're dunamically created by the kernel. Subdirectories only come into existence when a driver creates one for its own purposes, e.g. gmirror creates a /dev/mirror directory. > Any suggestions (besides creating it elsewhere, of course)? That depends on the purpose. *Why* do you want to create a subdirectory in /dev? What do you want to do with it? 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 $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable From olli at lurza.secnetix.de Wed May 21 17:37:33 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed May 21 17:37:36 2008 Subject: Digitally Signed Binaries w/ Kernel support, etc. In-Reply-To: <20080403170050.c0110778.torfinn.ingolfsen@broadpark.no> Message-ID: <200805211737.m4LHbVuX023379@lurza.secnetix.de> Sorry for replying to an old mail here, but there's an important point that was unanswered so far ... Torfinn Ingolfsen wrote: > David Schwartz wrote: > > > He would face a chicken and egg problem. To make a signed executable > > to set his key to be accepted, he would need his key to already be > > accepted. > > Uhm, if the attacker managed to get a hole in the sustem and get > in, he / she will surely manage to get the necessary tools (a signed > binrary) onto the system. As an added bonus, this is a binary he > created himself, so it works with his key. That wouldn't work. How is he going to sign a binary if he doesn't have the private key? When you set up a system with signed binaries, you usually store the private key somewhere else (on a floppy, USB stick or whatever). Maybe it could even be just a pass- phrase that only exists in the admin's mind, but not on any physical media. So an attacker _cannot_ create a binary with a valid signature. Of course, the kernel doesn't contain the private key either, because you only need the public key to verify the signature. I agree with Peter Wemm: There are legitimate uses for signed binaries. 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 "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" From olli at lurza.secnetix.de Wed May 21 18:17:54 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed May 21 18:18:12 2008 Subject: sched_ule performance on single CPU In-Reply-To: <438315.78030.qm@web57004.mail.re3.yahoo.com> Message-ID: <200805211817.m4LIHpbd024904@lurza.secnetix.de> Sorry for the late reply, but I think there's a technical detail that should be mentioned ... Unga wrote: > My earlier test shows processes in the normal category > can starve processes in real-time category. That's > alarming. It should be get fixed. Note that FreeBSD does not support "hard real time" processing. Strictly speaking no OS does that on PC standard hardware. FreeBSD's idprio/rtprio implementation only affects the decisions of the scheduler, i.e. the assignment of CPU time slices to processes. However, there are other resources beside CPU that influence the execution of processes. For example disk I/O. In other words, if an idle-prio process performs a lot of disk accesses, it creates an I/O bottleneck, and even realtime-prio processes will have to wait because the hardware (disk) is blocked. This problem can be alleviated by using faster and better hardware, e.g. a SCSI RAID-0 disk subsystem or whatever. Besides, for professional audio recording you will also need professional audio hardware (which should include its own buffer memory, among other things), not a consumer card or an el'cheapo USB dongle. Best regards Oliver PS: My notebook at home (Pentium-M, UP, 3 years old) works very well with FreeBSD/i386 RELENG_7 + SCHED_ULE. -- 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 "We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing." ? ? ? ? -- Mother Teresa From volker at vwsoft.com Wed May 21 19:08:50 2008 From: volker at vwsoft.com (Volker) Date: Wed May 21 19:08:55 2008 Subject: Instant reboot with FreeBSD 6.3 and > 2GB RAM In-Reply-To: <20080521080156.209010@gmx.net> References: <20080521080156.209010@gmx.net> Message-ID: <48347329.8020902@vwsoft.com> On 12/23/-58 20:59, votdev@gmx.de wrote: > Hello, > > some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots on systems with > 2GB RAM (most of them use 4GB). The reboot occurs right after displaying the FreeBSD loader menu. Most of them told me that they can boot if they reduce RAM to <= 2GB. > > We are using the following kernel configuration which is based on GENERIC: > http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291&view=markup > > I found out another problem that causes a reboot on my 2GB machine. We are using a image for the LiveCD which is 64MB great. If i change back mfs_root size to 63MB all works well, but all above 64MB causes a reboot. > Is there any limitation? > > Could someone help me out of this problem? > > Regards > Volker Hi Volker ;) I'm not quite sure about your 2nd problem and your report is not quite detailed but from your description it looks like loader is causing that. As there's no filesystem available at that time, the loader has to read itself through the filesystem structures. Knowing that, PR misc/108215 comes to mind. I've not been able to check if the issue and the patch to it is right but you may give it a try. Probably somebody with loader and filesystem (ufs) knowledge may answer that question quickly if the patch contained in the PR is right. The report is about 6.2-R but at least I've checked loader code and 7.x code is the same. I came across that report yesterday and was unable to check the calculation. If that is really the case, your problem may be related to that. http://www.freebsd.org/cgi/query-pr.cgi?pr=108215 Assuming the problem report is right, it's about reading huge files by loader reads in wrong sectors. HTH Volker From sweetnavelorange at gmail.com Thu May 22 02:11:56 2008 From: sweetnavelorange at gmail.com (James Butler) Date: Thu May 22 02:12:00 2008 Subject: Suspend/resume on IBM X31 In-Reply-To: References: Message-ID: On Mon, May 19, 2008 at 10:24 PM, James Butler wrote: > Greetings > > I am having trouble with suspend/resume on my Thinkpad X31, running > 7.0-STABLE as of April 23. Any help would be appreciated. > > First problem: When I run "acpiconf -s3" from mulituser mode, the > system suspends immediately, without executing /etc/rc.suspend (which > has mode 755); then on resume, I get a panic. [...] I just discovered: http://lists.freebsd.org/pipermail/freebsd-acpi/2008-April/004806.html which fixes the problem for me. Cheers, -James From unixmania at gmail.com Thu May 22 03:18:09 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Thu May 22 03:18:17 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: References: Message-ID: On Wed, May 21, 2008 at 11:15 AM, Vivek Khera wrote: > > On May 21, 2008, at 8:44 AM, Carlos A. M. dos Santos wrote: > >> I attempted this: >> >> # mkdir /dev/foo >> mkdir: /dev/foo: Operation not supported >> >> Any suggestions (besides creating it elsewhere, of course)? > > Assuming you're using a modern FreeBSD (version number would be useful), > /dev does not live on a file system. It exists as its own file system, > controlled by devfs. Check the man page for devfs for details. I'm using 7.0-STABLE. I've read devfs(8), devfs(5) and did not find an answer there. -- Carlos A. M. dos Santos From unixmania at gmail.com Thu May 22 03:22:32 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Thu May 22 03:22:36 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: <200805211706.m4LH61Zb021039@lurza.secnetix.de> References: <200805211706.m4LH61Zb021039@lurza.secnetix.de> Message-ID: On Wed, May 21, 2008 at 2:06 PM, Oliver Fromme wrote: > Carlos A. M. dos Santos <> wrote: > > I attempted this: > > > > # mkdir /dev/foo > > mkdir: /dev/foo: Operation not supported > > DEVFS is a "virtual" filesystem [...] I already knew that. :-) > > Any suggestions (besides creating it elsewhere, of course)? > > That depends on the purpose. *Why* do you want to create > a subdirectory in /dev? What do you want to do with it? I intended to use it as the mount point for a filesystem. -- Carlos A. M. dos Santos From avg at icyb.net.ua Thu May 22 07:02:16 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu May 22 07:02:20 2008 Subject: Is it possible to create a directory under /dev? References: Message-ID: <48351A70.8090402@icyb.net.ua> Carlos A. M. dos Santos wrote: > On Wed, May 21, 2008 at 2:06 PM, Oliver Fromme wrote: >> Carlos A. M. dos Santos <> wrote: >> > I attempted this: >> > >> > # mkdir /dev/foo >> > mkdir: /dev/foo: Operation not supported >> >> DEVFS is a "virtual" filesystem [...] > > I already knew that. :-) > >> > Any suggestions (besides creating it elsewhere, of course)? >> >> That depends on the purpose. *Why* do you want to create >> a subdirectory in /dev? What do you want to do with it? > > I intended to use it as the mount point for a filesystem. I think this is a quite weird idea. Why would you want another filesystem under /dev? /dev is for devices! Maybe you want something like /mnt or whatever, unless you are developing your own "sub-" devfs. But, by the way, there is a (slightly) more valid reason to want to create a directory under /dev, I recently had it. For one non-standard third-party application I needed to create a link to existing device in a certain subdirectory. I.e.: /dev/subdirX/device -> /dev/deviceX And I couldn't do that. Or maybe link operation for devfs just needs to be taught about creating subdirectories on demand. I don't know. -- Andriy Gapon From peter at pean.org Thu May 22 07:05:25 2008 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Thu May 22 07:05:28 2008 Subject: Jail resource limits Message-ID: <822C1BB6-3591-4CE1-AFEA-8B07B9F5ED8D@pean.org> http://wiki.freebsd.org/JailResourceLimits Is this anthing people are working on? Is it on its way to RELENG_7? Is there a 7-version of the patch or anything? This would be a _VERY_ useful feature. -- Peter Ankerst?l peter@pean.org From unga888 at yahoo.com Thu May 22 07:18:54 2008 From: unga888 at yahoo.com (Unga) Date: Thu May 22 07:18:59 2008 Subject: sched_ule performance on single CPU In-Reply-To: <200805211817.m4LIHpbd024904@lurza.secnetix.de> Message-ID: <69853.16097.qm@web57006.mail.re3.yahoo.com> --- Oliver Fromme wrote: > Sorry for the late reply, but I think there's a > technical > detail that should be mentioned ... > > Unga wrote: > > My earlier test shows processes in the normal > category > > can starve processes in real-time category. > That's > > alarming. It should be get fixed. > > Note that FreeBSD does not support "hard real time" > processing. Strictly speaking no OS does that on PC > standard hardware. > > FreeBSD's idprio/rtprio implementation only affects > the decisions of the scheduler, i.e. the assignment > of CPU time slices to processes. However, there are > other resources beside CPU that influence the > execution > of processes. For example disk I/O. > > In other words, if an idle-prio process performs a > lot > of disk accesses, it creates an I/O bottleneck, and > even realtime-prio processes will have to wait > because > the hardware (disk) is blocked. This problem can be > alleviated by using faster and better hardware, e.g. > a SCSI RAID-0 disk subsystem or whatever. Besides, > for professional audio recording you will also need > professional audio hardware (which should include > its > own buffer memory, among other things), not a > consumer > card or an el'cheapo USB dongle. > > Best regards > Oliver > > PS: My notebook at home (Pentium-M, UP, 3 years > old) > works very well with FreeBSD/i386 RELENG_7 + > SCHED_ULE. > Idle-prio process which generates lot of I/O is understandable. But when you either record or playback audio as realtime-prio and you opened up a pdf document as normal-prio, can the pdf rendering in normal-prio breaks down the realtime audio process? I don't think pdf rendering is I/O intensive. Using a faster processor or multi-core may solve this problem, but my question is, can smart scheduling solve it without buying more processors? Kind regards Unga From jamesoff at gmail.com Thu May 22 09:24:33 2008 From: jamesoff at gmail.com (James Seward) Date: Thu May 22 09:24:37 2008 Subject: BTX loader hangs after version info Message-ID: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> Hello, Two days ago I csup'd my desktop at home, which was running RELENG_7 from about 7.0-RELEASE time, to bring it up-to-date (still on RELENG_7). I followed my usual buildkernel/world procedure (the usual one) which has worked fine all the way since 5.x. After installing kernel and restarting in single user, it was working fine. However, following installworld it will not boot. It stops immediately after "BTX loader 1.00 BTX version 1.02", but with the cursor on the line *above* the first "B". Nothing futher happens, but the system responds to Ctrl-Alt-Del. I have managed to start it using the install CD and csup'd back to a version just before the commit to BTX that moved it to 1.02 (March 18th, I think). However, that version too hangs after "BTX loader 1.00 BTX version 1.01". My desktop is currently building RELENG_7_0 to see if that will work, but I won't know that until later as I'm at work and it is at home :) The install CD (BTX 1.00/1.01) boots fine. Nothing else changed on my system between the last successful boot and the unsuccessful one. Any suggestions/advice for what I can try next, or what I can do to help the troubleshooting process? My desktop is an Athlon64 but I am using i386, on an Asus A8V-E Deluxe board. /JMS From gavin at FreeBSD.org Thu May 22 09:25:28 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu May 22 09:25:36 2008 Subject: What does system do after "Uptime: "? In-Reply-To: <4819F6D3.80104@delphij.net> References: <481560AC.90109@delphij.net> <1209376409.59233.14.camel@buffy.york.ac.uk> <4818BF27.2080209@delphij.net> <200804301544.20802.jhb@freebsd.org> <1209660552.68622.53.camel@buffy.york.ac.uk> <4819F6D3.80104@delphij.net> Message-ID: <1211448313.71119.1.camel@buffy.york.ac.uk> On Thu, 2008-05-01 at 09:58 -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gavin Atkinson wrote: > | FWIW, there have been probably around 10 PRs in in the last few months > | about this behaviour. I'd vote for it as an errata candidate. > > FWIW I have written to re@ indicating some changes I wanted for > RELENG_7_0 as candidates. Could you please let me know if I have missed > something important? > > http://www.delphij.net/errata-20080430.xml Did you get anywhere with this request? PRs are still coming in about the "hang after Uptime:" issue. If the errata candidates were turned down, I think we need to have an entry in the release notes errata... Thanks, Gavin From 000.fbsd at quip.cz Thu May 22 11:19:42 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu May 22 11:19:47 2008 Subject: Jail resource limits In-Reply-To: <822C1BB6-3591-4CE1-AFEA-8B07B9F5ED8D@pean.org> References: <822C1BB6-3591-4CE1-AFEA-8B07B9F5ED8D@pean.org> Message-ID: <483556DB.9070602@quip.cz> Peter Ankerst?l wrote: > http://wiki.freebsd.org/JailResourceLimits > > Is this anthing people are working on? Is it on its way to RELENG_7? > Is there a 7-version of the patch or anything? This would be a _VERY_ > useful feature. Hi, AFAIK nobody is working on it. A year ago there was newer release of the patch against CURRENT at that time (FreeBSD 7) [1] http://www.ualberta.ca/~cdjones/jail-cpumem-current.tgz I never test this patch on current, only version for 6.x and if patch for current were made without improvements, it contains same bugs as patch for 6.x (eg.: not showing memory usage). There are some other guys trying to do the same, but I never saw patches published. Andrew Snow - Jails as a VPS [2] Alex Lyashkov - Jail2 aka FreeVPS [3a][3b] Or fixes for C.D. Jones work: Chris Thunes - jtune not showing resource usage - fixed [4] (note - attached patch is reversed) [5] So as you can see, there were some talks about Jail improvements for one year existence of this mailinglist (freebsd-jail@freebsd.org), also it is two years from SoC [6] and we still don't have anything commited to 7.x or to CURRENT. It is sad. There is little attention to jails, only few people are able to do some coding work etc. If the are somebody with skills and time to resurrect some mentioned projects, I am willing to help with testing. Also it will be good to have some up-to-date wiki page with "all the patches" (resource limits, SysV IPC, multiple IPs...) and status of this work, so people can easily find and try it. Miroslav Lachman [1] http://lists.freebsd.org/pipermail/freebsd-jail/2007-June/000030.html [2] http://lists.freebsd.org/pipermail/freebsd-jail/2008-January/000152.html [3a] http://docs.freevps.com/doku.php?id=freebsd:index [3b] http://lists.freebsd.org/pipermail/freebsd-arch/2006-June/005293.html [4] http://lists.freebsd.org/pipermail/freebsd-jail/2007-August/000060.html [5] http://lists.freebsd.org/pipermail/freebsd-jail/2007-September/000101.html [6] http://wiki.freebsd.org/JailResourceLimits Other links: jail services: http://wiki.freebsd.org/AsiaBSDCon_2007_DevSummit?action=AttachFile&do=get&target=jail_services.pdf kernel level virtualisation requirements: http://lists.freebsd.org/pipermail/freebsd-arch/2007-October/006872.html From Alexander at Leidinger.net Thu May 22 11:46:34 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu May 22 11:46:38 2008 Subject: Jail resource limits In-Reply-To: <483556DB.9070602@quip.cz> References: <822C1BB6-3591-4CE1-AFEA-8B07B9F5ED8D@pean.org> <483556DB.9070602@quip.cz> Message-ID: <20080522133115.84622rwkp784zi04@webmail.leidinger.net> Quoting Miroslav Lachman <000.fbsd@quip.cz> (from Thu, 22 May 2008 13:19:55 +0200): > Peter Ankerst?l wrote: >> http://wiki.freebsd.org/JailResourceLimits > If the are somebody with skills and time to resurrect some mentioned > projects, I am willing to help with testing. > > Also it will be good to have some up-to-date wiki page with "all the > patches" (resource limits, SysV IPC, multiple IPs...) and status of > this work, so people can easily find and try it. Are you willing to update the existing wiki page? If yes register to the wiki (default style would be MiroslavLachman as the username) and I give you write access to the page. Bye, Alexander. -- Please take note: http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From koitsu at FreeBSD.org Thu May 22 12:24:30 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu May 22 12:24:33 2008 Subject: BTX loader hangs after version info In-Reply-To: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> Message-ID: <20080522122430.GA43122@eos.sc1.parodius.com> On Thu, May 22, 2008 at 09:59:47AM +0100, James Seward wrote: > Two days ago I csup'd my desktop at home, which was running RELENG_7 > from about 7.0-RELEASE time, to bring it up-to-date (still on > RELENG_7). I followed my usual buildkernel/world procedure (the usual > one) which has worked fine all the way since 5.x. After installing > kernel and restarting in single user, it was working fine. However, > following installworld it will not boot. > > It stops immediately after "BTX loader 1.00 BTX version 1.02", but > with the cursor on the line *above* the first "B". Nothing futher > happens, but the system responds to Ctrl-Alt-Del. This sounds like a regression in the recent BTX fixes which were done by John Baldwin on March 18th. Strange, since those fixes addressed booting issues lots of users were having with BTX. See the very bottom of the below page, "BTX crashes on start": http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues After installworld, did you happen to use bsdlabel -B? > Any suggestions/advice for what I can try next, or what I can do to > help the troubleshooting process? > > My desktop is an Athlon64 but I am using i386, on an Asus A8V-E Deluxe board. I've CC'd John here, who might have some ideas. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From vivek at khera.org Thu May 22 13:49:06 2008 From: vivek at khera.org (Vivek Khera) Date: Thu May 22 13:49:18 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: References: Message-ID: On May 21, 2008, at 11:18 PM, Carlos A. M. dos Santos wrote: >> Assuming you're using a modern FreeBSD (version number would be >> useful), >> /dev does not live on a file system. It exists as its own file >> system, >> controlled by devfs. Check the man page for devfs for details. > > I'm using 7.0-STABLE. I've read devfs(8), devfs(5) and did not find an > answer there. perhaps if you state your goal rather than the difficulty you encounter using the mechanism you chose to reach that goal, we could help you better. From jamesoff at gmail.com Thu May 22 13:50:40 2008 From: jamesoff at gmail.com (James Seward) Date: Thu May 22 13:50:46 2008 Subject: BTX loader hangs after version info In-Reply-To: <20080522122430.GA43122@eos.sc1.parodius.com> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <20080522122430.GA43122@eos.sc1.parodius.com> Message-ID: <720051dc0805220650g299c1488la652cedf9c67f4db@mail.gmail.com> On Thu, May 22, 2008 at 1:24 PM, Jeremy Chadwick wrote: > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues My problem doesn't match the description of "screen continually scrolls registers or dumps registers then reboots"; it just freezes. While looking at the code for btx/btxldr I did notice a debug knob in the Makefile; should I turn this on? (And do I have to rebuild all of world to encourage it to update BTX? Presumably I can build/install a subset of it to save time?) > After installworld, did you happen to use bsdlabel -B? No, my procedure was: make buildkernel buildworld, make installkernel, reboot (to single user), mergemaster -p, make installworld, mergemaster (installed everything but passwd/group), reboot. This is the point where it broke :) Thanks, James From koitsu at FreeBSD.org Thu May 22 14:19:53 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu May 22 14:20:22 2008 Subject: BTX loader hangs after version info In-Reply-To: <720051dc0805220650g299c1488la652cedf9c67f4db@mail.gmail.com> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <20080522122430.GA43122@eos.sc1.parodius.com> <720051dc0805220650g299c1488la652cedf9c67f4db@mail.gmail.com> Message-ID: <20080522141953.GA46366@eos.sc1.parodius.com> On Thu, May 22, 2008 at 02:50:38PM +0100, James Seward wrote: > On Thu, May 22, 2008 at 1:24 PM, Jeremy Chadwick wrote: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > My problem doesn't match the description of "screen continually > scrolls registers or dumps registers then reboots"; it just freezes. > > While looking at the code for btx/btxldr I did notice a debug knob in > the Makefile; should I turn this on? Probably not. > (And do I have to rebuild all of > world to encourage it to update BTX? Presumably I can build/install a > subset of it to save time?) cd /sys/boot && make clean && make && make install will build and install new boot blocks in /boot, as well as /boot/loader. It will not apply new boot blocks to your disk (that's what bsdlabel does). > > After installworld, did you happen to use bsdlabel -B? > > No, my procedure was: make buildkernel buildworld, make installkernel, > reboot (to single user), mergemaster -p, make installworld, > mergemaster (installed everything but passwd/group), reboot. This is > the point where it broke :) My bad, sorry. The problem you're experiencing is likely in /boot/loader, which is what prints the "BTX version is x.xx" message. /boot/loader doesn't require your boot blocks be updated; it's updated during installworld. BTX version 1.01 is what comes with 7.0-RELEASE, while a RELENG_7 snapshot or a recently-rebuilt world (of RELENG_7) would use 1.02. I'm not sure what's breaking there for you; I'll have to dig through the CVS commit logs to check. Do you have anything in /boot/loader.conf? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From peter at pean.org Thu May 22 14:50:47 2008 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Thu May 22 14:50:58 2008 Subject: Jail resource limits In-Reply-To: <483556DB.9070602@quip.cz> References: <822C1BB6-3591-4CE1-AFEA-8B07B9F5ED8D@pean.org> <483556DB.9070602@quip.cz> Message-ID: <08244555-5BD2-4F67-B311-CCC5E316A068@pean.org> > > > If the are somebody with skills and time to resurrect some mentioned > projects, I am willing to help with testing. > I will also be happy to help in whatever way I can. I have no coding- experience to talk about. But testing in various env and so on. (and help with docs/wiki) -- Peter Ankerst?l peter@pean.org From bzeeb-lists at lists.zabbadoz.net Thu May 22 17:15:01 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu May 22 17:15:10 2008 Subject: Jail resource limits In-Reply-To: <08244555-5BD2-4F67-B311-CCC5E316A068@pean.org> References: <822C1BB6-3591-4CE1-AFEA-8B07B9F5ED8D@pean.org> <483556DB.9070602@quip.cz> <08244555-5BD2-4F67-B311-CCC5E316A068@pean.org> Message-ID: <20080522165219.D47338@maildrop.int.zabbadoz.net> On Thu, 22 May 2008, Peter Ankerst?l wrote: Hi, >> If the are somebody with skills and time to resurrect some mentioned >> projects, I am willing to help with testing. >> > I will also be happy to help in whatever way I can. I have no > coding-experience to talk about. But testing in various env > and so on. (and help with docs/wiki) I will have to go through all this again but it seems that there is more interest from multiple people on this work. As I am currently working on FreeBSD jails (see latetst status report http://www.freebsd.org/news/status/report-2008-01-2008-03.html#Multi-IPv4/v6/no-IP-jails and follow to my homepage to also find the slide from the BSDCan WIP session) I should look into this for everyone running FreeBSD 7. I'll try to get an overview on all the work out there based on the pointers already posted and will see how I can integrate that with whatever is going on in FreeBSD atm or come up with new patches.. Regards, Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From killing at multiplay.co.uk Thu May 22 17:42:40 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Thu May 22 17:42:43 2008 Subject: Jail resource limits References: <822C1BB6-3591-4CE1-AFEA-8B07B9F5ED8D@pean.org><483556DB.9070602@quip.cz><08244555-5BD2-4F67-B311-CCC5E316A068@pean.org> <20080522165219.D47338@maildrop.int.zabbadoz.net> Message-ID: <8068148B75CB4B3E953144A0DF47E496@multiplay.co.uk> This is something we're really looking forward to tbh a great feature :) One of the reasons for this is hosting jails, with the addition of multi IP support we will be able to enable jails to connect to "backdoor" secure services such as a mysql server. ----- Original Message ----- From: "Bjoern A. Zeeb" I will have to go through all this again but it seems that there is more interest from multiple people on this work. As I am currently working on FreeBSD jails (see latetst status report http://www.freebsd.org/news/status/report-2008-01-2008-03.html#Multi-IPv4/v6/no-IP-jails and follow to my homepage to also find the slide from the BSDCan WIP session) I should look into this for everyone running FreeBSD 7. I'll try to get an overview on all the work out there based on the pointers already posted and will see how I can integrate that with whatever is going on in FreeBSD atm or come up with new patches.. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From vivek at khera.org Thu May 22 19:26:14 2008 From: vivek at khera.org (Vivek Khera) Date: Thu May 22 19:26:18 2008 Subject: jail process limits Message-ID: <0FDDD3FE-395C-494C-8325-99FDB2BAEEB5@khera.org> While we're on the topic of jail resource limits, I think I'll ask my question again... I asked last month but got no response... I've got a jail server (FreeBSD 6.3/amd64) which runs a bunch of web site development environments. There is an apache or lighttpd running in each jail as user httpd (same UID on base system and each jail). On the jail host, I counted 231 processes owned by httpd. If I try to start an application server (or any process) as user httpd in one of the jails, it exits immediately with "Cannot fork: Resource temporarily unavailable". Even if I "su httpd" I get the same error on any command I try to run such as "ls". If I run the same on the jail host, it has no problems. The jail itself only has 34 processes running. On the jail host, the following is logged: Apr 22 16:34:38 staging kernel: maxproc limit exceeded by uid 80, please see tuning(7) and login.conf(5). tuning(7) and login.conf(5) have pretty much nothing to say about "maxproc". The sysctl settings are all default on this box. kern.maxproc: 6164 kern.maxprocperuid: 5547 The user httpd is of login class "daemon". My login.conf is unchanged from the distributed version, which states "unlimited" for max processes. Why am I getting the resource unavailable when I barely have 230 processes, not even close to the limits. Apache seems unaffected since the parent is run as root, so it can fork children willy-nilly and not be blocked by any limits. Can anyone tell me where to look to find out what is limiting user httpd from creating new processes inside the jail, and what exactly that limit is? More importantly, how to increase it. From stylinae at email.uc.edu Thu May 22 23:56:51 2008 From: stylinae at email.uc.edu (Adam Stylinski) Date: Thu May 22 23:56:55 2008 Subject: Core Dump? Message-ID: <20080522193648.CDW33820@mirapoint.uc.edu> I am experiencing the problem that I have found many people have in archived mailing list (and perhaps even this one). I have about 60-80 seconds of stability on my formerly stable freebsd7 installation before it reboots with what appears to be a kernel panic. I get the following message "Panic: ffs_blkfree", it gives an error about my /usr partition, and then it starts dumping physical memory before a reboot. Any idea how to fix this? From delphij at delphij.net Fri May 23 00:15:57 2008 From: delphij at delphij.net (Xin LI) Date: Fri May 23 00:15:59 2008 Subject: Core Dump? In-Reply-To: <20080522193648.CDW33820@mirapoint.uc.edu> References: <20080522193648.CDW33820@mirapoint.uc.edu> Message-ID: <48360CB3.6020008@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Stylinski wrote: | I am experiencing the problem that I have found many people have in archived mailing list (and perhaps even this one). I have about 60-80 seconds of stability on my formerly stable freebsd7 installation before it reboots with what appears to be a kernel panic. I get the following message "Panic: ffs_blkfree", it gives an error about my /usr partition, and then it starts dumping physical memory before a reboot. Any idea how to fix this? Try to have a manual 'fsck -fy' in single user mode should fix this I think. Cheers, - -- ** Help China's quake relief at http://www.redcross.org.cn/ |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkg2DLIACgkQi+vbBBjt66CZ6wCfUs36Nkk7vvGsYa0CHA2piurE ZGkAmgJEXKbv11q6/kkhBnAU2NcABRDo =7EdG -----END PGP SIGNATURE----- From markir at paradise.net.nz Fri May 23 01:23:05 2008 From: markir at paradise.net.nz (Mark Kirkwood) Date: Fri May 23 01:23:12 2008 Subject: BTX loader hangs after version info In-Reply-To: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> Message-ID: <48361C6F.2050108@paradise.net.nz> James Seward wrote: > Hello, > > Two days ago I csup'd my desktop at home, which was running RELENG_7 > from about 7.0-RELEASE time, to bring it up-to-date (still on > RELENG_7). I followed my usual buildkernel/world procedure (the usual > one) which has worked fine all the way since 5.x. After installing > kernel and restarting in single user, it was working fine. However, > following installworld it will not boot. > > It stops immediately after "BTX loader 1.00 BTX version 1.02", but > with the cursor on the line *above* the first "B". Nothing futher > happens, but the system responds to Ctrl-Alt-Del. > > I have managed to start it using the install CD and csup'd back to a > version just before the commit to BTX that moved it to 1.02 (March > 18th, I think). However, that version too hangs after "BTX loader 1.00 > BTX version 1.01". > > My desktop is currently building RELENG_7_0 to see if that will work, > but I won't know that until later as I'm at work and it is at home :) > > The install CD (BTX 1.00/1.01) boots fine. Nothing else changed on my > system between the last successful boot and the unsuccessful one. > > Any suggestions/advice for what I can try next, or what I can do to > help the troubleshooting process? > > My desktop is an Athlon64 but I am using i386, on an Asus A8V-E Deluxe board. > FWIW - I am seeing this too, on a Supermicro P3TDDE. 7-STABLE src from 28-Feb is fine, but Mar, Apr, May code all hangs after printing "loading /boot/defaults/loader.conf" - presumably reading my /boot/loader.conf? Interestingly I can usually get it to boot by escaping to the loader prompt and then just pressing return. Oddly some other machines (Supermicro P3TDER and Asus PRO31J Laptop) behave normally with src from Mar->May. In all cases the canonical procedure from UPDATING was used (buildworld, kernel, reboot single, mergemaster -p, installworld, delete-old, mergemaster, reboot). I happy to help collect some debug info (how do you switch this on for the loader?), tho the machine exhibiting the problem is my workstation (of course)! regards Mark From freebsd at meijome.net Fri May 23 01:33:07 2008 From: freebsd at meijome.net (Norberto Meijome) Date: Fri May 23 01:33:12 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: <48351A70.8090402@icyb.net.ua> References: <48351A70.8090402@icyb.net.ua> Message-ID: <20080523110556.485afa89@ayiin> On Thu, 22 May 2008 10:02:08 +0300 Andriy Gapon wrote: > But, by the way, there is a (slightly) more valid reason to want to > create a directory under /dev, I recently had it. For one non-standard > third-party application I needed to create a link to existing device in > a certain subdirectory. I.e.: > /dev/subdirX/device -> /dev/deviceX > And I couldn't do that. > Or maybe link operation for devfs just needs to be taught about creating > subdirectories on demand. I don't know. you can create links with devfs - man devfs.conf [...] link This action creates a symbolic link named arg that points to devname, the name of the device created by devfs(5). [..] B _________________________ {Beto|Norberto|Numard} Meijome ...using the internet as it was originally intended... for the further research of pornography and pipebombs. 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. From avg at icyb.net.ua Fri May 23 06:37:12 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri May 23 06:37:15 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: <48351A70.8090402@icyb.net.ua> References: <48351A70.8090402@icyb.net.ua> Message-ID: <4836660D.1070801@icyb.net.ua> Norberto Meijome wrote: > On Thu, 22 May 2008 10:02:08 +0300 > Andriy Gapon wrote: > >> But, by the way, there is a (slightly) more valid reason to want to >> create a directory under /dev, I recently had it. For one non-standard >> third-party application I needed to create a link to existing device in >> a certain subdirectory. I.e.: >> /dev/subdirX/device -> /dev/deviceX >> And I couldn't do that. >> Or maybe link operation for devfs just needs to be taught about creating >> subdirectories on demand. I don't know. > > you can create links with devfs - man devfs.conf > [...] > link This action creates a symbolic link named arg that points to > devname, the name of the device created by devfs(5). > [..] I do know that. Maybe I wasn't clear enough: "/dev/deviceX" was existing device node and I needed to create "/dev/subdirX/device" link, where directory "/dev/subdirX" didn't exist. Any help on this? -- Andriy Gapon From peter at pean.org Fri May 23 07:02:39 2008 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Fri May 23 07:02:46 2008 Subject: Jail resource limits In-Reply-To: <20080522133115.84622rwkp784zi04@webmail.leidinger.net> References: <822C1BB6-3591-4CE1-AFEA-8B07B9F5ED8D@pean.org> <483556DB.9070602@quip.cz> <20080522133115.84622rwkp784zi04@webmail.leidinger.net> Message-ID: On May 22, 2008, at 1:31 PM, Alexander Leidinger wrote: > Quoting Miroslav Lachman <000.fbsd@quip.cz> (from Thu, 22 May 2008 > 13:19:55 +0200): > >> Peter Ankerst?l wrote: >>> http://wiki.freebsd.org/JailResourceLimits > >> If the are somebody with skills and time to resurrect some >> mentioned projects, I am willing to help with testing. >> >> Also it will be good to have some up-to-date wiki page with "all >> the patches" (resource limits, SysV IPC, multiple IPs...) and >> status of this work, so people can easily find and try it. > > Are you willing to update the existing wiki page? If yes register to > the wiki (default style would be MiroslavLachman as the username) > and I give you write access to the page. > Maybe it will be a good idea to create a new page that puts all jail- stuff in one place. I mean, there is more to this then just resource limits. -- Peter Ankerst?l peter@pean.org From cflists at helinet.de Fri May 23 09:41:48 2008 From: cflists at helinet.de (cflists@helinet.de) Date: Fri May 23 09:41:51 2008 Subject: Building enlightenment-devel fails Message-ID: <48368AA8.6040803@helinet.de> Hi All, I'm running a FreeBSD 6.3-PRERELEASE and after a portupgrade building enlightenment-devel fails with following error. --snip-- libtool: link: cannot find the library `/usr/local/lib/libecore_dbus.la' or unhandled argument `/usr/local/lib/libecore_dbus.la' gmake[3]: *** [enlightenment] Error 1 --snip-- I googled this problem an found this --snip-- This removes the DBUS check for ecore. Since ecore does not appear to link against any other DBUS port, it is not necessary. In addition enlightenment-devel will not build if ecore does not have DBUS enabled due to a dependency on Ecore_DBus.h in e.h. A better way is welcome. --snip-- The attached patch doesn't solve the problem as I dunno know which Makefile to patch. "/usr/ports/x11/ecore/Makefile" doesn't exist on my machine, only "/usr/ports/x11/ecore-desktop". This was not the first problem with the upgrade. As ports/UPDATING said on 20080312 ecore and evas have been splitted. After uninstalling and clean reinstalling all e-related packages now problems with libcore_dbus.la occure. Please excuse my probably stupid questions here, but I'm relatively new to FreeBSD and try to fix most of my problems by myself. But in here im stuck. Any help will be highly appreciated. Many greetings from Germany, Christoph From kostikbel at gmail.com Fri May 23 09:42:24 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri May 23 09:42:50 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: <4836660D.1070801@icyb.net.ua> References: <20080523110556.485afa89@ayiin> <4836660D.1070801@icyb.net.ua> Message-ID: <20080523091627.GK29770@deviant.kiev.zoral.com.ua> On Fri, May 23, 2008 at 09:37:01AM +0300, Andriy Gapon wrote: > Norberto Meijome wrote: > >On Thu, 22 May 2008 10:02:08 +0300 > >Andriy Gapon wrote: > > > >>But, by the way, there is a (slightly) more valid reason to want to > >>create a directory under /dev, I recently had it. For one non-standard > >>third-party application I needed to create a link to existing device in > >>a certain subdirectory. I.e.: > >>/dev/subdirX/device -> /dev/deviceX > >>And I couldn't do that. > >>Or maybe link operation for devfs just needs to be taught about creating > >>subdirectories on demand. I don't know. > > > >you can create links with devfs - man devfs.conf > >[...] > >link This action creates a symbolic link named arg that points to > > devname, the name of the device created by devfs(5). > >[..] > > I do know that. > Maybe I wasn't clear enough: "/dev/deviceX" was existing device node and > I needed to create "/dev/subdirX/device" link, where directory > "/dev/subdirX" didn't exist. > Any help on this? As an ugly workaround, you may create an directory on ufs filesystem, populate it with needed symlinks, and then make a symlink /dev/subdirX -> the directory. I would prefer not to allow users to create the directories on the devfs. On the other hand, I like Solaris approach with devfs on /devices and /dev being populated with short symlinks to ../devices. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080523/969c41e2/attachment.pgp From kostikbel at gmail.com Fri May 23 11:53:17 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri May 23 11:53:20 2008 Subject: BTX loader hangs after version info In-Reply-To: <48361C6F.2050108@paradise.net.nz> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <48361C6F.2050108@paradise.net.nz> Message-ID: <20080523115311.GM29770@deviant.kiev.zoral.com.ua> On Fri, May 23, 2008 at 01:22:55PM +1200, Mark Kirkwood wrote: > James Seward wrote: > >Hello, > > > >Two days ago I csup'd my desktop at home, which was running RELENG_7 > >from about 7.0-RELEASE time, to bring it up-to-date (still on > >RELENG_7). I followed my usual buildkernel/world procedure (the usual > >one) which has worked fine all the way since 5.x. After installing > >kernel and restarting in single user, it was working fine. However, > >following installworld it will not boot. > > > >It stops immediately after "BTX loader 1.00 BTX version 1.02", but > >with the cursor on the line *above* the first "B". Nothing futher > >happens, but the system responds to Ctrl-Alt-Del. > > > >I have managed to start it using the install CD and csup'd back to a > >version just before the commit to BTX that moved it to 1.02 (March > >18th, I think). However, that version too hangs after "BTX loader 1.00 > >BTX version 1.01". > > > >My desktop is currently building RELENG_7_0 to see if that will work, > >but I won't know that until later as I'm at work and it is at home :) > > > >The install CD (BTX 1.00/1.01) boots fine. Nothing else changed on my > >system between the last successful boot and the unsuccessful one. > > > >Any suggestions/advice for what I can try next, or what I can do to > >help the troubleshooting process? > > > >My desktop is an Athlon64 but I am using i386, on an Asus A8V-E Deluxe > >board. > > > FWIW - I am seeing this too, on a Supermicro P3TDDE. 7-STABLE src from > 28-Feb is fine, but Mar, Apr, May code all hangs after printing "loading > /boot/defaults/loader.conf" - presumably reading my /boot/loader.conf? > > Interestingly I can usually get it to boot by escaping to the loader > prompt and then just pressing return. > > Oddly some other machines (Supermicro P3TDER and Asus PRO31J Laptop) > behave normally with src from Mar->May. > > In all cases the canonical procedure from UPDATING was used (buildworld, > kernel, reboot single, mergemaster -p, installworld, delete-old, > mergemaster, reboot). > > I happy to help collect some debug info (how do you switch this on for > the loader?), tho the machine exhibiting the problem is my workstation > (of course)! Try to install new bootblock. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080523/eb76f6f4/attachment.pgp From jhb at freebsd.org Fri May 23 13:04:20 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri May 23 13:04:38 2008 Subject: BTX loader hangs after version info In-Reply-To: <20080523115311.GM29770@deviant.kiev.zoral.com.ua> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <48361C6F.2050108@paradise.net.nz> <20080523115311.GM29770@deviant.kiev.zoral.com.ua> Message-ID: <200805230829.09524.jhb@freebsd.org> On Friday 23 May 2008 07:53:11 am Kostik Belousov wrote: > On Fri, May 23, 2008 at 01:22:55PM +1200, Mark Kirkwood wrote: > > James Seward wrote: > > >Hello, > > > > > >Two days ago I csup'd my desktop at home, which was running RELENG_7 > > >from about 7.0-RELEASE time, to bring it up-to-date (still on > > >RELENG_7). I followed my usual buildkernel/world procedure (the usual > > >one) which has worked fine all the way since 5.x. After installing > > >kernel and restarting in single user, it was working fine. However, > > >following installworld it will not boot. > > > > > >It stops immediately after "BTX loader 1.00 BTX version 1.02", but > > >with the cursor on the line *above* the first "B". Nothing futher > > >happens, but the system responds to Ctrl-Alt-Del. > > > > > >I have managed to start it using the install CD and csup'd back to a > > >version just before the commit to BTX that moved it to 1.02 (March > > >18th, I think). However, that version too hangs after "BTX loader 1.00 > > >BTX version 1.01". > > > > > >My desktop is currently building RELENG_7_0 to see if that will work, > > >but I won't know that until later as I'm at work and it is at home :) > > > > > >The install CD (BTX 1.00/1.01) boots fine. Nothing else changed on my > > >system between the last successful boot and the unsuccessful one. > > > > > >Any suggestions/advice for what I can try next, or what I can do to > > >help the troubleshooting process? > > > > > >My desktop is an Athlon64 but I am using i386, on an Asus A8V-E Deluxe > > >board. > > > > FWIW - I am seeing this too, on a Supermicro P3TDDE. 7-STABLE src from > > 28-Feb is fine, but Mar, Apr, May code all hangs after printing "loading > > /boot/defaults/loader.conf" - presumably reading my /boot/loader.conf? > > > > Interestingly I can usually get it to boot by escaping to the loader > > prompt and then just pressing return. > > > > Oddly some other machines (Supermicro P3TDER and Asus PRO31J Laptop) > > behave normally with src from Mar->May. > > > > In all cases the canonical procedure from UPDATING was used (buildworld, > > kernel, reboot single, mergemaster -p, installworld, delete-old, > > mergemaster, reboot). > > > > I happy to help collect some debug info (how do you switch this on for > > the loader?), tho the machine exhibiting the problem is my workstation > > (of course)! > > Try to install new bootblock. I would be wary of that as it might make things worse? These problems are all from starting /boot/loader. boot2 is still working fine and thus there is still the possiblity of using boot2 to load /boot/loader.old as a workaround. If you update boot2 and it breaks you can't fix that w/o booting off of some other media such as a CD. Debugging these hangs is not easy to do remotely. If you know assembly then there are some things you can play with. For example, in the case where it hangs after printing out the BTX version (from btxldr.S) you could start adding debugging to btx.S to print out '.' characters in various places and see how many get printed out before it hangs. However, doing this requires familiarity with assembly and is a lot easier with physical access to a box. -- John Baldwin From jamesoff at gmail.com Fri May 23 13:23:22 2008 From: jamesoff at gmail.com (James Seward) Date: Fri May 23 13:23:25 2008 Subject: BTX loader hangs after version info In-Reply-To: <200805230829.09524.jhb@freebsd.org> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <48361C6F.2050108@paradise.net.nz> <20080523115311.GM29770@deviant.kiev.zoral.com.ua> <200805230829.09524.jhb@freebsd.org> Message-ID: <720051dc0805230623r3d5b5234sa9d3d167656d7995@mail.gmail.com> On Fri, May 23, 2008 at 1:29 PM, John Baldwin wrote: > If you update boot2 and it breaks you can't fix that w/o booting off of some > other media such as a CD. This is where I'm at anyway :) Oh, I forgot to mention I'm booting with grub (which then hands over to BTX if I choose my FreeBSD option). I guess I should try getting rid of that temporarily. Jeremy, I do have a couple of lines in loader.conf but off hand I can't remember what precisely. I think it's a DMA hint, and disabling AGP (a solution I think sos@ came up with for problem I had some time during 6.2's release cycle). Unfortunately I was busy last night so couldn't try anything further, but I should be able to tonight and over the weekend. Thanks, James From kostikbel at gmail.com Fri May 23 13:26:59 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri May 23 13:27:13 2008 Subject: BTX loader hangs after version info In-Reply-To: <200805230829.09524.jhb@freebsd.org> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <48361C6F.2050108@paradise.net.nz> <20080523115311.GM29770@deviant.kiev.zoral.com.ua> <200805230829.09524.jhb@freebsd.org> Message-ID: <20080523132645.GO29770@deviant.kiev.zoral.com.ua> On Fri, May 23, 2008 at 08:29:09AM -0400, John Baldwin wrote: > On Friday 23 May 2008 07:53:11 am Kostik Belousov wrote: > > On Fri, May 23, 2008 at 01:22:55PM +1200, Mark Kirkwood wrote: > > > James Seward wrote: > > > >Hello, > > > > > > > >Two days ago I csup'd my desktop at home, which was running RELENG_7 > > > >from about 7.0-RELEASE time, to bring it up-to-date (still on > > > >RELENG_7). I followed my usual buildkernel/world procedure (the usual > > > >one) which has worked fine all the way since 5.x. After installing > > > >kernel and restarting in single user, it was working fine. However, > > > >following installworld it will not boot. > > > > > > > >It stops immediately after "BTX loader 1.00 BTX version 1.02", but > > > >with the cursor on the line *above* the first "B". Nothing futher > > > >happens, but the system responds to Ctrl-Alt-Del. > > > > > > > >I have managed to start it using the install CD and csup'd back to a > > > >version just before the commit to BTX that moved it to 1.02 (March > > > >18th, I think). However, that version too hangs after "BTX loader 1.00 > > > >BTX version 1.01". > > > > > > > >My desktop is currently building RELENG_7_0 to see if that will work, > > > >but I won't know that until later as I'm at work and it is at home :) > > > > > > > >The install CD (BTX 1.00/1.01) boots fine. Nothing else changed on my > > > >system between the last successful boot and the unsuccessful one. > > > > > > > >Any suggestions/advice for what I can try next, or what I can do to > > > >help the troubleshooting process? > > > > > > > >My desktop is an Athlon64 but I am using i386, on an Asus A8V-E Deluxe > > > >board. > > > > > > FWIW - I am seeing this too, on a Supermicro P3TDDE. 7-STABLE src from > > > 28-Feb is fine, but Mar, Apr, May code all hangs after printing "loading > > > /boot/defaults/loader.conf" - presumably reading my /boot/loader.conf? > > > > > > Interestingly I can usually get it to boot by escaping to the loader > > > prompt and then just pressing return. > > > > > > Oddly some other machines (Supermicro P3TDER and Asus PRO31J Laptop) > > > behave normally with src from Mar->May. > > > > > > In all cases the canonical procedure from UPDATING was used (buildworld, > > > kernel, reboot single, mergemaster -p, installworld, delete-old, > > > mergemaster, reboot). > > > > > > I happy to help collect some debug info (how do you switch this on for > > > the loader?), tho the machine exhibiting the problem is my workstation > > > (of course)! > > > > Try to install new bootblock. > > I would be wary of that as it might make things worse? These problems are all > from starting /boot/loader. boot2 is still working fine and thus there is > still the possiblity of using boot2 to load /boot/loader.old as a workaround. > If you update boot2 and it breaks you can't fix that w/o booting off of some > other media such as a CD. > > Debugging these hangs is not easy to do remotely. If you know assembly then > there are some things you can play with. For example, in the case where it > hangs after printing out the BTX version (from btxldr.S) you could start > adding debugging to btx.S to print out '.' characters in various places and > see how many get printed out before it hangs. However, doing this requires > familiarity with assembly and is a lot easier with physical access to a box. When I worked on my version of the realbtx, I sometimes experienced hangs when vm86 btx run before real-mode btx. I did not investigated it then, only noted the issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080523/aee48b97/attachment.pgp From avg at icyb.net.ua Fri May 23 14:33:10 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri May 23 14:33:15 2008 Subject: btw: kernel printing Message-ID: <4836D5A2.5050404@icyb.net.ua> This is RELENG_7, i386, uni-processor(!), SCHED_ULE: kernel: umass0: at uhub3 port 2 (addr 2) disconnected kernel: (da0:umass-sim0:0:0:0): loGEOM_LABEL: Label ufs/extbackup removed. kernel: st device kernel: (da0:umass-sim0:0:0:0): removing device entry kernel: umass0: detached So apparently not only SMP is affected. -- Andriy Gapon From olli at lurza.secnetix.de Fri May 23 16:00:54 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri May 23 16:00:57 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: <48351A70.8090402@icyb.net.ua> Message-ID: <200805231600.m4NG0oWq025982@lurza.secnetix.de> Andriy Gapon wrote: > But, by the way, there is a (slightly) more valid reason to want to > create a directory under /dev, I recently had it. For one non-standard > third-party application I needed to create a link to existing device in > a certain subdirectory. I.e.: > /dev/subdirX/device -> /dev/deviceX > And I couldn't do that. You could create a directory elsewhere and use UNIONFS to merge it with your existing /dev. I haven't tried this, but I think it should work. # mkdir /mydev # mount -t unionfs -o below /mydev /dev # cd /mydev # mkdir subdirX # ln -s /dev/deviceX subdirX/device The "-o below" option is used so that any modifications on /dev -- such as creating symlinks -- still happen on the real /dev, not on /mydev. 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 Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. From olli at lurza.secnetix.de Fri May 23 16:16:25 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri May 23 16:16:28 2008 Subject: sched_ule performance on single CPU In-Reply-To: <69853.16097.qm@web57006.mail.re3.yahoo.com> Message-ID: <200805231616.m4NGGNkK026611@lurza.secnetix.de> Unga wrote: > Idle-prio process which generates lot of I/O is > understandable. > > But when you either record or playback audio as > realtime-prio and you opened up a pdf document as > normal-prio, can the pdf rendering in normal-prio > breaks down the realtime audio process? I don't think > pdf rendering is I/O intensive. I think it can. Opening a PDF causes quite a lot of I/O. The viewer application has to be paged in from disk, all the libraries and configuration files it uses, possibly even parts of the X server have to be paged in, depending on what features of the X protocol and which extensions the viewer application uses. And of course the PDF itself has to be loaded (which might be not small), and finally all fonts used by the PDF have to be loaded by the viewer application. On the other hand, the default buffer space of the audio driver is quite small (the reason for that is to reduce latency for sound effects in games). So even a very short I/O congestion can cause an audible hiccup in audio playback or recording. > Using a faster processor or multi-core may solve this > problem, No, faster I/O hardware will solve it, or hardware that better supports concurrent access. It's also quite possible that improvements in FreeBSD's disk system might solve the problem, i.e. by reordering disk access in a more efficient manner, but this is very non-trivial. But all of that is not a matter of the process scheduler. Anotehr solution is to use more aggressive buffering by either the audio application or the audio driver. The latter can be set via sysctl. The former is a matter of your audio application. I use mpg123 for mp3 playback on a 3-year old UP machine. It has a buffer option which I use. E.g. "mpg123 -b5000" will use 5 MB buffer; that's enough for half a minute of audio. I do not use renice, idprio, rtprio or anything, but still audio playback works perfectly fine, even during a buildworld. Or when opening a PDF. No hiccups. 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 "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From jhb at freebsd.org Fri May 23 19:57:59 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri May 23 19:58:05 2008 Subject: BTX loader hangs after version info In-Reply-To: <20080523132645.GO29770@deviant.kiev.zoral.com.ua> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> Message-ID: <200805231238.10786.jhb@freebsd.org> On Friday 23 May 2008 09:26:45 am Kostik Belousov wrote: > On Fri, May 23, 2008 at 08:29:09AM -0400, John Baldwin wrote: > > On Friday 23 May 2008 07:53:11 am Kostik Belousov wrote: > > > On Fri, May 23, 2008 at 01:22:55PM +1200, Mark Kirkwood wrote: > > > > James Seward wrote: > > > > >Hello, > > > > > > > > > >Two days ago I csup'd my desktop at home, which was running RELENG_7 > > > > >from about 7.0-RELEASE time, to bring it up-to-date (still on > > > > >RELENG_7). I followed my usual buildkernel/world procedure (the usual > > > > >one) which has worked fine all the way since 5.x. After installing > > > > >kernel and restarting in single user, it was working fine. However, > > > > >following installworld it will not boot. > > > > > > > > > >It stops immediately after "BTX loader 1.00 BTX version 1.02", but > > > > >with the cursor on the line *above* the first "B". Nothing futher > > > > >happens, but the system responds to Ctrl-Alt-Del. > > > > > > > > > >I have managed to start it using the install CD and csup'd back to a > > > > >version just before the commit to BTX that moved it to 1.02 (March > > > > >18th, I think). However, that version too hangs after "BTX loader 1.00 > > > > >BTX version 1.01". > > > > > > > > > >My desktop is currently building RELENG_7_0 to see if that will work, > > > > >but I won't know that until later as I'm at work and it is at home :) > > > > > > > > > >The install CD (BTX 1.00/1.01) boots fine. Nothing else changed on my > > > > >system between the last successful boot and the unsuccessful one. > > > > > > > > > >Any suggestions/advice for what I can try next, or what I can do to > > > > >help the troubleshooting process? > > > > > > > > > >My desktop is an Athlon64 but I am using i386, on an Asus A8V-E Deluxe > > > > >board. > > > > > > > > FWIW - I am seeing this too, on a Supermicro P3TDDE. 7-STABLE src from > > > > 28-Feb is fine, but Mar, Apr, May code all hangs after printing "loading > > > > /boot/defaults/loader.conf" - presumably reading my /boot/loader.conf? > > > > > > > > Interestingly I can usually get it to boot by escaping to the loader > > > > prompt and then just pressing return. > > > > > > > > Oddly some other machines (Supermicro P3TDER and Asus PRO31J Laptop) > > > > behave normally with src from Mar->May. > > > > > > > > In all cases the canonical procedure from UPDATING was used (buildworld, > > > > kernel, reboot single, mergemaster -p, installworld, delete-old, > > > > mergemaster, reboot). > > > > > > > > I happy to help collect some debug info (how do you switch this on for > > > > the loader?), tho the machine exhibiting the problem is my workstation > > > > (of course)! > > > > > > Try to install new bootblock. > > > > I would be wary of that as it might make things worse? These problems are all > > from starting /boot/loader. boot2 is still working fine and thus there is > > still the possiblity of using boot2 to load /boot/loader.old as a workaround. > > If you update boot2 and it breaks you can't fix that w/o booting off of some > > other media such as a CD. > > > > Debugging these hangs is not easy to do remotely. If you know assembly then > > there are some things you can play with. For example, in the case where it > > hangs after printing out the BTX version (from btxldr.S) you could start > > adding debugging to btx.S to print out '.' characters in various places and > > see how many get printed out before it hangs. However, doing this requires > > familiarity with assembly and is a lot easier with physical access to a box. > > When I worked on my version of the realbtx, I sometimes experienced hangs when > vm86 btx run before real-mode btx. I did not investigated it then, only noted > the issue. We could get a hang if a vm86 request was ever done with interrupts disabled for some reason. I'll see if I can add some assertions to make BTX explicitly panic if that happens. -- John Baldwin From jhb at freebsd.org Fri May 23 22:11:18 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri May 23 22:11:23 2008 Subject: BTX loader hangs after version info In-Reply-To: <20080523132645.GO29770@deviant.kiev.zoral.com.ua> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> Message-ID: <200805231811.01936.jhb@freebsd.org> On Friday 23 May 2008 09:26:45 am Kostik Belousov wrote: > On Fri, May 23, 2008 at 08:29:09AM -0400, John Baldwin wrote: > > On Friday 23 May 2008 07:53:11 am Kostik Belousov wrote: > > > On Fri, May 23, 2008 at 01:22:55PM +1200, Mark Kirkwood wrote: > > > > James Seward wrote: > > > > >Hello, > > > > > > > > > >Two days ago I csup'd my desktop at home, which was running RELENG_7 > > > > >from about 7.0-RELEASE time, to bring it up-to-date (still on > > > > >RELENG_7). I followed my usual buildkernel/world procedure (the usual > > > > >one) which has worked fine all the way since 5.x. After installing > > > > >kernel and restarting in single user, it was working fine. However, > > > > >following installworld it will not boot. > > > > > > > > > >It stops immediately after "BTX loader 1.00 BTX version 1.02", but > > > > >with the cursor on the line *above* the first "B". Nothing futher > > > > >happens, but the system responds to Ctrl-Alt-Del. > > > > > > > > > >I have managed to start it using the install CD and csup'd back to a > > > > >version just before the commit to BTX that moved it to 1.02 (March > > > > >18th, I think). However, that version too hangs after "BTX loader 1.00 > > > > >BTX version 1.01". > > > > > > > > > >My desktop is currently building RELENG_7_0 to see if that will work, > > > > >but I won't know that until later as I'm at work and it is at home :) > > > > > > > > > >The install CD (BTX 1.00/1.01) boots fine. Nothing else changed on my > > > > >system between the last successful boot and the unsuccessful one. > > > > > > > > > >Any suggestions/advice for what I can try next, or what I can do to > > > > >help the troubleshooting process? > > > > > > > > > >My desktop is an Athlon64 but I am using i386, on an Asus A8V-E Deluxe > > > > >board. > > > > > > > > FWIW - I am seeing this too, on a Supermicro P3TDDE. 7-STABLE src from > > > > 28-Feb is fine, but Mar, Apr, May code all hangs after printing "loading > > > > /boot/defaults/loader.conf" - presumably reading my /boot/loader.conf? > > > > > > > > Interestingly I can usually get it to boot by escaping to the loader > > > > prompt and then just pressing return. > > > > > > > > Oddly some other machines (Supermicro P3TDER and Asus PRO31J Laptop) > > > > behave normally with src from Mar->May. > > > > > > > > In all cases the canonical procedure from UPDATING was used (buildworld, > > > > kernel, reboot single, mergemaster -p, installworld, delete-old, > > > > mergemaster, reboot). > > > > > > > > I happy to help collect some debug info (how do you switch this on for > > > > the loader?), tho the machine exhibiting the problem is my workstation > > > > (of course)! > > > > > > Try to install new bootblock. > > > > I would be wary of that as it might make things worse? These problems are all > > from starting /boot/loader. boot2 is still working fine and thus there is > > still the possiblity of using boot2 to load /boot/loader.old as a workaround. > > If you update boot2 and it breaks you can't fix that w/o booting off of some > > other media such as a CD. > > > > Debugging these hangs is not easy to do remotely. If you know assembly then > > there are some things you can play with. For example, in the case where it > > hangs after printing out the BTX version (from btxldr.S) you could start > > adding debugging to btx.S to print out '.' characters in various places and > > see how many get printed out before it hangs. However, doing this requires > > familiarity with assembly and is a lot easier with physical access to a box. > > When I worked on my version of the realbtx, I sometimes experienced hangs when > vm86 btx run before real-mode btx. I did not investigated it then, only noted > the issue. > Try this patch. I'm not 100% certain this will fix it as I can't reproduce the issue, but I think it might help. Specifically, when the boot code makes a v86 call, the loader/boot2/whatever swaps in/out a new set of registers via the v86 structure including the eflags register. However, none of the boot programs actually initialized the v86 structure. Thus, the BIOS routines would start off running with whatever garbage was in v86.efl when each boot program started. This meant that we could end up invoking BIOS routines with interrupts disabled, and I think this might explain a hard hang (if a BIOS routine was waiting for an interrupt the interrupt would never fire). The patch fixes all the boot programs to initialize v86 to a better known state. At the least it sets v86.efl to a sane value (0x202) rather than random. (The random might have always been 0x0 BTW, not sure on that one.) --- //depot/vendor/freebsd/src/sys/boot/i386/boot2/boot2.c 2008/02/28 17:10:57 +++ //depot/user/jhb/boot/sys/boot/i386/boot2/boot2.c 2008/05/23 21:59:59 @@ -24,6 +24,7 @@ #include #include +#include #include @@ -83,8 +84,8 @@ #define NDEV 3 #define MEM_BASE 0x12 #define MEM_EXT 0x15 -#define V86_CY(x) ((x) & 1) -#define V86_ZR(x) ((x) & 0x40) +#define V86_CY(x) ((x) & PSL_C) +#define V86_ZR(x) ((x) & PSL_Z) #define DRV_HARD 0x80 #define DRV_MASK 0x7f @@ -237,6 +238,7 @@ dmadat = (void *)(roundup2(__base + (int32_t)&_end, 0x10000) - __base); v86.ctl = V86_FLAGS; + v86.efl = PSL_RESERVED_DEFAULT | PSL_I; dsk.drive = *(uint8_t *)PTOV(ARGS); dsk.type = dsk.drive & DRV_HARD ? TYPE_AD : TYPE_FD; dsk.unit = dsk.drive & DRV_MASK; --- //depot/vendor/freebsd/src/sys/boot/i386/gptboot/gptboot.c 2008/02/28 17:10:57 +++ //depot/user/jhb/boot/sys/boot/i386/gptboot/gptboot.c 2008/05/23 21:59:59 @@ -23,6 +23,7 @@ #include #include +#include #include @@ -81,8 +82,8 @@ #define NDEV 3 #define MEM_BASE 0x12 #define MEM_EXT 0x15 -#define V86_CY(x) ((x) & 1) -#define V86_ZR(x) ((x) & 0x40) +#define V86_CY(x) ((x) & PSL_C) +#define V86_ZR(x) ((x) & PSL_Z) #define DRV_HARD 0x80 #define DRV_MASK 0x7f @@ -235,6 +236,7 @@ dmadat = (void *)(roundup2(__base + (int32_t)&_end, 0x10000) - __base); v86.ctl = V86_FLAGS; + v86.efl = PSL_RESERVED_DEFAULT | PSL_I; dsk.drive = *(uint8_t *)PTOV(ARGS); dsk.type = dsk.drive & DRV_HARD ? TYPE_AD : TYPE_FD; dsk.unit = dsk.drive & DRV_MASK; --- //depot/vendor/freebsd/src/sys/boot/i386/loader/main.c 2007/10/24 04:07:14 +++ //depot/user/jhb/boot/sys/boot/i386/loader/main.c 2008/05/23 21:59:59 @@ -35,6 +35,7 @@ #include #include #include +#include #include #include "bootstrap.h" @@ -86,6 +87,10 @@ initial_bootdev = kargs->bootdev; initial_bootinfo = kargs->bootinfo ? (struct bootinfo *)PTOV(kargs->bootinfo) : NULL; + /* Initialize the v86 register set to a known-good state. */ + bzero(&v86, sizeof(v86)); + v86.efl = PSL_RESERVED_DEFAULT | PSL_I; + /* * Initialise the heap as early as possible. Once this is done, malloc() is usable. */ --- //depot/vendor/freebsd/src/sys/boot/pc98/loader/main.c 2007/10/24 11:57:58 +++ //depot/user/jhb/boot/sys/boot/pc98/loader/main.c 2008/05/23 22:03:45 @@ -35,6 +35,7 @@ #include #include #include +#include #include #include "bootstrap.h" @@ -86,6 +87,10 @@ initial_bootdev = kargs->bootdev; initial_bootinfo = kargs->bootinfo ? (struct bootinfo *)PTOV(kargs->bootinfo) : NULL; + /* Initialize the v86 register set to a known-good state. */ + bzero(&v86, sizeof(v86)); + v86.efl = PSL_RESERVED_DEFAULT | PSL_I; + /* * Initialise the heap as early as possible. Once this is done, malloc() is usable. */ -- John Baldwin From unga888 at yahoo.com Sat May 24 01:37:47 2008 From: unga888 at yahoo.com (Unga) Date: Sat May 24 01:37:52 2008 Subject: sched_ule performance on single CPU In-Reply-To: <200805231616.m4NGGNkK026611@lurza.secnetix.de> Message-ID: <555870.1659.qm@web57010.mail.re3.yahoo.com> --- Oliver Fromme wrote: > Unga wrote: > > Idle-prio process which generates lot of I/O is > > understandable. > > > > But when you either record or playback audio as > > realtime-prio and you opened up a pdf document as > > normal-prio, can the pdf rendering in normal-prio > > breaks down the realtime audio process? I don't > think > > pdf rendering is I/O intensive. > > I think it can. > > Opening a PDF causes quite a lot of I/O. The viewer > application has to be paged in from disk, all the > libraries and configuration files it uses, possibly > even parts of the X server have to be paged in, > depending on what features of the X protocol and > which extensions the viewer application uses. > And of course the PDF itself has to be loaded (which > might be not small), and finally all fonts used by > the PDF have to be loaded by the viewer application. > > On the other hand, the default buffer space of the > audio driver is quite small (the reason for that is > to reduce latency for sound effects in games). So > even a very short I/O congestion can cause an > audible > hiccup in audio playback or recording. > > > Using a faster processor or multi-core may solve > this > > problem, > > No, faster I/O hardware will solve it, or hardware > that better supports concurrent access. It's also > quite possible that improvements in FreeBSD's disk > system might solve the problem, i.e. by reordering > disk access in a more efficient manner, but this is > very non-trivial. But all of that is not a matter > of the process scheduler. > > Anotehr solution is to use more aggressive buffering > by either the audio application or the audio driver. > The latter can be set via sysctl. The former is a > matter of your audio application. > > I use mpg123 for mp3 playback on a 3-year old UP > machine. It has a buffer option which I use. > E.g. "mpg123 -b5000" will use 5 MB buffer; that's > enough for half a minute of audio. I do not use > renice, idprio, rtprio or anything, but still > audio playback works perfectly fine, even during > a buildworld. Or when opening a PDF. No hiccups. > Noted your points. When open an pdf has two types of scenarios in FreeBSD: 1. When X run as a realtime-prio process, X go mad and swallow up almost all of CPU cycles, making audio hiccups. 2. When X run as a normal-prio process, X behaves well and rarely gets an audible hiccup. Why X behave different under different priority categories? Isn't this scheduler related? I wonder the issue I mentioned, open a pdf while playback audio, is it a issue on Apple Mac OSX? Could somebody give some light here who uses an Apple Mac OSX on this list? If it is not an issue in Mac OSX, how they have overcome it then? Kind regards Unga From kris at FreeBSD.org Sat May 24 08:49:08 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sat May 24 08:49:10 2008 Subject: jail process limits In-Reply-To: <0FDDD3FE-395C-494C-8325-99FDB2BAEEB5@khera.org> References: <0FDDD3FE-395C-494C-8325-99FDB2BAEEB5@khera.org> Message-ID: <20080524084908.GK20868@hub.freebsd.org> On Thu, May 22, 2008 at 03:26:13PM -0400, Vivek Khera wrote: > While we're on the topic of jail resource limits, I think I'll ask my > question again... I asked last month but got no response... > > > I've got a jail server (FreeBSD 6.3/amd64) which runs a bunch of web > site development environments. There is an apache or lighttpd running > in each jail as user httpd (same UID on base system and each jail). > > On the jail host, I counted 231 processes owned by httpd. > > If I try to start an application server (or any process) as user httpd > in one of the jails, it exits immediately with "Cannot fork: Resource > temporarily unavailable". Even if I "su httpd" I get the same error > on any command I try to run such as "ls". If I run the same on the > jail host, it has no problems. The jail itself only has 34 processes > running. > > On the jail host, the following is logged: > > Apr 22 16:34:38 staging kernel: maxproc limit exceeded by uid 80, > please see tuning(7) and login.conf(5). > Can anyone tell me where to look to find out what is limiting user > httpd from creating new processes inside the jail, and what exactly > that limit is? More importantly, how to increase it. I'd start by instrumenting the code path that leads to the above kernel printf, to try and differentiate any possible causes. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From peter at holm.cc Sat May 24 15:01:37 2008 From: peter at holm.cc (Peter Holm) Date: Sat May 24 15:01:41 2008 Subject: BTX loader hangs after version info In-Reply-To: <200805231811.01936.jhb@freebsd.org> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> Message-ID: <20080524143453.GA51069@peter.osted.lan> On Fri, May 23, 2008 at 06:11:01PM -0400, John Baldwin wrote: > On Friday 23 May 2008 09:26:45 am Kostik Belousov wrote: > > On Fri, May 23, 2008 at 08:29:09AM -0400, John Baldwin wrote: > > > On Friday 23 May 2008 07:53:11 am Kostik Belousov wrote: > > > > On Fri, May 23, 2008 at 01:22:55PM +1200, Mark Kirkwood wrote: > > > > > James Seward wrote: > > > > > >Hello, > > > > > > > > > > > >Two days ago I csup'd my desktop at home, which was running RELENG_7 > > > > > >from about 7.0-RELEASE time, to bring it up-to-date (still on > > > > > >RELENG_7). I followed my usual buildkernel/world procedure (the usual > > > > > >one) which has worked fine all the way since 5.x. After installing > > > > > >kernel and restarting in single user, it was working fine. However, > > > > > >following installworld it will not boot. > > > > > > > > > > > >It stops immediately after "BTX loader 1.00 BTX version 1.02", but > > > > > >with the cursor on the line *above* the first "B". Nothing futher > > > > > >happens, but the system responds to Ctrl-Alt-Del. > > > > > > > > > > > >I have managed to start it using the install CD and csup'd back to a > > > > > >version just before the commit to BTX that moved it to 1.02 (March > > > > > >18th, I think). However, that version too hangs after "BTX loader 1.00 > > > > > >BTX version 1.01". > > > > > > > > > > > >My desktop is currently building RELENG_7_0 to see if that will work, > > > > > >but I won't know that until later as I'm at work and it is at home :) > > > > > > > > > > > >The install CD (BTX 1.00/1.01) boots fine. Nothing else changed on my > > > > > >system between the last successful boot and the unsuccessful one. > > > > > > > > > > > >Any suggestions/advice for what I can try next, or what I can do to > > > > > >help the troubleshooting process? > > > > > > > > > > > >My desktop is an Athlon64 but I am using i386, on an Asus A8V-E Deluxe > > > > > >board. > > > > > > > > > > FWIW - I am seeing this too, on a Supermicro P3TDDE. 7-STABLE src from > > > > > 28-Feb is fine, but Mar, Apr, May code all hangs after printing "loading > > > > > /boot/defaults/loader.conf" - presumably reading my /boot/loader.conf? > > > > > > > > > > Interestingly I can usually get it to boot by escaping to the loader > > > > > prompt and then just pressing return. > > > > > > > > > > Oddly some other machines (Supermicro P3TDER and Asus PRO31J Laptop) > > > > > behave normally with src from Mar->May. > > > > > > > > > > In all cases the canonical procedure from UPDATING was used (buildworld, > > > > > kernel, reboot single, mergemaster -p, installworld, delete-old, > > > > > mergemaster, reboot). > > > > > > > > > > I happy to help collect some debug info (how do you switch this on for > > > > > the loader?), tho the machine exhibiting the problem is my workstation > > > > > (of course)! > > > > > > > > Try to install new bootblock. > > > > > > I would be wary of that as it might make things worse? These problems are all > > > from starting /boot/loader. boot2 is still working fine and thus there is > > > still the possiblity of using boot2 to load /boot/loader.old as a workaround. > > > If you update boot2 and it breaks you can't fix that w/o booting off of some > > > other media such as a CD. > > > > > > Debugging these hangs is not easy to do remotely. If you know assembly then > > > there are some things you can play with. For example, in the case where it > > > hangs after printing out the BTX version (from btxldr.S) you could start > > > adding debugging to btx.S to print out '.' characters in various places and > > > see how many get printed out before it hangs. However, doing this requires > > > familiarity with assembly and is a lot easier with physical access to a box. > > > > When I worked on my version of the realbtx, I sometimes experienced hangs when > > vm86 btx run before real-mode btx. I did not investigated it then, only noted > > the issue. > > > > Try this patch. I'm not 100% certain this will fix it as I can't reproduce > the issue, but I think it might help. Specifically, when the boot code makes > a v86 call, the loader/boot2/whatever swaps in/out a new set of registers via > the v86 structure including the eflags register. However, none of the boot > programs actually initialized the v86 structure. Thus, the BIOS routines > would start off running with whatever garbage was in v86.efl when each boot > program started. This meant that we could end up invoking BIOS routines with > interrupts disabled, and I think this might explain a hard hang (if a BIOS > routine was waiting for an interrupt the interrupt would never fire). The > patch fixes all the boot programs to initialize v86 to a better known state. > At the least it sets v86.efl to a sane value (0x202) rather than random. (The > random might have always been 0x0 BTW, not sure on that one.) > I can confirm that this patch fixes the loader problem seen with my old Tyan S2720 MB. - Peter From jamesoff at gmail.com Sat May 24 16:34:59 2008 From: jamesoff at gmail.com (James Seward) Date: Sat May 24 16:35:03 2008 Subject: BTX loader hangs after version info In-Reply-To: <200805231811.01936.jhb@freebsd.org> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> Message-ID: <720051dc0805240934o211c522eha6888dc55ebd928f@mail.gmail.com> `On Fri, May 23, 2008 at 11:11 PM, John Baldwin wrote: > [patch] I have not yet tried this patch, but here is my progress so far: * Rolling back to 7.0-RELEASE made it worse - now after choosing FreeBSD from grub the machine would immediately reboot. * I booted with the CD again and came forward to RELENG_7. This still caused an immediate reboot. * I booted with the CD and replaced grub with "boot0cfg -B" (bsdlabel, which I tried earlier, had no effect). This fixed it, mostly. My desktop now boots fine and completes normal startup. It even starts X. However, from the moment I press F1 to choose FreeBSD to the moment it's done booting, all I see on the screen is "BTX loader 1.00 BTX version is 1.02" and the cursor blinking below it. My only clues that it's booting at the time are disk activity, and the cursor changing from a flashing underline to a solid block (which it always has as the kernel proper takes over). The next thing I see is "FreeBSD/i386 (hostname.goes.here) (ttyv0)". I have also noticed that I don't get any output when I restart - no rc.d scripts telling me things are stopping, no vnodes syncing, nothing. It's apparently happening though, as everything is starting/stopping/umounting correctly. I don't see that I have anything configured to boot to serial rather than the console, but is there anything I can do/check to make sure this definitely isn't happening? Unfortunately, putting a cable on the serial port is not an option as I currently do not own one suitable :) Thanks, James From lists at thefrog.net Sat May 24 16:53:30 2008 From: lists at thefrog.net (Andrew Hill) Date: Sat May 24 16:53:38 2008 Subject: ZFS on root and disk write caching. Message-ID: <16a6ef710805240926t3b4f631bja349fed8df6785ff@mail.gmail.com> I don't have a definite answer to your first two questions (I've got a similar set up and would be interested to get some definite answers to those) however I'd like to comment on your third point... On May 21, 11:00 pm, arnaud.houdele...@tzim.net (Arnaud Houdelette) wrote: > 3. I'd like to keep the storage pool (zraid1) separated from the system > pool (just one disk). The wiki states that we may encounter problems > with more than one pool in use : is it still the case ? as for encountering problems with multiple zpools, my impression from the mailing lists is that it seems to work fine for some people and not for others... (i'm in the latter category, unfortunately) but what struck me as odd is the desire to create two separate zpools - one for data storage and one for the system. i think one of zfs's greatest strengths is the abstraction/separation between disks and filesystems. unless you're planning on removing/recreating the raidz1 pool in the near future, it seems a bit odd to put your system on a single/separate, non-redundant drive when you could just create a raidz across all four disks with storage and system filesystems in the one raidz pool. this way you don't lose anything if the disk you chose to run the OS from happens to fail, or even just gets a bad sector in an unfortunately crucial location... And even if you were going to recreate the raidz pool in the near future, it shouldn't be too hard to backup the system filesystems with zfs snapshot/send/receive commands, recreate the pool and then restore the system filesystems from the backup Andrew From eugen at kuzbass.ru Sat May 24 17:00:40 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sat May 24 17:00:44 2008 Subject: BTX loader hangs after version info In-Reply-To: <720051dc0805240934o211c522eha6888dc55ebd928f@mail.gmail.com> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <720051dc0805240934o211c522eha6888dc55ebd928f@mail.gmail.com> Message-ID: <20080524170036.GA3385@svzserv.kemerovo.su> On Sat, May 24, 2008 at 05:34:57PM +0100, James Seward wrote: > X. However, from the moment I press F1 to choose FreeBSD to the moment > it's done booting, all I see on the screen is "BTX loader 1.00 BTX > version is 1.02" and the cursor blinking below it. My only clues that > it's booting at the time are disk activity, and the cursor changing > from a flashing underline to a solid block (which it always has as the > kernel proper takes over). It seems you have /boot/device.hints missing or broken. Just do "cp /usr/src/sys/i386/conf/GENERIC.hints /boot/device.hints". Eugene Grosbein From zbeeble at gmail.com Sat May 24 20:08:38 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Sat May 24 20:08:42 2008 Subject: ZFS on root and disk write caching. In-Reply-To: <16a6ef710805240926t3b4f631bja349fed8df6785ff@mail.gmail.com> References: <16a6ef710805240926t3b4f631bja349fed8df6785ff@mail.gmail.com> Message-ID: <5f67a8c40805241308s15c98737w29bd66c0273bfe95@mail.gmail.com> On Sat, May 24, 2008 at 12:26 PM, Andrew Hill wrote: > but what struck me as odd is the desire to create two separate zpools - one > for data storage and one for the system. i think one of zfs's greatest > strengths is the abstraction/separation between disks and filesystems. There are a few reasons to consider more than one zpool. One is performance. Another is the ability to boot from it (AFAIK, you can only boot from mirror'd pools). The ZFS abstraction is cool --- but it's not magic. From cswiger at mac.com Sat May 24 20:17:01 2008 From: cswiger at mac.com (Chuck Swiger) Date: Sat May 24 20:17:06 2008 Subject: sched_ule performance on single CPU In-Reply-To: <555870.1659.qm@web57010.mail.re3.yahoo.com> References: <555870.1659.qm@web57010.mail.re3.yahoo.com> Message-ID: <35C9A4DD-3491-4850-92D5-CBE2BE4F814F@mac.com> On May 23, 2008, at 6:37 PM, Unga wrote: > When open an pdf has two types of scenarios in FreeBSD: > 1. When X run as a realtime-prio process, X go mad and swallow up > almost all of CPU cycles, making audio hiccups. > > 2. When X run as a normal-prio process, X behaves well and rarely > gets an audible hiccup. > > Why X behave different under different priority categories? Isn't > this scheduler related? Sure. To generalize, the traditional scheduler goal for Unix has been to maximize overall throughput and avoid starvation of even low- priority tasks, at the expense of higher and unpredictable latency. Using realtime priority means that the kernel is told to minimize latency for that process even if it means starving other processes of CPU time. That is well suited for things like CD/DVD burning or audio/visual capture, but as you've experienced yourself, it does poorly for heavily client-server oriented stuff like X11's architecture. > I wonder the issue I mentioned, open a pdf while playback audio, is > it a issue on Apple Mac OSX? Nope. :-) > Could somebody give some light here who uses an Apple Mac OSX on > this list? > > If it is not an issue in Mac OSX, how they have overcome it then? While both FreeBSD and MacOS X are general-purpose operating systems, doing multimedia creation and playback is among the primary functionality goals for MacOS X, in much the same way that FreeBSD regards providing "robust network services" like Apache, DNS, email, databases and so forth. Core Audio is probably the biggest user of realtime thread scheduling under MacOS X, followed by QuickTime or DVD playback over Core Video. These frameworks were designed to handle multimedia without skipping by preallocating sensible amounts of buffer space, and they take advantage of the Mach kernel and IOKit drivers which are intended to support realtime needs. Unlike the traditional BSD kernels, the Mach kernel was originally designed with SMP, soft & hard realtime scheduling in the kernel. The original userland threads library which came with Mach, called CThreads, was largely responsible for the design that was abstracted into the portable POSIX threads model widely used today. After FreeBSD 4, there has been a tremendous amount of work in the kernel on fine-grained locking and moving device drivers from running in the non-preemptable interrupt context to having device kernel threads which can be preempted, and there has also been a lot of work on the userland side to improve the C threading libraries and to improve multithreaded malloc() performance via jemalloc, but this is still ongoing and higher level applications like X11 programs haven't had years to adapt and take advantage of these changes. Simple things like auto-tuning the size of the audio buffers to avoid or minimize skipping or dropouts isn't really in place yet with FreeBSD. Realtime video on FreeBSD is dependent upon X11, which was originally designed by a bunch of guys at MIT to be able to display lots of xterms or other things involving simple blits of bits, possibly over the network, in order to replace the Andrew window manager system used by CMU, MIT, IBM, and a few others. X11 wasn't designed to do alpha channel (aka transparency), much less stream a couple of hundred MB per second of data for realtime OpenGL texturing or video. (Although, Composite and GLX have since been added to X11, they are extensions rather than core functionality, and hardware driver support for GLX is less than perfectly available, especially once you start looking at the AMD64/EM64T platform, rather than 32-bit x86....) There's a 2002 BSDcon paper here, written around the time of FreeBSD 5.x's release, which has more details: http://www.usenix.org/events/bsdcon02/full_papers/gerbarg/gerbarg_html/ Regards, -- -Chuck From markir at paradise.net.nz Sun May 25 07:05:17 2008 From: markir at paradise.net.nz (Mark Kirkwood) Date: Sun May 25 07:05:21 2008 Subject: BTX loader hangs after version info In-Reply-To: <200805231811.01936.jhb@freebsd.org> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> Message-ID: <48390FA9.5080503@paradise.net.nz> John Baldwin wrote: > > Try this patch. I'm not 100% certain this will fix it as I can't reproduce > the issue, but I think it might help. Specifically, when the boot code makes > a v86 call, the loader/boot2/whatever swaps in/out a new set of registers via > the v86 structure including the eflags register. However, none of the boot > programs actually initialized the v86 structure. Thus, the BIOS routines > would start off running with whatever garbage was in v86.efl when each boot > program started. This meant that we could end up invoking BIOS routines with > interrupts disabled, and I think this might explain a hard hang (if a BIOS > routine was waiting for an interrupt the interrupt would never fire). The > patch fixes all the boot programs to initialize v86 to a better known state. > At the least it sets v86.efl to a sane value (0x202) rather than random. (The > random might have always been 0x0 BTW, not sure on that one.) > > Thanks John, Unfortunately this patch does *not* cure the issue for my old Supermicro P3TDDE, it still hangs just before presenting the menu. I had to boot off the livefs and copy /boot/loader.old -> /boot/loader to get back to being bootable again - but at least the old fella is on a more up-to-date 7-STABLE now :-) Cheers Mark From markir at paradise.net.nz Sun May 25 08:33:29 2008 From: markir at paradise.net.nz (Mark Kirkwood) Date: Sun May 25 08:33:34 2008 Subject: BTX loader hangs after version info In-Reply-To: <48390FA9.5080503@paradise.net.nz> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> Message-ID: <4839243D.7000700@paradise.net.nz> I wrote: > John Baldwin wrote: >> >> Try this patch. I'm not 100% certain this will fix it as I can't >> reproduce >> the issue, but I think it might help. Specifically, when the boot >> code makes >> a v86 call, the loader/boot2/whatever swaps in/out a new set of >> registers via >> the v86 structure including the eflags register. However, none of >> the boot >> programs actually initialized the v86 structure. Thus, the BIOS >> routines >> would start off running with whatever garbage was in v86.efl when >> each boot >> program started. This meant that we could end up invoking BIOS >> routines with >> interrupts disabled, and I think this might explain a hard hang (if a >> BIOS >> routine was waiting for an interrupt the interrupt would never >> fire). The >> patch fixes all the boot programs to initialize v86 to a better known >> state. At the least it sets v86.efl to a sane value (0x202) rather >> than random. (The >> random might have always been 0x0 BTW, not sure on that one.) >> >> > Thanks John, > > Unfortunately this patch does *not* cure the issue for my old > Supermicro P3TDDE, it still hangs just before presenting the menu. I > had to boot off the livefs and copy /boot/loader.old -> /boot/loader > to get back to being bootable again - but at least the old fella is on > a more up-to-date 7-STABLE now :-) Given that the patch *did* cure Peters Tyan S2720, I'll double check I didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, whereas the P3TDDE has Award BIOS). Anyway, I'll double check and report back... Cheers Mark From freebsd at meijome.net Sun May 25 08:55:37 2008 From: freebsd at meijome.net (Norberto Meijome) Date: Sun May 25 08:55:42 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: <4836660D.1070801@icyb.net.ua> References: <48351A70.8090402@icyb.net.ua> <4836660D.1070801@icyb.net.ua> Message-ID: <20080525185503.7642e736@ayiin> On Fri, 23 May 2008 09:37:01 +0300 Andriy Gapon wrote: > >> But, by the way, there is a (slightly) more valid reason to want to > >> create a directory under /dev, I recently had it. For one non-standard > >> third-party application I needed to create a link to existing device in > >> a certain subdirectory. I.e.: > >> /dev/subdirX/device -> /dev/deviceX > >> And I couldn't do that. > >> Or maybe link operation for devfs just needs to be taught about creating > >> subdirectories on demand. I don't know. > > > > you can create links with devfs - man devfs.conf > > [...] > > link This action creates a symbolic link named arg that points to > > devname, the name of the device created by devfs(5). > > [..] > > I do know that. > Maybe I wasn't clear enough: "/dev/deviceX" was existing device node and > I needed to create "/dev/subdirX/device" link, where directory > "/dev/subdirX" didn't exist. > Any help on this? Not sure, but like someone mentioned parts of the system create this (geom?) . you can check its code to see how its done. good luck, B _________________________ {Beto|Norberto|Numard} Meijome Commitment is active, not passive. Commitment is doing whatever you can to bring about the desired result. Anything less is half-hearted. 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. From jille at quis.cx Sun May 25 10:31:29 2008 From: jille at quis.cx (Jille) Date: Sun May 25 10:31:34 2008 Subject: Is it possible to create a directory under /dev? In-Reply-To: <200805231600.m4NG0oWq025982@lurza.secnetix.de> References: <200805231600.m4NG0oWq025982@lurza.secnetix.de> Message-ID: <48393B70.7010405@quis.cx> Please note that unionfs still has a few bugs! You will need at least patchset p19 for mounting devfs below/above unionfs mounts. There is also a patchset p20, still experimental, you might want to try it. -- Jille Oliver Fromme schreef: > Andriy Gapon wrote: > > But, by the way, there is a (slightly) more valid reason to want to > > create a directory under /dev, I recently had it. For one non-standard > > third-party application I needed to create a link to existing device in > > a certain subdirectory. I.e.: > > /dev/subdirX/device -> /dev/deviceX > > And I couldn't do that. > > You could create a directory elsewhere and use UNIONFS to > merge it with your existing /dev. I haven't tried this, > but I think it should work. > > # mkdir /mydev > # mount -t unionfs -o below /mydev /dev > # cd /mydev > # mkdir subdirX > # ln -s /dev/deviceX subdirX/device > > The "-o below" option is used so that any modifications on > /dev -- such as creating symlinks -- still happen on the > real /dev, not on /mydev. > > Best regards > Oliver > From unga888 at yahoo.com Sun May 25 12:24:27 2008 From: unga888 at yahoo.com (Unga) Date: Sun May 25 12:24:35 2008 Subject: sched_ule performance on single CPU In-Reply-To: <35C9A4DD-3491-4850-92D5-CBE2BE4F814F@mac.com> Message-ID: <81954.15280.qm@web57005.mail.re3.yahoo.com> --- Chuck Swiger wrote: > On May 23, 2008, at 6:37 PM, Unga wrote: > > When open an pdf has two types of scenarios in > FreeBSD: > > 1. When X run as a realtime-prio process, X go mad > and swallow up > > almost all of CPU cycles, making audio hiccups. > > > > 2. When X run as a normal-prio process, X behaves > well and rarely > > gets an audible hiccup. > > > > Why X behave different under different priority > categories? Isn't > > this scheduler related? > > Sure. To generalize, the traditional scheduler goal > for Unix has been > to maximize overall throughput and avoid starvation > of even low- > priority tasks, at the expense of higher and > unpredictable latency. > Using realtime priority means that the kernel is > told to minimize > latency for that process even if it means starving > other processes of > CPU time. > > That is well suited for things like CD/DVD burning > or audio/visual > capture, but as you've experienced yourself, it does > poorly for > heavily client-server oriented stuff like X11's > architecture. > > > I wonder the issue I mentioned, open a pdf while > playback audio, is > > it a issue on Apple Mac OSX? > > Nope. :-) > > > Could somebody give some light here who uses an > Apple Mac OSX on > > this list? > > > > If it is not an issue in Mac OSX, how they have > overcome it then? > > > While both FreeBSD and MacOS X are general-purpose > operating systems, > doing multimedia creation and playback is among the > primary > functionality goals for MacOS X, in much the same > way that FreeBSD > regards providing "robust network services" like > Apache, DNS, email, > databases and so forth. > > Core Audio is probably the biggest user of realtime > thread scheduling > under MacOS X, followed by QuickTime or DVD playback > over Core Video. > These frameworks were designed to handle multimedia > without skipping > by preallocating sensible amounts of buffer space, > and they take > advantage of the Mach kernel and IOKit drivers which > are intended to > support realtime needs. Unlike the traditional BSD > kernels, the Mach > kernel was originally designed with SMP, soft & hard > realtime > scheduling in the kernel. The original userland > threads library which > came with Mach, called CThreads, was largely > responsible for the > design that was abstracted into the portable POSIX > threads model > widely used today. > > After FreeBSD 4, there has been a tremendous amount > of work in the > kernel on fine-grained locking and moving device > drivers from running > in the non-preemptable interrupt context to having > device kernel > threads which can be preempted, and there has also > been a lot of work > on the userland side to improve the C threading > libraries and to > improve multithreaded malloc() performance via > jemalloc, but this is > still ongoing and higher level applications like X11 > programs haven't > had years to adapt and take advantage of these > changes. > > Simple things like auto-tuning the size of the audio > buffers to avoid > or minimize skipping or dropouts isn't really in > place yet with > FreeBSD. Realtime video on FreeBSD is dependent > upon X11, which was > originally designed by a bunch of guys at MIT to be > able to display > lots of xterms or other things involving simple > blits of bits, > possibly over the network, in order to replace the > Andrew window > manager system used by CMU, MIT, IBM, and a few > others. X11 wasn't > designed to do alpha channel (aka transparency), > much less stream a > couple of hundred MB per second of data for realtime > OpenGL texturing > or video. (Although, Composite and GLX have since > been added to X11, > they are extensions rather than core functionality, > and hardware > driver support for GLX is less than perfectly > available, especially > once you start looking at the AMD64/EM64T platform, > rather than 32-bit > x86....) > > There's a 2002 BSDcon paper here, written around the > time of FreeBSD > 5.x's release, which has more details: > > http://www.usenix.org/events/bsdcon02/full_papers/gerbarg/gerbarg_html/ > Thank you very much for the detailed info. It seems FreeBSD may need two schedulers, one for desktop and one for server, among other things. Kind regards Unga From peter at holm.cc Sun May 25 14:59:10 2008 From: peter at holm.cc (Peter Holm) Date: Sun May 25 14:59:16 2008 Subject: BTX loader hangs after version info In-Reply-To: <4839243D.7000700@paradise.net.nz> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> Message-ID: <20080525145906.GA96904@peter.osted.lan> On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > I wrote: > >John Baldwin wrote: > >> > >>Try this patch. I'm not 100% certain this will fix it as I can't > >>reproduce > >>the issue, but I think it might help. Specifically, when the boot > >>code makes > >>a v86 call, the loader/boot2/whatever swaps in/out a new set of > >>registers via > >>the v86 structure including the eflags register. However, none of > >>the boot > >>programs actually initialized the v86 structure. Thus, the BIOS > >>routines > >>would start off running with whatever garbage was in v86.efl when > >>each boot > >>program started. This meant that we could end up invoking BIOS > >>routines with > >>interrupts disabled, and I think this might explain a hard hang (if a > >>BIOS > >>routine was waiting for an interrupt the interrupt would never > >>fire). The > >>patch fixes all the boot programs to initialize v86 to a better known > >>state. At the least it sets v86.efl to a sane value (0x202) rather > >>than random. (The > >>random might have always been 0x0 BTW, not sure on that one.) > >> > >> > >Thanks John, > > > >Unfortunately this patch does *not* cure the issue for my old > >Supermicro P3TDDE, it still hangs just before presenting the menu. I > >had to boot off the livefs and copy /boot/loader.old -> /boot/loader > >to get back to being bootable again - but at least the old fella is on > >a more up-to-date 7-STABLE now :-) > > Given that the patch *did* cure Peters Tyan S2720, I'll double check I > didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - > same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, > whereas the P3TDDE has Award BIOS). > > Anyway, I'll double check and report back... > > Cheers > > Mark I now have booted some more with this patch and it would seem that the problem is still there, from time to time! Most of the time I now boot without any problems but once in a while the loader still hangs. I'll try to gather some statistics... -- Peter From delphij at delphij.net Sun May 25 16:05:16 2008 From: delphij at delphij.net (Xin LI) Date: Sun May 25 16:05:19 2008 Subject: What does system do after "Uptime: "? In-Reply-To: <1211448313.71119.1.camel@buffy.york.ac.uk> References: <481560AC.90109@delphij.net> <1209376409.59233.14.camel@buffy.york.ac.uk> <4818BF27.2080209@delphij.net> <200804301544.20802.jhb@freebsd.org> <1209660552.68622.53.camel@buffy.york.ac.uk> <4819F6D3.80104@delphij.net> <1211448313.71119.1.camel@buffy.york.ac.uk> Message-ID: <48398E31.1030001@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gavin Atkinson wrote: | On Thu, 2008-05-01 at 09:58 -0700, Xin LI wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Gavin Atkinson wrote: |> | FWIW, there have been probably around 10 PRs in in the last few months |> | about this behaviour. I'd vote for it as an errata candidate. |> |> FWIW I have written to re@ indicating some changes I wanted for |> RELENG_7_0 as candidates. Could you please let me know if I have missed |> something important? |> |> http://www.delphij.net/errata-20080430.xml | | Did you get anywhere with this request? PRs are still coming in about | the "hang after Uptime:" issue. | | If the errata candidates were turned down, I think we need to have an | entry in the release notes errata... The latest list is: http://www.delphij.net/errata-20080511.xml And what would be finally made into errata is still under discussion. Cheers, - -- ** Help China's quake relief at http://www.redcross.org.cn/ |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkg5jjEACgkQi+vbBBjt66BmUACfUWWd1M3Ribis+YvvhEb78mlS 5LsAoLhcGhxBbpHBzUjVVVgB+M3IAnmM =aI4C -----END PGP SIGNATURE----- From peter at holm.cc Sun May 25 17:16:36 2008 From: peter at holm.cc (Peter Holm) Date: Sun May 25 17:16:43 2008 Subject: BTX loader hangs after version info In-Reply-To: <4839243D.7000700@paradise.net.nz> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> Message-ID: <20080525171632.GA1305@peter.osted.lan> On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > I wrote: > >John Baldwin wrote: > >> > >>Try this patch. I'm not 100% certain this will fix it as I can't > >>reproduce > >>the issue, but I think it might help. Specifically, when the boot > >>code makes > >>a v86 call, the loader/boot2/whatever swaps in/out a new set of > >>registers via > >>the v86 structure including the eflags register. However, none of > >>the boot > >>programs actually initialized the v86 structure. Thus, the BIOS > >>routines > >>would start off running with whatever garbage was in v86.efl when > >>each boot > >>program started. This meant that we could end up invoking BIOS > >>routines with > >>interrupts disabled, and I think this might explain a hard hang (if a > >>BIOS > >>routine was waiting for an interrupt the interrupt would never > >>fire). The > >>patch fixes all the boot programs to initialize v86 to a better known > >>state. At the least it sets v86.efl to a sane value (0x202) rather > >>than random. (The > >>random might have always been 0x0 BTW, not sure on that one.) > >> > >> > >Thanks John, > > > >Unfortunately this patch does *not* cure the issue for my old > >Supermicro P3TDDE, it still hangs just before presenting the menu. I > >had to boot off the livefs and copy /boot/loader.old -> /boot/loader > >to get back to being bootable again - but at least the old fella is on > >a more up-to-date 7-STABLE now :-) > > Given that the patch *did* cure Peters Tyan S2720, I'll double check I > didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - > same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, > whereas the P3TDDE has Award BIOS). > > Anyway, I'll double check and report back... > > Cheers > > Mark I did 18 boots with and with out John's patch. With the patch I got 6 actual boots and 12 hangs in the loaders progress bar. Without the patch I got 10 boots and 8 hangs. But, my Tyan M/B is old and with known ACPI issues so I'm not sure if this is of much value. Mark, it would be nice if you also observe if a sequence of reboots eventually boots your system. My longest bad streek was 8 reboots. - Peter From markir at paradise.net.nz Mon May 26 01:49:12 2008 From: markir at paradise.net.nz (Mark Kirkwood) Date: Mon May 26 01:49:22 2008 Subject: BTX loader hangs after version info In-Reply-To: <20080525171632.GA1305@peter.osted.lan> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> <20080525171632.GA1305@peter.osted.lan> Message-ID: <483A170E.3090204@paradise.net.nz> Peter Holm wrote: > On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > >> I wrote: >> >>> John Baldwin wrote: >>> >>>> Try this patch. I'm not 100% certain this will fix it as I can't >>>> reproduce >>>> the issue, but I think it might help. Specifically, when the boot >>>> code makes >>>> a v86 call, the loader/boot2/whatever swaps in/out a new set of >>>> registers via >>>> the v86 structure including the eflags register. However, none of >>>> the boot >>>> programs actually initialized the v86 structure. Thus, the BIOS >>>> routines >>>> would start off running with whatever garbage was in v86.efl when >>>> each boot >>>> program started. This meant that we could end up invoking BIOS >>>> routines with >>>> interrupts disabled, and I think this might explain a hard hang (if a >>>> BIOS >>>> routine was waiting for an interrupt the interrupt would never >>>> fire). The >>>> patch fixes all the boot programs to initialize v86 to a better known >>>> state. At the least it sets v86.efl to a sane value (0x202) rather >>>> than random. (The >>>> random might have always been 0x0 BTW, not sure on that one.) >>>> >>>> >>>> >>> Thanks John, >>> >>> Unfortunately this patch does *not* cure the issue for my old >>> Supermicro P3TDDE, it still hangs just before presenting the menu. I >>> had to boot off the livefs and copy /boot/loader.old -> /boot/loader >>> to get back to being bootable again - but at least the old fella is on >>> a more up-to-date 7-STABLE now :-) >>> >> Given that the patch *did* cure Peters Tyan S2720, I'll double check I >> didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - >> same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, >> whereas the P3TDDE has Award BIOS). >> >> Anyway, I'll double check and report back... >> >> Cheers >> >> Mark >> > > I did 18 boots with and with out John's patch. With the patch I got 6 > actual boots and 12 hangs in the loaders progress bar. > > Without the patch I got 10 boots and 8 hangs. > > But, my Tyan M/B is old and with known ACPI issues so I'm not sure if > this is of much value. > > Mark, it would be nice if you also observe if a sequence of reboots > eventually boots your system. My longest bad streek was 8 reboots. > > Ok, will do. Incidentally, checking showed that the patch *was* correctly applied. I'll report back in several reboots :-) Mark From markir at paradise.net.nz Mon May 26 02:23:35 2008 From: markir at paradise.net.nz (Mark Kirkwood) Date: Mon May 26 02:23:40 2008 Subject: BTX loader hangs after version info In-Reply-To: <20080525171632.GA1305@peter.osted.lan> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> <20080525171632.GA1305@peter.osted.lan> Message-ID: <483A1F0F.1060502@paradise.net.nz> Peter Holm wrote: > On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > >> I wrote: >> >>> John Baldwin wrote: >>> >>>> Try this patch. I'm not 100% certain this will fix it as I can't >>>> reproduce >>>> the issue, but I think it might help. Specifically, when the boot >>>> code makes >>>> a v86 call, the loader/boot2/whatever swaps in/out a new set of >>>> registers via >>>> the v86 structure including the eflags register. However, none of >>>> the boot >>>> programs actually initialized the v86 structure. Thus, the BIOS >>>> routines >>>> would start off running with whatever garbage was in v86.efl when >>>> each boot >>>> program started. This meant that we could end up invoking BIOS >>>> routines with >>>> interrupts disabled, and I think this might explain a hard hang (if a >>>> BIOS >>>> routine was waiting for an interrupt the interrupt would never >>>> fire). The >>>> patch fixes all the boot programs to initialize v86 to a better known >>>> state. At the least it sets v86.efl to a sane value (0x202) rather >>>> than random. (The >>>> random might have always been 0x0 BTW, not sure on that one.) >>>> >>>> >>>> >>> Thanks John, >>> >>> Unfortunately this patch does *not* cure the issue for my old >>> Supermicro P3TDDE, it still hangs just before presenting the menu. I >>> had to boot off the livefs and copy /boot/loader.old -> /boot/loader >>> to get back to being bootable again - but at least the old fella is on >>> a more up-to-date 7-STABLE now :-) >>> >> Given that the patch *did* cure Peters Tyan S2720, I'll double check I >> didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - >> same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, >> whereas the P3TDDE has Award BIOS). >> >> Anyway, I'll double check and report back... >> >> Cheers >> >> Mark >> > > I did 18 boots with and with out John's patch. With the patch I got 6 > actual boots and 12 hangs in the loaders progress bar. > > Without the patch I got 10 boots and 8 hangs. > > But, my Tyan M/B is old and with known ACPI issues so I'm not sure if > this is of much value. > > Mark, it would be nice if you also observe if a sequence of reboots > eventually boots your system. My longest bad streek was 8 reboots. > > Yeah, I see the same thing - with John's patch applied, out of 9 reboots I got 7 hangs and 2 actual boots. (didn't try without the patch). Mark From unixmania at gmail.com Mon May 26 02:52:08 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Mon May 26 02:52:12 2008 Subject: Why does sysinstall still limits cylinders to 65535? Message-ID: Hello, I have been struglling with sysinstall, attempting to make it handle the geometry of some large SATA drives. After a lot of effort I decided to stop suffering and modified the program in order to circumvent the outdated limit of 65535 cylinders (see attached patch). I'm thinking about submitting a PR with a change request but I'd like to get some additional opinions first. I did not test it in "batch" mode, so it would be great if any kind soul did this. Thanks in advance for your comments and/or suggestions. -- Carlos A. M. dos Santos -------------- next part -------------- A non-text attachment was scrubbed... Name: sysinstall-64kcyl.diff Type: application/octet-stream Size: 5107 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080526/9c14d7c3/sysinstall-64kcyl.obj From peter at holm.cc Mon May 26 05:27:32 2008 From: peter at holm.cc (Peter Holm) Date: Mon May 26 05:27:35 2008 Subject: BTX loader hangs after version info In-Reply-To: <483A1F0F.1060502@paradise.net.nz> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> <20080525171632.GA1305@peter.osted.lan> <483A1F0F.1060502@paradise.net.nz> Message-ID: <20080526052729.GA25171@peter.osted.lan> On Mon, May 26, 2008 at 02:23:11PM +1200, Mark Kirkwood wrote: > Peter Holm wrote: > >On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > > > >>I wrote: > >> > >>>John Baldwin wrote: > >>> > >>>>Try this patch. I'm not 100% certain this will fix it as I can't > >>>>reproduce > >>>>the issue, but I think it might help. Specifically, when the boot > >>>>code makes > >>>>a v86 call, the loader/boot2/whatever swaps in/out a new set of > >>>>registers via > >>>>the v86 structure including the eflags register. However, none of > >>>>the boot > >>>>programs actually initialized the v86 structure. Thus, the BIOS > >>>>routines > >>>>would start off running with whatever garbage was in v86.efl when > >>>>each boot > >>>>program started. This meant that we could end up invoking BIOS > >>>>routines with > >>>>interrupts disabled, and I think this might explain a hard hang (if a > >>>>BIOS > >>>>routine was waiting for an interrupt the interrupt would never > >>>>fire). The > >>>>patch fixes all the boot programs to initialize v86 to a better known > >>>>state. At the least it sets v86.efl to a sane value (0x202) rather > >>>>than random. (The > >>>>random might have always been 0x0 BTW, not sure on that one.) > >>>> > >>>> > >>>> > >>>Thanks John, > >>> > >>>Unfortunately this patch does *not* cure the issue for my old > >>>Supermicro P3TDDE, it still hangs just before presenting the menu. I > >>>had to boot off the livefs and copy /boot/loader.old -> /boot/loader > >>>to get back to being bootable again - but at least the old fella is on > >>>a more up-to-date 7-STABLE now :-) > >>> > >>Given that the patch *did* cure Peters Tyan S2720, I'll double check I > >>didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - > >>same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, > >>whereas the P3TDDE has Award BIOS). > >> > >>Anyway, I'll double check and report back... > >> > >>Cheers > >> > >>Mark > >> > > > >I did 18 boots with and with out John's patch. With the patch I got 6 > >actual boots and 12 hangs in the loaders progress bar. > > > >Without the patch I got 10 boots and 8 hangs. > > > >But, my Tyan M/B is old and with known ACPI issues so I'm not sure if > >this is of much value. > > > >Mark, it would be nice if you also observe if a sequence of reboots > >eventually boots your system. My longest bad streek was 8 reboots. > > > > > > Yeah, I see the same thing - with John's patch applied, out of 9 reboots > I got 7 hangs and 2 actual boots. (didn't try without the patch). > > Mark OK, that is at least nice with consistency across different HW. -- Peter From koitsu at FreeBSD.org Mon May 26 06:24:18 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon May 26 06:24:21 2008 Subject: Why does sysinstall still limits cylinders to 65535? In-Reply-To: References: Message-ID: <20080526062417.GA61084@eos.sc1.parodius.com> On Sun, May 25, 2008 at 11:52:06PM -0300, Carlos A. M. dos Santos wrote: > I have been struglling with sysinstall, attempting to make it handle > the geometry of some large SATA drives. After a lot of effort I > decided to stop suffering and modified the program in order to > circumvent the outdated limit of 65535 cylinders (see attached patch). > I'm thinking about submitting a PR with a change request but I'd like > to get some additional opinions first. I did not test it in "batch" > mode, so it would be great if any kind soul did this. Carlos, bottom line is to simply ignore the geometry warning you see. For others... This is just added evidence that the humongous warning spit out during sysinstall's fdisk is confusing users (many taking it very seriously when there's really no problem at all). I think this is the third time someone's brought this up in the past couple months... -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From krassi at bulinfo.net Mon May 26 17:14:45 2008 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Mon May 26 17:14:50 2008 Subject: shmat() return values? Message-ID: <483AEFFE.8080302@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, When I try: if ((*shm = shmat(shmid, NULL, 0)) == -1) The gcc complains with: warning: comparison between pointer and integer shmat() is declared in shm.h as: void *shmat(int, const void *, int); but 'man 4 shmat; RETURN VALUES Upon success, shmat() returns the address where the segment is attached; otherwise, -1 is returned and errno is set to indicate the error. What is the correct return value on failure, -1 or NULL? I think it should be NULL? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFIOu/+xJBWvpalMpkRAjZUAJ9UWQhOaUw/xtoNTfMydiudWv7apwCaAomp gJhTr9Iwh0jalQL+r8KwKdY= =m30h -----END PGP SIGNATURE----- From jille at quis.cx Mon May 26 20:56:10 2008 From: jille at quis.cx (Jille Timmermans) Date: Mon May 26 20:56:13 2008 Subject: ath network (wifi) driver (Fujitsu Siemens Amilo Pro V3515 laptop) Message-ID: <483B23D8.6010606@quis.cx> Hello Sam, I've got a Fujitsu Siemens Amilo Pro V3515 laptop, with a builtin autheros-wifi card, but I can't get it working. I am running FreeBSD 7.0-STABLE, I don't know whether it works in -CURRENT. Over here I have the dmesg: http://junk.quis.cx/VNViVksv/blackbox.dmesg.txt I haven't compiled it in, it didn't boot that way (kernel panic iirc). When I kldload if_ath I get this: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 3 device_attach: ath0 attach returned 6 # pciconf -l | grep ath ath0@pci0:5:1:0: class=0x020000 card=0x2052168c chip=0x001a168c rev=0x01 hdr=0x00 Full pciconf: http://junk.quis.cx/unvZDYnA/blackbox.pciconf.txt Could you please help me out ? Do you want more info ? -- Jille From marcolz at stack.nl Tue May 27 08:02:18 2008 From: marcolz at stack.nl (Marc Olzheim) Date: Tue May 27 08:02:23 2008 Subject: shmat() return values? In-Reply-To: <483AEFFE.8080302@bulinfo.net> References: <483AEFFE.8080302@bulinfo.net> Message-ID: <20080527074518.GA2593@zlo.nu> On Mon, May 26, 2008 at 08:14:38PM +0300, Krassimir Slavchev wrote: > Hello, > > When I try: > > if ((*shm = shmat(shmid, NULL, 0)) == -1) > > The gcc complains with: > warning: comparison between pointer and integer > > shmat() is declared in shm.h as: > void *shmat(int, const void *, int); > > but 'man 4 shmat; > > RETURN VALUES > Upon success, shmat() returns the address where the segment is > attached; > otherwise, -1 is returned and errno is set to indicate the error. > > > What is the correct return value on failure, -1 or NULL? > I think it should be NULL? The return value is a void pointer, with value equivalent to -1, so (void *)-1 So you can replace it with: if ((*shm = shmat(shmid, NULL, 0)) == (void*)-1) Marc From olli at lurza.secnetix.de Tue May 27 12:19:10 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue May 27 12:19:13 2008 Subject: sched_ule performance on single CPU In-Reply-To: <555870.1659.qm@web57010.mail.re3.yahoo.com> Message-ID: <200805271219.m4RCJ7Q6038124@lurza.secnetix.de> Unga wrote: > When open an pdf has two types of scenarios in > FreeBSD: > 1. When X run as a realtime-prio process, X go mad and > swallow up almost all of CPU cycles, making audio > hiccups. That's expected. Running the X server with rtprio is not a good idea. There's no reason to do that. > 2. When X run as a normal-prio process, X behaves well > and rarely gets an audible hiccup. That's good. :-) > Why X behave different under different priority > categories? Isn't this scheduler related? Very simple: Sometimes the X server consumes lots of CPU for a short time. If it runs with rtprio, then no other process gets a chance to execute, so your audio program will starve. My recommendation is to not use rtprio or renice. I think many people who try to use them are making things worse. (In fact I think rtprio and idprio should die.) > I wonder the issue I mentioned, open a pdf while > playback audio, is it a issue on Apple Mac OSX? Could > somebody give some light here who uses an Apple Mac > OSX on this list? OSX has a vastly different kernel, scheduler, I/O system, audio drivers and so on. It's a completely different animal. Have you tried increasing the audio driver's buffersize? It probably helps to alleviate your problem. I think OSX sizes the buffer dynamically (not sure though). 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 "When your hammer is C++, everything begins to look like a thumb." -- Steve Haflich, in comp.lang.c++ From gerrit at pmp.uni-hannover.de Tue May 27 15:23:47 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Tue May 27 15:23:52 2008 Subject: broken re(4) Message-ID: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> Hi folks, I have four identical ITX boards from Jetway here, each having two re(4) onboard nics: re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet re1@pci0:0:11:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet atapci0@pci0:0:15:0: class=0x01018f card=0x31491106 chip=0x31491106 rev=0x80 I run FreeBSD 7-stable from early March 08 on three of these machines and noticed no problems with networking with that so far. Some days ago I installed a fourth machine with 7-stable from early May (and some days later -because of the problems described below- to May 17th). With this new machine I see several networking problems. The most prominent are these two: - heavy networking traffic (in this case backup via tar & NFS) causes hangs for about 10s-30s and sometimes also leads to watchdog timeouts: May 27 09:04:07 protoserve kernel: re0: watchdog timeout May 27 09:04:07 protoserve kernel: re0: link state changed to DOWN May 27 09:04:10 protoserve kernel: re0: link state changed to UP - copying large files (more than some 100MB) via ssh/scp drops the connection due to "corrupted MAC on input": Disconnecting: Corrupted MAC on input. lost connection In the latter case the networking traffic should actually not be that high, because these are nanobsd systems which are transferring a new image file (system update, 2GB) via ssh (so the bottleneck should be the write speed of the CF card used to hold the system). I do not see these problems with the old codebase from March 08 on my old machines. The cvs shows a large MFC for the re-driver in April, so I guessed something came in there which broke things here. Therefore I downgraded the new system to a cvs codebase from March 1st, but the problems persist. They also exist on both interfaces. memtest86 is running for hours now without finding something wrong. Any hints what I should do next to find the culprit? cu Gerrit From mike at jellydonut.org Tue May 27 15:45:21 2008 From: mike at jellydonut.org (Michael Proto) Date: Tue May 27 15:45:26 2008 Subject: broken re(4) In-Reply-To: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> Message-ID: <483C2C8F.7070909@jellydonut.org> Gerrit K?hn wrote: > Hi folks, > > I have four identical ITX boards from Jetway here, each having two re(4) > onboard nics: > > re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 > hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > class = network > subclass = ethernet > re1@pci0:0:11:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec > rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > class = network > subclass = ethernet > atapci0@pci0:0:15:0: class=0x01018f card=0x31491106 chip=0x31491106 > rev=0x80 > > > I run FreeBSD 7-stable from early March 08 on three of these > machines and noticed no problems with networking with that so far. > Some days ago I installed a fourth machine with 7-stable from early May > (and some days later -because of the problems described below- to May > 17th). With this new machine I see several networking problems. The most > prominent are these two: > > - heavy networking traffic (in this case backup via tar & NFS) causes hangs > for about 10s-30s and sometimes also leads to watchdog timeouts: > May 27 09:04:07 protoserve kernel: re0: watchdog timeout > May 27 09:04:07 protoserve kernel: re0: link state changed to DOWN > May 27 09:04:10 protoserve kernel: re0: link state changed to UP > > - copying large files (more than some 100MB) via ssh/scp drops the > connection due to "corrupted MAC on input": > Disconnecting: Corrupted MAC on input. > lost connection > > In the latter case the networking traffic should actually not be that > high, because these are nanobsd systems which are transferring a new image > file (system update, 2GB) via ssh (so the bottleneck should be the write > speed of the CF card used to hold the system). > > > I do not see these problems with the old codebase from March 08 on my old > machines. The cvs shows a large MFC for the re-driver in April, so I > guessed something came in there which broke things here. Therefore I > downgraded the new system to a cvs codebase from March 1st, but the > problems persist. They also exist on both interfaces. memtest86 is running > for hours now without finding something wrong. > > Any hints what I should do next to find the culprit? > I'm running 6.3 on the exact same Jetway board at home, and while I haven't been bitten by the DOWN/UP issue I have seen the occasional "corrupted MAC on input" error when doing an ssh/scp. Seems to have simmered-down since moving from 6.3-RELEASE to 6.3-STABLE (last supped/rebuilt on 5/6/08). Note this is using only one of the 2 on-board NICs. I disabled the 2nd one in the BIOS as I don't need it at the moment. -Proto From david.buxton at zen.co.uk Tue May 27 22:15:41 2008 From: david.buxton at zen.co.uk (David Buxton) Date: Tue May 27 22:16:02 2008 Subject: SCSI bus reset with Adaptec 29320ALP and Eonstor RAID Message-ID: Hello, I am trying to use a 1.5TB Eonstor raid array with FreeBSD 7.0, but I don't understand whether it is the raid or the scsi card or something else that is causing the computer problems when accessing the raid. My problem is that soon after recognizing the attached disk during boot, FreeBSD appears to hang for about 10 seconds and then says ahd0: Recovery Initiated - Card was not paused followed by a great detail of SCSI status information. Eventually it says (da1:ahd0:0:0:0): SCB 255 - timed out (da1:ahd0:0:0:0): no longer in timeout, status = 24b ahd0: Issued Channel A Bus Reset. 1 SCBs aborted (da1:ahd0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:ahd0:0:0:0): CAM Status: SCSI Status Error (da1:ahd0:0:0:0): SCSI Status: Check Condition (da1:ahd0:0:0:0): UNIT ATTENTION asc:29,0 (da1:ahd0:0:0:0): Power on, reset, or bus device reset occurred (da1:ahd0:0:0:0): Retrying Command (per Sense Data) and then finishes booting as normal. Trying to use the disk after boot makes this happen again. Attached is my dmesg. Would someone tell me if the problem is with my computer? Or likely to be with the Adaptec SCSI card? Or should I suspect the Eonstor drive? Unfortunately I don't have a replacement SCSI card to test with nor a replacement Eonstor. Thanks for any suggestions, David B. FreeBSD 7.0-RELEASE for amd64 Computer is IBM xSeries 336 with 2 GB RAM and 2 x dual core Xeon @ 3.2 GHz. Boot device is a hardware mirror attached to the internal LSILogic raid card. External raid array is Eonstore A08U-1410 U320 LVD SCSI with 8 disks configured as a single 1.6 terabyte RAID-5 disk. RAID controller is Adaptec 29320ALP card with no other devices attached. -------------- next part -------------- Copyright (c) 1992-2008 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 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x641d AMD Features=0x20000800 Logical CPUs per core: 2 usable memory = 2134503424 (2035 MB) avail memory = 2059800576 (1964 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: 6 cpu3 (AP): APIC ID: 7 ioapic2 irqs 48-71 on motherboard ioapic1 irqs 24-47 on motherboard ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 cpu2: on acpi0 p4tcc2: on cpu2 cpu3: on acpi0 p4tcc3: on cpu3 pcib0: on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 2.0 on pci0 pci2: on pcib1 pcib2: at device 4.0 on pci0 pci3: on pcib2 pcib3: at device 0.0 on pci3 pci4: on pcib3 mpt0: port 0x4000-0x40ff mem 0xdeff0000-0xdeffffff,0xdefe0000-0xdefeffff irq 28 at device 1.0 on pci4 mpt0: [ITHREAD] mpt0: MPI Version=1.2.15.0 mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (6 Max) ahd0: port 0x4100-0x41ff,0x4200-0x42ff mem 0xdefde000-0xdefdffff irq 24 at device 2.0 on pci4 ahd0: [ITHREAD] aic7901: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs pcib4: at device 0.2 on pci3 pci5: on pcib4 pcib5: at device 6.0 on pci0 pci6: on pcib5 bge0: mem 0xdcff0000-0xdcffffff irq 16 at device 0.0 on pci6 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:11:25:a8:85:42 bge0: [ITHREAD] pcib6: at device 7.0 on pci0 pci7: on pcib6 bge1: mem 0xdaff0000-0xdaffffff irq 16 at device 0.0 on pci7 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:11:25:a8:85:43 bge1: [ITHREAD] pci0: at device 8.0 (no driver attached) uhci0: port 0x2200-0x221f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2600-0x261f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xf9000000-0xf90003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pcib7: at device 30.0 on pci0 pci1: on pcib7 vgapci0: port 0x3000-0x30ff mem 0xf0000000-0xf7ffffff,0xf8000000-0xf800ffff irq 16 at device 1.0 on pci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x480-0x48f at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD