Ximin Luo <infini...@debian.org> 于2018年9月27日周四 下午12:06写道： > > Ximin Luo: > > Do you have a link to a more detailed description of the problem, so that > > the rest of us can understand it? > > > > For example James in message 29 gave a very detailed summary of other > > previous problems: > > > > [29] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881845#29 > > > > Nobody in this thread has stated what the supposed problem actually is with > > these Cavium/Octeon machines. FYI the builds failed recently on eberlin and > > manda-03, and has failed in the past on aql-01. These are all octeon, and > > the other mips64el buildd sil-01 is also octeon. So it seems all our > > buildds are affected by the bug. So the blacklist approach won't even work. > > > > Oh I take that back, it seems aql-01 and manda-01,02 are not octeon, I had > previously assumed all the x-{01..03} machines would be the same. > > Still, please give us a link to the description of the problem.
I cannot remember clear. It seems that no branch instruction can be in ll/sc pair on Octeon, while llvm does generate code like this. Loongson has no this problem. anyway, we should patch llvm. > > X > > > Also unless I can understand the problem, I don't feel happy using the > > blacklist as a temporary solution, even if it was going to work. > > > > X > > > > YunQiang Su: > >> It is still about llvm+octeon problem. > >> > >> Maybe we can ask pin rustc on Loongson machines. > >> Ximin Luo <infini...@debian.org> 于2018年9月24日周一 上午2:21写道： > >>> > >>> Aron Xu: > >>>> [..] > >>>>> > >>>>> Aron, the next version 1.27.1 is already in binary-NEW so the same > >>>>> issue will block testing migration again, when that gets accepted. > >>>>> > >>>>> Earlier you said "Binary only upload from porter is allowed [..]" but I > >>>>> am not sure the other porters have access to a loongson-3a box. Will > >>>>> you continue to run builds of new rustc versions on your box? I think > >>>>> that is the key point here. > >>>>> > >>>> > >>>> Will do that and see if we can get the issue either fixed or have a > >>>> blacklist placed at the same time. > >>>> > >>> > >>> I have just uploaded 1.29.0 to unstable. It will need manual building > >>> with a non-buggy mips machine, to unblock us for Debian Testing. The > >>> previous build 1.29.0+dfsg1-1~exp1 failed due to hanging atomic tests: > >>> > >>> https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=mips64el&ver=1.29.0%2Bdfsg1-1%7Eexp1&stamp=1537686627&raw=0 > >>> > >>> test sync.rs - sync::Arc (line 124) ... test sync.rs - sync::Arc (line > >>> 124) has been running for over 60 seconds > >>> test sync.rs - sync::Arc<T>::downgrade (line 418) ... test sync.rs - > >>> sync::Arc<T>::downgrade (line 418) has been running for over 60 seconds > >>> test sync.rs - sync::Arc<T>::get_mut (line 856) ... test sync.rs - > >>> sync::Arc<T>::get_mut (line 856) has been running for over 60 seconds > >>> test sync.rs - sync::Arc<T>::make_mut (line 769) ... test sync.rs - > >>> sync::Arc<T>::make_mut (line 769) has been running for over 60 seconds > >>> E: Build killed with signal TERM after 150 minutes of inactivity > >>> > >>> I still think we should just RM rustc on mips64el. > >>> > >>> X > >>> > >>> -- > >>> GPG: ed25519/56034877E1F87C35 > >>> GPG: rsa4096/1318EFAC5FBBDBCE > >>> https://github.com/infinity0/pubkeys.git > >>> > >> > >> > > > > > > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git -- YunQiang Su
