|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] pvops: AHCI problems with SB600
On 09/23/09 12:32, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 23, 2009 at 12:22:32PM -0700, Jeremy Fitzhardinge wrote:
>
>> On 09/23/09 05:06, Konrad Rzeszutek Wilk wrote:
>>
>>> I've gotten my hands on machine with SB700 and it exhibits similar
>>> problems. The
>>> SB700 AHCI controller stops working if I have more than 4GB in the machine.
>>>
>>>
>> You mean just with this kernel? I presume it works OK normally.
>>
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1514
> has the details.
>
> It looks that the calls to ioremap_nocache return an address
> that is not synchronized with the physical address.
>
Synchronized in what sense? ioremap_* is all common code, so I would
expect it to fail or not fail. I guess the possibilities are that that
the physaddr is getting truncated to 32-bits somewhere, or _PAGE_PCD is
getting masked out (either from __supported_pte_flags, or elsewhere in
the process).
But you mention in the bug that the appears to be problems with the AGP
aperture. Do you get the "Aperture pointing to e820 RAM. Ignoring"
message when booting native?
We use the real BIOS-provided e820 map and then trim it according to the
provided memory size, so there should always be the same holes in the
E820 map that BIOS provides.
arch/x86/kernel/aperture_64.c has the test:
if (!no_iommu &&
max_pfn > MAX_DMA32_PFN &&
!printed_gart_size_msg) {
printk(KERN_ERR "you are using iommu with agp, but GART
size is less than 64M\n");
printk(KERN_ERR "please increase GART size in your BIOS
setup\n");
printk(KERN_ERR "if BIOS doesn't have that option,
contact your HW vendor!\n");
printed_gart_size_msg = 1;
}
I guess the "!no_iommu" clause is triggering because we have swiotlb
set, but I wonder if that's specifically testing for the presence of a
GART IOMMU?
How does ioremap_nocache fit into this? Is the mapping failing in some
way and causing this code to fail? Or am I misunderstanding?
> This is exhibited only when dom0 has more than 4GB, so if you do
> dom_mem=max:4GB
> the machine boots succesfully.
>
The test above also tests "max_pfn > MAX_DMA32_PFN" which limiting
memory would avoid.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] pvops: AHCI problems with SB600, (continued)
- [Xen-devel] pvops: AHCI problems with SB600, Patrick Scharrenberg
- Re: [Xen-devel] pvops: AHCI problems with SB600, Patrick Scharrenberg
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600, Jeremy Fitzhardinge
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600,
Jeremy Fitzhardinge <=
- Re: [Xen-devel] pvops: AHCI problems with SB600, Jeremy Fitzhardinge
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600, Jeremy Fitzhardinge
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600, Jeremy Fitzhardinge
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600, Patrick Scharrenberg
Re: [Xen-devel] Announcing xen/master: pvops git trees rearranged (AMD tests?), Konrad Rzeszutek Wilk
Re: [Xen-devel] Announcing xen/master: pvops git trees rearranged, Pasi Kärkkäinen
|
|
|
|
|