Regression in v4.8-rc4: i915 flickering since commit 1c80c25fb6
Hi! Since commit 1c80c25fb6 (determined by git bisect, and confirmed by reverting this patch on top of 9ca581b50d), the sceen on my DELL XPS 13 is flickering every once in a while (sometimes multiple times per second, sometimes only every few seconds). That's for 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0665 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 and Debian Jessie userland. Best, Dominik
Thunderbolt, Apple Monitor & MBA, and excess kworker load
On Wed, Jun 20, 2012 at 06:10:12PM +0200, Daniel Vetter wrote: > On Wed, Jun 20, 2012 at 08:56:26AM -0700, Greg KH wrote: > > On Wed, Jun 20, 2012 at 05:48:42PM +0200, Dominik Brodowski wrote: > > > Hi, > > > > > > At work, I wish to attach a 27" Apple Display using thunderbolt to my Mac > > > Book Air 4,2 13". Using OS X, it works fine, but as I prefer using Linux, > > > I > > > tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of > > > f40759e. > > > Hotplug doesn't work (known issue), but also with coldplug the display > > > reacts _very_ slow, way too slow for real use: The screen updates only > > > every > > > half second or so. Is this a known bug? Might something go afoul with > > > kworker -- they need about 75% of the CPU with the large display attached, > > > and less than 1% _without_ the large display. > > > > It's not really a known bug, but it is known that Thunderbolt doesn't > > work all that well, if at all, in Linux due to the BIOS issues that you > > have run into (the hotplug stuff.) Is there anything where I could help? > > Once the device is seen, it should just work like any other PCI device, > > and so, that might be a DRM driver issue somehow. > > A quick full-system profile would be a good start to tell where we're > burning through all these cycles exaclty. Also, anything special going on > with interrupts (if this excessive load is due to supurious display > hotplug events, drm/i915 should get _tons_ of interrupts). Did a $ perf record -a -g sleep 10 , and that shows: - 11,67% kworker/1:1 [kernel.kallsyms] + native_read_tsc + delay_tsc - 9,56% kworker/3:2 [kernel.kallsyms] + native_read_tsc + delay_tsc and other uninteresting things. $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event $ cat /sys/kernel/debug/tracing/trace_pipe shows these top functions: 305 i915_hotplug_work_func 504 flush_to_ldisc 14759 do_dbs_timer so nothing of interest either. Interrupts: pretty normal. Any ideas on how to debug this further? Thanks & best, Dominik
Re: Thunderbolt, Apple Monitor MBA, and excess kworker load
On Wed, Jun 20, 2012 at 06:10:12PM +0200, Daniel Vetter wrote: On Wed, Jun 20, 2012 at 08:56:26AM -0700, Greg KH wrote: On Wed, Jun 20, 2012 at 05:48:42PM +0200, Dominik Brodowski wrote: Hi, At work, I wish to attach a 27 Apple Display using thunderbolt to my Mac Book Air 4,2 13. Using OS X, it works fine, but as I prefer using Linux, I tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of f40759e. Hotplug doesn't work (known issue), but also with coldplug the display reacts _very_ slow, way too slow for real use: The screen updates only every half second or so. Is this a known bug? Might something go afoul with kworker -- they need about 75% of the CPU with the large display attached, and less than 1% _without_ the large display. It's not really a known bug, but it is known that Thunderbolt doesn't work all that well, if at all, in Linux due to the BIOS issues that you have run into (the hotplug stuff.) Is there anything where I could help? Once the device is seen, it should just work like any other PCI device, and so, that might be a DRM driver issue somehow. A quick full-system profile would be a good start to tell where we're burning through all these cycles exaclty. Also, anything special going on with interrupts (if this excessive load is due to supurious display hotplug events, drm/i915 should get _tons_ of interrupts). Did a $ perf record -a -g sleep 10 , and that shows: - 11,67% kworker/1:1 [kernel.kallsyms] + native_read_tsc + delay_tsc - 9,56% kworker/3:2 [kernel.kallsyms] + native_read_tsc + delay_tsc and other uninteresting things. $ echo workqueue:workqueue_queue_work /sys/kernel/debug/tracing/set_event $ cat /sys/kernel/debug/tracing/trace_pipe shows these top functions: 305 i915_hotplug_work_func 504 flush_to_ldisc 14759 do_dbs_timer so nothing of interest either. Interrupts: pretty normal. Any ideas on how to debug this further? Thanks best, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Thunderbolt, Apple Monitor & MBA, and excess kworker load
Hi, At work, I wish to attach a 27" Apple Display using thunderbolt to my Mac Book Air 4,2 13". Using OS X, it works fine, but as I prefer using Linux, I tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of f40759e. Hotplug doesn't work (known issue), but also with coldplug the display reacts _very_ slow, way too slow for real use: The screen updates only every half second or so. Is this a known bug? Might something go afoul with kworker -- they need about 75% of the CPU with the large display attached, and less than 1% _without_ the large display. Any hints are most welcome, also on where I may dig further to determine the root causes... Thanks & best, Dominik
Thunderbolt, Apple Monitor MBA, and excess kworker load
Hi, At work, I wish to attach a 27 Apple Display using thunderbolt to my Mac Book Air 4,2 13. Using OS X, it works fine, but as I prefer using Linux, I tested out Ubuntu's stock kernel and (among other) 3.5.0-rc3+ as of f40759e. Hotplug doesn't work (known issue), but also with coldplug the display reacts _very_ slow, way too slow for real use: The screen updates only every half second or so. Is this a known bug? Might something go afoul with kworker -- they need about 75% of the CPU with the large display attached, and less than 1% _without_ the large display. Any hints are most welcome, also on where I may dig further to determine the root causes... Thanks best, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 nouveau(?) regression (bisected)
On Tue, Apr 19, 2011 at 11:47:47PM +0200, Marcin Slusarz wrote: > On Mon, Apr 18, 2011 at 01:27:10PM -0700, Linus Torvalds wrote: > > On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz > > wrote: > > > > > > It's some nasty corruption: > > > > Looks like something wrote 0x to free'd memory. > > > > Enabling DEBUG_PAGEALLOC *might* show where it happens. > > > > > > > > [ ? ?6.523867] > > > = > > > [ ? ?6.523916] BUG sysfs_dir_cache: Poison overwritten > > > [ ? ?6.523949] > > > - > > > [ ? ?6.523950] > > > [ ? ?6.524016] INFO: 0x8801bb47df4c-0x8801bb47df4f. First byte > > > 0xff instead of 0x6b > > > [ ? ?6.524061] INFO: Slab 0xea00060f7b58 objects=22 used=21 > > > fp=0x8801bb47df18 flags=0x80c1 > > > [ ? ?6.524110] INFO: Object 0x8801bb47df18 @offset=3864 fp=0x ? ? ? ? > > > ?(null) > > > [ ? ?6.524111] > > > [ ? ?6.524170] Bytes b4 0x8801bb47df08: ?00 00 00 00 00 00 00 00 5a > > > 5a 5a 5a 5a 5a 5a 5a > > > [ ? ?6.524516] ? Object 0x8801bb47df18: ?6b 6b 6b 6b 6b 6b 6b 6b 6b > > > 6b 6b 6b 6b 6b 6b 6b > > > [ ? ?6.524862] ? Object 0x8801bb47df28: ?6b 6b 6b 6b 6b 6b 6b 6b 6b > > > 6b 6b 6b 6b 6b 6b 6b > > > [ ? ?6.525208] ? Object 0x8801bb47df38: ?6b 6b 6b 6b 6b 6b 6b 6b 6b > > > 6b 6b 6b 6b 6b 6b 6b > > > [ ? ?6.525556] ? Object 0x8801bb47df48: ?6b 6b 6b 6b ff ff ff ff 6b > > > 6b 6b 6b 6b 6b 6b 6b > > > > So here the 0x is pretty obvious. > > > > > and in another boot: > > > > > > [ ? ?6.704786] BUG: unable to handle kernel paging request at > > > bc70b058 > > > > Here it is less obvious, but it was _probably_ a regular kernel > > pointer of the type 0x8801bc70b058 before the high bits were > > overwritten by a 0x. > > > > So then sysfs_refresh_inode() follows that pointer, and crashes. > > > > Just a guess, obviously, but it looks rather likely. > > Thanks. It helped a bit. > I'll send two patches in response to this message, one of which fixes this > bug. Thanks Marcin, now my system boots finely again. Consider this bug CLOSED and FIXED. Thanks again, Dominik
Re: 2.6.39-rc1 nouveau(?) regression (bisected)
On Tue, Apr 19, 2011 at 11:47:47PM +0200, Marcin Slusarz wrote: On Mon, Apr 18, 2011 at 01:27:10PM -0700, Linus Torvalds wrote: On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz marcin.slus...@gmail.com wrote: It's some nasty corruption: Looks like something wrote 0x to free'd memory. Enabling DEBUG_PAGEALLOC *might* show where it happens. [ 6.523867] = [ 6.523916] BUG sysfs_dir_cache: Poison overwritten [ 6.523949] - [ 6.523950] [ 6.524016] INFO: 0x8801bb47df4c-0x8801bb47df4f. First byte 0xff instead of 0x6b [ 6.524061] INFO: Slab 0xea00060f7b58 objects=22 used=21 fp=0x8801bb47df18 flags=0x80c1 [ 6.524110] INFO: Object 0x8801bb47df18 @offset=3864 fp=0x (null) [ 6.524111] [ 6.524170] Bytes b4 0x8801bb47df08: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a [ 6.524516] Object 0x8801bb47df18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 6.524862] Object 0x8801bb47df28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 6.525208] Object 0x8801bb47df38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 6.525556] Object 0x8801bb47df48: 6b 6b 6b 6b ff ff ff ff 6b 6b 6b 6b 6b 6b 6b 6b So here the 0x is pretty obvious. and in another boot: [ 6.704786] BUG: unable to handle kernel paging request at bc70b058 Here it is less obvious, but it was _probably_ a regular kernel pointer of the type 0x8801bc70b058 before the high bits were overwritten by a 0x. So then sysfs_refresh_inode() follows that pointer, and crashes. Just a guess, obviously, but it looks rather likely. Thanks. It helped a bit. I'll send two patches in response to this message, one of which fixes this bug. Thanks Marcin, now my system boots finely again. Consider this bug CLOSED and FIXED. Thanks again, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 nouveau regression (bisected)
Hey, On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > 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 > pointer 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. indeed, setting CONFIG_LOGO=n makes it boot. Same as compiling nouveau as a module. With all the different bisect results and reverts which make it work, it seems to me to be a timing / interference issue... Best, Dominik
Re: 2.6.39-rc1 nouveau regression (bisected)
Hey, On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: 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 airl...@redhat.com 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 some pointer 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. indeed, setting CONFIG_LOGO=n makes it boot. Same as compiling nouveau as a module. With all the different bisect results and reverts which make it work, it seems to me to be a timing / interference issue... Best, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 nouveau regression (bisected)
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 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... Best, Dominik
Re: 2.6.39-rc1 nouveau regression (bisected)
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 airl...@redhat.com 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 some pointer 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... Best, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 nouveau regression (bisected)
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 ). My previous reports (Apr 03, Apr 07) seem to have gotten lost (or ignored, or both). Best, Dominik
2.6.39-rc1 nouveau regression (bisected)
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 airl...@redhat.com 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 ). My previous reports (Apr 03, Apr 07) seem to have gotten lost (or ignored, or both). Best, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 noveau trouble and regression (bad commit: 38f1cff0863809587b5fd10ecd0c24c8b543a48c )
Hey, still no joy with 2.6.39-rc2. Best, Dominik On Sun, Apr 03, 2011 at 08:12:06PM +0200, Dominik Brodowski wrote: > Hey, > > After bisecting for a day, I'm pretty confident that the commit > 38f1cff0863809587b5fd10ecd0c24c8b543a48c introduced an error which > causes one of my computers to hang during boot -- only a blank > screen appears. The initramfs never gets run. > > The system consists of an Atom D525 with Intel NM10 + NVIDIA GT218/ION2 > chipset. > > Best, > Dominik
Re: 2.6.39-rc1 noveau trouble and regression (bad commit: 38f1cff0863809587b5fd10ecd0c24c8b543a48c )
Hey, still no joy with 2.6.39-rc2. Best, Dominik On Sun, Apr 03, 2011 at 08:12:06PM +0200, Dominik Brodowski wrote: Hey, After bisecting for a day, I'm pretty confident that the commit 38f1cff0863809587b5fd10ecd0c24c8b543a48c introduced an error which causes one of my computers to hang during boot -- only a blank screen appears. The initramfs never gets run. The system consists of an Atom D525 with Intel NM10 + NVIDIA GT218/ION2 chipset. Best, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 noveau trouble and regression (bad commit: 38f1cff0863809587b5fd10ecd0c24c8b543a48c )
Hey, After bisecting for a day, I'm pretty confident that the commit 38f1cff0863809587b5fd10ecd0c24c8b543a48c introduced an error which causes one of my computers to hang during boot -- only a blank screen appears. The initramfs never gets run. The system consists of an Atom D525 with Intel NM10 + NVIDIA GT218/ION2 chipset. Best, Dominik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 noveau trouble and regression (bad commit: 38f1cff0863809587b5fd10ecd0c24c8b543a48c )
Hey, After bisecting for a day, I'm pretty confident that the commit 38f1cff0863809587b5fd10ecd0c24c8b543a48c introduced an error which causes one of my computers to hang during boot -- only a blank screen appears. The initramfs never gets run. The system consists of an Atom D525 with Intel NM10 + NVIDIA GT218/ION2 chipset. Best, Dominik
