lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 27 Feb 2013 15:20:31 -0500
From:	Josh Boyer <jwboyer@...il.com>
To:	Dave Airlie <airlied@...ux.ie>,
	Alex Deucher <alexander.deucher@....com>,
	Jerome Glisse <jglisse@...hat.com>
Cc:	torvalds@...ux-foundation.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] drm merge for 3.9-rc1

On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@...il.com> wrote:
> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@...ux.ie> wrote:
>> Alex Deucher (29):
>>       drm/radeon: halt engines before disabling MC (6xx/7xx)
>>       drm/radeon: halt engines before disabling MC (evergreen)
>>       drm/radeon: halt engines before disabling MC (cayman/TN)
>>       drm/radeon: halt engines before disabling MC (si)
>>       drm/radeon: use the reset mask to determine if rings are hung
>
> Something in this series of commits is causing the GPU to hang on reboot
> on my Dell XPS 8300 machine.  That has a:
>
> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
> ATI Caicos [Radeon HD 6450]
>
> card in it.  After reboots, I get a screen that looks like this:
>
> http://t.co/tPnT6xQZUK
>
> I can hit it fairly consistently after a few reboots, so I tried doing a
> git bisect on the radeon driver and it came down to:
>
> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit

So I don't think that's actually the cause of the problem.  Or at least
not that alone.  I reverted it on top of Linus' latest tree and I still
get the lockups.

Thus far I've reverted:

      drm/radeon: use status regs to determine what to reset (6xx/7xx)
      drm/radeon: use status regs to determine what to reset (evergreen)
      drm/radeon: use status regs to determine what to reset (cayman)
      drm/radeon: use status regs to determine what to reset (si)
      drm/radeon: halt engines before disabling MC (6xx/7xx)
      drm/radeon: halt engines before disabling MC (evergreen)
      drm/radeon: halt engines before disabling MC (cayman/TN)
      drm/radeon: halt engines before disabling MC (si)
      drm/radeon: use the reset mask to determine if rings are hung

and can still recreate the issue.  I'm starting to think the problem is
in one of:

      drm/radeon: rework GPU reset on r6xx/r7xx
      drm/radeon: rework GPU reset on evergreen
      drm/radeon: rework GPU reset on cayman/TN
      drm/radeon: rework GPU reset on cayman/TN (which should be si)

Still trying to figure out exactly which code paths are used on this
card, but I'll keep poking at it.  Any ideas or tips for debug are more
than welcome.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ