Re: 2.6.39-rc1 nouveau regression (bisected)
Hi. On 15/04/11 16:11, Dominik Brodowski wrote: > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" >>> to everyone, but then chose to CC Maciej instead: Would you be so kind and >>> add this to your regression list? Thanks! >>> >>> Since commit 38f1cff >>> >>> From: Dave Airlie >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 >>> Subject: [PATCH] Merge commit >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr >>> >>> This commit changed an internal radeon structure, that meant a new >>> driver >>> in -next had to be fixed up, merge in the commit and fix up the driver. >>> >>> Also fixes a trivial nouveau merge. >>> >>> Conflicts: >>> drivers/gpu/drm/nouveau/nouveau_mem.c >>> >>> booting my atom/NM10/ION2 system crashes hard during boot, right after >>> blanking the screen, and before the initramfs gets loaded. I just >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( 85f2e68 ). >> Can you activate netconsole and check whether kernel spits anything >> interesting? >> You might try to load nouveau module after boot - maybe something will be >> saved >> to /var/log or you could even ssh into the box and check dmesg... > Compiling it as a module seems to work fine. When I do so, no regression is > obvious from what gets reported in "dmesg". However, somehow I now do get > some output: The last message I see is > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 value> > > Then, nothing more. However, it really is quite strange why this error only > appears in the CONFIG_NOUVEAU=y case, not in the =m case... Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is causing me an oops at boot, but my bug has been ignored there so far - perhaps I should have posted it here instead. Regards, Nigel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] nouveau: fix acpi_lid_open undefined
Hi. On 25/05/10 08:47, Dave Airlie wrote: On Mon, 2010-05-24 at 07:17 -0700, Randy Dunlap wrote: On 05/24/10 06:59, Matthew Garrett wrote: On Mon, May 24, 2010 at 06:53:51AM -0700, Randy Dunlap wrote: On 05/24/10 05:56, Matthew Garrett wrote: Won't this result in a behavioural difference? The desirable outcome is It could, yes. that that configuration be impossible, not for that configuration to build but be buggy. so nouveau should depend on (or select, if ACPI is enabled) ACPI_BUTTON? There's an argument that it doesn't need to depend on it, but if button is a module then nouveau has to be. Except the inverse isn't true. Kconfig is hard, let's weep gently. Maybe Dave can weep with us when he is back at work... Yeah I've had problems like this a few times lately with the drm, I'm torn between just adding select all over the place, or assuming someone sane is configuring the kernel. I'm sort of erring on the someone sane is configuring the kernel just because Linus's objects to "default y" things seems to point at that we can't really give pointers to the people who haven't done it before. So I'm quite happy to leave it having different behaviour depending on the configuration and simply ignoring bug reports from incompetents. 'scuse me for butting in, but would you at least consider adding something to the help for the Nouveau and/or ACPI button options? You might have a sane person configuring the kernel, but that doesn't mean a dependency like this would necessarily be obvious to them. Personally, I'd argue for the select. Regards, Nigel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.35 Radeon KMS power management regression?
Hi. On 01/06/10 16:33, Dave Airlie wrote: On Tue, Jun 1, 2010 at 4:23 PM, Nigel Cunningham wrote: Hi all. Just wondering if anyone else has tried to hibernate while using Radeon KMS and a tree with Dave's post 2.6.34 patches? My 32 bit P4 based system (with an RV250 card) is hanging at the atomic copy, with the following backtrace hibernation_snapshot dpm_suspend_start async_synchronize_full async_synchronize_cookie async_synchronize_cookie_domain I've been trying to bisect, but this computer is being painfully slow, so I haven't been making much progress. 2.6.34 with the same config is fine, and my bisection progress so far seems to be pointing at the merge I mentioned above. The only thing I can think off might be the output polling task, or the fix from Jerome for AGP suspend/resume 10b06122afcc78468bd1d009633cb71e528acdc5 is AGP one to test Thanks for the quick reply. I've commented out the radeon_agp_suspend call and will try that shortly. By the way, saw your recent commit message talking about kids programs and lowering of IQs. I sympathise. I have the Wiggles in my head far too much at the moment :) disabling output polling is a messier revert, might be easier to just edit drivers/gpu/drm/drm_crtc_helper.c:drm_kms_helper_poll_init and remove the delayed_slow_work_enqueue call, also forcing repoll to false inside output_poll_execute which should in theory stop the polling from starting or being kicked off later. Will try that next. I'll try and recreate if I get a chance, cc'ing dri-devel also for Alex/Jerome. Ta. Nigel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.35 Radeon KMS power management regression?
Hi again. On 01/06/10 16:33, Dave Airlie wrote: On Tue, Jun 1, 2010 at 4:23 PM, Nigel Cunningham wrote: Hi all. Just wondering if anyone else has tried to hibernate while using Radeon KMS and a tree with Dave's post 2.6.34 patches? My 32 bit P4 based system (with an RV250 card) is hanging at the atomic copy, with the following backtrace hibernation_snapshot dpm_suspend_start async_synchronize_full async_synchronize_cookie async_synchronize_cookie_domain Just tried with the agp_suspend invocation commented out - no difference. But it did lead to me realising I'd forgotten to mention the other part of the issue: the above backtrace is from the thread doing the hibernating. In addition, there's an async work thread with the following backtrace. (I love having kdb in vanilla!) async_thread async_suspend __device_suspend device_for_each_child pm_op pci_pm_freeze pci_legacy_suspend radeon_pci_suspend radeon_suspend_kms radeon_pm_suspend del_timer_sync try_to_del_timer_sync I've been trying to bisect, but this computer is being painfully slow, so I haven't been making much progress. 2.6.34 with the same config is fine, and my bisection progress so far seems to be pointing at the merge I mentioned above. The only thing I can think off might be the output polling task, or the fix from Jerome for AGP suspend/resume 10b06122afcc78468bd1d009633cb71e528acdc5 is AGP one to test disabling output polling is a messier revert, might be easier to just edit drivers/gpu/drm/drm_crtc_helper.c:drm_kms_helper_poll_init and remove the delayed_slow_work_enqueue call, also forcing repoll to false inside output_poll_execute which should in theory stop the polling from starting or being kicked off later. Will try this now. Given the above, I guess it sounds more likely? I'll try and recreate if I get a chance, cc'ing dri-devel also for Alex/Jerome. Nigel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[BUG][PATCH] 2.6.36-rc showstopper (at least for me) in vmwgfx
Running a kernel based on the Rafael's -next tree, under VMware, I get the
following oops while booting:
Entering kdb (current=0xd73e2f70, pid 1024) on processor 0 Oops: (null)
due to oops @ 0xc108bc94
Modules linked in: ext4 jbd2 crc16 mptspi mptscsih mptbase
Pid: 1024, comm: plymouthd Not tainted 2.6.36-rc4+ #60 440BX Desktop
Reference Platform/VMware Virtual Platform
EIP: 0060:[] EFLAGS: 00010246 CPU: 0
EIP is at kfree+0x36/0x88
EAX: c146ccbd EBX: dc46e980 ECX: 4400 EDX: c182cd80
ESI: dfabf800 EDI: dfabf8c0 EBP: dfa7befc ESP: dfa7beec
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
<0>Process plymouthd (pid: 1024, ti=dfa7a000 task=d73e2f70 task.ti=dfa7a000)
<0>Stack:
dfabf800 dc46e980 dfabf800 dfabf8c0 dfa7bf18 c11c4ea0 c11d237c dfabf8c0
<0> dc46e980 c11c4e13 c11d5bd9 dfa7bf28 c113d3d1 dc437468 dc46e780 dfa7bf34
<0> c11c4d9d dc437468 dfa7bf40 c11d5f35 dfabf800 dfa7bf68 c11c1e3e dfabf800
<0>Call Trace:
<0> [] ? drm_master_destroy+0x8d/0xf0
<0> [] ? ttm_object_file_destroy+0x0/0xd
<0> [] ? drm_master_destroy+0x0/0xf0
<0> [] ? vmw_master_drop+0x0/0x76
<0> [] ? kref_put+0x39/0x42
<0> [] ? drm_master_put+0x12/0x1b
[0]more>
Only 'q' or 'Q' are processed at more prompt, input ignored
<0> [] ? vmw_postclose+0x1b/0x25
<0> [] ? drm_release+0x459/0x4cb
<0> [] ? fput+0xcc/0x1b1
<0> [] ? filp_close+0x51/0x5b
<0> [] ? sys_close+0x5a/0x88
<0> [] ? sysenter_do_call+0x12/0x26
<0>Code: 10 76 72 8d 90 00 00 00 40 c1 ea 0c c1 e2 05 03 15 00 1b 7e c1 66 83
3a 00 79 03 8b 52 0c 8b 0a 84 c9 78 14 66 f7 c1 00 c0 75 04 <0f> 0b eb fe 89 d0
e8 0a 3a fe ff eb 3d 8b 75 04 8b 5a 0c 9c 8f
Call Trace:
[] drm_master_destroy+0x8d/0xf0
[] ? ttm_object_file_destroy+0x0/0xd
[] ? drm_master_destroy+0x0/0xf0
[] ? vmw_master_drop+0x0/0x76
[] kref_put+0x39/0x42
[] drm_master_put+0x12/0x1b
[] vmw_postclose+0x1b/0x25
[] drm_release+0x459/0x4cb
[] fput+0xcc/0x1b1
[] filp_close+0x51/0x5b
[] sys_close+0x5a/0x88
[] sysenter_do_call+0x12/0x26
This oops is caused by vmwgfx setting it's dev->devicename to a static char *
instead of kmallocing memory. The kfree that's done in drm_master_destroy then
explodes :)
Signed-off-by: Nigel Cunningham
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 72ec2e2..1ca0ebc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -343,8 +343,16 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
dev->dev_private = dev_priv;
- if (!dev->devname)
- dev->devname = vmw_devname;
+ if (!dev->devname) {
+ dev->devname = kmalloc(strlen(vmw_devname) + 1, GFP_KERNEL);
+ if (!dev->devname) {
+ DRM_ERROR("Unable to allocate memory for device "
+ "name.\n");
+ ret = -ENOMEM;
+ goto out_err4;
+ }
+ strcpy(dev->devname, vmw_devname);
+ }
if (dev_priv->capabilities & SVGA_CAP_IRQMASK) {
ret = drm_irq_install(dev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG][PATCH] 2.6.36-rc showstopper (at least for me) in vmwgfx
Hi. On 05/10/10 12:51, Dave Airlie wrote: On Tue, Oct 5, 2010 at 8:57 AM, Nigel Cunningham wrote: Running a kernel based on the Rafael's -next tree, under VMware, I get the following oops while booting: Should already be fixed in Linus tree by, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f1a28ee238bddfa48c5233543926af65a4445bf6 Ah, great. Thanks! Nigel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 nouveau regression (bisected)
Hi. On 15/04/11 16:11, Dominik Brodowski wrote: > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" >>> to everyone, but then chose to CC Maciej instead: Would you be so kind and >>> add this to your regression list? Thanks! >>> >>> Since commit 38f1cff >>> >>> From: Dave Airlie >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 >>> Subject: [PATCH] Merge commit >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr >>> >>> This commit changed an internal radeon structure, that meant a new >>> driver >>> in -next had to be fixed up, merge in the commit and fix up the driver. >>> >>> Also fixes a trivial nouveau merge. >>> >>> Conflicts: >>> drivers/gpu/drm/nouveau/nouveau_mem.c >>> >>> booting my atom/NM10/ION2 system crashes hard during boot, right after >>> blanking the screen, and before the initramfs gets loaded. I just >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( 85f2e68 ). >> Can you activate netconsole and check whether kernel spits anything >> interesting? >> You might try to load nouveau module after boot - maybe something will be >> saved >> to /var/log or you could even ssh into the box and check dmesg... > Compiling it as a module seems to work fine. When I do so, no regression is > obvious from what gets reported in "dmesg". However, somehow I now do get > some output: The last message I see is > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 value> > > Then, nothing more. However, it really is quite strange why this error only > appears in the CONFIG_NOUVEAU=y case, not in the =m case... Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is causing me an oops at boot, but my bug has been ignored there so far - perhaps I should have posted it here instead. Regards, Nigel
[PATCH -next] nouveau: fix acpi_lid_open undefined
Hi. On 25/05/10 08:47, Dave Airlie wrote: > On Mon, 2010-05-24 at 07:17 -0700, Randy Dunlap wrote: >> On 05/24/10 06:59, Matthew Garrett wrote: >>> On Mon, May 24, 2010 at 06:53:51AM -0700, Randy Dunlap wrote: On 05/24/10 05:56, Matthew Garrett wrote: > Won't this result in a behavioural difference? The desirable outcome is It could, yes. > that that configuration be impossible, not for that configuration to > build but be buggy. so nouveau should depend on (or select, if ACPI is enabled) ACPI_BUTTON? >>> >>> There's an argument that it doesn't need to depend on it, but if button >>> is a module then nouveau has to be. Except the inverse isn't true. >>> Kconfig is hard, let's weep gently. >> >> Maybe Dave can weep with us when he is back at work... > > Yeah I've had problems like this a few times lately with the drm, I'm > torn between just adding select all over the place, or assuming someone > sane is configuring the kernel. > > I'm sort of erring on the someone sane is configuring the kernel just > because Linus's objects to "default y" things seems to point at that we > can't really give pointers to the people who haven't done it before. So > I'm quite happy to leave it having different behaviour depending on the > configuration and simply ignoring bug reports from incompetents. 'scuse me for butting in, but would you at least consider adding something to the help for the Nouveau and/or ACPI button options? You might have a sane person configuring the kernel, but that doesn't mean a dependency like this would necessarily be obvious to them. Personally, I'd argue for the select. Regards, Nigel
2.6.35 Radeon KMS power management regression?
Hi. On 01/06/10 16:33, Dave Airlie wrote: > On Tue, Jun 1, 2010 at 4:23 PM, Nigel Cunningham > wrote: >> Hi all. >> >> Just wondering if anyone else has tried to hibernate while using Radeon KMS >> and a tree with Dave's post 2.6.34 patches? My 32 bit P4 based system (with >> an RV250 card) is hanging at the atomic copy, with the following backtrace >> >> hibernation_snapshot >> dpm_suspend_start >> async_synchronize_full >> async_synchronize_cookie >> async_synchronize_cookie_domain >> >> I've been trying to bisect, but this computer is being painfully slow, so I >> haven't been making much progress. 2.6.34 with the same config is fine, and >> my bisection progress so far seems to be pointing at the merge I mentioned >> above. > > The only thing I can think off might be the output polling task, or > the fix from Jerome for AGP suspend/resume > 10b06122afcc78468bd1d009633cb71e528acdc5 is AGP one to test Thanks for the quick reply. I've commented out the radeon_agp_suspend call and will try that shortly. By the way, saw your recent commit message talking about kids programs and lowering of IQs. I sympathise. I have the Wiggles in my head far too much at the moment :) > disabling output polling is a messier revert, might be easier to just edit > drivers/gpu/drm/drm_crtc_helper.c:drm_kms_helper_poll_init and remove > the delayed_slow_work_enqueue call, also forcing repoll to false > inside output_poll_execute which should in theory stop the polling > from starting or being kicked off later. Will try that next. > I'll try and recreate if I get a chance, cc'ing dri-devel also for > Alex/Jerome. Ta. Nigel
2.6.35 Radeon KMS power management regression?
Hi again. On 01/06/10 16:33, Dave Airlie wrote: > On Tue, Jun 1, 2010 at 4:23 PM, Nigel Cunningham > wrote: >> Hi all. >> >> Just wondering if anyone else has tried to hibernate while using Radeon KMS >> and a tree with Dave's post 2.6.34 patches? My 32 bit P4 based system (with >> an RV250 card) is hanging at the atomic copy, with the following backtrace >> >> hibernation_snapshot >> dpm_suspend_start >> async_synchronize_full >> async_synchronize_cookie >> async_synchronize_cookie_domain Just tried with the agp_suspend invocation commented out - no difference. But it did lead to me realising I'd forgotten to mention the other part of the issue: the above backtrace is from the thread doing the hibernating. In addition, there's an async work thread with the following backtrace. (I love having kdb in vanilla!) async_thread async_suspend __device_suspend device_for_each_child pm_op pci_pm_freeze pci_legacy_suspend radeon_pci_suspend radeon_suspend_kms radeon_pm_suspend del_timer_sync try_to_del_timer_sync >> I've been trying to bisect, but this computer is being painfully slow, so I >> haven't been making much progress. 2.6.34 with the same config is fine, and >> my bisection progress so far seems to be pointing at the merge I mentioned >> above. > > The only thing I can think off might be the output polling task, or > the fix from Jerome for AGP suspend/resume > 10b06122afcc78468bd1d009633cb71e528acdc5 is AGP one to test > > disabling output polling is a messier revert, might be easier to just edit > drivers/gpu/drm/drm_crtc_helper.c:drm_kms_helper_poll_init and remove > the delayed_slow_work_enqueue call, also forcing repoll to false > inside output_poll_execute which should in theory stop the polling > from starting or being kicked off later. Will try this now. Given the above, I guess it sounds more likely? > I'll try and recreate if I get a chance, cc'ing dri-devel also for > Alex/Jerome. Nigel
[BUG][PATCH] 2.6.36-rc showstopper (at least for me) in vmwgfx
Running a kernel based on the Rafael's -next tree, under VMware, I get the
following oops while booting:
Entering kdb (current=0xd73e2f70, pid 1024) on processor 0 Oops: (null)
due to oops @ 0xc108bc94
Modules linked in: ext4 jbd2 crc16 mptspi mptscsih mptbase
Pid: 1024, comm: plymouthd Not tainted 2.6.36-rc4+ #60 440BX Desktop
Reference Platform/VMware Virtual Platform
EIP: 0060:[] EFLAGS: 00010246 CPU: 0
EIP is at kfree+0x36/0x88
EAX: c146ccbd EBX: dc46e980 ECX: 4400 EDX: c182cd80
ESI: dfabf800 EDI: dfabf8c0 EBP: dfa7befc ESP: dfa7beec
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
<0>Process plymouthd (pid: 1024, ti=dfa7a000 task=d73e2f70 task.ti=dfa7a000)
<0>Stack:
dfabf800 dc46e980 dfabf800 dfabf8c0 dfa7bf18 c11c4ea0 c11d237c dfabf8c0
<0> dc46e980 c11c4e13 c11d5bd9 dfa7bf28 c113d3d1 dc437468 dc46e780 dfa7bf34
<0> c11c4d9d dc437468 dfa7bf40 c11d5f35 dfabf800 dfa7bf68 c11c1e3e dfabf800
<0>Call Trace:
<0> [] ? drm_master_destroy+0x8d/0xf0
<0> [] ? ttm_object_file_destroy+0x0/0xd
<0> [] ? drm_master_destroy+0x0/0xf0
<0> [] ? vmw_master_drop+0x0/0x76
<0> [] ? kref_put+0x39/0x42
<0> [] ? drm_master_put+0x12/0x1b
[0]more>
Only 'q' or 'Q' are processed at more prompt, input ignored
<0> [] ? vmw_postclose+0x1b/0x25
<0> [] ? drm_release+0x459/0x4cb
<0> [] ? fput+0xcc/0x1b1
<0> [] ? filp_close+0x51/0x5b
<0> [] ? sys_close+0x5a/0x88
<0> [] ? sysenter_do_call+0x12/0x26
<0>Code: 10 76 72 8d 90 00 00 00 40 c1 ea 0c c1 e2 05 03 15 00 1b 7e c1 66 83
3a 00 79 03 8b 52 0c 8b 0a 84 c9 78 14 66 f7 c1 00 c0 75 04 <0f> 0b eb fe 89 d0
e8 0a 3a fe ff eb 3d 8b 75 04 8b 5a 0c 9c 8f
Call Trace:
[] drm_master_destroy+0x8d/0xf0
[] ? ttm_object_file_destroy+0x0/0xd
[] ? drm_master_destroy+0x0/0xf0
[] ? vmw_master_drop+0x0/0x76
[] kref_put+0x39/0x42
[] drm_master_put+0x12/0x1b
[] vmw_postclose+0x1b/0x25
[] drm_release+0x459/0x4cb
[] fput+0xcc/0x1b1
[] filp_close+0x51/0x5b
[] sys_close+0x5a/0x88
[] sysenter_do_call+0x12/0x26
This oops is caused by vmwgfx setting it's dev->devicename to a static char *
instead of kmallocing memory. The kfree that's done in drm_master_destroy then
explodes :)
Signed-off-by: Nigel Cunningham
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 72ec2e2..1ca0ebc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -343,8 +343,16 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
dev->dev_private = dev_priv;
- if (!dev->devname)
- dev->devname = vmw_devname;
+ if (!dev->devname) {
+ dev->devname = kmalloc(strlen(vmw_devname) + 1, GFP_KERNEL);
+ if (!dev->devname) {
+ DRM_ERROR("Unable to allocate memory for device "
+ "name.\n");
+ ret = -ENOMEM;
+ goto out_err4;
+ }
+ strcpy(dev->devname, vmw_devname);
+ }
if (dev_priv->capabilities & SVGA_CAP_IRQMASK) {
ret = drm_irq_install(dev);
[BUG][PATCH] 2.6.36-rc showstopper (at least for me) in vmwgfx
Hi. On 05/10/10 12:51, Dave Airlie wrote: > On Tue, Oct 5, 2010 at 8:57 AM, Nigel Cunningham > wrote: >> Running a kernel based on the Rafael's -next tree, under VMware, I get the >> following oops while booting: > > Should already be fixed in Linus tree by, > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f1a28ee238bddfa48c5233543926af65a4445bf6 Ah, great. Thanks! Nigel
