2.6.34-rc3: Badness at kernel/lockdep.c:2706

2010-04-02 Thread Sachin Sant

With 2.6.34-rc3 boot on a Power5 box :

loop: module loaded
BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ cut here ]
Badness at kernel/lockdep.c:2706
NIP: c010a0a8 LR: c010a08c CTR: c00704a4
REGS: c001096d76f0 TRAP: 0700   Not tainted  (2.6.34-rc3)
MSR: 80029032 EE,ME,CE,IR,DR  CR: 2882  XER: 0009
TASK = c001fa6f8000[1] 'swapper' THREAD: c001096d4000 CPU: 12
GPR00:  c001096d7970 c1322e38 0001
GPR04: 0001 c00c1ea8  0002
GPR08:  c1cc5a00 2422 c137d768
GPR12: 0002 cf66e400 00d47940 01c0
GPR16:  02673148 018ff984 0060
GPR20:   0253a291 018ff990
GPR24: 018ff988 c1229ef0  c0010793a730
GPR28: 6b6b6b6b6b6b6b6b c0010793afd8 c1299de0 c001096d7970
NIP [c010a0a8] .lockdep_init_map+0x12c/0x538
LR [c010a08c] .lockdep_init_map+0x110/0x538
Call Trace:
[c001096d7970] [c010a074] .lockdep_init_map+0xf8/0x538 (unreliable)
[c001096d7a30] [c0274eac] .sysfs_add_file_mode+0x90/0x124
[c001096d7af0] [c0274f7c] .sysfs_add_file+0x3c/0x50
[c001096d7b90] [c02750d8] .sysfs_create_file+0x5c/0x74
[c001096d7c30] [c04b36a0] .device_create_file+0x40/0x5c
[c001096d7cd0] [c04db384] .wf_register_control+0x108/0x178
[c001096d7d80] [c0a5f7cc] .wf_cpufreq_clamp_init+0x11c/0x16c
[c001096d7e20] [c000a104] .do_one_initcall+0xb0/0x208
[c001096d7ed0] [c0a12568] .kernel_init+0x230/0x2f0
[c001096d7f90] [c0033b20] .kernel_thread+0x54/0x70
Instruction dump:
e93e8190 8009 2f80 409e03f8 48280539 6000 2fa3 419e03e8
e93e8198 8009 2f80 409e03d8 0fe0 480003d0 e93e8140 fb9d
Uniform Multi-Platform E-IDE driver

Thanks
-Sachin

--

-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: 2.6.34-rc3 : Badness at lib/dma-debug.c:820 during ibmvscsi init

2010-04-02 Thread FUJITA Tomonori
On Fri, 02 Apr 2010 10:48:55 +0530
Sachin Sant sach...@in.ibm.com wrote:

 2.6.34-rc3 boot on a power5 box produces this badness message
 during ibmvscsi initialization.
 
 ibmvscsi 3003: Client reserve enabled
 ibmvscsi 3003: sent SRP login
 ibmvscsi 3003: SRP_LOGIN succeeded
 ibmvscsi 3003: DMA-API: device driver frees DMA memory with wrong 
 function [device address=0x00011520] [size=36 bytes] [mapped as 
 scather-gather] [unmapped as single]

ibmvscsi has been incompatible with the dma debug facility, I
guess. The driver uses dma_unmap_single for buffers mapped via
dma_map_sg. It works but it's the API violation.

Does this patch work?

diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index dc1bcbe..0856436 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -322,16 +322,6 @@ static void set_srp_direction(struct scsi_cmnd *cmd,
srp_cmd-buf_fmt = fmt;
 }
 
-static void unmap_sg_list(int num_entries,
-   struct device *dev,
-   struct srp_direct_buf *md)
-{
-   int i;
-
-   for (i = 0; i  num_entries; ++i)
-   dma_unmap_single(dev, md[i].va, md[i].len, DMA_BIDIRECTIONAL);
-}
-
 /**
  * unmap_cmd_data: - Unmap data pointed in srp_cmd based on the format
  * @cmd:   srp_cmd whose additional_data member will be unmapped
@@ -349,24 +339,9 @@ static void unmap_cmd_data(struct srp_cmd *cmd,
 
if (out_fmt == SRP_NO_DATA_DESC  in_fmt == SRP_NO_DATA_DESC)
return;
-   else if (out_fmt == SRP_DATA_DESC_DIRECT ||
-in_fmt == SRP_DATA_DESC_DIRECT) {
-   struct srp_direct_buf *data =
-   (struct srp_direct_buf *) cmd-add_data;
-   dma_unmap_single(dev, data-va, data-len, DMA_BIDIRECTIONAL);
-   } else {
-   struct srp_indirect_buf *indirect =
-   (struct srp_indirect_buf *) cmd-add_data;
-   int num_mapped = indirect-table_desc.len /
-   sizeof(struct srp_direct_buf);
 
-   if (num_mapped = MAX_INDIRECT_BUFS) {
-   unmap_sg_list(num_mapped, dev, indirect-desc_list[0]);
-   return;
-   }
-
-   unmap_sg_list(num_mapped, dev, evt_struct-ext_list);
-   }
+   if (evt_struct-cmnd)
+   scsi_dma_unmap(evt_struct-cmnd);
 }
 
 static int map_sg_list(struct scsi_cmnd *cmd, int nseg,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: 2.6.34-rc3 : Badness at lib/dma-debug.c:820 during ibmvscsi init

2010-04-02 Thread Sachin Sant

FUJITA Tomonori wrote:

On Fri, 02 Apr 2010 10:48:55 +0530
Sachin Sant sach...@in.ibm.com wrote:

  

2.6.34-rc3 boot on a power5 box produces this badness message
during ibmvscsi initialization.

ibmvscsi 3003: Client reserve enabled
ibmvscsi 3003: sent SRP login
ibmvscsi 3003: SRP_LOGIN succeeded
ibmvscsi 3003: DMA-API: device driver frees DMA memory with wrong function 
[device address=0x00011520] [size=36 bytes] [mapped as scather-gather] 
[unmapped as single]



ibmvscsi has been incompatible with the dma debug facility, I
guess. The driver uses dma_unmap_single for buffers mapped via
dma_map_sg. It works but it's the API violation.

Does this patch work?
  

Yes, this patch fixed the issue for me. Thanks

-Regards
-Sachin


diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index dc1bcbe..0856436 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -322,16 +322,6 @@ static void set_srp_direction(struct scsi_cmnd *cmd,
srp_cmd-buf_fmt = fmt;
 }

-static void unmap_sg_list(int num_entries,
-   struct device *dev,
-   struct srp_direct_buf *md)
-{
-   int i;
-
-   for (i = 0; i  num_entries; ++i)
-   dma_unmap_single(dev, md[i].va, md[i].len, DMA_BIDIRECTIONAL);
-}
-
 /**
  * unmap_cmd_data: - Unmap data pointed in srp_cmd based on the format
  * @cmd:   srp_cmd whose additional_data member will be unmapped
@@ -349,24 +339,9 @@ static void unmap_cmd_data(struct srp_cmd *cmd,

if (out_fmt == SRP_NO_DATA_DESC  in_fmt == SRP_NO_DATA_DESC)
return;
-   else if (out_fmt == SRP_DATA_DESC_DIRECT ||
-in_fmt == SRP_DATA_DESC_DIRECT) {
-   struct srp_direct_buf *data =
-   (struct srp_direct_buf *) cmd-add_data;
-   dma_unmap_single(dev, data-va, data-len, DMA_BIDIRECTIONAL);
-   } else {
-   struct srp_indirect_buf *indirect =
-   (struct srp_indirect_buf *) cmd-add_data;
-   int num_mapped = indirect-table_desc.len /
-   sizeof(struct srp_direct_buf);

-   if (num_mapped = MAX_INDIRECT_BUFS) {
-   unmap_sg_list(num_mapped, dev, indirect-desc_list[0]);
-   return;
-   }
-
-   unmap_sg_list(num_mapped, dev, evt_struct-ext_list);
-   }
+   if (evt_struct-cmnd)
+   scsi_dma_unmap(evt_struct-cmnd);
 }

 static int map_sg_list(struct scsi_cmnd *cmd, int nseg,

  



--

-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: 2.6.34-rc3 : Badness at lib/dma-debug.c:820 during ibmvscsi init

2010-04-02 Thread FUJITA Tomonori
On Fri, 02 Apr 2010 12:07:58 +0530
Sachin Sant sach...@in.ibm.com wrote:

 FUJITA Tomonori wrote:
  On Fri, 02 Apr 2010 10:48:55 +0530
  Sachin Sant sach...@in.ibm.com wrote:
 

  2.6.34-rc3 boot on a power5 box produces this badness message
  during ibmvscsi initialization.
 
  ibmvscsi 3003: Client reserve enabled
  ibmvscsi 3003: sent SRP login
  ibmvscsi 3003: SRP_LOGIN succeeded
  ibmvscsi 3003: DMA-API: device driver frees DMA memory with wrong 
  function [device address=0x00011520] [size=36 bytes] [mapped as 
  scather-gather] [unmapped as single]
  
 
  ibmvscsi has been incompatible with the dma debug facility, I
  guess. The driver uses dma_unmap_single for buffers mapped via
  dma_map_sg. It works but it's the API violation.
 
  Does this patch work?

 Yes, this patch fixed the issue for me. Thanks

Thanks, here's the patch in the proper format.

=
From: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Subject: [PATCH] ibmvscsi: fix DMA API misuse

ibmvscsi uses dma_unmap_single() for buffers mapped via
dma_map_sg(). It works however it's the API violation. The DMA debug
facility complains about it:

http://marc.info/?l=linux-scsim=127018555013151w=2

Reported-by: Sachin Sant sach...@in.ibm.com
Tested-by: Sachin Sant sach...@in.ibm.com
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
 drivers/scsi/ibmvscsi/ibmvscsi.c |   29 ++---
 1 files changed, 2 insertions(+), 27 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index dc1bcbe..0856436 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -322,16 +322,6 @@ static void set_srp_direction(struct scsi_cmnd *cmd,
srp_cmd-buf_fmt = fmt;
 }
 
-static void unmap_sg_list(int num_entries,
-   struct device *dev,
-   struct srp_direct_buf *md)
-{
-   int i;
-
-   for (i = 0; i  num_entries; ++i)
-   dma_unmap_single(dev, md[i].va, md[i].len, DMA_BIDIRECTIONAL);
-}
-
 /**
  * unmap_cmd_data: - Unmap data pointed in srp_cmd based on the format
  * @cmd:   srp_cmd whose additional_data member will be unmapped
@@ -349,24 +339,9 @@ static void unmap_cmd_data(struct srp_cmd *cmd,
 
if (out_fmt == SRP_NO_DATA_DESC  in_fmt == SRP_NO_DATA_DESC)
return;
-   else if (out_fmt == SRP_DATA_DESC_DIRECT ||
-in_fmt == SRP_DATA_DESC_DIRECT) {
-   struct srp_direct_buf *data =
-   (struct srp_direct_buf *) cmd-add_data;
-   dma_unmap_single(dev, data-va, data-len, DMA_BIDIRECTIONAL);
-   } else {
-   struct srp_indirect_buf *indirect =
-   (struct srp_indirect_buf *) cmd-add_data;
-   int num_mapped = indirect-table_desc.len /
-   sizeof(struct srp_direct_buf);
 
-   if (num_mapped = MAX_INDIRECT_BUFS) {
-   unmap_sg_list(num_mapped, dev, indirect-desc_list[0]);
-   return;
-   }
-
-   unmap_sg_list(num_mapped, dev, evt_struct-ext_list);
-   }
+   if (evt_struct-cmnd)
+   scsi_dma_unmap(evt_struct-cmnd);
 }
 
 static int map_sg_list(struct scsi_cmnd *cmd, int nseg,
-- 
1.7.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH RESEND 2/3] i2c/cpm: drop NO_IRQ

2010-04-02 Thread Jochen Friedrich

Wolfram Sang wrote:


Drop NO_IRQ as 0 is the preferred way to describe 'no irq'



Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Acked-by: Grant Likely grant.lik...@secretlab.ca

Acked-by: Jochen Friedrich joc...@scram.de

Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [Cbe-oss-dev] No otheros feature on new PS3 slim ?

2010-04-02 Thread Michel Dänzer
On Fri, 2010-02-26 at 12:30 +, David Woodhouse wrote: 
 On Fri, 2009-08-21 at 09:58 -0700, geoffrey.lev...@am.sony.com wrote:
  The feature of Install Other OS was removed from the new
  Slim PS3 model to focus on delivering games and other
  entertainment content. 
  
  Please be assured that SCE is committed to continue
  the support for previously sold models that have the
  Install Other OS feature and that this feature will
  not be disabled in future firmware releases.
 
 Although it's disappointing that Sony have removed the feature from new
 models, It's good to have this public assurance from Sony that at least
 the feature won't be removed from older models which are already
 working.
 
 I suppose it shouldn't be too much of a surprise -- if people have
 bought PS3s specifically to use the advertised 'OtherOS' feature and
 Sony were to break that with a firmware update, then there may well be
 legal ramifications. But it's nice to have the promise in writing
 anyway.

Unfortunately, it wasn't enough - firmware version 3.21 completely
removes 'other OS' support due to 'security concerns'. :(

http://blog.us.playstation.com/2010/03/28/ps3-firmware-v3-21-update/


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/3] arch/powerpc/platforms: Eliminate use after free

2010-04-02 Thread Julia Lawall
From: Julia Lawall ju...@diku.dk

dlpar_free_cc_nodes frees its argument, so dlpar_online_cpu should not be
called on the same value.  Skip over the call to dlpar_online_cpu by
jumping directly to out.

A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// smpl
@@
expression E,E2;
@@

dlpar_free_cc_nodes(E)
...
(
  E = E2
|
* E
)
// /smpl

Signed-off-by: Julia Lawall ju...@diku.dk

---
 arch/powerpc/platforms/pseries/dlpar.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/dlpar.c 
b/arch/powerpc/platforms/pseries/dlpar.c
index e1682bc..1540a41 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -433,6 +433,7 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t 
count)
if (rc) {
dlpar_release_drc(drc_index);
dlpar_free_cc_nodes(dn);
+   goto out;
}
 
rc = dlpar_online_cpu(dn);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: 2.6.34-rc3: Badness at kernel/lockdep.c:2706

2010-04-02 Thread Peter Zijlstra
On Fri, 2010-04-02 at 11:33 +0530, Sachin Sant wrote:
 With 2.6.34-rc3 boot on a Power5 box :
 
 loop: module loaded
 BUG: key 6b6b6b6b6b6b6b6b not in .data!
 [ cut here ]
 Badness at kernel/lockdep.c:2706
 NIP: c010a0a8 LR: c010a08c CTR: c00704a4
 REGS: c001096d76f0 TRAP: 0700   Not tainted  (2.6.34-rc3)
 MSR: 80029032 EE,ME,CE,IR,DR  CR: 2882  XER: 0009
 TASK = c001fa6f8000[1] 'swapper' THREAD: c001096d4000 CPU: 12
 GPR00:  c001096d7970 c1322e38 0001
 GPR04: 0001 c00c1ea8  0002
 GPR08:  c1cc5a00 2422 c137d768
 GPR12: 0002 cf66e400 00d47940 01c0
 GPR16:  02673148 018ff984 0060
 GPR20:   0253a291 018ff990
 GPR24: 018ff988 c1229ef0  c0010793a730
 GPR28: 6b6b6b6b6b6b6b6b c0010793afd8 c1299de0 c001096d7970
 NIP [c010a0a8] .lockdep_init_map+0x12c/0x538
 LR [c010a08c] .lockdep_init_map+0x110/0x538
 Call Trace:
 [c001096d7970] [c010a074] .lockdep_init_map+0xf8/0x538 
 (unreliable)
 [c001096d7a30] [c0274eac] .sysfs_add_file_mode+0x90/0x124
 [c001096d7af0] [c0274f7c] .sysfs_add_file+0x3c/0x50
 [c001096d7b90] [c02750d8] .sysfs_create_file+0x5c/0x74
 [c001096d7c30] [c04b36a0] .device_create_file+0x40/0x5c
 [c001096d7cd0] [c04db384] .wf_register_control+0x108/0x178
 [c001096d7d80] [c0a5f7cc] .wf_cpufreq_clamp_init+0x11c/0x16c
 [c001096d7e20] [c000a104] .do_one_initcall+0xb0/0x208
 [c001096d7ed0] [c0a12568] .kernel_init+0x230/0x2f0
 [c001096d7f90] [c0033b20] .kernel_thread+0x54/0x70
 Instruction dump:
 e93e8190 8009 2f80 409e03f8 48280539 6000 2fa3 419e03e8
 e93e8198 8009 2f80 409e03d8 0fe0 480003d0 e93e8140 fb9d
 Uniform Multi-Platform E-IDE driver

0x6b is POISON_FREE, so it seems to me sysfs made a boo-boo.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: 2.6.34-rc3: Badness at kernel/lockdep.c:2706

2010-04-02 Thread Eric W. Biederman

Could you try the fix Wolfram Sang sent to linux-kernel yesterday?

Peter Zijlstra pet...@infradead.org writes:

 On Fri, 2010-04-02 at 11:33 +0530, Sachin Sant wrote:
 With 2.6.34-rc3 boot on a Power5 box :
 
 loop: module loaded
 BUG: key 6b6b6b6b6b6b6b6b not in .data!
 [ cut here ]
 Badness at kernel/lockdep.c:2706
 NIP: c010a0a8 LR: c010a08c CTR: c00704a4
 REGS: c001096d76f0 TRAP: 0700   Not tainted  (2.6.34-rc3)
 MSR: 80029032 EE,ME,CE,IR,DR  CR: 2882  XER: 0009
 TASK = c001fa6f8000[1] 'swapper' THREAD: c001096d4000 CPU: 12
 GPR00:  c001096d7970 c1322e38 0001
 GPR04: 0001 c00c1ea8  0002
 GPR08:  c1cc5a00 2422 c137d768
 GPR12: 0002 cf66e400 00d47940 01c0
 GPR16:  02673148 018ff984 0060
 GPR20:   0253a291 018ff990
 GPR24: 018ff988 c1229ef0  c0010793a730
 GPR28: 6b6b6b6b6b6b6b6b c0010793afd8 c1299de0 c001096d7970
 NIP [c010a0a8] .lockdep_init_map+0x12c/0x538
 LR [c010a08c] .lockdep_init_map+0x110/0x538
 Call Trace:
 [c001096d7970] [c010a074] .lockdep_init_map+0xf8/0x538 
 (unreliable)
 [c001096d7a30] [c0274eac] .sysfs_add_file_mode+0x90/0x124
 [c001096d7af0] [c0274f7c] .sysfs_add_file+0x3c/0x50
 [c001096d7b90] [c02750d8] .sysfs_create_file+0x5c/0x74
 [c001096d7c30] [c04b36a0] .device_create_file+0x40/0x5c
 [c001096d7cd0] [c04db384] .wf_register_control+0x108/0x178
 [c001096d7d80] [c0a5f7cc] .wf_cpufreq_clamp_init+0x11c/0x16c
 [c001096d7e20] [c000a104] .do_one_initcall+0xb0/0x208
 [c001096d7ed0] [c0a12568] .kernel_init+0x230/0x2f0
 [c001096d7f90] [c0033b20] .kernel_thread+0x54/0x70
 Instruction dump:
 e93e8190 8009 2f80 409e03f8 48280539 6000 2fa3 419e03e8
 e93e8198 8009 2f80 409e03d8 0fe0 480003d0 e93e8140 fb9d
 Uniform Multi-Platform E-IDE driver

 0x6b is POISON_FREE, so it seems to me sysfs made a boo-boo.

Interesting combination of debugging options there.  First time I have
seen BUG: xyz not in .data with a 0x6b address...

Eric

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev