Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Michel Dänzer]

[ 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
> > > 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 ready" message.
> > 
> > Does radeon.agpmode=-1 radeon.no_wb=1 help?
> > 
> > You might be able to get more information via netconsole if you prevent
> > the radeon module from loading automatically (or load it with
> > radeon.modeset=0 first) and then load it e.g. via ssh with modeset=1.
> 
> Loading the module with modeset=1 results in insmod blocked in
> kernel state (not consuming CPU cycles either). The last kernel 
> message is always the same (ib pool ready). This seems to be 
> independent of agpmode and no_wb. The kernel messages when
> loading the driver are:
> 
> kernel: [drm] radeon kernel modesetting enabled.
> kernel: checking generic (c0000000 140000) vs hw (c0000000 10000000)
> kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing generic driver
> kernel: [drm] initializing kernel modesetting (RV530 0x1002:0x71C7).
> kernel: radeon 0000:f1:00.0: Using 64-bit DMA iommu bypass
> kernel: [drm] register mmio base: 0xE8000000
> kernel: [drm] register mmio size: 65536
> kernel: radeon 0000:f1:00.0: Invalid ROM contents
> kernel: ATOM BIOS: X1650PRO
> kernel: [drm] Generation 2 PCI interface, using max accessible memory
> kernel: radeon 0000:f1:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
> kernel: radeon 0000:f1:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
> kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> kernel: [drm] Driver supports precise vblank timestamp query.
> kernel: irq: irq 9 on host /mpic mapped to virtual irq 24
> kernel: u3msi: allocated virq 0x18 (hw 0x9) addr 0xf8004090
> kernel: radeon 0000:f1:00.0: radeon: using MSI.

Have you ruled out any MSI related problems? I think the IRQ not working
could explain the symptoms...

> kernel: [drm] radeon: irq initialized.
> kernel: [drm] Detected VRAM RAM=512M, BAR=256M
> kernel: [drm] RAM width 128bits DDR
> kernel: [TTM] Zone  kernel: Available graphics memory: 1002914 kiB.
> kernel: [TTM] Initializing pool allocator.
> kernel: [drm] radeon: 512M of VRAM memory ready
> kernel: [drm] radeon: 512M of GTT memory ready.
> kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
> kernel: [drm] radeon: 1 quad pipes, 2 z pipes initialized.
> kernel: [drm] PCIE GART of 512M enabled (table at 0x00040000).
> kernel: radeon 0000:f1:00.0: WB enabled

Make sure this line changes to 'WB disabled' with no_wb=1. There's a
writeback endianness bug with modeset=1, see
http://lists.freedesktop.org/archives/dri-devel/2011-April/009960.html .

> kernel: [drm] Loading R500 Microcode
> kernel: [drm] radeon: ring at 0x0000000020001000
> kernel: [drm] ring test succeeded in 6 usecs
> kernel: [drm] radeon: ib pool ready.


> For now, with modeset=0, agpmode=-1 and no_wb=1, the driver
> seems to work.

The agpmode and no_wb options only have an effect with modeset=1, and
you don't seem to be using AGP anyway. :)


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

	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
machine the Ethernet (tigon3) uses MSI and everything is fine. OTOH,
on my home PC (dual code Athlon64 4 1/2 years old), MSI has never worked.

> Make sure this line changes to 'WB disabled' with no_wb=1. There's a
> writeback endianness bug with modeset=1, see
> http://lists.freedesktop.org/archives/dri-devel/2011-April/009960.html .
> 

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: 

kernel: [drm] radeon kernel modesetting enabled.
kernel: checking generic (c0000000 140000) vs hw (c0000000 10000000)
kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing generic driver
kernel: [drm] initializing kernel modesetting (RV530 0x1002:0x71C7).
kernel: radeon 0000:f1:00.0: Using 64-bit DMA iommu bypass
kernel: [drm] register mmio base: 0xE8000000
kernel: [drm] register mmio size: 65536
kernel: radeon 0000:f1:00.0: Invalid ROM contents
kernel: ATOM BIOS: X1650PRO
kernel: [drm] Generation 2 PCI interface, using max accessible memory
kernel: radeon 0000:f1:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
kernel: radeon 0000:f1:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
kernel: [drm] Driver supports precise vblank timestamp query.
kernel: [drm] radeon: irq initialized.
kernel: [drm] Detected VRAM RAM=512M, BAR=256M
kernel: [drm] RAM width 128bits DDR
kernel: [TTM] Zone  kernel: Available graphics memory: 1003018 kiB.
kernel: [TTM] Initializing pool allocator.
kernel: [drm] radeon: 512M of VRAM memory ready
kernel: [drm] radeon: 512M of GTT memory ready.
kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
kernel: [drm] radeon: 1 quad pipes, 2 z pipes initialized.
kernel: [drm] PCIE GART of 512M enabled (table at 0x00040000).
kernel: radeon 0000:f1:00.0: WB disabled
kernel: [drm] Loading R500 Microcode
kernel: [drm] radeon: ring at 0x0000000020001000
kernel: [drm] ring test succeeded in 6 usecs
kernel: [drm] radeon: ib pool ready.
kernel: [drm] ib test succeeded in 0 usecs
kernel: [drm] Radeon Display Connectors
kernel: [drm] Connector 0:
kernel: [drm]   DVI-I
kernel: [drm]   HPD1
kernel: [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
kernel: [drm]   Encoders:
kernel: [drm]     CRT1: INTERNAL_KLDSCP_DAC1
kernel: [drm]     DFP1: INTERNAL_KLDSCP_TMDS1
kernel: [drm] Connector 1:
kernel: [drm]   S-video
kernel: [drm]   Encoders:
kernel: [drm]     TV1: INTERNAL_KLDSCP_DAC2
kernel: [drm] Connector 2:
kernel: [drm]   DVI-I
kernel: [drm]   HPD2
kernel: [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
kernel: [drm]   Encoders:
kernel: [drm]     CRT2: INTERNAL_KLDSCP_DAC2
kernel: [drm]     DFP3: INTERNAL_LVTM1
kernel: [drm] Possible lm63 thermal controller at 0x4c
kernel: [drm] fb mappable at 0xC00C0000
kernel: [drm] vram apper at 0xC0000000
kernel: [drm] size 9216000
kernel: [drm] fb depth is 24
kernel: [drm]    pitch is 7680
kernel: checking generic (c0000000 140000) vs hw (c0000000 10000000)
kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing generic driver
kernel: fb1: radeondrmfb frame buffer device
kernel: drm: registered panic notifier
kernel: [drm] Initialized radeon 2.8.0 20080528 for 0000:f1:00.0 on minor 0
kernel: [drm:drm_mode_getfb] *ERROR* invalid framebuffer id

There is only one display connected and it is to the first DVI connector, BTW.

	Regards,
	Gabriel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Michel Dänzer]

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. Actually on this
> machine the Ethernet (tigon3) uses MSI and everything is fine. OTOH,
> on my home PC (dual code Athlon64 4 1/2 years old), MSI has never worked.

Okay, the fact no_wb helps probably rules out an IRQ problem anyway.


> > Make sure this line changes to 'WB disabled' with no_wb=1. There's a
> > writeback endianness bug with modeset=1, see
> > http://lists.freedesktop.org/archives/dri-devel/2011-April/009960.html .
> > 
> 
> 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.


> kernel: [drm] radeon kernel modesetting enabled.
> kernel: checking generic (c0000000 140000) vs hw (c0000000 10000000)
> kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing generic driver
> kernel: [drm] initializing kernel modesetting (RV530 0x1002:0x71C7).
> kernel: radeon 0000:f1:00.0: Using 64-bit DMA iommu bypass
> kernel: [drm] register mmio base: 0xE8000000
> kernel: [drm] register mmio size: 65536
> kernel: radeon 0000:f1:00.0: Invalid ROM contents
> kernel: ATOM BIOS: X1650PRO
> kernel: [drm] Generation 2 PCI interface, using max accessible memory
> kernel: radeon 0000:f1:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
> kernel: radeon 0000:f1:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
> kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> kernel: [drm] Driver supports precise vblank timestamp query.
> kernel: [drm] radeon: irq initialized.
> kernel: [drm] Detected VRAM RAM=512M, BAR=256M
> kernel: [drm] RAM width 128bits DDR
> kernel: [TTM] Zone  kernel: Available graphics memory: 1003018 kiB.
> kernel: [TTM] Initializing pool allocator.
> kernel: [drm] radeon: 512M of VRAM memory ready
> kernel: [drm] radeon: 512M of GTT memory ready.
> kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
> kernel: [drm] radeon: 1 quad pipes, 2 z pipes initialized.
> kernel: [drm] PCIE GART of 512M enabled (table at 0x00040000).
> kernel: radeon 0000:f1:00.0: WB disabled
> kernel: [drm] Loading R500 Microcode
> kernel: [drm] radeon: ring at 0x0000000020001000
> kernel: [drm] ring test succeeded in 6 usecs
> kernel: [drm] radeon: ib pool ready.
> kernel: [drm] ib test succeeded in 0 usecs
> kernel: [drm] Radeon Display Connectors
> kernel: [drm] Connector 0:
> kernel: [drm]   DVI-I
> kernel: [drm]   HPD1
> kernel: [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> kernel: [drm]   Encoders:
> kernel: [drm]     CRT1: INTERNAL_KLDSCP_DAC1
> kernel: [drm]     DFP1: INTERNAL_KLDSCP_TMDS1
> kernel: [drm] Connector 1:
> kernel: [drm]   S-video
> kernel: [drm]   Encoders:
> kernel: [drm]     TV1: INTERNAL_KLDSCP_DAC2
> kernel: [drm] Connector 2:
> kernel: [drm]   DVI-I
> kernel: [drm]   HPD2
> kernel: [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> kernel: [drm]   Encoders:
> kernel: [drm]     CRT2: INTERNAL_KLDSCP_DAC2
> kernel: [drm]     DFP3: INTERNAL_LVTM1
> kernel: [drm] Possible lm63 thermal controller at 0x4c
> kernel: [drm] fb mappable at 0xC00C0000
> kernel: [drm] vram apper at 0xC0000000
> kernel: [drm] size 9216000
> kernel: [drm] fb depth is 24
> kernel: [drm]    pitch is 7680
> kernel: checking generic (c0000000 140000) vs hw (c0000000 10000000)
> kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing generic driver
> kernel: fb1: radeondrmfb frame buffer device

Hmm, I think this should say fb0, but that should only matter for
console, not X.

> kernel: drm: registered panic notifier
> kernel: [drm] Initialized radeon 2.8.0 20080528 for 0000:f1:00.0 on minor 0
> kernel: [drm:drm_mode_getfb] *ERROR* invalid framebuffer id

BTW, if your kernel contains commit
69a07f0b117a40fcc1a479358d8e1f41793617f2, can you try if reverting that
helps?


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

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, which is DRM_RADEON_GEM_WAIT_IDLE.

The Xorg.0.log from the previous boot is attached.

	Gabriel

[-- Attachment #2: Xorg.0.log.old --]
[-- Type: application/x-trash, Size: 27891 bytes --]

[-- Attachment #3: Type: text/plain, Size: 150 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Michel Dänzer]

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 provide the Xorg.0.log file as well.
> 
> From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.

Note that it's normal for this ioctl to be called every time before the
GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
always returns an error, this may not indicate a problem on its own. 


> The Xorg.0.log from the previous boot is attached.

I don't see any obvious problems in it. Can you describe the symptoms of
the problem you're having with X a bit more?

One thing I notice is that the X server/driver are rather oldish. Maybe
you can try newer versions from testing, sid or even experimental to see
if that makes any difference. 


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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 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, which is DRM_RADEON_GEM_WAIT_IDLE.
> 
> Note that it's normal for this ioctl to be called every time before the
> GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> always returns an error, this may not indicate a problem on its own. 

It seems to be an infinite loop, always returning EINTR because
of regular SIGALRM delivery.

> 
> 
> > The Xorg.0.log from the previous boot is attached.
> 
> I don't see any obvious problems in it. Can you describe the symptoms of
> the problem you're having with X a bit more?

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.

> 
> One thing I notice is that the X server/driver are rather oldish. Maybe
> you can try newer versions from testing, sid or even experimental to see
> if that makes any difference.

I lack time to do it until early May (being away for 2 weeks starting on 
Friday and busy on urgent things). I'm indeed Debian stable (Squeeze),
which is rather recent and the machine is about 2 1/2 years old.

	Gabriel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Benjamin Herrenschmidt]

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 radeons do so, sometimes it has to do with them not liking
what you ate that day...

The only thing I can see that could be of use would be a bisect

Cheers,
Ben.

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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.
> 
> So basically the card crashed. There's about an infinite amount of
> reasons why radeons do so, sometimes it has to do with them not liking
> what you ate that day...
> 
> The only thing I can see that could be of use would be a bisect

Bisecting for something which I have never got to work (radeon with
KMS) on this machine is something I don't know how to do...

Note that radeon without KMS also always ends up crashing, but it
may take hours. The only case where the machine works reliably is 
when glxinfo claims that it is using software rendering.
 
	Regards,
	Gabriel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Michel Dänzer]

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 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, which is DRM_RADEON_GEM_WAIT_IDLE.
> > 
> > Note that it's normal for this ioctl to be called every time before the
> > GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> > always returns an error, this may not indicate a problem on its own. 
> 
> It seems to be an infinite loop, always returning EINTR because
> of regular SIGALRM delivery.

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?


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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 +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, which is DRM_RADEON_GEM_WAIT_IDLE.
> > > 
> > > Note that it's normal for this ioctl to be called every time before the
> > > GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> > > always returns an error, this may not indicate a problem on its own. 
> > 
> > It seems to be an infinite loop, always returning EINTR because
> > of regular SIGALRM delivery.
> 
> 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.

	Gabriel

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Michel Dänzer]

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, 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 provide the Xorg.0.log file as well.
> > > > > 
> > > > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
> > > > 
> > > > Note that it's normal for this ioctl to be called every time before the
> > > > GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> > > > always returns an error, this may not indicate a problem on its own. 
> > > 
> > > It seems to be an infinite loop, always returning EINTR because
> > > of regular SIGALRM delivery.
> > 
> > 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
-dumbSched to see if that gets things along any further, but in the end
there's probably no way around figuring out what causes the lockup and
fixing that anyway.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Andy Furniss]

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
> -dumbSched to see if that gets things along any further, but in the end
> there's probably no way around figuring out what causes the lockup and
> fixing that anyway.

I have an old AGP box that locks with 600g + agpgart - It used to give 
GPU lockup to dmesg/log, but (I only test it occasionally) it doesn't 
anymore. I can still sysrq OK.

I wonder if something changed in recent months in the drm/whatever code 
that has changed/blocked the logging.

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Gabriel Paubert]

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).

	Gabriel

small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Uwe Kleine-König]

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 not include this commit
> (was introduced before 2.6.39-rc1 according to gitk).
gitk is not the best tool to find this out.

$ 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.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Andreas Schwab]

Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 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-rc1
v2.6.39-rc2

Andreas.

-- 
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Gabriel Paubert]

On Wed, Apr 13, 2011 at 10:59:14AM +0200, Andreas Schwab wrote:
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 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-rc1
> v2.6.39-rc2
> 

So who is right? I think it was before rc1. 

Anyway I'm aware that there are other git commands, although for the option
details I often have to have a look at the man page.

However in this case the main reason to fire gitk was to have a quick look 
at the patch and its context, and simply reported the "Precedes" line 
in the display, which is 2.6.39-rc1. It also follow v2.6.37-rc2, which means
that it has been quite a long time outside the main tree.

	Gabriel

Re: small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]

[Uwe Kleine-König]

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 <u.kleine-koenig@pengutronix.de> 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-rc1
> > v2.6.39-rc2
> > 
> 
> So who is right? I think it was before rc1. 
Yep, correct. I interpreted the output of git name-rev to mean it's not
included in a tag earlier than v2.6.39-rc2, but actually that's wrong.
It's just that it's easier (for some definition of easy) to reach the
commit in question from v2.6.39-rc2 than from v2.6.39-rc1.

> However in this case the main reason to fire gitk was to have a quick look 
> at the patch and its context, and simply reported the "Precedes" line 
> in the display, which is 2.6.39-rc1. It also follow v2.6.37-rc2, which means
> that it has been quite a long time outside the main tree.
I think this conclusion isn't valid in general. (E.g. in git itself a
bug-fix is often done on top of the commit that introduced it and than
merged into master. Still the bugfix might be new.) But looking at the
AuthorDate of 69a07f0b117a seems to support your statement.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |