Sigh, well this turned out less informative than I'd liked.

After bisecting 2.6.23 to 2.6.23-mm1, I found that

git-s390.patch is the one breaking my s390 boot :(

(Frown bc it's a conglomeration of patches0
Symptom is:

	"Cannot open root device "dasdd2" or unknown-block(94,14)"

even though dasdd2 appeared to be found earlier in the boot.  I also

get
Please append a correct "root=" boot option; here are the available partitions:

...

5e0c 7211520 dasdd driver: dasd-eckd

...

5e0e 6949296 dasdd2
Will keep looking at it, but maybe the fix is obvious to someone

in this cc: list?
thanks,

-serge

-

Can you post the full console output from IPL to the unsuccessful end?
Thanks
Christian

-

Yeah, sorry, appended below.
I had thought that the line

	sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy

meant that the fix referenced in http://lkml.org/lkml/2007/10/11/48

would fix it, but it appeared to have no effect.
thanks,

-serge
========================================================================

========================================================================
Linux version 2.6.23-mm1-g7692ccd6 (hallyn@elg11.watson.ibm.com) (gcc version 3.

4.2 20040907 (Red Hat 3.4.2-1)) #314 SMP PREEMPT Thu Oct 18 16:27:04 EDT 2007

We are running under VM (64 bit mode)

Detected 2 CPU's

Boot cpu address  0

Zone PFN ranges:

  DMA             0 ->   524288

  Normal     524288 ->   524288

Movable zone start PFN for each node

early_node_mapÝ1¨ active PFN ranges

    0:        0 ->    65535

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 63872

Kernel command line: dasd=0.0.0201,0.0.0202,0.0.0250,0.0.0251 mem=256M root=/dev

/dasdd2 ro           noinitrd

PID hash table entries: 1024 (order: 10, 8192 bytes)

console ÝttyS0¨ enabled

Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar

... MAX_LOCKDEP_SUBCLASSES:    8

... MAX_LOCK_DEPTH:          30

... MAX_LOCKDEP_KEYS:        2048

... CLASSHASH_SIZE:           1024

... MAX_LOCKDEP_ENTRIES:     8192

... MAX_LOCKDEP_CHAINS:      16384

... CHAINHASH_SIZE:          8192

 memory used by lock dependency info: 1712 kB

 per task-struct memory footprint: 2160 bytes

Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)

Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)

Memory: 243712k/262144k available (3217k kernel code, 0k reserved, 1651k data, 5

76k init)

Write protected kernel read-only data: 0x12000 - 0x477fff

Mount-cache hash table entries: 256

cpu 0 phys_idx=0 vers=FF ident=0210BC machine=2084 unused=8000

cpu 1 phys_idx=1 vers=FF ident=0210BC machine=2084 unused=8000

Brought up 2 CPUs

net_namespace: 152 bytes

NE...
[ message continues ]

This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg

moved the __initramfs_start and __initramfs_end symbols into

the .init.ramfs section. This is in itself not a problem, but it

surfaced a bug: there is no *(.init.initramfs), that needs to be

*(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has

the older one that still causes the "Cannot open root device". For

2.6.23-mm1 use the patch below.
--

blue skies,

  Martin.
"Reality continues to ruin my life." - Calvin.
---

diff -urpN linux-2.6/arch/s390/kernel/vmlinux.lds.S linux-2.6-patched/arch/s390/kernel/vmlinux.lds.S

--- linux-2.6/arch/s390/kernel/vmlinux.lds.S	2007-10-19 09:41:57.000000000 +0200

+++ linux-2.6-patched/arch/s390/kernel/vmlinux.lds.S	2007-10-19 09:42:29.000000000 +0200

@@ -128,7 +128,7 @@ SECTIONS

 	. = ALIGN(0x100);

 	.init.ramfs : {

 		__initramfs_start = .;

-		*(.init.initramfs)

+		*(.init.ramfs)

 		. = ALIGN(2);

 		__initramfs_end = .;

 	}
-

thanks martin, 
that helped going a little further in the boot process but we then have

a network issue when bringing the network interface up :
Bringing up interface eth0:  ------------Ý cut here ¨------------

Kernel BUG at 0000000000000002 Ýverbose debug info unavailable¨

illegal operation: 0001 Ý#1¨

Modules linked in:

CPU:    0    Not tainted

Process ip (pid: 1167, task: 0000000001d46038, ksp: 00000000025efb28)

Krnl PSW : 0704200180000000 0000000000000002 (0x2)

           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3

Krnl GPRS: 0000000000000000 0000000000000000 000000000241f600 0000000001c8d

           00000000000086dd 0000000001eb6d70 0000000000000000 0000000001c8d

           0000000001eb6d40 00000000003abc28 0000000001eb6d00 00000000025ef

           000000000241f600 00000000003b6d18 00000000002b33d2 00000000025ef

Krnl Code:>0000000000000002: 0000               unknown

           0000000000000004: 0000               unknown

           0000000000000006: 0000               unknown

           0000000000000008: 0000               unknown

           000000000000000a: 0000               unknown

           000000000000000c: 0000               unknown

           000000000000000e: 0000               unknown

           0000000000000010: 0000               unknown

Call Trace:

(Ý<00000000002b3352>¨ neigh_connected_output+0x76/0x138)

 Ý<0000000000325402>¨ ip6_output2+0x2da/0x470

 Ý<0000000000326ea6>¨ ip6_output+0x816/0x1064

 Ý<0000000000338e46>¨ __ndisc_send+0x416/0x6a8

 Ý<0000000000339330>¨ ndisc_send_rs+0x58/0x68

 Ý<000000000032cbf4>¨ addrconf_dad_completed+0xbc/0x100

 Ý<000000000032d2de>¨ addrconf_dad_start+0xa2/0x14c

 Ý<000000000032d408>¨ addrconf_add_linklocal+0x80/0xa8

 Ý<000000000032fa7e>¨ addrconf_notify+0x2de/0x8d4

 Ý<0000000000383990>¨ notifier_call_chain+0x5c/0x98

 Ý<0000000000063bca>¨ __raw_notifier_call_chain+0x26/0x34

 Ý<000000000...
[ message continues ]

I have a feeling that we fixed this.  But there's no BUG at 2.6.23-mm1's

include/linux/netdevice.h:819.  How about setting

CONFIG_DEBUG_BUGVERBOSE=y?
-

it is set :(
C.
-

This is definitly a problem with the header_ops in the qeth network

driver. I've asked our network team to take care of it. Stay tuned..
--

blue skies,

  Martin.
"Reality continues to ruin my life." - Calvin.
-

See http://marc.info/?l=linux-kernel&m=119270398931208&w=2
--

blue skies,

  Martin.
"Reality continues to ruin my life." - Calvin.
-

hmm, that doesn't fix the oops.
/me looking.
Thanks,
C.
-