Re: [HEADS UP] drm merged to -STABLE
On Wed, Mar 18, 2009 at 09:22:37PM -0500, Robert Noland wrote: On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote: [snip] I'm curious about why the drm driver calls this card a RV370, while pciconf and the X server call it a RV380: pciconf: RV380 RADEON X600 Series 265MB I'm not sure where pciconf gets it's data. I would actaully like to look at that. According to the pciconf(8) manpage: The PCI vendor/device information database is normally read from /usr/share/misc/pci_vendors. This path can be overridden by setting the environment variable PCICONF_VENDOR_DATABASE. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Thu, 2009-03-19 at 07:14 +0100, Erik Trulsson wrote: On Wed, Mar 18, 2009 at 09:22:37PM -0500, Robert Noland wrote: On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote: [snip] I'm curious about why the drm driver calls this card a RV370, while pciconf and the X server call it a RV380: pciconf: RV380 RADEON X600 Series 265MB I'm not sure where pciconf gets it's data. I would actaully like to look at that. According to the pciconf(8) manpage: The PCI vendor/device information database is normally read from /usr/share/misc/pci_vendors. This path can be overridden by setting the environment variable PCICONF_VENDOR_DATABASE. Right, that is just the vendor id though, not the device name string. The reason that I'm curious is that I was trying to extract device name info from Nvidia cards the other day, without using a static data source. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Thu, Mar 19, 2009 at 02:04:14AM -0500, Robert Noland wrote: On Thu, 2009-03-19 at 07:14 +0100, Erik Trulsson wrote: On Wed, Mar 18, 2009 at 09:22:37PM -0500, Robert Noland wrote: On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote: [snip] I'm curious about why the drm driver calls this card a RV370, while pciconf and the X server call it a RV380: pciconf: RV380 RADEON X600 Series 265MB I'm not sure where pciconf gets it's data. I would actaully like to look at that. According to the pciconf(8) manpage: The PCI vendor/device information database is normally read from /usr/share/misc/pci_vendors. This path can be overridden by setting the environment variable PCICONF_VENDOR_DATABASE. Right, that is just the vendor id though, not the device name string. Have you actually looked at the contents of that file? All the strings describing vendor and device name that pciconf prints can be found in that file. The reason that I'm curious is that I was trying to extract device name info from Nvidia cards the other day, without using a static data source. robert. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Thu, 2009-03-19 at 10:02 +0100, Erik Trulsson wrote: On Thu, Mar 19, 2009 at 02:04:14AM -0500, Robert Noland wrote: On Thu, 2009-03-19 at 07:14 +0100, Erik Trulsson wrote: On Wed, Mar 18, 2009 at 09:22:37PM -0500, Robert Noland wrote: On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote: [snip] I'm curious about why the drm driver calls this card a RV370, while pciconf and the X server call it a RV380: pciconf: RV380 RADEON X600 Series 265MB I'm not sure where pciconf gets it's data. I would actaully like to look at that. According to the pciconf(8) manpage: The PCI vendor/device information database is normally read from /usr/share/misc/pci_vendors. This path can be overridden by setting the environment variable PCICONF_VENDOR_DATABASE. Right, that is just the vendor id though, not the device name string. Have you actually looked at the contents of that file? All the strings describing vendor and device name that pciconf prints can be found in that file. Hrm, Ok... I only glanced at it, it lists only the vendors first. robert. The reason that I'm curious is that I was trying to extract device name info from Nvidia cards the other day, without using a static data source. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Thu, 2009-03-19 at 10:24 +0100, Torfinn Ingolfsen wrote: On Wed, 18 Mar 2009 18:18:41 -0500 (CDT) Greg Rivers gcr+freebsd-sta...@tharned.org wrote: I'm curious about why the drm driver calls this card a RV370, while pciconf and the X server call it a RV380: FWIW, despite the text description, drm treats this as CHIP_RV380. robert. You could always install the pciutils (sysutils/pciutils) port and find out what 'lspci' says, for one more data point. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Wed, 18 Mar 2009, Robert Noland wrote: Ok, so it isn't the gart caching... Can you get me a pointer to a screenshot? fetch http://www.tharned.org/rv380-drm-issue.tbz This archive contains various logs and system configuration files as well as screen shot images. Look at the README file for a description of the images. What is garbled exactly? Is the damage constrained to specific windows or it it the entire framebuffer? The entire frame buffer is garbled; switching to syscons and back seems to change the way it's garbled. However, the interior of an xterm window is never garbled. I'm running a dual-head configuration with the frame buffer spanning both monitors. -- Greg Rivers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Thu, 2009-03-19 at 15:01 -0500, Greg Rivers wrote:
On Wed, 18 Mar 2009, Robert Noland wrote:
Ok, so it isn't the gart caching... Can you get me a pointer to a
screenshot?
fetch http://www.tharned.org/rv380-drm-issue.tbz
This archive contains various logs and system configuration files as well
as screen shot images. Look at the README file for a description of the
images.
What is garbled exactly? Is the damage constrained to specific windows
or it it the entire framebuffer?
The entire frame buffer is garbled; switching to syscons and back seems to
change the way it's garbled. However, the interior of an xterm window is
never garbled. I'm running a dual-head configuration with the frame
buffer spanning both monitors.
Ok, I thought that I had already fixed this up, but I missed this
spot... Please try this patch.
robert.
--
Robert Noland rnol...@freebsd.org
FreeBSD
Index: dev/drm/ati_pcigart.c
===
--- dev/drm/ati_pcigart.c (revision 190096)
+++ dev/drm/ati_pcigart.c (working copy)
@@ -75,18 +75,15 @@
NULL, NULL, /* filtfunc, filtfuncargs */
gart_info-table_size, 1, /* maxsize, nsegs */
gart_info-table_size, /* maxsegsize */
- BUS_DMA_ALLOCNOW, NULL, NULL, /* flags, lockfunc, lockfuncargs */
+ 0, NULL, NULL, /* flags, lockfunc, lockfuncargs */
dmah-tag);
if (ret != 0) {
free(dmah, DRM_MEM_DMA);
return ENOMEM;
}
- flags = BUS_DMA_NOWAIT | BUS_DMA_ZERO;
- if (gart_info-gart_reg_if == DRM_ATI_GART_IGP)
- flags |= BUS_DMA_NOCACHE;
-
- ret = bus_dmamem_alloc(dmah-tag, dmah-vaddr, flags, dmah-map);
+ ret = bus_dmamem_alloc(dmah-tag, dmah-vaddr,
+ BUS_DMA_WAITOK | BUS_DMA_ZERO, dmah-map);
if (ret != 0) {
bus_dma_tag_destroy(dmah-tag);
free(dmah, DRM_MEM_DMA);
@@ -94,8 +91,12 @@
}
DRM_LOCK();
+ flags = BUS_DMA_NOWAIT;
+ if (gart_info-gart_reg_if == DRM_ATI_GART_IGP)
+ flags |= BUS_DMA_NOCACHE;
+
ret = bus_dmamap_load(dmah-tag, dmah-map, dmah-vaddr,
- gart_info-table_size, drm_ati_alloc_pcigart_table_cb, dmah, 0);
+ gart_info-table_size, drm_ati_alloc_pcigart_table_cb, dmah, flags);
if (ret != 0) {
bus_dmamem_free(dmah-tag, dmah-vaddr, dmah-map);
bus_dma_tag_destroy(dmah-tag);
signature.asc
Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Thu, 19 Mar 2009, Robert Noland wrote:
On Thu, 2009-03-19 at 15:01 -0500, Greg Rivers wrote:
On Wed, 18 Mar 2009, Robert Noland wrote:
Ok, so it isn't the gart caching... Can you get me a pointer to a
screenshot?
fetch http://www.tharned.org/rv380-drm-issue.tbz
This archive contains various logs and system configuration files as well
as screen shot images. Look at the README file for a description of the
images.
What is garbled exactly? Is the damage constrained to specific windows
or it it the entire framebuffer?
The entire frame buffer is garbled; switching to syscons and back seems to
change the way it's garbled. However, the interior of an xterm window is
never garbled. I'm running a dual-head configuration with the frame
buffer spanning both monitors.
Ok, I thought that I had already fixed this up, but I missed this
spot... Please try this patch.
It's still garbled with this patch too. Any other ideas? Just let me
know when it's time for me to buy a different video card. :-)
--
Greg RiversIndex: dev/drm/ati_pcigart.c
===
--- dev/drm/ati_pcigart.c (revision 190096)
+++ dev/drm/ati_pcigart.c (working copy)
@@ -75,18 +75,15 @@
NULL, NULL, /* filtfunc, filtfuncargs */
gart_info-table_size, 1, /* maxsize, nsegs */
gart_info-table_size, /* maxsegsize */
- BUS_DMA_ALLOCNOW, NULL, NULL, /* flags, lockfunc, lockfuncargs */
+ 0, NULL, NULL, /* flags, lockfunc, lockfuncargs */
dmah-tag);
if (ret != 0) {
free(dmah, DRM_MEM_DMA);
return ENOMEM;
}
- flags = BUS_DMA_NOWAIT | BUS_DMA_ZERO;
- if (gart_info-gart_reg_if == DRM_ATI_GART_IGP)
- flags |= BUS_DMA_NOCACHE;
-
- ret = bus_dmamem_alloc(dmah-tag, dmah-vaddr, flags, dmah-map);
+ ret = bus_dmamem_alloc(dmah-tag, dmah-vaddr,
+ BUS_DMA_WAITOK | BUS_DMA_ZERO, dmah-map);
if (ret != 0) {
bus_dma_tag_destroy(dmah-tag);
free(dmah, DRM_MEM_DMA);
@@ -94,8 +91,12 @@
}
DRM_LOCK();
+ flags = BUS_DMA_NOWAIT;
+ if (gart_info-gart_reg_if == DRM_ATI_GART_IGP)
+ flags |= BUS_DMA_NOCACHE;
+
ret = bus_dmamap_load(dmah-tag, dmah-map, dmah-vaddr,
- gart_info-table_size, drm_ati_alloc_pcigart_table_cb, dmah, 0);
+ gart_info-table_size, drm_ati_alloc_pcigart_table_cb, dmah, flags);
if (ret != 0) {
bus_dmamem_free(dmah-tag, dmah-vaddr, dmah-map);
bus_dma_tag_destroy(dmah-tag);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Thu, 2009-03-19 at 22:32 -0500, Greg Rivers wrote: On Thu, 19 Mar 2009, Robert Noland wrote: On Thu, 2009-03-19 at 15:01 -0500, Greg Rivers wrote: On Wed, 18 Mar 2009, Robert Noland wrote: Ok, so it isn't the gart caching... Can you get me a pointer to a screenshot? fetch http://www.tharned.org/rv380-drm-issue.tbz This archive contains various logs and system configuration files as well as screen shot images. Look at the README file for a description of the images. What is garbled exactly? Is the damage constrained to specific windows or it it the entire framebuffer? The entire frame buffer is garbled; switching to syscons and back seems to change the way it's garbled. However, the interior of an xterm window is never garbled. I'm running a dual-head configuration with the frame buffer spanning both monitors. Ok, I thought that I had already fixed this up, but I missed this spot... Please try this patch. It's still garbled with this patch too. Any other ideas? Just let me know when it's time for me to buy a different video card. :-) So, what I noticed today is that the difference between your ok and garbled xorg.logs seems to be the ring pointer contents not being empty... I haven't really figured out why that is yet... robert. -- Greg Rivers -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Tue, 2009-03-17 at 18:24 -0500, Greg Rivers wrote: On Tue, 17 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote: On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I have a workstation with a [Radeon X600 (PCIE)] card. The X display has been garbled since these DRM updates went in in January, and remains garbled with 7.1-STABLE as of yesterday. As a work-around, I'm running the up-to-date 7.1-STABLE system (both world and ports) with a 7.1-RELEASE-p2 kernel. The display is fine with the old kernel and X works great; I even see dramatically improved performance with the new Xorg and EXA acceleration. Your work is much appreciated. But the garbled display with the recent DRM still plagues me. [snip] Could you try the attached patch. Unfortunately, there is no noticeable difference with this patch. Also, I'm guessing that this is a PCI based card, right? Also, it isn't an integrated model? Yes, this is a PCIEx16 card in a HP Compaq dc7600 desktop PC, not a motherboard integrated adapter. Thanks for your help. I'm willing to spend some time debugging this; please let me know if there's more information I can provide or other tests or patches I can try. Ok, try this patch... I asked the folks from AMD and they agree that this shouldn't be needed on an RV370, but we will give it a try... This is what fixed the garbled display on the IGP chips. robet. -- Greg Rivers -- Robert Noland rnol...@freebsd.org FreeBSD Index: dev/drm/ati_pcigart.c === --- dev/drm/ati_pcigart.c (revision 189933) +++ dev/drm/ati_pcigart.c (working copy) @@ -83,7 +83,7 @@ } flags = BUS_DMA_NOWAIT | BUS_DMA_ZERO; - if (gart_info-gart_reg_if == DRM_ATI_GART_IGP) +/* if (gart_info-gart_reg_if == DRM_ATI_GART_IGP) */ flags |= BUS_DMA_NOCACHE; ret = bus_dmamem_alloc(dmah-tag, dmah-vaddr, flags, dmah-map); signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Wed, 18 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 18:24 -0500, Greg Rivers wrote: On Tue, 17 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote: On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I have a workstation with a [Radeon X600 (PCIE)] card. The X display has been garbled since these DRM updates went in in January, and remains garbled with 7.1-STABLE as of yesterday. As a work-around, I'm running the up-to-date 7.1-STABLE system (both world and ports) with a 7.1-RELEASE-p2 kernel. The display is fine with the old kernel and X works great; I even see dramatically improved performance with the new Xorg and EXA acceleration. Your work is much appreciated. But the garbled display with the recent DRM still plagues me. [snip] Could you try the attached patch. Unfortunately, there is no noticeable difference with this patch. Also, I'm guessing that this is a PCI based card, right? Also, it isn't an integrated model? Yes, this is a PCIEx16 card in a HP Compaq dc7600 desktop PC, not a motherboard integrated adapter. Thanks for your help. I'm willing to spend some time debugging this; please let me know if there's more information I can provide or other tests or patches I can try. Ok, try this patch... I asked the folks from AMD and they agree that this shouldn't be needed on an RV370, but we will give it a try... This is what fixed the garbled display on the IGP chips. The display is still garbled with this patch too. I'm curious about why the drm driver calls this card a RV370, while pciconf and the X server call it a RV380: pciconf: RV380 RADEON X600 Series 265MB X server: ATI Technologies Inc RV380 [Radeon X600 (PCIE)] drm driver: ATI Radeon RV370 X600 Pro Could it be that the drm driver has the wrong chip set or configuration for this PCI ID? -- Greg RiversIndex: dev/drm/ati_pcigart.c === --- dev/drm/ati_pcigart.c (revision 189933) +++ dev/drm/ati_pcigart.c (working copy) @@ -83,7 +83,7 @@ } flags = BUS_DMA_NOWAIT | BUS_DMA_ZERO; - if (gart_info-gart_reg_if == DRM_ATI_GART_IGP) +/* if (gart_info-gart_reg_if == DRM_ATI_GART_IGP) */ flags |= BUS_DMA_NOCACHE; ret = bus_dmamem_alloc(dmah-tag, dmah-vaddr, flags, dmah-map); ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote: On Wed, 18 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 18:24 -0500, Greg Rivers wrote: On Tue, 17 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote: On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I have a workstation with a [Radeon X600 (PCIE)] card. The X display has been garbled since these DRM updates went in in January, and remains garbled with 7.1-STABLE as of yesterday. As a work-around, I'm running the up-to-date 7.1-STABLE system (both world and ports) with a 7.1-RELEASE-p2 kernel. The display is fine with the old kernel and X works great; I even see dramatically improved performance with the new Xorg and EXA acceleration. Your work is much appreciated. But the garbled display with the recent DRM still plagues me. [snip] Could you try the attached patch. Unfortunately, there is no noticeable difference with this patch. Also, I'm guessing that this is a PCI based card, right? Also, it isn't an integrated model? Yes, this is a PCIEx16 card in a HP Compaq dc7600 desktop PC, not a motherboard integrated adapter. Thanks for your help. I'm willing to spend some time debugging this; please let me know if there's more information I can provide or other tests or patches I can try. Ok, try this patch... I asked the folks from AMD and they agree that this shouldn't be needed on an RV370, but we will give it a try... This is what fixed the garbled display on the IGP chips. The display is still garbled with this patch too. I'm curious about why the drm driver calls this card a RV370, while pciconf and the X server call it a RV380: pciconf: RV380 RADEON X600 Series 265MB I'm not sure where pciconf gets it's data. I would actaully like to look at that. X server: ATI Technologies Inc RV380 [Radeon X600 (PCIE)] This comes from /usr/local/share/pciids/pci.ids drm driver: ATI Radeon RV370 X600 Pro This comes from drm's own internal tables. (drm_pciids.h) Could it be that the drm driver has the wrong chip set or configuration for this PCI ID? I don't think so, all of those should be about the same. Ok, so it isn't the gart caching... Can you get me a pointer to a screenshot? What is garbled exactly? Is the damage constrained to specific windows or it it the entire framebuffer? robert. -- Greg Rivers -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I have a workstation with a [Radeon X600 (PCIE)] card. The X display has been garbled since these DRM updates went in in January, and remains garbled with 7.1-STABLE as of yesterday. As a work-around, I'm running the up-to-date 7.1-STABLE system (both world and ports) with a 7.1-RELEASE-p2 kernel. The display is fine with the old kernel and X works great; I even see dramatically improved performance with the new Xorg and EXA acceleration. Your work is much appreciated. But the garbled display with the recent DRM still plagues me. Here's how pciconf identifies the card: vgap...@pci0:1:0:0: class=0x03 card=0x06021002 chip=0x5b621002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RV380 RADEON X600 Series 265MB' class = display subclass = VGA vgap...@pci0:1:0:1: class=0x038000 card=0x06031002 chip=0x5b721002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon X600 Series - Secondary' class = display The old DRM probe: vgapci0: VGA-compatible display port 0x2000-0x20ff mem 0xe000-0xe7ff,0xe850-0xe850 irq 16 at device 0.0 on pci1 drm0: ATI Radeon RV370 X600 Pro on vgapci0 info: [drm] Initialized radeon 1.25.0 20060524 vgapci1: VGA-compatible display mem 0xe851-0xe851 at device 0.1 on pci1 ... vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xe850 vgapci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe000 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] writeback test succeeded in 1 usecs ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 60 drm0: [MPSAFE] The new DRM probe: vgapci0: VGA-compatible display port 0x2000-0x20ff mem 0xe000-0xe7ff,0xe850-0xe850 irq 16 at device 0.0 on pci1 drm0: ATI Radeon RV370 X600 Pro on vgapci0 vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xe850 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 vgapci1: VGA-compatible display mem 0xe851-0xe851 at device 0.1 on pci1 ... vgapci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe000 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 59 drm0: [MPSAFE] drm0: [ITHREAD] info: [drm] Num pipes: 1 Difference between the Xorg logs when it's working and when it's not: --- ok/Xorg.0.log 2009-03-16 14:39:40.0 -0500 +++ garbled/Xorg.0.log 2009-03-16 14:46:13.0 -0500 @@ -6 +6 @@ -Current Operating System: FreeBSD xxx.xxx.x.xxx 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Fri Jan 16 18:00:35 CST 2009 r...@xxx.xxx.x.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386 +Current Operating System: FreeBSD xxx.xxx.x.xxx 7.1-STABLE FreeBSD 7.1-STABLE #0: Mon Mar 16 11:42:42 CDT 2009 r...@xxx.xxx.x.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386 @@ -14 +14 @@ -(==) Log file: /var/log/Xorg.0.log, Time: Mon Mar 16 14:39:34 2009 +(==) Log file: /var/log/Xorg.0.log, Time: Mon Mar 16 14:22:00 2009 @@ -407 +407 @@ -(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.25.0 +(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.29.0 @@ -774,5 +774,5 @@ -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xc56d4000 -(II) RADEON(0): [pci] ring handle = 0xc56d4000 -(II) RADEON(0): [pci] Ring mapped at 0x90a0 -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xc57d5000 +(II) RADEON(0): [pci] 32768 kB allocated with handle 0xe7732000 +(II) RADEON(0): [pci] ring handle = 0xe7732000 +(II) RADEON(0): [pci] Ring mapped at 0x88a0 +(II) RADEON(0): [pci] Ring contents 0xff7d8c94 +(II) RADEON(0): [pci] ring read ptr handle = 0xe7833000 @@ -780,6 +780,6 @@ -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xc57d6000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x90b01000 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xc59d6000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x90d01000 +(II) RADEON(0): [pci] Ring read ptr contents
Re: [HEADS UP] drm merged to -STABLE
On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote: On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I have a workstation with a [Radeon X600 (PCIE)] card. The X display has been garbled since these DRM updates went in in January, and remains garbled with 7.1-STABLE as of yesterday. As a work-around, I'm running the up-to-date 7.1-STABLE system (both world and ports) with a 7.1-RELEASE-p2 kernel. The display is fine with the old kernel and X works great; I even see dramatically improved performance with the new Xorg and EXA acceleration. Your work is much appreciated. But the garbled display with the recent DRM still plagues me. Here's how pciconf identifies the card: vgap...@pci0:1:0:0: class=0x03 card=0x06021002 chip=0x5b621002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RV380 RADEON X600 Series 265MB' class = display subclass = VGA vgap...@pci0:1:0:1: class=0x038000 card=0x06031002 chip=0x5b721002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon X600 Series - Secondary' class = display The old DRM probe: vgapci0: VGA-compatible display port 0x2000-0x20ff mem 0xe000-0xe7ff,0xe850-0xe850 irq 16 at device 0.0 on pci1 drm0: ATI Radeon RV370 X600 Pro on vgapci0 info: [drm] Initialized radeon 1.25.0 20060524 vgapci1: VGA-compatible display mem 0xe851-0xe851 at device 0.1 on pci1 ... vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xe850 vgapci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe000 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] writeback test succeeded in 1 usecs ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 60 drm0: [MPSAFE] The new DRM probe: vgapci0: VGA-compatible display port 0x2000-0x20ff mem 0xe000-0xe7ff,0xe850-0xe850 irq 16 at device 0.0 on pci1 drm0: ATI Radeon RV370 X600 Pro on vgapci0 vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xe850 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 vgapci1: VGA-compatible display mem 0xe851-0xe851 at device 0.1 on pci1 ... vgapci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe000 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 59 drm0: [MPSAFE] drm0: [ITHREAD] info: [drm] Num pipes: 1 Difference between the Xorg logs when it's working and when it's not: --- ok/Xorg.0.log 2009-03-16 14:39:40.0 -0500 +++ garbled/Xorg.0.log2009-03-16 14:46:13.0 -0500 @@ -6 +6 @@ -Current Operating System: FreeBSD xxx.xxx.x.xxx 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Fri Jan 16 18:00:35 CST 2009 r...@xxx.xxx.x.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386 +Current Operating System: FreeBSD xxx.xxx.x.xxx 7.1-STABLE FreeBSD 7.1-STABLE #0: Mon Mar 16 11:42:42 CDT 2009 r...@xxx.xxx.x.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386 @@ -14 +14 @@ -(==) Log file: /var/log/Xorg.0.log, Time: Mon Mar 16 14:39:34 2009 +(==) Log file: /var/log/Xorg.0.log, Time: Mon Mar 16 14:22:00 2009 @@ -407 +407 @@ -(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.25.0 +(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.29.0 @@ -774,5 +774,5 @@ -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xc56d4000 -(II) RADEON(0): [pci] ring handle = 0xc56d4000 -(II) RADEON(0): [pci] Ring mapped at 0x90a0 -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xc57d5000 +(II) RADEON(0): [pci] 32768 kB allocated with handle 0xe7732000 +(II) RADEON(0): [pci] ring handle = 0xe7732000 +(II) RADEON(0): [pci] Ring mapped at 0x88a0 +(II) RADEON(0): [pci] Ring contents 0xff7d8c94 +(II) RADEON(0): [pci] ring read ptr handle = 0xe7833000 @@ -780,6 +780,6 @@ -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xc57d6000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x90b01000 -(II) RADEON(0): [pci] Vertex/indirect buffers contents
Re: [HEADS UP] drm merged to -STABLE
On Tue, 17 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote: On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I have a workstation with a [Radeon X600 (PCIE)] card. The X display has been garbled since these DRM updates went in in January, and remains garbled with 7.1-STABLE as of yesterday. As a work-around, I'm running the up-to-date 7.1-STABLE system (both world and ports) with a 7.1-RELEASE-p2 kernel. The display is fine with the old kernel and X works great; I even see dramatically improved performance with the new Xorg and EXA acceleration. Your work is much appreciated. But the garbled display with the recent DRM still plagues me. [snip] Could you try the attached patch. Unfortunately, there is no noticeable difference with this patch. Also, I'm guessing that this is a PCI based card, right? Also, it isn't an integrated model? Yes, this is a PCIEx16 card in a HP Compaq dc7600 desktop PC, not a motherboard integrated adapter. Thanks for your help. I'm willing to spend some time debugging this; please let me know if there's more information I can provide or other tests or patches I can try. -- Greg RiversIndex: drm_bufs.c === --- drm_bufs.c (revision 189907) +++ drm_bufs.c (revision 189908) @@ -1106,7 +1106,7 @@ if (size == 0) return 0; - order = ffsl(size) - 1; + order = flsl(size) - 1; if (size ~(1ul order)) ++order; ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote: If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: Thank you! :) bye, Uwe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[HEADS UP] drm merged to -STABLE
I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. thanks, robert. signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. robert. thanks, robert. signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. Do cards on the PCIE bus still need the agp device? It seems my r535 (radeon X1650Pro) on the PCIE bus can allocate a GART without it. I have the agp module loaded, but there is no /dev/agpgart device. But if I try to unload the module, it says 'can't unload file: Device busy'. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgplE1fFuEAZp.pgp Description: PGP signature
Re: [HEADS UP] drm merged to -STABLE
On Sat, 2009-01-10 at 18:54 +0100, Roland Smith wrote: On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. Do cards on the PCIE bus still need the agp device? It seems my r535 (radeon X1650Pro) on the PCIE bus can allocate a GART without it. I have the agp module loaded, but there is no /dev/agpgart device. But if I try to unload the module, it says 'can't unload file: Device busy'. Technically no, pci/pci-e based cards don't need AGP. All of the Intel chips do, as they emulate AGP in all cases. The pci/pci-e radeons do not need AGP at all, but I don't know of a way to conditionally require the AGP module as a dependency in drm. The other issue would be that even if I could, it would probably end up with undefined symbols in drm without agp loaded, even if it isn't used. robert. Roland signature.asc Description: This is a digitally signed message part
Re: [HEADS UP] drm merged to -STABLE
On Saturday 10 January 2009 08:49:01 am Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. What's your plan on incorporating r6xx/r7xx drm :? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Sat, 2009-01-10 at 15:53 -0800, vehemens wrote: On Saturday 10 January 2009 08:49:01 am Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. What's your plan on incorporating r6xx/r7xx drm :? The code isn't user ready yet. What AMD has released, I have building. AMD is being quite reasonable about their code, so it won't be a big deal to get that code imported quickly once it is ready. My expectation is that we will ship code, at least in -CURRENT, before any linux distro. ;) robert. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org signature.asc Description: This is a digitally signed message part
