Re: [osol-discuss] MAX CPUs in OpenSolaris?
Aubrey Li wrote: On Thu, May 22, 2008 at 11:28 PM, Peter Eriksson [EMAIL PROTECTED] wrote: I know that there used to be a 256 CPU limit in Solaris, but what are the current limits? How many processors can OpenSolaris handle? It depends on which platform. Previously, NCPU is 32 on 32-bit x86 kernel, and 64 on 64-bit x86 kernel. From B87, NCPU on 64-bit x86 kernel has been changed to 256. On the SPARC side I believe it's currently defined as high as 512. The only reason there is a static limit at all, is because there are still some allocations of per CPU data needing to be done early in boot (prior to kmem service availability). -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] panic[cpu0]/thread=fec1f2e0: assertion failed
Eric Saxe wrote: Dennis Clarke wrote: Dennis, was this an Intel or AMD based system? Actually neither .. it is a low power appliance motherboard based on VIA technology. I see. If you can provide me access to a crash dump somehow, that would be helpful. Otherwise, if you can reproduce this let's take the conversation offline (or to a chat session), and we can debug it live... FYI, this bug: 6580117 panic: assertion failed: ISP2(CPUSETSIZE()) on VIA Esther based system ...has been fixed in build 74 (Kit Chow fixed it)... Thanks, -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] High system cpu time
Can you provide your lockstat output again, this time with the -s flag... Something like: lockstat -kIW -s 20 -D 20 sleep 2 The stack traces might help... Thanks, -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] FlashPlayer 9 on SXDE on Laptop...It's Been a Long Time Coming!
Dick Davies wrote: On 17/07/07, Kaiwai Gardiner [EMAIL PROTECTED] wrote: The new power management in B70 should also make it a nice platform for university - I like sitting in the cafe doing some study without seeing my battery drop like a rock. That's interesting - is that the 'frkit/power management' packages ( from http://opensolaris.org/os/community/laptop/ ) or something else? See: http://www.opensolaris.org/os/community/on/flag-days/pages/2007071601/ and: http://mail.opensolaris.org/pipermail/tesla-dev/2007-July/92.html Thanks, -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] panic[cpu0]/thread=fec1f2e0: assertion failed
Jürgen Keil wrote: cpu0: x86 (CentaurHauls 6A9 family 6 model 10 step 9 clock 1200 MHz) cpu0: VIA Esther processor 1200MHz Could be missing / broken or incomplete VIA/CentaurHauls x86 cpu support: I'm suspecting that you are correct Jürgen. According to: http://en.wikipedia.org/wiki/VIA_C7#Esther ...the CPU's L2 is 32-way set associative, so we're likely mis-characterizing it. I'm trying to get access to the CPUID specification for this CPU. If someone can send me a pointer, i'd be grateful. :) -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] panic[cpu0]/thread=fec1f2e0: assertion failed
Dennis Clarke wrote: This seems to be an opportunity to employ some code early in the boot phase and to perhaps print out some debugging info at that time. The question is .. where and what to debug. Can you send me the output of: # echo cpuid_info0::print | mdb -k Those are the tea leaves that i'll be using the VIA CPUID guide to interpret. :) Thanks, -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] panic[cpu0]/thread=fec1f2e0: assertion failed
Dennis Clarke wrote:
Dennis Clarke wrote:
This seems to be an opportunity to employ some code early in the boot
phase
and to perhaps print out some debugging info at that time.
The question is .. where and what to debug.
Can you send me the output of:
# echo cpuid_info0::print | mdb -k
# echo cpuid_info0::print | mdb -k
{
cpi_pass = 0x4
cpi_maxeax = 0x1
cpi_vendorstr = [ CentaurHauls ]
cpi_vendor = 0x6
cpi_family = 0x6
cpi_model = 0xa
cpi_step = 0x9
cpi_chipid = 0x
cpi_brandid = 0
cpi_clogid = 0
cpi_ncpu_per_chip = 0x1
cpi_cacheinfo = [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ]
cpi_ncache = 0
cpi_std = [
{
cp_eax = 0x1
cp_ebx = 0x746e6543
cp_ecx = 0x736c7561
cp_edx = 0x48727561
}
{
cp_eax = 0x6a9
cp_ebx = 0x10800
cp_ecx = 0
cp_edx = 0xa7c9bbff
}
{
cp_eax = 0
cp_ebx = 0
cp_ecx = 0
cp_edx = 0
}
{
cp_eax = 0
cp_ebx = 0
cp_ecx = 0
cp_edx = 0
}
{
cp_eax = 0
cp_ebx = 0
cp_ecx = 0
cp_edx = 0
}
{
cp_eax = 0
cp_ebx = 0
cp_ecx = 0
cp_edx = 0
}
]
cpi_xmaxeax = 0x8006
cpi_brandstr = [ VIA Esther processor 1200MHz ]
cpi_pabits = 0x24
cpi_vabits = 0x20
cpi_extd = [
{
cp_eax = 0x8006
cp_ebx = 0
cp_ecx = 0
cp_edx = 0
}
{
cp_eax = 0
cp_ebx = 0
cp_ecx = 0
cp_edx = 0
}
{
cp_eax = 0x20202020
cp_ebx = 0x20202020
cp_ecx = 0x20202020
cp_edx = 0x20202020
}
{
cp_eax = 0x56202020
cp_ebx = 0x45204149
cp_ecx = 0x65687473
cp_edx = 0x72702072
}
{
cp_eax = 0x7365636f
cp_ebx = 0x20726f73
cp_ecx = 0x30303231
cp_edx = 0x7a484d
}
{
cp_eax = 0
cp_ebx = 0x8800880
cp_ecx = 0x40040140
cp_edx = 0x40040140
}
{
cp_eax = 0
cp_ebx = 0
cp_ecx = 0x80a140
cp_edx = 0
}
{
cp_eax = 0
cp_ebx = 0
cp_ecx = 0
cp_edx = 0
}
{
cp_eax = 0
cp_ebx = 0
cp_ecx = 0
cp_edx = 0
}
]
cpi_coreid = 0
cpi_ncore_per_chip = 0x1
cpi_support = [ 0xa7c9bbff, 0, 0, 0, 0 ]
cpi_chiprev = 0
cpi_chiprevstr = 0xfe8a6a80 Unknown
cpi_socket = 0
cpi_mwait = {
mon_min = 0
mon_max = 0
support = 0
}
}
Those are the tea leaves that i'll be using the VIA CPUID guide to
interpret. :)
let me know anything else that you need.
Thanks, I can see from cpuid_info0.cpi_extd[6].cp_ecx[15:12] where the
associativity was
derived from (0xa), so we were assuming an AMD style cache description
(amd_l2cacheinfo()).
cpuid_info.cpi_std[2] is filled with 0x20 descriptors...for which we
don't have an entry in our
tables. If the appropriate CPUID reference says we should be using
function 2, then that's probably
the problem.
I've filed:
6580117 panic: assertion failed: ISP2(CPUSETSIZE()) on VIA Esther
based system
for this.
Thanks,
-Eric
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] panic[cpu0]/thread=fec1f2e0: assertion failed
Dennis Clarke wrote: Hmm, startup_memlist+3f5 passes these as parameters to page_coloring_init(), so if we trust the parameters shown in the stack backtrace, we have pagecolor_memsz = page_coloring_init(l2cache_sz, l2cache_linesz, l2cache_assoc); fec38300 unix:page_coloring_init+35a (2, 40, a) l2cache_sz == 0x2, l2cache_linesz == 0x40, l2cache_assoc == 0xa That should give us a CPUSETSIZE() of 0x2 / 0xa == 0x, which is not a power of 2. 10 way set associative cache eh. ;) Dennis, was this an Intel or AMD based system? Thanks, -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] panic[cpu0]/thread=fec1f2e0: assertion failed
Eric Saxe wrote: Dennis Clarke wrote: Hmm, startup_memlist+3f5 passes these as parameters to page_coloring_init(), so if we trust the parameters shown in the stack backtrace, we have pagecolor_memsz = page_coloring_init(l2cache_sz, l2cache_linesz, l2cache_assoc); fec38300 unix:page_coloring_init+35a (2, 40, a) l2cache_sz == 0x2, l2cache_linesz == 0x40, l2cache_assoc == 0xa That should give us a CPUSETSIZE() of 0x2 / 0xa == 0x, which is not a power of 2. 10 way set associative cache eh. ;) Dennis, was this an Intel or AMD based system? Never mind...I neglected to look closely at the verbose boot output you provided... Thanks... -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] panic[cpu0]/thread=fec1f2e0: assertion failed
Dennis Clarke wrote: Dennis, was this an Intel or AMD based system? Actually neither .. it is a low power appliance motherboard based on VIA technology. I see. If you can provide me access to a crash dump somehow, that would be helpful. Otherwise, if you can reproduce this let's take the conversation offline (or to a chat session), and we can debug it live... Thanks, -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Flashplayer 9 Gone from Adobe Site
Eric Saxe wrote: Bob Palowoda wrote: Ah this does sound encouraging. Though it's still confusing why the download page says Solarisx86 and points to a Sparc version. It did at one time point to x86 versions. But maybe this an Adobe web page problem. I've been going back and forth with Adobe support on this one trying to get the link fixed. So far, it's been rather painful. Adobe just notified me that they are working on correcting this. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Flashplayer 9 Gone from Adobe Site
Bob Palowoda wrote: Ah this does sound encouraging. Though it's still confusing why the download page says Solarisx86 and points to a Sparc version. It did at one time point to x86 versions. But maybe this an Adobe web page problem. I've been going back and forth with Adobe support on this one trying to get the link fixed. So far, it's been rather painful. -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Brian Gupta wrote: I have reached decided to include my local LUG in the conversation. I have linked the thread, in case anyone is interested. They have some very valid points). Thanks for doing this Brian. I find the discussion on the thread fascinating. -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Project Proposal: Tesla, Solaris Enhanced Power Management
I'd like to propose a project to provide an enhanced platform independent power management architecture...to be known as Project Tesla. From a high level, this project would implement a set of kernel policies (including a default) that would leverage existing (and forthcoming) platform specific power management mechanisms (including PowerNow and Enhanced Speedstep). A second goal of the project would be to implement a platform independent power management administrative paradigm, though which administrators could specify (to start) power and performance objectives that the system would then attempt to honor though employment of one of the aforementioned policies. Longer term, it is conceivable that other types of objectives could be expressed. Implementation of power aware scheduling policy that meshes well with the kernel's existing CMT and NUMA policy would be an initial focus for the project, along with exploration, and prototyping of an administrative facility. Thanks, -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [perf-discuss] [osol-discuss] Proposal: new project for improving ON build times
Alexander Kolbasov wrote: I would like to propose a project aimed to improve ON build times. This can live either under tools or under performance or under some other community. There was some discussion about it a while ago in the context of Google summer of code: http://www.opensolaris.org/jive/message.jspa?messageID=33951 It may be a part of ONNV project, or something else if you think that some other project/community is more suitable. The goal of the project is to make our ON builds faster. This includes, but is not limited to: - Developing and running observability tools to understand existing problems and find some low-hanging fruits - Increasing build parallelism - Taking advantage of new OpenSOlaris technologies like DTrace and ZFS. - Cleaning up Makefiles (at least some major Makefile issues) - Exploring some aggressive tricks and techniques to radically improve build times - Exploring various caching approaches. The goal is to make builds fast enough for developers to be productive. This is, probably, going to be an open-ended project. +1 -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Pentium D Dual Core 64-bit kernel problem
Hi Ron, Ron Halstead wrote: I have just installed nv47 on a new Asus P5WD2-E M/B with Pentium D Dual Core cpu and 975x chipset. The machine boots a 64 bit kernel, which is not as stable as the same OS version on a Intel 32-bit single core machine. Is there a way to 1) force the installation of the 32-bit OS or 2) force the machine to boot the 32-bit kernel? Apparently, the CPU has EM64T support and Solaris sees a 64-bit cpu. I've tried Solaris 10 u2 and Solris 10 9/06 on the new machine with the same, unstable, 64-bit results. Any help is appreciated. At this rate, my older machine is better than the new one. You can pass kernel/unix as an argument to multiboot in grub, which will cause the 32-bit kernel to boot. It would also be good to know why the 64-bit kernel doesn't seem as stable, as that's something that should be fixed. :) Any information you can provide in a bug report filed at bugs.opensolaris.org would be greatly appreciated. Thanks, -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Some questions....
Boyd Adamson wrote: The global priorities are what is used by the scheduler to decide what to do in the disp() function. Each class provides a mapping from user to global priorities. I'm not aware, off the top of my head, of a way to manipulate the global priorities directly. If you just want to specify priorities in terms of what ends up being the global priority range, then FX is probably for you, although to specify a priority greater than 0, privileges are required. -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
