X doesn't work anymore

[Kurt Schreiner]

Hi,

after cvs updat'ing to -current as of Jul  9 23:52 MEST X fails to start.
Here's what /var/log/Xorg.0.log has to say on this (problem is the same with
and without /etc/xorg.conf):

[...]
        ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics,
        ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics,
        ATI Radeon HD Graphics, ATI Radeon Graphics,
        ATI Mobility Radeon HD Graphics, ATI Mobility Radeon Graphics,
        ATI Radeon Graphics
(II) VESA: driver for VESA chipsets: vesa
(II) Primary Device is: PCI 01@01:00:0
(II) resource ranges after xf86ClaimFixedResources() call:
        [0] -1  0       0x000f0000 - 0x000fffff (0x10000) MX[B]
        [1] -1  0       0x000c0000 - 0x000effff (0x30000) MX[B]
        [2] -1  0       0x00000000 - 0x0009ffff (0xa0000) MX[B]
        [3] -1  0       0x0000ffff - 0x0000ffff (0x1) IX[B]
        [4] -1  0       0x00000000 - 0x000000ff (0x100) IX[B]
(WW) Falling back to old probe method for vesa
(II) resource ranges after probing:
        [0] -1  0       0x000f0000 - 0x000fffff (0x10000) MX[B]
        [1] -1  0       0x000c0000 - 0x000effff (0x30000) MX[B]
        [2] -1  0       0x00000000 - 0x0009ffff (0xa0000) MX[B]
        [3] 0   1       0x000a0000 - 0x000affff (0x10000) MS[B]
        [4] 0   1       0x000b0000 - 0x000b7fff (0x8000) MS[B]
        [5] 0   1       0x000b8000 - 0x000bffff (0x8000) MS[B]
        [6] -1  0       0x0000ffff - 0x0000ffff (0x1) IX[B]
        [7] -1  0       0x00000000 - 0x000000ff (0x100) IX[B]
        [8] 0   1       0x000003b0 - 0x000003bb (0xc) IS[B]
        [9] 0   1       0x000003c0 - 0x000003df (0x20) IS[B]
(II) RADEON(0): TOTO SAYS 00000000a8100000
(II) RADEON(0): MMIO registers at 0x00000000a8100000: size 64KB
(EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22)
(EE) RADEON(0): Memory map the MMIO region failed
(II) UnloadModule: "radeon"
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Please consult the The X.Org Foundation support
         at http://wiki.X.Org
 for help.

Any idea where's the culprit?

Kurt

[Michael Lorenz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Jul 9, 2009, at 6:40 PM, Kurt Schreiner wrote:

> Hi,
>
> after cvs updat'ing to -current as of Jul  9 23:52 MEST X fails to  
> start.
> Here's what /var/log/Xorg.0.log has to say on this (problem is the  
> same with
> and without /etc/xorg.conf):
>
> [...]
>        ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics,
>        ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics,
>        ATI Radeon HD Graphics, ATI Radeon Graphics,
>        ATI Mobility Radeon HD Graphics, ATI Mobility Radeon Graphics,
>        ATI Radeon Graphics
> (II) VESA: driver for VESA chipsets: vesa
> (II) Primary Device is: PCI 01@01:00:0
> (II) resource ranges after xf86ClaimFixedResources() call:
>        [0] -1  0       0x000f0000 - 0x000fffff (0x10000) MX[B]
>        [1] -1  0       0x000c0000 - 0x000effff (0x30000) MX[B]
>        [2] -1  0       0x00000000 - 0x0009ffff (0xa0000) MX[B]
>        [3] -1  0       0x0000ffff - 0x0000ffff (0x1) IX[B]
>        [4] -1  0       0x00000000 - 0x000000ff (0x100) IX[B]
> (WW) Falling back to old probe method for vesa
> (II) resource ranges after probing:
>        [0] -1  0       0x000f0000 - 0x000fffff (0x10000) MX[B]
>        [1] -1  0       0x000c0000 - 0x000effff (0x30000) MX[B]
>        [2] -1  0       0x00000000 - 0x0009ffff (0xa0000) MX[B]
>        [3] 0   1       0x000a0000 - 0x000affff (0x10000) MS[B]
>        [4] 0   1       0x000b0000 - 0x000b7fff (0x8000) MS[B]
>        [5] 0   1       0x000b8000 - 0x000bffff (0x8000) MS[B]
>        [6] -1  0       0x0000ffff - 0x0000ffff (0x1) IX[B]
>        [7] -1  0       0x00000000 - 0x000000ff (0x100) IX[B]
>        [8] 0   1       0x000003b0 - 0x000003bb (0xc) IS[B]
>        [9] 0   1       0x000003c0 - 0x000003df (0x20) IS[B]
> (II) RADEON(0): TOTO SAYS 00000000a8100000
> (II) RADEON(0): MMIO registers at 0x00000000a8100000: size 64KB
> (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22)
> (EE) RADEON(0): Memory map the MMIO region failed
> (II) UnloadModule: "radeon"
> (EE) Screen(s) found, but none have a usable configuration.
>
> Fatal server error:
> no screens found
>
> Please consult the The X.Org Foundation support
>         at http://wiki.X.Org
> for help.
>
> Any idea where's the culprit?

Looks like you updated X but not your kernel.
I committed code to allow X to use arbitrary PCI devices no matter in  
which PCI domain they are without using /dev/mem - you will need to  
update your kernel with
options PCI_ALLOW_MMAP
then things should work again.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSlaMfMpnzkX8Yg2nAQJgIwf/fZZNZVb9Q49aRBGwH6C//gjbyb11OoGJ
ANqq/4aM5q83iECkw4HYAv3ToVdrxxWR/dXU/ed8FjV74M/SWrAURNT8Hl8zM5pU
1GTAPHQztzZh/MdUWiyMfliwBfAfI4WYmtlLP/zDVO31s/+EE5Z/ojf7No1pKnN+
S4aJUbEeItQtiaYscwmrcUz87cXAsyNvMxnmx6Yviz/itL/jn/+iMAFyr2gFPD9O
XkOBFl6+9IS7RTsl0RcpOeUKifrrbOWLR/P2VUE0X/V8lsSMntbRqUQrX+NheNmp
ENkWAI98sj2YZFkfELS5dH2m89lzH5ItsxyUCz6LfEN5eas4Iyu6ZQ==
=sV1m
-----END PGP SIGNATURE-----

[Mihai Chelaru-5]

On Thu, 09 Jul 2009 20:34:03 -0400, Michael wrote:
> Looks like you updated X but not your kernel. I committed code to allow
> X to use arbitrary PCI devices no matter in which PCI domain they are
> without using /dev/mem - you will need to update your kernel with
> options PCI_ALLOW_MMAP
> then things should work again.

Cool, radeon driver started to work again with this option. Care to
document it somewhere ?

Thanks !

--
Mihai

[Kurt Schreiner]

On Fri, Jul 10, 2009 at 02:34:03AM +0200, Michael wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> On Jul 9, 2009, at 6:40 PM, Kurt Schreiner wrote:
>
> > Hi,
> >
> > after cvs updat'ing to -current as of Jul  9 23:52 MEST X fails to  
> > start.
> > Here's what /var/log/Xorg.0.log has to say on this (problem is the  
> > same with
> > and without /etc/xorg.conf):
> >
> > [...]
> >
> > Fatal server error:
> > no screens found
> >
> > Please consult the The X.Org Foundation support
> >         at http://wiki.X.Org
> > for help.
> >
> > Any idea where's the culprit?
>
> Looks like you updated X but not your kernel.
> I committed code to allow X to use arbitrary PCI devices no matter in  
> which PCI domain they are without using /dev/mem - you will need to  
> update your kernel with
> options PCI_ALLOW_MMAP
> then things should work again.

Hm, ok I updated the kernel before userland (as usual ;-), but -not
knowing about it - I didn't include "options PCI_ALLOW_MMAP".
I'll try later tonight and let you know how it's going...

Thanks a lot
Kurt

[Paul Goyette]

On Fri, 10 Jul 2009, Mihai Chelaru wrote:

> On Thu, 09 Jul 2009 20:34:03 -0400, Michael wrote:
>> Looks like you updated X but not your kernel. I committed code to allow
>> X to use arbitrary PCI devices no matter in which PCI domain they are
>> without using /dev/mem - you will need to update your kernel with
>> options PCI_ALLOW_MMAP
>> then things should work again.
>
> Cool, radeon driver started to work again with this option. Care to
> document it somewhere ?

Should this option be included in GENERIC?

-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

[Michael Lorenz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Jul 10, 2009, at 7:07 AM, Paul Goyette wrote:

> On Fri, 10 Jul 2009, Mihai Chelaru wrote:
>
>> On Thu, 09 Jul 2009 20:34:03 -0400, Michael wrote:
>>> Looks like you updated X but not your kernel. I committed code to  
>>> allow
>>> X to use arbitrary PCI devices no matter in which PCI domain they  
>>> are
>>> without using /dev/mem - you will need to update your kernel with
>>> options PCI_ALLOW_MMAP
>>> then things should work again.
>>
>> Cool, radeon driver started to work again with this option. Care to
>> document it somewhere ?

I sent a heads up to tech-x11@

> Should this option be included in GENERIC?

Not yet. It opens a big, fat hole for processes to map arbitrary  
memory unless we look at the machine dependent PCI code first and make  
sure you can't map anything but PCI space through /dev/pci*

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSldzUMpnzkX8Yg2nAQLUggf+Mi2KxZS80s/Cd0JA27liA95mFzceB45V
Nm7QoFKpBc7wjCqf+knektosZV4sCZCGckWURQk2MPT9Z+ef3+2MOALCr3kZz9ze
9qhzL/GhIQLt4h7TPNpXC4ZXYxFAwRFarvZlH6LM4/OLpLg4V9CzxaDT9NWiCVH/
Kxf/wDM3Gt7JKXDcRKcu52FzRybugxFN34lDkWxrDuIXFbKhEl8h/FHt1cH0HkLg
ZPS6tcBo9IrDhFOno/mCqv/a1MogMbeGS6xMyo1yhi4OLuto7qhtDI+ASTNFilU7
ltWVPvasCu/CP9Xl/OGc8TARRfYCJ6XExszv0UZIhn0yaiSsJov1BQ==
=mc12
-----END PGP SIGNATURE-----

[Kurt Schreiner]

Hi,

On Fri, Jul 10, 2009 at 02:34:03AM +0200, Michael wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> On Jul 9, 2009, at 6:40 PM, Kurt Schreiner wrote:
>
> > [...]
> >
> > Fatal server error:
> > no screens found
> >
> > Please consult the The X.Org Foundation support
> >         at http://wiki.X.Org
> > for help.
> >
> > Any idea where's the culprit?
>
> Looks like you updated X but not your kernel.
> I committed code to allow X to use arbitrary PCI devices no matter in  
> which PCI domain they are without using /dev/mem - you will need to  
> update your kernel with
> options PCI_ALLOW_MMAP
> then things should work again.

Yep, including "options PCI_ALLOW_MMAP" gets things going again - as long
as I don't add "radeondrm* at vga?", too. With this added I get an unusable
X server causing 100% sys in vmstat...

Kurt

[Michael Lorenz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Jul 10, 2009, at 4:45 PM, Kurt Schreiner wrote:

> Hi,
>
> On Fri, Jul 10, 2009 at 02:34:03AM +0200, Michael wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello,
>>
>> On Jul 9, 2009, at 6:40 PM, Kurt Schreiner wrote:
>>
>>> [...]
>>>
>>> Fatal server error:
>>> no screens found
>>>
>>> Please consult the The X.Org Foundation support
>>>        at http://wiki.X.Org
>>> for help.
>>>
>>> Any idea where's the culprit?
>>
>> Looks like you updated X but not your kernel.
>> I committed code to allow X to use arbitrary PCI devices no matter in
>> which PCI domain they are without using /dev/mem - you will need to
>> update your kernel with
>> options PCI_ALLOW_MMAP
>> then things should work again.
> Yep, including "options PCI_ALLOW_MMAP" gets things going again - as  
> long
> as I don't add "radeondrm* at vga?", too. With this added I get an  
> unusable
> X server causing 100% sys in vmstat...

And that worked before? All that changed is how PCI devices are found  
and through which /dev entry they are mapped, the resulting mappings  
should be identical.
Where does the Xserver spin?

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSlepUspnzkX8Yg2nAQIwzAf+O1Wl+irEwV9TeomoRgYwVlnHhDhfJdVb
HTo4WBs/4smevW+kSnawRRVdK95UrakETQMSxHmCt+a+Pw4qp9jdGDVnxR5Vd0y5
C5YOx8lkzeq70dUJiuFOxN4oumqnuvpfRn1BhRQR4kVY8PXZauxWGo7AiI7IrQMY
mnYDXpzQi0aXvnB5xAqcgyb3RFoaala4bvAEmJgxmfH/2J7MHDtmLB2MEy3Khm4J
ARnKREVEslTU2WB9nQ12mi2azA6LYNOdEzKqI+zEnOJaPflhX0f2JK9DCesMFbu5
8Iweq1/v1hksiPIiUh/TdBVo3WbFXqoAMU5fdsCq8ElBT3voIndV2Q==
=GOEP
-----END PGP SIGNATURE-----

[Kurt Schreiner]

Hi,

On Fri, Jul 10, 2009 at 10:49:22PM +0200, Michael wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> On Jul 10, 2009, at 4:45 PM, Kurt Schreiner wrote:
> [....]
> > Yep, including "options PCI_ALLOW_MMAP" gets things going again - as  
> > long as I don't add "radeondrm* at vga?", too. With this added I get
> > an unusable X server causing 100% sys in vmstat...
>
> And that worked before?

That worked 'till ~ mid June - at least that was the last time I tried.

/var/log/messages.1.gz:Jun 19 22:02:26 ipaddi /netbsd: radeondrm0 at vga0: ATI FireGL M24 GL (unit 0)
/var/log/messages.1.gz:Jun 19 22:02:26 ipaddi /netbsd: radeondrm0: Initialized radeon 1.26.0 20060524
/var/log/messages.1.gz:Jun 19 22:02:37 ipaddi /netbsd: info: [drm] Setting GART location based on new memory map
/var/log/messages.1.gz:Jun 19 22:02:37 ipaddi /netbsd: info: [drm] Loading R300 Microcode
/var/log/messages.1.gz:Jun 19 22:02:37 ipaddi /netbsd: info: [drm] writeback test failed
/var/log/messages.1.gz:Jun 19 22:02:37 ipaddi /netbsd: radeondrm0: interrupting at ioapic0 pin 16

> All that changed is how PCI devices are found and through which /dev
> entry they are mapped, the resulting mappings should be identical.
> Where does the Xserver spin?
Doing an ioctl on /dev/dri/card0:

   571      1 Xorg     CALL  ioctl(0xb,_IO('d',0x44),0)
   571      1 Xorg     RET   ioctl -1 errno 16 Device busy
   571      1 Xorg     CALL  ioctl(0xb,_IO('d',0x44),0)
   571      1 Xorg     RET   ioctl -1 errno 16 Device busy
^C
>-1011: fstat -p 571
USER     CMD          PID   FD MOUNT       INUM MODE         SZ|DV R/W
root     Xorg         571   wd /home    1448448 drwxr-xr-x   54784 r
root     Xorg         571    0 /var       62476 -rw-r-----   34300 w
root     Xorg         571    1* internet stream tcp c2dcd1f8 *:6000
root     Xorg         571    2 /          79329 crwx-w----   ttyp0 rw
root     Xorg         571    3* unix stream c33ab080
root     Xorg         571    4 /          78412 crw-r-----     mem rw
root     Xorg         571    5 /          78425 crw-------   ttyE4 rw
root     Xorg         571    6 /          79599 crw-r--r--    pci0 rw
root     Xorg         571    7 /          79600 crw-r--r--    pci1 rw
root     Xorg         571    8 /          79601 crw-r--r--    pci2 rw
root     Xorg         571    9 /          79602 crw-r--r--    pci3 rw
root     Xorg         571   10 /          79603 crw-r--r--    pci4 rw
root     Xorg         571   11 /          82095 crw-rw----   180,0  rw

>-1012: ls -l /dev/* | grep 180
crw-rw----  1 root  wheel  - 180, 0 Jul 10 23:36 card0

Form /var/log/messages:

Jul 10 23:34:49 ipaddi /netbsd: agp0 at pchb0: can't find internal VGA device config space
Jul 10 23:34:49 ipaddi /netbsd: radeondrm0 at vga0: ATI FireGL M24 GL
Jul 10 23:34:49 ipaddi /netbsd: radeondrm0: Initialized radeon 1.29.0 20080613
Jul 10 23:36:14 ipaddi /netbsd: info: [drm] Setting GART location based on new memory map
Jul 10 23:36:14 ipaddi /netbsd: info: [drm] Loading R300 Microcode
Jul 10 23:36:14 ipaddi /netbsd: info: [drm] Num pipes: 1
Jul 10 23:36:14 ipaddi /netbsd: info: [drm] writeback test failed
Jul 10 23:36:14 ipaddi /netbsd: info: [drm] wait idle failed status : 0x80010140 0x00000000
Jul 10 23:36:45 ipaddi /netbsd: info: [drm] wait idle failed status : 0x80010140 0x00000000
Jul 10 23:38:46 ipaddi /netbsd: info: [drm] wait idle failed status : 0x80010140 0x00000000

There's no "radeondrm0: interrupting at ioapic0 pin 16" as in the
working case above...

Kurt

[Michael Lorenz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Jul 10, 2009, at 5:48 PM, Kurt Schreiner wrote:

> Hi,
>
> On Fri, Jul 10, 2009 at 10:49:22PM +0200, Michael wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello,
>>
>> On Jul 10, 2009, at 4:45 PM, Kurt Schreiner wrote:
>> [....]
>>> Yep, including "options PCI_ALLOW_MMAP" gets things going again - as
>>> long as I don't add "radeondrm* at vga?", too. With this added I get
>>> an unusable X server causing 100% sys in vmstat...
>>
>> And that worked before?
> That worked 'till ~ mid June - at least that was the last time I  
> tried.
>
> /var/log/messages.1.gz:Jun 19 22:02:26 ipaddi /netbsd: radeondrm0 at  
> vga0: ATI FireGL M24 GL (unit 0)
> /var/log/messages.1.gz:Jun 19 22:02:26 ipaddi /netbsd: radeondrm0:  
> Initialized radeon 1.26.0 20060524
> /var/log/messages.1.gz:Jun 19 22:02:37 ipaddi /netbsd: info: [drm]  
> Setting GART location based on new memory map
> /var/log/messages.1.gz:Jun 19 22:02:37 ipaddi /netbsd: info: [drm]  
> Loading R300 Microcode
> /var/log/messages.1.gz:Jun 19 22:02:37 ipaddi /netbsd: info: [drm]  
> writeback test failed
> /var/log/messages.1.gz:Jun 19 22:02:37 ipaddi /netbsd: radeondrm0:  
> interrupting at ioapic0 pin 16
>
>> All that changed is how PCI devices are found and through which /dev
>> entry they are mapped, the resulting mappings should be identical.
>> Where does the Xserver spin?
> Doing an ioctl on /dev/dri/card0:
>
>   571      1 Xorg     CALL  ioctl(0xb,_IO('d',0x44),0)
>   571      1 Xorg     RET   ioctl -1 errno 16 Device busy
>   571      1 Xorg     CALL  ioctl(0xb,_IO('d',0x44),0)
>   571      1 Xorg     RET   ioctl -1 errno 16 Device busy
> ^C

That's unrelated to my changes then.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSlfN/MpnzkX8Yg2nAQJfIggAhLWobuFz3kxL4ZrIwpw3R8uBtNDCFzYZ
MtKb2xHn+Ttrj7Tg6OmDq7hYZ7A5WybyccitJ2hR4MdUlcMzFG3OGiVe/GkqJgzC
aj4qDyZEPja2UhASIPaYCSOT99pklYKddhcwhVQn0iiinTUoB6ubEVSq2WsPN1/p
WYNJlEWdjjsONQXmGjwJ8e3KwNW0YTjhGJinL1X2LQ0vbVLglWjVDOjVF+Xw+cTz
q8q+nv58/0niVSMcDRi3r12xOZRBnEUdxaaLoQmtiU6INunQZ3l3EYp3CYsplkoi
i0zP4S3wSoBXgbJ5BtreBSyPGnpbY8FXjPtNzLbGZVCky6MamnGUuw==
=qz76
-----END PGP SIGNATURE-----

[Rafal Boni]

On Fri, Jul 10, 2009 at 11:48:56PM +0200, Kurt Schreiner wrote:
> That worked 'till ~ mid June - at least that was the last time I tried.
>
> /var/log/messages.1.gz:Jun 19 22:02:26 ipaddi /netbsd: radeondrm0 at vga0: ATI FireGL M24 GL (unit 0)
[...]

> > Where does the Xserver spin?
> Doing an ioctl on /dev/dri/card0:
>
>    571      1 Xorg     CALL  ioctl(0xb,_IO('d',0x44),0)
>    571      1 Xorg     RET   ioctl -1 errno 16 Device busy
>    571      1 Xorg     CALL  ioctl(0xb,_IO('d',0x44),0)
>    571      1 Xorg     RET   ioctl -1 errno 16 Device busy
[...]

> Form /var/log/messages:
>
> Jul 10 23:34:49 ipaddi /netbsd: agp0 at pchb0: can't find internal VGA device config space
> Jul 10 23:34:49 ipaddi /netbsd: radeondrm0 at vga0: ATI FireGL M24 GL
> Jul 10 23:34:49 ipaddi /netbsd: radeondrm0: Initialized radeon 1.29.0 20080613
> Jul 10 23:36:14 ipaddi /netbsd: info: [drm] Setting GART location based on new memory map
> Jul 10 23:36:14 ipaddi /netbsd: info: [drm] Loading R300 Microcode
> Jul 10 23:36:14 ipaddi /netbsd: info: [drm] Num pipes: 1
> Jul 10 23:36:14 ipaddi /netbsd: info: [drm] writeback test failed
> Jul 10 23:36:14 ipaddi /netbsd: info: [drm] wait idle failed status : 0x80010140 0x00000000
> Jul 10 23:36:45 ipaddi /netbsd: info: [drm] wait idle failed status : 0x80010140 0x00000000
> Jul 10 23:38:46 ipaddi /netbsd: info: [drm] wait idle failed status : 0x80010140 0x00000000

Yeah, I see this too on my X300 M22 after the upgrade to external DRM; I
suspect it's once again related to scatter-gather stuff, but I haven't
had the time to look in more detail (certainly before the last changes
to that code in the old DRM, X + DRM on that card failed in other odd
ways, though it would "fix" itself if I restarted X after the initial,
screwed-up session; it would also work just fine w/out DRM).

> There's no "radeondrm0: interrupting at ioapic0 pin 16" as in the
> working case above...

I think that's because the X server hasn't made it far enough to ask for
the IRQ handler to be installed / enabled... I think it gets wedged pretty
early in the DRM initialization.

--rafal

--
  Time is an illusion; lunchtime, doubly so.     |/\/\|           Rafal Boni
                   -- Ford Prefect               |\/\/|      rafal@...

[Rafal Boni]

On Fri, Jul 10, 2009 at 07:25:48PM -0400, Michael wrote:

[...DRM-related spin in X on ATI FireGL M24...
> That's unrelated to my changes then.

Yeah, and it coincides with the switch to the new external DRM; on my T43,
I see this same failure at least 3 weeks back (which was the first run-in
with external DRM + current Xsrc on that machine)

--rafal

--
  Time is an illusion; lunchtime, doubly so.     |/\/\|           Rafal Boni
                   -- Ford Prefect               |\/\/|      rafal@...

[Rafal Boni]

On Fri, Jul 10, 2009 at 10:12:06PM -0400, Rafal Boni wrote:

> On Fri, Jul 10, 2009 at 11:48:56PM +0200, Kurt Schreiner wrote:
> > Form /var/log/messages:
> >
> > Jul 10 23:34:49 ipaddi /netbsd: agp0 at pchb0: can't find internal VGA device config space
> > Jul 10 23:34:49 ipaddi /netbsd: radeondrm0 at vga0: ATI FireGL M24 GL
> > Jul 10 23:34:49 ipaddi /netbsd: radeondrm0: Initialized radeon 1.29.0 20080613
> > Jul 10 23:36:14 ipaddi /netbsd: info: [drm] Setting GART location based on new memory map
> > Jul 10 23:36:14 ipaddi /netbsd: info: [drm] Loading R300 Microcode
> > Jul 10 23:36:14 ipaddi /netbsd: info: [drm] Num pipes: 1
> > Jul 10 23:36:14 ipaddi /netbsd: info: [drm] writeback test failed
> > Jul 10 23:36:14 ipaddi /netbsd: info: [drm] wait idle failed status : 0x80010140 0x00000000
> > Jul 10 23:36:45 ipaddi /netbsd: info: [drm] wait idle failed status : 0x80010140 0x00000000
> > Jul 10 23:38:46 ipaddi /netbsd: info: [drm] wait idle failed status : 0x80010140 0x00000000
>
> Yeah, I see this too on my X300 M22 after the upgrade to external DRM; I
> suspect it's once again related to scatter-gather stuff, but I haven't
> had the time to look in more detail (certainly before the last changes
> to that code in the old DRM, X + DRM on that card failed in other odd
> ways, though it would "fix" itself if I restarted X after the initial,
> screwed-up session; it would also work just fine w/out DRM).

Interestingly enough, starting at hw.dri.debug output for a few hours
trying this and that, I couldn't figure out what in DRI-land was making
the card so unhappy... and then thought to actually verify if it was the
DRI bits or the X server (I said before I thought a kernel upgrade was
enough to make this fail -- but didn't have notes on what I upgraded
in what order and what I tested at what point).

Long story short, running a 5.99.14 DRM-enabled kernel with a 5.0 user-
land and native (5.0-release) Xorg 1.4.2 works just dandy with DRI on,
so it looks like the failure is caused by something in the new 1.6.xx
X server, new Mesa hardware renderer library for the R300, or something
related.

I'm not sure I feel better or worse about that, though :-/
--rafal

PS: I haven't tried with the latest-and-greatest Xorg 1.6.2, I was
still running a -current userland / native Xorg from ~ 6/23 when I
tripped over this failure.

--
  Time is an illusion; lunchtime, doubly so.     |/\/\|           Rafal Boni
                   -- Ford Prefect               |\/\/|      rafal@...