From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752532AbcCJObz (ORCPT ); Thu, 10 Mar 2016 09:31:55 -0500 Received: from unicorn.mansr.com ([81.2.72.234]:55628 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752455AbcCJObp (ORCPT ); Thu, 10 Mar 2016 09:31:45 -0500 From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: One Thousand Gnomes Cc: Andy Shevchenko , Guenter Roeck , Hans-Christian Noren Egtvedt , Sudip Mukherjee , Haavard Skinnemoen , "linux-kernel\@vger.kernel.org" Subject: Re: avr32 build failures in linux-next References: <56B4C799.5070401@roeck-us.net> <56B4CE8C.8040307@gmail.com> <20160206115722.GA32647@samfundet.no> <56B61D21.2010407@roeck-us.net> <56B964D9.8000300@roeck-us.net> <20160310142938.7e765a95@lxorguk.ukuu.org.uk> Date: Thu, 10 Mar 2016 14:31:43 +0000 In-Reply-To: <20160310142938.7e765a95@lxorguk.ukuu.org.uk> (One Thousand Gnomes's message of "Thu, 10 Mar 2016 14:29:38 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org One Thousand Gnomes writes: > On Wed, 9 Mar 2016 21:30:55 +0200 > Andy Shevchenko wrote: > >> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck wrote: >> > On 02/08/2016 08:06 AM, Andy Shevchenko wrote: >> >> >> >> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård 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