Hi,
On 07/31/07 12:46, liujun wrote:
>> $C
> [i]000002a100572bc1 vpanic(11eb3c0, 134e968, 134e978, 91f, c8, 2000)
> 000002a100572c71 assfail+0x74(134e968, 134e978, 91f, 183d400, 11eb000, 0)
> 000002a100572d21 mppLnx_scsi_done+0x8c(300020326e0, 70459000, 70459, 0,
> 134e000, 134e000)
> 000002a100572dd1 ssfcp_cmd_callback+0x64(30002032738, 0, 1, 813, 30002032548,
> 30002d7a900)
> 000002a100572e81 ql_fast_fcp_post+0x178(300020328d8, 12c0000, 30002032738,
> 3000203a140, 3000203a1b8
> , 12c0000)
> 000002a100572f31 ql_status_entry+0x224(0, 30002a58ac0, 2a100573958,
> 2a10057396c, 0, 0)
> 000002a100572fe1 ql_response_pkt+0x268(3000203a140, 2a100573958, 2a10057396c,
> 2a100573968, 4aa, 0)
> 000002a100573091 ql_isr+0x664(3000203a140, 2a, 8000, 2a, ffffffffffffffff,
> 3000203a198)
> 000002a100573171 ql_isr_aif+4(3000203a140, 0, 3000203a140, 0, 0, ff)
> 000002a100573221 pci_intr_wrapper+0xb4(3000146d328, 3000146e2e8, 0, 0, 0,
> 30002344200)
> 000002a1005732d1 intr_thread+0x170(134af78, 0, ffffffff85caeb50, 19c0,
> 7b69c428, 1838400)[/i]
> [b]000002a100ce8df1 cprintf+0x220(134fd70, 2bb134ee, 50, 18563d4, c8, 134af78)
> 000002a100ce8fc1 cmn_err+0x88(50, 134fd70, 0, 0, 40, 18563c4)
> 000002a100ce9091 mppLnx_insert_proxyRequest_to_list+0x8c(30010b11b00, 2,
> 7045a, 70400, 134f000,
> 134f)
> 000002a100ce9141 mppLnx_do_queuecommand+0xb08(30010b11b00, c8, 0,
> 30003090000, 30002d65180,
> 30002363ba0)
> 000002a100ce9201 mppLnx_dpc_handler+0x278(70000, 703cf998, 1, 703cf9f8, 134f,
> 30010b11b00)
> 000002a100ce92d1 thread_start+4(0, 0, baddcafebaddcafe, baddcafebaddcafe,
> baddcafebaddcafe,
> baddcafebaddcafe)[/b]>
>
>
> My thread is mppLnx_dpc_handler.When it's running at cprintf+0x220 frame,is
> it broken out by the intr_thread which is not belongs to
> mppLnx_dpc_handler?
>
> In mppLnx_dpc_handler , mppLnx_scsi_done is registerd to Qlogic HBA drivers
> as callback.I think the intr_thread is restart by Qlogic HBA drivers .
>
> Why the intr_thread stack frames is live in mppLnx_dpc_handler threads stack
> at this point.
>
> Thank your!!
Device interrupt arrival is asynchronous (obviously) and the interrupt is
handled
by the receiving processor as soon as it is able (defined as having
interrupts enabled in %pstate and %pil being below the PIL associated
with the interrupt vector. The ql driver has registered a handler
for this interrupt number so that handler (ql_isr_aif) is called when
we process the interrupt.
Your thread happened to be on cpu at the time the interrupt arrived.
It is likely that your code is not disabling interrupts (generally
not something you should be doing) and certainly has not
rasied the pil to defend against possible interrupt which
can re-enter your driver. You have registered a callback
which is occuring from interrupt context, so you have
arranged a means by which your driver can be re-entered.
That is quite legal, but it is up to you to ensure the
data safety either by preventing the interrupt from
occuring during certain critical sections (raising PIL
to at least that of the device interrupt) or through
other synchronisation mechanims such as a mutex.
The above interrupt is at low PIL (below 10) which
we can tell from the intr_thread on the stack, which means
that the handler is allowed to block and so may contend
for adaptive mutexes etc. You still need to be sure not
to deadlock, but the idea is that the interrupt thread
can block ("passivate") if it finds a mutex already held
by your thread; your thread will have it's priority raised
to that of the interrupt thread until it drops the mutex.
Hope that helps.
Gavin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3249 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20070731/19b4bc98/attachment.bin>
