We are looking for feedback regarding sccKit 1.4.2.
If you are currently using sccKit 1.4.2, please post your comments.
sccKit 1.4.2 beta is available here:
http://marcbug.scc-dc.com/svn/repository/tarballs/sccKit_1.4.2.tar.bz2
We have a 1.4.2 beta SCC system available in the SCC-dc. If you are interested in testing, request here:
http://marcbug.scc-dc.com/bugzilla3/show_bug.cgi?id=380
Details are here:
http://communities.intel.com/message/147525#147525
If there are no open P1 bugs by 4/30/2012 we will make sccKit available to data center accounts.
We have four beta testers in SCC-DC.
The beta has been installed on three SCC-DC systems.
Beta downloaded by over 30 remote users.
Usage observations so far are:
The new default linux memory allocation different from that of the 1.4.1.3 default image
Top reports only around half of the memory available vs the 1.4.1.3 image
1.4.2
Mem: 40280K used, 215172K free, 0K shrd, 0K buff, 30908K cached
1.4.1.3
Mem: 68956K used, 574204K free, 0K shrd, 0K buff, 56404K cached
Issue with running at a higher frequency on marc042 and marc006.
Higher frequency currently works fine on marc004.
selecting (1) Tile800_Mesh1600_DDR1066 causes boot failure on marc042 and marc006 (bug 402)
Installation observations:
If the target SCC system is currently setup with 1.4.1.3 emac enabled, the install is simple.
Basically untar and change the “current” softlink to point to 1.4.2.
New Linux CPU usage observation from beta tester:
The cores on 1.4.2 seemed more overwhelmed when running my programs (>90% CPU usage) than those on 1.4.1.3 (~30-40% CPU usage)
Actually, we have issue with running at a higher frequency on own system. Until when runing the install script, the problem is existing.
Thanks Hayder.
I have three SC-DC systems that would not run at the higher frequency until I ran the install script. Now all three have been working fine at the higher frequency.
Did running the script solve your problem?
I am also interested in knowing if you incremented the update.txt file before running the script.
/opt/sccKit/1.4.2/firmware/RockyLake/update/update.txt
-augie
>Did running the script solve your problem?
Hayder
Hayder,
I had a similar problem here in the MARC lab. Replacing the RockyLake chip fixed the problem.
It would seem the prior chip that would not run at the higher frequency was defective when running at the higher frequency.

