And this details the commits that contain what is believed to be the fix. ----- Forwarded message from Edward Nevill <[email protected]> -----
Date: Thu, 18 Sep 2014 07:46:49 +0100 From: Edward Nevill <[email protected]> To: Matthias Klose <[email protected]> Cc: Wookey <[email protected]>, [email protected] Subject: Re: Fw: Re: Fw: Re: openjdk-7 build failure on juno X-Spam-Status: No, score=-2.6 required=4.5 tests=AWL,BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 Hi, aph added the changes in a number of commits between Sep 09 and Sep 10 to the jdk8 tree. The following are the relevant changesets 6791:cdba257ca1e7 6789:5f7c46ba5f04 6788:63104abf5948 6787:a97d9870ab4f These were then merged into the jdk7u tree on Sep 11 with the changeset 6793:116bc9da35de This was then tagged as jdk7u60_b04_aarch64_834 in changeset 6794:9580ebccfdc3 I would suggest using 6794:9580ebccfdc3. It contains only bugs fixes over the revision you are currently using (778cb4032983). All the best, Ed. On 18/09/2014, Matthias Klose <[email protected]> wrote: > Hi guys, > > would be nice to CC me, not just forward me something to avoid some > speculation. > > The Ubuntu build uses the aarch64 hotspot directly, revision 778cb4032983. > > However I think that Ed references a97d9870ab4f? Or some other revision? > > Matthias > > Am 18.09.2014 um 01:29 schrieb Wookey: >> Looks like this is probably the root of the openjdk segfault on >> juno/A57 issue (subject to test confirmation). >> >> I guess I should file a bug about this to record the details. >> >> ----- Forwarded message from Edward Nevill <[email protected]> >> ----- >> >> Date: Thu, 18 Sep 2014 00:16:58 +0100 >> From: Edward Nevill <[email protected]> >> To: Wookey <[email protected]> >> Cc: Edmund Grimley-Evans <[email protected]> >> Subject: Re: Fw: Re: openjdk-7 build failure on juno >> X-Spam-Status: No, score=-2.6 required=4.5 tests=AWL,BAYES_00, >> RCVD_IN_DNSWL_LOW autolearn=ham >> version=3.3.2 >> >> Hi, >> >> OK. Looking at Edmund's description of the problem I believe this is >> due to a problem with ISBs. >> >> The problem is that when the JIT patches up code on the fly it does >> >> - flush dcache >> - invalidate icache >> >> on the patched region (with appropriate memory barriers). >> >> The problem is that on ARMv8 this is not sufficient. Every core that >> might execute the code that has just been patched must do an ISB, not >> just the core that is doing the patching. >> >> So essentially the core that is doing the patching must force all >> other cores to do an ISB. The only practical way to do this is to >> force all other threads within the process to do an ISB. >> >> The reason this does not happen on Mustang is that the ICache is more >> coherent on Mustang than on A57. I had thought that the additional ISB >> was unnecessary on Mustang, but Edmund says he has seen the problem >> once on Mustang. >> >> So, the good news is that a patch to fix this has been pushed to the >> aarch64 jdk7 hotspot tip >> >> http://hg.openjdk.java.net/aarch64-port/jdk7u/hotspot >> >> However, you are building from IcedTea which does not use this. >> Instead it uses a snapshot tarball of the hotspot tree. This is why >> you could not find the gcc.make, because it is wrapped up in the >> hotspot tarball. >> >> There is a file hotspot.map in the top level of the IcedTea build >> which, for each architecture, points to the hotspot tarball for that >> arch. >> >> So, what need to happen is a new hotspot tarball needs to be created >> from the repository above and then the entry in the hotspot.map >> replaced with the new entry allong with the appropriate SHA256SUM. >> >> If you let me know what version of IcedTea you are using I can create >> the revised tarball tomorrow. >> >> I *think* this should fix the problem. >> >> If this is the problem then just using taskset 01 on the whole build >> should make the problem go away albeit very slowly. >> >> All the best, >> Ed. >> >> >> On 17/09/2014, Wookey <[email protected]> wrote: >>> some more info from other-Ed. Edmund - keep Ed Nevil cc:ed on this as >>> he might some idea what to poke. >>> >>> ----- Forwarded message from Edmund Grimley Evans >>> <[email protected]> ----- >>> >>> Date: Wed, 17 Sep 2014 15:25:05 +0100 >>> From: Edmund Grimley Evans <[email protected]> >>> To: Wookey <[email protected]> >>> Subject: Re: debian-ports >>> X-Spam-Status: No, score=-2.6 required=4.5 tests=BAYES_00,FREEMAIL_FROM, >>> RCVD_IN_DNSWL_LOW,T_DKIM_INVALID >>> autolearn=ham version=3.3.2 >>> >>> Some updates: >>> >>> A good way to copy the ginormous build tree is with: tar cf - dir | >>> ssh host 'cd somewhere && tar xf -' >>> >>> (It took me a little while to understand that the argument to ssh is >>> not really what I call a "command" but some strings that get handed to >>> the shell!) >>> >>> I copied the mustang's successful build tree to the juno, and the >>> juno's unsuccessful build tree to the mustang. >>> >>> On the mustang, with either tree, the command I quoted early nearly >>> always runs in less than 10 seconds and works. However - and this is >>> interesting - I did see it fail on one occasion in a very similar way >>> to how it fails on the juno. >>> >>> On the juno, with either tree, the command usually fails, but >>> sometimes works, and, I happened to notice, it worked a lot more >>> frequently while I was copying the other build tree across. Sometimes >>> it runs for more than an hour. I've never seen it run for less than >>> 2.5 minutes, but in that particular case it succeeded in 2.5 minutes. >>> >>> You can make the command run successfully on the juno, in just 40 s, >>> every time I tried it, by the simple device of using taskset 0x10 >>> (making the program use just one core). >>> >>> So it appears to be a threading/lock issue. I would guess that either >>> the program is using the wrong kind of threading/lock primitive, or >>> the threading/locking is broken. >>> >>> This is definitely worth investigating. It could be that the issue >>> that is causing the openjdk-7 build to fail almost every time is also >>> causing intermittent problems with other programs. >>> >>> Can you pass this news onto anyone who might be interested? >>> >>> Edmund >>> >>> ----- End forwarded message ----- >>> Wookey >>> -- >>> Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM >>> http://wookware.org/ >>> >> >> ----- End forwarded message ----- >> Wookey >> > > ----- End forwarded message ----- Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
