From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Glisse Subject: Re: Linux 2.6.39-rc3 Date: Mon, 18 Apr 2011 11:59:25 -0400 Message-ID: References: <4DA655E7.3000904@zytor.com> <20110415131152.GJ18463@8bytes.org> <20110415131650.GB18660@elte.hu> <20110415154604.GN18463@8bytes.org> <20110416163509.GS18463@8bytes.org> <20110417140924.GU18463@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Alex Deucher Cc: Joerg Roedel , Yinghai Lu , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , "H. Peter Anvin" , Tejun Heo , Linus Torvalds , Thomas Gleixner , alexandre.f.demers@gmail.com List-Id: dri-devel@lists.freedesktop.org On Mon, Apr 18, 2011 at 11:33 AM, Alex Deucher = wrote: > On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse = wrote: >> On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher wrote: >>> On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wr= ote: >>>> On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: >>>> >>>>> If you want to go the printk way you can add printk before each t= est >>>>> ring_test, ib_test in r600.c this 2 functions are the own that mi= ght >>>>> trigger the first GPU gart activities. >>>> >>>> Okay, I found the place in source that triggers this. It happens i= n the >>>> function r600_ib_test. The interesting thing is that not the ib-co= mmand >>>> itself is responsible but the fence that is emitted afterwards (pr= oved >>>> by removing the fence command, where the problem went away). >>>> I don't know enough about the command semantics to make a guess wh= at >>>> goes wrong there. But maybe you GPU folks have an idea? >>>> >>> >>> I can't think of anything off hand. =A0It might be worth disabling = the >>> call to r600_ib_test() in r600_init() and then seeing if you get an= y >>> errors when the fences are used later on when X starts or just at t= hat >>> point in the module load sequence. =A0What's odd is that when you t= ested >>> radeon.no_wb=3D1 you got the same behavior as that disables shadowi= ng of >>> fence writes to gpu gart mem, so it wouldn't be writing to memory i= n >>> that case. >>> >>> Alex >>> >> >> It might be the irq ring write that is faulty. > > That's disabled with no_wb=3D1 as well. > > Alex > I mean the irq interrupt ring, i don't see this being disabled when no_= wb=3D1 Cheers, Jerome