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
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
Quoting Christian Borntraeger ([email protected]):
> 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 ([email protected]) (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 [email protected]).
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 ([email protected]) and David S. Miller ([email protected]
)
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
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
On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
> Quoting Christian Borntraeger ([email protected]):
> > 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 = .;
}
Martin Schwidefsky wrote:
> On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
>> Quoting Christian Borntraeger ([email protected]):
>>> 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.
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.
On Fri, 19 Oct 2007 11:16:16 +0200 Cedric Le Goater <[email protected]> wrote:
> Martin Schwidefsky wrote:
> > On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
> >> Quoting Christian Borntraeger ([email protected]):
> >>> 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?
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.
>> 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.
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.