One Thousand Gnomes <gno...@lxorguk.ukuu.org.uk> writes: > On Wed, 9 Mar 2016 21:30:55 +0200 > Andy Shevchenko <andy.shevche...@gmail.com> wrote: > >> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <li...@roeck-us.net> wrote: >> > On 02/08/2016 08:06 AM, Andy Shevchenko wrote: >> >> >> >> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <m...@mansr.com> wrote: >> >> >> >>> Not very surprising either. The number of people using Linux on avr32 >> >>> is probably approximately zero, and if anyone is, they're likely still >> >>> running 2.6.32 or thereabouts. >> >> >> >> >> >> Once I tried up the topic about removal avr32 for good, but looks like >> >> it wasn't a good time. Maybe now is better? It would really reduce a >> >> burden on many drivers. >> >> >> > I would agree, as long as the maintainers agree. We don't want to repeat >> > the h8300 experience. >> >> So, are we going to agree that avr32 must be retired from next cycle? >> >> P.S. I have no idea how to fix this "…relocation truncated to fit: >> R_AVR32_21S…", though I can test anything anyone propose. > > It means the AVR32 tool chain generated a 21bit signed code relocation > then couldn't fix it up at link time. This probably simply means that > something called through anon_inode_getfile() is now more than 1MB away > from the call location, in which case you'll just need to debloat the > kernel until it fits again or re-order the link to cure it (if I had to > guess it'll be some kind of support function call and the compiler > support tends to end up one end of the binary not in the middle).
It turned out to be a wrong asm operand constraint in cmpxchg(). Patch already sent. -- Måns Rullgård
