patch idr-fix-a-critical-misallocation-bug.patch added to 2.6.32-stable tree
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): 12651725962428@site
A message that is not in the archive (sent off-list or not yet received): 1265203299.2919.1.camel@localhost
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi
[ Sorry for not reporting this earlier today, while
idr-fix-a-critical-misallocation-bug was still part of queue-2.6.32, but bisecting this (and previously net-restore-ip-source-validation.patch) took its time. ]
Quoted 15 lines · Greg KH
Quoted 14 lines · Eric Paris
Quoted 12 lines · Tejun Heo
Quoted 4 lines
Eric Paris located a bug in idr. With
IDR_BITSof 6, it grows to three layers when id 4096 is first allocated. When that happens, idr wraps incorrectly and searches the idr array ignoring the high bits. The following test code from Eric demonstrates the bug nicely....
Quoted 6 lines
Based-on-patch-from: Eric Paris <[email protected]>
Reported-by Eric Paris <[email protected]>Signed-off-by Tejun Heo <[email protected]>Signed-off-by Andrew Morton <[email protected]>Signed-off-by Linus Torvalds <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Greg, can this wait a bit more, maybe until the next -stable release? The code there is very fragile and this has been broken forever so I think it would be better if we wait a bit more while it gets testing mainline.
Just as a side note, this patch as part of the 2.6.32 stable queue (before this patch was removed again) seems to break logging into KDE 4.3.4 through kdm on several different systems with Intel chipsets/ graphics (kvm active). X and kdm start normally, logging in shows the ksplash, which quickly terminates the xsession and dumps back to kdm. Removing just this patch from 2.6.32 + (previous) stable queue fixes the problem for me; however 2.6.33-rc6-git3 seems to be affected as well, but freezes X, instead of "just" terminating the current X session and reverting to kdm.
While I have reports from several different intel chipsets, I can personally reproduce it on an Intel D945GCLF2 mainboard:
00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02)
00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02) 00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 01) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 01)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 [8086:27d4] (rev 01)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 [8086:27d6] (rev 01)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 01) 00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01)
00:1f.2 IDE interface [0101]: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller [8086:27c0] (rev 01) 00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 01)
01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02)
===
[ the following might of course be unrelated ]
Oops captured with 2.6.33-rc6-git3 (X and kdm start up without problems, but freezes during ksplash - the system remains operationable through ssh):
[drm:i915_gem_do_execbuffer] *ERROR* Invalid object handle 1073741824 at index 23
BUG: unable to handle kernel paging request at ffffffff00000080 IP: [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915] PGD 14c0067 PUD 0 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/virtual/sound/timer/uevent CPU 0 Pid: 1846, comm: Xorg Tainted: G W 2.6.33-rc6-sidux-amd64 #1 D945GCLF2/ RIP: 0010:[<ffffffffa00951af>] [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915] RSP: 0018:ffff88007c49fbf8 EFLAGS: 00010286 RAX: ffff88007e80aac0 RBX: 00000000fffffff7 RCX: 000000000000001e RDX: ffffffff00000000 RSI: ffffffffa0042710 RDI: ffff88007e162a80 RBP: 0000000000000018 R08: 0000000000000001 R09: 0000000000000020 R10: 0000000000000000 R11: 000000000000006e R12: ffff88007e80aa00 R13: ffff88007c49fd18 R14: ffff88007e80aa00 R15: ffff88007c49fd18 FS: 00007f5bf591d790(0000) GS:ffff880001800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff00000080 CR3: 000000007c480000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process Xorg (pid: 1846, threadinfo ffff88007c49e000, task ffff88007c4fd280) Stack: ffff88007bebdb80 0000000000000000 ffff88007bebde18 ffffffff8135139b <0> ffff88007f002dc0 ffff880000000040 fffffff57f35a800 ffff88007e2f7800 <0> 0000000000001000 ffff88007c49fd48 ffff88007e80aa00 ffff88007e2f6000 Call Trace: [<ffffffff8135139b>] ? unix_stream_recvmsg+0x28b/0x620 [<ffffffffa0095fa0>] ? i915_gem_execbuffer+0x0/0x410 [i915] [<ffffffffa00961b0>] ? i915_gem_execbuffer+0x210/0x410 [i915] [<ffffffffa00904d5>] ? i915_gem_sw_finish_ioctl+0x95/0xd0 [i915] [<ffffffffa0040958>] ? drm_ioctl+0x308/0x440 [drm] [<ffffffffa0095fa0>] ? i915_gem_execbuffer+0x0/0x410 [i915] [<ffffffff8111ef2f>] ? do_sync_read+0xbf/0x100 [<ffffffff81071924>] ? bit_waitqueue+0x14/0xc0 [<ffffffff8112eed5>] ? vfs_ioctl+0x35/0xd0 [<ffffffff8112f098>] ? do_vfs_ioctl+0x88/0x570 [<ffffffff810566b3>] ? do_setitimer+0x1c3/0x240 [<ffffffff8112f600>] ? sys_ioctl+0x80/0xa0 [<ffffffff8100a002>] ? system_call_fastpath+0x16/0x1b Code: eb 48 8b 74 24 68 44 8b 4e 08 45 85 c9 74 4a 4c 8b 64 24 50 31 ed 49 89 f5 0f 1f 00 48 63 c5 49 8d 04 c4 48 8b 10 48 85 d2 74 25 <48> 8b 92 80 00 00 00 c7 82 a0 00 00 00 00 00 00 00 48 8b 38 48 RIP [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915] RSP <ffff88007c49fbf8> CR2: ffffffff00000080 ---[ end trace 88853e816bdbf457 ]---
I will test 2.6.33 HEAD with idr-fix-a-critical-misallocation-bug.patch reverted when I get home tonight (UTC+1), I'm likely not able to respond before that either.
Quoted 8 lines
Quoted 2 lines
I'm ok with that as well. inotify should not be able to trip up on this condition any more thanks to other changes to inotify.
Ok, I've now dropped it.
thanks,
greg k-h
Regards
Stefan Lippers-Hollmann
Post scriptum:
Xorg.0.log.gz, kdm.log.gz and xsession errors.gz are taken from 2.6.32.7+queue-2.6.32, including idr-fix-a-critical-misallocation-bug.patch
system: up to date Debian sid/ unstable
ii hal 0.5.14-2 Hardware Abstraction Layer ii libdrm-intel1 2.4.17-1 Userspace interface to intel-specific kernel DRM serv ii libdrm2 2.4.17-1 Userspace interface to kernel DRM services -- runtime ii libhal-storage1 0.5.14-2 Hardware Abstraction Layer - shared library for stora ii libhal1 0.5.14-2 Hardware Abstraction Layer - shared library ii xserver-xorg-core 2:1.7.4-2 Xorg X server - core server ii xserver-xorg-video-intel 2:2.9.1-2 X.Org X server -- Intel i8xx, i9xx display driver
Quoted 37 lines · Stefan Lippers-Hollmann
Hi
[ Sorry for not reporting this earlier today, while
idr-fix-a-critical-misallocation-bug was still part of queue-2.6.32, but bisecting this (and previously net-restore-ip-source-validation.patch) took its time. ]Quoted 15 lines · Greg KH
Quoted 14 lines · Eric Paris
Quoted 12 lines · Tejun Heo
Quoted 4 lines
Eric Paris located a bug in idr. With
IDR_BITSof 6, it grows to three layers when id 4096 is first allocated. When that happens, idr wraps incorrectly and searches the idr array ignoring the high bits. The following test code from Eric demonstrates the bug nicely....
Quoted 6 lines
Based-on-patch-from: Eric Paris <[email protected]>
Reported-by Eric Paris <[email protected]>Signed-off-by Tejun Heo <[email protected]>Signed-off-by Andrew Morton <[email protected]>Signed-off-by Linus Torvalds <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Greg, can this wait a bit more, maybe until the next -stable release? The code there is very fragile and this has been broken forever so I think it would be better if we wait a bit more while it gets testing mainline.
Just as a side note, this patch as part of the 2.6.32 stable queue (before this patch was removed again) seems to break logging into KDE 4.3.4 through kdm on several different systems with Intel chipsets/ graphics (kvm active). X and kdm start normally, logging in shows the ksplash, which quickly terminates the xsession and dumps back to kdm. Removing just this patch from 2.6.32 + (previous) stable queue fixes the problem for me; however 2.6.33-rc6-git3 seems to be affected as well, but freezes X, instead of "just" terminating the current X session and reverting to kdm.
Quoted 2 lines
While I have reports from several different intel chipsets, I can personally reproduce it on an Intel D945GCLF2 mainboard:
Does this patch make any difference?
lib/idr.c +2 -1
@@ -140,7 +140,8 @@ static int sub_alloc(struct idr *idp, int *starting_id, struct idr_layer **pa) id = *starting_id; restart: p = idp->top; - l = p->layer; + l = idp->layers; + pa[l--] =NULL ;while (1 ) {/* * We run around this while until we reach the leaf node...
Signature · 1 line
tejun
Quoted 38 lines · Tejun Heo
Quoted 37 lines · Stefan Lippers-Hollmann
Hi
[ Sorry for not reporting this earlier today, while idr-fix-a-critical-misallocation-bug was still part of queue-2.6.32, but bisecting this (and previously net-restore-ip-source-validation.patch) took its time. ]
Quoted 15 lines · Greg KH
Quoted 14 lines · Eric Paris
Quoted 12 lines · Tejun Heo
Quoted 4 lines
Eric Paris located a bug in idr. With
IDR_BITSof 6, it grows to three layers when id 4096 is first allocated. When that happens, idr wraps incorrectly and searches the idr array ignoring the high bits. The following test code from Eric demonstrates the bug nicely....
Quoted 6 lines
Based-on-patch-from: Eric Paris <[email protected]>
Reported-by Eric Paris <[email protected]>Signed-off-by Tejun Heo <[email protected]>Signed-off-by Andrew Morton <[email protected]>Signed-off-by Linus Torvalds <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Greg, can this wait a bit more, maybe until the next -stable release? The code there is very fragile and this has been broken forever so I think it would be better if we wait a bit more while it gets testing mainline.
Just as a side note, this patch as part of the 2.6.32 stable queue (before this patch was removed again) seems to break logging into KDE 4.3.4 through kdm on several different systems with Intel chipsets/ graphics (kvm active). X and kdm start normally, logging in shows the ksplash, which quickly terminates the xsession and dumps back to kdm. Removing just this patch from 2.6.32 + (previous) stable queue fixes the problem for me; however 2.6.33-rc6-git3 seems to be affected as well, but freezes X, instead of "just" terminating the current X session and reverting to kdm.
Quoted 2 lines
Quoted 2 lines
While I have reports from several different intel chipsets, I can personally reproduce it on an Intel D945GCLF2 mainboard:
My x86_64 box gets following messages when I'm running ltp testcase msgctl10, and my system hangs then.
reverting this patch makes msgctl10 go through.
BUG: spinlock already unlocked on CPU#3, msgctl10/1824 lock: ffff88021b627110, .magic: dead4ead, .owner: msgctl10/1824, .owner_cpu: 3 Pid: 1824, comm: msgctl10 Not tainted 2.6.33-rc6-git #56 Call Trace: [<ffffffff81225889>] spin_bug+0x9c/0xa3 [<ffffffff812258cc>] do_raw_spin_unlock+0x3c/0x8d [<ffffffff814497c3>] _raw_spin_unlock+0x2b/0x2f [<ffffffff811cdf90>] ipc_unlock+0xe/0x15 [<ffffffff811ce9f0>] newque+0x137/0x147 [<ffffffff8144812a>] ? down_write+0x7a/0x81 [<ffffffff811cd689>] ipcget+0x121/0x1a9 [<ffffffff811ce8a5>] sys_msgget+0x55/0x59 [<ffffffff811ce8b9>] ? newque+0x0/0x147 [<ffffffff811ce8a9>] ? msg_security+0x0/0x10 [<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
Quoted 2 lines
Does this patch make any difference?
This solves my spinlock already unlock issue.
Quoted 25 lines
lib/idr.c +0
-0@@ -140,7 +140,8 @@ static int sub_alloc(struct idr *idp, int *starting_id, struct idr_layer **pa) id = *starting_id;restart:
p =idp->top;
- l =p->layer;
+ l =idp->layers;
+ pa[l--] = NULL;
while (1) {
/*
* We run around this while until we reach the leaf node...--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi
Quoted 1 line · Tejun Heo
On 02/04/2010 12:46 PM, Stefan Lippers-Hollmann wrote:
[...]
Quoted 8 lines
Quoted 8 lines · Greg KH
Quoted 7 lines · Eric Paris
Quoted 6 lines · Tejun Heo
Quoted 5 lines
Quoted 5 lines
Eric Paris located a bug in idr. With
IDR_BITSof 6, it grows to three layers when id 4096 is first allocated. When that happens, idr wraps incorrectly and searches the idr array ignoring the high bits. The following test code from Eric demonstrates the bug nicely.
[...]
Quoted 14 lines
Quoted 14 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Greg, can this wait a bit more, maybe until the next -stable release? The code there is very fragile and this has been broken forever so I think it would be better if we wait a bit more while it gets testing mainline.
Just as a side note, this patch as part of the 2.6.32 stable queue (before this patch was removed again) seems to break logging into KDE 4.3.4 through kdm on several different systems with Intel chipsets/ graphics (kvm active). X and kdm start normally, logging in shows the ksplash, which quickly terminates the xsession and dumps back to kdm. Removing just this patch from 2.6.32 + (previous) stable queue fixes the problem for me; however 2.6.33-rc6-git3 seems to be affected as well, but freezes X, instead of "just" terminating the current X session and reverting to kdm.
Quoted 4 lines
Quoted 2 lines
While I have reports from several different intel chipsets, I can personally reproduce it on an Intel D945GCLF2 mainboard:
Does this patch make any difference?
Unfortunately I don't see any change, applied to queue-2.6.32 and on top of idr-fix-a-critical-misallocation-bug.patch, KDE 4.3.4 still terminates and dumps me back to kdm. Applied on top of 2.6.33-rc6-git4 it still continues to freeze X during ksplash and spews the same oops message as before:
[drm:i915_gem_do_execbuffer] *ERROR* Invalid object handle 1073741824 at index 19
BUG: unable to handle kernel paging request at ffffffff00000080 IP: [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915] PGD 14c0067 PUD 0 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/virtual/sound/timer/uevent CPU 2 Pid: 1857, comm: Xorg Tainted: G W 2.6.33-rc6-sidux-amd64 #1 D945GCLF2/ RIP: 0010:[<ffffffffa00951af>] [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915] RSP: 0018:ffff880037659bf8 EFLAGS: 00010286 RAX: ffff88007e3a68c0 RBX: 00000000fffffff7 RCX: 000000000000001e RDX: ffffffff00000000 RSI: ffffffffa0042710 RDI: ffff88007d6d9cc0 RBP: 0000000000000018 R08: 0000000000000001 R09: 0000000000000020 R10: 0000000000000000 R11: 000000000000006e R12: ffff88007e3a6800 R13: ffff880037659d18 R14: ffff88007e3a6800 R15: ffff880037659d18 FS: 00007f5b63f24790(0000) GS:ffff880001900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff00000080 CR3: 000000007e3b6000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process Xorg (pid: 1857, threadinfo ffff880037658000, task ffff8800376a86e0) Stack: ffff88007c6d2ec0 0000000000000000 ffff88007c6d3158 ffffffff813513ab <0> ffff88007f002dc0 ffff880000000040 fffffff57f35a800 ffff88007e025000 <0> 0000000000001000 ffff880037659d48 ffff88007e3a6800 ffff88007e026800 Call Trace: [<ffffffff813513ab>] ? unix_stream_recvmsg+0x28b/0x620 [<ffffffff811e5976>] ? idr_get_new_above_int+0x16/0x90 [<ffffffffa00961b0>] ? i915_gem_execbuffer+0x210/0x410 [i915] [<ffffffffa00904d5>] ? i915_gem_sw_finish_ioctl+0x95/0xd0 [i915] [<ffffffffa0040958>] ? drm_ioctl+0x308/0x440 [drm] [<ffffffffa0095fa0>] ? i915_gem_execbuffer+0x0/0x410 [i915] [<ffffffff8111ef2f>] ? do_sync_read+0xbf/0x100 [<ffffffff81071924>] ? bit_waitqueue+0x14/0xc0 [<ffffffff8112eed5>] ? vfs_ioctl+0x35/0xd0 [<ffffffff8112f098>] ? do_vfs_ioctl+0x88/0x570 [<ffffffff810566b3>] ? do_setitimer+0x1c3/0x240 [<ffffffff8112f600>] ? sys_ioctl+0x80/0xa0 [<ffffffff8100a002>] ? system_call_fastpath+0x16/0x1b Code: eb 48 8b 74 24 68 44 8b 4e 08 45 85 c9 74 4a 4c 8b 64 24 50 31 ed 49 89 f5 0f 1f 00 48 63 c5 49 8d 04 c4 48 8b 10 48 85 d2 74 25 <48> 8b 92 80 00 00 00 c7 82 a0 00 00 00 00 00 00 00 48 8b 38 48 RIP [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915] RSP <ffff880037659bf8> CR2: ffffffff00000080 ---[ end trace 465d589b5d608009 ]---
Reverting 859ddf09743a8cc680af33f7259ccd0fd36bfe9d "idr: fix a critical misallocation bug" however fixes the problem on 2.6.33-rc6-git4 (and queue-2.6.32), KDE 4.3.4 starts up correctly and the oops is gone.
Quoted 5 lines
lib/idr.c +0
-0
lib/idr.c static int sub_alloc(struct idr *idp, int *starting_id, struct idr_layer **pa) · line 147
Quoted 9 lines
lib/idr.c +2
-1@@ -140,7 +140,8 @@ static int sub_alloc(struct idr *idp, int *starting_id, struct idr_layer **pa) id = *starting_id; restart: p = idp->top; - l = p->layer; + l = idp->layers; + pa[l--] =NULL ;while (1 ) {/* * We run around this while until we reach the leaf node...
Regards
Stefan Lippers-Hollmann
Hello,
Can you please test the following patch on top of the current mainline?
Thanks.
lib/idr.c +3 -1
@@ -156,10 +156,12 @@ static int sub_alloc(struct idr *idp, int *starting_id, struct idr_layer **pa) id = (id | ((1 << (IDR_BITS * l)) -1 )) +1 ;/* if already at the top layer, we need to grow */ -if (!(p = pa[l])) { +if (id >=1 << (idp->layers *IDR_BITS )) { *starting_id = id;return IDR_NEED_TO_GROW ; } + p = pa[l]; +BUG_ON (!p);/* If we need to go up one layer, continue the * loop; otherwise, restart from the top.
Signature · 1 line
tejun
Stefan Lippers-Hollmann
Tested-byHi
Quoted 6 lines · Tejun Heo
Hello,
Can you please test the following patch on top of the current mainline?
Thanks.
This works fine for me on 2.6.33-rc7-git5 plus your patch:
KMS enabled:
ii xserver-xorg-video-intel 2:2.9.1-2 X.Org X server -- Intel i8xx, i9xx display driver
- 00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)
KMS enabled:
ii xserver-xorg-video-radeon 1:6.12.4-3 X.Org X server -- ATI Radeon display driver
- 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV630 [Radeon HD 2600 Series] [1002:9589] 01:00.1 Audio device [0403]: ATI Technologies Inc RV630/M76 audio device [Radeon HD 2600 Series] [1002:aa08]
- 05:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60] 05:00.1 Display controller [0380]: ATI Technologies Inc RV370 [Radeon X300SE] [1002:5b70]
- 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [1002:4e50]
- 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV280 [Radeon 9200 PRO] [1002:5960] (rev 01) 01:00.1 Display controller [0380]: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) [1002:5940] (rev 01)
no KMS available (Debian unstable has no matching xserver-xorg-video-nouveau
yet):
ii xserver-xorg-video-nv 1:2.1.15-1 X.Org X server -- NV display driver
- 01:00.0 VGA compatible controller [0300]: nVidia Corporation NV11 [GeForce2 MX/MX 400] [10de:0110] (rev a1)
Thank you a lot
Stefan Lippers-Hollmann
Quoted 18 lines
lib/idr.c +3
-1@@ -156,10 +156,12 @@ static int sub_alloc(struct idr *idp, int *starting_id, struct idr_layer **pa) id = (id | ((1 << (IDR_BITS * l)) -1 )) +1 ;/* if already at the top layer, we need to grow */ -if (!(p = pa[l])) { +if (id >=1 << (idp->layers *IDR_BITS )) { *starting_id = id;return IDR_NEED_TO_GROW ; } + p = pa[l]; +BUG_ON (!p);/* If we need to go up one layer, continue the * loop; otherwise, restart from the top.