xf86-video-ati-legacy port status

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

xf86-video-ati-legacy port status

Igor Pokrovsky-3
Hello!

Are there plans to fix port/xf86-video-ati-legacy? I have tried the
patch from commit messages on both amd64 and i386 and it fails.

-ip

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Igor Pokrovsky-3
On Thu, May 28, 2020 at 02:06:18PM +0700, Alexey Dokuchaev wrote:
> On Wed, May 27, 2020 at 09:29:18PM +0400, Igor Pokrovsky wrote:
> It's on my radar (I'm happily using it right now with xorg-server-1.18.4
> and drm-legacy-kmod-g20190213, so it would be nice to unbreak it against
> new xorg-server), but somewhat low-priority.  May I ask what does not
> work for you with xf86-video-ati-19.1.0?  I haven't heard of regressions
> other than invisible HW mouse pointer but that had been fixed in April.

With xf86-video-ati-19.1.0 I'm getting the following error in Xorg log:
(EE) RADEON(0): Failed to enable any CRTC

Here are some DRM related messages from kernel:

info: [drm] Initialized drm 1.1.0 20060810
drmn0: <ATI Radeon HD3850> on vgapci0
info: [drm] RADEON_IS_AGP
info: [drm] initializing kernel modesetting (RV670 0x1002:0x9515 0x174B:0x0028).
info: [drm] register mmio base: 0xFBF00000
info: [drm] register mmio size: 65536
info: [drm] radeon_atrm_get_bios: ===> Try ATRM...
info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, vendor=1002, device=9515
info: [drm] radeon_atrm_get_bios: Get ACPI device handle
info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT...
info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table
info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND
info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM...
info: [drm] igp_read_bios_from_vram: VRAM base address: 0xe0000000
info: [drm] igp_read_bios_from_vram: Map address: 0x1ec55000 (262144 bytes)
info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000
info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM...
info: [drm] radeon_read_bios: Map address: 0x4c0000 (131072 bytes)
info: [drm] ATOM BIOS:
drmn0: info: GTT: 64M 0xDC000000 - 0xDFFFFFFF
drmn0: info: VRAM: 512M 0xBC000000 - 0xDBFFFFFF (512M used)
info: [drm] Detected VRAM RAM=512M, BAR=256M
info: [drm] RAM width 256bits DDR
[TTM] Zone  kernel: Available graphics memory: 1029704 kiB
[TTM] Initializing pool allocator
info: [drm] radeon: 512M of VRAM memory ready
info: [drm] radeon: 64M of GTT memory ready.
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
info: [drm] radeon: irq initialized.
info: [drm] GART: num cpu pages 16384, num gpu pages 16384
info: [drm] Loading RV670 Microcode
radeon/RV670_pfp.bin: could not load firmware image, error 2
radeon/RV670_pfp.bin: could not load firmware image, error 2
drmn0: Successfully loaded firmware image with name (mapped name): radeon/RV670_pfp.bin (radeon_RV670_pfp_bin)
radeon/RV670_me.bin: could not load firmware image, error 2
radeon/RV670_me.bin: could not load firmware image, error 2
drmn0: Successfully loaded firmware image with name (mapped name): radeon/RV670_me.bin (radeon_RV670_me_bin)
radeon/R600_rlc.bin: could not load firmware image, error 2
radeon/R600_rlc.bin: could not load firmware image, error 2
drmn0: Successfully loaded firmware image with name (mapped name): radeon/R600_rlc.bin (radeon_R600_rlc_bin)
drmn0: info: WB disabled
drmn0: info: fence driver on ring 0 use gpu addr 0x00000000dc000004 and cpu addr 0x0x77ff004
drmn0: info: fence driver on ring 3 use gpu addr 0x00000000dc000c0c and cpu addr 0x0x77ffc0c
info: [drm] ring test on 0 succeeded in 1 usecs
info: [drm] ring test on 3 succeeded in 1 usecs
info: [drm] ib test on ring 0 succeeded in 0 usecs
info: [drm] ib test on ring 3 succeeded in 1 usecs
info: [drm] radeon_device_init: Taking over the fictitious range 0xe0000000-0xf0000000
info: [drm] radeon_device_init: Taking over the fictitious range 0xdc000000-0xe0000000
radeon_iicbb0 on drmn0
iicbus0: <Philips I2C bus> on iicbb0 addr 0x0
iic0: <I2C generic I/O> on iicbus0
iicsmb0: <SMBus over I2C bridge> on iicbus0
smbus0: <System Management Bus> on iicsmb0
smb0: <SMBus generic I/O> on smbus0
radeon_iicbb1 on drmn0
iicbus1: <Philips I2C bus> on iicbb1 addr 0x20
iic1: <I2C generic I/O> on iicbus1
iicsmb1: <SMBus over I2C bridge> on iicbus1
smbus1: <System Management Bus> on iicsmb1
smb1: <SMBus generic I/O> on smbus1
radeon_iicbb2 on drmn0
iicbus2: <Philips I2C bus> on iicbb2 addr 0x20
iic2: <I2C generic I/O> on iicbus2
iicsmb2: <SMBus over I2C bridge> on iicbus2
smbus2: <System Management Bus> on iicsmb2
smb2: <SMBus generic I/O> on smbus2
radeon_iicbb3 on drmn0
iicbus3: <Philips I2C bus> on iicbb3 addr 0x20
iic3: <I2C generic I/O> on iicbus3
iicsmb3: <SMBus over I2C bridge> on iicbus3
smbus3: <System Management Bus> on iicsmb3
smb3: <SMBus generic I/O> on smbus3
radeon_iicbb4 on drmn0
iicbus4: <Philips I2C bus> on iicbb4 addr 0x20
iic4: <I2C generic I/O> on iicbus4
iicsmb4: <SMBus over I2C bridge> on iicbus4
smbus4: <System Management Bus> on iicsmb4
smb4: <SMBus generic I/O> on smbus4
info: [drm] Radeon Display Connectors
info: [drm] Connector 0:
info: [drm]   DVI-I-1
info: [drm]   HPD1
info: [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
info: [drm]   Encoders:
info: [drm]     DFP1: INTERNAL_KLDSCP_TMDS1
info: [drm]     CRT2: INTERNAL_KLDSCP_DAC2
info: [drm] Connector 1:
info: [drm]   DIN-1
info: [drm]   Encoders:
info: [drm]     TV1: INTERNAL_KLDSCP_DAC2
info: [drm] Connector 2:
info: [drm]   DVI-I-2
info: [drm]   HPD2
info: [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
info: [drm]   Encoders:
info: [drm]     CRT1: INTERNAL_KLDSCP_DAC1
info: [drm]     DFP2: INTERNAL_LVTM1
info: [drm] Internal thermal controller with fan control
info: [drm] radeon: power management initialized
info: [drm] Connector DVI-I-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.DVI-I-1
info: [drm]   - kern.vt.fb.default_mode
info: [drm] Connector DIN-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.DIN-1
info: [drm]   - kern.vt.fb.default_mode
info: [drm] Connector DVI-I-2: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.DVI-I-2
info: [drm]   - kern.vt.fb.default_mode
info: [drm] fb mappable at 0xE0062000
info: [drm] vram apper at 0xE0000000
info: [drm] size 1228800
info: [drm] fb depth is 24
info: [drm]    pitch is 2560
fbd0 on drmn0
VT: Replacing driver "vga" with new "fb".
info: [drm] Initialized radeon 2.29.0 20080528 for drmn0 on minor 0
drmn0: error: No GEM object associated to handle 0x00000438, can't create framebuffer
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Andrea Venturoli
On 2020-05-28 19:49, Igor Pokrovsky wrote:

>> May I ask what does not
>> work for you with xf86-video-ati-19.1.0?  I haven't heard of regressions
>> other than invisible HW mouse pointer but that had been fixed in April.

Hello, and sorry to step in.

I've reported two cases on this list, where the new stuff does not work.



Radeon HD5450 works perfectly for a couple of hours/half day then panics.

Radeon HD4250: just loading new drm-kmod prevent DVI and HDMI outputs
from working (only VGA remains); using VGA works, but panics as above.



I'd happily put some work on this, but I can't seem be able to get going.

  bye
        av.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Niclas Zeising-6
In reply to this post by Igor Pokrovsky-3
On 2020-05-27 19:29, Igor Pokrovsky wrote:
> Hello!
>
> Are there plans to fix port/xf86-video-ati-legacy? I have tried the
> patch from commit messages on both amd64 and i386 and it fails.

Hi!
Unfortunately it is very hard to fix it.  There has been several changes
in how xorg-server interacts with the xf86 drivers, and the version
xf86-video-ati-legacy was based on was very old and not compatible with
xserver 1.20.
If anyone can make xf86-video-ati-legacy work with xserver 1.20 we can
get the patches in, but I don't have the time to work on
xf86-video-ati-legacy myself.
Regards
--
Niclas Zeising
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Andrea Venturoli
On 2020-05-29 10:42, Niclas Zeising wrote:

> Unfortunately it is very hard to fix it.  There has been several changes
> in how xorg-server interacts with the xf86 drivers, and the version
> xf86-video-ati-legacy was based on was very old and not compatible with
> xserver 1.20.
> If anyone can make xf86-video-ati-legacy work with xserver 1.20 we can
> get the patches in, but I don't have the time to work on
> xf86-video-ati-legacy myself.

Agreed, but it's really the non-legacy version that should be fixed.



At a bare minimum, documentation should be updated to report what really
works (not what should work but doesn't).

As I said my integrated Radeon GPU does not work at all with new Xorg; I
found another Radeon card laying around and tried that: it's better but
still not there. Both are reported as "working" on the wiki.

Now, if I decided to go ahead and buy a new card, I wouldn't know what
to buy: I could check the wiki, get a card which is listed there and
discover I just wasted my money?

  bye
        av.

P.S.
BTW, I also have a laptop with CPU integrated Intel graphics: again,
it's listed as just working, but I had to step through hops to avoid
hangs and I still often get screen corruption.
So even if I decided to change the whole box and get an Intel CPU, I'm
not sure what to expect.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Andrea Venturoli
On 2020-05-30 14:13, Alexey Dokuchaev wrote:
> Seeing all this fallout after the recent X.Org update I'm seriously
> considering creating xorg-server-19 or xorg-server-18 port so we can
> get our FreeBSD graphic stack back.  Right now it's simply broken for
> too many people. :-(

More or less what I did on my private side :(
N.B. This is not something complete that I could publish or pass to
others, since I only did the bits I'm interested in, knowing it's not
the way to go.

  bye
        av.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Warner Losh
In reply to this post by Andrea Venturoli
On Sat, May 30, 2020 at 12:56 AM Andrea Venturoli <[hidden email]> wrote:

> On 2020-05-29 10:42, Niclas Zeising wrote:
>
> > Unfortunately it is very hard to fix it.  There has been several changes
> > in how xorg-server interacts with the xf86 drivers, and the version
> > xf86-video-ati-legacy was based on was very old and not compatible with
> > xserver 1.20.
> > If anyone can make xf86-video-ati-legacy work with xserver 1.20 we can
> > get the patches in, but I don't have the time to work on
> > xf86-video-ati-legacy myself.
>
> Agreed, but it's really the non-legacy version that should be fixed.
>

Yes. Another heroic fix isn't going to help the project in the long run.


> At a bare minimum, documentation should be updated to report what really
> works (not what should work but doesn't).
>

This list might be rather long, and ambiguous...


> As I said my integrated Radeon GPU does not work at all with new Xorg; I
> found another Radeon card laying around and tried that: it's better but
> still not there. Both are reported as "working" on the wiki.
>

That, at least, should be udated.


> Now, if I decided to go ahead and buy a new card, I wouldn't know what
> to buy: I could check the wiki, get a card which is listed there and
> discover I just wasted my money?
>

fair point. Something much newer should just work, but I understand your
hesitation.

BTW, I also have a laptop with CPU integrated Intel graphics: again,
> it's listed as just working, but I had to step through hops to avoid
> hangs and I still often get screen corruption.
> So even if I decided to change the whole box and get an Intel CPU, I'm
> not sure what to expect.
>

Yea. Most newer intel just work, though some with workarounds. Super-new
intel requires the latest drm-devel port and -current.

But honestly, when we have just volunteers doing all this, having a
specific, long list of what's know working and not is hard: it's hardware
intensive, labor intensive and requires a large capital investment for both
the gear, and a large operating cost to keep it powered, part of regression
tests, etc.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Igor Pokrovsky-3
In reply to this post by Igor Pokrovsky-3
On Thu, May 28, 2020 at 02:06:18PM +0700, Alexey Dokuchaev wrote:
> On Wed, May 27, 2020 at 09:29:18PM +0400, Igor Pokrovsky wrote:
> It's on my radar (I'm happily using it right now with xorg-server-1.18.4
> and drm-legacy-kmod-g20190213, so it would be nice to unbreak it against
> new xorg-server), but somewhat low-priority.  May I ask what does not
> work for you with xf86-video-ati-19.1.0?  I haven't heard of regressions
> other than invisible HW mouse pointer but that had been fixed in April.
>
> ./danfe

I have successfully downgraded xorg-server to 1.18.4 and with latest
xf86-video-ati-19.1.0_3,1 I finally have xorg starting correctly. No need
for xf86-video-ati-legacy port indeed. Thanks for clues, Alexey!

-ip

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Emmanuel Vadot-7
In reply to this post by Andrea Venturoli
On Sat, 30 May 2020 08:56:25 +0200
Andrea Venturoli <[hidden email]> wrote:

> On 2020-05-29 10:42, Niclas Zeising wrote:
>
> > Unfortunately it is very hard to fix it.  There has been several changes
> > in how xorg-server interacts with the xf86 drivers, and the version
> > xf86-video-ati-legacy was based on was very old and not compatible with
> > xserver 1.20.
> > If anyone can make xf86-video-ati-legacy work with xserver 1.20 we can
> > get the patches in, but I don't have the time to work on
> > xf86-video-ati-legacy myself.
>
> Agreed, but it's really the non-legacy version that should be fixed.

 Agreed,
 Please post full dmesg, pciconf -vl, pkg info and Xorg.log somewhere

>
>
> At a bare minimum, documentation should be updated to report what really
> works (not what should work but doesn't).

 I'm working on an image that will test all that.

> As I said my integrated Radeon GPU does not work at all with new Xorg; I
> found another Radeon card laying around and tried that: it's better but
> still not there. Both are reported as "working" on the wiki.
>
> Now, if I decided to go ahead and buy a new card, I wouldn't know what
> to buy: I could check the wiki, get a card which is listed there and
> discover I just wasted my money?
>
>   bye
> av.
>
> P.S.
> BTW, I also have a laptop with CPU integrated Intel graphics: again,
> it's listed as just working, but I had to step through hops to avoid
> hangs and I still often get screen corruption.

 Same as above, without info on what hardware you have it's hard to
help.
 I'm happily running FreeBSD 13-CURRENT on Broadwell, Skylake and
WhiskeyLake without any problems.

> So even if I decided to change the whole box and get an Intel CPU, I'm
> not sure what to expect.
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "[hidden email]"


--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Andrea Venturoli
On 2020-06-01 21:15, Emmanuel Vadot wrote:

>   Agreed,
>   Please post full dmesg, pciconf -vl, pkg info and Xorg.log somewhere

https://lists.freebsd.org/pipermail/freebsd-x11/2020-May/025989.html



The above is what matters most to me.
The other Radeon card does not work properly with Linux either, so,
given the limited resource we have, I guess we should forget about it.

Notice, as I said previously, I'd be very happy to help debugging this:
unfortunately remote GDB hangs. If someone could help me overcome this
stopper...





>> BTW, I also have a laptop with CPU integrated Intel graphics: again,
>> it's listed as just working, but I had to step through hops to avoid
>> hangs and I still often get screen corruption.
>
>   Same as above, without info on what hardware you have it's hard to
> help.
>   I'm happily running FreeBSD 13-CURRENT on Broadwell, Skylake and
> WhiskeyLake without any problems.

I don't have access to this machine now; IIRC it's a Sandy Bridge
Pentium (but still running 11.3).

If needed, I can get full data the first time I have the chance, but
this is less important to me: I've been having corruption for years, and
it's usually enough to minimize the windows and restore it, to make it
go away.
The panic with the Radeon card is a much worse thing.



  bye & Thanks
        av.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Niclas Zeising-6
On 2020-06-02 10:13, Andrea Venturoli wrote:

> On 2020-06-01 21:15, Emmanuel Vadot wrote:
>
>>   Agreed,
>>   Please post full dmesg, pciconf -vl, pkg info and Xorg.log somewhere
>
> https://lists.freebsd.org/pipermail/freebsd-x11/2020-May/025989.html
>
>
>
> The above is what matters most to me.
> The other Radeon card does not work properly with Linux either, so,
> given the limited resource we have, I guess we should forget about it.

As a quick note, if a card doesn't work properly on Linux, it most
likely doesn't work on FreeBSD either, since we are using the Linux driver.

Regards
--
Niclas Zeising
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Andrea Venturoli
On 2020-06-02 10:16, Niclas Zeising wrote:

> As a quick note, if a card doesn't work properly on Linux, it most
> likely doesn't work on FreeBSD either, since we are using the Linux driver.

I know.
I just find it strange it works with legacy stuff.

  bye
        av.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Scott Bennett
In reply to this post by Andrea Venturoli
Andrea Venturoli <[hidden email]> wrote:

> On 2020-06-01 21:15, Emmanuel Vadot wrote:
>
> >   Agreed,
> >   Please post full dmesg, pciconf -vl, pkg info and Xorg.log somewhere
>
> https://lists.freebsd.org/pipermail/freebsd-x11/2020-May/025989.html
>
>
>
> The above is what matters most to me.
> The other Radeon card does not work properly with Linux either, so,
> given the limited resource we have, I guess we should forget about it.
>
> Notice, as I said previously, I'd be very happy to help debugging this:
> unfortunately remote GDB hangs. If someone could help me overcome this
> stopper...
>
>
>
>
>
> >> BTW, I also have a laptop with CPU integrated Intel graphics: again,
> >> it's listed as just working, but I had to step through hops to avoid
> >> hangs and I still often get screen corruption.
> >
> >   Same as above, without info on what hardware you have it's hard to
> > help.
> >   I'm happily running FreeBSD 13-CURRENT on Broadwell, Skylake and
> > WhiskeyLake without any problems.
>
> I don't have access to this machine now; IIRC it's a Sandy Bridge
> Pentium (but still running 11.3).
>
> If needed, I can get full data the first time I have the chance, but
> this is less important to me: I've been having corruption for years, and
> it's usually enough to minimize the windows and restore it, to make it
> go away.
> The panic with the Radeon card is a much worse thing.
>
     Perhaps you posted your panic messages, and I missed them, but I've
been wondering whether you actually get a panic screen with all sorts of
kernel panic messages, or do you instead get a hard BIOS reset in an
attempt by the DRM driver to reboot your system?  The reason I ask is that
the latter is what happens when running xorg on a Radeon HD 5770, and after
a reboot I can see the final messages that were written to /var/log/messages
just before the reset.  Those messages indicated that the GPU had crashed
(bug #1).  The improper response by the DRM driver is bug #2/design flaw #1,
depending upon how you view such things, although a design document might
well resolve which sort of error was made.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Andrea Venturoli
On 2020-06-02 11:12, Scott Bennett wrote:

>> https://lists.freebsd.org/pipermail/freebsd-x11/2020-May/025989.html

>       Perhaps you posted your panic messages, and I missed them,

Link is above.





> but I've
> been wondering whether you actually get a panic screen with all sorts of
> kernel panic messages,

Yes: the system drops into DDB.



> or do you instead get a hard BIOS reset

No.



> in an attempt by the DRM driver to reboot your system?

Here I'm not so sure... I guess not, since what I get is "panic: page
fault".



> The reason I ask is that
> the latter is what happens when running xorg on a Radeon HD 5770, and after
> a reboot I can see the final messages that were written to /var/log/messages
> just before the reset.  Those messages indicated that the GPU had crashed
> (bug #1).  The improper response by the DRM driver is bug #2/design flaw #1,
> depending upon how you view such things, although a design document might
> well resolve which sort of error was made.

I don't seem to follow you here.
Are those # references to some bug list?
Where?



  bye & Thanks
        av.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Scott Bennett
Andrea Venturoli <[hidden email]> wrote:

> On 2020-06-02 11:12, Scott Bennett wrote:
>
> >> https://lists.freebsd.org/pipermail/freebsd-x11/2020-May/025989.html
>
> >       Perhaps you posted your panic messages, and I missed them,
>
> Link is above.
>
     Oh, I see.  Okay, that is something quite different.

>
> > but I've
> > been wondering whether you actually get a panic screen with all sorts of
> > kernel panic messages,
>
> Yes: the system drops into DDB.
>
> > or do you instead get a hard BIOS reset
>
> No.
>
> > in an attempt by the DRM driver to reboot your system?
>
> Here I'm not so sure... I guess not, since what I get is "panic: page
> fault".
>
     Right.

>
> > The reason I ask is that
> > the latter is what happens when running xorg on a Radeon HD 5770, and after
> > a reboot I can see the final messages that were written to /var/log/messages
> > just before the reset.  Those messages indicated that the GPU had crashed
> > (bug #1).  The improper response by the DRM driver is bug #2/design flaw #1,
> > depending upon how you view such things, although a design document might
> > well resolve which sort of error was made.
>
> I don't seem to follow you here.
> Are those # references to some bug list?

     Not at all.  I was just pointing out that there appear to be two distinct
bugs involved that make running xorg on a Radeon HD 5770 very dangerous to
production operations.  The numbering merely reflects the order in which they
occur in crashing my system.  Bug #1 is probably in a gpu-firmware-kmod module
loaded by drm-fbsd11.2-kmod.  Bug #2/design flaw #1 happens second and is the
decision to crash the system, rather than reinitialize the GPU when it has hung
or crashed.  Bug #1 has thus far always occurred within 36 hours of starting
xorg, and because bug #2 means the response to bug #1, on my system it always
results in lost mprime work and taking down my tor relay.  The latter means the
relay loses its Stable flag status (determined hourly by the directory
authorities), which isn't regained until the relay has remained up and running
for several days again.
     So my choices are run tor or run xorg, dealing with the crashes and the
nuisance of cleaning up the wreckage every time.  Because I don't dare run xorg,
I have no way to file PRs, so the problems never get addressed.  It's a nice way
for the graphics team to shrug off a pair of bugs without doing anything to fix
them.
     BTW, you needn't insert all those extraneous blank lines in your postings.
I deleted a bunch of them in this followup.

                                        Scott
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Kevin Oberman-4
In reply to this post by Andrea Venturoli
On Tue, Jun 2, 2020 at 1:13 AM Andrea Venturoli <[hidden email]> wrote:

> On 2020-06-01 21:15, Emmanuel Vadot wrote:
>
> >   Agreed,
> >   Please post full dmesg, pciconf -vl, pkg info and Xorg.log somewhere
>
> https://lists.freebsd.org/pipermail/freebsd-x11/2020-May/025989.html
>
>
>
> The above is what matters most to me.
> The other Radeon card does not work properly with Linux either, so,
> given the limited resource we have, I guess we should forget about it.
>
> Notice, as I said previously, I'd be very happy to help debugging this:
> unfortunately remote GDB hangs. If someone could help me overcome this
> stopper...
>
>
>
>
>
> >> BTW, I also have a laptop with CPU integrated Intel graphics: again,
> >> it's listed as just working, but I had to step through hops to avoid
> >> hangs and I still often get screen corruption.
> >
> >   Same as above, without info on what hardware you have it's hard to
> > help.
> >   I'm happily running FreeBSD 13-CURRENT on Broadwell, Skylake and
> > WhiskeyLake without any problems.
>
> I don't have access to this machine now; IIRC it's a Sandy Bridge
> Pentium (but still running 11.3).
>
> If needed, I can get full data the first time I have the chance, but
> this is less important to me: I've been having corruption for years, and
> it's usually enough to minimize the windows and restore it, to make it
> go away.


I have had no issues with my Sandy Bridge system since shortly after the
Linux-based drivers were implemented. I started using the test versions
prior to their official release and have had few issues since. U am unclear
about the "Pentium" reference, though. While Core processors are
descendants of Pentium, Sandy Bridge came long after Intel had moved to
Core processors, so I have no idea what "Pentium" means in this context. My
CPU is a Core i5-2520M, now 9 years old.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: [hidden email]
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: xf86-video-ati-legacy port status

Andrea Venturoli
On 2020-06-02 18:53, Kevin Oberman wrote:

> U am
> unclear about the "Pentium" reference, though. While Core processors are
> descendants of Pentium, Sandy Bridge came long after Intel had moved to
> Core processors, so I have no idea what "Pentium" means in this context.

There are Core-based "Pentium"-branded CPUs.
They are positioned half-way between "Celeron"s and "i3"s.

Their features varies in times: some years ago they were almost
identical to i3s. Today I believe they are possibly older models with
fewer cores.

  bye
        av.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"