Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/offswitch out of staging."

[Jerome Glisse]

On Tue, Feb 02, 2010 at 04:42:21PM +0100, Ingo Molnar wrote:
> 
> * Jerome Glisse <glisse@xxxxxxxxxxxxxxx> wrote:
> 
> > On Tue, Feb 02, 2010 at 09:17:27AM +0100, Ingo Molnar wrote:
> > > 
> > > * Dave Airlie <airlied@xxxxxxxx> wrote:
> > > 
> > > > > Hi Linus,
> > > > > 
> > > > > Please pull the 'drm-linus' branch from
> > > > > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> > > > > 
> > > > 
> > > > I've also added an oops fix I seem to lose off my radar to this tree.
> > > > 
> > > > commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> > > > Author: Michel D??nzer <daenzer@xxxxxxxxxx>
> > > > Date:   Fri Jan 22 09:20:00 2010 +0100
> > > > 
> > > >     drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
> > > 
> > > FYI, this drm pull into mainline has triggered quick boot crashes in -tip 
> > > testing (even with the above fix applied), on an Athlon64 whitebox PC with:
> > > 
> > >  01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
> > >  01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
> > > 
> > > the crash is:
> > > 
> > > [    7.111003] radeon 0000:01:00.0: Disabling GPU acceleration
> > > [    7.273547] Failed to wait GUI idle while programming pipes. Bad things might happen.
> > > [    7.436296] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
> > > [    7.598755] Failed to wait GUI idle while programming pipes. Bad things might happen.
> > > [    7.599306] BUG: unable to handle kernel paging request at f8380000
> > > [    7.599999] IP: [<c149f0de>] rv370_pcie_gart_set_page+0x2d/0x3c
> > > [    7.599999] *pde = 36d44067 *pte = 00000000
> > > [    7.599999] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
> > > [    7.599999] last sysfs file:
> > > 
> > > i have bisected it back to:
> > > 
> > >  | 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0 is the first bad commit
> > >  | commit 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0
> > >  | Author: Dave Airlie <airlied@xxxxxxxxxx>
> > >  | Date:   Fri Jan 29 15:31:47 2010 +1000
> > >  |
> > >  |     drm/radeon/kms: fix incorrect logic in DP vs eDP connector checking.
> > >  |    
> > >  |     This makes displayport work again here.
> > > 
> > > Unfortunately even with that patch reverted it still crashes. Config and 
> > > bootlog attached.
> > > 
> > > It's the moving of radeom KMS out of staging after -rc6 that causes it, 
> > > because it brought it into the scope of my testing:
> > > 
> > >  f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
> > > 
> > > So at least on this box it's clearly not ready for mainline enablement yet. 
> > > I've attached the revert patch further below.
> > > 
> > > 	Ingo
> > > 
> > 
> > Attached is a patch which will fix the oops, still it's strange that CP 
> > fails to init on your config. [...]
> 
> Thanks, that fixes the crash here!
> 
> Tested-by: Ingo Molnar <mingo@xxxxxxx>
> 
> > [...] Do you have IOMMU enabled ? I haven't played with iommu stuff thus i 
> > wonder if we are missing somethings in this area.
> 
> No IOMMU here - this is a 5 years old box. (beyond GART that is)
> 
> Your patch fixes a bona-fide illegal-access bug in the DRM code, that's more 
> than enough to crash the box ;-)
> 
> Btw., there's a new warning in the DRM code
> 
>  drivers/gpu/drm/ati_pcigart.c: In function âdrm_ati_pcigart_initâ:
>  drivers/gpu/drm/ati_pcigart.c:115: warning: format â%Lxâ expects type âlong long unsigned intâ, but argument 3 has type âdma_addr_tâ
> 
> Please fix that too, the kernel build is noisy enough as-is.
> 
> Thanks,
> 
> 	Ingo

I think i saw a patch for this, it's often a nice thing to let people do their first
patch on this kind of thing, but i try to fix such thing when i run into it, thought
i haven't always been a well behaving kid in the % format area.

Cheers,
Jerome
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/