On 11/03/14 at 11:09am, WANG Chao wrote:
> On 11/03/14 at 10:33am, Dave Young wrote:
> > Hi,
> >
> > Well done, thanks Chao.
> >
> > Vivek/Bao/Minfei, could you review the patch as well?
> >
> > On 10/28/14 at 06:43pm, WANG Chao wrote:
> > > Currently we retrieve all the necessary information of an iSCSI session
> > > and pass them to 2nd kernel. This is wrong way to go for hardware iscsi,
> > > because dracut has already had its own infrastructure to do bring up any
> > > iscsi device configured in firmware of an HBA (Host Bus Bridge).
> > >
> > > This patch will determine if an iscsi session is established by firmware
> > > configured iscsi. If it does, then we don't pass anything down to 2nd
> > > kernel. dracut will handle it.
> > >
> > > I read some iscsi code and I also talked with storage QE. It's
confirmed
> > > that software iscsi will use "tcp" transport class while
hardware iscsi
> > > will use like "be2iscsi" "bnx2i" transport class.
It's ok to use
> > > the transport name of an iface of a scsi session to determine hardware
> > > iscsi or not. Additionally using "iscsi_firmware"
"rd.iscsi.firmware" to
> > > determine if the system is iscsi boot, because dracut can only handle
> > > this case.
> > >
> > > Along this patch, I add the infrastructure of determine iBFT, but
it's
> > > not complete yet. Mark the part as "FIXME". Once customer is
asking or
> > > maybe I get hold of iBFT box, I can start working on it.
> >
> > For non-root hwiscsi there's no kernel cmdline, you can put it in todo
list
> > We can support root device firstly and see if it works well.
>
> Yes, that's TODO and nice-to-have. My concern is that in 2nd kernel, not all
> hardware/driver works as fine as it does in 1st kernel. I've heard a few
> cases that certain driver won't work at 2nd kernel. I found one bug
> myself:
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1158014
> [kdump] [be2iscsi]: IP: [<ffffffffa00cf700>]
hwi_get_async_handle.isra.23.constprop.39+0x90/0x1d0 [be2iscsi]
>
> So I think it can be safer to use iscsi_tcp (software driver, no
> offload) instead of using hardware associated offload driver. What do
> you think?
I think we can open bugs in case such issues. Just what we did for drm module
you know nvidia card does not work well.
Agree that we can enable root device support as the first step. BTW can you
update documentation in the patch?