[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/46896: iSCSI initiator ccb_pool gets corrupted
The following reply was made to PR kern/46896; it has been noted by GNATS.
From: "Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>
Subject: Re: kern/46896: iSCSI initiator ccb_pool gets corrupted
Date: Sat, 8 Sep 2012 20:17:29 -0600 (MDT)
> I suspect this problem is relatively rare, and needs something similar
> to my above described setup to get enough random activity with the iSCSI
> target to duplicate.
I had added tagged queueing support for iscsi in my netbsd-6 while
debugging the problem, and wanted to test tagged queueing in -current
before commiting that change. With tagged queueuing, things very quickly
went awry and hung when I tried to start the DOMU, so adding tagged
queueing should make this problem much more repeatable.
> If the problem is multiple processing of a ccb on the ccbs_waiting
> try to prevent that from happening, or at least prevent it from
> the ccb_pool and ccbs_waiting queues.
What I've discovered so far: I do indeed see ccbs passed to wake_ccb()
which are not on the ccbs_waiting queue. If I check the ccbs_waiting
queue and only remove the ccb if it's on that queue, I do not have the
problems of ccb corruption. Also, I noticed that all the ccbs that passed
to wake_ccb() have a dispostion of CCBDISP_SCSIPI, which presumably are
the result of requests from the scsipi layer and will report their status
back to the scsipi layer. I don't yet know if there are any ccbs with
CCBDISP_SCSIPI that get added to the ccbs_waiting queue, and my cursory
attempt to follow the logic of the scsipi requests got me rather lost.
I think that the iscsi initiator working as well as it has for several
people is pure luck and happenstance.
Michael L. Hitch mhitch%montana.edu@localhost
Information Technology Center
Montana State University Bozeman, MT USA
Main Index |
Thread Index |