Prev: Ref Number 3XTA932CL9
Next: [tip:x86/urgent] x86-64: Clear a 64-bit FS/GS base on fork if selector is nonzero
From: H. Peter Anvin on 23 Apr 2010 19:50
On 04/23/2010 04:05 PM, Bjorn Helgaas wrote:
> On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
>> On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
>>> Update e820 at first, and later put them resource tree.
>>> Reserved that early, will not be allocated to unassigned PCI BAR
>>>
>>> v3: remove probe_roms() that is not needed, because whole range is reserved
>>> already
>>
>> Test booted this patch series on the problematic t3400, seems to work
>> fine. dmesg attached to bug 15744.
>
> Thanks for testing (again). I'm not confident that this series is
> going to be successful, so I started looking for other approaches.
>
> I can't reproduce the exact problem you're seeing, but in my
> kludged-up attempt, the patch below is enough to keep us from
> assigning the space below 1MB to a device.
>
> Would you guys (Andy & Andy, what a coincidence :-)) mind giving
> it a try? This is intended to work on top of current upstream,
> with no other patches required.
>

This certainly wins from a simplicity standpoint!

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 23 Apr 2010 20:40
On 04/23/2010 04:44 PM, H. Peter Anvin wrote:
> On 04/23/2010 04:05 PM, Bjorn Helgaas wrote:
>
>> On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
>>
>>> On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
>>>
>>>> Update e820 at first, and later put them resource tree.
>>>> Reserved that early, will not be allocated to unassigned PCI BAR
>>>>
>>>> v3: remove probe_roms() that is not needed, because whole range is reserved
>>>> already
>>>>
>>> Test booted this patch series on the problematic t3400, seems to work
>>> fine. dmesg attached to bug 15744.
>>>
>> Thanks for testing (again). I'm not confident that this series is
>> going to be successful, so I started looking for other approaches.
>>
>> I can't reproduce the exact problem you're seeing, but in my
>> kludged-up attempt, the patch below is enough to keep us from
>> assigning the space below 1MB to a device.
>>
>> Would you guys (Andy & Andy, what a coincidence :-)) mind giving
>> it a try? This is intended to work on top of current upstream,
>> with no other patches required.
>>
>>
> This certainly wins from a simplicity standpoint!
>
>
indeed.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: R. Andrew Bailey on 26 Apr 2010 09:10
On 23/04/10 17:05 -0600, Bjorn Helgaas wrote:
>On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
>> On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
>> > Update e820 at first, and later put them resource tree.
>> > Reserved that early, will not be allocated to unassigned PCI BAR
>> >
>> > v3: remove probe_roms() that is not needed, because whole range is reserved
>> > already
>>
>> Test booted this patch series on the problematic t3400, seems to work
>> fine. dmesg attached to bug 15744.
>
>Thanks for testing (again). I'm not confident that this series is
>going to be successful, so I started looking for other approaches.
>
>I can't reproduce the exact problem you're seeing, but in my
>kludged-up attempt, the patch below is enough to keep us from
>assigning the space below 1MB to a device.
>
>Would you guys (Andy & Andy, what a coincidence :-)) mind giving
>it a try? This is intended to work on top of current upstream,
>with no other patches required.
>
>Bjorn
>

Good news- that solved it. I tried Yinghai's patches saturday to no
avail (sorry it took me so long to get back to you, I was about 5 bios
revisions behind on this machine and wanted to update it before I
tried any more tests).

.andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Bjorn Helgaas on 26 Apr 2010 11:50
On Monday 26 April 2010 06:50:32 am R. Andrew Bailey wrote:
> On 23/04/10 17:05 -0600, Bjorn Helgaas wrote:
> >On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
> >Would you guys (Andy & Andy, what a coincidence :-)) mind giving
> >it a try? This is intended to work on top of current upstream,
> >with no other patches required.
> >
> Good news- that solved it. I tried Yinghai's patches saturday to no
> avail (sorry it took me so long to get back to you, I was about 5 bios
> revisions behind on this machine and wanted to update it before I
> tried any more tests).

Great, thanks for testing this! The only problem here is that we
changed two things at once -- the BIOS and the patch, and we need
to figure out which change fixed the problem.

I want Linux to work correctly even on the old BIOS, on the theory
that "if Windows works, Linux should work, too." Changing a BIOS
is relatively risky, and it's not something I want users to have to
diagnose and deal with.

If we're lucky, the kernel without the patch will still fail on the
updated BIOS. If the pre-patch kernel fails and the post-patch kernel
works, and you can attach the entire dmesg log of the post-patch kernel
to the bugzilla, we should be able to see Linux making more sensible
BAR assignments when working around the BIOS bug. Then we can be pretty
confident that my patch fixed the problem.

If the pre-patch kernel works on the updated BIOS, that means one of
the BIOS updates fixed the BIOS bug, and we didn't actually exercise
my patch at all. If that's the case, we'll have to wait for a report
from the other Andy. (Or you could temporarily down-grade your BIOS
to the original version you had. But I don't know whether that's even
possible... it probably depends on the BIOS update tools.)

Thanks again for all your help. All progress in Linux depends on early
adopters like you who are willing to test kernels and help work through
issues :-)

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Bjorn Helgaas on 26 Apr 2010 16:30
On Monday 26 April 2010 01:31:35 pm Jesse Barnes wrote:
> On Mon, 26 Apr 2010 11:34:36 -0700
> Andy Isaacson <adi(a)hexapodia.org> wrote:
> > On Fri, Apr 23, 2010 at 05:05:24PM -0600, Bjorn Helgaas wrote:

> > > commit 7fb707eb97fdf6dc4fa4b127f127f8d00223afc7
> > > Author: Bjorn Helgaas <bjorn.helgaas(a)hp.com>
> > > Date: Fri Apr 23 15:22:10 2010 -0600
> > >
> > > x86/PCI: never allocate PCI MMIO resources below BIOS_END
> > >
> > > When we move a PCI device or assign resources to a device not configured
> > > by the BIOS, we want to avoid the BIOS region below 1MB. Note that if the
> > > BIOS places devices below 1MB, we leave them there.
> >
> > Works for me. dmesg at
> > https://bugzilla.kernel.org/attachment.cgi?id=26150
>
> Great, thanks for testing. Applied this one to my for-linus tree.

Thanks!

> I still think Yinghai's patches should go in as well (marking regions as
> busy seems like good housekeeping), but with this fixed they're a better
> fit for -next.

I'm a little concerned that those patches are a sledgehammer approach.
Previously, IORESOURCE_BUSY has basically been used for mutual exclusion
between drivers that would otherwise claim the same resource. It hasn't
been used to guide resource assignment in the PCI/PNP/etc core. Maybe
it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure.
Right now it feels like undesirable overloading to me.

I think it also leads to at least one problem: Guenter's machine has no
VGA but has a PCI device that lives at 0xa0000. The driver for that
device won't be able to request that region if the arch code has marked
it busy.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: Ref Number 3XTA932CL9
Next: [tip:x86/urgent] x86-64: Clear a 64-bit FS/GS base on fork if selector is nonzero