On Thu, 2005-06-09 at 11:59 -0700, Libor Michalek wrote: > Do you want to send the stack trace from the panic? One thing to > note is when a passive connection is received, the new connection > and socket structures are allocated even if there is no one listening. > Only once they've been allocated does the check for listner occur, > and if there is not one present, then structures are deleted.
Yeah, I saw that. I think it is strange behavior, but alas...
Here is the trace:
[EMAIL PROTECTED] ~]# ----------- [cut here ] --------- [please bite here ]
---------
Kernel BUG at "/build1/tduffy/openib-work/linux-2.6.12-rc6-openi:352
invalid operand: 0000 [1] SMP
CPU 1
Modules linked in: ib_sdp ib_cm md5 ipv6 parport_pc lp parport autofs4 nfs
lockd rfcomm l2cap bluetooth pcmcia yenta_socket rsrc_nonstatic pcmcia_core
sunrpc ext3 jbd dm_mod video container button battery ac ohci_hcd tpm_nsc tpm
i2c_amd756 i2c_core ib_mthca ib_ipoib ib_sa ib_mad ib_core tg3 floppy xfs
exportfs mptscsih mptbase sd_mod scsi_mod
Pid: 946, comm: ib_cm/1 Not tainted 2.6.12-rc6openib
RIP: 0010:[<ffffffff802dd809>] <ffffffff802dd809>{sk_alloc+297}
RSP: 0018:ffff81001d465c68 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff81001c959790 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000000000000001b RDI: ffffffff882f4900
RBP: ffffffff882f4500 R08: 0000000000000000 R09: ffff81001c959790
R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff882f3dc0
R13: 0000000000000020 R14: 0000000000000001 R15: 000000000000001b
FS: 00002aaaaaad4ea0(0000) GS:ffffffff804e7900(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00002aaaaaaac000 CR3: 000000003e764000 CR4: 00000000000006e0
Process ib_cm/1 (pid: 946, threadinfo ffff81001d464000, task ffff81003fdd0f10)
Stack: ffff81001ddee230 0000000000000286 0000000100000001 ffff81003f0ebe8c
0000000000000000 ffff81003d3c3158 ffff810037de9af8 ffff81003d3c3158
ffff81003d3c31b0 ffffffff882e2f33
Call Trace:<ffffffff882e2f33>{:ib_sdp:sdp_conn_alloc+35}
<ffffffff882e9d8f>{:ib_sdp:sdp_cm_req_handler+2175}
<ffffffff8016703b>{cache_free_debugcheck+715}
<ffffffff882e909f>{:ib_sdp:sdp_cm_event_handler+175}
<ffffffff882d63d2>{:ib_cm:cm_process_work+50}
<ffffffff882d7ba9>{:ib_cm:cm_work_handler+1881}
<ffffffff882d7450>{:ib_cm:cm_work_handler+0}
<ffffffff8014912c>{worker_thread+476}
<ffffffff801327c0>{default_wake_function+0}
<ffffffff8014d7d0>{keventd_create_kthread+0}
<ffffffff80148f50>{worker_thread+0}
<ffffffff8014d7d0>{keventd_create_kthread+0}
<ffffffff8014da59>{kthread+217} <ffffffff80133d10>{schedule_tail+64}
<ffffffff8010f6db>{child_rip+8}
<ffffffff8014d7d0>{keventd_create_kthread+0}
<ffffffff8014d980>{kthread+0} <ffffffff8010f6d3>{child_rip+0}
Code: 0f 0b 40 06 37 80 ff ff ff ff 60 01 65 8b 04 25 34 00 00 00
RIP <ffffffff802dd809>{sk_alloc+297} RSP <ffff81001d465c68>
Message from [EMAIL PROTECTED] at Thu Jun 9 11:16:31 2005 ...
sins-stinger-10 kernel: invalid operand: 0000 [1] SMP
----
It is very strange because the buffer pool is allocated in init. I
don't understand why sk_alloc() would fail, and how it is getting an
invalid operand is beyond me.
-tduffy
signature.asc
Description: This is a digitally signed message part
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
