Michel Dänzer wrote:
That does sound like the GPU locks up. Do you get any messages in dmesg
about lockups and attempts to reset the GPU at any time?
No.
Hmm, I guess the constant SIGALRMs might prevent the lockup detection
from kicking in... Maybe you can try starting the X server with
-dum
On Mit, 2011-04-13 at 14:27 +0200, Gabriel Paubert wrote:
> On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel Dänzer wrote:
> > On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> > > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote:
> > > > On Die, 2011-04-12 at 14:00 +0200,
On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel Dänzer wrote:
> On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote:
> > > On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > > > On Tue, Apr 12, 2011 at 01:46:10PM +
Hello Gabriel
On Wed, Apr 13, 2011 at 12:31:44PM +0200, Gabriel Paubert wrote:
> On Wed, Apr 13, 2011 at 10:59:14AM +0200, Andreas Schwab wrote:
> > Uwe Kleine-König writes:
> >
> > > $ git name-rev --refs=refs/tags/v2.6\*
> > > 69a07f0b117a40fcc1a479358d8e1f41793617f2
> > > 69a07f0b117a40fcc1a4
On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote:
> > On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > > On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> > > > >
> > > > > With no_wb=1 the driver
On Wed, Apr 13, 2011 at 10:59:14AM +0200, Andreas Schwab wrote:
> Uwe Kleine-König writes:
>
> > $ git name-rev --refs=refs/tags/v2.6\*
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2 tags/v2.6.39-rc2~3^2~43^2~4
> >
> > so it was introduced just before -
On Wed, Apr 13, 2011 at 06:16:13PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> >
> > Well, X is dead, or rather in an infinite ioctl loop as described
> > above.
> > IIRC, the display enters a power-down mode and there is nothing to
> > see.
>
Uwe Kleine-König writes:
> $ git name-rev --refs=refs/tags/v2.6\*
> 69a07f0b117a40fcc1a479358d8e1f41793617f2
> 69a07f0b117a40fcc1a479358d8e1f41793617f2 tags/v2.6.39-rc2~3^2~43^2~4
>
> so it was introduced just before -rc2.
$ git tag --contains 69a07f0b117a40fcc1a479358d8e1f41793617f2
v2.6.39-rc
On Wed, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
>
> Well, X is dead, or rather in an infinite ioctl loop as described
> above.
> IIRC, the display enters a power-down mode and there is nothing to
> see.
So basically the card crashed. There's about an infinite amount of
reasons why radeo
On Wed, Apr 13, 2011 at 10:02:04AM +0200, Gabriel Paubert wrote:
> On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> > BTW, if your kernel contains commit
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2, can you try if reverting that
> > helps?
>
> My kernel is pristine 2.6.38 and does
On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> BTW, if your kernel contains commit
> 69a07f0b117a40fcc1a479358d8e1f41793617f2, can you try if reverting that
> helps?
My kernel is pristine 2.6.38 and does not include this commit
(was introduced before 2.6.39-rc1 according to gitk)
On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote:
> On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> > > >
> > > > With no_wb=1 the driver goes a bit further but the X server ends
> > > > up in an infinite i
On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> > >
> > > With no_wb=1 the driver goes a bit further but the X server ends
> > > up in an infinite ioctl loop and the logs are:
> >
> > Which ioctl does it loop on? Please
On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> >
> > With no_wb=1 the driver goes a bit further but the X server ends
> > up in an infinite ioctl loop and the logs are:
>
> Which ioctl does it loop on? Please provide the Xorg.0.log file as well.
>From memory, the code was 0x64
On Die, 2011-04-12 at 13:30 +0200, Gabriel Paubert wrote:
>
> On Mon, Apr 11, 2011 at 05:32:43PM +0200, Michel Dänzer wrote:
> >
> > Have you ruled out any MSI related problems? I think the IRQ not working
> > could explain the symptoms...
>
> Booting with MSI disabled does not change anything.
Hi Micel,
On Mon, Apr 11, 2011 at 05:32:43PM +0200, Michel Dänzer wrote:
> [ Adding the dri-devel list ]
>
> Have you ruled out any MSI related problems? I think the IRQ not working
> could explain the symptoms...
Booting with MSI disabled does not change anything. Actually on this
machi
[ Adding the dri-devel list ]
On Mon, 2011-04-11 at 15:31 +0200, Gabriel Paubert wrote:
> On Thu, Apr 07, 2011 at 04:04:35PM +0200, Michel Dänzer wrote:
> > On Mit, 2011-04-06 at 22:43 +0200, Gabriel Paubert wrote:
> > >
> > > The probem is that, at least on one of my machines, the new driver
>
On Thu, Apr 07, 2011 at 04:04:35PM +0200, Michel Dänzer wrote:
> On Mit, 2011-04-06 at 22:43 +0200, Gabriel Paubert wrote:
> >
> > The probem is that, at least on one of my machines, the new driver
> > does not work: the system hangs (apparently solid, but it's before
> > networking starts up and
On Mit, 2011-04-06 at 22:43 +0200, Gabriel Paubert wrote:
>
> The probem is that, at least on one of my machines, the new driver
> does not work: the system hangs (apparently solid, but it's before
> networking starts up and I've not yet hooked up a serial console),
> after the "radeon: ib pool
Hi Dave,
sorry, in my previous message I forgot the strace
output, which is an inifinite loop of the following:
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [])
ioctl(7, 0xc0286429, 0xffdf9bb8)= -1 EBUSY (Device or resource busy)
---
Hi Dave,
> This is the old DRM driver for radeon, which relies on userspace to
> start X then calls the kernel
Actually, even the old DRM driver occasionally hangs on this machine,
I suspect a missing barrier, but I might be completely off base.
The system is up, only X uses 100% of one
On Wed, Apr 06, 2011 at 06:46:55PM +1000, Dave Airlie wrote:
> 2011/4/6 Uwe Kleine-König :
> > Hi Gabriel,
> >
> > On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
> >> I've had the following funny crashes on PPC machines, with
> >> cataleptic X server as a consequence:
> >>
> >> ke
2011/4/6 Uwe Kleine-König :
> Hi Gabriel,
>
> On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
>> I've had the following funny crashes on PPC machines, with
>> cataleptic X server as a consequence:
>>
>> kernel: [drm] Setting GART location based on new memory map
>> kernel: Oops: Ex
Hi Gabriel,
On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
> I've had the following funny crashes on PPC machines, with
> cataleptic X server as a consequence:
>
> kernel: [drm] Setting GART location based on new memory map
> kernel: Oops: Exception in kernel mode, sig: 4 [#1]
>
On Die, 2011-04-05 at 01:52 +0200, Gabriel Paubert wrote:
>
> Actually I thought that the name radeon_cp that is registered there
> would appear somwhere under /sys (or /proc) but failed to find it...
FWIW the radeon_cp* functions are in drivers/gpu/drm/radeon.
--
Earthling Michel Dänzer
Hi,
I've had the following funny crashes on PPC machines, with
cataleptic X server as a consequence:
kernel: [drm] Setting GART location based on new memory map
kernel: Oops: Exception in kernel mode, sig: 4 [#1]
kernel: CHRP
kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/r
26 matches
Mail list logo
