Re: ibmvscsi badness (Re: 2.6.13-mm3)

[Andrew Morton <akpm@osdl.org>]

serue@us.ibm.com wrote:
>
> Trying to get 2.6.13-mm running on a power5 lpar, I'm
> having scsi problems.

You should have cc'ed the scsi mailing list, no?

> With -mm2, I only get things like:
> 	sd 0:0:0:0: SCSI error: return code = 0x8000002
> 	sda: Current: sense key: Aborted Command
> 	    Additional sense: No additional sense information
> 	Info fld=0x0
> 	end_request: I/O error, dev sda, sector 10468770
> 	sd 0:0:0:0: SCSI error: return code = 0x8000002
> 	sda: Current: sense key: Aborted Command
> 	    Additional sense: No additional sense information
> 	Info fld=0x0
> 	end_request: I/O error, dev sda, sector 10468778
> 	sd 0:0:0:0: SCSI error: return code = 0x8000002
> 	sda: Current: sense key: Aborted Command
> 	    Additional sense: No additional sense information
> 	Info fld=0x0
> 	end_request: I/O error, dev sda, sector 10468786
> 	sd 0:0:0:0: SCSI error: return code = 0x8000002
> 	sda: Current: sense key: Aborted Command
> 	    Additional sense: No additional sense information
> 	Info fld=0x0
> 	end_request: I/O error, dev sda, sector 10468794
> 
> When I copy the 2.6.13-rc6-mm2's drivers/scsi/ibmvscsi/ibmvscsi.{c,h}
> back (just changing the static vio_device_id initializer as per
> 
> @@ -1442,7 +1531,7 @@ static int ibmvscsi_remove(struct vio_de
>   */    
>  static struct vio_device_id ibmvscsi_device_table[] __devinitdata = {
>         {"vscsi", "IBM,v-scsi"},
> -       {0,}
> +       { "", "" } 
>  };                     
> 
> then this kernel boots fine.

There have been quite a lot of ibmvscsi changes since 2.6.13-rc6-mm2.

>  The same thing does not work for
> 2.6.13-mm3.  The console output of an attempted boot follows.
> (Seems the same with either version of ibmvscsi.{c,h}, so the
> problem appears to be elsewhere)
> 
> ...
> Remounting root filesystem in read-write mode:  [  OK  ]
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=128 NUMA PSERIES LPAR
> Modules linked in:
> NIP: C000000000087C1C XER: 20000010 LR: C000000000087D70 CTR: C0000000000830A4
> REGS: c0000000021dec00 TRAP: 0300   Not tainted  (2.6.13-mm3)
> MSR: 8000000000009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 CR: 24044042
> DAR: c000000103c23c58 DSISR: 0000000040010000
> TASK: c00000000700d050[2236] 'hotplug' THREAD: c0000000021dc000 CPU: 0
> GPR00: 0000000000000001 C0000000021DEE80 C00000000056B0E8 0000000000000000
> GPR04: 0000000000000000 616C746976656300 0000000020713DFA 0000000000000000
> GPR08: 0000000000000000 C000000103C23C38 3C4E554C4C3E0000 C000000000384C68
> GPR12: C000000000384C68 C00000000043C800 C0000000021BB600 0000000000000006
> GPR16: 00000000F800F958 00000000F800FA88 0000000010000000 0000000000000010
> GPR20: 0000000002000000 0000000000000000 0000000000000000 C00000000700D050
> GPR24: 0000000020713DFA C000000087FF7D88 00000000800400D2 0000000000000001
> GPR28: 0000000000000000 C000000000384C68 C0000000004ABC38 0000000000000000
> NIP [c000000000087c1c] .zone_watermark_ok+0x50/0xac
> LR [c000000000087d70] .__alloc_pages+0xf8/0x5fc
> Call Trace:
> [c0000000021dee80] [c0000000021def20] 0xc0000000021def20 (unreliable)
> [c0000000021def70] [c0000000000aa1b4] .alloc_page_interleave+0x3c/0xb8
> [c0000000021deff0] [c00000000009af70] .do_no_page+0x5f8/0x710
> [c0000000021df0e0] [c00000000009b2b8] .__handle_mm_fault+0x230/0x694
> [c0000000021df1c0] [c00000000035be38] .do_page_fault+0x4e0/0x7e8
> [c0000000021df340] [c000000000004760] .handle_page_fault+0x20/0x54
> --- Exception: 301 at .__clear_user+0x14/0x7c
>     LR = .padzero+0x34/0x5c
> [c0000000021df630] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
> [c0000000021df6a0] [c00000000001441c] .load_elf_binary+0x171c/0x1abc
> [c0000000021df830] [c0000000000c3c80] .search_binary_handler+0x184/0x4bc
> [c0000000021df8e0] [c0000000000f20c4] .load_script+0x2d0/0x314
> [c0000000021dfa10] [c0000000000c3c80] .search_binary_handler+0x184/0x4bc
> [c0000000021dfac0] [c0000000000c41cc] .do_execve+0x214/0x394
> [c0000000021dfb70] [c00000000000de64] .sys_execve+0x74/0xf8
> [c0000000021dfc10] [c000000000009c00] syscall_exit+0x0/0x18
> --- Exception: c01 at .____call_usermodehelper+0xcc/0xf8
>     LR = .____call_usermodehelper+0x9c/0xf8
> [c0000000021dff90] [c000000000010060] .kernel_thread+0x4c/0x68
> Instruction dump:
> 419e0010 7ca00e74 7c000194 7ca02850 2fa70000 419e0010 7ca01674 7c000194
> 7ca02850 78c91f24 38600000 7d296214 <e8090020> 7c002a14 7faa0040 4c9d0020
>  Oops: Kernel access of bad area, sig: 11 [#2]
> SMP NR_CPUS=128 NUMA PSERIES LPAR
> Modules linked in: dm_mod

Interesting.  It could be Andi's recent mempolicy.c changes
(convert-mempolicies-to-nodemask_t.patch) or it could be some recent ppc64
change or it could be something else ;)

Could the ppc64 guys please take a look?  In particular, it would be good
to know if convert-mempolicies-to-nodemask_t.patch is innocent - I was
planning on merging that upstream today.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/