On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <[email protected]> wrote:
> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>
>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <[email protected]> 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.
--
With Best Regards,
Andy Shevchenko
Andy Shevchenko <[email protected]> writes:
> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <[email protected]> wrote:
>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>
>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <[email protected]> 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.
I'd like to try fixing it before we delete anything. At the very least,
it's always a good idea to figure out exactly why it broke, just to be
sure it isn't a broader issue that has yet to manifest itself elsewhere.
--
Måns Rullgård
On Thursday 10 March 2016 01:20 AM, Måns Rullgård wrote:
> Andy Shevchenko <[email protected]> writes:
>
>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <[email protected]> wrote:
>>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>>
>>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <[email protected]> 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.
>
> I'd like to try fixing it before we delete anything. At the very least,
> it's always a good idea to figure out exactly why it broke, just to be
> sure it isn't a broader issue that has yet to manifest itself elsewhere.
>
I will suggest keeping it for one more cycle and see if it can be fixed.
regards
sudip
Andy Shevchenko <[email protected]> writes:
> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <[email protected]> wrote:
>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>
>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <[email protected]> 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.
The error goes away if CONFIG_AIO_THREAD is disabled. Still don't know why.
--
Måns Rullgård
On Thu, Mar 10, 2016 at 3:38 PM, Måns Rullgård <[email protected]> wrote:
> Andy Shevchenko <[email protected]> writes:
>
>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <[email protected]> wrote:
>>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>>
>>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <[email protected]> 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.
>
> The error goes away if CONFIG_AIO_THREAD is disabled. Still don't know why.
A straight guess: it has reduced enough room to fit the relocation window?
Anyway confirm that after disabling that kernel builds as usual.
--
With Best Regards,
Andy Shevchenko
Andy Shevchenko <[email protected]> writes:
> On Thu, Mar 10, 2016 at 3:38 PM, Måns Rullgård <[email protected]> wrote:
>> Andy Shevchenko <[email protected]> writes:
>>
>>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <[email protected]> wrote:
>>>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>>>
>>>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <[email protected]> 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.
>>
>> The error goes away if CONFIG_AIO_THREAD is disabled. Still don't know why.
>
> A straight guess: it has reduced enough room to fit the relocation window?
That was my first guess as well, but it was wrong. See the patch I just
sent for an explanation.
--
Måns Rullgård
On Wed, 9 Mar 2016 21:30:55 +0200
Andy Shevchenko <[email protected]> wrote:
> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <[email protected]> wrote:
> > On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
> >>
> >> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <[email protected]> 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).
Could also be a linker bug (AVR32 has a few) or the toolchain writing
crap (check the .S file)
Unfortunately I don't believe the AVR32 binutils is bright enough to fix
up such relocations with a more locally inserted branch to set up a
branch to a 32bit target (which is not pretty). Reordering the link might
help if it happens to move the problem routines nearer each other but
it's not a real fix.
Alan
One Thousand Gnomes <[email protected]> writes:
> On Wed, 9 Mar 2016 21:30:55 +0200
> Andy Shevchenko <[email protected]> wrote:
>
>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <[email protected]> wrote:
>> > On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>> >>
>> >> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <[email protected]> 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
On Thu, Mar 10, 2016 at 4:31 PM, Måns Rullgård <[email protected]> wrote:
> It turned out to be a wrong asm operand constraint in cmpxchg(). Patch
> already sent.
I will temporary apply it to my tree [1] as well.
By the way, I have updated (were one bug in my newly introduced fix)
and tested the series on Intel with UART, PPC with SATA, and AVR32
with plain dmatest. So far so good.
[1] https://bitbucket.org/andy-shev/linux/branch/topic%2Fdw%2Fsata
--
With Best Regards,
Andy Shevchenko