On Fri, Dec 21, 2012 at 10:14 AM, Stephan Seitz <stse+dri@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Dec 21, 2012 at 09:30:39AM -0500, Alex Deucher wrote: >> >> On Thu, Dec 20, 2012 at 5:09 AM, Stephan Seitz >> <stse+dri@xxxxxxxxxxxxxxxxxxx> wrote: >>> >>> filename: /lib/modules/3.7.0-Dom0/kernel/drivers/gpu/drm/radeon/radeon.ko >>> >>> hardware: >>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI >>> RV730XT [Radeon HD 4670] (prog-if 00 [VGA controller]) >>> Subsystem: Hightech Information System Ltd. Device 2003 >>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >>> ParErr- >>> Stepping- SERR- FastB2B- DisINTx- >>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >>> <TAbort- <MAbort- >SERR- <PERR- INTx- >>> Latency: 0, Cache Line Size: 32 bytes >>> Interrupt: pin A routed to IRQ 11 >>> Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M] >>> Region 2: Memory at e5000000 (64-bit, non-prefetchable) >>> [size=64K] >>> Region 4: I/O ports at b000 [size=256] >>> [virtual] Expansion ROM at e4000000 [disabled] [size=128K] >>> Capabilities: <access denied> >>> >>> 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI >>> Audio [Radeon HD 4000 series] >>> Subsystem: Hightech Information System Ltd. Device aa38 >>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >>> ParErr- >>> Stepping- SERR- FastB2B- DisINTx+ >>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >>> <TAbort- <MAbort- >SERR- <PERR- INTx- >>> Latency: 0, Cache Line Size: 32 bytes >>> Interrupt: pin B routed to IRQ 63 >>> Region 0: Memory at e5010000 (64-bit, non-prefetchable) >>> [size=16K] >>> Capabilities: <access denied> >>> Kernel driver in use: snd_hda_intel >>> >>> My system is debian testing with self-made kernels. The system is working >>> as >>> Dom0 under Xen 4.1. >>> >>> Since kernel 3.6 the drm radeon driver freezes the system after some >>> time. >>> This time can be 10 minutes or some hours. Since the system is completely >>> frozen I don’t know if there are error messages displayed, but the log >>> contains nothing. Simply pressing the reset switch won’t reset the >>> graphic >>> card (no output), I have to switch off the system to get the card working >>> again. >> >> >> Did you also change the userspace drivers (mesa, xf86-video-ati)? If > > > This system is a console system, X is only used sometimes. So while there > may be updates of other components (it is Debian testing after all) the > problem occurs in console mode without running X or mesa. > And rebooting the old 3.5 kernel solves the problem. > >> you only changed the kernel version, can you bisect? If you updated > > > Not without some help,. I’m no programmer. You probably mean I should test > different git commits? Git provides a a bisect option that allows you to track down when a problem was introduced. You'll need a copy of the kernel git tree. You can follow a tutorial like this one: http://www.landley.net/writing/git-bisect-howto.html git will bisect the tree picking commits for you to try. You basically build, install, and test the commit git bisect picks for you. If it works, you report it to get by saying 'git bisect good', if it's bad, you tell git by saying 'git bisect bad' after you report, git will pick another commit and you continue until the problematic commit has been identified. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
