Re: Panic 9 .1-PRERELEASE on HP Servers
On Sun, 2012-08-12 at 15:40 -0700, Garrett Cooper wrote: > On Aug 12, 2012, at 1:53 PM, Dennis Glatting wrote: > > > On Sun, 2012-08-12 at 13:37 -0700, Garrett Cooper wrote: > >> On Sun, Aug 12, 2012 at 1:29 PM, Dennis Glatting wrote: > >>> Looks like my screen shot was stripped. You can find it here: > >>> > >>> http://www.pki2.com/hp.JPG > >>> > >>> > >>> Also: > >>> > >>> Granny> cc -v > >>> Using built-in specs. > >>> Target: amd64-undermydesk-freebsd > >>> Configured with: FreeBSD/amd64 system compiler > >>> Thread model: posix > >>> gcc version 4.2.1 20070831 patched [FreeBSD] > >> > >>What was the actual panic message/assert that was hit? > >> Thanks, > > > > > > The iLO scroll back is very limited (the machine is also 1,200 miles > > away so a serial interface isn't possible). This new, second snap shot > > (http://www.pki2.com/hp2.JPG) I scrolled back as far as I can. > > Still can't see the exact cause :/; show msgbuf should help identify > what the exact panic string was. http://www.pki2.com/bpbt2.JPG I removed the ipmi driver and rebooted the machine five times without further problem. I won't be able to test the second machine until later in the week. > -Garrett > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1-RC1 Available...
On Thu, 2012-08-23 at 09:47 -0400, Ken Smith wrote: > On Thu, 2012-08-23 at 23:12 +1000, Ian Smith wrote: > > On Thu, 23 Aug 2012 00:50:46 -0400, Ken Smith wrote: > > > > > With both the doc and ports repositories now moved to SVN it has been > > > decided to not export the 9.1 release branch activity to CVS. So > > > csup/cvsup update mechanisms are not available for updating to 9.1-RC1. > > > If you would like to use SVN the branch to use is releng/9.1. > > > > Assuming the stupid question is the one you didn't ask, just to clarify: > > does this mean that c*sup won't work with these RCs in particular, or > > that CVS is dead and SVN becomes mandatory from 9.1-RELEASE? > > > > cheers, Ian > > > > The latter. If you are not using FreeBSD-Update to handle the updates > of a machine you'll need to update your source tree using SVN for > release branches (releng/*) from now on. Updates of the CVS repository > will continue for the existing stable/* and head for now. I don't think > anything has been decided on when that will stop. > Looking in the handbook ([1]) I do not see the mechanics of how to set up a mirror, of which I have three CVS mirrors in different infrastructures. Is there a web page somewhere on how to set up, synchronize, maintain, and use a local mirror? [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1-RC1 Available...
On Thu, 23 Aug 2012, Trond Endrest?l wrote: On Thu, 23 Aug 2012 07:25-0700, Dennis Glatting wrote: On Thu, 2012-08-23 at 09:47 -0400, Ken Smith wrote: On Thu, 2012-08-23 at 23:12 +1000, Ian Smith wrote: On Thu, 23 Aug 2012 00:50:46 -0400, Ken Smith wrote: > With both the doc and ports repositories now moved to SVN it has been > decided to not export the 9.1 release branch activity to CVS. So > csup/cvsup update mechanisms are not available for updating to 9.1-RC1. > If you would like to use SVN the branch to use is releng/9.1. Assuming the stupid question is the one you didn't ask, just to clarify: does this mean that c*sup won't work with these RCs in particular, or that CVS is dead and SVN becomes mandatory from 9.1-RELEASE? cheers, Ian The latter. If you are not using FreeBSD-Update to handle the updates of a machine you'll need to update your source tree using SVN for release branches (releng/*) from now on. Updates of the CVS repository will continue for the existing stable/* and head for now. I don't think anything has been decided on when that will stop. Looking in the handbook ([1]) I do not see the mechanics of how to set up a mirror, of which I have three CVS mirrors in different infrastructures. Is there a web page somewhere on how to set up, synchronize, maintain, and use a local mirror? [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html How about this one? http://motoyuki.bsdclub.org/BSD/cvsup.html I have CVS mirrors. The topic is SVN. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1-RC1 Available...
On Thu, 23 Aug 2012, Ken Menzel wrote: On 8/23/2012 9:47 AM, Ken Smith wrote: On Thu, 2012-08-23 at 23:12 +1000, Ian Smith wrote: On Thu, 23 Aug 2012 00:50:46 -0400, Ken Smith wrote: > With both the doc and ports repositories now moved to SVN it has been > decided to not export the 9.1 release branch activity to CVS. So > csup/cvsup update mechanisms are not available for updating to 9.1-RC1. > If you would like to use SVN the branch to use is releng/9.1. Assuming the stupid question is the one you didn't ask, just to clarify: does this mean that c*sup won't work with these RCs in particular, or that CVS is dead and SVN becomes mandatory from 9.1-RELEASE? cheers, Ian The latter. If you are not using FreeBSD-Update to handle the updates of a machine you'll need to update your source tree using SVN for release branches (releng/*) from now on. Updates of the CVS repository will continue for the existing stable/* and head for now. I don't think anything has been decided on when that will stop. I missed this announcement as well. Should we all use the primary URL or is there a list of mirrors? Is anyone going to be updating the Handbook to reflect this? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html However I can see this does not even reflect the more recent use of csup instead of cvsup. I found two good primers: http://mebsd.com/configure-freebsd-servers/update-freebsd-source-tree-using-subversion-svn.html http://www.freebsd.org/doc/en/articles/committers-guide/article.html#SUBVERSION-PRIMER The second primer in the committer handbook seems to indicate that it is difficult to run an SVN mirror. This appears to me to be the biggest drawback. I have been using CVS and perforce for years, but subversion is new to me. Thanks. I have several cases where I cannot have machines going to the Internet to update for various reasons, including WAN loading and policies, but I can have them hit local mirrors. I have three sites: #1, Static with less than ten servers. Strong maintenance policies. #2, Mostly static with twenty servers, virtual instances, laptops, and sticks. Loose maintenance policies #3, Largely dynamic but three servers and instances are static. Regulated environment with associated maintenance policies. If CVS is fading then I need to move my CVS mirrors to SVN mirrors. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1-RC1 Available...
On Fri, 2012-08-24 at 23:07 -0400, Jim Pingle wrote: > On 8/23/2012 11:43 AM, Ian Lepore wrote: > > On Thu, 2012-08-23 at 11:17 -0400, Ken Menzel wrote: > >> > >> I found two good primers: > >> http://mebsd.com/configure-freebsd-servers/update-freebsd-source-tree-using-subversion-svn.html > >> http://www.freebsd.org/doc/en/articles/committers-guide/article.html#SUBVERSION-PRIMER > >> > >> The second primer in the committer handbook seems to indicate that it > >> is difficult to run an SVN mirror. This appears to me to be the > >> biggest drawback. I have been using CVS and perforce for years, but > >> subversion is new to me. > > > > It may be difficult to run an svn mirror that allows you to commit > > locally and get those changes back to the project, but running a > > read-only mirror is trivial. The script I run nightly from cron to sync > > my local mirror is: > > > > #!/bin/sh > > # > > # svnsync to pull in changes from FreeBSD to my local mirror. > > # > > svnsync sync file:///local/vc/svn/base > > > > I can't remember how I initially created and populated the mirror, but > > it's likely I grabbed a snapshot of the mirror at work and brought it > > home on a thumb drive (just to avoid initial network DL time). > > I spent a little time today setting up an SVN mirror after reading this > thread and wrote up a how-to for those looking to do the same. > > http://www.pingle.org/2012/08/24/freebsd-svn-mirror > > Comments/Flames/Corrections welcome... > There are two things that I am confused about "base." 1) What, exactly, is base? When I do a co, what tree branch is that? 2) Base /appears/ not to contain releng/9.1 or stable/8. How do I mirror those? > Jim > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1-RC1 Available...
On Sat, 2012-08-25 at 04:42 -0700, David Wolfskill wrote: > On Fri, Aug 24, 2012 at 10:19:36PM -0700, Dennis Glatting wrote: > > ... > > There are two things that I am confused about "base." > > > > 1) What, exactly, is base? When I do a co, what tree branch is that? > > Using CVS, failure to specify a tag would get you HEAD. > > Using SVN, failure to specify a branch will get you head. > > This may help. As noted previously, I have a local private mirror of > the FreeBSD SVN src repository located in /svn/freebsd/src/base; so: > > g1-227(9.1-P)[1] svn ls file:///svn/freebsd/src/base > ROADMAP.txt > cvs2svn/ > head/ > projects/ > release/ > releng/ > stable/ > svnadmin/ > user/ > vendor/ > vendor-crypto/ > vendor-sys/ > g1-227(9.1-P)[2] svn ls file:///svn/freebsd/src/base/releng > 2.0.5/ > 4.10/ > 4.11/ > 4.3/ > 4.4/ > 4.5/ > 4.6/ > 4.7/ > 4.8/ > 4.9/ > 5.0/ > 5.1/ > 5.2/ > 5.3/ > 5.4/ > 5.5/ > 6.0/ > 6.1/ > 6.2/ > 6.3/ > 6.4/ > 7.0/ > 7.1/ > 7.2/ > 7.3/ > 7.4/ > 8.0/ > 8.1/ > 8.2/ > 8.3/ > 9.0/ > 9.1/ > ALPHA_2_0/ > BETA_2_0/ > g1-227(9.1-P)[3] svn ls file:///svn/freebsd/src/base/stable > 2.0.5/ > 2.1/ > 2.2/ > 3/ > 4/ > 5/ > 6/ > 7/ > 8/ > 9/ > g1-227(9.1-P)[4] svn ls file:///svn/freebsd/src/base/head > COPYRIGHT > LOCKS > MAINTAINERS > Makefile > Makefile.inc1 > ObsoleteFiles.inc > README > UPDATING > bin/ > cddl/ > contrib/ > crypto/ > etc/ > games/ > gnu/ > include/ > kerberos5/ > lib/ > libexec/ > release/ > rescue/ > sbin/ > secure/ > share/ > sys/ > tools/ > usr.bin/ > usr.sbin/ > g1-227(9.1-P)[5] > > > Does that help? > > > 2) Base /appears/ not to contain releng/9.1 or stable/8. How do I mirror > > those? > > As shown above, they are there. > Thanks for the clue. > Peace, > david ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS "stalls" -- and maybe we should be talking about defaults?
I get stalls with 256GB of RAM with arc_max=64G (my limit is usually 25% ) on a 64 core system with 20 new 3TB Seagate disks under LSI2008 chips without much load. Interestingly pbzip2 consistently created a problem on a volume whereas gzip does not. Here, stalls happen across several systems however I have had less problems under 8.3 than 9.1. If I go to hardware RAID5 (LSI2008 -- same chips: IR vs IT) I don't have a problem. On Mon, 2013-03-04 at 16:48 -0600, Karl Denninger wrote: > Well now this is interesting. > > I have converted a significant number of filesystems to ZFS over the > last week or so and have noted a few things. A couple of them aren't so > good. > > The subject machine in question has 12GB of RAM and dual Xeon > 5500-series processors. It also has an ARECA 1680ix in it with 2GB of > local cache and the BBU for it. The ZFS spindles are all exported as > JBOD drives. I set up four disks under GPT, have a single freebsd-zfs > partition added to them, are labeled and the providers are then > geli-encrypted and added to the pool. When the same disks were running > on UFS filesystems they were set up as a 0+1 RAID array under the ARECA > adapter, exported as a single unit, GPT labeled as a single pack and > then gpart-sliced and newfs'd under UFS+SU. > > Since I previously ran UFS filesystems on this config I know what the > performance level I achieved with that, and the entire system had been > running flawlessly set up that way for the last couple of years. > Presently the machine is running 9.1-Stable, r244942M > > Immediately after the conversion I set up a second pool to play with > backup strategies to a single drive and ran into a problem. The disk I > used for that testing is one that previously was in the rotation and is > also known good. I began to get EXTENDED stalls with zero I/O going on, > some lasting for 30 seconds or so. The system was not frozen but > anything that touched I/O would lock until it cleared. Dedup is off, > incidentally. > > My first thought was that I had a bad drive, cable or other physical > problem. However, searching for that proved fruitless -- there was > nothing being logged anywhere -- not in the SMART data, not by the > adapter, not by the OS. Nothing. Sticking a digital storage scope on > the +5V and +12V rails didn't disclose anything interesting with the > power in the chassis; it's stable. Further, swapping the only disk that > had changed (the new backup volume) with a different one didn't change > behavior either. > > The last straw was when I was able to reproduce the stalls WITHIN the > original pool against the same four disks that had been running > flawlessly for two years under UFS, and still couldn't find any evidence > of a hardware problem (not even ECC-corrected data returns.) All the > disks involved are completely clean -- zero sector reassignments, the > drive-specific log is clean, etc. > > Attempting to cut back the ARECA adapter's aggressiveness (buffering, > etc) on the theory that I was tickling something in its cache management > algorithm that was pissing it off proved fruitless as well, even when I > shut off ALL caching and NCQ options. I also set > vfs.zfs.prefetch_disable=1 to no effect. H... > > Last night after reading the ZFS Tuning wiki for FreeBSD I went on a > lark and limited the ARC cache to 2GB (vfs.zfs.arc_max=20), set > vfs.zfs.write_limit_override to 102400 (1GB) and rebooted. /* > > The problem instantly disappeared and I cannot provoke its return even > with multiple full-bore snapshot and rsync filesystem copies running > while a scrub is being done.*/ > /**/ > I'm pinging between being I/O and processor (geli) limited now in normal > operation and slamming the I/O channel during a scrub. It appears that > performance is roughly equivalent, maybe a bit less, than it was with > UFS+SU -- but it's fairly close. > > The operating theory I have at the moment is that the ARC cache was in > some way getting into a near-deadlock situation with other memory > demands on the system (there IS a Postgres server running on this > hardware although it's a replication server and not taking queries -- > nonetheless it does grab a chunk of RAM) leading to the stalls. > Limiting its grab of RAM appears to have to resolved the contention > issue. I was unable to catch it actually running out of free memory > although it was consistently into the low five-digit free page count and > the kernel never garfed on the console about resource exhaustion -- > other than a bitch about swap stalling (the infamous "more than 20 > seconds" message.) Page space in use near the time in question (I could > not get a display while locked as it went to I/O and froze) was not > zero, but pretty close to it (a few thousand blocks.) That the system > was driven into light paging does appear to be significant and > indicative of some sort of memory contention issue as under operation > with
Re: ZFS "stalls" -- and maybe we should be talking about defaults?
On Mon, 2013-03-04 at 20:58 -0600, Karl Denninger wrote: > Stick this in /boot/loader.conf and see if your lockups goes away: > > vfs.zfs.write_limit_override=102400 > K. > I've got a "sentinal" running that watches for zero-bandwidth zpool > iostat 5s that has been running for close to 12 hours now and with the > two tunables I changed it doesn't appear to be happening any more. > I've also done this as well as top and systat -vmstat. Disk I/O stops but the system lives through top, system, and the network. However, if I try to login the login won't complete. All of my systems are hardware RAID1 for the OS (LSI and Areca) and typically a separate disk for swap. All other disks are ZFS. > This system always has small-ball write I/Os going to it as it's a > postgresql "hot standby" mirror backing a VERY active system and is > receiving streaming logdata from the primary at a colocation site, so > the odds of it ever experiencing an actual zero for I/O (unless there's > a connectivity problem) is pretty remote. > I am doing multi TB sorts and GB database loads. > If it turns out that the write_limit_override tunable is the one > responsible for stopping the hangs I can drop the ARC limit tunable > although I'm not sure I want to; I don't see much if any performance > penalty from leaving it where it is and if the larger cache isn't > helping anything then why use it? I'm inclined to stick an SSD in the > cabinet as a cache drive instead of dedicating RAM to this -- even > though it's not AS fast as RAM it's still MASSIVELY quicker than getting > data off a rotating plate of rust. > I forgot to mention that on my three 8.3 systems they occasionally offline a disk (one or two a week, total). I simply online the disk and after resilver all is well. There are ~40 disks across those three systems. Of my 9.1 systems three are busy but with smaller number of disks (about eight across two volumes (RAIDz2 and mirror). I also have a ZFS-on-Linux (CentOS) system for play (about 12 disks). It did not exhibit problems when it was in use but it did teach me a lesson on the evils of dedup. :) > Am I correct that a ZFS filesystem does NOT use the VM buffer cache at all? > Dunno. > On 3/4/2013 8:07 PM, Dennis Glatting wrote: > > I get stalls with 256GB of RAM with arc_max=64G (my limit is usually 25% > > ) on a 64 core system with 20 new 3TB Seagate disks under LSI2008 chips > > without much load. Interestingly pbzip2 consistently created a problem > > on a volume whereas gzip does not. > > > > Here, stalls happen across several systems however I have had less > > problems under 8.3 than 9.1. If I go to hardware RAID5 (LSI2008 -- same > > chips: IR vs IT) I don't have a problem. > > > > > > > > > > On Mon, 2013-03-04 at 16:48 -0600, Karl Denninger wrote: > >> Well now this is interesting. > >> > >> I have converted a significant number of filesystems to ZFS over the > >> last week or so and have noted a few things. A couple of them aren't so > >> good. > >> > >> The subject machine in question has 12GB of RAM and dual Xeon > >> 5500-series processors. It also has an ARECA 1680ix in it with 2GB of > >> local cache and the BBU for it. The ZFS spindles are all exported as > >> JBOD drives. I set up four disks under GPT, have a single freebsd-zfs > >> partition added to them, are labeled and the providers are then > >> geli-encrypted and added to the pool. When the same disks were running > >> on UFS filesystems they were set up as a 0+1 RAID array under the ARECA > >> adapter, exported as a single unit, GPT labeled as a single pack and > >> then gpart-sliced and newfs'd under UFS+SU. > >> > >> Since I previously ran UFS filesystems on this config I know what the > >> performance level I achieved with that, and the entire system had been > >> running flawlessly set up that way for the last couple of years. > >> Presently the machine is running 9.1-Stable, r244942M > >> > >> Immediately after the conversion I set up a second pool to play with > >> backup strategies to a single drive and ran into a problem. The disk I > >> used for that testing is one that previously was in the rotation and is > >> also known good. I began to get EXTENDED stalls with zero I/O going on, > >> some lasting for 30 seconds or so. The system was not frozen but > >> anything that touched I/O would lock until it cleared. Dedup is off, > >> incidentally. > >> > >> My first thought was that I had a bad drive
Re: ZFS "stalls" -- and maybe we should be talking about defaults?
On Tue, 2013-03-05 at 03:25 +, Steven Hartland wrote: > - Original Message - > From: "Karl Denninger" > > > Stick this in /boot/loader.conf and see if your lockups goes away: > > > > vfs.zfs.write_limit_override=102400 > ... > > > If it turns out that the write_limit_override tunable is the one > > responsible for stopping the hangs I can drop the ARC limit tunable > > although I'm not sure I want to; I don't see much if any performance > > penalty from leaving it where it is and if the larger cache isn't > > helping anything then why use it? I'm inclined to stick an SSD in the > > cabinet as a cache drive instead of dedicating RAM to this -- even > > though it's not AS fast as RAM it's still MASSIVELY quicker than getting > > data off a rotating plate of rust. > > Now interesting you should say that I've seen a stall recently on ZFS > only box running on 6 x SSD RAIDZ2. > > The stall was caused by fairly large mysql import, with nothing else > running. > > Then it happened I thought the machine had wedged, but minutes (not > seconds) later, everything sprung into action again. > I've seen this too. > > Am I correct that a ZFS filesystem does NOT use the VM buffer cache > > at all? > > Correct > > Regards > Steve > > > 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 postmas...@multiplay.co.uk. > > _______ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Dennis Glatting ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Apparent regression in r250359
This patch allows my AMD CURRENT to complete boot without core dumping.
I was also able to recompile/reinstall lang/gcc48 without trouble.
My 9.1 systems are busy but I may be able to give it a try tomorrow.
On Thu, 2013-05-09 at 13:17 -0400, Jim Ohlstein wrote:
> On 05/09/13 12:04, Konstantin Belousov wrote:
> > On Thu, May 09, 2013 at 11:42:28AM -0400, Jim Ohlstein wrote:
> >> On 05/09/13 10:30, Konstantin Belousov wrote:
> >>> On Thu, May 09, 2013 at 10:13:15AM -0400, Jim Ohlstein wrote:
> # sysctl hw.model
> hw.model: AMD FX(tm)-8350 Eight-Core Processor
> >>> Ahh, so it seems that this is a CPU with the LWP.
> >>> Please try the patch at the end of message.
> >>
> >> Same error
> >>
> >>>
> >>> As another workaround, which does not disable AVX support, you
> >>> could try loader tunable hw.xsave_mask=0x7.
> >>
> >> This works
> >
> > Hm, I see another bug in the next line as well. Could you try this
> > updated patch ?
>
> This does work.
>
> >
> > diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c
> > index de79baa..9bc8a2f 100644
> > --- a/sys/amd64/amd64/fpu.c
> > +++ b/sys/amd64/amd64/fpu.c
> > @@ -687,8 +687,8 @@ fpugetregs(struct thread *td)
> > offsetof(struct xstate_hdr, xstate_bv));
> > max_ext_n = flsl(xsave_mask);
> > for (i = 0; i < max_ext_n; i++) {
> > - bit = 1 << i;
> > - if ((*xstate_bv & bit) != 0)
> > + bit = 1ULL << i;
> > + if ((xsave_mask & bit) == 0 || (*xstate_bv & bit) != 0)
> > continue;
> > bcopy((char *)fpu_initialstate +
> > xsave_area_desc[i].offset,
> >
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Apparent regression in r250359
This patch works on one of my 9.1 systems in addition to my CURRENT
system.
On Thu, 9 May 2013, Jim Ohlstein wrote:
On 05/09/13 12:04, Konstantin Belousov wrote:
On Thu, May 09, 2013 at 11:42:28AM -0400, Jim Ohlstein wrote:
On 05/09/13 10:30, Konstantin Belousov wrote:
On Thu, May 09, 2013 at 10:13:15AM -0400, Jim Ohlstein wrote:
# sysctl hw.model
hw.model: AMD FX(tm)-8350 Eight-Core Processor
Ahh, so it seems that this is a CPU with the LWP.
Please try the patch at the end of message.
Same error
As another workaround, which does not disable AVX support, you
could try loader tunable hw.xsave_mask=0x7.
This works
Hm, I see another bug in the next line as well. Could you try this
updated patch ?
This does work.
diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c
index de79baa..9bc8a2f 100644
--- a/sys/amd64/amd64/fpu.c
+++ b/sys/amd64/amd64/fpu.c
@@ -687,8 +687,8 @@ fpugetregs(struct thread *td)
offsetof(struct xstate_hdr, xstate_bv));
max_ext_n = flsl(xsave_mask);
for (i = 0; i < max_ext_n; i++) {
- bit = 1 << i;
- if ((*xstate_bv & bit) != 0)
+ bit = 1ULL << i;
+ if ((xsave_mask & bit) == 0 || (*xstate_bv & bit) !=
0)
continue;
bcopy((char *)fpu_initialstate +
xsave_area_desc[i].offset,
--
Jim Ohlstein
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Compile failure against RELENG_4
On Saturday 03 February 2001 12:51 pm, Kent Stewart wrote: > Dennis Glatting wrote: > > Updated my sources yesterday. There were no changes to the tree > > today. So, I guess this must be a problem. > > Well, I updated my sources last night and didn't have a problem doing > the usual buildworld, buildkernel, installkernel, and installworld. > > What version did you start with? Are you trying to build a release > because I don't have a disk-1 directory. > I feed several local machines from a CVS tree that I keep up to date from cvsup8.freebsd.org. The source in question has checked out against the RELENG_4 tag several times since 4.2. /usr/src is a symlink into /disk-1 on this machine. The last time I built RELENG_4 was January 10, 2001. When I compiler all I say is "make buildworld." > Kent > > > cd /disk-1/src/gnu/lib/libgcc; make depend; make all; make > > install echo '#include '> config.h > > echo '#include ' >> config.h > > echo '#include "gansidecl.h"' > tconfig.h > > echo '#include "i386/xm-i386.h"'>> tconfig.h > > echo '#include "i386/i386.h"' > tm.h > > echo '#include "i386/att.h"'>> tm.h > > echo '#include "svr4.h"'>> tm.h > > echo '#include ' >> tm.h > > echo '#include "i386/freebsd.h"'>> tm.h > > echo '#include "i386/perform.h"'>> tm.h > > rm -f .depend > > mkdep -f .depend -a > > -I/disk-1/src/gnu/lib/libgcc/../../../contrib/gcc/config > > -I/disk-1/src/gnu/lib/libgcc/../../../contrib/gcc -I. -DIN_GCC > > -D_PTHREADS -DGTHREAD_USE_WEAK > > -I/usr/obj/disk-1/src/i386/usr/include > > /disk-1/src/gnu/lib/libgcc/../../../contrib/gcc/frame.c > > mkdep -f .depend -a -nostdinc++ > > -I/disk-1/src/gnu/lib/libgcc/../../../contrib/gcc/cp/inc > > /disk-1/src/gnu/lib/libgcc/../../../contrib/gcc/cp/tinfo.cc > > /disk-1/src/gnu/lib/libgcc/../../../contrib/gcc/cp/tinfo2.cc > > /disk-1/src/gnu/lib/libgcc/../../../contrib/gcc/cp/new.cc > > /disk-1/src/gnu/lib/libgcc/../../../contrib/gcc/cp/exception.cc > > > > /disk-1/src/gnu/lib/libgcc/../../../contrib/gcc/cp/exception.cc:33: > > gansidecl.h: No > > such file or directory > > /disk-1/src/gnu/lib/libgcc/../../../contrib/gcc/cp/exception.cc:34: > > eh-common.h: No > > such file or directory > > mkdep: compile failed > > *** Error code 1 > > > > Stop in /disk-1/src/gnu/lib/libgcc. > > *** Error code 1 > > > > Stop in /disk-1/src. > > *** Error code 1 > > > > Stop in /disk-1/src. > > *** Error code 1 > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: pgm to kill 4.3 via vm
On Sat, 5 May 2001, Alfred Perlstein wrote: > * Dennis Glatting <[EMAIL PROTECTED]> [010505 14:38] wrote: > > > > I wrote a trivial program to fill vm and found I can reliably freeze my > > system. It may not work on the first attempt, but certainly within three. > > My command line is: > > > > a.out&;a.out&;a.out&;a.out&;a.out& > > > > The goal of my program is simply to see how the system behaves under > > memory exhaustion which, as it turns out on two similar systems, the > > systems freeze. Specifically, I can switch between consoles but the login > > prompts do not respond and the system does not respond on the network. > > > > I am running 4.3 on a dual processor system. > > > > Below are some things. First, the program. Second, dmesg. Finally, my > > /etc/rc.config. > > > > LOL > > There's no reason to cc two lists. > > You've obviously not bothered to read manpages on setting up system > limits, please do so. > Why is it expected behaviour for a system to freeze, thus requiring a power cycle, regardless of system limit settings? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: patch: bad ipv6 neighbor solicitation
This patch works for me. On Mon, 14 Dec 2009, Li, Qing wrote: Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with "route add *your parameters*" or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table I did delete the lo0 route before I exected the above command. Also, I haven't been able to specify a higher metric (e.g., -metric 2). That is rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer#
