[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SOLVED] Re: ARAnyM VMs with Debian hanging at 100% CPU usage


great work on pinning this bug down - and full kudos to Andreas for the fix.
Andreas Schwab dixit:

Obviously the syscall has never been tested on m68k.


Greg, can we get the above fix by Andreas into the stable series please?

Thorsten tried to send mail to stable@kernel.org but it got bounced - please advise if you're not a suitable point of contact for this kind of request.

We can always get it submitted through Geert's tree if that's easier.

Thanks, that fixes the problem. I’ve written an answer adding
my Tested-by and Cc'd stable@ as waldi suggested; if someone
here thinks that c663600584a596b5e66258cc10716fb781a5c2c9 also
should be added to stable, please do the same, I cannot judge

Since it does not appear to cause any real harm (presumaby nfeth still works after the message?), I'd leave it.
When duckduckgoïng for the problem and atomic stuff in general
I found <Pine.LNX.4.64.0711301901100.20112@digraph.polyomino.org.uk>
and wonder where __kernel_atomic_cmpxchg_32 is; should probably
be in libc? no vDSO, but it could still switch between doing the
trap or using CAS… and gcc should then use that?
It seems to say this really is not needed unless building glibc for use on both CF and classic m68k:
(On m68k - where
this kernel helper would only be used if glibc is built for the
intersection of ColdFire and m68k - this could be implemented with a
single cas instruction and a return.)
And I seem to recall we were not going to do anything like this, for performance reasons on both architectures.



Reply to: