Csepp <raingl...@riseup.net> writes:
> Csepp <raingl...@riseup.net> writes: > >> Maxim Cournoyer <maxim.courno...@gmail.com> writes: >> >>> Hi! >>> >>> raingloom <raingl...@riseup.net> writes: >>> >>>> It's been at 67% on guix-packages-base for at least an hour now. The >>>> system itself is responsive and with the swap I gave it, it has more >>>> than enough memory. Htop shows three guile processes at the top of the >>>> list when sorted by CPU%, their states are S, D, D. >>>> Both CPUs are practically idling. >>>> This looks like some kind of lockup to me. >>>> >>>> Fresh install based on bare-bones example on a 32 bit netbook, but the >>>> install image used is the latest tagged version, since apparently there >>>> is no 32 bit option for edge. >>>> >>>> I also tried pulling using channel-with-substitutes, since I'm not too >>>> keen on locally building everything on such an old machine. Although >>>> Guix itself should frankly not take this long to build if we want to be >>>> competitive with other distros. Anyways, pulling with that in >>>> channels.scm gives a cert related error, so that's great, means old >>>> images can't easily be used for installation. >>> >>> Have you been able to reproduce this? If so, could you share the commit >>> you are starting from and the CPU architecture, so that we may hopefully >>> reproduce too? >>> >>> Thanks, >>> >>> Maxim >> >> CPU architecture is x86, commit it happened on last time is 347733b. >> Other possibly relevant factors: >> * spinning rust storage >> * 1GB RAM >> * encrypted BTRFS root >> * 4GB (encrypted) swap >> * 128MB zswap >> >> The last was not there when I originally submitted the bug. >> >> The swap is relevant because if it's a timing issue it's very possible >> some part of the code assumes reads are almost instant, which is not >> true with swap, and delaying a read might be exposing a race condition. > > Happening again. > pulled to: 8320c0c > pulled from: 4501a50 > > Same system. > > The system version is from november of last year due, because trying to > upgrade takes so damn long and often gets stuck on some package with no > substitute. > So... the situation is not great... The process status says sleep so it's probably hanging in a syscall? Maybe a kernel bug?