On 29.03.2017 11:36, Michel Dänzer wrote: > On 29/03/17 06:07 PM, Christian König wrote: >> Am 29.03.2017 um 10:59 schrieb Michel Dänzer: >>> On 28/03/17 08:00 PM, Julien Isorce wrote: >>>> On 28 March 2017 at 10:36, Michel Dänzer <michel at daenzer.net >>>> <mailto:michel at daenzer.net>> wrote: >>>> >>>> On 28/03/17 05:24 PM, Julien Isorce wrote: >>>> > Hi Michel, >>>> > >>>> > About the hard lockup, I noticed that I cannot have it with the >>>> > following conditions: >>>> > >>>> > 1. soft lockup fix (the 0->i change which avoids infinite loop) >>>> > 2. Your suggestion: (!(rbo->flags & RADEON_GEM_CPU_ACCESS) >>>> > 3. radeon.gartsize=512 radeon.vramlimit=1024 (any other values >>>> above do >>>> > not help, for example (1024, 1024) or (1024, 2048)) >>>> > >>>> > Without 1 and 2, but with 3, our test reproduces the soft >>>> lockup (just >>>> > discovered few days ago). >>>> > Without 3 (and with or without 1., 2.), our test reproduces >>>> the hard >>>> > lockup which one does not give any info in kern.log (sometimes >>>> some NUL >>>> > ^@ characters but not always). >>>> >>>> What exactly does "hard lockup" mean? What are the symptoms? >>>> >>>> >>>> Screens are frozen, cannot ssh, no mouse/keyboard, no kernel panic. >>>> Requires hard reboot. >>>> After reboot, nothing in /var/crash, nothing in /sys/fs/pstore, nothing >>>> in kern.log except sometimes some nul characters ^@. >>> Does it still respond to ping when it's hung? >>> >>> >>>> Using a serial console did not show additional debug messages. kgdb was >>>> not useful but probably worth another attempt. >>> Right. >>> >>> Anyway, I'm afraid it sounds like it's probably not directly related to >>> the issue I was thinking of for my previous test patch or other similar >>> ones I was thinking of writing. >> >> Yeah, agree. >> >> Additional to that a complete crash where you don't even get anything >> over serial console is rather unlikely to be cause by something an >> application can do directly. >> >> Possible causes are more likely power management or completely messing >> up a bus system. Have you tried disabling dpm as well? > > Might also be worth trying the amdgpu kernel driver instead of radeon, > not sure how well the former currently works with Cape Verde though. I've recently used it to experiment with the sparse buffer support. It worked well enough for that :) Cheers, Nicolai -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte.
