Re: Reverting 5d423 fixes loading of ath9k on Acer Extensa 7630EZ
Linus Torvalds
On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
>
> Can you please consider reviewing this issue and help determine if
> this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>
> I am curious if other devices would work by reverting this as well.
> [ ... ] For details please feel free to check:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=14402
That same commit was the cause for
http://bugzilla.kernel.org/show_bug.cgi?id=13940
and we just increased the rounding to make it go away (see commit
15b812f1). But that was a hack.
And if that didn't help the ath9k case, then we should just revert
entirely.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Luis R. Rodriguez
> Luis R. Rodriguez wrote:
>> On Wed, Nov 4, 2009 at 3:57 PM, Linus Torvalds
>> <torv...@linux-foundation.org> wrote:
>>>
>>> On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
>>>> Can you please consider reviewing this issue and help determine if
>>>> this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>>>>
>>>> I am curious if other devices would work by reverting this as well.
>>>> [ ... ] For details please feel free to check:
>>>>
>>>> http://bugzilla.kernel.org/show_bug.cgi?id=14402
>>> That same commit was the cause for
>>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>>>
>>> and we just increased the rounding to make it go away (see commit
>>> 15b812f1). But that was a hack.
>>>
>>> And if that didn't help the ath9k case, then we should just revert
>>> entirely.
>>
>> report back.
>
> can you post whole boot log with debug?
You can find the logs without 15b812f1 on the bug report. I'll poke
Bernhard to poke logs with 15b812f1 applied.
Luis
Luis R. Rodriguez
reverting the commit 5d423, titled "x86/pci: remove rounding quirk
from e820_setup_gap()" fixes loading of ath9k on an Acer Extensa
7630EZ. We've troubleshooted the issue with the user, Bernhard, who
eventually did a full bisect between 2.6.30 and 2.6.31 and found 5d423
was the culprit. For details please feel free to check:
http://bugzilla.kernel.org/show_bug.cgi?id=14402
Can you please consider reviewing this issue and help determine if
this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
I am curious if other devices would work by reverting this as well.
Luis
Ingo Molnar
* Linus Torvalds <torv...@linux-foundation.org> wrote:
> On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
> >
> > Can you please consider reviewing this issue and help determine if
> > this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
> >
> > I am curious if other devices would work by reverting this as well.
> > [ ... ] For details please feel free to check:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=14402
>
> That same commit was the cause for
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>
> and we just increased the rounding to make it go away (see commit
> 15b812f1). But that was a hack.
>
> And if that didn't help the ath9k case, then we should just revert
> entirely.
Agreed - below is the combo 15b812f1 + 5d423ccd revert. (Would be nice
to get the boot log of the latest post-15b812f1 kernel that Yinghai
asked for before we revert, in the hope of better understanding the
problem.)
Thanks,
Ingo
Signed-off-by: Ingo Molnar <mi...@elte.hu>
---
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index d17d482..b322e30 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -617,7 +617,7 @@ __init int e820_search_gap(unsigned long *gapstart, unsigned long *gapsize,
*/
__init void e820_setup_gap(void)
{
- unsigned long gapstart, gapsize;
+ unsigned long gapstart, gapsize, round;
int found;
gapstart = 0x10000000;
@@ -634,9 +634,14 @@ __init void e820_setup_gap(void)
#endif
/*
- * e820_reserve_resources_late protect stolen RAM already
+ * See how much we want to round up: start off with
+ * rounding to the next 1MB area.
*/
- pci_mem_start = gapstart;
+ round = 0x100000;
+ while ((gapsize >> 4) > round)
+ round += round;
+ /* Fun with two's complement */
+ pci_mem_start = (gapstart + round) & -round;
printk(KERN_INFO
"Allocating PCI resources starting at %lx (gap: %lx:%lx)\n",
@@ -1378,8 +1383,8 @@ static unsigned long ram_alignment(resource_size_t pos)
if (mb < 16)
return 1024*1024;
- /* To 64MB for anything above that */
- return 64*1024*1024;
+ /* To 32MB for anything above that */
+ return 32*1024*1024;
}
#define MAX_RESOURCE_SIZE ((resource_size_t)-1)
Luis R. Rodriguez
>>
>> Can you please consider reviewing this issue and help determine if
>> this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>>
>> I am curious if other devices would work by reverting this as well.
>> [ ... ] For details please feel free to check:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=14402
>
> That same commit was the cause for
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>
> and we just increased the rounding to make it go away (see commit
> 15b812f1). But that was a hack.
>
> And if that didn't help the ath9k case, then we should just revert
> entirely.
Alright, will see if Bernhard is up for testing the 15b812f1 hack and
report back.
Luis
Yinghai Lu
> On Wed, Nov 4, 2009 at 3:57 PM, Linus Torvalds
> <torv...@linux-foundation.org> wrote:
>>
>> On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
>>> Can you please consider reviewing this issue and help determine if
>>> this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>>>
>>> I am curious if other devices would work by reverting this as well.
>>> [ ... ] For details please feel free to check:
>>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=14402
>> That same commit was the cause for
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>>
>> and we just increased the rounding to make it go away (see commit
>> 15b812f1). But that was a hack.
>>
>> And if that didn't help the ath9k case, then we should just revert
>> entirely.
>
> Alright, will see if Bernhard is up for testing the 15b812f1 hack and
> report back.
can you post whole boot log with debug?
YH
Luis R. Rodriguez
>
> * Linus Torvalds <torv...@linux-foundation.org> wrote:
>
>> On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
>> >
>> > Can you please consider reviewing this issue and help determine if
>> > this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>> >
>> > I am curious if other devices would work by reverting this as well.
>> > [ ... ] For details please feel free to check:
>> >
>> > http://bugzilla.kernel.org/show_bug.cgi?id=14402
>>
>> That same commit was the cause for
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>>
>> and we just increased the rounding to make it go away (see commit
>> 15b812f1). But that was a hack.
>>
>> And if that didn't help the ath9k case, then we should just revert
>> entirely.
>
> Agreed - below is the combo 15b812f1 + 5d423ccd revert. (Would be nice
> to get the boot log of the latest post-15b812f1 kernel that Yinghai
> asked for before we revert, in the hope of better understanding the
> problem.)
Bernhard has confirmed the new patch fixes this issue.
Luis
Ingo Molnar
* Luis R. Rodriguez <mcg...@gmail.com> wrote:
> On Wed, Nov 4, 2009 at 11:14 PM, Ingo Molnar <mi...@elte.hu> wrote:
> >
> > * Linus Torvalds <torv...@linux-foundation.org> wrote:
> >
> >> On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
> >> >
> >> > Can you please consider reviewing this issue and help determine if
> >> > this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
> >> >
> >> > I am curious if other devices would work by reverting this as well.
> >> > [ ... ] For details please feel free to check:
> >> >
> >> > http://bugzilla.kernel.org/show_bug.cgi?id=14402
> >>
> >> That same commit was the cause for
> >>
> >> ?? ?? ?? http://bugzilla.kernel.org/show_bug.cgi?id=13940
> >>
> >> and we just increased the rounding to make it go away (see commit
> >> 15b812f1). But that was a hack.
> >>
> >> And if that didn't help the ath9k case, then we should just revert
> >> entirely.
> >
> > Agreed - below is the combo 15b812f1 + 5d423ccd revert. (Would be nice
> > to get the boot log of the latest post-15b812f1 kernel that Yinghai
> > asked for before we revert, in the hope of better understanding the
> > problem.)
>
> Bernhard has confirmed the new patch fixes this issue.
Good - so latest kernels should be fine (on Bernhard's box) and no
change is needed, right?
Ingo
Luis R. Rodriguez
>
> * Luis R. Rodriguez <mcg...@gmail.com> wrote:
>
>> On Wed, Nov 4, 2009 at 11:14 PM, Ingo Molnar <mi...@elte.hu> wrote:
>> >
>> > * Linus Torvalds <torv...@linux-foundation.org> wrote:
>> >
>> >> On Wed, 4 Nov 2009, Luis R. Rodriguez wrote:
>> >> >
>> >> > Can you please consider reviewing this issue and help determine if
>> >> > this indeed needs to be reverted for 2.6.32 and the next 2.6.31.y.
>> >> >
>> >> > I am curious if other devices would work by reverting this as well.
>> >> > [ ... ] For details please feel free to check:
>> >> >
>> >> > http://bugzilla.kernel.org/show_bug.cgi?id=14402
>> >>
>> >> That same commit was the cause for
>> >>
>> >> ?? ?? ?? http://bugzilla.kernel.org/show_bug.cgi?id=13940
>> >>
>> >> and we just increased the rounding to make it go away (see commit
>> >> 15b812f1). But that was a hack.
>> >>
>> >> And if that didn't help the ath9k case, then we should just revert
>> >> entirely.
>> >
>> > Agreed - below is the combo 15b812f1 + 5d423ccd revert. (Would be nice
>> > to get the boot log of the latest post-15b812f1 kernel that Yinghai
>> > asked for before we revert, in the hope of better understanding the
>> > problem.)
>>
>> Bernhard has confirmed the new patch fixes this issue.
>
> Good - so latest kernels should be fine (on Bernhard's box) and no
> change is needed, right?
Yea, but it does mean we need a fix propagated down to older kernels.
Luis
Luis R. Rodriguez
Greg, please consider applying 15b812f1d0 to stable 2.6.31 as it fixes
an issue introduced on 2.6.31 and only fixed now for 2.6.32. This
should fix an issue when loading either sky2 or ath9k on some specific
platforms.
The details for the ath9k debugging are available on this bug:
http://bugzilla.kernel.org/show_bug.cgi?id=14402
Luis R. Rodriguez
Just noticed this did make it to 2.6.31.6, sorry for the noise and thanks.