xserver problem with 1.19.7->1.20.5

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

xserver problem with 1.19.7->1.20.5

Sebastien Marie-3
Hi,

I upgraded an amd64 host with
        OpenBSD 6.5-current (GENERIC.MP) #174: Tue Aug 6 10:56:11 MDT 2019.

The system starts xenodm using rcctl.

With X Server 1.20.5, the maximum screen size is 720x400, whereas it was
1280x1024 before.

old$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 400, current 1280 x 1024, maximum 1280 x 1024
default connected 1280x1024+0+0 0mm x 0mm
   1280x1024      0.00*
   1152x864       0.00  
   1024x768       0.00  
   800x600        0.00  
   640x480        0.00  
   720x400        0.00  

new$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 720 x 400, current 720 x 400, maximum 720 x 400
default connected 720x400+0+0 0mm x 0mm
   720x400        0.00*


I reverted X Server by untarring an old xserv65.tgz set, and I have got
back a working X Server.

I see no change in dmesg with my old state (Thu Jul 25 08:28:22 MDT
2019). I attached the current dmesg below (the radeondrm0 error and
detach was already present before).

The system uses VESA driver.

I attached also Xorg.0.log with old set and with current set.

The difference are in lines
        (II) VESA(0): Not using built-in mode "...x..." (no mode of this name)

where the list is longer with 1.20.5. Nothing particular else.

Thanks.
--
Sebastien Marie

Xorg.0.log (97K) Download Attachment
Xorg.0.old (95K) Download Attachment
dmesg.log (7K) Download Attachment
dmesg.old (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Mark Kettenis
> Date: Wed, 7 Aug 2019 09:21:28 +0200
> From: Sebastien Marie <[hidden email]>
>
> Hi,
>
> I upgraded an amd64 host with
> OpenBSD 6.5-current (GENERIC.MP) #174: Tue Aug 6 10:56:11 MDT 2019.
>
> The system starts xenodm using rcctl.
>
> With X Server 1.20.5, the maximum screen size is 720x400, whereas it was
> 1280x1024 before.
>
> old$ xrandr
> xrandr: Failed to get size of gamma for output default
> Screen 0: minimum 640 x 400, current 1280 x 1024, maximum 1280 x 1024
> default connected 1280x1024+0+0 0mm x 0mm
>    1280x1024      0.00*
>    1152x864       0.00  
>    1024x768       0.00  
>    800x600        0.00  
>    640x480        0.00  
>    720x400        0.00  
>
> new$ xrandr
> xrandr: Failed to get size of gamma for output default
> Screen 0: minimum 720 x 400, current 720 x 400, maximum 720 x 400
> default connected 720x400+0+0 0mm x 0mm
>    720x400        0.00*
>
>
> I reverted X Server by untarring an old xserv65.tgz set, and I have got
> back a working X Server.
>
> I see no change in dmesg with my old state (Thu Jul 25 08:28:22 MDT
> 2019). I attached the current dmesg below (the radeondrm0 error and
> detach was already present before).
>
> The system uses VESA driver.

The days of that driver (and other non-KMS non-wsfb drivers) are
numbered.  I'm seriously considering ripping out the "aperture" code
from the kernel at some point in the not too distant future.

Not arguing this isn't a bug in X that we shouldn't try to fix.  However:

initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
[TTM] Memory type 2 has not been initialized
drm0 detached
radeondrm0 detached
vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 Pro" rev 0x00

appears to be the real problem here.  Is it possible for you to build
a kernel with DRMDEBUG turned on and send me and jsg@ the output?

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Matthieu Herrb-3
In reply to this post by Sebastien Marie-3
On Wed, Aug 07, 2019 at 09:21:28AM +0200, Sebastien Marie wrote:

> Hi,
>
> I upgraded an amd64 host with
> OpenBSD 6.5-current (GENERIC.MP) #174: Tue Aug 6 10:56:11 MDT 2019.
>
> The system starts xenodm using rcctl.
>
> With X Server 1.20.5, the maximum screen size is 720x400, whereas it was
> 1280x1024 before.
>
> old$ xrandr
> xrandr: Failed to get size of gamma for output default
> Screen 0: minimum 640 x 400, current 1280 x 1024, maximum 1280 x 1024
> default connected 1280x1024+0+0 0mm x 0mm
>    1280x1024      0.00*
>    1152x864       0.00  
>    1024x768       0.00  
>    800x600        0.00  
>    640x480        0.00  
>    720x400        0.00  
>
> new$ xrandr
> xrandr: Failed to get size of gamma for output default
> Screen 0: minimum 720 x 400, current 720 x 400, maximum 720 x 400
> default connected 720x400+0+0 0mm x 0mm
>    720x400        0.00*
>
>
> I reverted X Server by untarring an old xserv65.tgz set, and I have got
> back a working X Server.
>
> I see no change in dmesg with my old state (Thu Jul 25 08:28:22 MDT
> 2019). I attached the current dmesg below (the radeondrm0 error and
> detach was already present before).
>
> The system uses VESA driver.

Hi,

have you installed the radeon firmware package ?  If not, that may
explain why this machine cannot use KMS and the radeon X driver.

If not, is it on purpose ?

I think I have a machine wih a Radeon HD 2400 that works well. I just
need to recheck when I'm home this evening.

I will also have a look on why did the extra built-in modes disapear.
But I think that if you can run a better driver than xf86-video-vesa,
it is better.

--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Sebastien Marie-3
In reply to this post by Mark Kettenis
On Wed, Aug 07, 2019 at 11:20:59AM +0200, Mark Kettenis wrote:
 >

> > I see no change in dmesg with my old state (Thu Jul 25 08:28:22 MDT
> > 2019). I attached the current dmesg below (the radeondrm0 error and
> > detach was already present before).
> >
> > The system uses VESA driver.
>
> The days of that driver (and other non-KMS non-wsfb drivers) are
> numbered.  I'm seriously considering ripping out the "aperture" code
> from the kernel at some point in the not too distant future.
>
> Not arguing this isn't a bug in X that we shouldn't try to fix.  However:
>
> initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
> drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> [TTM] Memory type 2 has not been initialized
> drm0 detached
> radeondrm0 detached
> vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 Pro" rev 0x00
>
> appears to be the real problem here.  Is it possible for you to build
> a kernel with DRMDEBUG turned on and send me and jsg@ the output?

I built a kernel with DRMDEBUG and put 0xffff in drm_debug variable.

initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
[drm] COMBIOS detected
drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
[drm] radeon: finishing device.
[TTM] Memory type 2 has not been initialized
[drm]
drm0 detached
radeondrm0 detached
vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 Pro" rev 0x00


I tried to follow a bit the initialisation path from radeon_get_bios():
- radeon_get_bios()
  - radeon_read_disabled_bios()
    - r600_read_disabled_bios()
      - init registers
      - radeon_read_bios()
      - restore registers

Thanks.
--
Sebastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Sebastien Marie-3
In reply to this post by Matthieu Herrb-3
On Wed, Aug 07, 2019 at 11:32:09AM +0200, Matthieu Herrb wrote:
> Hi,
>
> have you installed the radeon firmware package ?  If not, that may
> explain why this machine cannot use KMS and the radeon X driver.

Yes.

# pkg_info radeondrm-firmware
Information for inst:radeondrm-firmware-20181218

Comment:
firmware binary images for radeondrm(4) driver

Description:
Firmware binary images for use with the radeondrm(4) driver.

Maintainer: Jonathan Gray <[hidden email]>

WWW: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/radeon

> I think I have a machine wih a Radeon HD 2400 that works well. I just
> need to recheck when I'm home this evening.
>
> I will also have a look on why did the extra built-in modes disapear.
> But I think that if you can run a better driver than xf86-video-vesa,
> it is better.

Here the pcidump -v output.

Domain /dev/pci0:
 0:0:0: Intel 82Q35 Host
        0x0000: Vendor ID: 8086, Product ID: 29b0
        0x0004: Command: 0106, Status: 2090
        0x0008: Class: 06 Bridge, Subclass: 00 Host,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR empty (00000000)
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
        0x00e0: Capability 0x09: Vendor Specific
 0:1:0: Intel 82Q35 PCIE
        0x0000: Vendor ID: 8086, Product ID: 29b1
        0x0004: Command: 0107, Status: 0010
        0x0008: Class: 06 Bridge, Subclass: 04 PCI,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 01, Latency Timer: 00,
                Cache Line Size: 10
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: Primary Bus: 0, Secondary Bus: 1, Subordinate Bus: 1,
                Secondary Latency Timer: 00
        0x001c: I/O Base: d0, I/O Limit: d0, Secondary Status: 2000
        0x0020: Memory Base: fe90, Memory Limit: fea0
        0x0024: Prefetch Memory Base: d001, Prefetch Memory Limit: dff1
        0x0028: Prefetch Memory Base Upper 32 Bits: 00000000
        0x002c: Prefetch Memory Limit Upper 32 Bits: 00000000
        0x0030: I/O Base Upper 16 Bits: 0000, I/O Limit Upper 16 Bits: 0000
        0x0038: Expansion ROM Base Address: 00000000
        0x003c: Interrupt Pin: 01, Line: 0b, Bridge Control: 000a
        0x0088: Capability 0x0d: PCI-PCI
        0x0080: Capability 0x01: Power Management
                State: D0
        0x0090: Capability 0x05: Message Signalled Interrupts (MSI)
                Enabled: yes
        0x00a0: Capability 0x10: PCI Express
                Link Speed: 2.5 / 2.5 GT/s, Link Width: x16 / x16
 0:3:0: Intel 82Q35 HECI
        0x0000: Vendor ID: 8086, Product ID: 29b4
        0x0004: Command: 0006, Status: 0010
        0x0008: Class: 07 Communications, Subclass: 80 Miscellaneous,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR mem 64bit addr: 0x00000000fedad000/0x00000010
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR empty (00000000)
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x01: Power Management
                State: D0
        0x008c: Capability 0x05: Message Signalled Interrupts (MSI)
                Enabled: no
 0:3:2: Intel 82Q35 PT IDER
        0x0000: Vendor ID: 8086, Product ID: 29b6
        0x0004: Command: 0005, Status: 00b0
        0x0008: Class: 01 Mass Storage, Subclass: 01 IDE,
                Interface: 85, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR io addr: 0x0000fe80/0x0008
        0x0014: BAR io addr: 0x0000fe90/0x0004
        0x0018: BAR io addr: 0x0000fea0/0x0008
        0x001c: BAR io addr: 0x0000feb0/0x0004
        0x0020: BAR io addr: 0x0000fef0/0x0010
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 03 Line: 09 Min Gnt: 00 Max Lat: 00
        0x00c8: Capability 0x01: Power Management
                State: D0
        0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
                Enabled: no
 0:3:3: Intel 82Q35 KT
        0x0000: Vendor ID: 8086, Product ID: 29b7
        0x0004: Command: 0007, Status: 00b0
        0x0008: Class: 07 Communications, Subclass: 00 Serial,
                Interface: 02, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR io addr: 0x0000ec98/0x0008
        0x0014: BAR mem 32bit addr: 0xfebda000/0x00001000
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR empty (00000000)
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 02 Line: 05 Min Gnt: 00 Max Lat: 00
        0x00c8: Capability 0x01: Power Management
                State: D0
        0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
                Enabled: no
 0:25:0: Intel ICH9 IGP AMT
        0x0000: Vendor ID: 8086, Product ID: 10bd
        0x0004: Command: 0107, Status: 0010
        0x0008: Class: 02 Network, Subclass: 00 Ethernet,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR mem 32bit addr: 0xfebe0000/0x00020000
        0x0014: BAR mem 32bit addr: 0xfebdb000/0x00001000
        0x0018: BAR io addr: 0x0000ecc0/0x0020
        0x001c: BAR empty (00000000)
        0x0020: BAR empty (00000000)
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 01 Line: 03 Min Gnt: 00 Max Lat: 00
        0x00c8: Capability 0x01: Power Management
                State: D0 PME# enabled
        0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
                Enabled: yes
        0x00e0: Capability 0x13: PCI Advanced Features
 0:26:0: Intel 82801I USB
        0x0000: Vendor ID: 8086, Product ID: 2937
        0x0004: Command: 0005, Status: 0290
        0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR io addr: 0x0000ff20/0x0020
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x13: PCI Advanced Features
 0:26:1: Intel 82801I USB
        0x0000: Vendor ID: 8086, Product ID: 2938
        0x0004: Command: 0005, Status: 0290
        0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR io addr: 0x0000ff00/0x0020
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 02 Line: 05 Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x13: PCI Advanced Features
 0:26:7: Intel 82801I USB
        0x0000: Vendor ID: 8086, Product ID: 293c
        0x0004: Command: 0106, Status: 0290
        0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
                Interface: 20, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR mem 32bit addr: 0xfebd9c00/0x00000400
        0x0014: BAR empty (00000000)
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR empty (00000000)
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 03 Line: 05 Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x01: Power Management
                State: D0
        0x0058: Capability 0x0a: Debug Port
        0x0098: Capability 0x13: PCI Advanced Features
 0:27:0: Intel 82801I HD Audio
        0x0000: Vendor ID: 8086, Product ID: 293e
        0x0004: Command: 0106, Status: 0010
        0x0008: Class: 04 (unknown), Subclass: 03 (unknown),
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 10
        0x0010: BAR mem 64bit addr: 0x00000000febdc000/0x00004000
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR empty (00000000)
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x01: Power Management
                State: D0
        0x0060: Capability 0x05: Message Signalled Interrupts (MSI)
                Enabled: yes
        0x0070: Capability 0x10: PCI Express
 0:28:0: Intel 82801I PCIE
        0x0000: Vendor ID: 8086, Product ID: 2940
        0x0004: Command: 0107, Status: 0010
        0x0008: Class: 06 Bridge, Subclass: 04 PCI,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 81, Latency Timer: 00,
                Cache Line Size: 10
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: Primary Bus: 0, Secondary Bus: 2, Subordinate Bus: 2,
                Secondary Latency Timer: 00
        0x001c: I/O Base: f0, I/O Limit: 00, Secondary Status: 2000
        0x0020: Memory Base: fe80, Memory Limit: fe80
        0x0024: Prefetch Memory Base: fff1, Prefetch Memory Limit: 0001
        0x0028: Prefetch Memory Base Upper 32 Bits: 00000000
        0x002c: Prefetch Memory Limit Upper 32 Bits: 00000000
        0x0030: I/O Base Upper 16 Bits: 0000, I/O Limit Upper 16 Bits: 0000
        0x0038: Expansion ROM Base Address: 00000000
        0x003c: Interrupt Pin: 01, Line: 0b, Bridge Control: 0002
        0x0040: Capability 0x10: PCI Express
                Link Speed: 2.5 / 2.5 GT/s, Link Width: x0 / x1
        0x0080: Capability 0x05: Message Signalled Interrupts (MSI)
                Enabled: yes
        0x0090: Capability 0x0d: PCI-PCI
        0x00a0: Capability 0x01: Power Management
                State: D0
 0:29:0: Intel 82801I USB
        0x0000: Vendor ID: 8086, Product ID: 2934
        0x0004: Command: 0005, Status: 0290
        0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR io addr: 0x0000ff80/0x0020
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x13: PCI Advanced Features
 0:29:1: Intel 82801I USB
        0x0000: Vendor ID: 8086, Product ID: 2935
        0x0004: Command: 0005, Status: 0290
        0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR io addr: 0x0000ff60/0x0020
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 02 Line: 05 Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x13: PCI Advanced Features
 0:29:2: Intel 82801I USB
        0x0000: Vendor ID: 8086, Product ID: 2936
        0x0004: Command: 0005, Status: 0290
        0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR io addr: 0x0000ff40/0x0020
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 03 Line: 09 Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x13: PCI Advanced Features
 0:29:7: Intel 82801I USB
        0x0000: Vendor ID: 8086, Product ID: 293a
        0x0004: Command: 0106, Status: 0290
        0x0008: Class: 0c Serial Bus, Subclass: 03 USB,
                Interface: 20, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR mem 32bit addr: 0xff980800/0x00000400
        0x0014: BAR empty (00000000)
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR empty (00000000)
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x01: Power Management
                State: D0
        0x0058: Capability 0x0a: Debug Port
        0x0098: Capability 0x13: PCI Advanced Features
 0:30:0: Intel 82801BA Hub-to-PCI
        0x0000: Vendor ID: 8086, Product ID: 244e
        0x0004: Command: 0107, Status: 0010
        0x0008: Class: 06 Bridge, Subclass: 04 PCI,
                Interface: 01, Revision: 92
        0x000c: BIST: 00, Header Type: 01, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: Primary Bus: 0, Secondary Bus: 3, Subordinate Bus: 3,
                Secondary Latency Timer: 20
        0x001c: I/O Base: c0, I/O Limit: c0, Secondary Status: 2280
        0x0020: Memory Base: fe60, Memory Limit: fe70
        0x0024: Prefetch Memory Base: fff1, Prefetch Memory Limit: 0001
        0x0028: Prefetch Memory Base Upper 32 Bits: 00000000
        0x002c: Prefetch Memory Limit Upper 32 Bits: 00000000
        0x0030: I/O Base Upper 16 Bits: 0000, I/O Limit Upper 16 Bits: 0000
        0x0038: Expansion ROM Base Address: 00000000
        0x003c: Interrupt Pin: 00, Line: 00, Bridge Control: 0002
        0x0050: Capability 0x0d: PCI-PCI
 0:31:0: Intel 82801IO LPC
        0x0000: Vendor ID: 8086, Product ID: 2914
        0x0004: Command: 0107, Status: 0210
        0x0008: Class: 06 Bridge, Subclass: 01 ISA,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR empty (00000000)
        0x0014: BAR empty (00000000)
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR empty (00000000)
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 0000 Product ID: 0000
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
        0x00e0: Capability 0x09: Vendor Specific
 0:31:2: Intel 82801I AHCI
        0x0000: Vendor ID: 8086, Product ID: 2922
        0x0004: Command: 0007, Status: 02b0
        0x0008: Class: 01 Mass Storage, Subclass: 06 SATA,
                Interface: 01, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR io addr: 0x0000fe00/0x0008
        0x0014: BAR io addr: 0x0000fe10/0x0004
        0x0018: BAR io addr: 0x0000fe20/0x0008
        0x001c: BAR io addr: 0x0000fe30/0x0004
        0x0020: BAR io addr: 0x0000fec0/0x0020
        0x0024: BAR mem 32bit addr: 0xff970000/0x00000800
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 03 Line: 09 Min Gnt: 00 Max Lat: 00
        0x0080: Capability 0x05: Message Signalled Interrupts (MSI)
                Enabled: yes
        0x0070: Capability 0x01: Power Management
                State: D0
        0x00a8: Capability 0x12: SATA
        0x00b0: Capability 0x13: PCI Advanced Features
 0:31:3: Intel 82801I SMBus
        0x0000: Vendor ID: 8086, Product ID: 2930
        0x0004: Command: 0103, Status: 0280
        0x0008: Class: 0c Serial Bus, Subclass: 05 SMBus,
                Interface: 00, Revision: 02
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 00
        0x0010: BAR mem 64bit addr: 0x00000000febd9b00/0x00000100
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR io addr: 0x0000ece0/0x0020
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0211
        0x0030: Expansion ROM Base Address: 00000000
        0x0038: 00000000
        0x003c: Interrupt Pin: 03 Line: 09 Min Gnt: 00 Max Lat: 00
 1:0:0: ATI Radeon HD 2400 Pro
        0x0000: Vendor ID: 1002, Product ID: 94c3
        0x0004: Command: 0007, Status: 0010
        0x0008: Class: 03 Display, Subclass: 00 VGA,
                Interface: 00, Revision: 00
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
                Cache Line Size: 10
        0x0010: BAR mem prefetchable 64bit addr: 0x00000000d0000000/0x10000000
        0x0018: BAR mem 64bit addr: 0x00000000fe9f0000/0x00010000
        0x0020: BAR io addr: 0x0000dc00/0x0100
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1028 Product ID: 0402
        0x0030: Expansion ROM Base Address: fea00001
        0x0038: 00000000
        0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00
        0x0050: Capability 0x01: Power Management
                State: D0
        0x0058: Capability 0x10: PCI Express
                Link Speed: 2.5 / 2.5 GT/s, Link Width: x16 / x16
        0x00a0: Capability 0x05: Message Signalled Interrupts (MSI)
                Enabled: no
 3:2:0: NS DP83815
        0x0000: Vendor ID: 100b, Product ID: 0020
        0x0004: Command: 0107, Status: 0290
        0x0008: Class: 02 Network, Subclass: 00 Ethernet,
                Interface: 00, Revision: 00
        0x000c: BIST: 00, Header Type: 00, Latency Timer: 40,
                Cache Line Size: 00
        0x0010: BAR io addr: 0x0000cc00/0x0100
        0x0014: BAR mem 32bit addr: 0xfe6ff000/0x00001000
        0x0018: BAR empty (00000000)
        0x001c: BAR empty (00000000)
        0x0020: BAR empty (00000000)
        0x0024: BAR empty (00000000)
        0x0028: Cardbus CIS: 00000000
        0x002c: Subsystem Vendor ID: 1385 Product ID: f311
        0x0030: Expansion ROM Base Address: fe700000
        0x0038: 00000000
        0x003c: Interrupt Pin: 01 Line: 09 Min Gnt: 0b Max Lat: 34
        0x0040: Capability 0x01: Power Management
                State: D0
 

--
Sebastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Mark Kettenis
In reply to this post by Sebastien Marie-3
> Date: Wed, 7 Aug 2019 14:52:50 +0200
> From: Sebastien Marie <[hidden email]>
>
> On Wed, Aug 07, 2019 at 11:20:59AM +0200, Mark Kettenis wrote:
>  >
> > > I see no change in dmesg with my old state (Thu Jul 25 08:28:22 MDT
> > > 2019). I attached the current dmesg below (the radeondrm0 error and
> > > detach was already present before).
> > >
> > > The system uses VESA driver.
> >
> > The days of that driver (and other non-KMS non-wsfb drivers) are
> > numbered.  I'm seriously considering ripping out the "aperture" code
> > from the kernel at some point in the not too distant future.
> >
> > Not arguing this isn't a bug in X that we shouldn't try to fix.  However:
> >
> > initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
> > drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> > drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> > [TTM] Memory type 2 has not been initialized
> > drm0 detached
> > radeondrm0 detached
> > vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 Pro" rev 0x00
> >
> > appears to be the real problem here.  Is it possible for you to build
> > a kernel with DRMDEBUG turned on and send me and jsg@ the output?
>
> I built a kernel with DRMDEBUG and put 0xffff in drm_debug variable.
>
> initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
> [drm] COMBIOS detected
> drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> [drm] radeon: finishing device.
> [TTM] Memory type 2 has not been initialized
> [drm]
> drm0 detached
> radeondrm0 detached
> vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 Pro" rev 0x00
>
>
> I tried to follow a bit the initialisation path from radeon_get_bios():
> - radeon_get_bios()
>   - radeon_read_disabled_bios()
>     - r600_read_disabled_bios()
>       - init registers
>       - radeon_read_bios()
>       - restore registers

Can you try to figure out where exactly reading the BIOS from the card
goes wrong?

The thread at

  https://marc.info/?t=154237747300002&r=1&w=2

suggests that reading the BIOS works, but that the actual contents are
garbled.  But that the header check later in radeon_get_bios() fails.

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Matthieu Herrb-3
In reply to this post by Matthieu Herrb-3
On Wed, Aug 07, 2019 at 11:32:09AM +0200, Matthieu Herrb wrote:
>
> I will also have a look on why did the extra built-in modes disapear.
> But I think that if you can run a better driver than xf86-video-vesa,
> it is better.

Hi again,

I think I've found the problem.
It's caused by this commit:
https://gitlab.freedesktop.org/xorg/xserver/commit/fdc79fe72bc0b97776df2c3a664076c60e08a87c

Can you try this patch to xserver 1.20.5 ?

The reason why xf86PruneDuplicateModes() removes modes that are not
duplicated is still to be identified though.

Index: hw/xfree86/modes/xf86EdidModes.c
===================================================================
RCS file: /cvs/xenocara/xserver/hw/xfree86/modes/xf86EdidModes.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 xf86EdidModes.c
--- hw/xfree86/modes/xf86EdidModes.c 27 Jul 2019 07:57:17 -0000 1.18
+++ hw/xfree86/modes/xf86EdidModes.c 7 Aug 2019 17:42:14 -0000
@@ -1220,8 +1220,6 @@ xf86EdidMonitorSet(int scrnIndex, MonPtr
             Monitor->Modes = Modes;
         }
 
-        Monitor->Modes = xf86PruneDuplicateModes(Monitor->Modes);
-
         /* Update pointer to last mode */
         for (Mode = Monitor->Modes; Mode && Mode->next; Mode = Mode->next) {}
         Monitor->Last = Mode;


--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Sebastien Marie-3
In reply to this post by Mark Kettenis
On Wed, Aug 07, 2019 at 03:16:56PM +0200, Mark Kettenis wrote:

> >
> > I built a kernel with DRMDEBUG and put 0xffff in drm_debug variable.
> >
> > initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
> > [drm] COMBIOS detected
> > drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> > drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> > [drm] radeon: finishing device.
> > [TTM] Memory type 2 has not been initialized
> > [drm]
> > drm0 detached
> > radeondrm0 detached
> > vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 Pro" rev 0x00
> >
> >
> > I tried to follow a bit the initialisation path from radeon_get_bios():
> > - radeon_get_bios()
> >   - radeon_read_disabled_bios()
> >     - r600_read_disabled_bios()
> >       - init registers
> >       - radeon_read_bios()
> >       - restore registers
>
> Can you try to figure out where exactly reading the BIOS from the card
> goes wrong?

radeon_read_bios (called by r600_read_disabled_bios) returns something
good enough to pass some tests (bios signature check) and finally
returns true. the fail is later (in r600_init function, where it checks
for ATOM bios. it isn't so its abort init).

so I tried something stupid: commenting the call to
radeon_read_disabled_bios, in order to force radeon_get_bios to try
another way to get bios.

it called radeon_read_platform_bios() (the next method) and succeed. it
returned an ATOM bios (so r600_init is happy), radeondrm(4) finished its
initialization, and xenodm started correctly.

        $ dmesg
        ...
        initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
        radeondrm0: 1680x1050, 32bpp
        wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0
        ...

        $ xrandr                                                                             <
        Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192
        DIN disconnected primary (normal left inverted right x axis y axis)
        DVI-0 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 430mm x 270mm
           1680x1050     59.88*+
           1280x1024     75.02    60.02
           1152x864      75.00
           1024x768      75.03    60.00
           800x600       75.00    60.32
           640x480       75.00    59.94
           720x400       70.08

Below the patch for what I did (it could be more evident than my explain)

Index: radeon_bios.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_bios.c,v
retrieving revision 1.15
diff -u -p -r1.15 radeon_bios.c
--- radeon_bios.c 14 Apr 2019 10:14:54 -0000 1.15
+++ radeon_bios.c 7 Aug 2019 17:41:42 -0000
@@ -815,8 +815,10 @@ bool radeon_get_bios(struct radeon_devic
  r = igp_read_bios_from_vram(rdev);
  if (r == false)
  r = radeon_read_bios(rdev);
+#if 0
  if (r == false)
  r = radeon_read_disabled_bios(rdev);
+#endif
  if (r == false)
  r = radeon_read_platform_bios(rdev);
  if (r == false || rdev->bios == NULL) {


Now, I know it is only a workaround on this specific machine.

I still dunno if:

- radeon_read_disabled_bios() should return false (because it
  isn't the right way for this specific card), and so the use of
  radeon_read_platform_bios() is the right thing to do.

- radeon_read_disabled_bios() should return true and an ATOM bios,
  and calling radeon_read_platform_bios() is a workaround.

Thanks.
--
Sebastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Mark Kettenis
> Date: Wed, 7 Aug 2019 20:17:26 +0200
> From: Sebastien Marie <[hidden email]>
>
> On Wed, Aug 07, 2019 at 03:16:56PM +0200, Mark Kettenis wrote:
> > >
> > > I built a kernel with DRMDEBUG and put 0xffff in drm_debug variable.
> > >
> > > initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
> > > [drm] COMBIOS detected
> > > drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> > > drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> > > [drm] radeon: finishing device.
> > > [TTM] Memory type 2 has not been initialized
> > > [drm]
> > > drm0 detached
> > > radeondrm0 detached
> > > vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 Pro" rev 0x00
> > >
> > >
> > > I tried to follow a bit the initialisation path from radeon_get_bios():
> > > - radeon_get_bios()
> > >   - radeon_read_disabled_bios()
> > >     - r600_read_disabled_bios()
> > >       - init registers
> > >       - radeon_read_bios()
> > >       - restore registers
> >
> > Can you try to figure out where exactly reading the BIOS from the card
> > goes wrong?
>
> radeon_read_bios (called by r600_read_disabled_bios) returns something
> good enough to pass some tests (bios signature check) and finally
> returns true. the fail is later (in r600_init function, where it checks
> for ATOM bios. it isn't so its abort init).
>
> so I tried something stupid: commenting the call to
> radeon_read_disabled_bios, in order to force radeon_get_bios to try
> another way to get bios.
>
> it called radeon_read_platform_bios() (the next method) and succeed. it
> returned an ATOM bios (so r600_init is happy), radeondrm(4) finished its
> initialization, and xenodm started correctly.
>
> $ dmesg
> ...
> initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
> radeondrm0: 1680x1050, 32bpp
> wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0
> ...
>
> $ xrandr                                                                             <
> Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192
> DIN disconnected primary (normal left inverted right x axis y axis)
> DVI-0 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 430mm x 270mm
>   1680x1050     59.88*+
>   1280x1024     75.02    60.02
>   1152x864      75.00
>   1024x768      75.03    60.00
>   800x600       75.00    60.32
>   640x480       75.00    59.94
>   720x400       70.08
>
> Below the patch for what I did (it could be more evident than my explain)
>
> Index: radeon_bios.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_bios.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 radeon_bios.c
> --- radeon_bios.c 14 Apr 2019 10:14:54 -0000 1.15
> +++ radeon_bios.c 7 Aug 2019 17:41:42 -0000
> @@ -815,8 +815,10 @@ bool radeon_get_bios(struct radeon_devic
>   r = igp_read_bios_from_vram(rdev);
>   if (r == false)
>   r = radeon_read_bios(rdev);
> +#if 0
>   if (r == false)
>   r = radeon_read_disabled_bios(rdev);
> +#endif
>   if (r == false)
>   r = radeon_read_platform_bios(rdev);
>   if (r == false || rdev->bios == NULL) {
>
>
> Now, I know it is only a workaround on this specific machine.
>
> I still dunno if:
>
> - radeon_read_disabled_bios() should return false (because it
>   isn't the right way for this specific card), and so the use of
>   radeon_read_platform_bios() is the right thing to do.
>
> - radeon_read_disabled_bios() should return true and an ATOM bios,
>   and calling radeon_read_platform_bios() is a workaround.

Could you try booting an i386 kernel.  I think you can just boot the
kernel without reinstalling.  Obviously you'll crash as soon as it
tries to run init(8) but at that point the bios reading should already
have failed.

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Sebastien Marie-3
On Wed, Aug 07, 2019 at 11:12:57PM +0200, Mark Kettenis wrote:

> > > Can you try to figure out where exactly reading the BIOS from the card
> > > goes wrong?
> >
> > radeon_read_bios (called by r600_read_disabled_bios) returns something
> > good enough to pass some tests (bios signature check) and finally
> > returns true. the fail is later (in r600_init function, where it checks
> > for ATOM bios. it isn't so its abort init).
> >
> > so I tried something stupid: commenting the call to
> > radeon_read_disabled_bios, in order to force radeon_get_bios to try
> > another way to get bios.
> >
> > it called radeon_read_platform_bios() (the next method) and succeed. it
> > returned an ATOM bios (so r600_init is happy), radeondrm(4) finished its
> > initialization, and xenodm started correctly.
> >
> > [...]
> >
> > I still dunno if:
> >
> > - radeon_read_disabled_bios() should return false (because it
> >   isn't the right way for this specific card), and so the use of
> >   radeon_read_platform_bios() is the right thing to do.
> >
> > - radeon_read_disabled_bios() should return true and an ATOM bios,
> >   and calling radeon_read_platform_bios() is a workaround.
>
> Could you try booting an i386 kernel.  I think you can just boot the
> kernel without reinstalling.  Obviously you'll crash as soon as it
> tries to run init(8) but at that point the bios reading should already
> have failed.

Booting an i386 kernel to gain information wasn't as easy I expected:
amd64 bootloader doesn't boot i386 kernel (I don't recall if it is new
or not), and once I booted i386, debug-printf in init are on "old"
console, so once radeon succeed its initialisation I don't see them
anymore (and I have no keyboard in ddb).

With stock kernel, booting i386 kernel result on successfully
init radeondrm.  The method used for finding the bios is
radeon_read_platform_bios().

So with i386, radeon_read_disabled_bios() failed, and it returns false,
whereas it returns true on amd64 (and a "bad" bios, so r600_init aborts).

I will try to figure which part of radeon_read_disabled_bios() failed
on i386 in order to have some elements to understand why it didn't with
amd64.

Thanks.
--
Sebastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Sebastien Marie-3
In reply to this post by Matthieu Herrb-3
On Wed, Aug 07, 2019 at 07:47:43PM +0200, Matthieu Herrb wrote:

> On Wed, Aug 07, 2019 at 11:32:09AM +0200, Matthieu Herrb wrote:
> >
> > I will also have a look on why did the extra built-in modes disapear.
> > But I think that if you can run a better driver than xf86-video-vesa,
> > it is better.
>
> Hi again,
>
> I think I've found the problem.
> It's caused by this commit:
> https://gitlab.freedesktop.org/xorg/xserver/commit/fdc79fe72bc0b97776df2c3a664076c60e08a87c
>
> Can you try this patch to xserver 1.20.5 ?
>
> The reason why xf86PruneDuplicateModes() removes modes that are not
> duplicated is still to be identified though.
>
> Index: hw/xfree86/modes/xf86EdidModes.c
> ===================================================================
> RCS file: /cvs/xenocara/xserver/hw/xfree86/modes/xf86EdidModes.c,v
> retrieving revision 1.18
> diff -u -p -u -r1.18 xf86EdidModes.c
> --- hw/xfree86/modes/xf86EdidModes.c 27 Jul 2019 07:57:17 -0000 1.18
> +++ hw/xfree86/modes/xf86EdidModes.c 7 Aug 2019 17:42:14 -0000
> @@ -1220,8 +1220,6 @@ xf86EdidMonitorSet(int scrnIndex, MonPtr
>              Monitor->Modes = Modes;
>          }
>  
> -        Monitor->Modes = xf86PruneDuplicateModes(Monitor->Modes);
> -
>          /* Update pointer to last mode */
>          for (Mode = Monitor->Modes; Mode && Mode->next; Mode = Mode->next) {}
>          Monitor->Last = Mode;
>

I confirm the diff solves the issue.

[    39.848] (II) VESA(0): Total Memory: 256 64KB banks (16384kB)
[    39.848] (II) VESA(0): <default monitor>: Using hsync range of 30.00-83.00 kHz
[    39.848] (II) VESA(0): <default monitor>: Using vrefresh range of 56.00-75.00 Hz
[    39.848] (II) VESA(0): <default monitor>: Using maximum pixel clock of 145.00 MHz
[    39.848] (WW) VESA(0): Unable to estimate virtual size
[    39.848] (II) VESA(0): Not using built-in mode "1400x1050" (no mode of this name)
[    39.848] (II) VESA(0): Not using built-in mode "640x400" (no mode of this name)
[    39.848] (II) VESA(0): Not using built-in mode "640x400" (no mode of this name)
[    39.848] (II) VESA(0): Not using built-in mode "640x350" (no mode of this name)
[    39.848] (II) VESA(0): Not using built-in mode "512x384" (no mode of this name)
[    39.848] (II) VESA(0): Not using built-in mode "320x240" (no mode of this name)
[    39.848] (II) VESA(0): Not using built-in mode "320x200" (no mode of this name)
[    39.848] (II) VESA(0): Virtual size is 1280x1024 (pitch 1280)
[    39.848] (**) VESA(0): *Built-in mode "1280x1024"
[    39.848] (**) VESA(0): *Built-in mode "1280x1024"
[    39.848] (**) VESA(0): *Built-in mode "1152x864"
[    39.849] (**) VESA(0): *Built-in mode "1024x768"
[    39.849] (**) VESA(0): *Built-in mode "800x600"
[    39.849] (**) VESA(0): *Built-in mode "640x480"
[    39.849] (**) VESA(0): *Built-in mode "720x400"
[    39.849] (**) VESA(0): Display dimensions: (430, 270) mm
[    39.849] (**) VESA(0): DPI set to (75, 96)
[    39.849] (**) VESA(0): Using "Shadow Framebuffer"

The virtual size isn't "720x400" anymore.

Thanks.
--
Sebastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Matthieu Herrb-3
On Thu, Aug 08, 2019 at 09:42:49AM +0200, Sebastien Marie wrote:

> On Wed, Aug 07, 2019 at 07:47:43PM +0200, Matthieu Herrb wrote:
> > On Wed, Aug 07, 2019 at 11:32:09AM +0200, Matthieu Herrb wrote:
> > >
> > > I will also have a look on why did the extra built-in modes disapear.
> > > But I think that if you can run a better driver than xf86-video-vesa,
> > > it is better.
> >
> > Hi again,
> >
> > I think I've found the problem.
> > It's caused by this commit:
> > https://gitlab.freedesktop.org/xorg/xserver/commit/fdc79fe72bc0b97776df2c3a664076c60e08a87c
> >
> > Can you try this patch to xserver 1.20.5 ?
> >
> > The reason why xf86PruneDuplicateModes() removes modes that are not
> > duplicated is still to be identified though.
> >
> > Index: hw/xfree86/modes/xf86EdidModes.c
> > ===================================================================
> > RCS file: /cvs/xenocara/xserver/hw/xfree86/modes/xf86EdidModes.c,v
> > retrieving revision 1.18
> > diff -u -p -u -r1.18 xf86EdidModes.c
> > --- hw/xfree86/modes/xf86EdidModes.c 27 Jul 2019 07:57:17 -0000 1.18
> > +++ hw/xfree86/modes/xf86EdidModes.c 7 Aug 2019 17:42:14 -0000
> > @@ -1220,8 +1220,6 @@ xf86EdidMonitorSet(int scrnIndex, MonPtr
> >              Monitor->Modes = Modes;
> >          }
> >  
> > -        Monitor->Modes = xf86PruneDuplicateModes(Monitor->Modes);
> > -
> >          /* Update pointer to last mode */
> >          for (Mode = Monitor->Modes; Mode && Mode->next; Mode = Mode->next) {}
> >          Monitor->Last = Mode;
> >
>
> I confirm the diff solves the issue.

Thanks. I will try to debug this a bit more. I tried this with radeon,
intel and modesettings drivers. It doesn't change anything with those.


--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Sebastien Marie-3
In reply to this post by Sebastien Marie-3
On Thu, Aug 08, 2019 at 06:57:57AM +0200, Sebastien Marie wrote:

> On Wed, Aug 07, 2019 at 11:12:57PM +0200, Mark Kettenis wrote:
> > > > Can you try to figure out where exactly reading the BIOS from the card
> > > > goes wrong?
> > >
> > > radeon_read_bios (called by r600_read_disabled_bios) returns something
> > > good enough to pass some tests (bios signature check) and finally
> > > returns true. the fail is later (in r600_init function, where it checks
> > > for ATOM bios. it isn't so its abort init).
> > >
> > > so I tried something stupid: commenting the call to
> > > radeon_read_disabled_bios, in order to force radeon_get_bios to try
> > > another way to get bios.
> > >
> > > it called radeon_read_platform_bios() (the next method) and succeed. it
> > > returned an ATOM bios (so r600_init is happy), radeondrm(4) finished its
> > > initialization, and xenodm started correctly.
> > >
> > > [...]
> > >
> > > I still dunno if:
> > >
> > > - radeon_read_disabled_bios() should return false (because it
> > >   isn't the right way for this specific card), and so the use of
> > >   radeon_read_platform_bios() is the right thing to do.
> > >
> > > - radeon_read_disabled_bios() should return true and an ATOM bios,
> > >   and calling radeon_read_platform_bios() is a workaround.
> >
> > Could you try booting an i386 kernel.  I think you can just boot the
> > kernel without reinstalling.  Obviously you'll crash as soon as it
> > tries to run init(8) but at that point the bios reading should already
> > have failed.
>
> Booting an i386 kernel to gain information wasn't as easy I expected:
> amd64 bootloader doesn't boot i386 kernel (I don't recall if it is new
> or not), and once I booted i386, debug-printf in init are on "old"
> console, so once radeon succeed its initialisation I don't see them
> anymore (and I have no keyboard in ddb).
>
> With stock kernel, booting i386 kernel result on successfully
> init radeondrm.  The method used for finding the bios is
> radeon_read_platform_bios().

While searching where radeon_read_disabled_bios would fail on i386, I
found I missinterpreted my debug message. i386 is able to read valid
bios with radeon_read_disabled_bios(), and radeondrm is successfully
initialized.

my bad.

I will try to compare i386 and amd64 in r600_read_disabled_bios().

--
Sebastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: xserver problem with 1.19.7->1.20.5

Sebastien Marie-3
On Thu, Aug 08, 2019 at 10:23:15AM +0200, Sebastien Marie wrote:
>
> I will try to compare i386 and amd64 in r600_read_disabled_bios().

I didn't found any major difference between i386 and amd64. the values
below are the same for i386 and amd64.

- radeon_get_bios()
  - radeon_read_disabled_bios()
    - r600_read_disabled_bios()
      - save registers
        ## viph_control = 0x0
        ## bus_cntl = 0x0
        ## d1vga_control = 0x1
        ## d2vga_control = 0x401
        ## vga_render_control = 0x201000f
        ## rom_cntl = 0x11030300
        ## general_pwrmgt = 0x7e08
        ## low_vid_lower_gpio_cntl = 0x0
        ## medium_vid_lower_gpio_cntl = 0x0
        ## high_vid_lower_gpio_cntl = 0x0
        ## ctxsw_vid_lower_gpio_cntl = 0x0
        ## lower_gpio_enable = 0x0
      - set new values to register to read the bios
      - radeon_read_bios()
        ##┬ásize=131072
        ## bios[0,1]={0x55,0xaa}
      - restore registers
  - check the bios
    ##┬ásignature correct ({0x55,0xaa})
    ## bios_header_start=0x19a

when looking `rdev->bios + tmp' values (memcmp "ATOM" || "MOTA" to set
rdev->is_atom_bios), amd64 has 00 00 4f 4d ("\0\0OM") whereas i386 has
41 54 4f 4d ("ATOM").

--
Sebastien Marie