iSCSI initiator driver beta version, testers wanted

[Danny Braniss]

> Scott Long wrote:
> > Danny Braniss wrote:
> > 
> >>> with tags enabled, iSCSI is much faster, but it also causes a 
> >>> deadlock :-(
> >>> this is what i run:
> >>>     newfs -U /<iscsi device>
> >>>     cd /<iscsi device>
> >>>     restore rf /home/file.dump
> >>>
> >>> on the same motherboard, a dual Xeon, with smp disabled all is OK
> >>> with smp enabled restore gets stuck usualy waiting on biord.
> >>> the iscsi driver shows that all requests have been done, the sniffing
> >>> shows the same(ie all request have been done).
> >>>
> >>> so this leads me to think that there is some race condition that i'm not
> >>> aware of in a SMP system, where xpt_done(ccb) is called while
> >>> another process is calling biowait.
> >>>
> >>> another lead is that after restore gets stuck, the system slowly gets 
> >>> 'stalled'.
> >>>
> >>> any insight is most welcome!, i'm also stuck.
> >>
> >>
> >>
> >> ahh, hate talking to myself :-)
> >>
> >> grabbing Giant before calling xpt_done solved it, so the problem is
> >> most probably in the CAM ...
> >>
> >> danny
> >>
> >>
> >>
> > 
> > No, you need to grab Giant when calling xpt_done().  I even put an
> > assertion into CAM to make sure of that.  Are you running with WITNESS
> > and/or INVARIANTS enabled?  Those would have caught this problem.
> > 
they are off :-(, would have saved me some time.
> > Scott
> 
> Oops, I forgot to mention that I recently addressed this in 6-CURRENT.
> Now, much of the rest of cam API still requires Giant to be held, but
> xpt_done() does not.  This only applies to 6-CURRENT, and I doubt that
> it will be backported to 5-STABLE.
> 
> Scott

so what you are saying is that in 5.x it's a must to grab Giant before calling
xpt_done, and not in 6?

danny