[openib-general] [PATCHv6] SDP: Allow SDP to compile on 2.6.12-rc6

[Tom Duffy]

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:

[root at sins-stinger-10 ~]# ----------- [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 syslogd at sins-stinger-10 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050609/66f241bc/attachment.sig>