Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled
On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann wrote: > Hi > > On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen wrote: >> Hi David, >> >> On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen wrote: >>> On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann >>> wrote: Attached are two patches. The first one should fix this issue, the second one is the rebased ioremap_wc() patch from the other thread. Does this fix the issue (and the speed-problems)? >>> >>> Sadly, no. I added a few printk's to verify that the function you >>> added is called (it is), but still the same oops. >> >> A few more datapoints: >> >> Triggers: >> X86_SYSFB=y and FB_SIMPLE=n (so no fbdev until i915 is loaded) >> X86_SYSFB=y and FB_SIMPLE=y >> >> Does not trigger: >> X86_SYSFB=y, FB_EFI=yes, and without the overflow fix (i.e., so we >> fall back to efifb) >> X86_SYSFB=n and FB_EFI=y >> X86_SYSFB=n and FB_EFI=n (so no fbdev until i915 is loaded) >> >> Does this make any sense? > > Thanks a lot for these results. I think I got it know. I will write a > patch that marks the resource as busy. See: > kernel/resource.c iomem_map_sanity_check() > It also contains a hint that we should set this for driver-resources > which not directly map to hardware resources (such as veasfb and, > obviously, simplefb). > > Following a diff which hopefully fixes this. The other two patches > should still be required, though. I will try to write a proper patch > tomorrow. > > Thanks a lot for these extensive tests, Tom! No problem. Thanks for the fix, it works for me! Cheers, Tom > diff --git a/arch/x86/kernel/sysfb_simplefb.c > b/arch/x86/kernel/sysfb_simplefb.c > index 22513e9..b7bb615 100644 > --- a/arch/x86/kernel/sysfb_simplefb.c > +++ b/arch/x86/kernel/sysfb_simplefb.c > @@ -79,7 +79,7 @@ __init int create_simplefb(const struct screen_info *si, > > /* setup IORESOURCE_MEM as framebuffer memory */ > memset(&res, 0, sizeof(res)); > - res.flags = IORESOURCE_MEM; > + res.flags = IORESOURCE_MEM | IORESOURCE_BUSY; > res.name = simplefb_resname; > res.start = si->lfb_base; > res.end = si->lfb_base + len - 1; ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/6] SimpleDRM Driver
Hi David, On Wed, Sep 4, 2013 at 7:34 PM, David Herrmann wrote: > Hi > > On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann wrote: >> Hi >> >> With the upcoming 3.12 merge-window, I thought people might find themselves >> with >> nothing to do, so here's a new SimpleDRM series. Comments welcome! >> >> This depends on the tip/x86/fb series in the x86-tip tree: >> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/fb >> Which, as far as I understood, will be pushed into 3.12 by the x86 people. > > FYI, this is now merged in Linus' tree. See: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=228abe73ad67665d71eacd6a8a347dd76b0115ae > > So hopefully we can get SimpleDRM ready for 3.13. Now that simplefb works for me, I finally got around to testing this. Just a couple of comments: * I guess you need to add the modalias "platform:simple-framebuffer" in addition to the "of:..." one to get module auto loading working. * the driver currently doesn't work with your IORESOURCE_BUSY fix to sysfb (as might be expected(?)): simple-framebuffer simple-framebuffer.0: cannot reserve VMEM simple-framebuffer: probe of simple-framebuffer.0 failed with error -5 * except for that, fbcon on top of the fbdev fallback support works fine for me. I didn't yet try the drm driver itself, what clients (if any) are supposed to work with this, kmscon, weston? Cheers, Tom ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: Make sure every ioctl structure has a typedef
On Fri, Sep 06, 2013 at 07:57:19PM +0100, Damien Lespiau wrote: > Just for consistency. > > Signed-off-by: Damien Lespiau Afaik kernel coding style is to echew typdefs for normal structures as much as possible. The only exception is for truly opaque types used in abstractions, like dma_addr_t or pid_t. All the typedefs we still have here go back to the old days of a drm core shared between *bsd and linux. Since that's long gone they imo should all die, but certainly we shouldn't add new ones. Aside: My patcha apply script will also bitch about new usages of drm_i915_private_t ;-) Cheers, Daniel > --- > include/uapi/drm/drm.h | 29 + > 1 file changed, 29 insertions(+) > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > index b8604d2..0430fab 100644 > --- a/include/uapi/drm/drm.h > +++ b/include/uapi/drm/drm.h > @@ -799,6 +799,11 @@ typedef struct drm_client drm_client_t; > typedef enum drm_stat_type drm_stat_type_t; > typedef struct drm_stats drm_stats_t; > typedef struct drm_set_version drm_set_version_t; > +typedef struct drm_modeset_ctl drm_modeset_ctl_t; > +typedef struct drm_gem_close drm_gem_close_t; > +typedef struct drm_gem_flink drm_gem_flink_t; > +typedef struct drm_gem_open drm_gem_open_t; > +typedef struct drm_get_cap drm_get_cap_t; > typedef struct drm_block drm_block_t; > typedef struct drm_control drm_control_t; > typedef struct drm_buf_desc drm_buf_desc_t; > @@ -815,6 +820,7 @@ typedef struct drm_ctx_res drm_ctx_res_t; > typedef struct drm_draw drm_draw_t; > typedef enum drm_lock_flags drm_lock_flags_t; > typedef struct drm_lock drm_lock_t; > +typedef struct drm_prime_handle drm_prime_handle_t; > typedef struct drm_agp_mode drm_agp_mode_t; > typedef struct drm_agp_info drm_agp_info_t; > typedef struct drm_agp_buffer drm_agp_buffer_t; > @@ -823,6 +829,29 @@ typedef struct drm_scatter_gather drm_scatter_gather_t; > typedef enum drm_vblank_seq_type drm_vblank_seq_type_t; > typedef union drm_wait_vblank drm_wait_vblank_t; > typedef struct drm_update_draw drm_update_draw_t; > +typedef struct drm_mode_card_res drm_mode_card_res_t; > +typedef struct drm_mode_crtc drm_mode_crtc_t; > +typedef struct drm_mode_cursor drm_mode_cursor_t; > +typedef struct drm_mode_crtc_lut drm_mode_crtc_lut_t; > +typedef struct drm_mode_get_encoder drm_mode_get_encoder_t; > +typedef struct drm_mode_get_connector drm_mode_get_connector_t; > +typedef struct drm_mode_mode_cmd drm_mode_mode_cmd_t; > +typedef struct drm_mode_get_property drm_mode_get_property_t; > +typedef struct drm_mode_connector_set_property > drm_mode_connector_set_property_t; > +typedef struct drm_mode_get_blob drm_mode_get_blob_t; > +typedef struct drm_mode_fb_cmd drm_mode_fb_cmd_t; > +typedef struct drm_mode_crtc_page_flip drm_mode_crtc_page_flip_t; > +typedef struct drm_mode_fb_dirty_cmd drm_mode_fb_dirty_cmd_t; > +typedef struct drm_mode_create_dumb drm_mode_create_dumb_t; > +typedef struct drm_mode_map_dumb drm_mode_map_dumb_t; > +typedef struct drm_mode_destroy_dumb drm_mode_destroy_dumb_t; > +typedef struct drm_mode_get_plane_res drm_mode_get_plane_res_t; > +typedef struct drm_mode_get_plane drm_mode_get_plane_t; > +typedef struct drm_mode_set_plane drm_mode_set_plane_t; > +typedef struct drm_mode_fb_cmd2 drm_mode_fb_cmd2_t; > +typedef struct drm_mode_obj_get_properties drm_mode_obj_get_properties_t; > +typedef struct drm_mode_obj_set_property drm_mode_obj_set_property_t; > +typedef struct drm_mode_cursor2 drm_mode_cursor2_t; > > typedef struct drm_clip_rect drm_clip_rect_t; > typedef struct drm_drawable_info drm_drawable_info_t; > -- > 1.8.3.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Stereo 3D v3
On Fri, Sep 6, 2013 at 9:11 PM, Chris Wilson wrote: > On Fri, Sep 06, 2013 at 07:57:16PM +0100, Damien Lespiau wrote: >> Follow up of: >> http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html >> >> Let's try again! This time, intead of a magic connector property to select if >> we want to return more modeinfo flags to userspace, this series introduces a >> new SET_CAP ioctl. >> >> So the flow goes as following: >> 1/ the DRM client (limited to the DRM master) can notify it knows about >> those >> flags through SET_CAP > > Is this capability dropped along with a change in master then? Yeah, I think it would make sense to store this flag in the master structure. But David Herrmann has some big plans for the drm master stuff, so would be good to have his opinion on this. David? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/radeon kexec fixes
Here are a couple of patches that get kexec working with radeon devices. I've tested this on my RS780. Comments or flames are welcome. Thanks. Markus Trippelsdorf (3): kexec: get rid of late printk drm/radeon: Implement radeon_pci_shutdown drm/radeon: get rid of r100_restore_sanity hack drivers/gpu/drm/radeon/r100.c| 27 --- drivers/gpu/drm/radeon/r300.c| 2 -- drivers/gpu/drm/radeon/r420.c| 2 -- drivers/gpu/drm/radeon/r520.c| 2 -- drivers/gpu/drm/radeon/radeon_asic.h | 1 - drivers/gpu/drm/radeon/radeon_drv.c | 10 ++ drivers/gpu/drm/radeon/rs400.c | 2 -- drivers/gpu/drm/radeon/rs600.c | 2 -- drivers/gpu/drm/radeon/rs690.c | 2 -- drivers/gpu/drm/radeon/rv515.c | 2 -- kernel/kexec.c | 1 - 11 files changed, 10 insertions(+), 43 deletions(-) -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] kexec: get rid of late printk
kexec calls:
printk(KERN_EMERG "Starting new kernel\n");
late before calling machine_shutdown().
However at this point the underlying fb device may have already been
shutdown. This causes the kernel to hang.
Fix by simply getting rid of the printk call.
Signed-off-by: Markus Trippelsdorf
---
kernel/kexec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 59f7b55..f33fa9f 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1679,7 +1679,6 @@ int kernel_kexec(void)
#endif
{
kernel_restart_prepare(NULL);
- printk(KERN_EMERG "Starting new kernel\n");
machine_shutdown();
}
--
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/radeon: Implement radeon_pci_shutdown
Currently radeon devices are not properbly shutdown during kexec. This
cases a varity of issues, e.g. dpm initialization failures.
Fix this by implementing a radeon_pci_shutdown function, that unloads
the driver cleanly.
Signed-off-by: Markus Trippelsdorf
---
drivers/gpu/drm/radeon/radeon_drv.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index cb4445f..d71edee 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -380,6 +380,15 @@ static const struct file_operations radeon_driver_kms_fops
= {
#endif
};
+
+static void
+radeon_pci_shutdown(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+
+ radeon_driver_unload_kms(dev);
+}
+
static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP |
@@ -453,6 +462,7 @@ static struct pci_driver radeon_kms_pci_driver = {
.remove = radeon_pci_remove,
.suspend = radeon_pci_suspend,
.resume = radeon_pci_resume,
+ .shutdown = radeon_pci_shutdown,
};
static int __init radeon_init(void)
--
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/radeon: get rid of r100_restore_sanity hack
Now that radeon devices are properly shutdown during kexec, we can get
rid of r100_restore_sanity.
Signed-off-by: Markus Trippelsdorf
---
drivers/gpu/drm/radeon/r100.c| 27 ---
drivers/gpu/drm/radeon/r300.c| 2 --
drivers/gpu/drm/radeon/r420.c| 2 --
drivers/gpu/drm/radeon/r520.c| 2 --
drivers/gpu/drm/radeon/radeon_asic.h | 1 -
drivers/gpu/drm/radeon/rs400.c | 2 --
drivers/gpu/drm/radeon/rs600.c | 2 --
drivers/gpu/drm/radeon/rs690.c | 2 --
drivers/gpu/drm/radeon/rv515.c | 2 --
9 files changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 9fc61dd..d53dcd8 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3938,31 +3938,6 @@ void r100_fini(struct radeon_device *rdev)
rdev->bios = NULL;
}
-/*
- * Due to how kexec works, it can leave the hw fully initialised when it
- * boots the new kernel. However doing our init sequence with the CP and
- * WB stuff setup causes GPU hangs on the RN50 at least. So at startup
- * do some quick sanity checks and restore sane values to avoid this
- * problem.
- */
-void r100_restore_sanity(struct radeon_device *rdev)
-{
- u32 tmp;
-
- tmp = RREG32(RADEON_CP_CSQ_CNTL);
- if (tmp) {
- WREG32(RADEON_CP_CSQ_CNTL, 0);
- }
- tmp = RREG32(RADEON_CP_RB_CNTL);
- if (tmp) {
- WREG32(RADEON_CP_RB_CNTL, 0);
- }
- tmp = RREG32(RADEON_SCRATCH_UMSK);
- if (tmp) {
- WREG32(RADEON_SCRATCH_UMSK, 0);
- }
-}
-
int r100_init(struct radeon_device *rdev)
{
int r;
@@ -3975,8 +3950,6 @@ int r100_init(struct radeon_device *rdev)
radeon_scratch_init(rdev);
/* Initialize surface registers */
radeon_surface_init(rdev);
- /* sanity check some register to avoid hangs like after kexec */
- r100_restore_sanity(rdev);
/* TODO: disable VGA need to use VGA request */
/* BIOS*/
if (!radeon_get_bios(rdev)) {
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index d8dd269..57ba534 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1480,8 +1480,6 @@ int r300_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* TODO: disable VGA need to use VGA request */
- /* restore some register to sane defaults */
- r100_restore_sanity(rdev);
/* BIOS*/
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 4e796ec..9ee3360 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -371,8 +371,6 @@ int r420_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* TODO: disable VGA need to use VGA request */
- /* restore some register to sane defaults */
- r100_restore_sanity(rdev);
/* BIOS*/
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index e1aece7..4709c10 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -256,8 +256,6 @@ int r520_init(struct radeon_device *rdev)
radeon_scratch_init(rdev);
/* Initialize surface registers */
radeon_surface_init(rdev);
- /* restore some register to sane defaults */
- r100_restore_sanity(rdev);
/* TODO: disable VGA need to use VGA request */
/* BIOS*/
if (!radeon_get_bios(rdev)) {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 818bbe6..6eee9e2 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -122,7 +122,6 @@ void r100_mc_resume(struct radeon_device *rdev, struct
r100_mc_save *save);
void r100_vram_init_sizes(struct radeon_device *rdev);
int r100_cp_reset(struct radeon_device *rdev);
void r100_vga_render_disable(struct radeon_device *rdev);
-void r100_restore_sanity(struct radeon_device *rdev);
int r100_cs_track_check_pkt3_indx_buffer(struct radeon_cs_parser *p,
struct radeon_cs_packet *pkt,
struct radeon_bo *robj);
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index b8074a8..23bbf89 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -510,8 +510,6 @@ int rs400_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* TODO: disable VGA need to use VGA request */
- /* restore some register to sane defaults */
- r100_restore_sanity(rdev);
/* BIOS*/
if (!radeon_get_
[Bug 67800] Computer freezes several hours (trinity)
https://bugs.freedesktop.org/show_bug.cgi?id=67800 Kertesz Laszlo changed: What|Removed |Added Summary|Computer freezes after idle |Computer freezes several |for several hours (trinity) |hours (trinity) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/6] SimpleDRM Driver
Hi On Sun, Sep 8, 2013 at 1:33 PM, Tom Gundersen wrote: > Hi David, > > On Wed, Sep 4, 2013 at 7:34 PM, David Herrmann wrote: >> Hi >> >> On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann wrote: >>> Hi >>> >>> With the upcoming 3.12 merge-window, I thought people might find themselves >>> with >>> nothing to do, so here's a new SimpleDRM series. Comments welcome! >>> >>> This depends on the tip/x86/fb series in the x86-tip tree: >>> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/fb >>> Which, as far as I understood, will be pushed into 3.12 by the x86 people. >> >> FYI, this is now merged in Linus' tree. See: >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=228abe73ad67665d71eacd6a8a347dd76b0115ae >> >> So hopefully we can get SimpleDRM ready for 3.13. > > Now that simplefb works for me, I finally got around to testing this. > Just a couple of comments: > > * I guess you need to add the modalias "platform:simple-framebuffer" > in addition to the "of:..." one to get module auto loading working. Yes, sounds good. > * the driver currently doesn't work with your IORESOURCE_BUSY fix to > sysfb (as might be expected(?)): > simple-framebuffer simple-framebuffer.0: cannot reserve VMEM > simple-framebuffer: probe of simple-framebuffer.0 failed with error -5 Yes, if the simple-framebuffer region is already marked BUSY, simpleDRM must not (and doesn't have to) call __request_region() (or request_mem_region()). I have to remove that call if the BUSY fix gets applied. > * except for that, fbcon on top of the fbdev fallback support works > fine for me. I didn't yet try the drm driver itself, what clients (if > any) are supposed to work with this, kmscon, weston? Obviously, simpledrm doesn't support double-buffering, page-flipping or other advanced techniques. So I currently doubt you can use any real application on it as they all at least require 2 buffers. I haven't decided whether to emulate these in the kernel driver or to rely on user-space to deal with this reduced driver. It's quite likely I will go with both. That means, a compatibility option that makes simpledrm emulate any required techniques (multiple FBs, page-flipping) but also user-space patches to maybe some day be able to disable the kernel emulation. Thanks a lot for testing all this. I will try to get the fixes into rc2. The speed-improvements might have to wait for 3.13, though. Cheers David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm: Move the GET_CAP macros next to the corresponding ioctl structure
Hi
On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau wrote:
> It's a tiny bit more logical to find the different capabilities you can
> use with the GET_CAP ioctl next to the structure rather than putting
> them at the end of the file.
>
> Signed-off-by: Damien Lespiau
> ---
> include/uapi/drm/drm.h | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 272580c..4b683f9 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -611,6 +611,16 @@ struct drm_gem_open {
> __u64 size;
> };
>
> +#define DRM_CAP_DUMB_BUFFER 0x1
> +#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
> +#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
> +#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
> +#define DRM_CAP_PRIME 0x5
> +#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
> +
> +#define DRM_PRIME_CAP_IMPORT 0x1
> +#define DRM_PRIME_CAP_EXPORT 0x2
> +
Makes sense. Would you mind also adding tabs between the name and
literal? Makes it much more readable. And I think it's fine to use
moves to fix coding-style issues.
Thanks
David
> /** DRM_IOCTL_GET_CAP ioctl argument type */
> struct drm_get_cap {
> __u64 capability;
> @@ -774,16 +784,6 @@ struct drm_event_vblank {
> __u32 reserved;
> };
>
> -#define DRM_CAP_DUMB_BUFFER 0x1
> -#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
> -#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
> -#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
> -#define DRM_CAP_PRIME 0x5
> -#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
> -
> -#define DRM_PRIME_CAP_IMPORT 0x1
> -#define DRM_PRIME_CAP_EXPORT 0x2
> -
> /* typedef area */
> #ifndef __KERNEL__
> typedef struct drm_clip_rect drm_clip_rect_t;
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Stereo 3D v3
Hi On Sun, Sep 8, 2013 at 1:59 PM, Daniel Vetter wrote: > On Fri, Sep 6, 2013 at 9:11 PM, Chris Wilson wrote: >> On Fri, Sep 06, 2013 at 07:57:16PM +0100, Damien Lespiau wrote: >>> Follow up of: >>> http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html >>> >>> Let's try again! This time, intead of a magic connector property to select >>> if >>> we want to return more modeinfo flags to userspace, this series introduces a >>> new SET_CAP ioctl. >>> >>> So the flow goes as following: >>> 1/ the DRM client (limited to the DRM master) can notify it knows about >>> those >>> flags through SET_CAP >> >> Is this capability dropped along with a change in master then? > > Yeah, I think it would make sense to store this flag in the master > structure. But David Herrmann has some big plans for the drm master > stuff, so would be good to have his opinion on this. David? The series implements SET_CAP as a per _file_ capability set, not per master. I like it this way. Note that with SET_VERSION, we already have a per _master_ capability set. Compared to SET_CAP it only allows incremental capability changes, but that's fine I think. However, the problem with per-master capabilities (SET_VERSION) is that we currently have no way to control which master a graphics-server gets assigned to. If it's started in background, it will get the same master as the foreground compositor. Therefore, we don't want per-master client-capabilities. It's wrong and breaks existing setups (same as SET_VERSION, and everyone knows that). I also don't see a reason to bind capabilities to a master object. SET_CAP describes what the *calling client* understands and can work with. And this is logically bound to drm_file (as it represents a client). On the other hand, GET_CAP describes what the *device* understands and provides. This is obviously bound to a "drm_device". A "drm_master" object allows to split GET_CAP capabilities and resources across multiple logical master objects. But these resemble a drm_device much more than a drm_file. So no, this capability is not dropped with a change in master. It's independent of the active/bound master. It just describes what a client sees or not sees. Regarding my drm_master plans: I don't plan on changing the concept, I just plan on adding ioctls to control master objects and allow *multiple* active masters per device, but each with different resources. Just as a hint: with the current setup, we only have one master. Seriously, add debug-prints to drm_master_create() and watch. The problem is, chances are pretty low that a compositors starts while no master is active. At least on my system.. here all compositors share a master-object. Comments? David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] drm: Add a DRM_CAP_STEREO_3D capability for SET_CAP ioctl
Hi
On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau wrote:
> This capability allows user space to control the delivery of modes with
> the 3D flags set. This is to not play games with current user space
> users not knowing anything about stereo 3D flags and that could try
> to set a mode with one or several of those bits set.
>
> So, the plan is to remove the stereo 3D flags from the user mode
> modeinfo structure by default, and let them through if we are being told
> otherwise.
>
> stereo_allowed is bound to the drm_file structure to make it a
> per-client setting, not a global one.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_crtc.c | 16 +---
> drivers/gpu/drm/drm_ioctl.c | 14 +-
> include/drm/drmP.h | 3 +++
> include/uapi/drm/drm.h | 9 +
> 4 files changed, 38 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index a691764..ff9646f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1257,12 +1257,14 @@ EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
> * drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo
> * @out: drm_mode_modeinfo struct to return to the user
> * @in: drm_display_mode to use
> + * @file_priv: drm file from the ioctl call
> *
> * Convert a drm_display_mode into a drm_mode_modeinfo structure to return to
> * the user.
> */
> static void drm_crtc_convert_to_umode(struct drm_mode_modeinfo *out,
> - const struct drm_display_mode *in)
> + const struct drm_display_mode *in,
> + const struct drm_file *file_priv)
> {
> WARN(in->hdisplay > USHRT_MAX || in->hsync_start > USHRT_MAX ||
> in->hsync_end > USHRT_MAX || in->htotal > USHRT_MAX ||
> @@ -1287,6 +1289,13 @@ static void drm_crtc_convert_to_umode(struct
> drm_mode_modeinfo *out,
> out->type = in->type;
> strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> +
> + /*
> +* If user-space hasn't configured the driver to expose the stereo 3D
> +* flags, clear them.
> +*/
> + if (!file_priv->stereo_allowed)
> + out->flags &= ~DRM_MODE_FLAG_3D_MASK;
So just to be clear: Whenever a mode is present with 3D flags, it is
also a valid non-3D mode? Is this guaranteed? Don't you want to add a
mode twice, once without 3D flags and once with? You could then just
skip all 3D modes for clients that don't support it.
I have no idea how the 3D flags are specified, just want to go sure
this doesn't break. So whenever a mode with 3D flags is present on a
device, it can be set by a client dropping the 3D flags and it will be
a valid mono-mode?
Cheers
David
> }
>
> /**
> @@ -1556,7 +1565,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
>
> if (crtc->enabled) {
>
> - drm_crtc_convert_to_umode(&crtc_resp->mode, &crtc->mode);
> + drm_crtc_convert_to_umode(&crtc_resp->mode, &crtc->mode,
> + file_priv);
> crtc_resp->mode_valid = 1;
>
> } else {
> @@ -1655,7 +1665,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
> *data,
> copied = 0;
> mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned
> long)out_resp->modes_ptr;
> list_for_each_entry(mode, &connector->modes, head) {
> - drm_crtc_convert_to_umode(&u_mode, mode);
> + drm_crtc_convert_to_umode(&u_mode, mode, file_priv);
> if (copy_to_user(mode_ptr + copied,
> &u_mode, sizeof(u_mode))) {
> ret = -EFAULT;
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index e471cd9..a716641 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -304,7 +304,19 @@ int drm_getcap(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> */
> int drm_setcap(struct drm_device *dev, void *data, struct drm_file
> *file_priv)
> {
> - return -EINVAL;
> + struct drm_set_cap *req = data;
> +
> + switch (req->capability) {
> + case DRM_CAP_STEREO_3D:
> + if (req->value > 1)
> + return -EINVAL;
> + file_priv->stereo_allowed = req->value;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> }
>
> /**
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index b9c321b..0df654c 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -431,6 +431,9 @@ struct drm_file {
> struct drm_master *master; /* master this node is currently
> associated with
> N.B
Re: [PATCH 6/9] drm: Add a DRM_CAP_STEREO_3D capability for SET_CAP ioctl
On Sun, Sep 08, 2013 at 03:50:29PM +0200, David Herrmann wrote:
> Hi
>
> On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau
> wrote:
> > This capability allows user space to control the delivery of modes with
> > the 3D flags set. This is to not play games with current user space
> > users not knowing anything about stereo 3D flags and that could try
> > to set a mode with one or several of those bits set.
> >
> > So, the plan is to remove the stereo 3D flags from the user mode
> > modeinfo structure by default, and let them through if we are being told
> > otherwise.
> >
> > stereo_allowed is bound to the drm_file structure to make it a
> > per-client setting, not a global one.
> >
> > Signed-off-by: Damien Lespiau
> > ---
> > drivers/gpu/drm/drm_crtc.c | 16 +---
> > drivers/gpu/drm/drm_ioctl.c | 14 +-
> > include/drm/drmP.h | 3 +++
> > include/uapi/drm/drm.h | 9 +
> > 4 files changed, 38 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index a691764..ff9646f 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1257,12 +1257,14 @@ EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
> > * drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo
> > * @out: drm_mode_modeinfo struct to return to the user
> > * @in: drm_display_mode to use
> > + * @file_priv: drm file from the ioctl call
> > *
> > * Convert a drm_display_mode into a drm_mode_modeinfo structure to return
> > to
> > * the user.
> > */
> > static void drm_crtc_convert_to_umode(struct drm_mode_modeinfo *out,
> > - const struct drm_display_mode *in)
> > + const struct drm_display_mode *in,
> > + const struct drm_file *file_priv)
> > {
> > WARN(in->hdisplay > USHRT_MAX || in->hsync_start > USHRT_MAX ||
> > in->hsync_end > USHRT_MAX || in->htotal > USHRT_MAX ||
> > @@ -1287,6 +1289,13 @@ static void drm_crtc_convert_to_umode(struct
> > drm_mode_modeinfo *out,
> > out->type = in->type;
> > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> > out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> > +
> > + /*
> > +* If user-space hasn't configured the driver to expose the stereo
> > 3D
> > +* flags, clear them.
> > +*/
> > + if (!file_priv->stereo_allowed)
> > + out->flags &= ~DRM_MODE_FLAG_3D_MASK;
>
> So just to be clear: Whenever a mode is present with 3D flags, it is
> also a valid non-3D mode? Is this guaranteed? Don't you want to add a
> mode twice, once without 3D flags and once with? You could then just
> skip all 3D modes for clients that don't support it.
>
> I have no idea how the 3D flags are specified, just want to go sure
> this doesn't break. So whenever a mode with 3D flags is present on a
> device, it can be set by a client dropping the 3D flags and it will be
> a valid mono-mode?
So yes, that's exactly what happens right now. I was actually thinking
about a v4 of the series with what you said in the first paragraph: just
add the 3D modes to the list, one mode per 3D layout, and drop those
modes from the list given back to userspace when the stereo_allowed
isn't set. That seems quite a bit better than the convoluted approach
here.
--
Damien
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Stereo 3D v3
On Sun, Sep 08, 2013 at 03:46:43PM +0200, David Herrmann wrote: > The series implements SET_CAP as a per _file_ capability set, not per > master. I like it this way. Note that with SET_VERSION, we already > have a per _master_ capability set. Compared to SET_CAP it only allows > incremental capability changes, but that's fine I think. > > However, the problem with per-master capabilities (SET_VERSION) is > that we currently have no way to control which master a > graphics-server gets assigned to. If it's started in background, it > will get the same master as the foreground compositor. Therefore, we > don't want per-master client-capabilities. It's wrong and breaks > existing setups (same as SET_VERSION, and everyone knows that). I also > don't see a reason to bind capabilities to a master object. > > SET_CAP describes what the *calling client* understands and can work > with. And this is logically bound to drm_file (as it represents a > client). On the other hand, GET_CAP describes what the *device* > understands and provides. This is obviously bound to a "drm_device". A > "drm_master" object allows to split GET_CAP capabilities and resources > across multiple logical master objects. But these resemble a > drm_device much more than a drm_file. > > So no, this capability is not dropped with a change in master. It's > independent of the active/bound master. It just describes what a > client sees or not sees. Right, that sums it up. Note that while I've made stereo_allowed a per fd thing (which is what I wanted in that case, alter the reality viewed by the process opening the file), SET_CAP itself it marked as master only. This can be changed in the future to provide per-cap access restrictions if needed. -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #17 from Brian Hall --- Fixed it! The problem was in atom.c, my bisect was correct. Starting with the bad 3.10.5 atom.c, I copied it into the good 3.10.4 tree, commented out the reset data block part, rebuilt, and that fixed it. Commenting out the reset divmul part, without removing the reset data block part, did not fix the corruption. So I generated a patch, and applied that to a 3.11 tree. Fixed the corruption on 3.11. This is the first time I've booted anything higher than 3.10.4 without this problem. Now I'm running 3.11+fix_radeon_dvi_corruption.patch on DVI and there's no corruption during boot or on my desktop. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #18 from Brian Hall --- Created attachment 107621 --> https://bugzilla.kernel.org/attachment.cgi?id=107621&action=edit fixes radeon DVI display corruption -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61011] New: Radeon Screen Corruption since merged patch of Bug 60639
https://bugzilla.kernel.org/show_bug.cgi?id=61011 Bug ID: 61011 Summary: Radeon Screen Corruption since merged patch of Bug 60639 Product: Drivers Version: 2.5 Kernel Version: 3.10.5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: hams...@freenet.de Regression: No Created attachment 107641 --> https://bugzilla.kernel.org/attachment.cgi?id=107641&action=edit This is the result I own a board: 880GMH/U3S3 with radeon chipset HD 4250. Since I upgraded to kernel 3.10.5 I get some screen corruption (shown in attached picture). Then I used git bisect to track down the commit between the last working kernel 3.10.2 and 3.10.5. The commit in question is 6f8bbaf568c7f2c497558bfd04654c0b9841ad57 which points to https://bugzilla.kernel.org/show_bug.cgi?id=60639. Without this commit I was able to build and run the 3.11.0 kernel release. This is also the version, which attached log files refers to. As reference: I created an thread https://bbs.archlinux.org/viewtopic.php?id=169361 where I first described my problem. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639
https://bugzilla.kernel.org/show_bug.cgi?id=61011 --- Comment #1 from hams...@freenet.de --- Created attachment 107651 --> https://bugzilla.kernel.org/attachment.cgi?id=107651&action=edit dmesg output from working kernel -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639
https://bugzilla.kernel.org/show_bug.cgi?id=61011 --- Comment #2 from hams...@freenet.de --- Created attachment 107661 --> https://bugzilla.kernel.org/attachment.cgi?id=107661&action=edit Xorg0.log output from working kernel -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639
https://bugzilla.kernel.org/show_bug.cgi?id=61011 --- Comment #3 from hams...@freenet.de --- Created attachment 107671 --> https://bugzilla.kernel.org/attachment.cgi?id=107671&action=edit dmesg output from non working kernel -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639
https://bugzilla.kernel.org/show_bug.cgi?id=61011 --- Comment #4 from hams...@freenet.de --- Created attachment 107681 --> https://bugzilla.kernel.org/attachment.cgi?id=107681&action=edit Xorg0.log output from non working kernel -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639
https://bugzilla.kernel.org/show_bug.cgi?id=61011 hams...@freenet.de changed: What|Removed |Added See Also||https://bugzilla.kernel.org ||/show_bug.cgi?id=60639 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: Make sure every ioctl structure has a typedef
On Sun, Sep 08, 2013 at 01:58:29PM +0200, Daniel Vetter wrote: > On Fri, Sep 06, 2013 at 07:57:19PM +0100, Damien Lespiau wrote: > > Just for consistency. > > > > Signed-off-by: Damien Lespiau > > Afaik kernel coding style is to echew typdefs for normal structures as > much as possible. The only exception is for truly opaque types used in > abstractions, like dma_addr_t or pid_t. > > All the typedefs we still have here go back to the old days of a drm core > shared between *bsd and linux. Since that's long gone they imo should all > die, but certainly we shouldn't add new ones. I figured that since we where talking about user space API, the kernel rules wouldn't apply there and we could have some consistency, but I certainly can just drop those patches. -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: Make sure every ioctl structure has a typedef
On Sun, Sep 8, 2013 at 9:36 PM, Damien Lespiau wrote: > On Sun, Sep 08, 2013 at 01:58:29PM +0200, Daniel Vetter wrote: >> On Fri, Sep 06, 2013 at 07:57:19PM +0100, Damien Lespiau wrote: >> > Just for consistency. >> > >> > Signed-off-by: Damien Lespiau >> >> Afaik kernel coding style is to echew typdefs for normal structures as >> much as possible. The only exception is for truly opaque types used in >> abstractions, like dma_addr_t or pid_t. >> >> All the typedefs we still have here go back to the old days of a drm core >> shared between *bsd and linux. Since that's long gone they imo should all >> die, but certainly we shouldn't add new ones. > > I figured that since we where talking about user space API, the kernel > rules wouldn't apply there and we could have some consistency, but I > certainly can just drop those patches. I've thought typedefs are even frowned upon in the ioctl abi - magically changing sized types cause pain since they need 32bit compat wrappers. And otherwise I haven't really seen them much for structures ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Stereo 3D v3
On Sun, Sep 8, 2013 at 5:03 PM, Damien Lespiau wrote: > On Sun, Sep 08, 2013 at 03:46:43PM +0200, David Herrmann wrote: >> The series implements SET_CAP as a per _file_ capability set, not per >> master. I like it this way. Note that with SET_VERSION, we already >> have a per _master_ capability set. Compared to SET_CAP it only allows >> incremental capability changes, but that's fine I think. >> >> However, the problem with per-master capabilities (SET_VERSION) is >> that we currently have no way to control which master a >> graphics-server gets assigned to. If it's started in background, it >> will get the same master as the foreground compositor. Therefore, we >> don't want per-master client-capabilities. It's wrong and breaks >> existing setups (same as SET_VERSION, and everyone knows that). I also >> don't see a reason to bind capabilities to a master object. >> >> SET_CAP describes what the *calling client* understands and can work >> with. And this is logically bound to drm_file (as it represents a >> client). On the other hand, GET_CAP describes what the *device* >> understands and provides. This is obviously bound to a "drm_device". A >> "drm_master" object allows to split GET_CAP capabilities and resources >> across multiple logical master objects. But these resemble a >> drm_device much more than a drm_file. >> >> So no, this capability is not dropped with a change in master. It's >> independent of the active/bound master. It just describes what a >> client sees or not sees. > > Right, that sums it up. Note that while I've made stereo_allowed a per > fd thing (which is what I wanted in that case, alter the reality viewed > by the process opening the file), SET_CAP itself it marked as master > only. This can be changed in the future to provide per-cap access > restrictions if needed. Ok, I admit defaut, master doesn't make sense here ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] kexec: get rid of late printk
On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf wrote: > kexec calls: > printk(KERN_EMERG "Starting new kernel\n"); > late before calling machine_shutdown(). > However at this point the underlying fb device may have already been > shutdown. This causes the kernel to hang. > Fix by simply getting rid of the printk call. > > Signed-off-by: Markus Trippelsdorf Shouldn't this be taken care of with the suspend/resume_console calls? At least that's my understanding how it works in the suspend/hibernate code, maybe kexec needs similar treatment ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #16 from Peter Kraus --- Hi there, any update on this one? Can I / do I need to test anything? It's a bit of a bummer... Or is this a bug in Dota? The behaviour is there also with linux-3.11. Peter -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] kexec: get rid of late printk
On Sun, 08 September 2013 Daniel Vetter wrote: > On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf > wrote: > > kexec calls: > > printk(KERN_EMERG "Starting new kernel\n"); > > late before calling machine_shutdown(). > > However at this point the underlying fb device may have already been > > shutdown. This causes the kernel to hang. > > Fix by simply getting rid of the printk call. > > > > Signed-off-by: Markus Trippelsdorf > > Shouldn't this be taken care of with the suspend/resume_console calls? > At least that's my understanding how it works in the suspend/hibernate > code, maybe kexec needs similar treatment ... Is it suspend/resume_console? Shouldn't the fbcon be short-circuited or disabled once there is no more underlying fb? Serial console, if present, as well as netconsole if network device is still alive should continue working I would say. Bruno > -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639
https://bugzilla.kernel.org/show_bug.cgi?id=61011 --- Comment #5 from Alex Deucher --- This is a duplicate of bug 60791. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #19 from Alex Deucher --- Please attach a copy of your vbios. (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] New: With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 Priority: medium Bug ID: 69120 Assignee: dri-devel@lists.freedesktop.org Summary: With dpm=1 vdpau is not usable Severity: normal Classification: Unclassified OS: Linux (All) Reporter: john.etted...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.2 Component: Drivers/Gallium/r600 Product: Mesa Hello, with radeon.dpm=0 (or not set), vdpau output works very fine. But if I switch to radeon.dpm=1 it becomes unusable. mplayer tells me that my computer is too slow, video stutters to a crazy extent, same in xbmc. With dpm set to 1, I am still able to watch videos "normally" if not using vdpau. I have a Radeon 4670, Linux 3.11, Mesa 9.2 and Radeon 1:7.2.0. I tried to change power_dpm_state and power_dpm_force_performance_level to see if it would help. power_dpm_state stays at performance but even if I set power_dpm_force_performance_level to high, but it always reverts to auto... This doesn't help at all... I am not sure what else to attach. Thank you -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #20 from Brian Hall --- Created attachment 107711 --> https://bugzilla.kernel.org/attachment.cgi?id=107711&action=edit copy of video bios -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #1 from Dieter Nützel --- Hello John, I see nearly the same with all 3.11-rcX and final plus 3.12-next. Only diffence with dpm=0 I get partially mosaic with bigger videos (1280x720 H.264 and 1920x1080 H.264) from time to time. But my system is much slower than yours: poor Duron 1800 ;-) RV730 AGP (4650) Mesa 9.2 and git master 3.11 and 3.12-next power_dpm_force_performance_level didn't works for me, too. > I am not sure what else to attach. Maybe your dmesg.log, Xorg.0.log and your vbios. (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom Mine comming, here. (With dual DVI monitor configuration I got something in dmesg) [drm:rv770_dpm_set_power_state] *ERROR* rv770_restrict_performance_levels_before_switch failed Regards, Dieter -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #2 from Dieter Nützel --- Created attachment 85467 --> https://bugs.freedesktop.org/attachment.cgi?id=85467&action=edit dmesg-3.11-dmp-1-two-displays.log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #3 from Dieter Nützel --- Created attachment 85468 --> https://bugs.freedesktop.org/attachment.cgi?id=85468&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #4 from Dieter Nützel --- Created attachment 85469 --> https://bugs.freedesktop.org/attachment.cgi?id=85469&action=edit copy of video bios -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #5 from Dieter Nützel --- # radeontool regmatch 0x0718 0x0718 0x20010002 (536936450) # radeontool regmatch 0x071c 0x071c 0x021f2111 (35594513) # radeontool regmatch 0x0720 0x0720 0x102774da (271021274) 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730 Pro AGP [Radeon HD 4600 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device 0028 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at c000 (32-bit, prefetchable) [size=256M] I/O ports at a800 [size=256] Memory at dfdf (32-bit, non-prefetchable) [size=64K] Expansion ROM at dfdc [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] AGP version 3.0 Kernel driver in use: radeon -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67800] Computer freezes after several hours (trinity)
https://bugs.freedesktop.org/show_bug.cgi?id=67800 Kertesz Laszlo changed: What|Removed |Added Summary|Computer freezes several|Computer freezes after |hours (trinity) |several hours (trinity) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67800] Computer freezes after several hours (trinity)
https://bugs.freedesktop.org/show_bug.cgi?id=67800 --- Comment #13 from Kertesz Laszlo --- The freezes are still happening, both with kernel 3.11 stable or the later git versions, mesa 9.2 stable or with the 9.3 devel git. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #45 from Aaron Watry --- (In reply to comment #43) > I patched llvm with > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130812/184089. > html > > using > > patch -N -p1 -i p2.patch > > But still got lock-ups. > Any hints? :/ I just did a fresh install of Ubuntu 3.04 64bit on an Athlon 64 with a radeonsi 6850. I did a checkout of LLVM/clang master and applied only the following patch: http://llvm-reviews.chandlerc.com/file/data/lzktdebskepaizauyiqg/PHID-FILE-ke45wuyidarlnthfbtcg/D1449.diff Without that patch, libclc won't currently build for the radeonsi target. Along with that I checked out git copies of Mesa, drm, and libclc. I upgraded the kernel to 3.11 from the Ubuntu mainline ppa, but I didn't enable dpm (machine wouldn't boot with it enabled, and I was too busy to debug that). With this done and all of the aforementioned packages compiled and installed to /usr/local, I have been running 'bfgminer -v1 --benchmark' without a single lockup for 20 minutes now on a radeonsi 6850 that used to exhibit the same lock ups that we have been discussing, and which also seem to have been cured on the 5400 card I was esting on before. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #46 from Aaron Watry --- Autocorrect got the best of me... s/radeonsi/radeon/g -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] nouveau: fix reclocking on nv40
On Sun, Sep 8, 2013 at 9:25 PM, Pali Rohár wrote: > On Wednesday 21 August 2013 02:24:01 Ben Skeggs wrote: >> On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár > wrote: >> > On Friday 16 August 2013 14:57:07 Pali Rohár wrote: >> >> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was >> >> introduced error which cause that reclocking on nv40 not >> >> working anymore. There is missing assigment of return value >> >> from pll_calc to ret. >> >> >> >> Signed-off-by: Pali Rohár >> >> Signed-off-by: Martin Peres >> >> --- >> >> >> >> drivers/gpu/drm/nouveau/nv40_pm.c |2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c >> >> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d >> >> 100644 >> >> --- a/drivers/gpu/drm/nouveau/nv40_pm.c >> >> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c >> >> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, >> >> u32 reg, struct nvbios_pll *pll, if (clk < >> >> pll->vco1.max_freq) >> >> >> >> pll->vco2.max_freq = 0; >> >> >> >> - pclk->pll_calc(pclk, pll, clk, &coef); >> >> + ret = pclk->pll_calc(pclk, pll, clk, &coef); >> >> >> >> if (ret == 0) >> >> >> >> return -ERANGE; >> > >> > Hello, it is possible to include this patch in 3.11? >> > Or it is too late now and need to wait for 3.12? >> >> I've picked up the patch and will submit it in my next >> 3.11-fixes pull request. >> >> Thanks, >> Ben. >> > > Hello, now I see that patch is in 3.11, thanks! Ben, what do you > think, can be this patch backported to older kernels? Personally, I don't care at all. The current PM code is a dead end, and completely not "supported" (hence why it's hidden behind a magic parameter). If I had my way it'd have been completely ripped out already. If someone wants to backport and test it on earlier kernels though, by all means, go ahead :) Thanks, Ben. > > -- > Pali Rohár > pali.ro...@gmail.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639
https://bugzilla.kernel.org/show_bug.cgi?id=61011 hams...@freenet.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from hams...@freenet.de --- *** This bug has been marked as a duplicate of bug 60791 *** -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 hams...@freenet.de changed: What|Removed |Added CC||hams...@freenet.de --- Comment #21 from hams...@freenet.de --- *** Bug 61011 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #6 from John --- Hello Dieter, thanks for the suggestions. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #7 from John --- Created attachment 85476 --> https://bugs.freedesktop.org/attachment.cgi?id=85476&action=edit John's vbios -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nv10/plane: add plane support for nv10-nv40
On Sun, Sep 8, 2013 at 10:33 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> This has received light testing on NV18 and NV34 cards, using the modetest
> tool. Userspace support to use this for xv is not yet ready.
>
> I decided against creating a new "pvideo" engine -- that just seems way too
> heavy-handed compared to the ~10 lines of code in disp/nv04.c to deal with the
> PVIDEO interrupts.
>
> Even though there are two possible planes, they are sufficiently linked
> together that I decided to just expose them as one, and do a
> double-buffering-style thing, similar to what xf86-video-nouveau did pre-KMS.
Merged:
http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=289d94b9e87eb09eb16a525e105d3a57a9f2e872
Thanks!
Ben.
>
> drivers/gpu/drm/nouveau/core/engine/disp/nv04.c | 9 +
> drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c | 1 +
> drivers/gpu/drm/nouveau/dispnv04/Makefile | 1 +
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +
> drivers/gpu/drm/nouveau/dispnv04/disp.h | 3 +
> drivers/gpu/drm/nouveau/dispnv04/hw.c | 10 +-
> drivers/gpu/drm/nouveau/dispnv04/overlay.c | 320
>
> 7 files changed, 342 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/nouveau/dispnv04/overlay.c
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
> b/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
> index 05e903f..a0bc8a8 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
> @@ -59,6 +59,7 @@ nv04_disp_intr(struct nouveau_subdev *subdev)
> struct nv04_disp_priv *priv = (void *)subdev;
> u32 crtc0 = nv_rd32(priv, 0x600100);
> u32 crtc1 = nv_rd32(priv, 0x602100);
> + u32 pvideo;
>
> if (crtc0 & 0x0001) {
> nouveau_event_trigger(priv->base.vblank, 0);
> @@ -69,6 +70,14 @@ nv04_disp_intr(struct nouveau_subdev *subdev)
> nouveau_event_trigger(priv->base.vblank, 1);
> nv_wr32(priv, 0x602100, 0x0001);
> }
> +
> + if (nv_device(priv)->chipset >= 0x10 &&
> + nv_device(priv)->chipset <= 0x40) {
> + pvideo = nv_rd32(priv, 0x8100);
> + if (pvideo & ~0x11)
> + nv_info(priv, "PVIDEO intr: %08x\n", pvideo);
> + nv_wr32(priv, 0x8100, pvideo);
> + }
> }
>
> static int
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
> b/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
> index 64aa4ed..062c048 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
> @@ -33,6 +33,7 @@ nv04_mc_intr[] = {
> { 0x0001, NVDEV_ENGINE_MPEG }, /* NV17- MPEG/ME */
> { 0x0100, NVDEV_ENGINE_FIFO },
> { 0x1000, NVDEV_ENGINE_GR },
> + { 0x0001, NVDEV_ENGINE_DISP },
> { 0x0002, NVDEV_ENGINE_VP },/* NV40- */
> { 0x0010, NVDEV_SUBDEV_TIMER },
> { 0x0100, NVDEV_ENGINE_DISP }, /* NV04- PCRTC0 */
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/Makefile
> b/drivers/gpu/drm/nouveau/dispnv04/Makefile
> index ea3f5b8..424a489 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/Makefile
> +++ b/drivers/gpu/drm/nouveau/dispnv04/Makefile
> @@ -5,6 +5,7 @@ nouveau-y += dispnv04/dac.o
> nouveau-y += dispnv04/dfp.o
> nouveau-y += dispnv04/disp.o
> nouveau-y += dispnv04/hw.o
> +nouveau-y += dispnv04/overlay.o
> nouveau-y += dispnv04/tvmodesnv17.o
> nouveau-y += dispnv04/tvnv04.o
> nouveau-y += dispnv04/tvnv17.o
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> index 4908d3f..b13ff0f 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> @@ -140,6 +140,8 @@ nv04_display_create(struct drm_device *dev)
> func->save(encoder);
> }
>
> + nouveau_overlay_init(dev);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h
> b/drivers/gpu/drm/nouveau/dispnv04/disp.h
> index 9928187..bb5c1bd 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
> @@ -123,6 +123,9 @@ int nv04_tv_create(struct drm_connector *, struct
> dcb_output *);
> /* nv17_tv.c */
> int nv17_tv_create(struct drm_connector *, struct dcb_output *);
>
> +/* overlay.c */
> +void nouveau_overlay_init(struct drm_device *dev);
> +
> static inline bool
> nv_two_heads(struct drm_device *dev)
> {
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
> b/drivers/gpu/drm/nouveau/dispnv04/hw.c
> index ffd2641..b1c5cd6 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
> @@ -27,6 +27,7 @@
> #include "hw.h"
>
> #include
> +#include
> #include
> #include
>
> @@ -664,6 +665,7 @@ nv_load_state_ext(struct drm_device *dev, int hea
Re: [PATCH] drm/nv84-: write fence value on exit, and restore value on init.
On Wed, Sep 4, 2013 at 10:37 PM, Maarten Lankhorst wrote: > Op 04-09-13 05:21, Ben Skeggs schreef: >> On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst >> wrote: >>> This increases the chance slightly that recovery from lockup can happen >>> succesfully. >> I'd *really* love to see proof of this. When channels die, all >> outstanding fences are marked as signalled. This should do absolutely >> nothing... > nv84+ heavily rely on fences though, and a race like this is possible: > - channel 0 uses a bo from channel 1, queues a wait somewhere in the command > stream for it. > - channel 1 dies cleanly, but userspace creates a new channel in its place, > fence counter is reset to 0. > - channel 0 reaches the NV84_SUBCHAN_SEMAPHORE_TRIGGER.ACQUIRE_GEQUAL op, > waits on fence in channel 1 to signal forever. Ok, this isn't exactly the issue you implied in the commit message. But yes, this could possibly be an issue for sure. I don't think this is the right way to fix it however. I'll have a bit of a think on the problem and see what I can come up with. Thanks, Ben. > > Channel 0 could be the global drm channel used for buffer moves, which would > result in a hang. This may seem unlikely, but I believe that parallel piglit > runs could trigger it. > > If not, simply creating an operation that takes a few seconds in channel 0 > and then queuing a command that uses a bo from channel 1 while chan1 is still > busy, then deleting/recreating chan1 could trigger it. > > ~Maarten > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #20 from Weber K. ---
Here is what Ive got!
If this dont help, please give me more details and I will try my best!
Thanks in advance!
xf86-video-ati 6.14.4
xorg-server 1.12.4
Program received signal SIGSEGV, Segmentation fault.
0x7ff17f1ad465 in radeon_dri2_destroy_buffer (drawable=0x343bbb0,
buffers=0x342cc40) at radeon_dri2.c:419
419xf86DrvMsg(scrn->scrnIndex, X_WARNING,
(gdb) bt f
#0 0x7ff17f1ad465 in radeon_dri2_destroy_buffer (drawable=0x343bbb0,
buffers=0x342cc40) at radeon_dri2.c:419
scrn = 0x0
pScreen = 0x30a0300
private = 0x343d8f0
#1 0x7ff17f1ad845 in radeon_dri2_unref_buffer (buffer=0x342cc40)
at radeon_dri2.c:585
private = 0x343d8f0
#2 0x7ff17f1ad8ec in radeon_dri2_client_state_changed (
ClientStateCallback=0x860c20 , data=0x0,
calldata=0x7fff2094cb90) at radeon_dri2.c:610
pClientEventsPriv = 0x345a4d0
ref = 0x353ca60
clientinfo = 0x7fff2094cb90
pClient = 0x345a410
#3 0x0043fd67 in _CallCallbacks (pcbl=0x860c20 ,
call_data=0x7fff2094cb90) at dixutils.c:715
cbl = 0x2880a40
cbr = 0x2881050
pcbr = 0x0
#4 0x004311fb in CallCallbacks (pcbl=0x860c20 ,
call_data=0x7fff2094cb90) at ../include/callback.h:83
No locals.
#5 0x0043926b in CloseDownClient (client=0x345a410) at dispatch.c:3380
clientinfo = {client = 0x345a410, prefix = 0x0, setup = 0x0}
really_close_down = 1
#6 0x004317ab in Dispatch () at dispatch.c:402
clientReady = 0x2ff5ee0
result = -1
client = 0x345a410
nready = 0
icheck = 0x860c30
start_tick = 320
#7 0x00422911 in main (argc=4, argv=0x7fff2094cd58,
envp=0x7fff2094cd80) at main.c:288
i = 2
alwaysCheckForInput = {0, 1}
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 --- Comment #7 from Pinak Ahuja --- Is there anything i can do to check that my BIOS is buggy. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
