Expanding the use of DMA buffers in 3.3

[Pekka Enberg]

On Wed, Jan 18, 2012 at 2:08 AM, Robert Morell  wrote:
> The DMA buffer infrastructure (dma-buf) currently exposes its interface
> with EXPORT_SYMBOL_GPL. ?The documentation for EXPORT_SYMBOL_GPL says:
> ? ?"It implies that the function is considered an internal
> ? ?implementation issue, and not really an interface."
> This interface is clearly not just an "implementation issue" but an
> interface to be used across drivers/subsystems, so I think it makes
> sense for it to use EXPORT_SYMBOL instead.
>
> Work on dma-buf was originally started with the goal of unifying several
> competing "memory management" systems developed with different ARM SoCs
> in mind. ?It would be unfortunate if restricting its use to only
> GPL-licensed modules caused dma-buf adoption to be limited.
>
> For convenience, I'll send the trivial patch to implement this change.
> I'd like to see this in the first release with dma-buf in 3.3.

How about you open up your driver code instead? You'd get access to
all EXPORT_SYMBOL_GPL symbols instantly!

Pekka

Re: Expanding the use of DMA buffers in 3.3

[Pekka Enberg]

On Wed, Jan 18, 2012 at 2:08 AM, Robert Morell  wrote:
> The DMA buffer infrastructure (dma-buf) currently exposes its interface
> with EXPORT_SYMBOL_GPL.  The documentation for EXPORT_SYMBOL_GPL says:
>    "It implies that the function is considered an internal
>    implementation issue, and not really an interface."
> This interface is clearly not just an "implementation issue" but an
> interface to be used across drivers/subsystems, so I think it makes
> sense for it to use EXPORT_SYMBOL instead.
>
> Work on dma-buf was originally started with the goal of unifying several
> competing "memory management" systems developed with different ARM SoCs
> in mind.  It would be unfortunate if restricting its use to only
> GPL-licensed modules caused dma-buf adoption to be limited.
>
> For convenience, I'll send the trivial patch to implement this change.
> I'd like to see this in the first release with dma-buf in 3.3.

How about you open up your driver code instead? You'd get access to
all EXPORT_SYMBOL_GPL symbols instantly!

Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Pekka Enberg]

On Mon, Dec 5, 2011 at 9:27 PM, Markus Trippelsdorf
 wrote:
>> > Yes the patch finally fixes the issue for me (tested with 120 kexec
>> > iterations).
>> > Thanks Jerome!
>>
>> Can you do a kick run on the modified patch ?
>
> This one is also OK after ~60 iterations.

Jerome, could you please include a reference to this LKML thread for
context and attribution for Markus for reporting and following up to
get the issue fixed in the changelog?

  Pekka

Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Pekka Enberg]

On Mon, Dec 5, 2011 at 9:27 PM, Markus Trippelsdorf
 wrote:
>> > Yes the patch finally fixes the issue for me (tested with 120 kexec
>> > iterations).
>> > Thanks Jerome!
>>
>> Can you do a kick run on the modified patch ?
>
> This one is also OK after ~60 iterations.

Jerome, could you please include a reference to this LKML thread for
context and attribution for Markus for reporting and following up to
get the issue fixed in the changelog?

  Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Pekka Enberg]

On Thu, 1 Dec 2011, Markus Trippelsdorf wrote:
> On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
>> On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
>>> On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
>>>
> FIX idr_layer_cache: Marking all objects used

 Yesterday I couldn't reproduce the issue at all. But today I've hit
 exactly the same spot again. (CCing the drm list)
>>>
>>> Well this is looks like write after free.
>>>
 =
 BUG idr_layer_cache: Poison overwritten
 -
 Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
>>>
>>> And its an integer sized write of 0. If you look at the struct definition
>>> and lookup the offset you should be able to locate the field that
>>> was modified.
>
> It also happens with CONFIG_SLAB.
> (If someone wants to reproduce the issue, just run a kexec boot loop and
> the bug will occur after a few (~10) iterations.)
>
> Dec  1 05:04:52 x4 kernel: [drm] Initialized drm 1.1.0 20060810
> Dec  1 05:04:52 x4 kernel: [drm] radeon defaulting to kernel modesetting.
> Dec  1 05:04:52 x4 kernel: [drm] radeon kernel modesetting enabled.
> Dec  1 05:04:52 x4 kernel: radeon :01:05.0: PCI INT A -> GSI 18 (level, 
> low) -> IRQ 18
> Dec  1 05:04:52 x4 kernel: radeon :01:05.0: setting latency timer to 64
> Dec  1 05:04:52 x4 kernel: [drm] initializing kernel modesetting (RS780 
> 0x1002:0x9614 0x1043:0x834D).
> Dec  1 05:04:52 x4 kernel: [drm] register mmio base: 0xFBEE
> Dec  1 05:04:52 x4 kernel: [drm] register mmio size: 65536
> Dec  1 05:04:52 x4 kernel: ATOM BIOS: 113
> Dec  1 05:04:52 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 
> - 0xC7FF (128M used)
> Dec  1 05:04:52 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 
> - 0xBFFF
> Dec  1 05:04:52 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
> Dec  1 05:04:52 x4 kernel: [drm] RAM width 32bits DDR
> Dec  1 05:04:52 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
> 4090750 kiB.
> Dec  1 05:04:52 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
> 2097152 kiB.
> Dec  1 05:04:52 x4 kernel: [TTM] Initializing pool allocator.
> Dec  1 05:04:52 x4 kernel: [drm] radeon: 128M of VRAM memory ready
> Dec  1 05:04:52 x4 kernel: [drm] radeon: 512M of GTT memory ready.
> Dec  1 05:04:52 x4 kernel: [drm] Supports vblank timestamp caching Rev 1 
> (10.10.2010).
> Dec  1 05:04:52 x4 kernel: [drm] Driver supports precise vblank timestamp 
> query.
> Dec  1 05:04:52 x4 kernel: [drm] radeon: irq initialized.
> Dec  1 05:04:52 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 
> 131072
> Dec  1 05:04:52 x4 kernel: [drm] Loading RS780 Microcode
> Dec  1 05:04:52 x4 kernel: [drm] PCIE GART of 512M enabled (table at 
> 0xC004).
> Dec  1 05:04:52 x4 kernel: radeon :01:05.0: WB enabled
> Dec  1 05:04:52 x4 kernel: Slab corruption: size-1024 start=880216cbc730, 
> len=1024
> Dec  1 05:04:52 x4 kernel: Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
> Dec  1 05:04:52 x4 kernel: Last user: [<  (null)>](0x0)
> Dec  1 05:04:52 x4 kernel: 0d0: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> 6b  
> Dec  1 05:04:52 x4 kernel: Prev obj: start=880216cbc318, len=1024
> Dec  1 05:04:52 x4 kernel: Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
> Dec  1 05:04:52 x4 kernel: Last user: [<  (null)>](0x0)
> Dec  1 05:04:52 x4 kernel: 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> 6b  
> Dec  1 05:04:52 x4 kernel: 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> 6b  
> Dec  1 05:04:52 x4 kernel: Next obj: start=880216cbcb48, len=1024
> Dec  1 05:04:52 x4 kernel: Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
> Dec  1 05:04:52 x4 kernel: Last user: 
> [](radeon_bo_create+0xb4/0x240)
> Dec  1 05:04:52 x4 kernel: 000: 48 cb cb 16 02 88 ff ff 48 cb cb 16 02 88 ff 
> ff  H...H...
> Dec  1 05:04:52 x4 kernel: 010: 02 00 27 00 00 00 00 00 00 00 00 00 00 00 00 
> 00  ..'.
> Dec  1 05:04:52 x4 kernel: [drm] ring test succeeded in 0 usecs
> Dec  1 05:04:52 x4 kernel: [drm] radeon: ib pool ready.
> Dec  1 05:04:52 x4 kernel: [drm] ib test succeeded in 0 usecs
> Dec  1 05:04:52 x4 kernel: [drm] Radeon Display Connectors
> Dec  1 05:0

Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Pekka Enberg]

On Thu, 1 Dec 2011, Markus Trippelsdorf wrote:

On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:

On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:

On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:


FIX idr_layer_cache: Marking all objects used


Yesterday I couldn't reproduce the issue at all. But today I've hit
exactly the same spot again. (CCing the drm list)


Well this is looks like write after free.


=
BUG idr_layer_cache: Poison overwritten
-
Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  



And its an integer sized write of 0. If you look at the struct definition
and lookup the offset you should be able to locate the field that
was modified.


It also happens with CONFIG_SLAB.
(If someone wants to reproduce the issue, just run a kexec boot loop and
the bug will occur after a few (~10) iterations.)

Dec  1 05:04:52 x4 kernel: [drm] Initialized drm 1.1.0 20060810
Dec  1 05:04:52 x4 kernel: [drm] radeon defaulting to kernel modesetting.
Dec  1 05:04:52 x4 kernel: [drm] radeon kernel modesetting enabled.
Dec  1 05:04:52 x4 kernel: radeon :01:05.0: PCI INT A -> GSI 18 (level, low) 
-> IRQ 18
Dec  1 05:04:52 x4 kernel: radeon :01:05.0: setting latency timer to 64
Dec  1 05:04:52 x4 kernel: [drm] initializing kernel modesetting (RS780 
0x1002:0x9614 0x1043:0x834D).
Dec  1 05:04:52 x4 kernel: [drm] register mmio base: 0xFBEE
Dec  1 05:04:52 x4 kernel: [drm] register mmio size: 65536
Dec  1 05:04:52 x4 kernel: ATOM BIOS: 113
Dec  1 05:04:52 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 - 
0xC7FF (128M used)
Dec  1 05:04:52 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
Dec  1 05:04:52 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
Dec  1 05:04:52 x4 kernel: [drm] RAM width 32bits DDR
Dec  1 05:04:52 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
4090750 kiB.
Dec  1 05:04:52 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
2097152 kiB.
Dec  1 05:04:52 x4 kernel: [TTM] Initializing pool allocator.
Dec  1 05:04:52 x4 kernel: [drm] radeon: 128M of VRAM memory ready
Dec  1 05:04:52 x4 kernel: [drm] radeon: 512M of GTT memory ready.
Dec  1 05:04:52 x4 kernel: [drm] Supports vblank timestamp caching Rev 1 
(10.10.2010).
Dec  1 05:04:52 x4 kernel: [drm] Driver supports precise vblank timestamp query.
Dec  1 05:04:52 x4 kernel: [drm] radeon: irq initialized.
Dec  1 05:04:52 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 
131072
Dec  1 05:04:52 x4 kernel: [drm] Loading RS780 Microcode
Dec  1 05:04:52 x4 kernel: [drm] PCIE GART of 512M enabled (table at 
0xC004).
Dec  1 05:04:52 x4 kernel: radeon :01:05.0: WB enabled
Dec  1 05:04:52 x4 kernel: Slab corruption: size-1024 start=880216cbc730, 
len=1024
Dec  1 05:04:52 x4 kernel: Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Dec  1 05:04:52 x4 kernel: Last user: [<  (null)>](0x0)
Dec  1 05:04:52 x4 kernel: 0d0: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
 
Dec  1 05:04:52 x4 kernel: Prev obj: start=880216cbc318, len=1024
Dec  1 05:04:52 x4 kernel: Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Dec  1 05:04:52 x4 kernel: Last user: [<  (null)>](0x0)
Dec  1 05:04:52 x4 kernel: 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
 
Dec  1 05:04:52 x4 kernel: 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
 
Dec  1 05:04:52 x4 kernel: Next obj: start=880216cbcb48, len=1024
Dec  1 05:04:52 x4 kernel: Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Dec  1 05:04:52 x4 kernel: Last user: 
[](radeon_bo_create+0xb4/0x240)
Dec  1 05:04:52 x4 kernel: 000: 48 cb cb 16 02 88 ff ff 48 cb cb 16 02 88 ff ff 
 H...H...
Dec  1 05:04:52 x4 kernel: 010: 02 00 27 00 00 00 00 00 00 00 00 00 00 00 00 00 
 ..'.
Dec  1 05:04:52 x4 kernel: [drm] ring test succeeded in 0 usecs
Dec  1 05:04:52 x4 kernel: [drm] radeon: ib pool ready.
Dec  1 05:04:52 x4 kernel: [drm] ib test succeeded in 0 usecs
Dec  1 05:04:52 x4 kernel: [drm] Radeon Display Connectors
Dec  1 05:04:52 x4 kernel: [drm] Connector 0:
Dec  1 05:04:52 x4 kernel: [drm]   VGA
Dec  1 05:04:52 x4 kernel: [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 
0x7e48 0x7e4c 0x7e4c
Dec  1 05:04:52 x4 kernel: [drm]   Encoders:
Dec  1 05:04:52 x4 kernel: [drm] 

[git pull drm fixes

[Pekka Enberg]

On Fri, Aug 5, 2011 at 1:04 PM, Dave Airlie  wrote:
> Okay I hadn't seen Francesco's report of still failing, I've pushed a
> revert on top of that pull,

Thanks Dave.

[git pull drm fixes

[Pekka Enberg]

On Fri, Aug 5, 2011 at 12:48 PM, Dave Airlie  wrote:
>> Isn't "drm/i915: Try enabling RC6 by default (again)" still broken for
>> some people? Keith, Francesco? If Linus pulls now, we end up with
>> broken i915 in -rc1 once again, no?
>
> I think we are trying again with RC6, if it doesn't work this time,
> it'll get reverted before release. Its really a useful feature and the
> more testing of it the Intel guys can get the quicker they seem to be
> able to make it more likely to be the default.

Please don't do that! The RC6 patch is known to be broken for at least
one configuration:

https://patchwork.kernel.org/patch/1033782/

See the last email from Francesco. I don't know why you insist pushing
patches that are known to be fragile in the past without getting broad
Tested-by tags from people who have been affected in the past.

   Pekka

[git pull drm fixes

[Pekka Enberg]

Hi Dave,

On Fri, Aug 5, 2011 at 12:22 PM, Dave Airlie  wrote:
> Intel modesetting fixes a lot of them, Keith, Jesse and ajax have been
> focusing on a lot of the corner cases and display port and hdmi stuff.
>
> misc radeon fixes, the main one being for certain machines where EDID
> returns what looks like misc noise when connectors aren't populated on
> certain boards.
>
> and some misc trivial type fixes.

Isn't "drm/i915: Try enabling RC6 by default (again)" still broken for
some people? Keith, Francesco? If Linus pulls now, we end up with
broken i915 in -rc1 once again, no?

 Pekka

Re: [git pull drm fixes

[Pekka Enberg]

On Fri, Aug 5, 2011 at 1:04 PM, Dave Airlie  wrote:
> Okay I hadn't seen Francesco's report of still failing, I've pushed a
> revert on top of that pull,

Thanks Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull drm fixes

[Pekka Enberg]

On Fri, Aug 5, 2011 at 12:48 PM, Dave Airlie  wrote:
>> Isn't "drm/i915: Try enabling RC6 by default (again)" still broken for
>> some people? Keith, Francesco? If Linus pulls now, we end up with
>> broken i915 in -rc1 once again, no?
>
> I think we are trying again with RC6, if it doesn't work this time,
> it'll get reverted before release. Its really a useful feature and the
> more testing of it the Intel guys can get the quicker they seem to be
> able to make it more likely to be the default.

Please don't do that! The RC6 patch is known to be broken for at least
one configuration:

https://patchwork.kernel.org/patch/1033782/

See the last email from Francesco. I don't know why you insist pushing
patches that are known to be fragile in the past without getting broad
Tested-by tags from people who have been affected in the past.

   Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull drm fixes

[Pekka Enberg]

Hi Dave,

On Fri, Aug 5, 2011 at 12:22 PM, Dave Airlie  wrote:
> Intel modesetting fixes a lot of them, Keith, Jesse and ajax have been
> focusing on a lot of the corner cases and display port and hdmi stuff.
>
> misc radeon fixes, the main one being for certain machines where EDID
> returns what looks like misc noise when connectors aren't populated on
> certain boards.
>
> and some misc trivial type fixes.

Isn't "drm/i915: Try enabling RC6 by default (again)" still broken for
some people? Keith, Francesco? If Linus pulls now, we end up with
broken i915 in -rc1 once again, no?

 Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Pekka Enberg]

Hi Keith,

On Fri, 22 Jul 2011, Keith Packard wrote:
>> Sorry, to me it all looked like "UMS is being ignored forever".
>
> You're right, of course -- UMS is a huge wart on the kernel driver at
> this point, keeping it working while also adding new functionality
> continues to cause challenges. We tend to expect that most people will
> run reasonably contemporaneous kernel and user space code, and so three
> years after the switch, it continues to surprise us when someone
> actually tries UMS.

I know I sound like a broken record but I really wish you i915 devs were 
little more eager to revert broken patches early rather than late. I mean, 
this particular breakage was already bisected but nobody said or 
did anything - and it's not like it's the first time either!

I suppose I need to bribe Linus somehow to be more strict with you folks.

Pekka

Re: Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

[Pekka Enberg]

Hi Keith,

On Fri, 22 Jul 2011, Keith Packard wrote:

Sorry, to me it all looked like "UMS is being ignored forever".


You're right, of course -- UMS is a huge wart on the kernel driver at
this point, keeping it working while also adding new functionality
continues to cause challenges. We tend to expect that most people will
run reasonably contemporaneous kernel and user space code, and so three
years after the switch, it continues to surprise us when someone
actually tries UMS.


I know I sound like a broken record but I really wish you i915 devs were 
little more eager to revert broken patches early rather than late. I mean, 
this particular breakage was already bisected but nobody said or 
did anything - and it's not like it's the first time either!


I suppose I need to bribe Linus somehow to be more strict with you folks.

Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Reverting rc6 by default

[Pekka Enberg]

On Tue, 12 Jul 2011 10:33:06 +0300, Pekka Enberg  wrote:
>> AFAICT, this problem is still there in 3.0-rc7. Keith, isn't it time
>> to revert commit a51f7a6 ("drm/i915: enable rc6 by default") before
>> 3.0 is out?

On Tue, Jul 12, 2011 at 6:42 PM, Keith Packard  wrote:
> Yes. I'll put together a few tiny patches including this.

This if fixed in mainline as of commit
a94919eaddaa3fede1df8563ce4d761a75374645 ("Revert "drm/i915: enable
rc6 by default"). Keith, it would have been nice to include a
'Reported-by' and/or a link to this discussion in the changelog for
future reference.

Pekka

Re: Reverting rc6 by default

[Pekka Enberg]

On Tue, 12 Jul 2011 10:33:06 +0300, Pekka Enberg  wrote:
>> AFAICT, this problem is still there in 3.0-rc7. Keith, isn't it time
>> to revert commit a51f7a6 ("drm/i915: enable rc6 by default") before
>> 3.0 is out?

On Tue, Jul 12, 2011 at 6:42 PM, Keith Packard  wrote:
> Yes. I'll put together a few tiny patches including this.

This if fixed in mainline as of commit
a94919eaddaa3fede1df8563ce4d761a75374645 ("Revert "drm/i915: enable
rc6 by default"). Keith, it would have been nice to include a
'Reported-by' and/or a link to this discussion in the changelog for
future reference.

Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] Major 2.6.38 / 2.6.39 regression ignored?

[Pekka Enberg]

On Tue, Jul 12, 2011 at 8:17 PM, Kirill Smelkov  wrote:
> On Sat, May 28, 2011 at 05:19:20PM +0400, Kirill Smelkov wrote:
>> Hello Chris, everyone,
>>
>> On Sat, May 21, 2011 at 04:40:17PM +0100, Chris Wilson wrote:
>> > On Sat, 21 May 2011 11:23:53 -0400, "Luke-Jr"  wrote:
>> > > On Saturday, May 21, 2011 4:41:45 AM Chris Wilson wrote:
>> > > > On Fri, 20 May 2011 11:08:56 -0700, Ray Lee  
>> > > > wrote:
>> > > > > [ Adding Chris Wilson (author of the problematic patch) and Rafael
>> > > > > Wysocki to the message ]
>> > > > >
>> > > > > On Fri, May 20, 2011 at 10:06 AM, Luke-Jr  wrote:
>> > > > > > I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a 
>> > > > > > month
>> > > > > > ago against 2.6.38. Now 2.6.39 was just released without the
>> > > > > > regression being addressed. This bug makes the system unusable... 
>> > > > > > Some
>> > > > > > guys on IRC suggested I
>> > > > > > email, so here it is.
>> > > > >
>> > > > > See the bugzilla entry for the bisection history.
>> > > >
>> > > > Which has nothing to do with Luke's bug. Considering the thousand 
>> > > > things
>> > > > that can go wrong during X starting, without a hint as to which it is 
>> > > > nigh
>> > > > on impossible to debug except by trial and error. If you set up
>> > > > netconsole, does the kernel emit an OOPS with it's last dying breath?
>> > >
>> > > Why assume it's a different bug? I would almost wonder if it might affect
>> > > all Sandy Bridge GPUs. In any case, I no longer have the original
>> > > motherboard (it was recalled, as I said in the first post), nor even the
>> > > revision of it (it had other issues that weren't being fixed). I 
>> > > *assume* I
>> > > will have the same problem with my new motherboard (Intel DQ67SW), but I
>> > > haven't verified that yet. I'll be sure to try a netconsole when I have 
>> > > to
>> > > reboot next and get a chance to try the most recent 2.6.38 and .39 
>> > > kernels,
>> > > but at the moment it seems reasonable to address the problem bisected in 
>> > > the
>> > > bug, even if it turns out to be different.
>> >
>> > The bisection is into an old DRI1 bug on 945GM. That DRI has inadequate
>> > locking between release and IRQ and so is prone to such races as befell
>> > Kirill should not surprise anyone. As neither UMS nor DRI supported SNB,
>> > I can quite confidently state they are separate bugs.
>> > -Chris
>>
>> I see DRI1 is maybe buggy and old, but still, pre-kms X used to work ok
>> on kernels < 2.6.38, and starting from 2.6.38 the system is just
>> unusable because X either crashes the kernel (2.6.38), or does not start
>> at all (2.6.39):
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=36052
>>
>>
>> It's a regression. It's blocking me to upgrade to newer kernels. I've
>> done my homework -- digged it and came with detailed OOPS on netconsole
>> and bisected to single commit. Could this please be fixed?
>
> Silence...
>
> Still, reverting the bisected patch helps even for 3.0:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=36052#c4

Keith, Chris, what's up with this regression from 2.6.38? It seems
commit e8616b6 ("drm/i915: Initialise ring vfuncs for old DRI paths")
caused problems on other machines.

Re: [Intel-gfx] Major 2.6.38 / 2.6.39 regression ignored?

[Pekka Enberg]

On Tue, Jul 12, 2011 at 8:17 PM, Kirill Smelkov  wrote:
> On Sat, May 28, 2011 at 05:19:20PM +0400, Kirill Smelkov wrote:
>> Hello Chris, everyone,
>>
>> On Sat, May 21, 2011 at 04:40:17PM +0100, Chris Wilson wrote:
>> > On Sat, 21 May 2011 11:23:53 -0400, "Luke-Jr"  wrote:
>> > > On Saturday, May 21, 2011 4:41:45 AM Chris Wilson wrote:
>> > > > On Fri, 20 May 2011 11:08:56 -0700, Ray Lee  
>> > > > wrote:
>> > > > > [ Adding Chris Wilson (author of the problematic patch) and Rafael
>> > > > > Wysocki to the message ]
>> > > > >
>> > > > > On Fri, May 20, 2011 at 10:06 AM, Luke-Jr  wrote:
>> > > > > > I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a 
>> > > > > > month
>> > > > > > ago against 2.6.38. Now 2.6.39 was just released without the
>> > > > > > regression being addressed. This bug makes the system unusable... 
>> > > > > > Some
>> > > > > > guys on IRC suggested I
>> > > > > > email, so here it is.
>> > > > >
>> > > > > See the bugzilla entry for the bisection history.
>> > > >
>> > > > Which has nothing to do with Luke's bug. Considering the thousand 
>> > > > things
>> > > > that can go wrong during X starting, without a hint as to which it is 
>> > > > nigh
>> > > > on impossible to debug except by trial and error. If you set up
>> > > > netconsole, does the kernel emit an OOPS with it's last dying breath?
>> > >
>> > > Why assume it's a different bug? I would almost wonder if it might affect
>> > > all Sandy Bridge GPUs. In any case, I no longer have the original
>> > > motherboard (it was recalled, as I said in the first post), nor even the
>> > > revision of it (it had other issues that weren't being fixed). I 
>> > > *assume* I
>> > > will have the same problem with my new motherboard (Intel DQ67SW), but I
>> > > haven't verified that yet. I'll be sure to try a netconsole when I have 
>> > > to
>> > > reboot next and get a chance to try the most recent 2.6.38 and .39 
>> > > kernels,
>> > > but at the moment it seems reasonable to address the problem bisected in 
>> > > the
>> > > bug, even if it turns out to be different.
>> >
>> > The bisection is into an old DRI1 bug on 945GM. That DRI has inadequate
>> > locking between release and IRQ and so is prone to such races as befell
>> > Kirill should not surprise anyone. As neither UMS nor DRI supported SNB,
>> > I can quite confidently state they are separate bugs.
>> > -Chris
>>
>> I see DRI1 is maybe buggy and old, but still, pre-kms X used to work ok
>> on kernels < 2.6.38, and starting from 2.6.38 the system is just
>> unusable because X either crashes the kernel (2.6.38), or does not start
>> at all (2.6.39):
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=36052
>>
>>
>> It's a regression. It's blocking me to upgrade to newer kernels. I've
>> done my homework -- digged it and came with detailed OOPS on netconsole
>> and bisected to single commit. Could this please be fixed?
>
> Silence...
>
> Still, reverting the bisected patch helps even for 3.0:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=36052#c4

Keith, Chris, what's up with this regression from 2.6.38? It seems
commit e8616b6 ("drm/i915: Initialise ring vfuncs for old DRI paths")
caused problems on other machines.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Reverting rc6 by default

[Pekka Enberg]

On Wed, Jul 6, 2011 at 2:01 AM, Francesco Allertsen
 wrote:
> On Tue, Jun 21, 2011 at 12:01:34PM -0700, Keith Packard wrote:
>> Thanks. I'll see if I can't get an X201s upgraded to this version and
>> see if we can reproduce the problem you're having...
>
> Any news?
>
> I have found the time today for more debugging.
>
> Attached there are 3 files.
>
> dmesg-startup is the startup of the last 3.0.0-rc6 kernel, with the
> debug enabled.
> dmesg-enabled is the X startup (and freeze) with debug mode and rc6
> enabled.
> dmesg-disabled is the X startup with debug mode enabled and rc6 disabled
> (so no freeze; full kde startup and logout).
>
> I hope this helps you to solve the problem, otherwise the X201s users
> will not use the 3.0.0 kernel :-(.
>
> If you need more informations just let me know.

AFAICT, this problem is still there in 3.0-rc7. Keith, isn't it time
to revert commit a51f7a6 ("drm/i915: enable rc6 by default") before
3.0 is out?

Re: Reverting rc6 by default

[Pekka Enberg]

On Wed, Jul 6, 2011 at 2:01 AM, Francesco Allertsen
 wrote:
> On Tue, Jun 21, 2011 at 12:01:34PM -0700, Keith Packard wrote:
>> Thanks. I'll see if I can't get an X201s upgraded to this version and
>> see if we can reproduce the problem you're having...
>
> Any news?
>
> I have found the time today for more debugging.
>
> Attached there are 3 files.
>
> dmesg-startup is the startup of the last 3.0.0-rc6 kernel, with the
> debug enabled.
> dmesg-enabled is the X startup (and freeze) with debug mode and rc6
> enabled.
> dmesg-disabled is the X startup with debug mode enabled and rc6 disabled
> (so no freeze; full kde startup and logout).
>
> I hope this helps you to solve the problem, otherwise the X201s users
> will not use the 3.0.0 kernel :-(.
>
> If you need more informations just let me know.

AFAICT, this problem is still there in 3.0-rc7. Keith, isn't it time
to revert commit a51f7a6 ("drm/i915: enable rc6 by default") before
3.0 is out?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

it *appears* the i915 black screen of death issue is back

[Pekka Enberg]

[ Fixing your CC list. ]

On Sun, Apr 10, 2011 at 9:35 AM, Robert P. J. Day  
wrote:
> ?when i built a new kernel based on the latest git tree, i once again
> got the black screen of death on my gateway laptop with an integrated
> intel graphics controller.
>
> ?and as i did not that long ago, i got around it by applying the
> following tweak to the source tree before rebuilding:
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index d2c7104..a1a5d03 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device
> *dev, u32 bclp)
> ? ? ? ?struct opregion_asle *asle = dev_priv->opregion.asle;
> ? ? ? ?u32 max;
>
> +return ASLE_BACKLIGHT_FAILED; // rday
> +
> ? ? ? ?if (!(bclp & ASLE_BCLP_VALID))
> ? ? ? ? ? ? ? ?return ASLE_BACKLIGHT_FAILED;
>
>
> ?so if this issue was resolved, it seems to have regressed.
>
> rday
>
> --
>
> 
> Robert P. J. Day ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ottawa, Ontario, CANADA
> ? ? ? ? ? ? ? ? ? ? ? ?http://crashcourse.ca
>
> Twitter: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? http://twitter.com/rpjday
> LinkedIn: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? http://ca.linkedin.com/in/rpjday
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: it *appears* the i915 black screen of death issue is back

[Pekka Enberg]

[ Fixing your CC list. ]

On Sun, Apr 10, 2011 at 9:35 AM, Robert P. J. Day  wrote:
>  when i built a new kernel based on the latest git tree, i once again
> got the black screen of death on my gateway laptop with an integrated
> intel graphics controller.
>
>  and as i did not that long ago, i got around it by applying the
> following tweak to the source tree before rebuilding:
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index d2c7104..a1a5d03 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device
> *dev, u32 bclp)
>        struct opregion_asle *asle = dev_priv->opregion.asle;
>        u32 max;
>
> +return ASLE_BACKLIGHT_FAILED; // rday
> +
>        if (!(bclp & ASLE_BCLP_VALID))
>                return ASLE_BACKLIGHT_FAILED;
>
>
>  so if this issue was resolved, it seems to have regressed.
>
> rday
>
> --
>
> 
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                        http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> 
> ___
> 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

[git pull] drm fixes for -rc1

[Pekka Enberg]

On Mon, Mar 28, 2011 at 10:09 PM, Chris Wilson  
wrote:
> On Mon, 28 Mar 2011 21:53:32 +0300, Pekka Enberg  
> wrote:
>> On Mon, Mar 28, 2011 at 9:43 PM, Pekka Enberg  wrote:
>> > On Thu, Mar 24, 2011 at 1:34 PM, Dave Airlie  wrote:
>> >> It should have the fix for your i915 in the intel patches, along with
>> >> a couple of radeon fixes, and the vblank change + fix.
>> >
>> > I'm seeing some laptop screen flicker during boot and a while after I
>> > log in (it then seems to go away). It's my trusty old Macbook with
>> > i915 and Ubuntu 10.04. I see this in dmesg:
>> >
>> > [ ? ?1.782046] [drm] initialized overlay support
>> > [ ? ?1.782075] [drm] capturing error event; look for more information
>> > in /debug/dri/0/i915_error_state
>> > [ ? ?1.782889] render error detected, EIR: 0x0010
>> > [ ? ?1.782933] page table error
>> > [ ? ?1.782970] ? PGTBL_ER: 0x0102
>> > [ ? ?1.783009] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck:
>> > 0x0010, masking
>> > [ ? ?1.783063] render error detected, EIR: 0x0010
>> > [ ? ?1.783106] page table error
>> > [ ? ?1.783143] ? PGTBL_ER: 0x0102
>> >
>> > I'm attaching the full dmesg, i915_error_state, and .config.
>
> Right, looks like we have an issue with setting up the hardware for
> KMS/GEM whilst it is still active. As we disable the outputs anyway for
> the KMS takeover, we can arrange to do so first and so prevent this bug.
> The side-effect will be that initial screen blanking will last a little
> bit longer.

Let me know if there's a patch/git tree to test. The flicker is
extremely annoying and I boot the machine often because it's my main
kernel development laptop.

>> I'm also seeing these errors now which seem to be new from 2.6.38-final:
>>
>> [ ?437.566022] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>> [ ?437.566187] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>> [ ?437.566232] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>> [ ?437.566275] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>> [ ?437.566318] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>
> That's an old userspace bug, which so far no one has been able to
> reproduce on the upstream ddx.

Is it harmless? Why is the kernel complaining about it?

Re: [git pull] drm fixes for -rc1

[Pekka Enberg]

On Mon, Mar 28, 2011 at 10:09 PM, Chris Wilson  wrote:
> On Mon, 28 Mar 2011 21:53:32 +0300, Pekka Enberg  wrote:
>> On Mon, Mar 28, 2011 at 9:43 PM, Pekka Enberg  wrote:
>> > On Thu, Mar 24, 2011 at 1:34 PM, Dave Airlie  wrote:
>> >> It should have the fix for your i915 in the intel patches, along with
>> >> a couple of radeon fixes, and the vblank change + fix.
>> >
>> > I'm seeing some laptop screen flicker during boot and a while after I
>> > log in (it then seems to go away). It's my trusty old Macbook with
>> > i915 and Ubuntu 10.04. I see this in dmesg:
>> >
>> > [    1.782046] [drm] initialized overlay support
>> > [    1.782075] [drm] capturing error event; look for more information
>> > in /debug/dri/0/i915_error_state
>> > [    1.782889] render error detected, EIR: 0x0010
>> > [    1.782933] page table error
>> > [    1.782970]   PGTBL_ER: 0x0102
>> > [    1.783009] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck:
>> > 0x0010, masking
>> > [    1.783063] render error detected, EIR: 0x0010
>> > [    1.783106] page table error
>> > [    1.783143]   PGTBL_ER: 0x0102
>> >
>> > I'm attaching the full dmesg, i915_error_state, and .config.
>
> Right, looks like we have an issue with setting up the hardware for
> KMS/GEM whilst it is still active. As we disable the outputs anyway for
> the KMS takeover, we can arrange to do so first and so prevent this bug.
> The side-effect will be that initial screen blanking will last a little
> bit longer.

Let me know if there's a patch/git tree to test. The flicker is
extremely annoying and I boot the machine often because it's my main
kernel development laptop.

>> I'm also seeing these errors now which seem to be new from 2.6.38-final:
>>
>> [  437.566022] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>> [  437.566187] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>> [  437.566232] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>> [  437.566275] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>> [  437.566318] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
>> purgeable buffer
>
> That's an old userspace bug, which so far no one has been able to
> reproduce on the upstream ddx.

Is it harmless? Why is the kernel complaining about it?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes for -rc1

[Pekka Enberg]

On Mon, Mar 28, 2011 at 9:43 PM, Pekka Enberg  wrote:
> On Thu, Mar 24, 2011 at 1:34 PM, Dave Airlie  wrote:
>> It should have the fix for your i915 in the intel patches, along with
>> a couple of radeon fixes, and the vblank change + fix.
>
> I'm seeing some laptop screen flicker during boot and a while after I
> log in (it then seems to go away). It's my trusty old Macbook with
> i915 and Ubuntu 10.04. I see this in dmesg:
>
> [ ? ?1.782046] [drm] initialized overlay support
> [ ? ?1.782075] [drm] capturing error event; look for more information
> in /debug/dri/0/i915_error_state
> [ ? ?1.782889] render error detected, EIR: 0x0010
> [ ? ?1.782933] page table error
> [ ? ?1.782970] ? PGTBL_ER: 0x0102
> [ ? ?1.783009] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck:
> 0x0010, masking
> [ ? ?1.783063] render error detected, EIR: 0x0010
> [ ? ?1.783106] page table error
> [ ? ?1.783143] ? PGTBL_ER: 0x0102
>
> I'm attaching the full dmesg, i915_error_state, and .config.

I'm also seeing these errors now which seem to be new from 2.6.38-final:

[  437.566022] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer
[  437.566187] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer
[  437.566232] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer
[  437.566275] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer
[  437.566318] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer

[git pull] drm fixes for -rc1

[Pekka Enberg]

On Thu, Mar 24, 2011 at 1:34 PM, Dave Airlie  wrote:
> It should have the fix for your i915 in the intel patches, along with
> a couple of radeon fixes, and the vblank change + fix.

I'm seeing some laptop screen flicker during boot and a while after I
log in (it then seems to go away). It's my trusty old Macbook with
i915 and Ubuntu 10.04. I see this in dmesg:

[1.782046] [drm] initialized overlay support
[1.782075] [drm] capturing error event; look for more information
in /debug/dri/0/i915_error_state
[1.782889] render error detected, EIR: 0x0010
[1.782933] page table error
[1.782970]   PGTBL_ER: 0x0102
[1.783009] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck:
0x0010, masking
[1.783063] render error detected, EIR: 0x0010
[1.783106] page table error
[1.783143]   PGTBL_ER: 0x0102

I'm attaching the full dmesg, i915_error_state, and .config.

 Pekka
-- next part --
A non-text attachment was scrubbed...
Name: i915_error_state.gz
Type: application/x-gzip
Size: 92190 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: config.gz
Type: application/x-gzip
Size: 20257 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: dmesg.gz
Type: application/x-gzip
Size: 13976 bytes
Desc: not available
URL: 

Re: [git pull] drm fixes for -rc1

[Pekka Enberg]

On Mon, Mar 28, 2011 at 9:43 PM, Pekka Enberg  wrote:
> On Thu, Mar 24, 2011 at 1:34 PM, Dave Airlie  wrote:
>> It should have the fix for your i915 in the intel patches, along with
>> a couple of radeon fixes, and the vblank change + fix.
>
> I'm seeing some laptop screen flicker during boot and a while after I
> log in (it then seems to go away). It's my trusty old Macbook with
> i915 and Ubuntu 10.04. I see this in dmesg:
>
> [    1.782046] [drm] initialized overlay support
> [    1.782075] [drm] capturing error event; look for more information
> in /debug/dri/0/i915_error_state
> [    1.782889] render error detected, EIR: 0x0010
> [    1.782933] page table error
> [    1.782970]   PGTBL_ER: 0x0102
> [    1.783009] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck:
> 0x0010, masking
> [    1.783063] render error detected, EIR: 0x0010
> [    1.783106] page table error
> [    1.783143]   PGTBL_ER: 0x0102
>
> I'm attaching the full dmesg, i915_error_state, and .config.

I'm also seeing these errors now which seem to be new from 2.6.38-final:

[  437.566022] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer
[  437.566187] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer
[  437.566232] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer
[  437.566275] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer
[  437.566318] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a
purgeable buffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

[Pekka Enberg]

On Fri, Nov 5, 2010 at 4:27 AM, Arnd Bergmann  wrote:
> On Wednesday 03 November 2010, Pekka Enberg wrote:
>> On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek  wrote:
>> > Hi!
>> >
>> >> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>> >>
>> >> ?static int __init i810_init(void)
>> >> ?{
>> >> + ? ? if (num_present_cpus() > 1) {
>> >> + ? ? ? ? ? ? pr_err("drm/i810 does not support SMP\n");
>> >> + ? ? ? ? ? ? return -EINVAL;
>> >> + ? ? }
>> >> ? ? ? driver.num_ioctls = i810_max_ioctl;
>> >> ? ? ? return drm_init(&driver);
>> >
>> > Umm, and now someone onlines second cpu?
>>
>> Well, I see it's being fixed in a different way but yeah,
>> num_possible_cpus() would be more appropriate here.
>
> (trimming Cc list again)
>
> I thought that patch was still current, what other way are we fixing it now?

Oh, I just read the thread wrong. If you repost with
num_possible_cpus, feel free to add my ACK.

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

[Pekka Enberg]

On Fri, Nov 5, 2010 at 4:27 AM, Arnd Bergmann  wrote:
> On Wednesday 03 November 2010, Pekka Enberg wrote:
>> On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek  wrote:
>> > Hi!
>> >
>> >> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>> >>
>> >>  static int __init i810_init(void)
>> >>  {
>> >> +     if (num_present_cpus() > 1) {
>> >> +             pr_err("drm/i810 does not support SMP\n");
>> >> +             return -EINVAL;
>> >> +     }
>> >>       driver.num_ioctls = i810_max_ioctl;
>> >>       return drm_init(&driver);
>> >
>> > Umm, and now someone onlines second cpu?
>>
>> Well, I see it's being fixed in a different way but yeah,
>> num_possible_cpus() would be more appropriate here.
>
> (trimming Cc list again)
>
> I thought that patch was still current, what other way are we fixing it now?

Oh, I just read the thread wrong. If you repost with
num_possible_cpus, feel free to add my ACK.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

[Pekka Enberg]

On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek  wrote:
> Hi!
>
>> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>>
>> ?static int __init i810_init(void)
>> ?{
>> + ? ? if (num_present_cpus() > 1) {
>> + ? ? ? ? ? ? pr_err("drm/i810 does not support SMP\n");
>> + ? ? ? ? ? ? return -EINVAL;
>> + ? ? }
>> ? ? ? driver.num_ioctls = i810_max_ioctl;
>> ? ? ? return drm_init(&driver);
>
> Umm, and now someone onlines second cpu?

Well, I see it's being fixed in a different way but yeah,
num_possible_cpus() would be more appropriate here.

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

[Pekka Enberg]

On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek  wrote:
> Hi!
>
>> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>>
>>  static int __init i810_init(void)
>>  {
>> +     if (num_present_cpus() > 1) {
>> +             pr_err("drm/i810 does not support SMP\n");
>> +             return -EINVAL;
>> +     }
>>       driver.num_ioctls = i810_max_ioctl;
>>       return drm_init(&driver);
>
> Umm, and now someone onlines second cpu?

Well, I see it's being fixed in a different way but yeah,
num_possible_cpus() would be more appropriate here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915: wrong framebuffer size in 2.6.36-rc3

[Pekka Enberg]

On Mon, Aug 30, 2010 at 12:36 PM, Sven Joachim  wrote:
> On my laptop which has a 1280x800 display, only the upper left 848x480
> pixels are used on the console in 2.6.36-rc3. ?The resolution is
> correct, but /sys/class/graphics/fb0/modes looks like this:
>
> U:848x480p-0
>
> This is a regression from 2.6.35. ?The graphics card according to lspci:
>
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
> 943/940GML Express Integrated Graphics Controller (rev 03)

Yeah, you're not alone on this:

http://lkml.org/lkml/2010/8/23/452

Re: i915: wrong framebuffer size in 2.6.36-rc3

[Pekka Enberg]

On Mon, Aug 30, 2010 at 12:36 PM, Sven Joachim  wrote:
> On my laptop which has a 1280x800 display, only the upper left 848x480
> pixels are used on the console in 2.6.36-rc3.  The resolution is
> correct, but /sys/class/graphics/fb0/modes looks like this:
>
> U:848x480p-0
>
> This is a regression from 2.6.35.  The graphics card according to lspci:
>
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
> 943/940GML Express Integrated Graphics Controller (rev 03)

Yeah, you're not alone on this:

http://lkml.org/lkml/2010/8/23/452
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PROBLEM] i915/drm: Insufficient FIFO for plane

[Pekka Enberg]

On Thu, Aug 26, 2010 at 9:27 PM, Maciej Rutecki
 wrote:
> On niedziela, 22 sierpnia 2010 o 17:26:19 Pekka Enberg wrote:
>> Hi,
>>
>> I'm seeing tons of these error messages with current Linus' git:
>>
>> [ ? 95.941618] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for
>> plane, expect flickering: entries required = 36, available = 31.
>>
>> Contrary to the error message, I don't see any flickering. I've attached
>> my dmesg and config.
>>
> See:
> https://bugzilla.kernel.org/show_bug.cgi?id=17021

The "insufficient FIFO for plane" problem seems to have gone away with
latest Linus' git. I suppose commit
9559fcdbff4f93d29af04478bbc48294519424f5 ("drm/i915: fix vblank wait
test condition") fixed it although I don't see any mention of the
error in the changelog?

 Pekka

i915: 2.6.36-rc2 wrong resolution on gdm start

[Pekka Enberg]

Hi all,

On Tue, Aug 24, 2010 at 12:12 PM, Ivan Bulatovic  wrote:
> Thanks for the confirmation Pekka. I've managed to change the resolution
> but gdm always starts with 1024x768 and upon login it gets 1280x1024,
> and sometimes the mouse pointer go out of bounds to the right edge of
> the screen but when I maximize windows it sticks to 1280x1024. When I
> start gnome-display-properties that invisible right portion of the
> screen dissapears.

I'm still seeing wrong resolution with my i915 Macbook with latest
Linus' git. Is there a fix in the pipeline or should we start looking
for a commit to revert? As a slab maintainer, I'm supposed to be able
to work with -rc kernels and this particular bug is pretty damn
annoying.

   Pekka

Re: [PROBLEM] i915/drm: Insufficient FIFO for plane

[Pekka Enberg]

On Thu, Aug 26, 2010 at 9:27 PM, Maciej Rutecki
 wrote:
> On niedziela, 22 sierpnia 2010 o 17:26:19 Pekka Enberg wrote:
>> Hi,
>>
>> I'm seeing tons of these error messages with current Linus' git:
>>
>> [   95.941618] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for
>> plane, expect flickering: entries required = 36, available = 31.
>>
>> Contrary to the error message, I don't see any flickering. I've attached
>> my dmesg and config.
>>
> See:
> https://bugzilla.kernel.org/show_bug.cgi?id=17021

The "insufficient FIFO for plane" problem seems to have gone away with
latest Linus' git. I suppose commit
9559fcdbff4f93d29af04478bbc48294519424f5 ("drm/i915: fix vblank wait
test condition") fixed it although I don't see any mention of the
error in the changelog?

 Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: 2.6.36-rc2 wrong resolution on gdm start

[Pekka Enberg]

Hi all,

On Tue, Aug 24, 2010 at 12:12 PM, Ivan Bulatovic  wrote:
> Thanks for the confirmation Pekka. I've managed to change the resolution
> but gdm always starts with 1024x768 and upon login it gets 1280x1024,
> and sometimes the mouse pointer go out of bounds to the right edge of
> the screen but when I maximize windows it sticks to 1280x1024. When I
> start gnome-display-properties that invisible right portion of the
> screen dissapears.

I'm still seeing wrong resolution with my i915 Macbook with latest
Linus' git. Is there a fix in the pipeline or should we start looking
for a commit to revert? As a slab maintainer, I'm supposed to be able
to work with -rc kernels and this particular bug is pretty damn
annoying.

   Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915: 2.6.36-rc2 wrong resolution on gdm start

[Pekka Enberg]

On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic  wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x768 on startup.
>
> I've disabled LVDS output with video=LVDS-1:d because the cable looses
> connection in certain lid positions.
>
> 2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and
> it came down to this commit:
>
> 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit
> commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
> Author: Jesse Barnes 
> Date: ? Wed Aug 18 13:20:54 2010 -0700
>
> ? ?drm/i915: wait for actual vblank, not just 20ms
>
> Waiting for a hard coded 20ms isn't always enough to make sure a vblank
> period has actually occurred, so add code to make sure we really have
> passed through a vblank period (or that the pipe is off when disabling).
>
> This prevents problems with mode setting and link training, and seems to
> fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
> on an HP 8440p instead. ?Hopefully also fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=29141.
>
> ? ?Signed-off-by: Jesse Barnes 
> ? ?Signed-off-by: Eric Anholt 
>
> :04 04 9941813d0f0bc4e141a87696d34f1d1b9087711b
> 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
>
> I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on
> DELL Vostro 1310 is in question. Thanks,

On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic  wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x768 on startup.
>
> I've disabled LVDS output with video=LVDS-1:d because the cable looses
> connection in certain lid positions.
>
> 2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and
> it came down to this commit:
>
> 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit
> commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
> Author: Jesse Barnes 
> Date: ? Wed Aug 18 13:20:54 2010 -0700
>
> ? ?drm/i915: wait for actual vblank, not just 20ms
>
> Waiting for a hard coded 20ms isn't always enough to make sure a vblank
> period has actually occurred, so add code to make sure we really have
> passed through a vblank period (or that the pipe is off when disabling).
>
> This prevents problems with mode setting and link training, and seems to
> fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
> on an HP 8440p instead. ?Hopefully also fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=29141.
>
> ? ?Signed-off-by: Jesse Barnes 
> ? ?Signed-off-by: Eric Anholt 
>
> :04 04 9941813d0f0bc4e141a87696d34f1d1b9087711b
> 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
>
> I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on
> DELL Vostro 1310 is in question. Thanks,

FWIW, I saw this on my MacBook as well. I was debugging a boot time
oops at the time so I just changed screen resolution in Gnome to fix
it.

Re: i915: 2.6.36-rc2 wrong resolution on gdm start

[Pekka Enberg]

On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic  wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x768 on startup.
>
> I've disabled LVDS output with video=LVDS-1:d because the cable looses
> connection in certain lid positions.
>
> 2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and
> it came down to this commit:
>
> 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit
> commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
> Author: Jesse Barnes 
> Date:   Wed Aug 18 13:20:54 2010 -0700
>
>    drm/i915: wait for actual vblank, not just 20ms
>
> Waiting for a hard coded 20ms isn't always enough to make sure a vblank
> period has actually occurred, so add code to make sure we really have
> passed through a vblank period (or that the pipe is off when disabling).
>
> This prevents problems with mode setting and link training, and seems to
> fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
> on an HP 8440p instead.  Hopefully also fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=29141.
>
>    Signed-off-by: Jesse Barnes 
>    Signed-off-by: Eric Anholt 
>
> :04 04 9941813d0f0bc4e141a87696d34f1d1b9087711b
> 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
>
> I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on
> DELL Vostro 1310 is in question. Thanks,

On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic  wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x768 on startup.
>
> I've disabled LVDS output with video=LVDS-1:d because the cable looses
> connection in certain lid positions.
>
> 2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and
> it came down to this commit:
>
> 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit
> commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
> Author: Jesse Barnes 
> Date:   Wed Aug 18 13:20:54 2010 -0700
>
>    drm/i915: wait for actual vblank, not just 20ms
>
> Waiting for a hard coded 20ms isn't always enough to make sure a vblank
> period has actually occurred, so add code to make sure we really have
> passed through a vblank period (or that the pipe is off when disabling).
>
> This prevents problems with mode setting and link training, and seems to
> fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
> on an HP 8440p instead.  Hopefully also fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=29141.
>
>    Signed-off-by: Jesse Barnes 
>    Signed-off-by: Eric Anholt 
>
> :04 04 9941813d0f0bc4e141a87696d34f1d1b9087711b
> 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
>
> I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on
> DELL Vostro 1310 is in question. Thanks,

FWIW, I saw this on my MacBook as well. I was debugging a boot time
oops at the time so I just changed screen resolution in Gnome to fix
it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PROBLEM] i915/drm: Insufficient FIFO for plane

[Pekka Enberg]

Hi,

I'm seeing tons of these error messages with current Linus' git:

[   95.941618] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for 
plane, expect flickering: entries required = 36, available = 31.

Contrary to the error message, I don't see any flickering. I've attached 
my dmesg and config.

Pekka
-- next part --
[0.00] Linux version 2.6.36-rc1+ (penberg at tiger) (gcc version 4.4.1 
(Ubuntu 4.4.1-4ubuntu9) ) #100 SMP Sun Aug 22 17:58:15 EEST 2010
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.36-rc1+ 
root=UUID=ff2f6ee0-003b-4c90-96f8-5256070fc641 ro quiet splash
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009fc00 (usable)
[0.00]  BIOS-e820: 0009fc00 - 000a (reserved)
[0.00]  BIOS-e820: 000e - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 3e0f8000 (usable)
[0.00]  BIOS-e820: 3e0f8000 - 3e2f9000 (ACPI NVS)
[0.00]  BIOS-e820: 3e2f9000 - 3eebe000 (ACPI data)
[0.00]  BIOS-e820: 3eebe000 - 3eeef000 (ACPI NVS)
[0.00]  BIOS-e820: 3eeef000 - 3ef0 (ACPI data)
[0.00]  BIOS-e820: 3ef0 - 4000 (reserved)
[0.00]  BIOS-e820: f000 - f400 (reserved)
[0.00]  BIOS-e820: fec0 - fec01000 (reserved)
[0.00]  BIOS-e820: fed14000 - fed1a000 (reserved)
[0.00]  BIOS-e820: fed1c000 - fed2 (reserved)
[0.00]  BIOS-e820: fee0 - fee01000 (reserved)
[0.00]  BIOS-e820: ffe0 - 0001 (reserved)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.4 present.
[0.00] e820 update range:  - 1000 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x3e0f8 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFE0 mask FFFE0 write-protect
[0.00]   1 base 0 mask FC000 write-back
[0.00]   2 base 03F00 mask FFF00 uncachable
[0.00]   3 base 03EF0 mask 0 uncachable
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] e820 update range: 1000 - 0001 (usable) 
==> (reserved)
[0.00] Scanning 1 areas for low memory corruption
[0.00] modified physical RAM map:
[0.00]  modified:  - 0001 (reserved)
[0.00]  modified: 0001 - 0009fc00 (usable)
[0.00]  modified: 0009fc00 - 000a (reserved)
[0.00]  modified: 000e - 0010 (reserved)
[0.00]  modified: 0010 - 3e0f8000 (usable)
[0.00]  modified: 3e0f8000 - 3e2f9000 (ACPI NVS)
[0.00]  modified: 3e2f9000 - 3eebe000 (ACPI data)
[0.00]  modified: 3eebe000 - 3eeef000 (ACPI NVS)
[0.00]  modified: 3eeef000 - 3ef0 (ACPI data)
[0.00]  modified: 3ef0 - 4000 (reserved)
[0.00]  modified: f000 - f400 (reserved)
[0.00]  modified: fec0 - fec01000 (reserved)
[0.00]  modified: fed14000 - fed1a000 (reserved)
[0.00]  modified: fed1c000 - fed2 (reserved)
[0.00]  modified: fee0 - fee01000 (reserved)
[0.00]  modified: ffe0 - 0001 (reserved)
[0.00] initial memory mapped : 0 - 2000
[0.00] init_memory_mapping: -3e0f8000
[0.00]  00 - 003e00 page 2M
[0.00]  003e00 - 003e0f8000 page 4k
[0.00] kernel direct mapping tables up to 3e0f8000 @ 16000-19000
[0.00] RAMDISK: 2e62c000 - 2e8fa000
[0.00] ACPI: RSDP 000fe020 00024 (v02 APPLE )
[0.00] ACPI: XSDT 3eefd1c0 00074 (v01 APPLE   Apple00 00A5  
0113)
[0.00] ACPI: FACP 3eefb000 000F4 (v03 APPLE   Apple00 00A5 
Loki 005F)
[0.00] ACPI: DSDT 3eef 041E4 (v01 APPLE   MacBook 00020001 
INTL 20050309)
[0.00] ACPI: F