Problems with alpha/pci + radeon/ttm
in [Kernel]
|
Prev: Hyperv: Export the symbol that tracks hyperv features and recommendations
Next: [RELEASE] LTTng 0.218 for kernel 2.6.34
From: Michael Cree on 28 Jun 2010 05:10 On 28/06/10 11:14, Dave Airlie wrote: > The bus error is caused by the kernel, its something alpha specific > with how mmap works, > I'm not sure if alpha needs some special mmap flags or something, Neither am I. All I know is that Alpha reorders CPU instructions more aggressively than most other architectures, the page map size is 8kB, and memory accesses must be aligned to the datum size. Maybe Ivan or Richard can comment on any relevant Alpha mmap specific issues. BTW, I discovered a couple of weeks ago that DRI is broken under UMS. It was working a year or so ago so something has happened to it. Am I correct in thinking that the DRM code has pretty much been shifted into the kernel even for UMS? On the Alpha I have been testing on (PWS600au, EV56 cpu and a radeon RV710 graphics card) running glxgears under UMS displays artefacts in rendering the gears, that is, some facets are not clipped to the rotating gear but extend to the edge of the window. On another Alpha (XP1000, EV67 cpu and a radeon RV610 card) it locked up completely (couldn't even ping it) when I ran glxgears. They are both running Debian unstable. Cheers Michael. -- 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: Richard Henderson on 28 Jun 2010 12:40 On 06/28/2010 02:03 AM, Michael Cree wrote: > On 28/06/10 11:14, Dave Airlie wrote: >> The bus error is caused by the kernel, its something alpha specific >> with how mmap works, >> I'm not sure if alpha needs some special mmap flags or something, > > Neither am I. All I know is that Alpha reorders CPU instructions more > aggressively than most other architectures, the page map size is 8kB, > and memory accesses must be aligned to the datum size. There are no special mmap flags on alpha. The non-cacheable property is a function of the physical address (e.g. bit 40 set for ev5), and this has already been taken care of by the kernel. r~ -- 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: Konrad Rzeszutek Wilk on 30 Jun 2010 14:50
On Sun, Jun 27, 2010 at 12:58:07AM -0400, Matt Turner wrote: > On Sun, Jun 27, 2010 at 12:20 AM, FUJITA Tomonori > <fujita.tomonori(a)lab.ntt.co.jp> wrote: > > On Thu, 24 Jun 2010 10:53:52 -0400 > > Matt Turner <mattst88(a)gmail.com> wrote: > > > >> > Seems that the IOMMU can't find 128 pages. It's likely due to: > >> > > >> > - out of the IOMMU space (possibly someone doesn't free the IOMMU > >> > �space). > >> > > >> > or > >> > > >> > - the mapping parameters (such as align) aren't appropriate so the > >> > �IOMMU can't find space. > >> > > >> > > >> >> Is this the cause of the bug we're seeing in the report [1]? For the fun I did: cat /tmp/screenlog.0 | grep iommu_arena | wc 28509 199588 2167164 Which is to say 28509 * 4096 = 116736000. That looks to be about 111MB. That does not look right when you are trying to allocate 128 pages. You are sure it is 128 pages? Can you make the ttm_ code print out the total of pages it is trying to PCI map ? It might also be interesting to see how many pages the pci_iommu.c has already set aside for other devices. The BAR is 128MB, but that would have been an ioremap call - and done much earlier I think. -- 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/ |