On Thu, 2008-01-10 at 15:55 -0600, Mike Christie wrote:
> Mike Christie wrote:
> > Anil Veerabhadrappa wrote:
> >> On Thu, 2008-01-10 at 14:41 -0600, Mike Christie wrote:
> >>> Anil Veerabhadrappa wrote:
> >>>> On Thu, 2008-01-10 at 07:22 -0600, Mike Christie wrote:
> >>>>> Hey Broadcom guys and iscsi list,
> >>>>>
> >>>>> I put up all my changes to the bnx2i driver in the bnx2i branches of
> >>>>> the
> >>>>> open-iscsi git tree and linux-2.6-iscsi.
> >>>> Thanks Mike
> >>>>
> >>>>> It hooks bnx2i into the iscsi layers like how iser and iscsi_tcp is,
> >>>>> except that it allocates a scsi_host per net device instead of per
> >>>>> session.
> >>>>>
> >>>>> The code is only compile tested, and I am sure it is very broken
> >>>>> because
> >>>>> lot of code changed:
> >>>> got following error messages while trying to test this, any idea?
> >>>>
> >>>> ----- log start -----
> >>>>
> >>>> iscsiadm: Could not read /sys/class/scsi_host/host3/proc_name rc 22.
> >>>> iscsiadm: Could not read /sys/class/scsi_host/host4/proc_name rc 22.
> >>>> iscsiadm: Could not read /sys/class/scsi_host/host5/proc_name rc 22.
> >>> Come man, time to put on your super hero debugging cap on. When I said I
> >>> am sure it is broken I really meant that it is horribly broken :)
> >> Reported error was seen during iscsi discovery session, thought it have
> >> nothing to do with bnx2i related changes. iSCSI discovery & initial
> >> connection setup works fine with the Dec 17, 2007 snapshot of bnx2i
> >> branch.
> >>
> >>
> >>> This error normally happens, when something goes completely screwy and
> >>> you end up with partially created or partially destroyed kernel sessions
> >>> or connections.
> >> iSCSI discovery session does not involve any kernel sessions or am I
> >> missing something?
> >>
> >
> > Yeah, that is right. I do not know off the top of my head.
> >
>
> Are you sure you have the bnx2i brand in the open-iscsi tree?
Yes
I had one question regarding following code snippet in
scsi_transport_iscsi.c::iscsi_register_transport:1597
if (!(tt->caps & CAP_DATA_PATH_OFFLOAD))
priv->t.create_work_queue = 1;
Is this still valid? while testing bnx2i changes I see libiscsi indeed
calls scsi_queue_work(). I was going to remove conditional 'if'
statement and continue to test bnx2i, but for a second I thought of
implications on other existing offload drivers like qla4xxx. any
thoughts?
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
