* 2.6.23-mm1 s390 driver problem @ 2007-10-18 20:01 Serge E. Hallyn 2007-10-18 20:15 ` Christian Borntraeger 0 siblings, 1 reply; 10+ messages in thread From: Serge E. Hallyn @ 2007-10-18 20:01 UTC (permalink / raw) To: Andrew Morton, linux-kernel Cc: cornelia.huck, heiko.carstens, sam, schwidefsky 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.23-mm1 s390 driver problem 2007-10-18 20:01 2.6.23-mm1 s390 driver problem Serge E. Hallyn @ 2007-10-18 20:15 ` Christian Borntraeger 2007-10-18 20:31 ` Serge E. Hallyn 0 siblings, 1 reply; 10+ messages in thread From: Christian Borntraeger @ 2007-10-18 20:15 UTC (permalink / raw) To: Serge E. Hallyn Cc: Andrew Morton, linux-kernel, cornelia.huck, heiko.carstens, sam, schwidefsky Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn: > 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 Can you post the full console output from IPL to the unsuccessful end? Thanks Christian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.23-mm1 s390 driver problem 2007-10-18 20:15 ` Christian Borntraeger @ 2007-10-18 20:31 ` Serge E. Hallyn 2007-10-19 7:47 ` Martin Schwidefsky 0 siblings, 1 reply; 10+ messages in thread From: Serge E. Hallyn @ 2007-10-18 20:31 UTC (permalink / raw) To: Christian Borntraeger Cc: Serge E. Hallyn, Andrew Morton, linux-kernel, cornelia.huck, heiko.carstens, sam, schwidefsky Quoting Christian Borntraeger (borntraeger@de.ibm.com): > Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn: > > 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 > > Can you post the full console output from IPL to the unsuccessful end? 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 NET: Registered protocol family 16 debug: Initialization complete SCSI subsystem initialized INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. 00000000fffffffe 0000000000000002 0000000000000000 00000000015afc10 00000000015afb88 00000000003c09d6 00000000003c09d6 0000000000014ef2 0000000000000000 0000000000000002 0000000000486040 0000000000000000 0000000000000000 000000000000000d 00000000015afb70 00000000015afbe8 0000000000329368 0000000000014ef2 00000000015afb70 00000000015afbc0 Call Trace: (Ã<0000000000014e24>¨ show_trace+0x9c/0xd0) Ã<0000000000014f10>¨ show_stack+0xb8/0xc8 Ã<0000000000014f4e>¨ dump_stack+0x2e/0x3c Ã<000000000005c3d4>¨ __lock_acquire+0x21c/0x1010 Ã<000000000005d4f0>¨ lock_acquire+0x98/0xc0 Ã<00000000000499e2>¨ run_workqueue+0x13e/0x240 Ã<0000000000049ba4>¨ worker_thread+0xc0/0xd8 Ã<000000000004faf0>¨ kthread+0x68/0xa0 Ã<0000000000018f66>¨ kernel_thread_starter+0x6/0xc Ã<0000000000018f60>¨ kernel_thread_starter+0x0/0xc INFO: lockdep is turned off. Time: tod clocksource has been installed. NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 2, 16384 bytes) TCP established hash table entries: 8192 (order: 7, 589824 bytes) TCP bind hash table entries: 8192 (order: 7, 589824 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered audit: initializing netlink socket (disabled) audit(1192739358.161:1): initialized Installing knfsd (copyright (C) 1996 okir@monad.swb.de). io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: module loaded nbd: registered device at major 43 Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007) bonding: Warning: either miimon or arp_interval and arp_ip_target module paramet ers must be specified, otherwise bonding will not detect link failures! see bond ing.txt for details. Equalizer2002: Simon Janes (simon@ncm.com) and David S. Miller (davem@redhat.com ) tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> st: Version 20070203, fixed bufsize 32768, s/g segs 256 md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: multipath personality registered for level -4 cio: Channel measurement facility using extended format (autodetected) qdio: loading QDIO base support version 2 dasd(eckd): 0.0.0250: 3390/0C(CU:3990/01) Cyl:10016 Head:15 Sec:224 dasd(eckd): 0.0.0250: (4kB blks): 7211520kB at 48kB/trk compatible disk layout dasdc:VOL1/ 0X0250: dasdc1 dasd(eckd): 0.0.0251: 3390/0C(CU:3990/01) Cyl:10016 Head:15 Sec:224 dasd(eckd): 0.0.0251: (4kB blks): 7211520kB at 48kB/trk compatible disk layout dasdd:VOL1/ ES2612: dasdd1 dasdd2 dasd(eckd): 0.0.0201: 3390/0C(CU:3990/01) Cyl:50 Head:15 Sec:224 dasd(eckd): 0.0.0201: (4kB blks): 36000kB at 48kB/trk linux disk layout dasda:CMS1/ SCRTCH: dasda1 dasd(eckd): 0.0.0202: 3390/0C(CU:3990/01) Cyl:200 Head:15 Sec:224 dasd(eckd): 0.0.0202: (4kB blks): 144000kB at 48kB/trk linux disk layout dasdb:CMS1/ SCRTCH: dasdb1 xpram error:expanded storage lost! xpram warning:No expanded memory available cpi: no system name specified TAPE_CHAR: tape gets major 254 for character devices TAPE_BLOCK: tape gets major 253 for block device vmur: z/VM virtual unit record device driver loaded. CTC driver initialized lcs: Loading LCS driver qeth: loading qeth S/390 OSA-Express driver u32 classifier Actions configured TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy sysctl table check failed: /sunrpc/transports .7249.14 Unknown sysctl binary pat h RPC: Registered udp transport module. RPC: Registered tcp transport module. VFS: Cannot open root device "dasdd2" or unknown-block(94,14) Please append a correct "root=" boot option; here are the available partitions: 5e08 7211520 dasdc driver: dasd-eckd 5e09 7211424 dasdc1 5e0c 7211520 dasdd driver: dasd-eckd 5e0d 262128 dasdd1 5e0e 6949296 dasdd2 5e00 36000 dasda driver: dasd-eckd 5e01 35988 dasda1 5e04 144000 dasdb driver: dasd-eckd 5e05 143988 dasdb1 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(94,14) 00: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from CPU 01. 01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 004C72F8 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.23-mm1 s390 driver problem 2007-10-18 20:31 ` Serge E. Hallyn @ 2007-10-19 7:47 ` Martin Schwidefsky 2007-10-19 9:16 ` Cedric Le Goater 0 siblings, 1 reply; 10+ messages in thread From: Martin Schwidefsky @ 2007-10-19 7:47 UTC (permalink / raw) To: Serge E. Hallyn Cc: Christian Borntraeger, Andrew Morton, linux-kernel, cornelia.huck, heiko.carstens, sam On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote: > Quoting Christian Borntraeger (borntraeger@de.ibm.com): > > Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn: > > > 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 > > > > Can you post the full console output from IPL to the unsuccessful end? > > 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. 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 = .; } ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.23-mm1 s390 driver problem 2007-10-19 7:47 ` Martin Schwidefsky @ 2007-10-19 9:16 ` Cedric Le Goater 2007-10-19 9:20 ` Martin Schwidefsky 2007-10-19 9:27 ` Andrew Morton 0 siblings, 2 replies; 10+ messages in thread From: Cedric Le Goater @ 2007-10-19 9:16 UTC (permalink / raw) To: schwidefsky Cc: Serge E. Hallyn, Christian Borntraeger, Andrew Morton, linux-kernel, cornelia.huck, heiko.carstens, sam, Linux Containers Martin Schwidefsky wrote: > On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote: >> Quoting Christian Borntraeger (borntraeger@de.ibm.com): >>> Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn: >>>> 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 >>> Can you post the full console output from IPL to the unsuccessful end? >> 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. > > 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. > 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 Ý<0000000000063c06>¨ raw_notifier_call_chain+0x2e/0x3c Ý<00000000002aa54c>¨ call_netdevice_notifiers+0x34/0x44 Ý<00000000002ad1aa>¨ dev_open+0x9e/0xe0 Ý<00000000002ad80a>¨ dev_change_flags+0x9e/0x1cc Ý<0000000000302c74>¨ devinet_ioctl+0x650/0x73c Ý<00000000003050ba>¨ inet_ioctl+0xde/0xf4 Ý<000000000029a8d0>¨ sock_ioctl+0x1cc/0x2dc Ý<00000000000cb844>¨ do_ioctl+0xb8/0xcc Ý<00000000000cb8f2>¨ vfs_ioctl+0x9a/0x3ec Ý<00000000000cbc96>¨ sys_ioctl+0x52/0x7c Ý<0000000000022484>¨ sysc_noemu+0x10/0x16 Ý<000002000010df12>¨ 0x2000010df12 00000000002b3352 gives : include/linux/netdevice.h:819 C. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.23-mm1 s390 driver problem 2007-10-19 9:16 ` Cedric Le Goater @ 2007-10-19 9:20 ` Martin Schwidefsky 2007-10-19 11:06 ` Cedric Le Goater 2007-10-19 9:27 ` Andrew Morton 1 sibling, 1 reply; 10+ messages in thread From: Martin Schwidefsky @ 2007-10-19 9:20 UTC (permalink / raw) To: Cedric Le Goater Cc: Serge E. Hallyn, Christian Borntraeger, Andrew Morton, linux-kernel, cornelia.huck, heiko.carstens, sam, Linux Containers On Fri, 2007-10-19 at 11:16 +0200, Cedric Le Goater wrote: > > 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. > > > > 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 : See http://marc.info/?l=linux-kernel&m=119270398931208&w=2 -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.23-mm1 s390 driver problem 2007-10-19 9:20 ` Martin Schwidefsky @ 2007-10-19 11:06 ` Cedric Le Goater 0 siblings, 0 replies; 10+ messages in thread From: Cedric Le Goater @ 2007-10-19 11:06 UTC (permalink / raw) To: schwidefsky Cc: Serge E. Hallyn, Christian Borntraeger, Andrew Morton, linux-kernel, cornelia.huck, heiko.carstens, sam, Linux Containers, Netdev Martin Schwidefsky wrote: > On Fri, 2007-10-19 at 11:16 +0200, Cedric Le Goater wrote: >>> 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. >>> >> 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 : > > See http://marc.info/?l=linux-kernel&m=119270398931208&w=2 hmm, that doesn't fix the oops. /me looking. Thanks, C. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.23-mm1 s390 driver problem 2007-10-19 9:16 ` Cedric Le Goater 2007-10-19 9:20 ` Martin Schwidefsky @ 2007-10-19 9:27 ` Andrew Morton 2007-10-19 11:17 ` Cedric Le Goater 1 sibling, 1 reply; 10+ messages in thread From: Andrew Morton @ 2007-10-19 9:27 UTC (permalink / raw) To: Cedric Le Goater Cc: schwidefsky, Serge E. Hallyn, Christian Borntraeger, linux-kernel, cornelia.huck, heiko.carstens, sam, Linux Containers, netdev On Fri, 19 Oct 2007 11:16:16 +0200 Cedric Le Goater <clg@fr.ibm.com> wrote: > Martin Schwidefsky wrote: > > On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote: > >> Quoting Christian Borntraeger (borntraeger@de.ibm.com): > >>> Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn: > >>>> 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 > >>> Can you post the full console output from IPL to the unsuccessful end? > >> 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. > > > > 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. > > > > 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 : please cc netdev on network issues. > 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 > Ý<0000000000063c06>¨ raw_notifier_call_chain+0x2e/0x3c > Ý<00000000002aa54c>¨ call_netdevice_notifiers+0x34/0x44 > Ý<00000000002ad1aa>¨ dev_open+0x9e/0xe0 > Ý<00000000002ad80a>¨ dev_change_flags+0x9e/0x1cc > Ý<0000000000302c74>¨ devinet_ioctl+0x650/0x73c > Ý<00000000003050ba>¨ inet_ioctl+0xde/0xf4 > Ý<000000000029a8d0>¨ sock_ioctl+0x1cc/0x2dc > Ý<00000000000cb844>¨ do_ioctl+0xb8/0xcc > Ý<00000000000cb8f2>¨ vfs_ioctl+0x9a/0x3ec > Ý<00000000000cbc96>¨ sys_ioctl+0x52/0x7c > Ý<0000000000022484>¨ sysc_noemu+0x10/0x16 > Ý<000002000010df12>¨ 0x2000010df12 that's a network issue ;) > 00000000002b3352 gives : include/linux/netdevice.h:819 > 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.23-mm1 s390 driver problem 2007-10-19 9:27 ` Andrew Morton @ 2007-10-19 11:17 ` Cedric Le Goater 2007-10-19 11:25 ` Martin Schwidefsky 0 siblings, 1 reply; 10+ messages in thread From: Cedric Le Goater @ 2007-10-19 11:17 UTC (permalink / raw) To: Andrew Morton Cc: schwidefsky, Serge E. Hallyn, Christian Borntraeger, linux-kernel, cornelia.huck, heiko.carstens, sam, Linux Containers, netdev >> that helped going a little further in the boot process but we then have >> a network issue when bringing the network interface up : > > please cc netdev on network issues. yes. >> 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 >> Ý<0000000000063c06>¨ raw_notifier_call_chain+0x2e/0x3c >> Ý<00000000002aa54c>¨ call_netdevice_notifiers+0x34/0x44 >> Ý<00000000002ad1aa>¨ dev_open+0x9e/0xe0 >> Ý<00000000002ad80a>¨ dev_change_flags+0x9e/0x1cc >> Ý<0000000000302c74>¨ devinet_ioctl+0x650/0x73c >> Ý<00000000003050ba>¨ inet_ioctl+0xde/0xf4 >> Ý<000000000029a8d0>¨ sock_ioctl+0x1cc/0x2dc >> Ý<00000000000cb844>¨ do_ioctl+0xb8/0xcc >> Ý<00000000000cb8f2>¨ vfs_ioctl+0x9a/0x3ec >> Ý<00000000000cbc96>¨ sys_ioctl+0x52/0x7c >> Ý<0000000000022484>¨ sysc_noemu+0x10/0x16 >> Ý<000002000010df12>¨ 0x2000010df12 > > that's a network issue ;) > >> 00000000002b3352 gives : include/linux/netdevice.h:819 >> > > I have a feeling that we fixed this. But there's no BUG at 2.6.23-mm1's > include/linux/netdevice.h:819. but dev->header_ops is bogus. right ? > How about setting CONFIG_DEBUG_BUGVERBOSE=y? it is set :( C. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 2.6.23-mm1 s390 driver problem 2007-10-19 11:17 ` Cedric Le Goater @ 2007-10-19 11:25 ` Martin Schwidefsky 0 siblings, 0 replies; 10+ messages in thread From: Martin Schwidefsky @ 2007-10-19 11:25 UTC (permalink / raw) To: Cedric Le Goater Cc: Andrew Morton, Serge E. Hallyn, Christian Borntraeger, linux-kernel, cornelia.huck, heiko.carstens, sam, Linux Containers, netdev On Fri, 2007-10-19 at 13:17 +0200, Cedric Le Goater wrote: > > please cc netdev on network issues. > > yes. > > >> Bringing up interface eth0: ------------Ý cut here ¨------------ > >> Kernel BUG at 0000000000000002 Ýverbose debug info unavailable¨ > >> illegal operation: 0001 Ý#1¨ > > > > that's a network issue ;) > > > >> 00000000002b3352 gives : include/linux/netdevice.h:819 > >> > > > > I have a feeling that we fixed this. But there's no BUG at 2.6.23-mm1's > > include/linux/netdevice.h:819. > > but dev->header_ops is bogus. right ? > > > How about setting CONFIG_DEBUG_BUGVERBOSE=y? > > it is set :( 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-10-19 11:25 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-10-18 20:01 2.6.23-mm1 s390 driver problem Serge E. Hallyn 2007-10-18 20:15 ` Christian Borntraeger 2007-10-18 20:31 ` Serge E. Hallyn 2007-10-19 7:47 ` Martin Schwidefsky 2007-10-19 9:16 ` Cedric Le Goater 2007-10-19 9:20 ` Martin Schwidefsky 2007-10-19 11:06 ` Cedric Le Goater 2007-10-19 9:27 ` Andrew Morton 2007-10-19 11:17 ` Cedric Le Goater 2007-10-19 11:25 ` Martin Schwidefsky
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox