> > (BTW, just what kernel version were you using for those patches? The
> > v2.6.27-rcX series place the patch's changes over 100 lines earlier
> > than the line numbers indicated in your patches....)
>
> we are working on tip/master
My mistake... sorry. Previously, Ingo had me doing things with tip/master,
but usually you had me working with v2.6.27-rc3. I should have tried
tip/master as soon as I saw the discrepancy.
I have some questions about what happens next:
- This fix will naturally make it into v2.6.27, maybe even as soon
as v2.6.27-rc5, correct?
- Is there any chance I can get it into the stable 2.6.26.X updates?
(Who should I ask, or are only developers allowed to lobby for this
sort of thing?)
- Are you worried about the potential problems of a quirk-based approach?
What if many more people experience a similar regression once 2.6.26 or
later appears in their distribution? I'm sure you don't want to have to
write a different quirk for each individual's hardware, and this problem
did not arise with the approach used for resource management in 2.6.25.
Thanks again Yinghai (and Ingo),
Dave W.
On Sat, Aug 23, 2008 at 7:39 PM, David Witbrodt <[email protected]> wrote:
>
>
>> > (BTW, just what kernel version were you using for those patches? The
>> > v2.6.27-rcX series place the patch's changes over 100 lines earlier
>> > than the line numbers indicated in your patches....)
>>
>> we are working on tip/master
>
> My mistake... sorry. Previously, Ingo had me doing things with tip/master,
> but usually you had me working with v2.6.27-rc3. I should have tried
> tip/master as soon as I saw the discrepancy.
>
>
> I have some questions about what happens next:
>
> - This fix will naturally make it into v2.6.27, maybe even as soon
> as v2.6.27-rc5, correct?
yes.
>
> - Is there any chance I can get it into the stable 2.6.26.X updates?
> (Who should I ask, or are only developers allowed to lobby for this
> sort of thing?)
after the patch get into linus tree. Greg will put the patch into 2.6.26.X
>
> - Are you worried about the potential problems of a quirk-based approach?
> What if many more people experience a similar regression once 2.6.26 or
> later appears in their distribution? I'm sure you don't want to have to
> write a different quirk for each individual's hardware, and this problem
> did not arise with the approach used for resource management in 2.6.25.
this patch should be safe.
2.6.26 is fixing one bug about reserving local apic address and that
in e820 table.
and it reveals one bios bug.
YH