FreeBSD 9.0
Somebody know when FreeBSD 9.0 Releng will be available? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0
On 09/15/2011 16:42, Alisson wrote: Somebody know when FreeBSD 9.0 Releng will be available? When it is ready? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cvsup broken on amd64?
On 15 September 2011 18:05, Mark Linimon wrote: >> Usually rather quite later than sooner. > > A perfect opportunity for src committers to dive in and make a > difference :-) I hate you. :) Ok. Some third person test/verify that this patch (a) does what it's supposed to do, and (b) is correct, and I'll commit it. (blah, what am I signing myself up for..) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0
Le 15/09/2011 16:42, Alisson a écrit : > Somebody know when FreeBSD 9.0 Releng will be available? > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Please have a look to http://www.freebsd.org/releng/index.html regards Martin MATO -- Ce message a été vérifié par MailScanner pour des virus ou des polluriels et rien de suspect n'a été trouvé. CRI UPVD http://www.univ-perp.fr ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0
On Thu, Sep 15, 2011 at 3:42 PM, Alisson wrote: > Somebody know when FreeBSD 9.0 Releng will be available? http://www.freebsd.org/releases/9.0R/schedule.html Remember that just because a date is in the schedule, doesn't make it a hard date. So I don't know, but sometime soon, when it is ready. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RELENG_8 / mpt / zpool Errors
On Sep 15, 2011 11:36 PM, "Tim Gustafson" wrote: > > > The SAS 2008 chip (SAS 6G) is the one that the FreeBSD mps driver has > > problems with when used with port expanders. It's the older SAS 3G chip > > that works OK with FreeBSD I think. > > I had crossed some wires earlier on in our discussion. > > We do have a SAS 2008 chip in the system already, but it's not the one that's running the external disk boxes (and we are having no problem with those drives). The external disk boxes (the ones that are having the problems) are connect through an LSI SAS 3801E, which is handled by the mpt driver. The mpt driver is what's giving us trouble right now. Can you connect an enclosure to the SAS 2008 chip card you have now and test? I thought I had read about problems like yours with that chip on FreeBSD when using such enclosures. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cvsup broken on amd64?
On Thu, Sep 15, 2011 at 8:19 AM, Adrian Chadd wrote: > On 15 September 2011 18:05, Mark Linimon wrote: >>> Usually rather quite later than sooner. >> >> A perfect opportunity for src committers to dive in and make a >> difference :-) > > I hate you. :) > > Ok. Some third person test/verify that this patch (a) does what it's > supposed to do, and (b) is correct, and I'll commit it. > > (blah, what am I signing myself up for..) Based on the ticket and the patch, I think this is the right procedure for verifying the patch. Please verify that the case below repros the issue seen by the end-user before applying the patch though :). Thanks, -Garrett supdir=$(mktemp -d /tmp/sup.XX) # Supfile follows. Change cvsup host as necessary.. cat >$supdir/supfile < $i done # This should fail, requiring multiple tries. csup $supdir/supfile # Clean up rm -Rf $supdir ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cvsup broken on amd64?
On Thu, Sep 15, 2011 at 9:30 AM, Garrett Cooper wrote: > On Thu, Sep 15, 2011 at 8:19 AM, Adrian Chadd wrote: >> On 15 September 2011 18:05, Mark Linimon wrote: Usually rather quite later than sooner. >>> >>> A perfect opportunity for src committers to dive in and make a >>> difference :-) >> >> I hate you. :) >> >> Ok. Some third person test/verify that this patch (a) does what it's >> supposed to do, and (b) is correct, and I'll commit it. >> >> (blah, what am I signing myself up for..) > > Based on the ticket and the patch, I think this is the right > procedure for verifying the patch. Please verify that the case below > repros the issue seen by the end-user before applying the patch though > :). > Thanks, > -Garrett > > supdir=$(mktemp -d /tmp/sup.XX) > # Supfile follows. Change cvsup host as necessary.. > cat >$supdir/supfile < *default host=cvsup10.FreeBSD.org > *default base=$supdir > *default prefix=$supdir/checkout > *default release=cvs > *default delete use-rel-suffix > *default compress > src-all > EOF > # Get the sources > csup $supdir/supfile > # Empty out the files > for i in $(find $supdir/supfile/sys -name '*.[ch]'); do This should be $supdir/checkout/sys . Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
9.0-BETA2 do not support SpeedStep on E5420
Hi, >From today's -CURRENT: Copyright (c) 1992-2011 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 9.0-BETA2 #17 r225560+be1f8b9: Thu Sep 15 12:05:41 EDT 2011 al@shai-hulud:/data/src/freebsd/obj/master/i386.i386/data/src/freebsd/src/sys/GENERIC i386 CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2493.80-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x40ce3bd AMD Features=0x2010 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 6442450944 (6144 MB) avail memory = 3677458432 (3507 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <100509 APIC1714> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) 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 [...] est0: failed to enable SpeedStep p4tcc0: on cpu0 est1: failed to enable SpeedStep p4tcc1: on cpu1 est2: failed to enable SpeedStep p4tcc2: on cpu2 est3: failed to enable SpeedStep p4tcc3: on cpu3 est4: failed to enable SpeedStep p4tcc4: on cpu4 est5: failed to enable SpeedStep p4tcc5: on cpu5 est6: failed to enable SpeedStep p4tcc6: on cpu6 est7: failed to enable SpeedStep p4tcc7: on cpu7 It feels strange that the latest FreeBSD do not support est(4) on a 3 years old CPU... Thanks, - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0
Am Thu, 15 Sep 2011 11:42:06 -0300 schrieb Alisson : > Somebody know when FreeBSD 9.0 Releng will be available? Judging from the schedule, it's at least a month late. If not two. Unsurprisingly, to me at least. Personally, I don't care. I don't plan with "future" releases anyway, only with the ones available. I assume, one can work reasonably well even with the BETA2 currently out. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
On Thu, Sep 15, 2011 at 5:12 AM, Gary Palmer wrote: > On Wed, Sep 14, 2011 at 03:46:21PM -0700, Kevin Oberman wrote: >> Second, I frequently want custom newfs options, most notably -b, -f, >> and -i. There was no way to do this with sysinstall > > The source appears to disagree with you > > From usr.sbin/sysinstall/label.c > > /* If the user wants a special newfs command for this, set it */ > static void > getNewfsCmd(PartInfo *p) > > I'm pretty sure I've used that option in multiple releases of FBSD. > > If that is missing in the new installer then that is something that needs > fixed. I stand corrected and am baffled by how I missed it. I still want to see the arguments that are to be passed to newfs before I pull the trigger. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
On Thu, Sep 15, 2011 at 10:58 AM, Kevin Oberman wrote: > On Thu, Sep 15, 2011 at 5:12 AM, Gary Palmer wrote: >> On Wed, Sep 14, 2011 at 03:46:21PM -0700, Kevin Oberman wrote: >>> Second, I frequently want custom newfs options, most notably -b, -f, >>> and -i. There was no way to do this with sysinstall >> >> The source appears to disagree with you >> >> From usr.sbin/sysinstall/label.c >> >> /* If the user wants a special newfs command for this, set it */ >> static void >> getNewfsCmd(PartInfo *p) >> >> I'm pretty sure I've used that option in multiple releases of FBSD. >> >> If that is missing in the new installer then that is something that needs >> fixed. > > I stand corrected and am baffled by how I missed it. > > I still want to see the arguments that are to be passed to newfs > before I pull the trigger. That functionality doesn't exist today, unless you want to drop into the shell and set everything up manually.. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0
On Thu, Sep 15, 2011 at 10:38 AM, Rainer Duffner wrote: > Am Thu, 15 Sep 2011 11:42:06 -0300 > schrieb Alisson : > >> Somebody know when FreeBSD 9.0 Releng will be available? > > > Judging from the schedule, it's at least a month late. If not two. > Unsurprisingly, to me at least. > > Personally, I don't care. I don't plan with "future" releases > anyway, only with the ones available. > > I assume, one can work reasonably well even with the BETA2 currently > out. To some degree yes. It's a fairly good sneak peak of what 9.0-RELEASE will contain, plus some performance tweaks that kib@ has committed for jhb@, etc, and other potential minor bugfixes, etc. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
On Thu, Sep 15, 2011 at 11:02:33AM -0700, Garrett Cooper wrote: > On Thu, Sep 15, 2011 at 10:58 AM, Kevin Oberman wrote: > > On Thu, Sep 15, 2011 at 5:12 AM, Gary Palmer wrote: > >> On Wed, Sep 14, 2011 at 03:46:21PM -0700, Kevin Oberman wrote: > >>> Second, I frequently want custom newfs options, most notably -b, -f, > >>> and -i. There was no way to do this with sysinstall > >> > >> The source appears to disagree with you > >> > >> From usr.sbin/sysinstall/label.c > >> > >> /* If the user wants a special newfs command for this, set it */ > >> static void > >> getNewfsCmd(PartInfo *p) > >> > >> I'm pretty sure I've used that option in multiple releases of FBSD. > >> > >> If that is missing in the new installer then that is something that needs > >> fixed. > > > > I stand corrected and am baffled by how I missed it. > > > > I still want to see the arguments that are to be passed to newfs > > before I pull the trigger. > > That functionality doesn't exist today, unless you want to drop into > the shell and set everything up manually.. Is there a way of tracking suggested improvements to the new installer other than the mailing list archives? Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
On Sep 15, 2011, at 11:55 AM, Gary Palmer wrote: > Is there a way of tracking suggested improvements to the new installer http://svnweb.freebsd.org/base/head/usr.sbin/bsdinstall/ ? It's a little more annoying viewing changes in the ViewVC interface. There's also svn log though if you have a source tree with svn checked out.. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
On Thu, Sep 15, 2011 at 11:58:55AM -0700, Garrett Cooper wrote: > On Sep 15, 2011, at 11:55 AM, Gary Palmer wrote: > > > Is there a way of tracking suggested improvements to the new installer > > http://svnweb.freebsd.org/base/head/usr.sbin/bsdinstall/ ? It's a > little more annoying viewing changes in the ViewVC interface. There's > also svn log though if you have a source tree with svn checked out.. Apologies if you misunderstood my query. There has been a lot of discussion lately about bsdinstall, both bugs (or what people consider bugs) and suggestions for improvements. Bugs should obviously go in gnats (Discussions about whether gnats should be replaced can happen behind the pink bikeshed). How about improvement suggestions? Are they tracked anywhere? Wiki, gnats, scrap of paper on someones desk, etc? Even if they are ultimately not considered for inclusion into the new installer, there needs to be a way of tracking all the feedback. Thanks, Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-BETA2 do not support SpeedStep on E5420
on 15/09/2011 19:20 Arnaud Lacombe said the following: > est0: failed to enable SpeedStep > p4tcc0: on cpu0 > est1: failed to enable SpeedStep > p4tcc1: on cpu1 > est2: failed to enable SpeedStep > p4tcc2: on cpu2 > est3: failed to enable SpeedStep > p4tcc3: on cpu3 > est4: failed to enable SpeedStep > p4tcc4: on cpu4 > est5: failed to enable SpeedStep > p4tcc5: on cpu5 > est6: failed to enable SpeedStep > p4tcc6: on cpu6 > est7: failed to enable SpeedStep > p4tcc7: on cpu7 > > It feels strange that the latest FreeBSD do not support est(4) on a 3 > years old CPU... Somehow I do not read "failed to enable" as "can not detect" or "can not support" SpeedStep on this CPU. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-BETA2 do not support SpeedStep on E5420
On Thu, Sep 15, 2011 at 9:22 PM, Andriy Gapon wrote:
> on 15/09/2011 19:20 Arnaud Lacombe said the following:
>> est0: failed to enable SpeedStep
>> p4tcc0: on cpu0
>> est1: failed to enable SpeedStep
>> p4tcc1: on cpu1
>> est2: failed to enable SpeedStep
>> p4tcc2: on cpu2
>> est3: failed to enable SpeedStep
>> p4tcc3: on cpu3
>> est4: failed to enable SpeedStep
>> p4tcc4: on cpu4
>> est5: failed to enable SpeedStep
>> p4tcc5: on cpu5
>> est6: failed to enable SpeedStep
>> p4tcc6: on cpu6
>> est7: failed to enable SpeedStep
>> p4tcc7: on cpu7
>>
>> It feels strange that the latest FreeBSD do not support est(4) on a 3
>> years old CPU...
>
> Somehow I do not read "failed to enable" as "can not detect" or "can not
> support" SpeedStep on this CPU.
sys/x86/cpufreq/est.c:1008
/* Attempt to enable SpeedStep if not currently enabled. */
msr = rdmsr(MSR_MISC_ENABLE);
if ((msr & MSR_SS_ENABLE) == 0) {
wrmsr(MSR_MISC_ENABLE, msr | MSR_SS_ENABLE);
if (bootverbose)
device_printf(dev, "enabling SpeedStep\n");
/* Check if the enable failed. */
msr = rdmsr(MSR_MISC_ENABLE);
if ((msr & MSR_SS_ENABLE) == 0) {
device_printf(dev, "failed to enable SpeedStep\n");
return (ENXIO);
}
}
Andriy -
He is correct. Possibly power management on server processors isn't
considered a priority by the maintainer.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
On Thu, Sep 15, 2011 at 12:12 PM, Gary Palmer wrote: > On Thu, Sep 15, 2011 at 11:58:55AM -0700, Garrett Cooper wrote: >> On Sep 15, 2011, at 11:55 AM, Gary Palmer wrote: >> >> > Is there a way of tracking suggested improvements to the new installer >> >> http://svnweb.freebsd.org/base/head/usr.sbin/bsdinstall/ ? It's a >> little more annoying viewing changes in the ViewVC interface. There's >> also svn log though if you have a source tree with svn checked out.. > > Apologies if you misunderstood my query. There has been a lot of discussion > lately about bsdinstall, both bugs (or what people consider bugs) and > suggestions for improvements. Bugs should obviously go in gnats > (Discussions about whether gnats should be replaced can happen > behind the pink bikeshed). How about improvement suggestions? Are > they tracked anywhere? Wiki, gnats, scrap of paper on someones desk, > etc? Even if they are ultimately not considered for inclusion into > the new installer, there needs to be a way of tracking all the feedback. Seems like this is the best spot: http://wiki.freebsd.org/BSDInstall -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-BETA2 do not support SpeedStep on E5420
I was just discussing this issues with some others - evidently est(9) works fine on both older and newer cpus. I see you're active on lkml - does the linux driver work correctly on this machine? i.e. do you know that it isn't disabled in the BIOS. Thanks On Thu, Sep 15, 2011 at 6:20 PM, Arnaud Lacombe wrote: > Hi, > > >From today's -CURRENT: > > Copyright (c) 1992-2011 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 9.0-BETA2 #17 r225560+be1f8b9: Thu Sep 15 12:05:41 EDT 2011 > > al@shai-hulud:/data/src/freebsd/obj/master/i386.i386/data/src/freebsd/src/sys/GENERIC > i386 > CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2493.80-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 > Features=0xbfebfbff > Features2=0x40ce3bd > AMD Features=0x2010 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 6442450944 (6144 MB) > avail memory = 3677458432 (3507 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: <100509 APIC1714> > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) > 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 > [...] > est0: failed to enable SpeedStep > p4tcc0: on cpu0 > est1: failed to enable SpeedStep > p4tcc1: on cpu1 > est2: failed to enable SpeedStep > p4tcc2: on cpu2 > est3: failed to enable SpeedStep > p4tcc3: on cpu3 > est4: failed to enable SpeedStep > p4tcc4: on cpu4 > est5: failed to enable SpeedStep > p4tcc5: on cpu5 > est6: failed to enable SpeedStep > p4tcc6: on cpu6 > est7: failed to enable SpeedStep > p4tcc7: on cpu7 > > It feels strange that the latest FreeBSD do not support est(4) on a 3 > years old CPU... > > Thanks, > - Arnaud > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD and GPGPU on nVidia (OpenCL/CUDA): Pathscale and "open" compute driver
Just read this on www.phoronix.com: http://www.phoronix.com/scan.php?page=news_item&px=OTkxMA Does it sound promising? It seems so. Even if this would be a commercial product which would fits into FreeBSD's gap of having GPU compute support, this could be an affordable solution. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RELENG_8 / mpt / zpool Errors
> Can you connect an enclosure to the SAS 2008 chip card you have now > and test? I thought I had read about problems like yours with that > chip on FreeBSD when using such enclosures. The SAS 2008 chip we have is built in to the motherboard; it does not have any external connectors. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-BETA2 do not support SpeedStep on E5420
On Thu, Sep 15, 2011 at 12:32 PM, K. Macy wrote:
[...]
> sys/x86/cpufreq/est.c:1008
>
> /* Attempt to enable SpeedStep if not currently enabled. */
> msr = rdmsr(MSR_MISC_ENABLE);
> if ((msr & MSR_SS_ENABLE) == 0) {
> wrmsr(MSR_MISC_ENABLE, msr | MSR_SS_ENABLE);
> if (bootverbose)
> device_printf(dev, "enabling SpeedStep\n");
>
> /* Check if the enable failed. */
> msr = rdmsr(MSR_MISC_ENABLE);
> if ((msr & MSR_SS_ENABLE) == 0) {
> device_printf(dev, "failed to enable SpeedStep\n");
> return (ENXIO);
Looking at the Intel® 64 and IA-32 Architectures Software Developers
Manual (section 14.1), I think the code here is right?
(I'd expect Linux do the same since the code are mostly the same there).
Cheers,
--
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-BETA2 do not support SpeedStep on E5420
Hi, On Thu, Sep 15, 2011 at 4:26 PM, K. Macy wrote: > I was just discussing this issues with some others - evidently est(9) > works fine on both older and newer cpus. I see you're active on lkml - > does the linux driver work correctly on this machine? i.e. do you know > that it isn't disabled in the BIOS. > Actually, I checked the BIOS after I sent the mail. I not see anything related to that. Looking again, there is a BIOS entry named "Ratio CMOS Setting" whose help reads "Sets the ratio between CPU Core Clock and the FSB. Note: For CedarMill and Prescott Family CPUs, the setup option only available when Intel SpeedStep technology is disabled.". However, I'm not sure whether or not the E5420 is either a CedarMill and Prescott Family CPUs, or maybe the BIOS is just not enabling the feature. I did not try to boot a Linux on that platform. - Arnaud > Thanks > > On Thu, Sep 15, 2011 at 6:20 PM, Arnaud Lacombe wrote: >> Hi, >> >> >From today's -CURRENT: >> >> Copyright (c) 1992-2011 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 9.0-BETA2 #17 r225560+be1f8b9: Thu Sep 15 12:05:41 EDT 2011 >> >> al@shai-hulud:/data/src/freebsd/obj/master/i386.i386/data/src/freebsd/src/sys/GENERIC >> i386 >> CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2493.80-MHz 686-class >> CPU) >> Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 >> Features=0xbfebfbff >> Features2=0x40ce3bd >> AMD Features=0x2010 >> AMD Features2=0x1 >> TSC: P-state invariant, performance statistics >> real memory = 6442450944 (6144 MB) >> avail memory = 3677458432 (3507 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: <100509 APIC1714> >> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> FreeBSD/SMP: 2 package(s) x 4 core(s) >> 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 >> [...] >> est0: failed to enable SpeedStep >> p4tcc0: on cpu0 >> est1: failed to enable SpeedStep >> p4tcc1: on cpu1 >> est2: failed to enable SpeedStep >> p4tcc2: on cpu2 >> est3: failed to enable SpeedStep >> p4tcc3: on cpu3 >> est4: failed to enable SpeedStep >> p4tcc4: on cpu4 >> est5: failed to enable SpeedStep >> p4tcc5: on cpu5 >> est6: failed to enable SpeedStep >> p4tcc6: on cpu6 >> est7: failed to enable SpeedStep >> p4tcc7: on cpu7 >> >> It feels strange that the latest FreeBSD do not support est(4) on a 3 >> years old CPU... >> >> Thanks, >> - Arnaud >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-BETA2 do not support SpeedStep on E5420
Hi, On Thu, Sep 15, 2011 at 12:20 PM, Arnaud Lacombe wrote: > Hi, > > From today's -CURRENT: > > Copyright (c) 1992-2011 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 9.0-BETA2 #17 r225560+be1f8b9: Thu Sep 15 12:05:41 EDT 2011 > > al@shai-hulud:/data/src/freebsd/obj/master/i386.i386/data/src/freebsd/src/sys/GENERIC > i386 > CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2493.80-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 > Features=0xbfebfbff > Features2=0x40ce3bd > AMD Features=0x2010 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 6442450944 (6144 MB) > avail memory = 3677458432 (3507 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: <100509 APIC1714> > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) > 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 > [...] > est0: failed to enable SpeedStep > p4tcc0: on cpu0 > est1: failed to enable SpeedStep > p4tcc1: on cpu1 > est2: failed to enable SpeedStep > p4tcc2: on cpu2 > est3: failed to enable SpeedStep > p4tcc3: on cpu3 > est4: failed to enable SpeedStep > p4tcc4: on cpu4 > est5: failed to enable SpeedStep > p4tcc5: on cpu5 > est6: failed to enable SpeedStep > p4tcc6: on cpu6 > est7: failed to enable SpeedStep > p4tcc7: on cpu7 > different issue, same config, still est(4) related, bot on a Q9650: FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-BETA2 #16 r225462+e068e24-dirty: Sat Sep 10 14:50:17 EDT 2011 al@shai-hulud:/data/src/freebsd/obj/master/i386.i386/data/src/freebsd/src/sys/GENERIC i386 CPU: Pentium III/Pentium III Xeon/Celeron (2666.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x2010 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 2084757504 (1988 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 [...] est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082506000825 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082506000825 device_attach: est1 attach returned 6 p4tcc1: on cpu1 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082506000825 device_attach: est2 attach returned 6 p4tcc2: on cpu2 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082506000825 device_attach: est3 attach returned 6 p4tcc3: on cpu3 - Arnaud > It feels strange that the latest FreeBSD do not support est(4) on a 3 > years old CPU... > > Thanks, > - Arnaud > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 7-STABLE mbuf corruption
Hi, [added -current@ to the CC list, as the issue is still present in 9.0-BETA2] On Wed, Sep 7, 2011 at 7:19 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 5, 2011 at 2:59 AM, Arnaud Lacombe wrote: >> Hi folks, >> >> We have been trying to track down a bad mbuf management for about two >> weeks on a customized 7.1 base. I have finally been able to reproduce >> it with a stock FreeBSD 7-STABLE (kernel from r225276, userland from >> 7.4). >> >> With the help of the attached patches, I have just been able to >> trigger the following panic: >> >> panic: Corrupted unused flags, expected 0x, got 0x0, flags >> 0x3 >> cpuid = 1 >> Uptime: 3d10h5m3s >> Cannot dump. No dump device defined >> > General form of the crash is: > > panic: Corrupted unused flags, expected 0x, got > 0xbabe00, flags 0xbabebabe00 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c0874e29,0,c0835757,f4574c48,0,...) at > db_trace_self_wrapper+0x26 > panic(c0835757,0,,0,babe00,...) at panic+0x10b > igb_txeof(c6a25008,0,c0837083,5ea,17c,...) at igb_txeof+0x399 > igb_msix_que(c6a2b800,0,c084d367,4b6,c69dd068,...) at igb_msix_que+0x7b > ithread_loop(c6a29090,f4574d38,c084d0db,31c,c6a16828,...) at ithread_loop+0xc3 > fork_exit(c061d520,c6a29090,f4574d38) at fork_exit+0xa6 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xf4574d70, ebp = 0 --- > Uptime: 1m42s > I converted igb(4) to use the legacy if_start() logic and triggered the following panic on the latest FreeBSD 9.0-BETA2: panic: Corrupted mbuf tainting, expected 0x, got 0xaabb, taint 0xaabb cpuid = 6 KDB: enter: panic [ thread pid 0 tid 100045 ] Stopped at kdb_enter+0x3b: movl$0,kdb_why db> bt Tracing pid 0 tid 100045 td 0xc6bd52e0 kdb_enter(c081831c,c081831c,c08026c1,c673ec28,6,...) at kdb_enter+0x3b panic(c08026c1,,aabb,aabb,c6bd1400,...) at panic+0x103 igb_txeof(c6bd1408,0,c080411c,558,c6bd1408,...) at igb_txeof+0x318 igb_handle_que(c6bac400,1,c081e508,130,c673ecb0,...) at igb_handle_que+0xae taskqueue_run_locked(c6bdc400,c6bdc418,0,c080a966,0,...) at taskqueue_run_locked+0xa3 taskqueue_thread_loop(c6bac430,c673ed28,c0812d90,3f9,0,...) at taskqueue_thread_loop+0x4d fork_exit(c063ea10,c6bac430,c673ed28) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc673ed60, ebp = 0 --- for those who have not followed the thread on -net, the same mbuf is queued twice in the interface queue, transmitted twice... and freed twice. Of course, after having been released first, it ends up eventually in a socket buffer, and when it gets released the second time, it triggers all kind of funny panic() and crashes. The 0xaabb pattern comes from memory tainting with INVARIANTS at the ends of m_free(). I can provide the patches I am testing with. - Arnaud > It happens particularly easily when the box receives wall of SYN > (about 1000 cnx attempts at once) every 5s or so. > > - Arnaud > >> >> [cut stuff no one cares about...] > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
no X after installing xorg + xfce
Dear folks, I hope this is the correct list to post this message. I have successfully installed FreeBSD-9.0-BETA2 to an amd64 bit machine, I have used the ports to install xfce and xorg. When I type startx, I get a screen with a bunch of colors no mouse, no keyboard, just colors. The machine has nvidia onboard graphics. I am trying to get kernel sources installed via sysinstall to install nvidia-driver but I can't get anywhere from any ftp site I select at random. I have updated to latest sources available on the ports and it comes up the same. I have to use the nv driver, should I try the nouveau driver? What should I do? I want to help in testing and have no way to report bugs as without X there's not much one can do :( Thanks for advice/suggestions/comments. I am successfully running FreeBSD 8.2 amd64 on three machines two at home and one at work in case it is important/relevant in the thread. Regards, Antonio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: no X after installing xorg + xfce
On Thu, Sep 15, 2011 at 6:35 PM, Antonio Olivares wrote: > Dear folks, > > I hope this is the correct list to post this message. > > I have successfully installed FreeBSD-9.0-BETA2 to an amd64 bit > machine, I have used the ports to install xfce and xorg. When I type > startx, I get a screen with a bunch of colors no mouse, no keyboard, > just colors. The machine has nvidia onboard graphics. I am trying to > get kernel sources installed via sysinstall to install nvidia-driver > but I can't get anywhere from any ftp site I select at random. I have > updated to latest sources available on the ports and it comes up the > same. I have to use the nv driver, should I try the nouveau driver? > What should I do? I want to help in testing and have no way to report > bugs as without X there's not much one can do :( > > Thanks for advice/suggestions/comments. I am successfully running > FreeBSD 8.2 amd64 on three machines two at home and one at work in > case it is important/relevant in the thread. > > Regards, > > Antonio > There is no X, I try to get information about the onboard video and I get VendorName "nVidia Corporation" BoardName "C61 [GeForce 6150SE nForce 430]" I tried installing nouveau but it did not do any difference, screen is garbled no X. The BSD install setup was too fast and I did not select sources for kernel and now I can't install nvidia driver to see if I could get X working :( Again, I appreciate any input given to see how I can help in testing. Regards, Antonio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Queue drop not accounted ?
Hi,
Shouldn't packet freed in IFQ_ENQUEUE() because the queue is full be
accounted as dropped, cf attached patch ?
Thanks,
- Arnaud
diff --git a/sys/net/if_var.h b/sys/net/if_var.h
index 2dcb6f9..387f614 100644
--- a/sys/net/if_var.h
+++ b/sys/net/if_var.h
@@ -419,6 +419,7 @@ do { \
ALTQ_ENQUEUE(ifq, m, NULL, err); \
else {\
if (_IF_QFULL(ifq)) { \
+ _IF_DROP(ifq); \
m_freem(m); \
(err) = ENOBUFS;\
} else { \
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
more thoughts on the (9.0beta2) installer
Dear all, I set up a scratch box earlier this week (to check that openafs still works on beta2, and soon, HEAD), and took advantage of the opportunity to play around with the installer a bit. First off, let me thank Nathan for putting in a huge pile of work to get things to where they are -- the new installer is pretty solid, and looks to be much more improvable than sysinstall. Of course, I do have a few improvements of my own that I'd like to see find their way in ... I was doing this on top of an existing installation of 7.4 (also for openafs testing, surprise surprise), so my first thought was to just reuse the existing partitions/slices. However, this failed in the extracting stage with an error about not being able to create /var/empty (with permissions such and such; I didn't record it verbatim). Now, installing over an existing system is somewhat risk-prone, as there may well be stuff sitting around that is unneeded or actively harmful, but this is not the way I would expect an installer to enforce a "don't install on top of an existing installation" rule. When I was installing it, the ports.txz extraction felt very slow, slower even than portsnap extract. However, in a later installation I did not take ports from bsdinstall and used portsnap post-install, and it also felt longer than I remembered :) . So, maybe I (or someone else) should go back and actually time these things; I know that at least Thomas Mueller mentioned a portsnap preference on this list, and I suspect many other people do as well. The point being that, perhaps the ports.txz collection need not be selected by default. Having console messages overwrite the dialog is really annoying -- is there any way to have the installer run on VT4 or something, with console messages staying on VT0? If I can start up a shell to go do stuff mid-installation, then we must be multi-user, so I think this is possible Our Debathena installer here at MIT (on top of the debian installer) does this, actually even further separating console output and the installer output to separate terminals and having another one dedicated for user interaction. In the networking configuration, if I need to cancel out and try again, some settings (IP address/netmask/gateway) are saved and pre-filled for the next round, but others (e.g. distributions and resolver settings) are not. This inconsistency feels unnatural -- it would be really nice to have consistency. On the topifc of IP address and netmask and gateway, wouldn't it be enough to specify only one of the netmask and gateway, and determine the other accordingly? (Well, most of the time, at least.) In most of the installer, the new dialog is reasonable, with space select/deselecting and enter activating. But the behavior in the network configuration and resolver dialogs is different -- it seems that I have to use the up/down arrows to move between the IP address, netmask, and default router fields; enter on any of them still performs the 'ok' action, even though 'ok' is not selected when any of those three fields are selected. I think there are several ways in which this situation might be improved -- it might be that one of 'ok' and 'cancel' is always selected, or tab might move between the three entry fields as well as ok/cancel, or enter on one field might move to the next. (I didn't do anything with IPv6, so I don't know if similar issues are present there.) After installation is finished, I would really like a stage where I have the option of removing the CD, prior to rebooting. Otherwise I'll just end up at the installer again, unless I'm paying full attention to the machine and intervene in time. The guided partitioner is pretty overwhelming. Not so much as being handed raw fdisk/gpart/bsdlabel/etc. (hm, are there man pages available in the shell? I didn't think to check) and having to deal, but there's still a lot going on. Someone will need to sit down and try out a whole slew of combinations and document what is expected and furthermore what is recommended. (Sorry, I'm booked solid for the next couple weeks. It took me a couple days just to get to write this mail.) In particular, this list of seven (?) options when I select a physical disk is pretty daunting -- I'm pretty sure I want either GPT or MBR (or maybe BSD), but I don't remember seeing a "this one is probably what you want" notice. Once I'm in the interactive partitioner, I have no way of knowing what values are valid for the "type" other than essentially trial-and-error. (I think ivoras has also noted this?) If there was a way to display a list of valid or commonly-used values, that would be quite helpful. (When is "freebsd-ufs" used, versus just "freebsd"?) Also, if I try to modify a partition that I've created, I don't have the ability to change the size -- I have to delete and recreate. Now, I know that there are some cases where this
Re: 9.0-BETA2 do not support SpeedStep on old Core2Duo E4500 too
Hello, Arnaud. You wrote 16 сентября 2011 г., 1:19:29: CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (2200.09-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant coretemp0: on cpu0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr b280b2806000b28 device_attach: est0 attach returned 6 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr b280b2806000b28 device_attach: est1 attach returned 6 p4tcc1: on cpu1 -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-BETA2 do not support SpeedStep on E5420
on 16/09/2011 00:19 Arnaud Lacombe said the following: > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 616082506000825 > device_attach: est0 attach returned 6 This is a far more common issue. The output implies that acpi_perf driver hasn't been able to attach, presumably because it couldn't evaluate _PSS method. We usually discuss problems like this one on acpi@ and you can find some information in the archives of that mailing list. Diagnosing an issue like this requires examining DSDT and SSDT(s), if present, to see the logic there and what capabilities the firmware/BIOS expects from the OS. It's a tedious process and I am currently short on time. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-BETA2 do not support SpeedStep on old Core2Duo E4500 too
On Sep 15, 2011, at 10:21 PM, Lev Serebryakov wrote: > Hello, Arnaud. > You wrote 16 сентября 2011 г., 1:19:29: > > > CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (2200.09-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > > Features=0xbfebfbff > Features2=0xe39d > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > > coretemp0: on cpu0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr b280b2806000b28 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr b280b2806000b28 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 Like Andriy suggested, it might be an ACPI issue because it works just fine on these machines running 9.0-BETA2: $ dmesg | egrep 'Pentium|Xeon|^(coretemp|p4tcc|est)' CPU: Pentium(R) Dual-Core CPU E5800 @ 3.20GHz (3200.06-MHz K8-class CPU) est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 $ dmesg | egrep 'Xeon|^(coretemp|p4tcc|est)' CPU: Intel(R) Xeon(R) CPU X3230 @ 2.66GHz (2664.06-MHz K8-class CPU) est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 $ dmesg | egrep 'Xeon|^(coretemp|est)' CPU: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz (2672.78-MHz K8-class CPU) coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 coretemp2: on cpu2 est2: on cpu2 coretemp3: on cpu3 est3: on cpu3 coretemp4: on cpu4 est4: on cpu4 coretemp5: on cpu5 est5: on cpu5 coretemp6: on cpu6 est6: on cpu6 coretemp7: on cpu7 est7: on cpu7 Thanks, -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cvsup broken on amd64?
On Wed, Sep 14, 2011 at 11:19 PM, Adrian Chadd wrote: > Pester the maintainer? The maintainer is alumni. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r225474 - in head/sys: amd64/amd64 amd64/ia32 i386/i386 ia64/ia32 ia64/ia64 kern powerpc/aim powerpc/booke sparc64/sparc64 sys
On Wed, Sep 14, 2011 at 4:10 PM, Garrett Cooper wrote: > On Sep 14, 2011, at 2:09 PM, Kostik Belousov wrote: > >> [It seems that distribution list can be trimmed without any bad >> consequences] >> On Wed, Sep 14, 2011 at 01:50:51PM -0700, Garrett Cooper wrote: >>> On Sun, Sep 11, 2011 at 9:05 AM, Konstantin Belousov >>> wrote: Author: kib Date: Sun Sep 11 16:05:09 2011 New Revision: 225474 URL: http://svn.freebsd.org/changeset/base/225474 Log: Inline the syscallenter() and syscallret(). This reduces the time measured by the syscall entry speed microbenchmarks by ~10% on amd64. Submitted by: jhb Approved by: re (bz) MFC after: 2 weeks >>> >>> This change completely breaks ZFS mounting (for some odd reason) >>> with the following backtrace. >>> >>> #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:260 >>> 260 /usr/src/sys/kern/kern_shutdown.c: No such file or directory. >>> in /usr/src/sys/kern/kern_shutdown.c >>> (kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:260 >>> #1 0x802b1cd0 in db_dump (dummy=Variable "dummy" is not available. >>> ) >>> at /usr/src/sys/ddb/db_command.c:537 >>> #2 0x802b12c1 in db_command (last_cmdp=0x809b96c0, >>> cmd_table=Variable "cmd_table" is not available. >>> >>> ) at /usr/src/sys/ddb/db_command.c:448 >>> #3 0x802b1510 in db_command_loop () >>> at /usr/src/sys/ddb/db_command.c:501 >>> #4 0x802b3664 in db_trap (type=Variable "type" is not available. >>> ) at /usr/src/sys/ddb/db_main.c:229 >>> #5 0x804b29d1 in kdb_trap (type=3, code=0, tf=0xff8231a5f3d0) >>> at /usr/src/sys/kern/subr_kdb.c:631 >>> #6 0x80646ac8 in trap (frame=0xff8231a5f3d0) >>> at /usr/src/sys/amd64/amd64/trap.c:590 >>> #7 0x8063113f in calltrap () >>> at /usr/src/sys/amd64/amd64/exception.S:228 >>> #8 0x804b277b in kdb_enter (why=0x806e022b "panic", >>> msg=0x80 ) at cpufunc.h:63 >>> #9 0x8047db5c in panic (fmt=Variable "fmt" is not available. >>> ) >>> at /usr/src/sys/kern/kern_shutdown.c:599 >>> #10 0x8046e5cc in _mtx_assert (m=Variable "m" is not available. >>> ) >>> at /usr/src/sys/kern/kern_mutex.c:706 >>> #11 0x80620f31 in vm_page_free_toq (m=0xfe021bf3d1f0) >>> at /usr/src/sys/vm/vm_page.c:1756 >>> #12 0x80c77938 in zfs_freebsd_getpages () from /boot/kernel/zfs.ko >>> #13 0x8046ebd6 in _mtx_unlock_flags (m=0xfe0006dc7000, >>> opts=421100272, file=0xfe0006dc70e8 "?P?\200", line=1) >>> at /usr/src/sys/kern/kern_mutex.c:223 >>> Previous frame inner to this frame (corrupt stack?) >>> (kgdb) >> >> The backtrace is impossible and truncated. You probably used unmatched >> kernel for vmcore, or might be, the zfs.ko is installed without debugging >> symbols. >> >> The change you pointed the finger to has very low probability of causing >> the panic for vm_page_free_toq(), it is for unrelated part of the kernel. >> Can you do full rebuild of the kernel without any possible local changes >> and retest ? >> >> If still getting panic, make sure that both kernel and all modules are >> installed with debug symbols. > > zfs.ko wasn't built with symbols because I did make -C /sys/modules/zfs all > install; will rebuild my kernel and submit my results again :). Weird. The new kernel didn't exhibit the problem after I blew away /usr/obj (and it contains all of the changes that the old kernel had).. I guess I'll have to chock this up to improperly compiled sources.. Sorry for the noise. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: cvsup broken on amd64?
> Pester the maintainer? I've thought that if an opened PR exists, then it have to be reviewed sooner or later... -- Alexander Zagrebin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cvsup broken on amd64?
on 15/09/2011 12:16 Alexander Zagrebin said the following: >> Pester the maintainer? > > I've thought that if an opened PR exists, then it have to be > reviewed sooner or later... > Usually rather quite later than sooner. There are about 5000 non-ports PRs and there are only a few dozen active developers. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
Hello, Kevin. You wrote 15 сентября 2011 г., 2:46:21: >>> 7. On the partition editor screen the option should be the >>> first in the list (ie; left most side) so if user accepts this config, >>> hitting enter moves to next menu screen instead of having to tab over >>> taking more time and effort. >> And again: there is no way to change block size/frag size/inode >> number in GUI. Only SU/SU+J/Version present in "Options" and here is >> no way to change options after partition creation (adding to dialog) >> but BEFORE real FS are created (changes are committed). > First, I don't think you get SU+J (soft-updates and full FS journal), which is > a bad combination. I think you get SUJ (journal of metadata) which is > a very different and is, I believe the preferred default setup. `+' character could be my mistake here. > Of course, all of these are issues that exist with the old installer, > but I think can be improved with the move to bsdinstall. As far as I remember, old installer (with "black-bacgrounded" partiiton creation screen) allows to provide additional newfs arguments... But I've used it very long time ago for last time... -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cvsup broken on amd64?
> Usually rather quite later than sooner. A perfect opportunity for src committers to dive in and make a difference :-) mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 beta2 & the new bsdinstaller
On Wed, Sep 14, 2011 at 03:46:21PM -0700, Kevin Oberman wrote: > Second, I frequently want custom newfs options, most notably -b, -f, > and -i. There was no way to do this with sysinstall The source appears to disagree with you >From usr.sbin/sysinstall/label.c /* If the user wants a special newfs command for this, set it */ static void getNewfsCmd(PartInfo *p) I'm pretty sure I've used that option in multiple releases of FBSD. If that is missing in the new installer then that is something that needs fixed. Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
9.0 bata2 & keymap
Out of the 9 USA maps only "us.iso.acc.kbd" worked somewhat.
The keyboard 9 key block above the arrow keys don't function.
Issuing the "man cmd_name" command doe's display the man page,
but the {Page up, Page down keys } don't work.
Also when using the "ee" edit command the {delete, Page up, Page down
keys } don't work. This does not happen in any of the previous releases.
Further more, localization of the keyboard should not be forced on the
user during the install process. This BSDinstall option should be
disabled or removed.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: changing a zfs pool to another machine
on 15/09/2011 00:26 Alisson said the following: > Hi... > > I have a zfs pool with 3 harddrives (ad8,ad10,ad15) > > I need to change to another machine... > > when I try to boot freebsd in the another machine with this 3 harddrives... > goes to mountroot prompt. > > so.. I need to boot with > > set vfs.root.mountfrom="zfs:tank/root" > > but don't work... goes ever to mountroot prompt.. To be able to boot from a pool you must first arrange for the pool to be to zpool.cache file. If you have exported the pool you would need some alternative boot media to import it first. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RELENG_8 / mpt / zpool Errors
> The SAS 2008 chip (SAS 6G) is the one that the FreeBSD mps driver has > problems with when used with port expanders. It's the older SAS 3G chip > that works OK with FreeBSD I think. I had crossed some wires earlier on in our discussion. We do have a SAS 2008 chip in the system already, but it's not the one that's running the external disk boxes (and we are having no problem with those drives). The external disk boxes (the ones that are having the problems) are connect through an LSI SAS 3801E, which is handled by the mpt driver. The mpt driver is what's giving us trouble right now. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
couple of sched_ule issues
This is more of a "just for the record" email.
I think I've already stated the following observations, but I suspect that they
drowned in the noise of a thread in which I mentioned them.
1. Incorrect topology is built for single-package SMP systems.
That topology has two levels ("shared nothing" and "shared package") with
exactly
the same CPU sets. That doesn't work well with the rebalancing algorithm which
assumes that each level is a proper/strict subset of its parent.
2. CPU load comparison algorithms are biased towards lower logical CPU IDs.
With all other things being equal the algorithms will always pick a CPU with a
lower ID. This creates certain load asymmetry and predictable patterns in load
distribution.
Another observation.
It seems that ULE makes a decision about thread-to-CPU affinity at the time
when a
thread gets switched out. This looks logical from the implementation point of
view. But it doesn't seem logical from a general point of view - when the
thread
will be becoming running again its affinity profile may become completely
different. I think that it would depend on how much a thread actually spends
not
running.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
