JPRT system changes

[Vladimir Kozlov]

Tim,

It is not just JBB. Here is current status:

   [ 3 windows_x64_6.1 clients, 3 hosts ]
     sc11136526(P1)[DevOps VM Windows 7 X64]: running 
<2012-10-26-154155.jcoomes.gc-push> windows_x64-product-c2-GCBasher_ParOldGC(46m 
40s)
     sc11136598(P1)[DevOps VM Windows 7 X64]: running 
<2012-10-26-003719.vkozlov.7163534> 
windows_x64-fastdebug-c2-jbb_default_nontiered(56m 10s)
     sc11136603(P1)[DevOps VM Windows 7 X64]: running 
<2012-10-26-154155.jcoomes.gc-push> windows_x64-product-c2-runThese_Xcomp(36m 52s)

Vladimir

Tim Bell wrote:
> Adding hotspot-dev for the question about jbb_default below.
> 
> Kelly-
> 
>> I'll be taking all the Windows 7 systems out of the queues until we 
>> resolve this.
> 
> Rather than take them out, could you make thw W7 systems build-only?
> 
> The root of the problem is that jbb does not really run properly in 
> headless mode.  Everything after that has been us standing on our heads 
> trying to work around breakage in jbb or in AWT.
> 
> Is jbb_default worth keeping, or is it simply run out of habit? Just 
> asking because it is causing a fair amount of trouble.
> 
> 
> Tim
> 
> On 10/26/12 09:56, Kelly O'Hair wrote:
>> It's the Windows 7 jbb issue.
>>
>> We have seen this before in JPRT Stockholm, which was the first JPRT 
>> system that had Windows 7.
>>
>> Current theory, not sure how much we understand this, is that the 
>> CYGWIN sshd service is somehow
>> involved, and that if we manually start sshd the hang goes away.
>> But so far we haven't had any solutions on how to get this manual sshd 
>> startup to work on reboots.
>>
>> I'll be taking all the Windows 7 systems out of the queues until we 
>> resolve this.
>>
>> -kto
>>
>> On Oct 26, 2012, at 9:31 AM, Vladimir Kozlov wrote:
>>
>>> It looks like some of new machines periodically timeout during jbb 
>>> test run (>25min) so out jobs failed.
>>>
>>>   windows_x64-fastdebug-c2-jbb_default              FAILED(25m 40s)
>>>         USED:     hostname=sc11136526 platform=windows_x64_6.1 
>>> osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB 
>>> instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true 
>>> dxsdk=true pstools=true
>>>         ATTRS:    cygwin=true
>>>         TIMING:   clean=1s init=13s work=25m12s fini=5s
>>>         VMFLAGS:  -server -Djava.awt.headless=true
>>>         NEEDS:    cygwin,gnumake381,jbb,jtreg
>>>
>>>
>>>   windows_x64-fastdebug-c2-jbb_default              FAILED(25m 50s)
>>>         USED:     hostname=sc11136603 platform=windows_x64_6.1 
>>> osname=windows osarch=x64 cpus=2 parallelcount=2 ram=7899MB 
>>> instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true 
>>> dxsdk=true pstools=true
>>>         ATTRS:    mks=true
>>>         TIMING:   clean=12s init=13s work=25m13s fini=4s
>>>         VMFLAGS:  -server -Djava.awt.headless=true
>>>         NEEDS:    gnumake381,jbb,jtreg,mks
>>>
>>> Vladimir
>>>
>>> Kelly O'Hair wrote:
>>>> I have updated all the JPRT systems to a new version.
>>>> JPRT Version: 3.0.47: (2012-10-23) Case of the Unwelcome Well
>>>> Changes:
>>>> * hotspotwest will get all the Windows X64 machines currently used 
>>>> by the sfbay queue (4 X64 systems, 1 is a VM)
>>>> * sfbay will get 6 new Windows X64 DevOps VM's
>>>> * Both sfbay and hotspotwest will each get 3 new Windows 7 X64 DevOp 
>>>> VMs
>>>> * some changes with regards to how JPRT kills off processes on 
>>>> clients, should help kill off failed or hung cygwin builds
>>>> * An attempt to allow ccache to work on Solaris with build-infra builds
>>>> There are some JPRT sfbay machines that are down, tickets have been 
>>>> filed. So sfbay is shy Solaris SPARC and one MacPro.
>>>> JPRT East is missing some Solaris SPARC machines.
>>>> -kto
> 
>