From: "Måns Rullgård" <mans@mansr.com>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
Guenter Roeck <linux@roeck-us.net>,
Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>,
Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
Haavard Skinnemoen <hskinnemoen@gmail.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: avr32 build failures in linux-next
Date: Thu, 10 Mar 2016 14:31:43 +0000 [thread overview]
Message-ID: <yw1xegbi4d68.fsf@unicorn.mansr.com> (raw)
In-Reply-To: <20160310142938.7e765a95@lxorguk.ukuu.org.uk> (One Thousand Gnomes's message of "Thu, 10 Mar 2016 14:29:38 +0000")
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> writes:
> On Wed, 9 Mar 2016 21:30:55 +0200
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@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 <mans@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
next prev parent reply other threads:[~2016-03-10 14:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 16:02 avr32 build failures in linux-next Guenter Roeck
2016-02-05 16:32 ` Sudip Mukherjee
2016-02-06 11:57 ` Hans-Christian Noren Egtvedt
2016-02-06 14:01 ` Måns Rullgård
2016-02-06 16:19 ` Guenter Roeck
2016-02-06 17:28 ` Måns Rullgård
2016-02-08 16:06 ` Andy Shevchenko
2016-02-09 4:02 ` Guenter Roeck
2016-03-09 19:30 ` Andy Shevchenko
2016-03-09 19:50 ` Måns Rullgård
2016-03-10 4:55 ` Sudip Mukherjee
2016-03-10 13:38 ` Måns Rullgård
2016-03-10 13:53 ` Andy Shevchenko
2016-03-10 14:24 ` Måns Rullgård
2016-03-10 14:29 ` One Thousand Gnomes
2016-03-10 14:31 ` Måns Rullgård [this message]
2016-03-10 15:10 ` Andy Shevchenko
2016-02-06 15:50 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yw1xegbi4d68.fsf@unicorn.mansr.com \
--to=mans@mansr.com \
--cc=andy.shevchenko@gmail.com \
--cc=egtvedt@samfundet.no \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=hskinnemoen@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=sudipm.mukherjee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox