[Bug 21682] White screen with compiz/AIGLX on X.org server 1.5.2 when running on 16bpp (intel 945GM)
https://bugs.freedesktop.org/show_bug.cgi?id=21682 --- Comment #15 from Stefan Dirsch 2010-09-17 23:36:59 PDT --- Tamás is already using openSUSE 11.3, which ships xorg-server 1.8 and therefore includes DRI2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 21682] White screen with compiz/AIGLX on X.org server 1.5.2 when running on 16bpp (intel 945GM)
https://bugs.freedesktop.org/show_bug.cgi?id=21682 --- Comment #15 from Stefan Dirsch 2010-09-17 23:36:59 PDT --- Tam?s is already using openSUSE 11.3, which ships xorg-server 1.8 and therefore includes DRI2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
r300 PenumbraOverture complete hang 2.6.35/36-rc4 (regression)
Hello, Last week I reported a complete hang with PenumbraOverture on kernel 2.6.35 and 2.6.36-rc3. This week I tried 2.6.36-rc4, and I still get a complete hang after playing PenumbraOverture for about a minute. I'm not using any xorg.conf, I'm using KMS. I also tried without KMS, and then I have no problem. 2.6.34 is the last kernel that worked with KMS. I got no reaction on my first mail; could you please let me know whether this report is useful at all? And if so, could you please let me know if I should file this in Bugzilla? I searched bugzilla but I couldn't find anything like I'm reporting here. Also, this problem does not seem to be reported as a kernel regression. Or maybe the problem is that I'm not subscribed to the dri-devel mailing list. My graphics adapter is an ATI Technologies Inc M24GL [Mobility FireGL V3200] (rev 80), and I'm using Slackware 13.1 with Mesa 7.8.1, Xserver 1.7.7. I wasn't able to get any further information--I tried running the game with all graphics options turned off, but it didn't help. Anyway, I'd really like this problem to be solved, and I'd very much like to help out as much as I can. PJ
Remaining BKL users, what to do
On Thursday 16 September 2010 20:32:36 Jens Axboe wrote:
> On 2010-09-16 16:49, Steven Rostedt wrote:
> > Git blame shows this to be your code (copied from block/blktrace.c from
> > years past).
> >
> > Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
>
> It isn't, it can be removed.
Ok, I queued up this patch now. Thanks!
Arnd
---
Subject: [PATCH] blktrace: remove the big kernel lock
According to Jens, this code does not need the BKL at all,
it is sufficiently serialized by bd_mutex.
Signed-off-by: Arnd Bergmann
Cc: Jens Axboe
Cc: Steven Rostedt
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 959f8d6..5328e87 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
@@ -639,7 +638,6 @@ int blk_trace_ioctl(struct block_device *bdev, unsigned
cmd, char __user *arg)
if (!q)
return -ENXIO;
- lock_kernel();
mutex_lock(&bdev->bd_mutex);
switch (cmd) {
@@ -667,7 +665,6 @@ int blk_trace_ioctl(struct block_device *bdev, unsigned
cmd, char __user *arg)
}
mutex_unlock(&bdev->bd_mutex);
- unlock_kernel();
return ret;
}
@@ -1652,10 +1649,9 @@ static ssize_t sysfs_blk_trace_attr_show(struct device
*dev,
struct block_device *bdev;
ssize_t ret = -ENXIO;
- lock_kernel();
bdev = bdget(part_devt(p));
if (bdev == NULL)
- goto out_unlock_kernel;
+ goto out;
q = blk_trace_get_queue(bdev);
if (q == NULL)
@@ -1683,8 +1679,7 @@ out_unlock_bdev:
mutex_unlock(&bdev->bd_mutex);
out_bdput:
bdput(bdev);
-out_unlock_kernel:
- unlock_kernel();
+out:
return ret;
}
@@ -1714,11 +1709,10 @@ static ssize_t sysfs_blk_trace_attr_store(struct device
*dev,
ret = -ENXIO;
- lock_kernel();
p = dev_to_part(dev);
bdev = bdget(part_devt(p));
if (bdev == NULL)
- goto out_unlock_kernel;
+ goto out;
q = blk_trace_get_queue(bdev);
if (q == NULL)
@@ -1753,8 +1747,6 @@ out_unlock_bdev:
mutex_unlock(&bdev->bd_mutex);
out_bdput:
bdput(bdev);
-out_unlock_kernel:
- unlock_kernel();
out:
return ret ? ret : count;
}
nouveau/ttm: BUG in ttm_bo_release_list
Hi Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a couple of times a day: [ 2869.618504] [ cut here ] [ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153! [ 2869.618560] invalid opcode: [#1] PREEMPT SMP [ 2869.618600] last sysfs file: /sys/devices/pci:00/:00:03.0/:02:00.0/pm_status [ 2869.618637] CPU 0 [ 2869.618649] Modules linked in: nouveau ttm drm_kms_helper snd_hda_codec_realtek snd_hda_intel snd_hda_codec [ 2869.618730] [ 2869.618742] Pid: 11, comm: kworker/0:1 Not tainted 2.6.36-rc3-nv+ #485 P6T SE/System Product Name [ 2869.618781] RIP: 0010:[] [] ttm_bo_release_list+0x37/0xcf [ttm] [ 2869.618830] RSP: 0018:8801bfd85d40 EFLAGS: 00010202 [ 2869.618855] RAX: 0001 RBX: 8801b1e50c00 RCX: 8801b7500330 [ 2869.618887] RDX: 0001 RSI: 0037 RDI: 8801b1e50c44 [ 2869.618918] RBP: 8801bfd85d60 R08: 0002 R09: 8801bf683000 [ 2869.618950] R10: 8801b1e50c70 R11: R12: 8801b1e50c44 [ 2869.618981] R13: 8801b7500188 R14: R15: 8801b7500738 [ 2869.619013] FS: () GS:880001e0() knlGS: [ 2869.619048] CS: 0010 DS: ES: CR0: 8005003b [ 2869.619074] CR2: 7f2cc0f6b000 CR3: 0001bfe8a000 CR4: 06f0 [ 2869.619106] DR0: DR1: DR2: [ 2869.619137] DR3: DR6: 0ff0 DR7: 0400 [ 2869.619168] Process kworker/0:1 (pid: 11, threadinfo 8801bfd84000, task 8801bfd88000) [ 2869.619205] Stack: [ 2869.619217] 8801b1e50c44 a0082c67 8801bdcb8ab0 [ 2869.619262] <0> 8801bfd85d80 8121c83a 8801b1e5 8801b1e50c00 [ 2869.619318] <0> 8801bfd85dd0 a00839f4 880001e0ebc0 0001 [ 2869.619374] Call Trace: [ 2869.619392] [] ? ttm_bo_release_list+0x0/0xcf [ttm] [ 2869.619425] [] kref_put+0x43/0x4d [ 2869.619451] [] ttm_bo_delayed_delete+0xa2/0xf9 [ttm] [ 2869.619484] [] ? ttm_bo_delayed_workqueue+0x0/0x30 [ttm] [ 2869.619517] [] ttm_bo_delayed_workqueue+0x1a/0x30 [ttm] [ 2869.619551] [] process_one_work+0x29f/0x448 [ 2869.619580] [] worker_thread+0x1d6/0x349 [ 2869.619607] [] ? worker_thread+0x0/0x349 [ 2869.619635] [] kthread+0x7d/0x85 [ 2869.619661] [] kernel_thread_helper+0x4/0x10 [ 2869.619692] [] ? finish_task_switch+0x49/0xb2 [ 2869.619722] [] ? _raw_spin_unlock_irq+0x19/0x34 [ 2869.619752] [] ? restore_args+0x0/0x30 [ 2869.619779] [] ? kthread+0x0/0x85 [ 2869.619805] [] ? kernel_thread_helper+0x0/0x10 [ 2869.619832] Code: 48 8d 5f bc 48 83 ec 08 8b 07 4c 8b 6f c4 85 c0 74 04 0f 0b eb fe 8b 47 fc 85 c0 74 04 0f 0b eb fe 8b 87 a8 00 00 00 85 c0 74 04 <0f> 0b eb fe 48 83 bb 38 01 00 00 00 74 04 0f 0b eb fe 48 83 bb [ 2869.620255] RIP [] ttm_bo_release_list+0x37/0xcf [ttm] [ 2869.620295] RSP [ 2869.629610] ---[ end trace 302a6257f0da8cdc ]--- this is BUG_ON(atomic_read(&bo->cpu_writers)); I'm on b642f07208988270ac402d2548d42dab1d5fec92 "drm/nv50: fix 100c90 write on nva3". If you have any patches / ideas how to debug this, let me know. Marcin
[PATCH] drm/edid: Don't repeatedly log hex dumps of bad EDIDs by default
On my system, every 10 seconds drm_edid_block_valid() gets called 4
times by radeon_dvi_detect(). This results in 4 instances of a
multi-line hex dump of the same EDID (non-)data being logged every 10
seconds.
Silence the hex dump from drm_edid_block_valid() unless a drm_debug
module parameter flag is set.
Signed-of-by: Andy Walls
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dce5c4a..33a748c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -173,9 +173,12 @@ drm_edid_block_valid(u8 *raw_edid)
bad:
if (raw_edid) {
- DRM_ERROR("Raw EDID:\n");
- print_hex_dump_bytes(KERN_ERR, DUMP_PREFIX_NONE, raw_edid,
EDID_LENGTH);
- printk("\n");
+ DRM_DEBUG("Raw EDID:\n");
+ if (drm_debug & DRM_UT_CORE) {
+ print_hex_dump_bytes(KERN_ERR, DUMP_PREFIX_NONE,
+raw_edid, EDID_LENGTH);
+ printk("\n");
+ }
}
return 0;
}
Re: nouveau/ttm: BUG in ttm_bo_release_list
On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote: > Hi > Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a > couple of times a day: > > [ 2869.618504] [ cut here ] > [ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153! > [ 2869.618560] invalid opcode: [#1] PREEMPT SMP > [ 2869.618600] last sysfs file: > /sys/devices/pci:00/:00:03.0/:02:00.0/pm_status > [ 2869.618637] CPU 0 > [ 2869.618649] Modules linked in: nouveau ttm drm_kms_helper > snd_hda_codec_realtek snd_hda_intel snd_hda_codec > [ 2869.618730] > [ 2869.618742] Pid: 11, comm: kworker/0:1 Not tainted 2.6.36-rc3-nv+ #485 P6T > SE/System Product Name > [ 2869.618781] RIP: 0010:[] [] > ttm_bo_release_list+0x37/0xcf [ttm] > [ 2869.618830] RSP: 0018:8801bfd85d40 EFLAGS: 00010202 > [ 2869.618855] RAX: 0001 RBX: 8801b1e50c00 RCX: > 8801b7500330 > [ 2869.618887] RDX: 0001 RSI: 0037 RDI: > 8801b1e50c44 > [ 2869.618918] RBP: 8801bfd85d60 R08: 0002 R09: > 8801bf683000 > [ 2869.618950] R10: 8801b1e50c70 R11: R12: > 8801b1e50c44 > [ 2869.618981] R13: 8801b7500188 R14: R15: > 8801b7500738 > [ 2869.619013] FS: () GS:880001e0() > knlGS: > [ 2869.619048] CS: 0010 DS: ES: CR0: 8005003b > [ 2869.619074] CR2: 7f2cc0f6b000 CR3: 0001bfe8a000 CR4: > 06f0 > [ 2869.619106] DR0: DR1: DR2: > > [ 2869.619137] DR3: DR6: 0ff0 DR7: > 0400 > [ 2869.619168] Process kworker/0:1 (pid: 11, threadinfo 8801bfd84000, > task 8801bfd88000) > [ 2869.619205] Stack: > [ 2869.619217] 8801b1e50c44 a0082c67 > 8801bdcb8ab0 > [ 2869.619262] <0> 8801bfd85d80 8121c83a 8801b1e5 > 8801b1e50c00 > [ 2869.619318] <0> 8801bfd85dd0 a00839f4 880001e0ebc0 > 0001 > [ 2869.619374] Call Trace: > [ 2869.619392] [] ? ttm_bo_release_list+0x0/0xcf [ttm] > [ 2869.619425] [] kref_put+0x43/0x4d > [ 2869.619451] [] ttm_bo_delayed_delete+0xa2/0xf9 [ttm] > [ 2869.619484] [] ? ttm_bo_delayed_workqueue+0x0/0x30 [ttm] > [ 2869.619517] [] ttm_bo_delayed_workqueue+0x1a/0x30 [ttm] > [ 2869.619551] [] process_one_work+0x29f/0x448 > [ 2869.619580] [] worker_thread+0x1d6/0x349 > [ 2869.619607] [] ? worker_thread+0x0/0x349 > [ 2869.619635] [] kthread+0x7d/0x85 > [ 2869.619661] [] kernel_thread_helper+0x4/0x10 > [ 2869.619692] [] ? finish_task_switch+0x49/0xb2 > [ 2869.619722] [] ? _raw_spin_unlock_irq+0x19/0x34 > [ 2869.619752] [] ? restore_args+0x0/0x30 > [ 2869.619779] [] ? kthread+0x0/0x85 > [ 2869.619805] [] ? kernel_thread_helper+0x0/0x10 > [ 2869.619832] Code: 48 8d 5f bc 48 83 ec 08 8b 07 4c 8b 6f c4 85 c0 74 04 0f > 0b eb fe 8b 47 fc 85 c0 74 04 0f 0b eb fe 8b 87 a8 00 00 00 85 c0 74 04 <0f> > 0b eb fe 48 83 bb 38 01 00 00 00 74 04 0f 0b eb fe 48 83 bb > [ 2869.620255] RIP [] ttm_bo_release_list+0x37/0xcf [ttm] > [ 2869.620295] RSP > [ 2869.629610] ---[ end trace 302a6257f0da8cdc ]--- > > this is BUG_ON(atomic_read(&bo->cpu_writers)); > > I'm on b642f07208988270ac402d2548d42dab1d5fec92 "drm/nv50: fix 100c90 write > on nva3". > If you have any patches / ideas how to debug this, let me know. I've actually seen this a couple of times. It appears I was incorrectly blaming some patches I have in progress for it, the problem appeared to go away when I reverted them. Perhaps it's more random. I have no current ideas however. Ben. > > Marcin > ___ > 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
Remaining BKL users, what to do
I'll try to come up with something for ncpfs.
Trivial lock replacement will open deadlock possibility when someone reads to
page which is also mmaped from the same filesystem (like grep likes to do). BKL
with its automated release on sleep helped (or papered over) a lot here.
Petr
"Arnd Bergmann" wrote:
>On Thursday 16 September 2010, Anton Altaparmakov wrote:
>> On 16 Sep 2010, at 16:04, Jan Kara wrote:
>> > On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
>> >> The big kernel lock is gone from almost all code in linux-next, this is
>> >> the status of what I think will happen to the remaining users:
>> > ...
>> >> fs/ncpfs:
>> >> Should be fixable if Petr still cares about it. Otherwise suggest
>> >> moving to drivers/staging if there are no users left.
>> > I think some people still use this...
>>
>> Yes, indeed. Netware is still alive (unfortunately!) and ncpfs is used in a
>> lot of
>> Universities here in the UK at least (we use it about a thousand
>> workstations and
>> servers here at Cambridge University!).
>
>Ok, that means at least when someone gets around to fix it, there will be
>people that can test the patches.
>
>If you know someone who would like to help on this, it would be nice to try
>out the patch below, unless someone can come up with a better solution.
>My na?ve understanding of the code tells me that simply using the super block
>lock there may work. In fact it makes locking stricter, so if it still works
>with that patch, there are probably no subtle regressions.
>The patch applies to current linux-next of my bkl/vfs series.
>
> Arnd
>
>---
>ncpfs: replace BKL with lock_super
>
>This mindlessly changes every instance of lock_kernel in ncpfs to
>lock_super. I haven't tested this, it may work or may break horribly.
>Please test with CONFIG_LOCKDEP enabled.
>
>Signed-off-by: Arnd Bergmann
>
>diff --git a/fs/ncpfs/dir.c b/fs/ncpfs/dir.c
>index 9578cbe..303338d 100644
>--- a/fs/ncpfs/dir.c
>+++ b/fs/ncpfs/dir.c
>@@ -19,7 +19,6 @@
> #include
> #include
> #include
>-#include
>
> #include
>
>@@ -339,9 +338,10 @@ static int
> ncp_lookup_validate(struct dentry * dentry, struct nameidata *nd)
> {
> int res;
>- lock_kernel();
>+ struct super_block *sb = dentry->d_inode->i_sb;
>+ lock_super(sb);
> res = __ncp_lookup_validate(dentry);
>- unlock_kernel();
>+ unlock_super(sb);
> return res;
> }
>
>@@ -404,6 +404,7 @@ static int ncp_readdir(struct file *filp, void *dirent,
>filldir_t filldir)
> {
> struct dentry *dentry = filp->f_path.dentry;
> struct inode *inode = dentry->d_inode;
>+ struct super_block *sb = inode->i_sb;
> struct page *page = NULL;
> struct ncp_server *server = NCP_SERVER(inode);
> union ncp_dir_cache *cache = NULL;
>@@ -411,7 +412,7 @@ static int ncp_readdir(struct file *filp, void *dirent,
>filldir_t filldir)
> int result, mtime_valid = 0;
> time_t mtime = 0;
>
>- lock_kernel();
>+ lock_super(sb);
>
> ctl.page = NULL;
> ctl.cache = NULL;
>@@ -546,7 +547,7 @@ finished:
> page_cache_release(ctl.page);
> }
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return result;
> }
>
>@@ -794,12 +795,13 @@ out:
> static struct dentry *ncp_lookup(struct inode *dir, struct dentry *dentry,
> struct nameidata *nd)
> {
> struct ncp_server *server = NCP_SERVER(dir);
>+ struct super_block *sb = dir->i_sb;
> struct inode *inode = NULL;
> struct ncp_entry_info finfo;
> int error, res, len;
> __u8 __name[NCP_MAXPATHLEN + 1];
>
>- lock_kernel();
>+ lock_super(sb);
> error = -EIO;
> if (!ncp_conn_valid(server))
> goto finished;
>@@ -846,7 +848,7 @@ add_entry:
>
> finished:
> PPRINTK("ncp_lookup: result=%d\n", error);
>- unlock_kernel();
>+ unlock_super(sb);
> return ERR_PTR(error);
> }
>
>@@ -880,6 +882,7 @@ int ncp_create_new(struct inode *dir, struct dentry
>*dentry, int mode,
> {
> struct ncp_server *server = NCP_SERVER(dir);
> struct ncp_entry_info finfo;
>+ struct super_block *sb = dir->i_sb;
> int error, result, len;
> int opmode;
> __u8 __name[NCP_MAXPATHLEN + 1];
>@@ -888,7 +891,7 @@ int ncp_create_new(struct inode *dir, struct dentry
>*dentry, int mode,
> dentry->d_parent->d_name.name, dentry->d_name.name, mode);
>
> error = -EIO;
>- lock_kernel();
>+ lock_super(sb);
> if (!ncp_conn_valid(server))
> goto out;
>
>@@ -935,7 +938,7 @@ int ncp_create_new(struct inode *dir, struct dentry
>*dentry, int mode,
>
> error = ncp_instantiate(dir, dentry, &finfo);
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return error;
> }
>
>@@ -949,6 +952,7 @@ static int ncp_mkdir(struct inode *dir, struct dentry
>*dentry, int mode)
> {
> struct ncp_entry_info finfo;
> struct ncp_server *server = NCP_SER
[PATCH 2/2] drm/i915: Support for another B43 device id
We find there is another device id set for B43 chipset. After adding the device
id 4E90/4E92 beside 4E40/4E42, the machine works fine with the same
modification in xserver-xorg-video-intel.
Signed-off-by: Ike Panhc
---
drivers/gpu/drm/i915/i915_drv.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 216deb5..a9876ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -170,6 +170,7 @@ static const struct pci_device_id pciidlist[] = {
/* aka */
INTEL_VGA_DEVICE(0x2e22, &intel_g45_info), /* G45_G */
INTEL_VGA_DEVICE(0x2e32, &intel_g45_info), /* G41_G */
INTEL_VGA_DEVICE(0x2e42, &intel_g45_info), /* B43_G */
+ INTEL_VGA_DEVICE(0x2e92, &intel_g45_info), /* B43_G */
INTEL_VGA_DEVICE(0xa001, &intel_pineview_info),
INTEL_VGA_DEVICE(0xa011, &intel_pineview_info),
INTEL_VGA_DEVICE(0x0042, &intel_ironlake_d_info),
--
1.7.1
[PATCH 1/2] apg/intel: Support for another B43 device id
We find there is another device id set for B43 chipset. After adding the device
id 4E90/4E92 beside 4E40/4E42, the machine works fine with the same
modification in xserver-xorg-video-intel.
Signed-off-by: Ike Panhc
---
drivers/char/agp/intel-agp.c |7 +--
drivers/char/agp/intel-agp.h |9 ++---
drivers/char/agp/intel-gtt.c |3 ++-
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index eab58db..b7eef63 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -804,7 +804,9 @@ static const struct intel_driver_description {
"Q45/Q43", NULL, &intel_i965_driver },
{ PCI_DEVICE_ID_INTEL_G45_HB, PCI_DEVICE_ID_INTEL_G45_IG,
"G45/G43", NULL, &intel_i965_driver },
- { PCI_DEVICE_ID_INTEL_B43_HB, PCI_DEVICE_ID_INTEL_B43_IG,
+ { PCI_DEVICE_ID_INTEL_B43_1_HB, PCI_DEVICE_ID_INTEL_B43_1_IG,
+ "B43", NULL, &intel_i965_driver },
+ { PCI_DEVICE_ID_INTEL_B43_2_HB, PCI_DEVICE_ID_INTEL_B43_2_IG,
"B43", NULL, &intel_i965_driver },
{ PCI_DEVICE_ID_INTEL_G41_HB, PCI_DEVICE_ID_INTEL_G41_IG,
"G41", NULL, &intel_i965_driver },
@@ -1046,7 +1048,8 @@ static struct pci_device_id agp_intel_pci_table[] = {
ID(PCI_DEVICE_ID_INTEL_Q45_HB),
ID(PCI_DEVICE_ID_INTEL_G45_HB),
ID(PCI_DEVICE_ID_INTEL_G41_HB),
- ID(PCI_DEVICE_ID_INTEL_B43_HB),
+ ID(PCI_DEVICE_ID_INTEL_B43_1_HB),
+ ID(PCI_DEVICE_ID_INTEL_B43_2_HB),
ID(PCI_DEVICE_ID_INTEL_IRONLAKE_D_HB),
ID(PCI_DEVICE_ID_INTEL_IRONLAKE_M_HB),
ID(PCI_DEVICE_ID_INTEL_IRONLAKE_MA_HB),
diff --git a/drivers/char/agp/intel-agp.h b/drivers/char/agp/intel-agp.h
index ee189c7..5d9c17c 100644
--- a/drivers/char/agp/intel-agp.h
+++ b/drivers/char/agp/intel-agp.h
@@ -184,8 +184,10 @@
#define PCI_DEVICE_ID_INTEL_Q35_IG 0x29B2
#define PCI_DEVICE_ID_INTEL_Q33_HB 0x29D0
#define PCI_DEVICE_ID_INTEL_Q33_IG 0x29D2
-#define PCI_DEVICE_ID_INTEL_B43_HB 0x2E40
-#define PCI_DEVICE_ID_INTEL_B43_IG 0x2E42
+#define PCI_DEVICE_ID_INTEL_B43_1_HB0x2E40
+#define PCI_DEVICE_ID_INTEL_B43_1_IG0x2E42
+#define PCI_DEVICE_ID_INTEL_B43_2_HB0x2E90
+#define PCI_DEVICE_ID_INTEL_B43_2_IG0x2E92
#define PCI_DEVICE_ID_INTEL_GM45_HB 0x2A40
#define PCI_DEVICE_ID_INTEL_GM45_IG 0x2A42
#define PCI_DEVICE_ID_INTEL_EAGLELAKE_HB0x2E00
@@ -246,7 +248,8 @@
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_G45_HB || \
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_GM45_HB || \
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_G41_HB || \
- agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_B43_HB || \
+ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_B43_1_HB || \
+ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_B43_2_HB || \
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_IRONLAKE_D_HB ||
\
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_IRONLAKE_M_HB ||
\
agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_IRONLAKE_MA_HB
|| \
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 75e0a34..3c71568 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1379,7 +1379,8 @@ static void intel_i965_get_gtt_range(int *gtt_offset, int
*gtt_size)
case PCI_DEVICE_ID_INTEL_Q45_HB:
case PCI_DEVICE_ID_INTEL_G45_HB:
case PCI_DEVICE_ID_INTEL_G41_HB:
- case PCI_DEVICE_ID_INTEL_B43_HB:
+ case PCI_DEVICE_ID_INTEL_B43_1_HB:
+ case PCI_DEVICE_ID_INTEL_B43_2_HB:
case PCI_DEVICE_ID_INTEL_IRONLAKE_D_HB:
case PCI_DEVICE_ID_INTEL_IRONLAKE_M_HB:
case PCI_DEVICE_ID_INTEL_IRONLAKE_MA_HB:
--
1.7.1
[PATCH 0/2] Add device id for Intel B43 chipset
There is another device id for Intel B43 chip. Since there is already an id sets for B43 in intel-agp and i915. We tried to modify the kernel and xserver-xorg-video-intel and they work fine on 8086:2E90/2E92 chipsets. I believe this id sets is valid[1], and another patches has been sent to bug tracking system of freedesktop[2]. Since this is a blind try, please review the patches and if there is no more modification needed, please consider apply them. [1] https://upgrades.intel.com/Public/PublicLandingPage.aspx [2] https://bugs.freedesktop.org/show_bug.cgi?id=30221 Ike Panhc (2): apg/intel: Support for another B43 device id drm/i915: Support for another B43 device id drivers/char/agp/intel-agp.c|7 +-- drivers/char/agp/intel-agp.h|9 ++--- drivers/char/agp/intel-gtt.c|3 ++- drivers/gpu/drm/i915/i915_drv.c |1 + 4 files changed, 14 insertions(+), 6 deletions(-)
nouveau/ttm: BUG in ttm_bo_release_list
Hi Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a couple of times a day: [ 2869.618504] [ cut here ] [ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153! [ 2869.618560] invalid opcode: [#1] PREEMPT SMP [ 2869.618600] last sysfs file: /sys/devices/pci:00/:00:03.0/:02:00.0/pm_status [ 2869.618637] CPU 0 [ 2869.618649] Modules linked in: nouveau ttm drm_kms_helper snd_hda_codec_realtek snd_hda_intel snd_hda_codec [ 2869.618730] [ 2869.618742] Pid: 11, comm: kworker/0:1 Not tainted 2.6.36-rc3-nv+ #485 P6T SE/System Product Name [ 2869.618781] RIP: 0010:[] [] ttm_bo_release_list+0x37/0xcf [ttm] [ 2869.618830] RSP: 0018:8801bfd85d40 EFLAGS: 00010202 [ 2869.618855] RAX: 0001 RBX: 8801b1e50c00 RCX: 8801b7500330 [ 2869.618887] RDX: 0001 RSI: 0037 RDI: 8801b1e50c44 [ 2869.618918] RBP: 8801bfd85d60 R08: 0002 R09: 8801bf683000 [ 2869.618950] R10: 8801b1e50c70 R11: R12: 8801b1e50c44 [ 2869.618981] R13: 8801b7500188 R14: R15: 8801b7500738 [ 2869.619013] FS: () GS:880001e0() knlGS: [ 2869.619048] CS: 0010 DS: ES: CR0: 8005003b [ 2869.619074] CR2: 7f2cc0f6b000 CR3: 0001bfe8a000 CR4: 06f0 [ 2869.619106] DR0: DR1: DR2: [ 2869.619137] DR3: DR6: 0ff0 DR7: 0400 [ 2869.619168] Process kworker/0:1 (pid: 11, threadinfo 8801bfd84000, task 8801bfd88000) [ 2869.619205] Stack: [ 2869.619217] 8801b1e50c44 a0082c67 8801bdcb8ab0 [ 2869.619262] <0> 8801bfd85d80 8121c83a 8801b1e5 8801b1e50c00 [ 2869.619318] <0> 8801bfd85dd0 a00839f4 880001e0ebc0 0001 [ 2869.619374] Call Trace: [ 2869.619392] [] ? ttm_bo_release_list+0x0/0xcf [ttm] [ 2869.619425] [] kref_put+0x43/0x4d [ 2869.619451] [] ttm_bo_delayed_delete+0xa2/0xf9 [ttm] [ 2869.619484] [] ? ttm_bo_delayed_workqueue+0x0/0x30 [ttm] [ 2869.619517] [] ttm_bo_delayed_workqueue+0x1a/0x30 [ttm] [ 2869.619551] [] process_one_work+0x29f/0x448 [ 2869.619580] [] worker_thread+0x1d6/0x349 [ 2869.619607] [] ? worker_thread+0x0/0x349 [ 2869.619635] [] kthread+0x7d/0x85 [ 2869.619661] [] kernel_thread_helper+0x4/0x10 [ 2869.619692] [] ? finish_task_switch+0x49/0xb2 [ 2869.619722] [] ? _raw_spin_unlock_irq+0x19/0x34 [ 2869.619752] [] ? restore_args+0x0/0x30 [ 2869.619779] [] ? kthread+0x0/0x85 [ 2869.619805] [] ? kernel_thread_helper+0x0/0x10 [ 2869.619832] Code: 48 8d 5f bc 48 83 ec 08 8b 07 4c 8b 6f c4 85 c0 74 04 0f 0b eb fe 8b 47 fc 85 c0 74 04 0f 0b eb fe 8b 87 a8 00 00 00 85 c0 74 04 <0f> 0b eb fe 48 83 bb 38 01 00 00 00 74 04 0f 0b eb fe 48 83 bb [ 2869.620255] RIP [] ttm_bo_release_list+0x37/0xcf [ttm] [ 2869.620295] RSP [ 2869.629610] ---[ end trace 302a6257f0da8cdc ]--- this is BUG_ON(atomic_read(&bo->cpu_writers)); I'm on b642f07208988270ac402d2548d42dab1d5fec92 "drm/nv50: fix 100c90 write on nva3". If you have any patches / ideas how to debug this, let me know. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] nouveau build regression, undefined reference to `acpi_video_get_edid'
Phil Turmel writes: > Build breakage: > > drivers/built-in.o: In function `nouveau_acpi_edid': > (.text+0x13404e): undefined reference to `acpi_video_get_edid' > make: *** [.tmp_vmlinux1] Error 1 > > Introduced by: > > a6ed76d7ffc62ffa474b41d31b011b6853c5de32 is the first bad commit > commit a6ed76d7ffc62ffa474b41d31b011b6853c5de32 > Author: Ben Skeggs > Date: Mon Jul 12 15:33:07 2010 +1000 > > drm/nouveau: support fetching LVDS EDID from ACPI > > Based on a patch from Matthew Garrett. > > Signed-off-by: Ben Skeggs > Acked-by: Matthew Garrett > > :04 04 2fbe9b4d9778329908107e72c11b100c2f5a460b > 97dcf06923bb576298746584c45d17d3be9edcf8 M drivers > > It doesn't seem to revert cleanly, but the problem lies in these > two config entries: > > CONFIG_ACPI=y > CONFIG_ACPI_VIDEO=m > > Adding a select for ACPI_VIDEO appears to be the best solution, and > is comparable to what is done in DRM_I915. Builds, boots, and appears to > work correctly. > > Signed-off-by: Philip J. Turmel > --- > > The first version disabled all ACPI functions in the nouveau driver if > ACPI_VIDEO wasn't set. Francisco Jerez pointed out > that this didn't make much sense. > > diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig > index d2d2804..72730e9 100644 > --- a/drivers/gpu/drm/nouveau/Kconfig > +++ b/drivers/gpu/drm/nouveau/Kconfig > @@ -10,6 +10,7 @@ config DRM_NOUVEAU > select FB > select FRAMEBUFFER_CONSOLE if !EMBEDDED > select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT > + select ACPI_VIDEO if ACPI > help > Choose this option for open-source nVidia support. Thanks, pushed to the nouveau tree. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100917/9056e4ec/attachment.pgp>
[Bug 30227] Radom X.org freeze by a GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #5 from Michel Dänzer 2010-09-17 03:11:18 PDT --- (In reply to comment #4) > This happens with radeon.agpmode=-1 on the kernel boot command line. Without > it, the kernel doesn't boot (it freeze, without eth connection and monitor > freeze on some openfirmware specification - I have no serial - when switching > from openfirmware to kernel itself, I think). How about agpmode=1? There's an issue with higher transfer rates that Ben Herrenschmidt is working on fixing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 30227] Radom X.org freeze by a GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #5 from Michel D?nzer 2010-09-17 03:11:18 PDT --- (In reply to comment #4) > This happens with radeon.agpmode=-1 on the kernel boot command line. Without > it, the kernel doesn't boot (it freeze, without eth connection and monitor > freeze on some openfirmware specification - I have no serial - when switching > from openfirmware to kernel itself, I think). How about agpmode=1? There's an issue with higher transfer rates that Ben Herrenschmidt is working on fixing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28294] [r300g] Unigine Sanctuary v2.2: black glitches
https://bugs.freedesktop.org/show_bug.cgi?id=28294 --- Comment #29 from Pavel Ondračka 2010-09-17 02:39:42 PDT --- Created an attachment (id=38758) --> (https://bugs.freedesktop.org/attachment.cgi?id=38758) screenshot with current mesa git (dab2a7660a407364a7327743b56ea9701d9b) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 28294] [r300g] Unigine Sanctuary v2.2: black glitches
https://bugs.freedesktop.org/show_bug.cgi?id=28294 --- Comment #29 from Pavel Ondra?ka 2010-09-17 02:39:42 PDT --- Created an attachment (id=38758) --> (https://bugs.freedesktop.org/attachment.cgi?id=38758) screenshot with current mesa git (dab2a7660a407364a7327743b56ea9701d9b) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28294] [r300g] Unigine Sanctuary v2.2: black glitches
https://bugs.freedesktop.org/show_bug.cgi?id=28294 --- Comment #28 from Pavel Ondračka 2010-09-17 02:38:12 PDT --- Created an attachment (id=38757) --> (https://bugs.freedesktop.org/attachment.cgi?id=38757) screenshot with mesa 9021c56a5738815777f27c39b63637b5975270c6 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 28294] [r300g] Unigine Sanctuary v2.2: black glitches
https://bugs.freedesktop.org/show_bug.cgi?id=28294 --- Comment #28 from Pavel Ondra?ka 2010-09-17 02:38:12 PDT --- Created an attachment (id=38757) --> (https://bugs.freedesktop.org/attachment.cgi?id=38757) screenshot with mesa 9021c56a5738815777f27c39b63637b5975270c6 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28294] [r300g] Unigine Sanctuary v2.2: black glitches
https://bugs.freedesktop.org/show_bug.cgi?id=28294 Pavel Ondračka changed: What|Removed |Added Attachment #35900|0 |1 is obsolete|| Attachment #36173|0 |1 is obsolete|| Attachment #36703|0 |1 is obsolete|| Attachment #36704|0 |1 is obsolete|| Attachment #36705|0 |1 is obsolete|| --- Comment #27 from Pavel Ondračka 2010-09-17 02:36:37 PDT --- Created an attachment (id=38756) --> (https://bugs.freedesktop.org/attachment.cgi?id=38756) screenshot just before 9021c56a5738815777f27c39b63637b5975270c6 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 28294] [r300g] Unigine Sanctuary v2.2: black glitches
https://bugs.freedesktop.org/show_bug.cgi?id=28294 Pavel Ondra?ka changed: What|Removed |Added Attachment #35900|0 |1 is obsolete|| Attachment #36173|0 |1 is obsolete|| Attachment #36703|0 |1 is obsolete|| Attachment #36704|0 |1 is obsolete|| Attachment #36705|0 |1 is obsolete|| --- Comment #27 from Pavel Ondra?ka 2010-09-17 02:36:37 PDT --- Created an attachment (id=38756) --> (https://bugs.freedesktop.org/attachment.cgi?id=38756) screenshot just before 9021c56a5738815777f27c39b63637b5975270c6 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28294] [r300g] Unigine Sanctuary v2.2: black glitches
https://bugs.freedesktop.org/show_bug.cgi?id=28294 Pavel Ondračka changed: What|Removed |Added CC||benjamin.sego...@intel.com --- Comment #26 from Pavel Ondračka 2010-09-17 02:35:21 PDT --- Here is status with latest mesa (and lowest settings): - shadows are broken, they were quite good before glsl2 merge (at least with shaders quality high), I thought they were broken because of glsl2 merge but I did some quick testing and now it seems they were partially broken before it by commit 9021c56a5738815777f27c39b63637b5975270c6 Author: Benjamin Segovia Date: Fri Aug 13 10:36:47 2010 -0600 mesa: more/better program optimizations This is the patch from Benjamin's Aug 11, 2010 email with minor fixes (such as moving declarations before code) Signed-off-by: Brian Paul And then glsl2 merge did the rest. Note that with shaders quality set to low it didn't ever worked, just with high. - those black glitches are gone (they are now only present when parallax mapping is turned on), they may be related to the shadows, see screenshots - menus are broken hard, its almost imposible to change any settings. Maybe this bug needs some splitting? Any logs needed? I'll attach screenshots. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 28294] [r300g] Unigine Sanctuary v2.2: black glitches
https://bugs.freedesktop.org/show_bug.cgi?id=28294 Pavel Ondra?ka changed: What|Removed |Added CC||benjamin.segovia at intel.com --- Comment #26 from Pavel Ondra?ka 2010-09-17 02:35:21 PDT --- Here is status with latest mesa (and lowest settings): - shadows are broken, they were quite good before glsl2 merge (at least with shaders quality high), I thought they were broken because of glsl2 merge but I did some quick testing and now it seems they were partially broken before it by commit 9021c56a5738815777f27c39b63637b5975270c6 Author: Benjamin Segovia Date: Fri Aug 13 10:36:47 2010 -0600 mesa: more/better program optimizations This is the patch from Benjamin's Aug 11, 2010 email with minor fixes (such as moving declarations before code) Signed-off-by: Brian Paul And then glsl2 merge did the rest. Note that with shaders quality set to low it didn't ever worked, just with high. - those black glitches are gone (they are now only present when parallax mapping is turned on), they may be related to the shadows, see screenshots - menus are broken hard, its almost imposible to change any settings. Maybe this bug needs some splitting? Any logs needed? I'll attach screenshots. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29787] random XRandR failures (i2c related?)
https://bugs.freedesktop.org/show_bug.cgi?id=29787 --- Comment #9 from Arno Schuring 2010-09-17 02:19:58 PDT --- While I still can't reproduce this at will, both the EDID errors and xrandr resets seem related to system load. When the system is idle, or I'm simply browsing or text-editing, the problems don't happen. However, when I'm stressing the system (which is not that hard on this old machine), for example creating a backup or compiling a kernel, I get multiple EDID errors per minute and occasional resets. Since I've been running with the patch, I have only seen position resets on the left monitor. The right monitor has never lost its rotation. I can't reproduce this by pegging the cpu, I need to generate a lot of disk activity. So I think it is related to latency rather than throughput. Also, X seems to hang for 50-500ms every time an EDID message appears in syslog, as I can see the mouse cursor freezing. When the freeze lasts more than a second, it is usually followed by an XRandR reset. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 29787] random XRandR failures (i2c related?)
https://bugs.freedesktop.org/show_bug.cgi?id=29787 --- Comment #9 from Arno Schuring 2010-09-17 02:19:58 PDT --- While I still can't reproduce this at will, both the EDID errors and xrandr resets seem related to system load. When the system is idle, or I'm simply browsing or text-editing, the problems don't happen. However, when I'm stressing the system (which is not that hard on this old machine), for example creating a backup or compiling a kernel, I get multiple EDID errors per minute and occasional resets. Since I've been running with the patch, I have only seen position resets on the left monitor. The right monitor has never lost its rotation. I can't reproduce this by pegging the cpu, I need to generate a lot of disk activity. So I think it is related to latency rather than throughput. Also, X seems to hang for 50-500ms every time an EDID message appears in syslog, as I can see the mouse cursor freezing. When the freeze lasts more than a second, it is usually followed by an XRandR reset. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
