Re: davinci boot failures in next-20140519

2014-05-21 Thread Sekhar Nori 
On Tuesday 20 May 2014 10:32 PM, Prabhakar Lad wrote:
 Sekhar,
 
 I am not sure why this didnt work on your side you can find the boot log at 
 [1],
 I tested this on latest next.

I tried NFS after a long time. It could have been some setup issue.
Thanks for testing at your end.

Regards,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: davinci boot failures in next-20140519

2014-05-20 Thread Prabhakar Lad 
Hi,

On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote:
 As found by my automated boot tester[1], dm365 EVM and da850 EVM started
 failing boot tests in today's linux-next.

 I haven't had the time to bisect, but it appears to be related to some
 devres failures in the EMAC driver.  Full boot log below for the
 da850evm (the dm365 fault looks the same.)

I too hit this issue, this was introduced with commit id:
e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
davinci_cpdma: Convert kzalloc() to devm_kzalloc().)
Reverting this patch fixes it.
From the outset patch looks good, not sure why exactly it is failing.

Regards,
--Prabhakar Lad

 Kevin

 [1]
 http://lists.linaro.org/pipermail/kernel-build-reports/2014-May/003561.html



 Connected to da850evm console [channel connected] (~$quit to exit)
 (user:khilman) is already connected

 ~$hardreset

 Command(da850evm console) hardreset
 (user:khilman) Reboot da850evm
 `Reboot: da850evm ; phidget 4 2 :  off, sleep, on
 OMAP-L138 initialization passed!
 Booting TI User Boot Loader
 UBL Version: 1.65
 UBL Flashtype: SPI
 Starting SPI Memory Copy...
 Valid magicnum, 0x55424CBB, found at offset 0x0001.
DONE
 Jumping to entry point at 0xC108.
 MMC:   davinci: 0
 SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
 *** Warning - bad CRC, using default environment

 In:serial
 Out:   serial
 Err:   serial
 SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
 Net:   DaVinci-EMAC
 Hit any key to stop autoboot:
  3 0
 U-Boot 
 U-Boot  version
 version

 U-Boot 2014.01-dirty (Feb 27 2014 - 15:12:48)
 arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
 GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913
 U-Boot  setenv bootargs console=ttyS2,115200n8 debug earlyprintk
 setenv bootargs console=ttyS2,115200n8 debug earlyprintk
 U-Boot if test -n ${initenv}; then run initenv; fi
  if test -n ${initenv}; then run initenv; fi
 U-Boot  if test -n ${preboot}; then run preboot; fi
 if test -n ${preboot}; then run preboot; fi
 U-Boot setenv autoload no; setenv autoboot no
  setenv autoload no; setenv autoboot no
 U-Boot  dhcp
 dhcp
 BOOTP broadcast 1
 DHCP client bound to address 192.168.1.194
 U-Boot  setenv serverip 192.168.1.2
 setenv serverip 192.168.1.2
 U-Boot  if test -n ${netargs}; then run netargs; fi
 if test -n ${netargs}; then run netargs; fi
 U-Boot  tftp 0xc080 192.168.1.2:tmp/da850evm-ySSgF4/zImage-dtb-Ua2SNu
 tftp 0xc080 192.168.1.2:tmp/da850evm-ySSgF4/zImage-dtb-Ua2SNu
 Using DaVinci-EMAC device
 TFTP from server 192.168.1.2; our IP address is 192.168.1.194
 Filename 'tmp/da850evm-ySSgF4/zImage-dtb-Ua2SNu'.
 Load address: 0xc080
 Loading: * #
  #
  #
  1.7 MiB/s
 done
 Bytes transferred = 2261167 (2280af hex)
 U-Boot tftp 0xc0c0 192.168.1.2:buildroot.cpio.gz.uboot
  tftp 0xc0c0 192.168.1.2:buildroot.cpio.gz.uboot
 Using DaVinci-EMAC device
 TFTP from server 192.168.1.2; our IP address is 192.168.1.194
 Filename 'buildroot.cpio.gz.uboot'.
 Load address: 0xc0c0
 Loading: * 
  1.7 MiB/s
 done
 Bytes transferred = 642602 (9ce2a hex)
 U-Boot printenv bootargs
  printenv bootargs
 bootargs=console=ttyS2,115200n8 debug earlyprintk
 U-Boot  bootz 0xc080 0xc0c0
 bootz 0xc080 0xc0c0
 Kernel image @ 0xc080 [ 0x00 - 0x226598 ]
 ## Loading init Ramdisk from Legacy Image at c0c0 ...
Image Name:
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:642538 Bytes = 627.5 KiB
Load Address: 
Entry Point:  
Verifying Checksum ... OK

 Starting kernel ...

 Uncompressing Linux... done, booting the kernel.
 Booting Linux on physical CPU 0x0
 Linux version 3.15.0-rc5-next-20140519 (buildslave@kbuilderdedi01) (gcc 
 version 4.7.1 (Ubuntu/Linaro 4.7.1-5ubuntu1~ppa1) ) #1 PREEMPT Mon May 19 
 11:11:13 CEST 2014
 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
 CPU: VIVT data cache, VIVT instruction cache
 Machine model: DA850/AM1808/OMAP-L138 EVM
 Memory policy: Data cache writethrough
 DaVinci da850/omap-l138 variant 0x0
 On node 0 totalpages: 32768
 free_area_init_node: node 0, pgdat c045e6b0, node_mem_map c7efa000
   DMA zone: 256 pages used for memmap
   DMA zone: 0 pages reserved
   DMA zone: 32768 pages, LIFO batch:7
 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
 pcpu-alloc: [0] 0
 Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
 Kernel command line: console=ttyS2,115200n8 debug earlyprintk
 PID hash table entries: 512 (order: -1, 2048 bytes)
 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
 Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
 Memory: 124592K/131072K

Re: davinci boot failures in next-20140519

2014-05-20 Thread Sekhar Nori 
On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote:
 Hi,
 
 On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote:
 As found by my automated boot tester[1], dm365 EVM and da850 EVM started
 failing boot tests in today's linux-next.

 I haven't had the time to bisect, but it appears to be related to some
 devres failures in the EMAC driver.  Full boot log below for the
 da850evm (the dm365 fault looks the same.)

 I too hit this issue, this was introduced with commit id:
 e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
 davinci_cpdma: Convert kzalloc() to devm_kzalloc().)
 Reverting this patch fixes it.
 From the outset patch looks good, not sure why exactly it is failing.

Following patch seems to help. I will post it for review after some more
analysis.

Thanks,
Sekhar

diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/da
index e76eae5..9cd0d9c 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1930,7 +1930,7 @@ static int davinci_emac_probe(struct platform_device *pdev
hw_ram_addr = (u32 __force)res-start + pdata-ctrl_ram_offset;
 
memset(dma_params, 0, sizeof(dma_params));
-   dma_params.dev  = emac_dev;
+   dma_params.dev  = pdev-dev;
dma_params.dmaregs  = priv-emac_base;
dma_params.rxthresh = priv-emac_base + 0x120;
dma_params.rxfree   = priv-emac_base + 0x140;

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: davinci boot failures in next-20140519

2014-05-20 Thread Prabhakar Lad 
Hi Sekhar,

On Tue, May 20, 2014 at 1:43 PM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote:
 Hi,

 On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote:
 As found by my automated boot tester[1], dm365 EVM and da850 EVM started
 failing boot tests in today's linux-next.

 I haven't had the time to bisect, but it appears to be related to some
 devres failures in the EMAC driver.  Full boot log below for the
 da850evm (the dm365 fault looks the same.)

 I too hit this issue, this was introduced with commit id:
 e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
 davinci_cpdma: Convert kzalloc() to devm_kzalloc().)
 Reverting this patch fixes it.
 From the outset patch looks good, not sure why exactly it is failing.

 Following patch seems to help. I will post it for review after some more
 analysis.

I am not sure if you hit the following issue later fixing above one,
I see following issue on DA850 evm,

git bisect points me to
commit id: 975c3a671f11279441006a29a19f55ccc15fb320
( mm: non-atomically mark page accessed during page cache allocation
where possible)

Unable to handle kernel paging request at virtual address 30e03501
pgd = c68cc000
[30e03501] *pgd=
Internal error: Oops: 1 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1015 Comm: network.sh Not tainted 3.15.0-rc5-00323-g975c3a6 #9
task: c70c4e00 ti: c73d task.ti: c73d
PC is at init_page_accessed+0xc/0x24
LR is at shmem_write_begin+0x54/0x60
pc : [c0088aa0]lr : [c00923e8]psr: 2013
sp : c73d1d90  ip : c73d1da0  fp : c73d1d9c
r10: c73d1dec  r9 :   r8 : 
r7 : c73d1e6c  r6 : c694d7bc  r5 : ffe4  r4 : c73d1dec
r3 : c73d  r2 : 0001  r1 :   r0 : 30e03501
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: c68cc000  DAC: 0015
Process network.sh (pid: 1015, stack limit = 0xc73d01c0)
Stack: (0xc73d1d90 to 0xc73d2000)
1d80: c73d1dbc c73d1da0 c00923e8 c0088aa4
1da0: 000200da  0005  c73d1e1c c73d1dc0 c0079d5c c00923a4
1dc0: 0005  c73d1dec c73d1de8  c73d 1000 c0347920
1de0: c68b1000  000a 30e03501 000a c73d c68b1000 c694d7bc
1e00: c73d1ef0 0005 00020401 0005 c73d1eac c73d1e20 c007cb7c c0079bf4
1e20: c73d1e4c c73d c73d1e4c c73d1e38 c00429ac c694d700 0005 
1e40: c73d1e94  c033d5c8 c0042858 c73d1f28 c73d1eb0  
1e60:  0001 b6fcf000 c73d1f28 0001  0005 0005
1e80: c73d c68b1000 c73d1ef0 0001 c694d75c c73d1f28 c73d 
1ea0: c73d1ee4 c73d1eb0 c007cddc c007c884 c000b540 c000c36c c73d1f7c c73d1f50
1ec0: c73d1ef0 c70c4e00 c73d1f80 c73d1f80 c00098a4 c73d c73d1f4c c73d1ee8
1ee0: c00bb0f0 c007cd80   c68b1000   
1f00: c70c4e00      0005 
1f20:   b6fcf000 0005 c73d1f80 c68b1000 0005 b6fcf000
1f40: c73d1f7c c73d1f50 c00bc240 c00bb06c c00d8378 c00d82dc c68b1000 c68b1000
1f60: 0005 b6fcf000 c00098a4  c73d1fa4 c73d1f80 c00bc3f4 c00bc198
1f80:   0005 b6fcf000 b6efd5e8 0004  c73d1fa8
1fa0: c0009740 c00bc3bc 0005 b6fcf000 0001 b6fcf000 0005 
1fc0: 0005 b6fcf000 b6efd5e8 0004 0005 000ad3f0 0001 000ad008
1fe0: b6fcf000 bef1e1c8 b6e3bc70 b6e8babc 6010 0001  
Backtrace:
[c0088a94] (init_page_accessed) from [c00923e8]
(shmem_write_begin+0x54/0x60)
[c0092394] (shmem_write_begin) from [c0079d5c]
(generic_perform_write+0x178/0x1e0)
 r5: r4:0005
[c0079be4] (generic_perform_write) from [c007cb7c]
(__generic_file_aio_write+0x308/0x4fc)
 r10:0005 r9:00020401 r8:0005 r7:c73d1ef0 r6:c694d7bc r5:c68b1000
 r4:c73d
[c007c874] (__generic_file_aio_write) from [c007cddc]
(generic_file_aio_write+0x6c/0x100)
 r10: r9:c73d r8:c73d1f28 r7:c694d75c r6:0001 r5:c73d1ef0
 r4:c68b1000
[c007cd70] (generic_file_aio_write) from [c00bb0f0]
(do_sync_write+0x94/0xbc)
 r9:c73d r8:c00098a4 r7:c73d1f80 r6:c73d1f80 r5:c70c4e00 r4:c73d1ef0
[c00bb05c] (do_sync_write) from [c00bc240] (vfs_write+0xb8/0x190)
 r6:b6fcf000 r5:0005 r4:c68b1000
[c00bc188] (vfs_write) from [c00bc3f4] (SyS_write+0x48/0x8c)
 r10: r8:c00098a4 r7:b6fcf000 r6:0005 r5:c68b1000 r4:c68b1000
[c00bc3ac] (SyS_write) from [c0009740] (ret_fast_syscall+0x0/0x2c)
 r7:0004 r6:b6efd5e8 r5:b6fcf000 r4:0005
Code: e89da830 e1a0c00d e92dd800 e24cb004 (e5903000)
---[ end trace 37a953844ea656a1 ]---
Unable to handle kernel paging request at virtual address 26be3681
pgd = c68a
[26be3681] *pgd=
Internal error: Oops: 1 [#2] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1155 Comm: udevd Tainted: G  D
3.15.0-rc5-00323-g975c3a6 #9
task: c7264a80 ti: c7108000 task.ti: c7108000
PC is at

Re: davinci boot failures in next-20140519

2014-05-20 Thread Sekhar Nori 
On Tuesday 20 May 2014 02:46 PM, Prabhakar Lad wrote:
 Hi Sekhar,
 
 On Tue, May 20, 2014 at 1:43 PM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote:
 Hi,

 On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote:
 As found by my automated boot tester[1], dm365 EVM and da850 EVM started
 failing boot tests in today's linux-next.

 I haven't had the time to bisect, but it appears to be related to some
 devres failures in the EMAC driver.  Full boot log below for the
 da850evm (the dm365 fault looks the same.)

 I too hit this issue, this was introduced with commit id:
 e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
 davinci_cpdma: Convert kzalloc() to devm_kzalloc().)
 Reverting this patch fixes it.
 From the outset patch looks good, not sure why exactly it is failing.

 Following patch seems to help. I will post it for review after some more
 analysis.

 I am not sure if you hit the following issue later fixing above one,
 I see following issue on DA850 evm,

No, I am using ramdisk though. Are you using NFS?

 
 git bisect points me to
 commit id: 975c3a671f11279441006a29a19f55ccc15fb320
 ( mm: non-atomically mark page accessed during page cache allocation
 where possible)

Does reverting this cause the issue to disappear?

Thanks,
Sekhar

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: davinci boot failures in next-20140519

2014-05-20 Thread Prabhakar Lad 
On Tue, May 20, 2014 at 2:51 PM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 20 May 2014 02:46 PM, Prabhakar Lad wrote:
 Hi Sekhar,

 On Tue, May 20, 2014 at 1:43 PM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote:
 Hi,

 On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote:
 As found by my automated boot tester[1], dm365 EVM and da850 EVM started
 failing boot tests in today's linux-next.

 I haven't had the time to bisect, but it appears to be related to some
 devres failures in the EMAC driver.  Full boot log below for the
 da850evm (the dm365 fault looks the same.)

 I too hit this issue, this was introduced with commit id:
 e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
 davinci_cpdma: Convert kzalloc() to devm_kzalloc().)
 Reverting this patch fixes it.
 From the outset patch looks good, not sure why exactly it is failing.

 Following patch seems to help. I will post it for review after some more
 analysis.

 I am not sure if you hit the following issue later fixing above one,
 I see following issue on DA850 evm,

 No, I am using ramdisk though. Are you using NFS?

Yes I am using NFS.


 git bisect points me to
 commit id: 975c3a671f11279441006a29a19f55ccc15fb320
 ( mm: non-atomically mark page accessed during page cache allocation
 where possible)

 Does reverting this cause the issue to disappear?

Yep reverting this patch fixes it up back again.

Thanks,
--Prabhakar Lad
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: davinci boot failures in next-20140519

2014-05-20 Thread Mel Gorman 
On Tue, May 20, 2014 at 02:46:47PM +0530, Prabhakar Lad wrote:
 Hi Sekhar,
 
 On Tue, May 20, 2014 at 1:43 PM, Sekhar Nori nsek...@ti.com wrote:
  On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote:
  Hi,
 
  On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote:
  As found by my automated boot tester[1], dm365 EVM and da850 EVM started
  failing boot tests in today's linux-next.
 
  I haven't had the time to bisect, but it appears to be related to some
  devres failures in the EMAC driver.  Full boot log below for the
  da850evm (the dm365 fault looks the same.)
 
  I too hit this issue, this was introduced with commit id:
  e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
  davinci_cpdma: Convert kzalloc() to devm_kzalloc().)
  Reverting this patch fixes it.
  From the outset patch looks good, not sure why exactly it is failing.
 
  Following patch seems to help. I will post it for review after some more
  analysis.
 
 I am not sure if you hit the following issue later fixing above one,
 I see following issue on DA850 evm,
 
 git bisect points me to
 commit id: 975c3a671f11279441006a29a19f55ccc15fb320
 ( mm: non-atomically mark page accessed during page cache allocation
 where possible)
 
 Unable to handle kernel paging request at virtual address 30e03501
 pgd = c68cc000
 [30e03501] *pgd=
 Internal error: Oops: 1 [#1] PREEMPT ARM
 Modules linked in:
 CPU: 0 PID: 1015 Comm: network.sh Not tainted 3.15.0-rc5-00323-g975c3a6 #9
 task: c70c4e00 ti: c73d task.ti: c73d
 PC is at init_page_accessed+0xc/0x24
 LR is at shmem_write_begin+0x54/0x60
 pc : [c0088aa0]lr : [c00923e8]psr: 2013

What line does this address correspond to according to addr2line? It's not
a NULL pointer exception obviously because the data address does not match
up and there is a check for NULL before calling init_page_accessed. The
obvious guess would be that this is due to an uninitialised page pointer
on the stack and shmem_getpage_gfp() returning before it gets initialised.

Could you try this please?

diff --git a/mm/filemap.c b/mm/filemap.c
index 2a7b9d1..0691481 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2459,7 +2459,7 @@ ssize_t generic_perform_write(struct file *file,
flags |= AOP_FLAG_UNINTERRUPTIBLE;
 
do {
-   struct page *page;
+   struct page *page = NULL;
unsigned long offset;   /* Offset into pagecache page */
unsigned long bytes;/* Bytes to write to page */
size_t copied;  /* Bytes copied from user */
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: davinci boot failures in next-20140519

2014-05-20 Thread Sekhar Nori 
On Tuesday 20 May 2014 05:29 PM, Mel Gorman wrote:
 On Tue, May 20, 2014 at 02:46:47PM +0530, Prabhakar Lad wrote:
 Hi Sekhar,

 On Tue, May 20, 2014 at 1:43 PM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote:
 Hi,

 On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote:
 As found by my automated boot tester[1], dm365 EVM and da850 EVM started
 failing boot tests in today's linux-next.

 I haven't had the time to bisect, but it appears to be related to some
 devres failures in the EMAC driver.  Full boot log below for the
 da850evm (the dm365 fault looks the same.)

 I too hit this issue, this was introduced with commit id:
 e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
 davinci_cpdma: Convert kzalloc() to devm_kzalloc().)
 Reverting this patch fixes it.
 From the outset patch looks good, not sure why exactly it is failing.

 Following patch seems to help. I will post it for review after some more
 analysis.

 I am not sure if you hit the following issue later fixing above one,
 I see following issue on DA850 evm,

 git bisect points me to
 commit id: 975c3a671f11279441006a29a19f55ccc15fb320
 ( mm: non-atomically mark page accessed during page cache allocation
 where possible)

 Unable to handle kernel paging request at virtual address 30e03501
 pgd = c68cc000
 [30e03501] *pgd=
 Internal error: Oops: 1 [#1] PREEMPT ARM
 Modules linked in:
 CPU: 0 PID: 1015 Comm: network.sh Not tainted 3.15.0-rc5-00323-g975c3a6 #9
 task: c70c4e00 ti: c73d task.ti: c73d
 PC is at init_page_accessed+0xc/0x24
 LR is at shmem_write_begin+0x54/0x60
 pc : [c0088aa0]lr : [c00923e8]psr: 2013
 
 What line does this address correspond to according to addr2line? It's not

addr2line shows mm/swap.c:622

objdump shows that page pointer is corrupt in init_page_accessed()

c00805ec init_page_accessed:
/*
 * Used to mark_page_accessed(page) that is not visible yet and when it is
 * still safe to use non-atomic ops
 */
void init_page_accessed(struct page *page)
{
c00805ec:   e1a0c00dmov ip, sp
c00805f0:   e92dd800push{fp, ip, lr, pc}
c00805f4:   e24cb004sub fp, ip, #4
c00805f8:   e5903000ldr r3, [r0]
if (!PageReferenced(page))
c00805fc:   e3130004tst r3, #4

When crash occurs, instruction at address c00805f8 crashes with r0 corrupt.
Attached[1] is the corresponding oops message.

 Could you try this please?
 
 diff --git a/mm/filemap.c b/mm/filemap.c
 index 2a7b9d1..0691481 100644
 --- a/mm/filemap.c
 +++ b/mm/filemap.c
 @@ -2459,7 +2459,7 @@ ssize_t generic_perform_write(struct file *file,
   flags |= AOP_FLAG_UNINTERRUPTIBLE;
  
   do {
 - struct page *page;
 + struct page *page = NULL;
   unsigned long offset;   /* Offset into pagecache page */
   unsigned long bytes;/* Bytes to write to page */
   size_t copied;  /* Bytes copied from user */

This definitely avoided the oops, but I am still not able to get nfsroot 
working 
(it starts to mount the filesystem and eventually timesout). It could be a 
different
problem. Need to get to a known working setup and then bisect.

Thanks,
Sekhar

[1] oops log that I observed.

Unable to handle kernel NULL pointer dereference at virtual address 000b
pgd = c703
[000b] *pgd=c7a9e831, *pte=, *ppte=
Internal error: Oops: 1 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 976 Comm: udevd Not tainted 3.15.0-rc5-next-20140519-07053-g0855e8f 
#384
task: c7a7d500 ti: c7ad6000 task.ti: c7ad6000
PC is at init_page_accessed+0xc/0x24
LR is at shmem_write_begin+0x58/0x64
pc : [c00805f8]lr : [c0089d5c]psr: 2013
sp : c7ad7da8  ip : c7ad7db8  fp : c7ad7db4
r10: c0312600  r9 : c7ad7ee8  r8 : 
r7 : 1000  r6 : c7ba365c  r5 : ffe4  r4 : c7ad7e00
r3 :   r2 : 0001  r1 : c7ad7d60  r0 : 000b
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: c703  DAC: 0015
Process udevd (pid: 976, stack limit = 0xc7ad61c0)
Stack: (0xc7ad7da8 to 0xc7ad8000)
7da0:   c7ad7dd4 c7ad7db8 c0089d5c c00805fc 000200da 
7dc0: 0005 c7ad7ed4 c7ad7e34 c7ad7dd8 c00751f0 c0089d14 0005 
7de0: c7ad7e00 c7ad7e04 c7ad6000  c715e500   
7e00: 000b 13ab6681 000b   0005 c715e500 c7ad6038
7e20: c7ad7ee8 c7ba365c c7ad7e8c c7ad7e38 c0077274 c007509c c0026850 c002648c
7e40: c7a7d7b4 c7ad7e90 c7ad7e74  c7ba35fc c7ad7ed4 c7ad7ed4 c7a7d500
7e60: beeffc58 c7ad7ee8 c7ba35fc c7ad7ed4 c715e500 c7a7d500 beeffc58 
7e80: c7ad7ebc c7ad7e90 c0077568 c0077110 c7ad7ebc c7ad7ea0 c000c064 c000b118
7ea0:   c7ad7f78 c715e500 c7ad7f44 c7ad7ec0 c00aedb8 c007753c
7ec0: 0005 c00af6b0 c7ad7f74 beeffc58 0005 0001  0005
7ee0: c7ad7ecc 0001

Re: davinci boot failures in next-20140519

2014-05-20 Thread Prabhakar Lad 
Hi,

On Tue, May 20, 2014 at 5:29 PM, Mel Gorman mgor...@suse.de wrote:
 On Tue, May 20, 2014 at 02:46:47PM +0530, Prabhakar Lad wrote:
 Hi Sekhar,

 On Tue, May 20, 2014 at 1:43 PM, Sekhar Nori nsek...@ti.com wrote:
  On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote:
  Hi,
 
  On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote:
  As found by my automated boot tester[1], dm365 EVM and da850 EVM started
  failing boot tests in today's linux-next.
 
  I haven't had the time to bisect, but it appears to be related to some
  devres failures in the EMAC driver.  Full boot log below for the
  da850evm (the dm365 fault looks the same.)
 
  I too hit this issue, this was introduced with commit id:
  e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
  davinci_cpdma: Convert kzalloc() to devm_kzalloc().)
  Reverting this patch fixes it.
  From the outset patch looks good, not sure why exactly it is failing.
 
  Following patch seems to help. I will post it for review after some more
  analysis.
 
 I am not sure if you hit the following issue later fixing above one,
 I see following issue on DA850 evm,

 git bisect points me to
 commit id: 975c3a671f11279441006a29a19f55ccc15fb320
 ( mm: non-atomically mark page accessed during page cache allocation
 where possible)

 Unable to handle kernel paging request at virtual address 30e03501
 pgd = c68cc000
 [30e03501] *pgd=
 Internal error: Oops: 1 [#1] PREEMPT ARM
 Modules linked in:
 CPU: 0 PID: 1015 Comm: network.sh Not tainted 3.15.0-rc5-00323-g975c3a6 #9
 task: c70c4e00 ti: c73d task.ti: c73d
 PC is at init_page_accessed+0xc/0x24
 LR is at shmem_write_begin+0x54/0x60
 pc : [c0088aa0]lr : [c00923e8]psr: 2013

 What line does this address correspond to according to addr2line? It's not
 a NULL pointer exception obviously because the data address does not match
 up and there is a check for NULL before calling init_page_accessed. The
 obvious guess would be that this is due to an uninitialised page pointer
 on the stack and shmem_getpage_gfp() returning before it gets initialised.

 Could you try this please?

 diff --git a/mm/filemap.c b/mm/filemap.c
 index 2a7b9d1..0691481 100644
 --- a/mm/filemap.c
 +++ b/mm/filemap.c
 @@ -2459,7 +2459,7 @@ ssize_t generic_perform_write(struct file *file,
 flags |= AOP_FLAG_UNINTERRUPTIBLE;

 do {
 -   struct page *page;
 +   struct page *page = NULL;
 unsigned long offset;   /* Offset into pagecache page */
 unsigned long bytes;/* Bytes to write to page */
 size_t copied;  /* Bytes copied from user */

This patch fixes the issue now I am able to boot it back again via NFS,
you can add:

Reported-and-Tested-by: Lad, Prabhakar prabhakar.cse...@gmail.com

Sekhar,

I am not sure why this didnt work on your side you can find the boot log at [1],
I tested this on latest next.

Regards,
--Prabhakar Lad

[1] Boot Log

U-Boot SPL 2013.01-00010-g25dc42f (Jan 22 2013 - 12:26:23)
SF: Detected M25P64 with page size 64 KiB, total 8 MiB


U-Boot 2013.01-00010-g25dc42f (Jan 22 2013 - 12:26:23)

I2C:   ready
DRAM:  128 MiB
WARNING: Caches not enabled
MMC:   davinci: 0
SF: Detected M25P64 with page size 64 KiB, total 8 MiB
In:serial
Out:   serial
Err:   serial
SF: Detected M25P64 with page size 64 KiB, total 8 MiB
Default using MAC address from environment
Default using MAC address from environment
Net:   DaVinci-EMAC
Hit any key to stop autoboot:  0
U-Boot 
U-Boot 
U-Boot 
U-Boot  tftp uImage;bootm
Using DaVinci-EMAC device
TFTP from server 169.254.243.186; our IP address is 169.254.243.185
Filename 'uImage'.
Load address: 0xc070
Loading: #
 #
 #
 #
 #
 #
 #
 
 1.3 MiB/s
done
Bytes transferred = 2472672 (25bae0 hex)
## Booting kernel from Legacy Image at c070 ...
   Image Name:   Linux-3.15.0-rc5-next-20140520-0
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:2472608 Bytes = 2.4 MiB
   Load Address: c0008000
   Entry Point:  c0008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.15.0-rc5-next-20140520-1-g68d7f74-dirty
(prabhakar@tango-charlie) (gcc version 4.4.1 (Sourcery G++ Lite
2009q3-67) ) #2 PREEM4
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache,