subject:"Re\: linux\-next\: Tree for Aug 13"

Re: nvme crash - Re: linux-next: Tree for Aug 13

2020-08-14 Thread John Garry


On 14/08/2020 14:07, John Garry wrote:


BTW, as for the DMA/sg scatterlist code, it so happens in this case that 
we try the dma alloc for size=0 in nvme_alloc_queue() - I know an 
allocation for size=0 makes no sense, but couldn't we bit a bit more 
robust?


it's giving ZERO_SIZE_PTR, which we deference, so ignore me...

Re: nvme crash - Re: linux-next: Tree for Aug 13

2020-08-14 Thread John Garry


On 14/08/2020 13:08, Christoph Hellwig wrote:

[148.455065]__sg_alloc_table_from_pages+0xec/0x238
[148.459931]sg_alloc_table_from_pages+0x18/0x28
[148.464541]iommu_dma_alloc+0x474/0x678
[148.468455]dma_alloc_attrs+0xd8/0xf0
[148.472193]nvme_alloc_queue+0x114/0x160 [nvme]
[148.476798]nvme_reset_work+0xb34/0x14b4 [nvme]
[148.481407]process_one_work+0x1e8/0x360
[148.485405]worker_thread+0x44/0x478
[148.489055]kthread+0x150/0x158
[148.492273]ret_from_fork+0x10/0x34
[148.495838] Code: f94002c3 6b01017f 540007c2 11000486 (f8645aa5)
[148.501921] ---[ end trace 89bb2b72d59bf925 ]---

Anything to worry about? I guess not since we're in the merge window, but
mentioning just in case ...

I bisected, and this patch looks to fix it (note the comments below the
'---'):

 From 263891a760edc24b901085bf6e5fe2480808f86d Mon Sep 17 00:00:00 2001
From: John Garry
Date: Fri, 14 Aug 2020 12:45:18 +0100
Subject: [PATCH] nvme-pci: Use u32 for nvme_dev.q_depth

Recently nvme_dev.q_depth was changed from int to u16 type.

This falls over for the queue depth calculation in nvme_pci_enable(),
where NVME_CAP_MQES(dev->ctrl.cap) + 1 may overflow, as NVME_CAP_MQES()
gives a 16b number also. That happens for me, and this is the result:

Oh, interesting.  Please also switch the module option parsing to
use kstrtou32 and param_set_uint and send this as a formal patch.



I'm doing it now.

BTW, as for the DMA/sg scatterlist code, it so happens in this case that 
we try the dma alloc for size=0 in nvme_alloc_queue() - I know an 
allocation for size=0 makes no sense, but couldn't we bit a bit more robust?


Cheers,
John

Re: nvme crash - Re: linux-next: Tree for Aug 13

2020-08-14 Thread Christoph Hellwig

On Fri, Aug 14, 2020 at 01:00:30PM +0100, John Garry wrote:
> 
> > > I have experienced this this crash below on linux-next for the last few 
> > > days
> > > on my arm64 system. Linus' master branch today also has it.
> > Adding Robin and the iommu list as this seems to be in the dma-iommu
> > code.
> > 
> > > root@ubuntu:/home/john# insmod nvme.ko
> > > [148.254564] nvme :81:00.0: Adding to iommu group 21
> > > [148.260973] nvme nvme0: pci function :81:00.0
> > > root@ubuntu:/home/john# [148.272996] Unable to handle kernel NULL pointer
> > > dereference at virtual address 0010
> > > [148.281784] Mem abort info:
> > > [148.284584] ESR = 0x9604
> > > [148.287641] EC = 0x25: DABT (current EL), IL = 32 bits
> > > [148.292950] SET = 0, FnV = 0
> > > [148.295998] EA = 0, S1PTW = 0
> > > [148.299126] Data abort info:
> > > [148.302003] ISV = 0, ISS = 0x0004
> > > [148.305832] CM = 0, WnR = 0
> > > [148.308794] user pgtable: 4k pages, 48-bit VAs, pgdp=0a27bf3c9000
> > > [148.315229] [0010] pgd=, p4d=
> > > [148.322016] Internal error: Oops: 9604 [#1] PREEMPT SMP
> > > [148.327577] Modules linked in: nvme nvme_core
> > > [148.331927] CPU: 56 PID: 256 Comm: kworker/u195:0 Not tainted
> > > 5.8.0-next-20200812 #27
> > > [148.339744] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 -
> > > V1.16.01 03/15/2019
> > > [148.348260] Workqueue: nvme-reset-wq nvme_reset_work [nvme]
> > > [148.353822] pstate: 80c9 (Nzcv daif +PAN +UAO BTYPE=--)
> > > [148.359390] pc : __sg_alloc_table_from_pages+0xec/0x238
> > > [148.364604] lr : __sg_alloc_table_from_pages+0xc8/0x238
> > > [148.369815] sp : 800013ccbad0
> > > [148.373116] x29: 800013ccbad0 x28: 0a27b3d380a8
> > > [148.378417] x27:  x26: 2dc2
> > > [148.383718] x25: 0dc0 x24: 
> > > [148.389019] x23:  x22: 800013ccbbe8
> > > [148.394320] x21: 0010 x20: 
> > > [148.399621] x19: f000 x18: 
> > > [148.404922] x17: 00c0 x16: fe289eaf6380
> > > [148.410223] x15: 800011b59948 x14: 002bc8fe98f8
> > > [148.415523] x13: ff00 x12: 8000114ca000
> > > [148.420824] x11:  x10: 
> > > [148.426124] x9 : ffc0 x8 : 0a27b5f9b6a0
> > > [148.431425] x7 :  x6 : 0001
> > > [148.436726] x5 : 0a27b5f9b680 x4 : 
> > > [148.442027] x3 : 0a27b5f9b680 x2 : 
> > > [148.447328] x1 : 0001 x0 : 
> > > [148.452629] Call trace:
> > > [148.455065]__sg_alloc_table_from_pages+0xec/0x238
> > > [148.459931]sg_alloc_table_from_pages+0x18/0x28
> > > [148.464541]iommu_dma_alloc+0x474/0x678
> > > [148.468455]dma_alloc_attrs+0xd8/0xf0
> > > [148.472193]nvme_alloc_queue+0x114/0x160 [nvme]
> > > [148.476798]nvme_reset_work+0xb34/0x14b4 [nvme]
> > > [148.481407]process_one_work+0x1e8/0x360
> > > [148.485405]worker_thread+0x44/0x478
> > > [148.489055]kthread+0x150/0x158
> > > [148.492273]ret_from_fork+0x10/0x34
> > > [148.495838] Code: f94002c3 6b01017f 540007c2 11000486 (f8645aa5)
> > > [148.501921] ---[ end trace 89bb2b72d59bf925 ]---
> > > 
> > > Anything to worry about? I guess not since we're in the merge window, but
> > > mentioning just in case ...
> 
> I bisected, and this patch looks to fix it (note the comments below the
> '---'):
> 
> From 263891a760edc24b901085bf6e5fe2480808f86d Mon Sep 17 00:00:00 2001
> From: John Garry 
> Date: Fri, 14 Aug 2020 12:45:18 +0100
> Subject: [PATCH] nvme-pci: Use u32 for nvme_dev.q_depth
> 
> Recently nvme_dev.q_depth was changed from int to u16 type.
> 
> This falls over for the queue depth calculation in nvme_pci_enable(),
> where NVME_CAP_MQES(dev->ctrl.cap) + 1 may overflow, as NVME_CAP_MQES()
> gives a 16b number also. That happens for me, and this is the result:

Oh, interesting.  Please also switch the module option parsing to
use kstrtou32 and param_set_uint and send this as a formal patch.

Thanks!

Re: nvme crash - Re: linux-next: Tree for Aug 13

2020-08-14 Thread John Garry





I have experienced this this crash below on linux-next for the last few days
on my arm64 system. Linus' master branch today also has it.

Adding Robin and the iommu list as this seems to be in the dma-iommu
code.


root@ubuntu:/home/john# insmod nvme.ko
[148.254564] nvme :81:00.0: Adding to iommu group 21
[148.260973] nvme nvme0: pci function :81:00.0
root@ubuntu:/home/john# [148.272996] Unable to handle kernel NULL pointer
dereference at virtual address 0010
[148.281784] Mem abort info:
[148.284584] ESR = 0x9604
[148.287641] EC = 0x25: DABT (current EL), IL = 32 bits
[148.292950] SET = 0, FnV = 0
[148.295998] EA = 0, S1PTW = 0
[148.299126] Data abort info:
[148.302003] ISV = 0, ISS = 0x0004
[148.305832] CM = 0, WnR = 0
[148.308794] user pgtable: 4k pages, 48-bit VAs, pgdp=0a27bf3c9000
[148.315229] [0010] pgd=, p4d=
[148.322016] Internal error: Oops: 9604 [#1] PREEMPT SMP
[148.327577] Modules linked in: nvme nvme_core
[148.331927] CPU: 56 PID: 256 Comm: kworker/u195:0 Not tainted
5.8.0-next-20200812 #27
[148.339744] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 -
V1.16.01 03/15/2019
[148.348260] Workqueue: nvme-reset-wq nvme_reset_work [nvme]
[148.353822] pstate: 80c9 (Nzcv daif +PAN +UAO BTYPE=--)
[148.359390] pc : __sg_alloc_table_from_pages+0xec/0x238
[148.364604] lr : __sg_alloc_table_from_pages+0xc8/0x238
[148.369815] sp : 800013ccbad0
[148.373116] x29: 800013ccbad0 x28: 0a27b3d380a8
[148.378417] x27:  x26: 2dc2
[148.383718] x25: 0dc0 x24: 
[148.389019] x23:  x22: 800013ccbbe8
[148.394320] x21: 0010 x20: 
[148.399621] x19: f000 x18: 
[148.404922] x17: 00c0 x16: fe289eaf6380
[148.410223] x15: 800011b59948 x14: 002bc8fe98f8
[148.415523] x13: ff00 x12: 8000114ca000
[148.420824] x11:  x10: 
[148.426124] x9 : ffc0 x8 : 0a27b5f9b6a0
[148.431425] x7 :  x6 : 0001
[148.436726] x5 : 0a27b5f9b680 x4 : 
[148.442027] x3 : 0a27b5f9b680 x2 : 
[148.447328] x1 : 0001 x0 : 
[148.452629] Call trace:
[148.455065]__sg_alloc_table_from_pages+0xec/0x238
[148.459931]sg_alloc_table_from_pages+0x18/0x28
[148.464541]iommu_dma_alloc+0x474/0x678
[148.468455]dma_alloc_attrs+0xd8/0xf0
[148.472193]nvme_alloc_queue+0x114/0x160 [nvme]
[148.476798]nvme_reset_work+0xb34/0x14b4 [nvme]
[148.481407]process_one_work+0x1e8/0x360
[148.485405]worker_thread+0x44/0x478
[148.489055]kthread+0x150/0x158
[148.492273]ret_from_fork+0x10/0x34
[148.495838] Code: f94002c3 6b01017f 540007c2 11000486 (f8645aa5)
[148.501921] ---[ end trace 89bb2b72d59bf925 ]---

Anything to worry about? I guess not since we're in the merge window, but
mentioning just in case ...


I bisected, and this patch looks to fix it (note the comments below the 
'---'):


From 263891a760edc24b901085bf6e5fe2480808f86d Mon Sep 17 00:00:00 2001
From: John Garry 
Date: Fri, 14 Aug 2020 12:45:18 +0100
Subject: [PATCH] nvme-pci: Use u32 for nvme_dev.q_depth

Recently nvme_dev.q_depth was changed from int to u16 type.

This falls over for the queue depth calculation in nvme_pci_enable(),
where NVME_CAP_MQES(dev->ctrl.cap) + 1 may overflow, as NVME_CAP_MQES()
gives a 16b number also. That happens for me, and this is the result:

root@ubuntu:/home/john# [148.272996] Unable to handle kernel NULL pointer
dereference at virtual address 0010
[148.281784] Mem abort info:
[148.284584] ESR = 0x9604
[148.287641] EC = 0x25: DABT (current EL), IL = 32 bits
[148.292950] SET = 0, FnV = 0
[148.295998] EA = 0, S1PTW = 0
[148.299126] Data abort info:
[148.302003] ISV = 0, ISS = 0x0004
[148.305832] CM = 0, WnR = 0
[148.308794] user pgtable: 4k pages, 48-bit VAs, pgdp=0a27bf3c9000
[148.315229] [0010] pgd=, p4d=
[148.322016] Internal error: Oops: 9604 [#1] PREEMPT SMP
[148.327577] Modules linked in: nvme nvme_core
[148.331927] CPU: 56 PID: 256 Comm: kworker/u195:0 Not tainted
5.8.0-next-20200812 #27
[148.339744] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 -
V1.16.01 03/15/2019
[148.348260] Workqueue: nvme-reset-wq nvme_reset_work [nvme]
[148.353822] pstate: 80c9 (Nzcv daif +PAN +UAO BTYPE=--)
[148.359390] pc : __sg_alloc_table_from_pages+0xec/0x238
[148.364604] lr : __sg_alloc_table_from_pages+0xc8/0x238
[148.369815] sp : 800013ccbad0
[148.373116] x29: 800013ccbad0 x28: 0a27b3d380a8
[148.378417] x27:  x26: 2dc2
[148.383718] x25: 0dc0 x24: 
[148.389019] x23:  x22: 800013ccbbe8
[148.394320] x21: 0010 x20: 
[148.399621] x19: f000 x18: 
[148.404922] x17:

Re: linux-next: Tree for Aug 13 (drivers/media/i2c/max9286.c)

2020-08-13 Thread Sakari Ailus

Hi Kieran,

On Thu, Aug 13, 2020 at 08:01:01PM +0100, Kieran Bingham wrote:
> Hi Randy,
> 
> On 13/08/2020 19:35, Randy Dunlap wrote:
> > On 8/12/20 11:58 PM, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> News: The merge window has opened, so please do not add any v5.10
> >> related material to your linux-next included branches until after the
> >> merge window closes again.
> >>
> >> Changes since 20200812:
> >>
> > 
> > on x86_64:
> > 
> > # CONFIG_GPIOLIB is not set
> > 
> > ../drivers/media/i2c/max9286.c: In function 'max9286_register_gpio':
> > ../drivers/media/i2c/max9286.c:1033:6: error: 'struct gpio_chip' has no 
> > member named 'of_node'
> >   gpio->of_node = dev->of_node;
> > 
> 
> Thanks for the report, Sakari has already submitted a fix [0] for this.
> I assume it just needs a nudge to get picked up via Mauro's tree.
> 
> [0]
> https://lore.kernel.org/linux-media/20200803090935.23619-1-sakari.ai...@linux.intel.com/

Yes. I'll send a pull request soon.

-- 
Sakari Ailus

Re: linux-next: Tree for Aug 13 (drivers/media/i2c/max9286.c)

2020-08-13 Thread Kieran Bingham

Hi Randy,

On 13/08/2020 19:35, Randy Dunlap wrote:
> On 8/12/20 11:58 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> News: The merge window has opened, so please do not add any v5.10
>> related material to your linux-next included branches until after the
>> merge window closes again.
>>
>> Changes since 20200812:
>>
> 
> on x86_64:
> 
> # CONFIG_GPIOLIB is not set
> 
> ../drivers/media/i2c/max9286.c: In function 'max9286_register_gpio':
> ../drivers/media/i2c/max9286.c:1033:6: error: 'struct gpio_chip' has no 
> member named 'of_node'
>   gpio->of_node = dev->of_node;
> 

Thanks for the report, Sakari has already submitted a fix [0] for this.
I assume it just needs a nudge to get picked up via Mauro's tree.

[0]
https://lore.kernel.org/linux-media/20200803090935.23619-1-sakari.ai...@linux.intel.com/

Thanks
--
Kieran

Re: linux-next: Tree for Aug 13 (drivers/media/i2c/max9286.c)

2020-08-13 Thread Randy Dunlap

On 8/12/20 11:58 PM, Stephen Rothwell wrote:
> Hi all,
> 
> News: The merge window has opened, so please do not add any v5.10
> related material to your linux-next included branches until after the
> merge window closes again.
> 
> Changes since 20200812:
> 

on x86_64:

# CONFIG_GPIOLIB is not set

../drivers/media/i2c/max9286.c: In function 'max9286_register_gpio':
../drivers/media/i2c/max9286.c:1033:6: error: 'struct gpio_chip' has no member 
named 'of_node'
  gpio->of_node = dev->of_node;


-- 
~Randy
Reported-by: Randy Dunlap

Re: nvme crash - Re: linux-next: Tree for Aug 13

2020-08-13 Thread Christoph Hellwig

On Thu, Aug 13, 2020 at 12:00:19PM +0100, John Garry wrote:
> On 13/08/2020 07:58, Stephen Rothwell wrote:
> > Hi all,
> 
> Hi guys,
> 
> I have experienced this this crash below on linux-next for the last few days
> on my arm64 system. Linus' master branch today also has it.

Adding Robin and the iommu list as this seems to be in the dma-iommu
code.

> root@ubuntu:/home/john# insmod nvme.ko
> [148.254564] nvme :81:00.0: Adding to iommu group 21
> [148.260973] nvme nvme0: pci function :81:00.0
> root@ubuntu:/home/john# [148.272996] Unable to handle kernel NULL pointer
> dereference at virtual address 0010
> [148.281784] Mem abort info:
> [148.284584] ESR = 0x9604
> [148.287641] EC = 0x25: DABT (current EL), IL = 32 bits
> [148.292950] SET = 0, FnV = 0
> [148.295998] EA = 0, S1PTW = 0
> [148.299126] Data abort info:
> [148.302003] ISV = 0, ISS = 0x0004
> [148.305832] CM = 0, WnR = 0
> [148.308794] user pgtable: 4k pages, 48-bit VAs, pgdp=0a27bf3c9000
> [148.315229] [0010] pgd=, p4d=
> [148.322016] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [148.327577] Modules linked in: nvme nvme_core
> [148.331927] CPU: 56 PID: 256 Comm: kworker/u195:0 Not tainted
> 5.8.0-next-20200812 #27
> [148.339744] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 -
> V1.16.01 03/15/2019
> [148.348260] Workqueue: nvme-reset-wq nvme_reset_work [nvme]
> [148.353822] pstate: 80c9 (Nzcv daif +PAN +UAO BTYPE=--)
> [148.359390] pc : __sg_alloc_table_from_pages+0xec/0x238
> [148.364604] lr : __sg_alloc_table_from_pages+0xc8/0x238
> [148.369815] sp : 800013ccbad0
> [148.373116] x29: 800013ccbad0 x28: 0a27b3d380a8
> [148.378417] x27:  x26: 2dc2
> [148.383718] x25: 0dc0 x24: 
> [148.389019] x23:  x22: 800013ccbbe8
> [148.394320] x21: 0010 x20: 
> [148.399621] x19: f000 x18: 
> [148.404922] x17: 00c0 x16: fe289eaf6380
> [148.410223] x15: 800011b59948 x14: 002bc8fe98f8
> [148.415523] x13: ff00 x12: 8000114ca000
> [148.420824] x11:  x10: 
> [148.426124] x9 : ffc0 x8 : 0a27b5f9b6a0
> [148.431425] x7 :  x6 : 0001
> [148.436726] x5 : 0a27b5f9b680 x4 : 
> [148.442027] x3 : 0a27b5f9b680 x2 : 
> [148.447328] x1 : 0001 x0 : 
> [148.452629] Call trace:
> [148.455065]__sg_alloc_table_from_pages+0xec/0x238
> [148.459931]sg_alloc_table_from_pages+0x18/0x28
> [148.464541]iommu_dma_alloc+0x474/0x678
> [148.468455]dma_alloc_attrs+0xd8/0xf0
> [148.472193]nvme_alloc_queue+0x114/0x160 [nvme]
> [148.476798]nvme_reset_work+0xb34/0x14b4 [nvme]
> [148.481407]process_one_work+0x1e8/0x360
> [148.485405]worker_thread+0x44/0x478
> [148.489055]kthread+0x150/0x158
> [148.492273]ret_from_fork+0x10/0x34
> [148.495838] Code: f94002c3 6b01017f 540007c2 11000486 (f8645aa5)
> [148.501921] ---[ end trace 89bb2b72d59bf925 ]---
> 
> Anything to worry about? I guess not since we're in the merge window, but
> mentioning just in case ...
> 
> Thanks,
> john
> 
> > 
> > News: The merge window has opened, so please do not add any v5.10
> > related material to your linux-next included branches until after the
> > merge window closes again.
> > 
> > Changes since 20200812:
> > 
> > My fixes tree contains:
> > 
> >73c7adb54169 ("device_cgroup: Fix RCU list debugging warning")
> > 
> > Linus' tree produces a WARNING in my qemu testing (see
> > https://lore.kernel.org/lkml/20200813164654.061db...@canb.auug.org.au/).
> > 
> > Non-merge commits (relative to Linus' tree): 946
> >   1083 files changed, 28405 insertions(+), 9953 deletions(-)
> > 
> > 
> > 
> > I have created today's linux-next tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> > are tracking the linux-next tree using git, you should not use "git pull"
> > to do so as that will try to merge the new linux-next release with the
> > old one.  You should use "git fetch" and checkout or reset to the new
> > master.
> > 
> > You can see which trees have been included by looking in the Next/Trees
> > file in the source.  There are also quilt-import.log and merge.log
> > files in the Next directory.  Between each merge, the tree was built
> > with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> > multi_v7_defconfig for arm and a native build of tools/perf. After
> > the final fixups (if any), I do an x86_64 modules_install followed by
> > builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> > ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> > and sparc64 defconfig and htmldocs. And

nvme crash - Re: linux-next: Tree for Aug 13

2020-08-13 Thread John Garry


On 13/08/2020 07:58, Stephen Rothwell wrote:

Hi all,


Hi guys,

I have experienced this this crash below on linux-next for the last few 
days on my arm64 system. Linus' master branch today also has it.


root@ubuntu:/home/john# insmod nvme.ko
[148.254564] nvme :81:00.0: Adding to iommu group 21
[148.260973] nvme nvme0: pci function :81:00.0
root@ubuntu:/home/john# [148.272996] Unable to handle kernel NULL 
pointer dereference at virtual address 0010

[148.281784] Mem abort info:
[148.284584] ESR = 0x9604
[148.287641] EC = 0x25: DABT (current EL), IL = 32 bits
[148.292950] SET = 0, FnV = 0
[148.295998] EA = 0, S1PTW = 0
[148.299126] Data abort info:
[148.302003] ISV = 0, ISS = 0x0004
[148.305832] CM = 0, WnR = 0
[148.308794] user pgtable: 4k pages, 48-bit VAs, pgdp=0a27bf3c9000
[148.315229] [0010] pgd=, p4d=
[148.322016] Internal error: Oops: 9604 [#1] PREEMPT SMP
[148.327577] Modules linked in: nvme nvme_core
[148.331927] CPU: 56 PID: 256 Comm: kworker/u195:0 Not tainted 
5.8.0-next-20200812 #27
[148.339744] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 
- V1.16.01 03/15/2019

[148.348260] Workqueue: nvme-reset-wq nvme_reset_work [nvme]
[148.353822] pstate: 80c9 (Nzcv daif +PAN +UAO BTYPE=--)
[148.359390] pc : __sg_alloc_table_from_pages+0xec/0x238
[148.364604] lr : __sg_alloc_table_from_pages+0xc8/0x238
[148.369815] sp : 800013ccbad0
[148.373116] x29: 800013ccbad0 x28: 0a27b3d380a8
[148.378417] x27:  x26: 2dc2
[148.383718] x25: 0dc0 x24: 
[148.389019] x23:  x22: 800013ccbbe8
[148.394320] x21: 0010 x20: 
[148.399621] x19: f000 x18: 
[148.404922] x17: 00c0 x16: fe289eaf6380
[148.410223] x15: 800011b59948 x14: 002bc8fe98f8
[148.415523] x13: ff00 x12: 8000114ca000
[148.420824] x11:  x10: 
[148.426124] x9 : ffc0 x8 : 0a27b5f9b6a0
[148.431425] x7 :  x6 : 0001
[148.436726] x5 : 0a27b5f9b680 x4 : 
[148.442027] x3 : 0a27b5f9b680 x2 : 
[148.447328] x1 : 0001 x0 : 
[148.452629] Call trace:
[148.455065]__sg_alloc_table_from_pages+0xec/0x238
[148.459931]sg_alloc_table_from_pages+0x18/0x28
[148.464541]iommu_dma_alloc+0x474/0x678
[148.468455]dma_alloc_attrs+0xd8/0xf0
[148.472193]nvme_alloc_queue+0x114/0x160 [nvme]
[148.476798]nvme_reset_work+0xb34/0x14b4 [nvme]
[148.481407]process_one_work+0x1e8/0x360
[148.485405]worker_thread+0x44/0x478
[148.489055]kthread+0x150/0x158
[148.492273]ret_from_fork+0x10/0x34
[148.495838] Code: f94002c3 6b01017f 540007c2 11000486 (f8645aa5)
[148.501921] ---[ end trace 89bb2b72d59bf925 ]---

Anything to worry about? I guess not since we're in the merge window, 
but mentioning just in case ...


Thanks,
john



News: The merge window has opened, so please do not add any v5.10
related material to your linux-next included branches until after the
merge window closes again.

Changes since 20200812:

My fixes tree contains:

   73c7adb54169 ("device_cgroup: Fix RCU list debugging warning")

Linus' tree produces a WARNING in my qemu testing (see
https://lore.kernel.org/lkml/20200813164654.061db...@canb.auug.org.au/).

Non-merge commits (relative to Linus' tree): 946
  1083 files changed, 28405 insertions(+), 9953 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 327 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build

Re: linux-next: Tree for Aug 13

2019-08-14 Thread Stephen Rothwell

Hi all,

On Wed, 14 Aug 2019 08:14:18 +0200 Marek Szyprowski  
wrote:
>
> On 2019-08-13 16:56, Steven Rostedt wrote:
> > This looks related to what Marek posted.
> >
> >
> > https://lore.kernel.org/linux-security-module/3028ed35-3b6d-459f-f3c8-103c5636f...@samsung.com/
> >
> > Care to apply the change he suggested to see if it fixes the issue for
> > you. If it does, Marek, can you make an official patch?  
> 
> Sure: https://lkml.org/lkml/2019/8/14/75

I have applied that to linux-next today.

-- 
Cheers,
Stephen Rothwell


pgpW_TGg2bE9g.pgp
Description: OpenPGP digital signature

Re: linux-next: Tree for Aug 13

2019-08-14 Thread Marek Szyprowski

Hi Steven,

On 2019-08-13 16:56, Steven Rostedt wrote:
> This looks related to what Marek posted.
>
>
> https://lore.kernel.org/linux-security-module/3028ed35-3b6d-459f-f3c8-103c5636f...@samsung.com/
>
> Care to apply the change he suggested to see if it fixes the issue for
> you. If it does, Marek, can you make an official patch?

Sure: https://lkml.org/lkml/2019/8/14/75

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: linux-next: Tree for Aug 13

2019-08-13 Thread Vasily Gorbik

On Tue, Aug 13, 2019 at 10:56:45AM -0400, Steven Rostedt wrote:
> 
> This looks related to what Marek posted.
> 
>   
> https://lore.kernel.org/linux-security-module/3028ed35-3b6d-459f-f3c8-103c5636f...@samsung.com/
> 
> Care to apply the change he suggested to see if it fixes the issue for
> you. If it does, Marek, can you make an official patch?
> 
> -- Steve

Right, same issue - same fix. Oh well, at least I got a bit more
familiar with the code.

--
⢋⡀⣀⠹
⠠⣶⡦⠀
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿
⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿
⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿
⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿

Re: linux-next: Tree for Aug 13

2019-08-13 Thread Vasily Gorbik

On Tue, Aug 13, 2019 at 02:41:55PM +0200, Vasily Gorbik wrote:
> On Tue, Aug 13, 2019 at 07:19:24PM +1000, Stephen Rothwell wrote:
> > Merging security/next-testing (a4848e06f9af Merge branch 'next-lockdown' 
> > into next-testing)
> > CONFLICT (content): Merge conflict in kernel/trace/trace_kprobe.c
> > CONFLICT (content): Merge conflict in fs/tracefs/inode.c
> > Applying: early_security_init() needs a stub got !CONFIG_SECURITY
> 
> Hi all,
> 
> next-lockdown causes panic on s390 when doing:
> cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/id
> 
> [ 3972.384027] Unable to handle kernel pointer dereference in virtual kernel 
> address space
> [ 3972.384031] Failing address:  TEID: 0887
> [ 3972.384032] Fault in home space mode while using kernel ASCE.
> [ 3972.384033] AS:744cc007 R3:0001fffd0007 S:0001fffd6000 
> P:013d 
> [ 3972.384051] Oops: 0004 ilc:1 [#1] SMP 
> [ 3972.384053] Modules linked in: binfmt_misc(E) dm_crypt(E) lcs(E) ctcm(E) 
> fsm(E) algif_skcipher(E) af_alg(E) nfsv3(E) nfs_acl(E) nfs(E) lockd(E) 
> grace(E) sctp(E) quota_v2(E) quota_tree(E) ntfs(E) vfat(E) fat(E) overlay(E) 
> loop(E) dm_service_time(E) kvm(E) xt_CHECKSUM(E) xt_MASQUERADE(E) 
> xt_tcpudp(E) ip6t_rpfilter(E) ip6t_REJECT(E) nf_reject_ipv6(E) ipt_REJECT(E) 
> nf_reject_ipv4(E) xt_conntrack(E) ip6table_nat(E) ip6table_mangle(E) 
> ip6table_raw(E) tun(E) ip6table_security(E) bridge(E) iptable_nat(E) 
> nf_nat(E) stp(E) llc(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) 
> nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) ip_set(E) nfnetlink(E) 
> ip6table_filter(E) ip6_tables(E) iptable_filter(E) ip_tables(E) x_tables(E) 
> sunrpc(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) 
> scsi_dh_alua(E) s390_trng(E) ghash_s390(E) prng(E) aes_s390(E) des_s390(E) 
> des_generic(E) sha512_s390(E) sha1_s390(E) vfio_ccw(E) vfio_mdev(E) mdev(E) 
> vfio_iommu_type1(E) vfio(E) eadm_sch(E) sch_fq_codel(E)
> [ 3972.384076]  sha256_s390(E) sha_common(E) pkey(E) zcrypt(E) rng_core(E) 
> autofs4(E) [last unloaded: dummy_del_mod]
> [ 3972.384084] CPU: 17 PID: 45118 Comm: psvc-ioctl-bpf1 Tainted: G   
> OE 5.3.0-20190813.rc4.git0.8e72ac275c63.301.fc30.s390x+next #1
> [ 3972.384086] Hardware name: IBM 3906 M04 704 (LPAR)
> [ 3972.384087] Krnl PSW : 0704c0018000  (0x0)
> [ 3972.384090]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 
> RI:0 EA:3
> [ 3972.384103] Krnl GPRS: 03e004c0fb90  0001f912abf0 
> 000197b36800
> [ 3972.384104]000197b36810 0001 0001 
> 000197b36810
> [ 3972.384105]736ae3a0 0001 0001f912abf0 
> 000197b36800
> [ 3972.384106]00013aff 73c625a8 734a1486 
> 03e004c0fbc8
> [ 3972.384110] Krnl Code:>: illegal 
>   0002: illegal 
>   0004: illegal 
>   0006: illegal 
>   0008: illegal 
>   000a: illegal 
>   000c: illegal 
>   000e: illegal 
> [ 3972.384116] Call Trace:
> [ 3972.384122] ([<734a1486>] do_dentry_open+0x206/0x3c0)
> [ 3972.384125]  [<734b8c1e>] do_last+0x16e/0x918 
> [ 3972.384126]  [<734b944e>] path_openat+0x86/0x2b8 
> [ 3972.384128]  [<734baa64>] do_filp_open+0x7c/0xf8 
> [ 3972.384129]  [<734a3484>] do_sys_open+0x18c/0x258 
> [ 3972.384134]  [<73c457cc>] system_call+0xd8/0x2c8 
> [ 3972.384135] Last Breaking-Event-Address:
> [ 3972.384139]  [<736ae3fa>] default_open_file+0x5a/0x78
> [ 3972.384141] Kernel panic - not syncing: Fatal exception: panic_on_oops
> 
> Which correspond to:
> fs/tracefs/inode.c:46
> static int default_open_file(struct inode *inode, struct file *filp)
>  45 real_fops = dentry->d_fsdata;
>  46 return real_fops->open(inode, filp);
> 
> Commit which introduces the problem:
> commit 757ff7244358406dd16a7f5f623ca40ed27c603c
> Author: Matthew Garrett 
> AuthorDate: Wed Aug 7 17:07:19 2019 -0700
> Commit: James Morris 
> CommitDate: Fri Aug 9 22:23:58 2019 -0700
> 
> tracefs: Restrict tracefs when the kernel is locked down
> 
> Tracefs may release more information about the kernel than desirable, so
> restrict it when the kernel is locked down in confidentiality mode by
> preventing open().
> 
> Signed-off-by: Matthew Garrett 
> Reviewed-by: Steven Rostedt (VMware) 
> Signed-off-by: James Morris 
> ---
>  fs/tracefs/inode.c   | 40 +++-
>

Re: linux-next: Tree for Aug 13

2019-08-13 Thread Steven Rostedt



This looks related to what Marek posted.

  
https://lore.kernel.org/linux-security-module/3028ed35-3b6d-459f-f3c8-103c5636f...@samsung.com/

Care to apply the change he suggested to see if it fixes the issue for
you. If it does, Marek, can you make an official patch?

-- Steve


On Tue, 13 Aug 2019 14:41:55 +0200
Vasily Gorbik  wrote:

> On Tue, Aug 13, 2019 at 07:19:24PM +1000, Stephen Rothwell wrote:
> > Merging security/next-testing (a4848e06f9af Merge branch 'next-lockdown' 
> > into next-testing)
> > CONFLICT (content): Merge conflict in kernel/trace/trace_kprobe.c
> > CONFLICT (content): Merge conflict in fs/tracefs/inode.c
> > Applying: early_security_init() needs a stub got !CONFIG_SECURITY  
> 
> Hi all,
> 
> next-lockdown causes panic on s390 when doing:
> cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/id
> 
> [ 3972.384027] Unable to handle kernel pointer dereference in virtual kernel 
> address space
> [ 3972.384031] Failing address:  TEID: 0887
> [ 3972.384032] Fault in home space mode while using kernel ASCE.
> [ 3972.384033] AS:744cc007 R3:0001fffd0007 S:0001fffd6000 
> P:013d 
> [ 3972.384051] Oops: 0004 ilc:1 [#1] SMP 
> [ 3972.384053] Modules linked in: binfmt_misc(E) dm_crypt(E) lcs(E) ctcm(E) 
> fsm(E) algif_skcipher(E) af_alg(E) nfsv3(E) nfs_acl(E) nfs(E) lockd(E) 
> grace(E) sctp(E) quota_v2(E) quota_tree(E) ntfs(E) vfat(E) fat(E) overlay(E) 
> loop(E) dm_service_time(E) kvm(E) xt_CHECKSUM(E) xt_MASQUERADE(E) 
> xt_tcpudp(E) ip6t_rpfilter(E) ip6t_REJECT(E) nf_reject_ipv6(E) ipt_REJECT(E) 
> nf_reject_ipv4(E) xt_conntrack(E) ip6table_nat(E) ip6table_mangle(E) 
> ip6table_raw(E) tun(E) ip6table_security(E) bridge(E) iptable_nat(E) 
> nf_nat(E) stp(E) llc(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) 
> nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) ip_set(E) nfnetlink(E) 
> ip6table_filter(E) ip6_tables(E) iptable_filter(E) ip_tables(E) x_tables(E) 
> sunrpc(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) 
> scsi_dh_alua(E) s390_trng(E) ghash_s390(E) prng(E) aes_s390(E) des_s390(E) 
> des_generic(E) sha512_s390(E) sha1_s390(E) vfio_ccw(E) vfio_mdev(E) mdev(E) 
> vfio_iommu_type1(E) vfio(E) eadm_sch(E) sch_f
 q_codel(E)
> [ 3972.384076]  sha256_s390(E) sha_common(E) pkey(E) zcrypt(E) rng_core(E) 
> autofs4(E) [last unloaded: dummy_del_mod]
> [ 3972.384084] CPU: 17 PID: 45118 Comm: psvc-ioctl-bpf1 Tainted: G   
> OE 5.3.0-20190813.rc4.git0.8e72ac275c63.301.fc30.s390x+next #1
> [ 3972.384086] Hardware name: IBM 3906 M04 704 (LPAR)
> [ 3972.384087] Krnl PSW : 0704c0018000  (0x0)
> [ 3972.384090]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 
> RI:0 EA:3
> [ 3972.384103] Krnl GPRS: 03e004c0fb90  0001f912abf0 
> 000197b36800
> [ 3972.384104]000197b36810 0001 0001 
> 000197b36810
> [ 3972.384105]736ae3a0 0001 0001f912abf0 
> 000197b36800
> [ 3972.384106]00013aff 73c625a8 734a1486 
> 03e004c0fbc8
> [ 3972.384110] Krnl Code:>: illegal 
>   0002: illegal 
>   0004: illegal 
>   0006: illegal 
>   0008: illegal 
>   000a: illegal 
>   000c: illegal 
>   000e: illegal 
> [ 3972.384116] Call Trace:
> [ 3972.384122] ([<734a1486>] do_dentry_open+0x206/0x3c0)
> [ 3972.384125]  [<734b8c1e>] do_last+0x16e/0x918 
> [ 3972.384126]  [<734b944e>] path_openat+0x86/0x2b8 
> [ 3972.384128]  [<734baa64>] do_filp_open+0x7c/0xf8 
> [ 3972.384129]  [<734a3484>] do_sys_open+0x18c/0x258 
> [ 3972.384134]  [<73c457cc>] system_call+0xd8/0x2c8 
> [ 3972.384135] Last Breaking-Event-Address:
> [ 3972.384139]  [<736ae3fa>] default_open_file+0x5a/0x78
> [ 3972.384141] Kernel panic - not syncing: Fatal exception: panic_on_oops
> 
> Which correspond to:
> fs/tracefs/inode.c:46
> static int default_open_file(struct inode *inode, struct file *filp)
>  45 real_fops = dentry->d_fsdata;
>  46 return real_fops->open(inode, filp);
> 
> Commit which introduces the problem:
> commit 757ff7244358406dd16a7f5f623ca40ed27c603c
> Author: Matthew Garrett 
> AuthorDate: Wed Aug 7 17:07:19 2019 -0700
> Commit: James Morris 
> CommitDate: Fri Aug 9 22:23:58 2019 -0700
> 
> tracefs: Restrict tracefs when the kernel is locked down
> 
> Tracefs may release more information about the kernel than desirable, so
> restrict it when the kernel

Re: linux-next: Tree for Aug 13

2019-08-13 Thread Vasily Gorbik

On Tue, Aug 13, 2019 at 07:19:24PM +1000, Stephen Rothwell wrote:
> Merging security/next-testing (a4848e06f9af Merge branch 'next-lockdown' into 
> next-testing)
> CONFLICT (content): Merge conflict in kernel/trace/trace_kprobe.c
> CONFLICT (content): Merge conflict in fs/tracefs/inode.c
> Applying: early_security_init() needs a stub got !CONFIG_SECURITY

Hi all,

next-lockdown causes panic on s390 when doing:
cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/id

[ 3972.384027] Unable to handle kernel pointer dereference in virtual kernel 
address space
[ 3972.384031] Failing address:  TEID: 0887
[ 3972.384032] Fault in home space mode while using kernel ASCE.
[ 3972.384033] AS:744cc007 R3:0001fffd0007 S:0001fffd6000 
P:013d 
[ 3972.384051] Oops: 0004 ilc:1 [#1] SMP 
[ 3972.384053] Modules linked in: binfmt_misc(E) dm_crypt(E) lcs(E) ctcm(E) 
fsm(E) algif_skcipher(E) af_alg(E) nfsv3(E) nfs_acl(E) nfs(E) lockd(E) grace(E) 
sctp(E) quota_v2(E) quota_tree(E) ntfs(E) vfat(E) fat(E) overlay(E) loop(E) 
dm_service_time(E) kvm(E) xt_CHECKSUM(E) xt_MASQUERADE(E) xt_tcpudp(E) 
ip6t_rpfilter(E) ip6t_REJECT(E) nf_reject_ipv6(E) ipt_REJECT(E) 
nf_reject_ipv4(E) xt_conntrack(E) ip6table_nat(E) ip6table_mangle(E) 
ip6table_raw(E) tun(E) ip6table_security(E) bridge(E) iptable_nat(E) nf_nat(E) 
stp(E) llc(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) 
nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) ip_set(E) nfnetlink(E) 
ip6table_filter(E) ip6_tables(E) iptable_filter(E) ip_tables(E) x_tables(E) 
sunrpc(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) 
scsi_dh_alua(E) s390_trng(E) ghash_s390(E) prng(E) aes_s390(E) des_s390(E) 
des_generic(E) sha512_s390(E) sha1_s390(E) vfio_ccw(E) vfio_mdev(E) mdev(E) 
vfio_iommu_type1(E) vfio(E) eadm_sch(E) sch_fq_codel(E)
[ 3972.384076]  sha256_s390(E) sha_common(E) pkey(E) zcrypt(E) rng_core(E) 
autofs4(E) [last unloaded: dummy_del_mod]
[ 3972.384084] CPU: 17 PID: 45118 Comm: psvc-ioctl-bpf1 Tainted: G   OE 
5.3.0-20190813.rc4.git0.8e72ac275c63.301.fc30.s390x+next #1
[ 3972.384086] Hardware name: IBM 3906 M04 704 (LPAR)
[ 3972.384087] Krnl PSW : 0704c0018000  (0x0)
[ 3972.384090]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 
RI:0 EA:3
[ 3972.384103] Krnl GPRS: 03e004c0fb90  0001f912abf0 
000197b36800
[ 3972.384104]000197b36810 0001 0001 
000197b36810
[ 3972.384105]736ae3a0 0001 0001f912abf0 
000197b36800
[ 3972.384106]00013aff 73c625a8 734a1486 
03e004c0fbc8
[ 3972.384110] Krnl Code:>: illegal 
  0002: illegal 
  0004: illegal 
  0006: illegal 
  0008: illegal 
  000a: illegal 
  000c: illegal 
  000e: illegal 
[ 3972.384116] Call Trace:
[ 3972.384122] ([<734a1486>] do_dentry_open+0x206/0x3c0)
[ 3972.384125]  [<734b8c1e>] do_last+0x16e/0x918 
[ 3972.384126]  [<734b944e>] path_openat+0x86/0x2b8 
[ 3972.384128]  [<734baa64>] do_filp_open+0x7c/0xf8 
[ 3972.384129]  [<734a3484>] do_sys_open+0x18c/0x258 
[ 3972.384134]  [<73c457cc>] system_call+0xd8/0x2c8 
[ 3972.384135] Last Breaking-Event-Address:
[ 3972.384139]  [<736ae3fa>] default_open_file+0x5a/0x78
[ 3972.384141] Kernel panic - not syncing: Fatal exception: panic_on_oops

Which correspond to:
fs/tracefs/inode.c:46
static int default_open_file(struct inode *inode, struct file *filp)
 45 real_fops = dentry->d_fsdata;
 46 return real_fops->open(inode, filp);

Commit which introduces the problem:
commit 757ff7244358406dd16a7f5f623ca40ed27c603c
Author: Matthew Garrett 
AuthorDate: Wed Aug 7 17:07:19 2019 -0700
Commit: James Morris 
CommitDate: Fri Aug 9 22:23:58 2019 -0700

tracefs: Restrict tracefs when the kernel is locked down

Tracefs may release more information about the kernel than desirable, so
restrict it when the kernel is locked down in confidentiality mode by
preventing open().

Signed-off-by: Matthew Garrett 
Reviewed-by: Steven Rostedt (VMware) 
Signed-off-by: James Morris 
---
 fs/tracefs/inode.c   | 40 +++-
 include/linux/security.h |  1 +
 security/lockdown/lockdown.c |  1 +
 3 files changed, 41 insertions(+), 1 deletion(-)

Using default s390 config, where
# CONFIG_SECURITY_LOCKDOWN_LSM is not set

-- 
⢋⡀⣀⠹
⠠⣶⡦⠀
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿

Re: linux-next: Tree for Aug 13

2018-08-13 Thread Guenter Roeck

On Mon, Aug 13, 2018 at 07:32:01PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20180810:
> 
> The ida tree lost its build failure.
> 
> The akpm-current tree gained conflicts against the block tree and a
> build failure due to an interaction with the userns tree for which I
> applied a merge fix patch.
> 
> Non-merge commits (relative to Linus' tree): 11957
>  10727 files changed, 510277 insertions(+), 209635 deletions(-)
> 
> 
> 

Complete report, given this is probably the base of v4.19-rc1.

Guenter

---

Build results:
total: 134 pass: 127 fail: 7
Failed builds: 
m68k:allmodconfig 
powerpc:ppc6xx_defconfig
s390:allmodconfig 
sparc32:allmodconfig 
unicore32:defconfig 
unicore32:allnoconfig 
xtensa:allmodconfig 
Qemu test results:
total: 297 pass: 297 fail: 0

---
m68k:allmodconfig, powerpc:ppc6xx_defconfig, xtensa:allmodconfig:

drivers/net/virtio_net.c: In function 'virtnet_set_affinity':
drivers/net/virtio_net.c:1916:10: error: implicit declaration of function 
'cpumask_next_wrap'

s390:allmodconfig:

drivers/net/ethernet/microchip/lan743x_ethtool.c:
In function 'lan743x_ethtool_get_ts_info':
drivers/net/ethernet/microchip/lan743x_ethtool.c:558:19: error:
'struct lan743x_ptp' has no member named 'ptp_clock'`

[multiple instances in several files]

---
sparc32:allmodconfig:

arch/sparc/kernel/head_32.o: In function `current_pc':
arch/sparc/kernel/.tmp_head_32.o:(.head.text+0x5040): relocation truncated to 
fit: R_SPARC_WDISP22 against `.init.text'
arch/sparc/kernel/head_32.o: In function `halt_notsup':
arch/sparc/kernel/.tmp_head_32.o:(.head.text+0x5100): relocation truncated to 
fit: R_SPARC_WDISP22 against `.init.text'
arch/sparc/kernel/head_32.o: In function `leon_init':
arch/sparc/kernel/.tmp_head_32.o:(.init.text+0xa4): relocation truncated to 
fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text 
section
in arch/sparc/kernel/trampoline_32.o
arch/sparc/kernel/process_32.o:(.fixup+0x4): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/process_32.o:(.fixup+0xc): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x0): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x8): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x10): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x18): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x20): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x28): additional relocation overflows 
omitted from the output

---
unicore32:defconfig, unicore32:allnoconfig:

In file included from include/linux/mm.h:17,
 from arch/unicore32/kernel/asm-offsets.c:17:
linux/mm_types.h:500: error: flexible array member in otherwise empty struct

[maybe due to gcc version 4.4.2, more recent toolchain not available]

==

Runtime warnings:

arm:smdkc210:exynos_defconfig:exynos4210-smdkv310:

[   10.857719] [ cut here ]
[   10.861967] WARNING: CPU: 0 PID: 82 at kernel/locking/lockdep.c:2876 
__irq_svc+0x8c/0xb0
[   10.862450] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
...
[   10.869031] [] (__irq_svc) from [] 
(s3c24xx_serial_tx_chars+0x1b8/0x204)
[   10.869369] [] (s3c24xx_serial_tx_chars) from [] 
(s3c64xx_serial_handle_irq+0x34/0x60)
[   10.869729] [] (s3c64xx_serial_handle_irq) from [] 
(__handle_irq_event_percpu+0x84/0x46c)
[   10.870093] [] (__handle_irq_event_percpu) from [] 
(handle_irq_event_percpu+0x2c/0x7c)
[   10.870446] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x38/0x5c)
[   10.870831] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xb8/0x16c)
[   10.871193] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x24/0x34)
[   10.871569] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x7c/0xec)
[   10.871879] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x58/0x9c)
[   10.872170] [] (gic_handle_irq) from [] 
(__irq_svc+0x70/0xb0)

---
sh:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 
ohci_init+0x194/0x2d0
...
Call trace:
 [<(ptrval)>] usb_add_hcd+0x1e8/0x6ec
 [<(ptrval)>] _dev_info+0x0/0x54
 [<(ptrval)>] arch_local_save_flags+0x0/0x8
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] ohci_hcd_sm501_drv_probe+0x114/0x2d8

[several associated instances]

WARNING: CPU: 0 PID: 1 at mm/slab.c:2666 cache_alloc_refill+0x8a/0x594
...
Call trace:
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] arch_local_save_flags+0x0/0x8
 [<(ptrval)>] kmem_cache_alloc+0x72/0xac
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>]

Re: linux-next: Tree for Aug 13

2018-08-13 Thread Guenter Roeck

On Mon, Aug 13, 2018 at 07:32:01PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20180810:
> 
> The ida tree lost its build failure.
> 
> The akpm-current tree gained conflicts against the block tree and a
> build failure due to an interaction with the userns tree for which I
> applied a merge fix patch.
> 
> Non-merge commits (relative to Linus' tree): 11957
>  10727 files changed, 510277 insertions(+), 209635 deletions(-)
> 
> 
> 

Complete report, given this is probably the base of v4.19-rc1.

Guenter

---

Build results:
total: 134 pass: 127 fail: 7
Failed builds: 
m68k:allmodconfig 
powerpc:ppc6xx_defconfig
s390:allmodconfig 
sparc32:allmodconfig 
unicore32:defconfig 
unicore32:allnoconfig 
xtensa:allmodconfig 
Qemu test results:
total: 297 pass: 297 fail: 0

---
m68k:allmodconfig, powerpc:ppc6xx_defconfig, xtensa:allmodconfig:

drivers/net/virtio_net.c: In function 'virtnet_set_affinity':
drivers/net/virtio_net.c:1916:10: error: implicit declaration of function 
'cpumask_next_wrap'

s390:allmodconfig:

drivers/net/ethernet/microchip/lan743x_ethtool.c:
In function 'lan743x_ethtool_get_ts_info':
drivers/net/ethernet/microchip/lan743x_ethtool.c:558:19: error:
'struct lan743x_ptp' has no member named 'ptp_clock'`

[multiple instances in several files]

---
sparc32:allmodconfig:

arch/sparc/kernel/head_32.o: In function `current_pc':
arch/sparc/kernel/.tmp_head_32.o:(.head.text+0x5040): relocation truncated to 
fit: R_SPARC_WDISP22 against `.init.text'
arch/sparc/kernel/head_32.o: In function `halt_notsup':
arch/sparc/kernel/.tmp_head_32.o:(.head.text+0x5100): relocation truncated to 
fit: R_SPARC_WDISP22 against `.init.text'
arch/sparc/kernel/head_32.o: In function `leon_init':
arch/sparc/kernel/.tmp_head_32.o:(.init.text+0xa4): relocation truncated to 
fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text 
section
in arch/sparc/kernel/trampoline_32.o
arch/sparc/kernel/process_32.o:(.fixup+0x4): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/process_32.o:(.fixup+0xc): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x0): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x8): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x10): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x18): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x20): relocation truncated to fit: 
R_SPARC_WDISP22 against `.text'
arch/sparc/kernel/signal_32.o:(.fixup+0x28): additional relocation overflows 
omitted from the output

---
unicore32:defconfig, unicore32:allnoconfig:

In file included from include/linux/mm.h:17,
 from arch/unicore32/kernel/asm-offsets.c:17:
linux/mm_types.h:500: error: flexible array member in otherwise empty struct

[maybe due to gcc version 4.4.2, more recent toolchain not available]

==

Runtime warnings:

arm:smdkc210:exynos_defconfig:exynos4210-smdkv310:

[   10.857719] [ cut here ]
[   10.861967] WARNING: CPU: 0 PID: 82 at kernel/locking/lockdep.c:2876 
__irq_svc+0x8c/0xb0
[   10.862450] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
...
[   10.869031] [] (__irq_svc) from [] 
(s3c24xx_serial_tx_chars+0x1b8/0x204)
[   10.869369] [] (s3c24xx_serial_tx_chars) from [] 
(s3c64xx_serial_handle_irq+0x34/0x60)
[   10.869729] [] (s3c64xx_serial_handle_irq) from [] 
(__handle_irq_event_percpu+0x84/0x46c)
[   10.870093] [] (__handle_irq_event_percpu) from [] 
(handle_irq_event_percpu+0x2c/0x7c)
[   10.870446] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x38/0x5c)
[   10.870831] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xb8/0x16c)
[   10.871193] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x24/0x34)
[   10.871569] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x7c/0xec)
[   10.871879] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x58/0x9c)
[   10.872170] [] (gic_handle_irq) from [] 
(__irq_svc+0x70/0xb0)

---
sh:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 
ohci_init+0x194/0x2d0
...
Call trace:
 [<(ptrval)>] usb_add_hcd+0x1e8/0x6ec
 [<(ptrval)>] _dev_info+0x0/0x54
 [<(ptrval)>] arch_local_save_flags+0x0/0x8
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] ohci_hcd_sm501_drv_probe+0x114/0x2d8

[several associated instances]

WARNING: CPU: 0 PID: 1 at mm/slab.c:2666 cache_alloc_refill+0x8a/0x594
...
Call trace:
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] arch_local_save_flags+0x0/0x8
 [<(ptrval)>] kmem_cache_alloc+0x72/0xac
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>]

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 10:33 PM, Sedat Dilek  wrote:
> On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek  wrote:
>> On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson  
>> wrote:
>>> On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson  
 wrote:
 > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
 >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson 
 >>  wrote:
 >> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
 >> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson 
 >> >>  wrote:
 >> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
 >> >> >> Files attached.
 >> >> >
 >> >> > Can you also please attach a full dmesg so I can check for anything
 >> >> > unusual?
 >> >> >
 >> >
 >> > Nothing scarred me on a couple of read throughs.
 >> >
 >> > What happens if you try:
 >> >
 >> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 >> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
 >> > index 112c5e1..9828d9b 100644
 >> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 >> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 >> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device 
 >> > *dev, u32 size)
 >> > return NULL;
 >> >
 >> > ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
 >> > -4096, DRM_MM_SEARCH_DEFAULT);
 >> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
 >> > if (ret) {
 >> > kfree(stolen);
 >> > return NULL;
 >> >
 >> > --
 >>
 >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
 >> from the top).
 >> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
 >> So-to-say 3/4 "blind".
 >
 > That implies that the scanout is always reading from the base of stolen.
 > Can you grab intel_reg_dumper so that I can check what values the
 > transcoder is set to?
 >
 > At the moment, I am guessing that the display never sees the updated
 > surface offset and so persists with the value programmed by the BIOS -
 > which will be 0 and set to the base of stolen memory in the GTT. A
 > drm.debug=6 dmesg would help here as well.
 >
 > If you forced a mode change, I think that too would restore the output.

 With which kernel? Vanilla next-20130813? With any of your patches?
>>>
>>> Any but the working one ;-)
>>
>> Damn Gmail, they switched again the UI, f***.
>>
>> This is d-i-n with Revert "drm/i915: Allocate LLC ringbuffers from
>> stolen" <--- "working one" (no screen corruptions).
>>
>> - Sedat -
>
> Vanilla next-20130813 after 1st login and logout-unity2d-plus-relogin-lightdm.
> The diff might be interesting as the 2nd login makes the issue go away.
>

intel_reg_dumper output attached.

- Sedat -
PGETBL_CTL: 0x
   GEN6_INSTDONE_1: 0xfffe
   GEN6_INSTDONE_2: 0x
  CPU_VGACNTRL: 0x8000 (disabled)
DIGITAL_PORT_HOTPLUG_CNTRL: 0x
 RR_HW_CTL: 0x (low 0, high 0)
FDI_PLL_BIOS_0: 0x
FDI_PLL_BIOS_1: 0x
FDI_PLL_BIOS_2: 0x
   DISPLAY_PORT_PLL_BIOS_0: 0x
   DISPLAY_PORT_PLL_BIOS_1: 0x
   DISPLAY_PORT_PLL_BIOS_2: 0x
  FDI_PLL_FREQ_CTL: 0x
 PIPEACONF: 0xc000 (enabled, active, pf-pd, rotate 0, 
8bpc)
  HTOTAL_A: 0x05cd0555 (1366 active, 1486 total)
  HBLANK_A: 0x05cd0555 (1366 start, 1486 end)
   HSYNC_A: 0x05a50585 (1414 start, 1446 end)
  VTOTAL_A: 0x031702ff (768 active, 792 total)
  VBLANK_A: 0x031702ff (768 start, 792 end)
   VSYNC_A: 0x03060301 (770 start, 775 end)
  VSYNCSHIFT_A: 0x
  PIPEASRC: 0x055502ff (1366, 768)
 PIPEA_DATA_M1: 0x7e32468a (TU 64, val 0x32468a 3294858)
 PIPEA_DATA_N1: 0x0040 (val 0x40 4194304)
 PIPEA_DATA_M2: 0x (TU 1, val 0x0 0)
 PIPEA_DATA_N2: 0x (val 0x0 0)
 PIPEA_LINK_M1: 0x00021845 (val 0x21845 137285)
 PIPEA_LINK_N1: 0x0008 (val 0x8 524288)
 PIPEA_LINK_M2: 0x (val 0x0 0)
 PIPEA_LINK_N2: 0x (val 0x0 0)
  DSPACNTR: 0xd8004400 (enabled)
  DSPABASE: 0x
DSPASTRIDE: 0x1600 (88)
  DSPASURF: 0x0047a000
   DSPATILEOFF: 0x (0, 0)
 PIPEBCONF: 0x (disabled, inactive, pf-pd, rotate 
0, 8bpc)

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson  
> wrote:
> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson  
> >> wrote:
> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> >> >> Files attached.
> >> >
> >> > Can you also please attach a full dmesg so I can check for anything
> >> > unusual?
> >> >
> >
> > Nothing scarred me on a couple of read throughs.
> >
> > What happens if you try:
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index 112c5e1..9828d9b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, 
> > u32 size)
> > return NULL;
> >
> > ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
> > -4096, DRM_MM_SEARCH_DEFAULT);
> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
> > if (ret) {
> > kfree(stolen);
> > return NULL;
> >
> > --
> 
> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
> from the top).
> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
> So-to-say 3/4 "blind".

That implies that the scanout is always reading from the base of stolen.
Can you grab intel_reg_dumper so that I can check what values the
transcoder is set to?

At the moment, I am guessing that the display never sees the updated
surface offset and so persists with the value programmed by the BIOS -
which will be 0 and set to the base of stolen memory in the GTT. A
drm.debug=6 dmesg would help here as well.

If you forced a mode change, I think that too would restore the output.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson  
> wrote:
> > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
> >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson  
> >> wrote:
> >> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> >> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson 
> >> >>  wrote:
> >> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> >> >> >> Files attached.
> >> >> >
> >> >> > Can you also please attach a full dmesg so I can check for anything
> >> >> > unusual?
> >> >> >
> >> >
> >> > Nothing scarred me on a couple of read throughs.
> >> >
> >> > What happens if you try:
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> >> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> > index 112c5e1..9828d9b 100644
> >> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device 
> >> > *dev, u32 size)
> >> > return NULL;
> >> >
> >> > ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
> >> > -4096, DRM_MM_SEARCH_DEFAULT);
> >> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
> >> > if (ret) {
> >> > kfree(stolen);
> >> > return NULL;
> >> >
> >> > --
> >>
> >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
> >> from the top).
> >> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
> >> So-to-say 3/4 "blind".
> >
> > That implies that the scanout is always reading from the base of stolen.
> > Can you grab intel_reg_dumper so that I can check what values the
> > transcoder is set to?
> >
> > At the moment, I am guessing that the display never sees the updated
> > surface offset and so persists with the value programmed by the BIOS -
> > which will be 0 and set to the base of stolen memory in the GTT. A
> > drm.debug=6 dmesg would help here as well.
> >
> > If you forced a mode change, I think that too would restore the output.
> 
> With which kernel? Vanilla next-20130813? With any of your patches?

Any but the working one ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson  wrote:
> On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson  
>> wrote:
>> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson  
>> >> wrote:
>> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> >> Files attached.
>> >> >
>> >> > Can you also please attach a full dmesg so I can check for anything
>> >> > unusual?
>> >> >
>> >
>> > Nothing scarred me on a couple of read throughs.
>> >
>> > What happens if you try:
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
>> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > index 112c5e1..9828d9b 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, 
>> > u32 size)
>> > return NULL;
>> >
>> > ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
>> > -4096, DRM_MM_SEARCH_DEFAULT);
>> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
>> > if (ret) {
>> > kfree(stolen);
>> > return NULL;
>> >
>> > --
>>
>> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>> from the top).
>> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>> So-to-say 3/4 "blind".
>
> That implies that the scanout is always reading from the base of stolen.
> Can you grab intel_reg_dumper so that I can check what values the
> transcoder is set to?
>
> At the moment, I am guessing that the display never sees the updated
> surface offset and so persists with the value programmed by the BIOS -
> which will be 0 and set to the base of stolen memory in the GTT. A
> drm.debug=6 dmesg would help here as well.
>
> If you forced a mode change, I think that too would restore the output.

With which kernel? Vanilla next-20130813? With any of your patches?

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson  wrote:
> On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson  
>> wrote:
>> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> Files attached.
>> >
>> > Can you also please attach a full dmesg so I can check for anything
>> > unusual?
>> >
>
> Nothing scarred me on a couple of read throughs.
>
> What happens if you try:
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 112c5e1..9828d9b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 
> size)
> return NULL;
>
> ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
> -4096, DRM_MM_SEARCH_DEFAULT);
> +1024*1024, DRM_MM_SEARCH_DEFAULT);
> if (ret) {
> kfree(stolen);
> return NULL;
>
> --

Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
from the top).
On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
So-to-say 3/4 "blind".

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson  
> wrote:
> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> >> Files attached.
> >
> > Can you also please attach a full dmesg so I can check for anything
> > unusual?
> >

Nothing scarred me on a couple of read throughs.

What happens if you try:

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 112c5e1..9828d9b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 
size)
return NULL;
 
ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
-4096, DRM_MM_SEARCH_DEFAULT);
+1024*1024, DRM_MM_SEARCH_DEFAULT);
if (ret) {
kfree(stolen);
return NULL;

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 (xfs)

2013-08-13 Thread Eric Sandeen

On 8/13/13 11:59 AM, Randy Dunlap wrote:
> On 08/13/13 01:28, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20130812:
>>
> 
> on i386:
> 
> fs/built-in.o: In function `xfs_log_calc_minimum_size':
> (.text+0x1797a9): undefined reference to `__udivdi3'
> 
> 

See:

[PATCH] xfs: call roundup_64() to calculate the min_logblks

on the xfs list:

From: Jie Liu 

Replace roundup() with roundup_64() as we calculate min_logblks
with 64-bit divisions.  Hence, call roundup() will cause the
following error while compiling a 32-bit kernel:

fs/built-in.o: In function `xfs_log_calc_minimum_size':
fs/xfs/xfs_log_rlimit.c:140: undefined reference to `__udivdi3'

Reported-by: Fengguang Wu 
Cc: Dave Chinner 
Signed-off-by: Jie Liu 
---
 fs/xfs/xfs_log_rlimit.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_log_rlimit.c b/fs/xfs/xfs_log_rlimit.c
index 6b17ef4..bbcec0b 100644
--- a/fs/xfs/xfs_log_rlimit.c
+++ b/fs/xfs/xfs_log_rlimit.c
@@ -136,10 +136,12 @@ xfs_log_calc_minimum_size(
 * Also, the log size should be a multiple of the log stripe unit, round
 * it up to lsunit boundary if lsunit is specified.
 */
-   if (lsunit)
-   min_logblks = roundup(BTOBB(max_logres), lsunit) + 2 * lsunit;
-   else
+   if (lsunit) {
+   min_logblks = roundup_64(BTOBB(max_logres), lsunit) +
+ 2 * lsunit;
+   } else
min_logblks = BTOBB(max_logres) + 2 * BBSIZE;
min_logblks *= XFS_MIN_LOG_FACTOR;
+
return XFS_BB_TO_FSB(mp, min_logblks);
 }
-- 

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> Files attached.

Can you also please attach a full dmesg so I can check for anything
unusual?

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 7:13 PM, Chris Wilson  wrote:
> On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek  wrote:
>> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson  
>> > wrote:
>> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
>> >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek  
>> >>> wrote:
>> >>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
>> >>> >
>> >>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
>> >>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829
>> >>> > Author: Chris Wilson 
>> >>> > Date:   Thu Aug 8 14:41:07 2013 +0100
>> >>> >
>> >>> > drm/i915: Allocate LLC ringbuffers from stolen
>> >>> >
>> >>> > As stolen objects now behave identically (wrt to default LLC 
>> >>> > cacheing)
>> >>> > as their normal system counterparts, we no longer have to 
>> >>> > differentiate
>> >>> > our usage for ringbuffers. So allocate them from stolen on SNB+ as 
>> >>> > well.
>> >>> >
>> >>> > Signed-off-by: Chris Wilson 
>> >>> > Reviewed-by: Ville Syrjälä 
>> >>> > Signed-off-by: Daniel Vetter 
>> >>> >
>> >>> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
>> >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
>> >>> >
>> >>> > See also attached files!
>> >>> >
>> >>>
>> >>> With the attached revert-patch my system is OK (with my customized X 
>> >>> stack).
>> >>
>> >> No indication of a GPU hang? I'm puzzled as to how this ends up with the
>> >> scanout being misread.
>> >>
>> >> cat /sys/kernel/debug/dri/0/i915_gem_stolen
>> >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
>> >>
>> >> would be interesting.
>
>> Attached both outputs with GOOD and BAD (BROKEN) kernel.
>
> ggtt offset is the same for both setups, the only difference between the
> two is the location of fbcon in stolen memory.
>
> Can you please attach the output of intel_reg_dumper for good/bad? It's
> a long shot...
>
> Speaking of long shots, try this (slightly different to the earlier patch):
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a21f935..37ad772 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
> BUG();
> }
>
> +   if (obj->stolen && INTEL_INFO(dev)->gen >= 6)
> +   alignment = 256 * 1024;
> +
> /* Note that the w/a also requires 64 PTE of padding following the
>  * bo. We currently fill all unused PTE with the shadow page and so
>  * we should always have valid PTE following the scanout preventing
>
>
> --

Files attached.

- Sedat -
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 88010c54fe40: p g 
4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 
0008, size: 00408000) (stolen: 0006) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 88010c54fcc0: pXg  
   5120KiB 36 02 -591 -591 0 uncached dirty (name: 3) (pinned x 1) (display) 
(fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring)
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073fca200: p g 
4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 
0008, size: 00408000) (stolen: ) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880118928b40: pXg  
   5120KiB 36 02 -12 -12 0 uncached dirty (name: 3) (pinned x 1) (display) 
(fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring)
Stolen:
   880072c39c80: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable)
   880072c39800: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable)
   880072c39500: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable)
   88010c54fe40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 
1) (display) (ggtt offset: 0008, size: 00408000) (stolen: 0006) (p 
mappable)
Total 4 objects, 4620288 bytes, 4620288 GTT size
Stolen:
   880073fca200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 
1) (display) (ggtt offset: 0008, size: 00408000) (stolen: ) (p 
mappable)
Total 1 objects, 4227072 bytes, 4227072 GTT size

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek  wrote:
> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson  
> > wrote:
> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek  
> >>> wrote:
> >>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
> >>> >
> >>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
> >>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829
> >>> > Author: Chris Wilson 
> >>> > Date:   Thu Aug 8 14:41:07 2013 +0100
> >>> >
> >>> > drm/i915: Allocate LLC ringbuffers from stolen
> >>> >
> >>> > As stolen objects now behave identically (wrt to default LLC 
> >>> > cacheing)
> >>> > as their normal system counterparts, we no longer have to 
> >>> > differentiate
> >>> > our usage for ringbuffers. So allocate them from stolen on SNB+ as 
> >>> > well.
> >>> >
> >>> > Signed-off-by: Chris Wilson 
> >>> > Reviewed-by: Ville Syrjälä 
> >>> > Signed-off-by: Daniel Vetter 
> >>> >
> >>> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
> >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
> >>> >
> >>> > See also attached files!
> >>> >
> >>>
> >>> With the attached revert-patch my system is OK (with my customized X 
> >>> stack).
> >>
> >> No indication of a GPU hang? I'm puzzled as to how this ends up with the
> >> scanout being misread.
> >>
> >> cat /sys/kernel/debug/dri/0/i915_gem_stolen
> >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
> >>
> >> would be interesting.

> Attached both outputs with GOOD and BAD (BROKEN) kernel.

ggtt offset is the same for both setups, the only difference between the
two is the location of fbcon in stolen memory.

Can you please attach the output of intel_reg_dumper for good/bad? It's
a long shot...

Speaking of long shots, try this (slightly different to the earlier patch):

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a21f935..37ad772 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
BUG();
}
 
+   if (obj->stolen && INTEL_INFO(dev)->gen >= 6)
+   alignment = 256 * 1024;
+
/* Note that the w/a also requires 64 PTE of padding following the
 * bo. We currently fill all unused PTE with the shadow page and so
 * we should always have valid PTE following the scanout preventing


-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek  wrote:
> On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson  
> wrote:
>> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
>>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek  wrote:
>>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
>>> >
>>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
>>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829
>>> > Author: Chris Wilson 
>>> > Date:   Thu Aug 8 14:41:07 2013 +0100
>>> >
>>> > drm/i915: Allocate LLC ringbuffers from stolen
>>> >
>>> > As stolen objects now behave identically (wrt to default LLC cacheing)
>>> > as their normal system counterparts, we no longer have to 
>>> > differentiate
>>> > our usage for ringbuffers. So allocate them from stolen on SNB+ as 
>>> > well.
>>> >
>>> > Signed-off-by: Chris Wilson 
>>> > Reviewed-by: Ville Syrjälä 
>>> > Signed-off-by: Daniel Vetter 
>>> >
>>> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
>>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
>>> >
>>> > See also attached files!
>>> >
>>>
>>> With the attached revert-patch my system is OK (with my customized X stack).
>>
>> No indication of a GPU hang? I'm puzzled as to how this ends up with the
>> scanout being misread.
>>
>> cat /sys/kernel/debug/dri/0/i915_gem_stolen
>> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
>>
>> would be interesting.
>
> With revert-patch applied:
>
> $ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen
> Stolen:
>88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1)
> (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
> (stolen: ) (p mappable)
> Total 1 objects, 4227072 bytes, 4227072 GTT size
>
> $ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
> fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj
> 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1)
> (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
> (stolen: ) (p mappable)
> user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj
> 88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty
> (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000,
> size: 0050) (p mappable) (blitter ring)
>

Attached both outputs with GOOD and BAD (BROKEN) kernel.

- Sedat -
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880074492e40: p g 
4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 
00072000, size: 00408000) (stolen: ) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880074492840: pXg  
   5120KiB 36 02 158126 158126 0 uncached dirty (name: 3) (pinned x 1) 
(display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) 
(blitter ring)
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073995200: p g 
4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 
00072000, size: 00408000) (stolen: 0006) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 8800736d8e00: pXg  
   5120KiB 36 02 -737 -737 0 uncached dirty (name: 3) (pinned x 1) (display) 
(fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring)
Stolen:
   880074492e40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 
1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p 
mappable)
Total 1 objects, 4227072 bytes, 4227072 GTT size
Stolen:
   880073995c80: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable)
   880073995800: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable)
   880073995500: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable)
   880073995200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 
1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 0006) (p 
mappable)
Total 4 objects, 4620288 bytes, 4620288 GTT size

Re: linux-next: Tree for Aug 13 (xfs)

2013-08-13 Thread Randy Dunlap

On 08/13/13 01:28, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20130812:
> 

on i386:

fs/built-in.o: In function `xfs_log_calc_minimum_size':
(.text+0x1797a9): undefined reference to `__udivdi3'


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson  wrote:
> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek  wrote:
>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
>> >
>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829
>> > Author: Chris Wilson 
>> > Date:   Thu Aug 8 14:41:07 2013 +0100
>> >
>> > drm/i915: Allocate LLC ringbuffers from stolen
>> >
>> > As stolen objects now behave identically (wrt to default LLC cacheing)
>> > as their normal system counterparts, we no longer have to differentiate
>> > our usage for ringbuffers. So allocate them from stolen on SNB+ as 
>> > well.
>> >
>> > Signed-off-by: Chris Wilson 
>> > Reviewed-by: Ville Syrjälä 
>> > Signed-off-by: Daniel Vetter 
>> >
>> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
>> >
>> > See also attached files!
>> >
>>
>> With the attached revert-patch my system is OK (with my customized X stack).
>
> No indication of a GPU hang? I'm puzzled as to how this ends up with the
> scanout being misread.
>
> cat /sys/kernel/debug/dri/0/i915_gem_stolen
> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
>
> would be interesting.

With revert-patch applied:

$ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen
Stolen:
   88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1)
(pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
(stolen: ) (p mappable)
Total 1 objects, 4227072 bytes, 4227072 GTT size

$ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj
88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1)
(pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
(stolen: ) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj
88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty
(name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000,
size: 0050) (p mappable) (blitter ring)

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek  wrote:
> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
> >
> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
> > commit 5456fe3882812aba251886e36fe55bfefb8e8829
> > Author: Chris Wilson 
> > Date:   Thu Aug 8 14:41:07 2013 +0100
> >
> > drm/i915: Allocate LLC ringbuffers from stolen
> >
> > As stolen objects now behave identically (wrt to default LLC cacheing)
> > as their normal system counterparts, we no longer have to differentiate
> > our usage for ringbuffers. So allocate them from stolen on SNB+ as well.
> >
> > Signed-off-by: Chris Wilson 
> > Reviewed-by: Ville Syrjälä 
> > Signed-off-by: Daniel Vetter 
> >
> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
> >
> > See also attached files!
> >
> 
> With the attached revert-patch my system is OK (with my customized X stack).

No indication of a GPU hang? I'm puzzled as to how this ends up with the
scanout being misread.

cat /sys/kernel/debug/dri/0/i915_gem_stolen
cat /sys/kernel/debug/dri/0/i915_gem_framebuffer

would be interesting.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek  wrote:
> On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek  wrote:
>> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek  wrote:
>>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek  wrote:
 On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson  
 wrote:
> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson 
>>  wrote:
>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
>> >> for LightDM seems to be OK.
>> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
>> >
>> > What hardware and display do you have?
>>
>> It's a Samsung ultrabook with SandyBridge CPU.
>>
>> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
>> Graphics 3000
>
> using LVDS.
>
>> - Sedat -
>>
>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>
> Did that make a difference? It shouldn't if the error is occuring before
> X even starts...

 NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
 Xorg.log :-).

 As said logging out of Unity-2D and entering LightDM greeter - screen is 
 fine.
 Starting again a Unity-2D session - no screen corruption, too.

 - Sedat -
>>>
>>> Some more testing:
>>>
>>> [1] With my X stack:
>>>
>>> FIRST BAD: next-20130812
>>> LAST GOOD: next-20130809
>>>
>>> [2] With Ubuntu's X stack:
>>>
>>> next-20130813 is OK (Xorg.log attached)
>>>
>>
>> drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack
>> no problems).
>>
>
> I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
>
> 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
> commit 5456fe3882812aba251886e36fe55bfefb8e8829
> Author: Chris Wilson 
> Date:   Thu Aug 8 14:41:07 2013 +0100
>
> drm/i915: Allocate LLC ringbuffers from stolen
>
> As stolen objects now behave identically (wrt to default LLC cacheing)
> as their normal system counterparts, we no longer have to differentiate
> our usage for ringbuffers. So allocate them from stolen on SNB+ as well.
>
> Signed-off-by: Chris Wilson 
> Reviewed-by: Ville Syrjälä 
> Signed-off-by: Daniel Vetter 
>
> :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
> 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
>
> See also attached files!
>

With the attached revert-patch my system is OK (with my customized X stack).

- Sedat -


0001-Revert-drm-i915-Allocate-LLC-ringbuffers-from-stolen.patch
Description: Binary data

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek  wrote:
> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek  wrote:
>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek  wrote:
>>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson  
>>> wrote:
 On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson  
> wrote:
> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
> >> for LightDM seems to be OK.
> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
> >
> > What hardware and display do you have?
>
> It's a Samsung ultrabook with SandyBridge CPU.
>
> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
> Graphics 3000

 using LVDS.

> - Sedat -
>
> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.

 Did that make a difference? It shouldn't if the error is occuring before
 X even starts...
>>>
>>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
>>> Xorg.log :-).
>>>
>>> As said logging out of Unity-2D and entering LightDM greeter - screen is 
>>> fine.
>>> Starting again a Unity-2D session - no screen corruption, too.
>>>
>>> - Sedat -
>>
>> Some more testing:
>>
>> [1] With my X stack:
>>
>> FIRST BAD: next-20130812
>> LAST GOOD: next-20130809
>>
>> [2] With Ubuntu's X stack:
>>
>> next-20130813 is OK (Xorg.log attached)
>>
>
> drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack
> no problems).
>

I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:

5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
commit 5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson 
Date:   Thu Aug 8 14:41:07 2013 +0100

drm/i915: Allocate LLC ringbuffers from stolen

As stolen objects now behave identically (wrt to default LLC cacheing)
as their normal system counterparts, we no longer have to differentiate
our usage for ringbuffers. So allocate them from stolen on SNB+ as well.

Signed-off-by: Chris Wilson 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 

:04 04 de063a052f39095f4d2f51b49caef9f827df41e8
1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers

See also attached files!

- Sedat -
git bisect start
# good: [d4e4ab86bcba5a72779c43dc1459f71fea3d89c8] Linux 3.11-rc5
git bisect good d4e4ab86bcba5a72779c43dc1459f71fea3d89c8
# bad: [5b79c8eb1b61d499ca70cc3e4e2ced7822209876] Merge branch 
'drm-intel-nightly' into 3.11.0-rc5-iniza-small
git bisect bad 5b79c8eb1b61d499ca70cc3e4e2ced7822209876
# good: [36f2d1f151215c48d902947d64b86dc5ab277e19] drm/i915: rip out legacy 
encoder->mode_set callback
git bisect good 36f2d1f151215c48d902947d64b86dc5ab277e19
# good: [c35426d2bc25b242ee2a9a7a1d62634be1e86bb0] drm/i915: Split plane 
watermark parameters into a separate struct
git bisect good c35426d2bc25b242ee2a9a7a1d62634be1e86bb0
# good: [32c913e4369ce7bd1d16a9b6983f7b8975c13f5a] Merge tag 
'drm-intel-next-2013-07-26-fixed' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next
git bisect good 32c913e4369ce7bd1d16a9b6983f7b8975c13f5a
# good: [d46f1c3f1372e3a72fab97c60480aa4a1084387f] drm/i915: Allow the GPU to 
cache stolen memory
git bisect good d46f1c3f1372e3a72fab97c60480aa4a1084387f
# bad: [b8a1868b10bb4fe7fb7d283da5d56064b1a189f4] drm/i915: Allow the user to 
set bo into the DISPLAY cache domain
git bisect bad b8a1868b10bb4fe7fb7d283da5d56064b1a189f4
# bad: [a698a20e8cf9a946b0a491cb58ff96c0b4332d08] i915: Fix SDVO potentially 
turning off randomly
git bisect bad a698a20e8cf9a946b0a491cb58ff96c0b4332d08
# bad: [8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1] drm/i915: Only do a chipset 
flush after a clflush
git bisect bad 8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1
# bad: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC 
ringbuffers from stolen
git bisect bad 5456fe3882812aba251886e36fe55bfefb8e8829
# first bad commit: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: 
Allocate LLC ringbuffers from stolen
commit 5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson 
Date:   Thu Aug 8 14:41:07 2013 +0100

drm/i915: Allocate LLC ringbuffers from stolen

As stolen objects now behave identically (wrt to default LLC cacheing)
as their normal system counterparts, we no longer have to differentiate
our usage for ringbuffers. So allocate them from stolen on SNB+ as well.

Signed-off-by: Chris Wilson 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 

 drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
commit 5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson 
Date:   Thu Aug 8 14:41:07 2013 +0100

drm/i915: Allocate LLC ringbuffers from stolen

As stolen objects now behave identically (wrt to default LLC cacheing)

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek  wrote:
> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek  wrote:
>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson  
>> wrote:
>>> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson  
 wrote:
 > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
 >> After a logout from my "BROKEN" Unity-2D session - the login-screen
 >> for LightDM seems to be OK.
 >> Then entering my Unity-2D desktop is OK - no screen corruptions.
 >
 > What hardware and display do you have?

 It's a Samsung ultrabook with SandyBridge CPU.

 [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
 Graphics 3000
>>>
>>> using LVDS.
>>>
 - Sedat -

 P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>>>
>>> Did that make a difference? It shouldn't if the error is occuring before
>>> X even starts...
>>
>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
>> Xorg.log :-).
>>
>> As said logging out of Unity-2D and entering LightDM greeter - screen is 
>> fine.
>> Starting again a Unity-2D session - no screen corruption, too.
>>
>> - Sedat -
>
> Some more testing:
>
> [1] With my X stack:
>
> FIRST BAD: next-20130812
> LAST GOOD: next-20130809
>
> [2] With Ubuntu's X stack:
>
> next-20130813 is OK (Xorg.log attached)
>

drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack
no problems).

- Sedat -

> - Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek  wrote:
> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson  
> wrote:
>> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson  
>>> wrote:
>>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
>>> >> for LightDM seems to be OK.
>>> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
>>> >
>>> > What hardware and display do you have?
>>>
>>> It's a Samsung ultrabook with SandyBridge CPU.
>>>
>>> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
>>> Graphics 3000
>>
>> using LVDS.
>>
>>> - Sedat -
>>>
>>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>>
>> Did that make a difference? It shouldn't if the error is occuring before
>> X even starts...
>
> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
> Xorg.log :-).
>
> As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
> Starting again a Unity-2D session - no screen corruption, too.
>
> - Sedat -

Some more testing:

[1] With my X stack:

FIRST BAD: next-20130812
LAST GOOD: next-20130809

[2] With Ubuntu's X stack:

next-20130813 is OK (Xorg.log attached)

- Sedat -


Xorg.0.log
Description: Binary data

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson  wrote:
> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson  
>> wrote:
>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
>> >> for LightDM seems to be OK.
>> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
>> >
>> > What hardware and display do you have?
>>
>> It's a Samsung ultrabook with SandyBridge CPU.
>>
>> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
>> Graphics 3000
>
> using LVDS.
>
>> - Sedat -
>>
>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>
> Did that make a difference? It shouldn't if the error is occuring before
> X even starts...

NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
Xorg.log :-).

As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
Starting again a Unity-2D session - no screen corruption, too.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson  
> wrote:
> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
> >> for LightDM seems to be OK.
> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
> >
> > What hardware and display do you have?
> 
> It's a Samsung ultrabook with SandyBridge CPU.
> 
> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
> Graphics 3000

using LVDS.
 
> - Sedat -
> 
> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.

Did that make a difference? It shouldn't if the error is occuring before
X even starts...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson  wrote:
> On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>> After a logout from my "BROKEN" Unity-2D session - the login-screen
>> for LightDM seems to be OK.
>> Then entering my Unity-2D desktop is OK - no screen corruptions.
>
> What hardware and display do you have?

It's a Samsung ultrabook with SandyBridge CPU.

[   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
Graphics 3000

xrand output attached.

- Sedat -

P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS1 connected 1366x768+0+0 (0x45) normal (normal left inverted right x axis y 
axis) 0mm x 0mm
Identifier: 0x41
Timestamp:  339571
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
BACKLIGHT: 7 (0x0007)   range:  (0,7)
Backlight: 7 (0x0007)   range:  (0,7)
scaling mode:   Full aspect
supported: None Full Center   Full aspect 
  1366x768 (0x45)   70.7MHz -HSync -VSync *current +preferred
h: width  1366 start 1414 end 1446 total 1486 skew0 clock   47.6KHz
v: height  768 start  770 end  775 total  792   clock   60.1Hz
  1360x768 (0x46)   84.8MHz -HSync +VSync
h: width  1360 start 1432 end 1568 total 1776 skew0 clock   47.7KHz
v: height  768 start  771 end  781 total  798   clock   59.8Hz
  1360x768 (0x47)   72.0MHz +HSync -VSync
h: width  1360 start 1408 end 1440 total 1520 skew0 clock   47.4KHz
v: height  768 start  771 end  781 total  790   clock   60.0Hz
  1024x768 (0x48)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806   clock   60.0Hz
  800x600 (0x49)   40.0MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock   37.9KHz
v: height  600 start  601 end  605 total  628   clock   60.3Hz
  800x600 (0x4a)   36.0MHz +HSync +VSync
h: width   800 start  824 end  896 total 1024 skew0 clock   35.2KHz
v: height  600 start  601 end  603 total  625   clock   56.2Hz
  640x480 (0x4b)   25.2MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock   31.5KHz
v: height  480 start  490 end  492 total  525   clock   59.9Hz
VGA1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x42
Timestamp:  339571
Subpixel:   unknown
Clones:
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
HDMI1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x43
Timestamp:  339571
Subpixel:   unknown
Clones:
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
Broadcast RGB:  Automatic
supported: AutomaticFull Limited 16:2
audio:  auto
supported: force-dvioff  auto on  
DP1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x44
Timestamp:  339571
Subpixel:   unknown
Clones:
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
Broadcast RGB:  Automatic
supported: AutomaticFull Limited 16:2
audio:  auto
supported: force-dvioff  auto on

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> After a logout from my "BROKEN" Unity-2D session - the login-screen
> for LightDM seems to be OK.
> Then entering my Unity-2D desktop is OK - no screen corruptions.

What hardware and display do you have?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:25 AM, Chris Wilson  wrote:
> On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> with today's next-20130813 I cannot see 1/10 of my desktop-screen's
>> top, it's simply black.
>> I can estimate the URL line in Firefox (or open a new tab blindly and
>> get a known URL from my autocompleted history).
>
> Can you attach a photograph?
>

It's a black bar on the top of my desktop-screen - approx. 1/10.

It looks like this is also in the VT on bootup before entering LightDM.

>> My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
>> next-20130808 was OK - no screen corruptions.
>>
>> Any idea, hint?
>
> Can you please try:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index af1b2f0..b0f181d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1837,7 +1837,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
> break;
> case I915_TILING_X:
> /* pin() will align the object as required by fence */
> -   alignment = 0;
> +   alignment = 256 * 1024;
> break;
> case I915_TILING_Y:
> /* Despite that we check this in framebuffer_init userspace 
> can
>
> --

NO, that did not help.

After a logout from my "BROKEN" Unity-2D session - the login-screen
for LightDM seems to be OK.
Then entering my Unity-2D desktop is OK - no screen corruptions.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
> Hi,
> 
> with today's next-20130813 I cannot see 1/10 of my desktop-screen's
> top, it's simply black.
> I can estimate the URL line in Firefox (or open a new tab blindly and
> get a known URL from my autocompleted history).

Can you attach a photograph?
 
> My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
> next-20130808 was OK - no screen corruptions.
> 
> Any idea, hint?

Can you please try:

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index af1b2f0..b0f181d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1837,7 +1837,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
break;
case I915_TILING_X:
/* pin() will align the object as required by fence */
-   alignment = 0;
+   alignment = 256 * 1024;
break;
case I915_TILING_Y:
/* Despite that we check this in framebuffer_init userspace can

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:14 AM, Sedat Dilek  wrote:
> On Tue, Aug 13, 2013 at 11:10 AM, Sedat Dilek  wrote:
>> On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell  
>> wrote:
>>> Hi all,
>>>
>>> Changes since 20130812:
>>>
>>> The ext4 tree gained a conflict against Linus' tree.
>>>
>>> The infiniband tree gained a build failure for which I applied a merge
>>> fix patch and another so I used the version from next-20130812.
>>>
>>> The tty tree gained conflicts against the devicetree and tile trees.
>>>
>>> The usb tree gained a conflict against the net-next tree.
>>>
>>> The usb-gadget tree gained a build failure for which I reverted a commit.
>>>
>>> The ptr-ret tree gained a conflict against the staging tree.
>>>
>>> The akpm tree gained a conflict against the staging tree.
>>>
>>> 
>>>
>>
>> Hi,
>>
>> with today's next-20130813 I cannot see 1/10 of my desktop-screen's
>> top, it's simply black.
>> I can estimate the URL line in Firefox (or open a new tab blindly and
>> get a known URL from my autocompleted history).
>>
>> My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
>> next-20130808 was OK - no screen corruptions.
>>
>> Any idea, hint?
>>
>> - Sedat -
>
> [ From my dmesg ]
>
> [   28.026524] [ cut here ]
> [   28.026557] WARNING: CPU: 3 PID: 639 at
> drivers/gpu/drm/i915/i915_gem.c:3435
> i915_gem_object_set_cache_level+0x389/0x3a0 [i915]()
> [   28.026560] Modules linked in: arc4 snd_hwdep i915(+) iwldvm
> snd_pcm snd_page_alloc mac80211 snd_seq_midi parport_pc
> snd_seq_midi_event rfcomm bnep snd_rawmidi ppdev uvcvideo snd_seq
> btusb videobuf2_vmalloc i2c_algo_bit psmouse iwlwifi drm_kms_helper
> videobuf2_memops snd_timer drm snd_seq_device videobuf2_core bluetooth
> videodev serio_raw snd cfg80211 samsung_laptop wmi soundcore lp
> mac_hid video lpc_ich parport hid_generic usbhid hid usb_storage r8169
> mii
> [   28.026610] CPU: 3 PID: 639 Comm: modprobe Not tainted
> 3.11.0-rc5-next20130813-1-iniza-small #1
> [   28.026613] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [   28.026616]  0d6b 8800795535a8 816e259a
> 0007
> [   28.026622]   8800795535e8 810661dc
> 81376e70
> [   28.026627]  8800746ba200 8800746ba2b8 88007a2c7000
> 0041
> [   28.026632] Call Trace:
> [   28.026641]  [] dump_stack+0x46/0x58
> [   28.026647]  [] warn_slowpath_common+0x8c/0xc0
> [   28.026653]  [] ? sg_kfree+0x30/0x30
> [   28.026658]  [] warn_slowpath_null+0x1a/0x20
> [   28.026680]  []
> i915_gem_object_set_cache_level+0x389/0x3a0 [i915]
> [   28.026684]  [] ? sg_alloc_table+0x1f/0x50
> [   28.026703]  []
> i915_gem_object_pin_to_display_plane+0x62/0x1c0 [i915]
> [   28.026727]  []
> intel_pin_and_fence_fb_obj+0xc0/0x140 [i915]
> [   28.026732]  [] ? mutex_lock+0x1e/0x40
> [   28.026761]  [] intelfb_create+0x107/0x510 [i915]
> [   28.026778]  [] ? drm_mode_create+0x47/0x70 [drm]
> [   28.026786]  []
> drm_fb_helper_initial_config+0x2fe/0x550 [drm_kms_helper]
> [   28.026813]  [] ? i915_write32+0xc3/0x190 [i915]
> [   28.026838]  [] intel_fbdev_initial_config+0x21/0x30 
> [i915]
> [   28.026859]  [] i915_driver_load+0xe9d/0xed0 [i915]
> [   28.026876]  [] drm_get_pci_dev+0x181/0x2a0 [drm]
> [   28.026881]  [] ? do_raw_spin_unlock+0x5d/0xb0
> [   28.026900]  [] i915_pci_probe+0x36/0x70 [i915]
> [   28.026905]  [] local_pci_probe+0x4b/0x80
> [   28.026910]  [] pci_device_probe+0x101/0x120
> [   28.026915]  [] driver_probe_device+0x7b/0x240
> [   28.026920]  [] __driver_attach+0xab/0xb0
> [   28.026924]  [] ? driver_probe_device+0x240/0x240
> [   28.026928]  [] bus_for_each_dev+0x5e/0x90
> [   28.026932]  [] driver_attach+0x1e/0x20
> [   28.026936]  [] bus_add_driver+0x104/0x2a0
> [   28.026941]  [] driver_register+0x64/0xf0
> [   28.026946]  [] __pci_register_driver+0x64/0x70
> [   28.026951]  [] ? 0xa0474fff
> [   28.026963]  [] drm_pci_init+0x11a/0x130 [drm]
> [   28.026968]  [] ? 0xa0474fff
> [   28.026987]  [] i915_init+0x66/0x68 [i915]
> [   28.026992]  [] do_one_initcall+0x4e/0x180
> [   28.026997]  [] ? set_memory_nx+0x43/0x50
> [   28.027003]  [] load_module+0x209c/0x25b0
> [   28.027007]  [] ? show_initstate+0x50/0x50
> [   28.027013]  [] SyS_init_module+0xac/0xd0
> [   28.027018]  [] tracesys+0xe1/0xe6
> [   28.027022] ---[ end trace be830cf8c302dde8 ]---
>
>
> - Sedat -

Looks like there is patch to fix this WARNING, do not think it fixes
my screen corruption.

- Sedat -

http://lists.freedesktop.org/archives/intel-gfx/2013-August/031701.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell  
wrote:
> Hi all,
>
> Changes since 20130812:
>
> The ext4 tree gained a conflict against Linus' tree.
>
> The infiniband tree gained a build failure for which I applied a merge
> fix patch and another so I used the version from next-20130812.
>
> The tty tree gained conflicts against the devicetree and tile trees.
>
> The usb tree gained a conflict against the net-next tree.
>
> The usb-gadget tree gained a build failure for which I reverted a commit.
>
> The ptr-ret tree gained a conflict against the staging tree.
>
> The akpm tree gained a conflict against the staging tree.
>
> 
>

Hi,

with today's next-20130813 I cannot see 1/10 of my desktop-screen's
top, it's simply black.
I can estimate the URL line in Firefox (or open a new tab blindly and
get a known URL from my autocompleted history).

My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
next-20130808 was OK - no screen corruptions.

Any idea, hint?

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell s...@canb.auug.org.au 
wrote:
 Hi all,

 Changes since 20130812:

 The ext4 tree gained a conflict against Linus' tree.

 The infiniband tree gained a build failure for which I applied a merge
 fix patch and another so I used the version from next-20130812.

 The tty tree gained conflicts against the devicetree and tile trees.

 The usb tree gained a conflict against the net-next tree.

 The usb-gadget tree gained a build failure for which I reverted a commit.

 The ptr-ret tree gained a conflict against the staging tree.

 The akpm tree gained a conflict against the staging tree.

 


Hi,

with today's next-20130813 I cannot see 1/10 of my desktop-screen's
top, it's simply black.
I can estimate the URL line in Firefox (or open a new tab blindly and
get a known URL from my autocompleted history).

My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
next-20130808 was OK - no screen corruptions.

Any idea, hint?

- Sedat -
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:14 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 11:10 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell s...@canb.auug.org.au 
 wrote:
 Hi all,

 Changes since 20130812:

 The ext4 tree gained a conflict against Linus' tree.

 The infiniband tree gained a build failure for which I applied a merge
 fix patch and another so I used the version from next-20130812.

 The tty tree gained conflicts against the devicetree and tile trees.

 The usb tree gained a conflict against the net-next tree.

 The usb-gadget tree gained a build failure for which I reverted a commit.

 The ptr-ret tree gained a conflict against the staging tree.

 The akpm tree gained a conflict against the staging tree.

 


 Hi,

 with today's next-20130813 I cannot see 1/10 of my desktop-screen's
 top, it's simply black.
 I can estimate the URL line in Firefox (or open a new tab blindly and
 get a known URL from my autocompleted history).

 My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
 next-20130808 was OK - no screen corruptions.

 Any idea, hint?

 - Sedat -

 [ From my dmesg ]

 [   28.026524] [ cut here ]
 [   28.026557] WARNING: CPU: 3 PID: 639 at
 drivers/gpu/drm/i915/i915_gem.c:3435
 i915_gem_object_set_cache_level+0x389/0x3a0 [i915]()
 [   28.026560] Modules linked in: arc4 snd_hwdep i915(+) iwldvm
 snd_pcm snd_page_alloc mac80211 snd_seq_midi parport_pc
 snd_seq_midi_event rfcomm bnep snd_rawmidi ppdev uvcvideo snd_seq
 btusb videobuf2_vmalloc i2c_algo_bit psmouse iwlwifi drm_kms_helper
 videobuf2_memops snd_timer drm snd_seq_device videobuf2_core bluetooth
 videodev serio_raw snd cfg80211 samsung_laptop wmi soundcore lp
 mac_hid video lpc_ich parport hid_generic usbhid hid usb_storage r8169
 mii
 [   28.026610] CPU: 3 PID: 639 Comm: modprobe Not tainted
 3.11.0-rc5-next20130813-1-iniza-small #1
 [   28.026613] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
 [   28.026616]  0d6b 8800795535a8 816e259a
 0007
 [   28.026622]   8800795535e8 810661dc
 81376e70
 [   28.026627]  8800746ba200 8800746ba2b8 88007a2c7000
 0041
 [   28.026632] Call Trace:
 [   28.026641]  [816e259a] dump_stack+0x46/0x58
 [   28.026647]  [810661dc] warn_slowpath_common+0x8c/0xc0
 [   28.026653]  [81376e70] ? sg_kfree+0x30/0x30
 [   28.026658]  [8106622a] warn_slowpath_null+0x1a/0x20
 [   28.026680]  [a03e1fe9]
 i915_gem_object_set_cache_level+0x389/0x3a0 [i915]
 [   28.026684]  [8137723f] ? sg_alloc_table+0x1f/0x50
 [   28.026703]  [a03e2162]
 i915_gem_object_pin_to_display_plane+0x62/0x1c0 [i915]
 [   28.026727]  [a03f9b10]
 intel_pin_and_fence_fb_obj+0xc0/0x140 [i915]
 [   28.026732]  [816e82ee] ? mutex_lock+0x1e/0x40
 [   28.026761]  [a0424277] intelfb_create+0x107/0x510 [i915]
 [   28.026778]  [a020f807] ? drm_mode_create+0x47/0x70 [drm]
 [   28.026786]  [a01a404e]
 drm_fb_helper_initial_config+0x2fe/0x550 [drm_kms_helper]
 [   28.026813]  [a0431323] ? i915_write32+0xc3/0x190 [i915]
 [   28.026838]  [a0424751] intel_fbdev_initial_config+0x21/0x30 
 [i915]
 [   28.026859]  [a03cb38d] i915_driver_load+0xe9d/0xed0 [i915]
 [   28.026876]  [a020aad1] drm_get_pci_dev+0x181/0x2a0 [drm]
 [   28.026881]  [8137b12d] ? do_raw_spin_unlock+0x5d/0xb0
 [   28.026900]  [a03c75d6] i915_pci_probe+0x36/0x70 [i915]
 [   28.026905]  [81399ceb] local_pci_probe+0x4b/0x80
 [   28.026910]  [8139b5c1] pci_device_probe+0x101/0x120
 [   28.026915]  [81478a1b] driver_probe_device+0x7b/0x240
 [   28.026920]  [81478c8b] __driver_attach+0xab/0xb0
 [   28.026924]  [81478be0] ? driver_probe_device+0x240/0x240
 [   28.026928]  [81476b6e] bus_for_each_dev+0x5e/0x90
 [   28.026932]  [8147851e] driver_attach+0x1e/0x20
 [   28.026936]  [81477fc4] bus_add_driver+0x104/0x2a0
 [   28.026941]  [814793f4] driver_register+0x64/0xf0
 [   28.026946]  [8139a544] __pci_register_driver+0x64/0x70
 [   28.026951]  [a0475000] ? 0xa0474fff
 [   28.026963]  [a020ad0a] drm_pci_init+0x11a/0x130 [drm]
 [   28.026968]  [a0475000] ? 0xa0474fff
 [   28.026987]  [a0475066] i915_init+0x66/0x68 [i915]
 [   28.026992]  [8100207e] do_one_initcall+0x4e/0x180
 [   28.026997]  [81058413] ? set_memory_nx+0x43/0x50
 [   28.027003]  [810d147c] load_module+0x209c/0x25b0
 [   28.027007]  [810ce0a0] ? show_initstate+0x50/0x50
 [   28.027013]  [810d1a3c] SyS_init_module+0xac/0xd0
 [   28.027018]  [816f41ef] tracesys+0xe1/0xe6
 [

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
 Hi,
 
 with today's next-20130813 I cannot see 1/10 of my desktop-screen's
 top, it's simply black.
 I can estimate the URL line in Firefox (or open a new tab blindly and
 get a known URL from my autocompleted history).

Can you attach a photograph?
 
 My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
 next-20130808 was OK - no screen corruptions.
 
 Any idea, hint?

Can you please try:

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index af1b2f0..b0f181d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1837,7 +1837,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
break;
case I915_TILING_X:
/* pin() will align the object as required by fence */
-   alignment = 0;
+   alignment = 256 * 1024;
break;
case I915_TILING_Y:
/* Despite that we check this in framebuffer_init userspace can

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:25 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
 Hi,

 with today's next-20130813 I cannot see 1/10 of my desktop-screen's
 top, it's simply black.
 I can estimate the URL line in Firefox (or open a new tab blindly and
 get a known URL from my autocompleted history).

 Can you attach a photograph?


It's a black bar on the top of my desktop-screen - approx. 1/10.

It looks like this is also in the VT on bootup before entering LightDM.

 My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
 next-20130808 was OK - no screen corruptions.

 Any idea, hint?

 Can you please try:

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index af1b2f0..b0f181d 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -1837,7 +1837,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
 break;
 case I915_TILING_X:
 /* pin() will align the object as required by fence */
 -   alignment = 0;
 +   alignment = 256 * 1024;
 break;
 case I915_TILING_Y:
 /* Despite that we check this in framebuffer_init userspace 
 can

 --

NO, that did not help.

After a logout from my BROKEN Unity-2D session - the login-screen
for LightDM seems to be OK.
Then entering my Unity-2D desktop is OK - no screen corruptions.

- Sedat -
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
 After a logout from my BROKEN Unity-2D session - the login-screen
 for LightDM seems to be OK.
 Then entering my Unity-2D desktop is OK - no screen corruptions.

What hardware and display do you have?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
 After a logout from my BROKEN Unity-2D session - the login-screen
 for LightDM seems to be OK.
 Then entering my Unity-2D desktop is OK - no screen corruptions.

 What hardware and display do you have?

It's a Samsung ultrabook with SandyBridge CPU.

[   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
Graphics 3000

xrand output attached.

- Sedat -

P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS1 connected 1366x768+0+0 (0x45) normal (normal left inverted right x axis y 
axis) 0mm x 0mm
Identifier: 0x41
Timestamp:  339571
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
BACKLIGHT: 7 (0x0007)   range:  (0,7)
Backlight: 7 (0x0007)   range:  (0,7)
scaling mode:   Full aspect
supported: None Full Center   Full aspect 
  1366x768 (0x45)   70.7MHz -HSync -VSync *current +preferred
h: width  1366 start 1414 end 1446 total 1486 skew0 clock   47.6KHz
v: height  768 start  770 end  775 total  792   clock   60.1Hz
  1360x768 (0x46)   84.8MHz -HSync +VSync
h: width  1360 start 1432 end 1568 total 1776 skew0 clock   47.7KHz
v: height  768 start  771 end  781 total  798   clock   59.8Hz
  1360x768 (0x47)   72.0MHz +HSync -VSync
h: width  1360 start 1408 end 1440 total 1520 skew0 clock   47.4KHz
v: height  768 start  771 end  781 total  790   clock   60.0Hz
  1024x768 (0x48)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806   clock   60.0Hz
  800x600 (0x49)   40.0MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock   37.9KHz
v: height  600 start  601 end  605 total  628   clock   60.3Hz
  800x600 (0x4a)   36.0MHz +HSync +VSync
h: width   800 start  824 end  896 total 1024 skew0 clock   35.2KHz
v: height  600 start  601 end  603 total  625   clock   56.2Hz
  640x480 (0x4b)   25.2MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock   31.5KHz
v: height  480 start  490 end  492 total  525   clock   59.9Hz
VGA1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x42
Timestamp:  339571
Subpixel:   unknown
Clones:
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
HDMI1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x43
Timestamp:  339571
Subpixel:   unknown
Clones:
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
Broadcast RGB:  Automatic
supported: AutomaticFull Limited 16:2
audio:  auto
supported: force-dvioff  auto on  
DP1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x44
Timestamp:  339571
Subpixel:   unknown
Clones:
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
Broadcast RGB:  Automatic
supported: AutomaticFull Limited 16:2
audio:  auto
supported: force-dvioff  auto on

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
  After a logout from my BROKEN Unity-2D session - the login-screen
  for LightDM seems to be OK.
  Then entering my Unity-2D desktop is OK - no screen corruptions.
 
  What hardware and display do you have?
 
 It's a Samsung ultrabook with SandyBridge CPU.
 
 [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
 Graphics 3000

using LVDS.
 
 - Sedat -
 
 P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.

Did that make a difference? It shouldn't if the error is occuring before
X even starts...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
  After a logout from my BROKEN Unity-2D session - the login-screen
  for LightDM seems to be OK.
  Then entering my Unity-2D desktop is OK - no screen corruptions.
 
  What hardware and display do you have?

 It's a Samsung ultrabook with SandyBridge CPU.

 [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
 Graphics 3000

 using LVDS.

 - Sedat -

 P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.

 Did that make a difference? It shouldn't if the error is occuring before
 X even starts...

NO, was just confused not seeing GT2 (HD-3000 was new to me) in my
Xorg.log :-).

As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
Starting again a Unity-2D session - no screen corruption, too.

- Sedat -
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
  After a logout from my BROKEN Unity-2D session - the login-screen
  for LightDM seems to be OK.
  Then entering my Unity-2D desktop is OK - no screen corruptions.
 
  What hardware and display do you have?

 It's a Samsung ultrabook with SandyBridge CPU.

 [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
 Graphics 3000

 using LVDS.

 - Sedat -

 P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.

 Did that make a difference? It shouldn't if the error is occuring before
 X even starts...

 NO, was just confused not seeing GT2 (HD-3000 was new to me) in my
 Xorg.log :-).

 As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
 Starting again a Unity-2D session - no screen corruption, too.

 - Sedat -

Some more testing:

[1] With my X stack:

FIRST BAD: next-20130812
LAST GOOD: next-20130809

[2] With Ubuntu's X stack:

next-20130813 is OK (Xorg.log attached)

- Sedat -


Xorg.0.log
Description: Binary data

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
  After a logout from my BROKEN Unity-2D session - the login-screen
  for LightDM seems to be OK.
  Then entering my Unity-2D desktop is OK - no screen corruptions.
 
  What hardware and display do you have?

 It's a Samsung ultrabook with SandyBridge CPU.

 [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
 Graphics 3000

 using LVDS.

 - Sedat -

 P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.

 Did that make a difference? It shouldn't if the error is occuring before
 X even starts...

 NO, was just confused not seeing GT2 (HD-3000 was new to me) in my
 Xorg.log :-).

 As said logging out of Unity-2D and entering LightDM greeter - screen is 
 fine.
 Starting again a Unity-2D session - no screen corruption, too.

 - Sedat -

 Some more testing:

 [1] With my X stack:

 FIRST BAD: next-20130812
 LAST GOOD: next-20130809

 [2] With Ubuntu's X stack:

 next-20130813 is OK (Xorg.log attached)


drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack
no problems).

- Sedat -

 - Sedat -
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
  After a logout from my BROKEN Unity-2D session - the login-screen
  for LightDM seems to be OK.
  Then entering my Unity-2D desktop is OK - no screen corruptions.
 
  What hardware and display do you have?

 It's a Samsung ultrabook with SandyBridge CPU.

 [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
 Graphics 3000

 using LVDS.

 - Sedat -

 P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.

 Did that make a difference? It shouldn't if the error is occuring before
 X even starts...

 NO, was just confused not seeing GT2 (HD-3000 was new to me) in my
 Xorg.log :-).

 As said logging out of Unity-2D and entering LightDM greeter - screen is 
 fine.
 Starting again a Unity-2D session - no screen corruption, too.

 - Sedat -

 Some more testing:

 [1] With my X stack:

 FIRST BAD: next-20130812
 LAST GOOD: next-20130809

 [2] With Ubuntu's X stack:

 next-20130813 is OK (Xorg.log attached)


 drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack
 no problems).


I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:

5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
commit 5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Thu Aug 8 14:41:07 2013 +0100

drm/i915: Allocate LLC ringbuffers from stolen

As stolen objects now behave identically (wrt to default LLC cacheing)
as their normal system counterparts, we no longer have to differentiate
our usage for ringbuffers. So allocate them from stolen on SNB+ as well.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

:04 04 de063a052f39095f4d2f51b49caef9f827df41e8
1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers

See also attached files!

- Sedat -
git bisect start
# good: [d4e4ab86bcba5a72779c43dc1459f71fea3d89c8] Linux 3.11-rc5
git bisect good d4e4ab86bcba5a72779c43dc1459f71fea3d89c8
# bad: [5b79c8eb1b61d499ca70cc3e4e2ced7822209876] Merge branch 
'drm-intel-nightly' into 3.11.0-rc5-iniza-small
git bisect bad 5b79c8eb1b61d499ca70cc3e4e2ced7822209876
# good: [36f2d1f151215c48d902947d64b86dc5ab277e19] drm/i915: rip out legacy 
encoder-mode_set callback
git bisect good 36f2d1f151215c48d902947d64b86dc5ab277e19
# good: [c35426d2bc25b242ee2a9a7a1d62634be1e86bb0] drm/i915: Split plane 
watermark parameters into a separate struct
git bisect good c35426d2bc25b242ee2a9a7a1d62634be1e86bb0
# good: [32c913e4369ce7bd1d16a9b6983f7b8975c13f5a] Merge tag 
'drm-intel-next-2013-07-26-fixed' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next
git bisect good 32c913e4369ce7bd1d16a9b6983f7b8975c13f5a
# good: [d46f1c3f1372e3a72fab97c60480aa4a1084387f] drm/i915: Allow the GPU to 
cache stolen memory
git bisect good d46f1c3f1372e3a72fab97c60480aa4a1084387f
# bad: [b8a1868b10bb4fe7fb7d283da5d56064b1a189f4] drm/i915: Allow the user to 
set bo into the DISPLAY cache domain
git bisect bad b8a1868b10bb4fe7fb7d283da5d56064b1a189f4
# bad: [a698a20e8cf9a946b0a491cb58ff96c0b4332d08] i915: Fix SDVO potentially 
turning off randomly
git bisect bad a698a20e8cf9a946b0a491cb58ff96c0b4332d08
# bad: [8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1] drm/i915: Only do a chipset 
flush after a clflush
git bisect bad 8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1
# bad: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC 
ringbuffers from stolen
git bisect bad 5456fe3882812aba251886e36fe55bfefb8e8829
# first bad commit: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: 
Allocate LLC ringbuffers from stolen
commit 5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Thu Aug 8 14:41:07 2013 +0100

drm/i915: Allocate LLC ringbuffers from stolen

As stolen objects now behave identically (wrt to default LLC cacheing)
as their normal system counterparts, we no longer have to differentiate
our usage for ringbuffers. So allocate them from stolen on SNB+ as well.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

 drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
commit 5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Thu Aug 8 14:41:07

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson 
 ch...@chris-wilson.co.uk wrote:
  On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
  After a logout from my BROKEN Unity-2D session - the login-screen
  for LightDM seems to be OK.
  Then entering my Unity-2D desktop is OK - no screen corruptions.
 
  What hardware and display do you have?

 It's a Samsung ultrabook with SandyBridge CPU.

 [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
 Graphics 3000

 using LVDS.

 - Sedat -

 P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.

 Did that make a difference? It shouldn't if the error is occuring before
 X even starts...

 NO, was just confused not seeing GT2 (HD-3000 was new to me) in my
 Xorg.log :-).

 As said logging out of Unity-2D and entering LightDM greeter - screen is 
 fine.
 Starting again a Unity-2D session - no screen corruption, too.

 - Sedat -

 Some more testing:

 [1] With my X stack:

 FIRST BAD: next-20130812
 LAST GOOD: next-20130809

 [2] With Ubuntu's X stack:

 next-20130813 is OK (Xorg.log attached)


 drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack
 no problems).


 I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:

 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
 commit 5456fe3882812aba251886e36fe55bfefb8e8829
 Author: Chris Wilson ch...@chris-wilson.co.uk
 Date:   Thu Aug 8 14:41:07 2013 +0100

 drm/i915: Allocate LLC ringbuffers from stolen

 As stolen objects now behave identically (wrt to default LLC cacheing)
 as their normal system counterparts, we no longer have to differentiate
 our usage for ringbuffers. So allocate them from stolen on SNB+ as well.

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

 :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers

 See also attached files!


With the attached revert-patch my system is OK (with my customized X stack).

- Sedat -


0001-Revert-drm-i915-Allocate-LLC-ringbuffers-from-stolen.patch
Description: Binary data

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
 
  5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
  commit 5456fe3882812aba251886e36fe55bfefb8e8829
  Author: Chris Wilson ch...@chris-wilson.co.uk
  Date:   Thu Aug 8 14:41:07 2013 +0100
 
  drm/i915: Allocate LLC ringbuffers from stolen
 
  As stolen objects now behave identically (wrt to default LLC cacheing)
  as their normal system counterparts, we no longer have to differentiate
  our usage for ringbuffers. So allocate them from stolen on SNB+ as well.
 
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
  :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
  1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
 
  See also attached files!
 
 
 With the attached revert-patch my system is OK (with my customized X stack).

No indication of a GPU hang? I'm puzzled as to how this ends up with the
scanout being misread.

cat /sys/kernel/debug/dri/0/i915_gem_stolen
cat /sys/kernel/debug/dri/0/i915_gem_framebuffer

would be interesting.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
 
  5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
  commit 5456fe3882812aba251886e36fe55bfefb8e8829
  Author: Chris Wilson ch...@chris-wilson.co.uk
  Date:   Thu Aug 8 14:41:07 2013 +0100
 
  drm/i915: Allocate LLC ringbuffers from stolen
 
  As stolen objects now behave identically (wrt to default LLC cacheing)
  as their normal system counterparts, we no longer have to differentiate
  our usage for ringbuffers. So allocate them from stolen on SNB+ as 
  well.
 
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
  :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
  1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
 
  See also attached files!
 

 With the attached revert-patch my system is OK (with my customized X stack).

 No indication of a GPU hang? I'm puzzled as to how this ends up with the
 scanout being misread.

 cat /sys/kernel/debug/dri/0/i915_gem_stolen
 cat /sys/kernel/debug/dri/0/i915_gem_framebuffer

 would be interesting.

With revert-patch applied:

$ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen
Stolen:
   88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1)
(pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
(stolen: ) (p mappable)
Total 1 objects, 4227072 bytes, 4227072 GTT size

$ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj
88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1)
(pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
(stolen: ) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj
88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty
(name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000,
size: 0050) (p mappable) (blitter ring)

- Sedat -
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 (xfs)

2013-08-13 Thread Randy Dunlap

On 08/13/13 01:28, Stephen Rothwell wrote:
 Hi all,
 
 Changes since 20130812:
 

on i386:

fs/built-in.o: In function `xfs_log_calc_minimum_size':
(.text+0x1797a9): undefined reference to `__udivdi3'


-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
 
  5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
  commit 5456fe3882812aba251886e36fe55bfefb8e8829
  Author: Chris Wilson ch...@chris-wilson.co.uk
  Date:   Thu Aug 8 14:41:07 2013 +0100
 
  drm/i915: Allocate LLC ringbuffers from stolen
 
  As stolen objects now behave identically (wrt to default LLC cacheing)
  as their normal system counterparts, we no longer have to 
  differentiate
  our usage for ringbuffers. So allocate them from stolen on SNB+ as 
  well.
 
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
  :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
  1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
 
  See also attached files!
 

 With the attached revert-patch my system is OK (with my customized X stack).

 No indication of a GPU hang? I'm puzzled as to how this ends up with the
 scanout being misread.

 cat /sys/kernel/debug/dri/0/i915_gem_stolen
 cat /sys/kernel/debug/dri/0/i915_gem_framebuffer

 would be interesting.

 With revert-patch applied:

 $ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen
 Stolen:
88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1)
 (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
 (stolen: ) (p mappable)
 Total 1 objects, 4227072 bytes, 4227072 GTT size

 $ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
 fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj
 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1)
 (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
 (stolen: ) (p mappable)
 user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj
 88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty
 (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000,
 size: 0050) (p mappable) (blitter ring)


Attached both outputs with GOOD and BAD (BROKEN) kernel.

- Sedat -
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880074492e40: p g 
4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 
00072000, size: 00408000) (stolen: ) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880074492840: pXg  
   5120KiB 36 02 158126 158126 0 uncached dirty (name: 3) (pinned x 1) 
(display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) 
(blitter ring)
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073995200: p g 
4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 
00072000, size: 00408000) (stolen: 0006) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 8800736d8e00: pXg  
   5120KiB 36 02 -737 -737 0 uncached dirty (name: 3) (pinned x 1) (display) 
(fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring)
Stolen:
   880074492e40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 
1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p 
mappable)
Total 1 objects, 4227072 bytes, 4227072 GTT size
Stolen:
   880073995c80: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable)
   880073995800: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable)
   880073995500: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable)
   880073995200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 
1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 0006) (p 
mappable)
Total 4 objects, 4620288 bytes, 4620288 GTT size

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk 
  wrote:
  On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
  On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com 
  wrote:
   I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
  
   5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
   commit 5456fe3882812aba251886e36fe55bfefb8e8829
   Author: Chris Wilson ch...@chris-wilson.co.uk
   Date:   Thu Aug 8 14:41:07 2013 +0100
  
   drm/i915: Allocate LLC ringbuffers from stolen
  
   As stolen objects now behave identically (wrt to default LLC 
   cacheing)
   as their normal system counterparts, we no longer have to 
   differentiate
   our usage for ringbuffers. So allocate them from stolen on SNB+ as 
   well.
  
   Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
   Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
   Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  
   :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
   1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
  
   See also attached files!
  
 
  With the attached revert-patch my system is OK (with my customized X 
  stack).
 
  No indication of a GPU hang? I'm puzzled as to how this ends up with the
  scanout being misread.
 
  cat /sys/kernel/debug/dri/0/i915_gem_stolen
  cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
 
  would be interesting.

 Attached both outputs with GOOD and BAD (BROKEN) kernel.

ggtt offset is the same for both setups, the only difference between the
two is the location of fbcon in stolen memory.

Can you please attach the output of intel_reg_dumper for good/bad? It's
a long shot...

Speaking of long shots, try this (slightly different to the earlier patch):

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a21f935..37ad772 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
BUG();
}
 
+   if (obj-stolen  INTEL_INFO(dev)-gen = 6)
+   alignment = 256 * 1024;
+
/* Note that the w/a also requires 64 PTE of padding following the
 * bo. We currently fill all unused PTE with the shadow page and so
 * we should always have valid PTE following the scanout preventing


-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 7:13 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk 
  wrote:
  On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
  On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com 
  wrote:
   I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
  
   5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
   commit 5456fe3882812aba251886e36fe55bfefb8e8829
   Author: Chris Wilson ch...@chris-wilson.co.uk
   Date:   Thu Aug 8 14:41:07 2013 +0100
  
   drm/i915: Allocate LLC ringbuffers from stolen
  
   As stolen objects now behave identically (wrt to default LLC 
   cacheing)
   as their normal system counterparts, we no longer have to 
   differentiate
   our usage for ringbuffers. So allocate them from stolen on SNB+ as 
   well.
  
   Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
   Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
   Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  
   :04 04 de063a052f39095f4d2f51b49caef9f827df41e8
   1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M  drivers
  
   See also attached files!
  
 
  With the attached revert-patch my system is OK (with my customized X 
  stack).
 
  No indication of a GPU hang? I'm puzzled as to how this ends up with the
  scanout being misread.
 
  cat /sys/kernel/debug/dri/0/i915_gem_stolen
  cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
 
  would be interesting.

 Attached both outputs with GOOD and BAD (BROKEN) kernel.

 ggtt offset is the same for both setups, the only difference between the
 two is the location of fbcon in stolen memory.

 Can you please attach the output of intel_reg_dumper for good/bad? It's
 a long shot...

 Speaking of long shots, try this (slightly different to the earlier patch):

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index a21f935..37ad772 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
 BUG();
 }

 +   if (obj-stolen  INTEL_INFO(dev)-gen = 6)
 +   alignment = 256 * 1024;
 +
 /* Note that the w/a also requires 64 PTE of padding following the
  * bo. We currently fill all unused PTE with the shadow page and so
  * we should always have valid PTE following the scanout preventing


 --

Files attached.

- Sedat -
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 88010c54fe40: p g 
4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 
0008, size: 00408000) (stolen: 0006) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 88010c54fcc0: pXg  
   5120KiB 36 02 -591 -591 0 uncached dirty (name: 3) (pinned x 1) (display) 
(fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring)
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073fca200: p g 
4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 
0008, size: 00408000) (stolen: ) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880118928b40: pXg  
   5120KiB 36 02 -12 -12 0 uncached dirty (name: 3) (pinned x 1) (display) 
(fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring)
Stolen:
   880072c39c80: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable)
   880072c39800: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable)
   880072c39500: p g  128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 
1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable)
   88010c54fe40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 
1) (display) (ggtt offset: 0008, size: 00408000) (stolen: 0006) (p 
mappable)
Total 4 objects, 4620288 bytes, 4620288 GTT size
Stolen:
   880073fca200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 
1) (display) (ggtt offset: 0008, size: 00408000) (stolen: ) (p 
mappable)
Total 1 objects, 4227072 bytes, 4227072 GTT size

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
 Files attached.

Can you also please attach a full dmesg so I can check for anything
unusual?

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 (xfs)

2013-08-13 Thread Eric Sandeen

On 8/13/13 11:59 AM, Randy Dunlap wrote:
 On 08/13/13 01:28, Stephen Rothwell wrote:
 Hi all,

 Changes since 20130812:

 
 on i386:
 
 fs/built-in.o: In function `xfs_log_calc_minimum_size':
 (.text+0x1797a9): undefined reference to `__udivdi3'
 
 

See:

[PATCH] xfs: call roundup_64() to calculate the min_logblks

on the xfs list:

From: Jie Liu jeff@oracle.com

Replace roundup() with roundup_64() as we calculate min_logblks
with 64-bit divisions.  Hence, call roundup() will cause the
following error while compiling a 32-bit kernel:

fs/built-in.o: In function `xfs_log_calc_minimum_size':
fs/xfs/xfs_log_rlimit.c:140: undefined reference to `__udivdi3'

Reported-by: Fengguang Wu fengguang...@intel.com
Cc: Dave Chinner dchin...@redhat.com
Signed-off-by: Jie Liu jeff@oracle.com
---
 fs/xfs/xfs_log_rlimit.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_log_rlimit.c b/fs/xfs/xfs_log_rlimit.c
index 6b17ef4..bbcec0b 100644
--- a/fs/xfs/xfs_log_rlimit.c
+++ b/fs/xfs/xfs_log_rlimit.c
@@ -136,10 +136,12 @@ xfs_log_calc_minimum_size(
 * Also, the log size should be a multiple of the log stripe unit, round
 * it up to lsunit boundary if lsunit is specified.
 */
-   if (lsunit)
-   min_logblks = roundup(BTOBB(max_logres), lsunit) + 2 * lsunit;
-   else
+   if (lsunit) {
+   min_logblks = roundup_64(BTOBB(max_logres), lsunit) +
+ 2 * lsunit;
+   } else
min_logblks = BTOBB(max_logres) + 2 * BBSIZE;
min_logblks *= XFS_MIN_LOG_FACTOR;
+
return XFS_BB_TO_FSB(mp, min_logblks);
 }
-- 

-Eric
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
  Files attached.
 
  Can you also please attach a full dmesg so I can check for anything
  unusual?
 

Nothing scarred me on a couple of read throughs.

What happens if you try:

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 112c5e1..9828d9b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 
size)
return NULL;
 
ret = drm_mm_insert_node(dev_priv-mm.stolen, stolen, size,
-4096, DRM_MM_SEARCH_DEFAULT);
+1024*1024, DRM_MM_SEARCH_DEFAULT);
if (ret) {
kfree(stolen);
return NULL;

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
  Files attached.
 
  Can you also please attach a full dmesg so I can check for anything
  unusual?
 

 Nothing scarred me on a couple of read throughs.

 What happens if you try:

 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 112c5e1..9828d9b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 
 size)
 return NULL;

 ret = drm_mm_insert_node(dev_priv-mm.stolen, stolen, size,
 -4096, DRM_MM_SEARCH_DEFAULT);
 +1024*1024, DRM_MM_SEARCH_DEFAULT);
 if (ret) {
 kfree(stolen);
 return NULL;

 --

Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
from the top).
On the bottom I can read Ubuntu 12.04 LTS with the known background.
So-to-say 3/4 blind.

- Sedat -
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
  On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson ch...@chris-wilson.co.uk 
  wrote:
   On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
   Files attached.
  
   Can you also please attach a full dmesg so I can check for anything
   unusual?
  
 
  Nothing scarred me on a couple of read throughs.
 
  What happens if you try:
 
  diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
  b/drivers/gpu/drm/i915/i915_gem_stolen.c
  index 112c5e1..9828d9b 100644
  --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
  +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
  @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, 
  u32 size)
  return NULL;
 
  ret = drm_mm_insert_node(dev_priv-mm.stolen, stolen, size,
  -4096, DRM_MM_SEARCH_DEFAULT);
  +1024*1024, DRM_MM_SEARCH_DEFAULT);
  if (ret) {
  kfree(stolen);
  return NULL;
 
  --

 Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
 from the top).
 On the bottom I can read Ubuntu 12.04 LTS with the known background.
 So-to-say 3/4 blind.

 That implies that the scanout is always reading from the base of stolen.
 Can you grab intel_reg_dumper so that I can check what values the
 transcoder is set to?

 At the moment, I am guessing that the display never sees the updated
 surface offset and so persists with the value programmed by the BIOS -
 which will be 0 and set to the base of stolen memory in the GTT. A
 drm.debug=6 dmesg would help here as well.

 If you forced a mode change, I think that too would restore the output.

With which kernel? Vanilla next-20130813? With any of your patches?

- Sedat -
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
  On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson ch...@chris-wilson.co.uk 
  wrote:
   On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
   On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson 
   ch...@chris-wilson.co.uk wrote:
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
Files attached.
   
Can you also please attach a full dmesg so I can check for anything
unusual?
   
  
   Nothing scarred me on a couple of read throughs.
  
   What happens if you try:
  
   diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
   b/drivers/gpu/drm/i915/i915_gem_stolen.c
   index 112c5e1..9828d9b 100644
   --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
   +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
   @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device 
   *dev, u32 size)
   return NULL;
  
   ret = drm_mm_insert_node(dev_priv-mm.stolen, stolen, size,
   -4096, DRM_MM_SEARCH_DEFAULT);
   +1024*1024, DRM_MM_SEARCH_DEFAULT);
   if (ret) {
   kfree(stolen);
   return NULL;
  
   --
 
  Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
  from the top).
  On the bottom I can read Ubuntu 12.04 LTS with the known background.
  So-to-say 3/4 blind.
 
  That implies that the scanout is always reading from the base of stolen.
  Can you grab intel_reg_dumper so that I can check what values the
  transcoder is set to?
 
  At the moment, I am guessing that the display never sees the updated
  surface offset and so persists with the value programmed by the BIOS -
  which will be 0 and set to the base of stolen memory in the GTT. A
  drm.debug=6 dmesg would help here as well.
 
  If you forced a mode change, I think that too would restore the output.
 
 With which kernel? Vanilla next-20130813? With any of your patches?

Any but the working one ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Chris Wilson

On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
  On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson ch...@chris-wilson.co.uk 
  wrote:
   On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
   Files attached.
  
   Can you also please attach a full dmesg so I can check for anything
   unusual?
  
 
  Nothing scarred me on a couple of read throughs.
 
  What happens if you try:
 
  diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
  b/drivers/gpu/drm/i915/i915_gem_stolen.c
  index 112c5e1..9828d9b 100644
  --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
  +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
  @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, 
  u32 size)
  return NULL;
 
  ret = drm_mm_insert_node(dev_priv-mm.stolen, stolen, size,
  -4096, DRM_MM_SEARCH_DEFAULT);
  +1024*1024, DRM_MM_SEARCH_DEFAULT);
  if (ret) {
  kfree(stolen);
  return NULL;
 
  --
 
 Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
 from the top).
 On the bottom I can read Ubuntu 12.04 LTS with the known background.
 So-to-say 3/4 blind.

That implies that the scanout is always reading from the base of stolen.
Can you grab intel_reg_dumper so that I can check what values the
transcoder is set to?

At the moment, I am guessing that the display never sees the updated
surface offset and so persists with the value programmed by the BIOS -
which will be 0 and set to the base of stolen memory in the GTT. A
drm.debug=6 dmesg would help here as well.

If you forced a mode change, I think that too would restore the output.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

2013-08-13 Thread Sedat Dilek

On Tue, Aug 13, 2013 at 10:33 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
 On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
  On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson 
  ch...@chris-wilson.co.uk wrote:
   On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
   On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson 
   ch...@chris-wilson.co.uk wrote:
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
Files attached.
   
Can you also please attach a full dmesg so I can check for anything
unusual?
   
  
   Nothing scarred me on a couple of read throughs.
  
   What happens if you try:
  
   diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
   b/drivers/gpu/drm/i915/i915_gem_stolen.c
   index 112c5e1..9828d9b 100644
   --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
   +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
   @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device 
   *dev, u32 size)
   return NULL;
  
   ret = drm_mm_insert_node(dev_priv-mm.stolen, stolen, size,
   -4096, DRM_MM_SEARCH_DEFAULT);
   +1024*1024, DRM_MM_SEARCH_DEFAULT);
   if (ret) {
   kfree(stolen);
   return NULL;
  
   --
 
  Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
  from the top).
  On the bottom I can read Ubuntu 12.04 LTS with the known background.
  So-to-say 3/4 blind.
 
  That implies that the scanout is always reading from the base of stolen.
  Can you grab intel_reg_dumper so that I can check what values the
  transcoder is set to?
 
  At the moment, I am guessing that the display never sees the updated
  surface offset and so persists with the value programmed by the BIOS -
  which will be 0 and set to the base of stolen memory in the GTT. A
  drm.debug=6 dmesg would help here as well.
 
  If you forced a mode change, I think that too would restore the output.

 With which kernel? Vanilla next-20130813? With any of your patches?

 Any but the working one ;-)

 Damn Gmail, they switched again the UI, f***.

 This is d-i-n with Revert drm/i915: Allocate LLC ringbuffers from
 stolen --- working one (no screen corruptions).

 - Sedat -

 Vanilla next-20130813 after 1st login and logout-unity2d-plus-relogin-lightdm.
 The diff might be interesting as the 2nd login makes the issue go away.


intel_reg_dumper output attached.

- Sedat -
PGETBL_CTL: 0x
   GEN6_INSTDONE_1: 0xfffe
   GEN6_INSTDONE_2: 0x
  CPU_VGACNTRL: 0x8000 (disabled)
DIGITAL_PORT_HOTPLUG_CNTRL: 0x
 RR_HW_CTL: 0x (low 0, high 0)
FDI_PLL_BIOS_0: 0x
FDI_PLL_BIOS_1: 0x
FDI_PLL_BIOS_2: 0x
   DISPLAY_PORT_PLL_BIOS_0: 0x
   DISPLAY_PORT_PLL_BIOS_1: 0x
   DISPLAY_PORT_PLL_BIOS_2: 0x
  FDI_PLL_FREQ_CTL: 0x
 PIPEACONF: 0xc000 (enabled, active, pf-pd, rotate 0, 
8bpc)
  HTOTAL_A: 0x05cd0555 (1366 active, 1486 total)
  HBLANK_A: 0x05cd0555 (1366 start, 1486 end)
   HSYNC_A: 0x05a50585 (1414 start, 1446 end)
  VTOTAL_A: 0x031702ff (768 active, 792 total)
  VBLANK_A: 0x031702ff (768 start, 792 end)
   VSYNC_A: 0x03060301 (770 start, 775 end)
  VSYNCSHIFT_A: 0x
  PIPEASRC: 0x055502ff (1366, 768)
 PIPEA_DATA_M1: 0x7e32468a (TU 64, val 0x32468a 3294858)
 PIPEA_DATA_N1: 0x0040 (val 0x40 4194304)
 PIPEA_DATA_M2: 0x (TU 1, val 0x0 0)
 PIPEA_DATA_N2: 0x (val 0x0 0)
 PIPEA_LINK_M1: 0x00021845 (val 0x21845 137285)
 PIPEA_LINK_N1: 0x0008 (val 0x8 524288)
 PIPEA_LINK_M2: 0x (val 0x0 0)
 PIPEA_LINK_N2: 0x (val 0x0 0)
  DSPACNTR: 0xd8004400 (enabled)
  DSPABASE: 0x
DSPASTRIDE: 0x1600 (88)
  DSPASURF: 0x0047a000
   DSPATILEOFF: 0x (0, 0)
 PIPEBCONF: 0x (disabled, inactive, pf-pd, rotate 
0, 8bpc)
  HTOTAL_B: 0x (1 active, 1 total)
  HBLANK_B: 0x (1 start, 1 end)
   HSYNC_B: 0x (1 start, 1 end)
  VTOTAL_B: 0x (1 active, 1 total)

69 matches

Mail list logo