On 09/30/15 at 12:01pm, Minfei Huang wrote:
On 09/30/15 at 11:10am, Dave Young wrote:
> On 09/25/15 at 06:03pm, Minfei Huang wrote:
> > On 09/25/15 at 02:39pm, Dave Young wrote:
> > > On 09/24/15 at 01:29pm, Minfei Huang wrote:
> > > > Hardware iscsi can export the iscsi device before starting to load
the
> > > > kernel code, which setups the iscsi card using the config stored in
> > > > hardward iscsi card memory.
> > > >
> > > > kdump need not do anything for this sort of hardware iscsi card, if
this
> > > > card does not have the feature iBFT. IBFT can export the iscsi
> > > > configuration from hardware iscsi card memroy to current running
kernel.
> > > > Thus iscsiadm cann't get the iscsi session info using
"iscsiadm -m
> > > > session -r /sys/block/xxx", due to limitation of iscsi info
exported by
> > > > kernel.
> > > >
> > > > Once the machine is plugged in this sort of hardware iscsi card,
kdump
> > > > returns as soon as possible.
> > >
> > > Since we do not know much about iscsi, could you describe the basic
infomation
> > > about them?
> > >
> > > 1. how many type of cases we should consider for iscsi?
> >
> > There are three iscsi initiators we use more frequently.
> > 1) software iscsi initiator
> > 2) iSCSI HBA
> > 3) iBFT
> >
> > >
> > > 2. what is the difference between them, how to diffrentiate them.
> >
> > 1) software iscsi initiator
> > - We can setup the iscsi environemnt by using tgt suit. It is more
> > continent to setup the iscsi without the hardware supporting.
> >
> > 2) iSCSI HBA
> > - System has no ability to detect the iscsi session config. The
> > usage of exported iSCSI device is the same as local SCSI device.
> >
> > 3) iBFT
> > - The iSCSI Bios Firmware Table (iBFT) is a table that is created in
> > memory which is mapped with the iSCSI card firmware. Thus we can get
> > the session config according to the command iscsiadm.
> > >
> > > 3. how to setup them (basic steps)
> >
> > 1) software iscsi initiator
> > - According to the command iscsiadm to setup the available seesion,
> > and the session info should be passed manually
> >
> > 2) iSCSI HBA
> > - Do nothing, except for passing "rd.iscsi.firmware=1" to the
> > kernel. The iSCSI device will use the config stored in firmware to
> > setup the session.
>
> So assume your patch is for addressing 2), if it is a boot disk there should
> be rd.iscsi.firmware=1 in /proc/cmdline, but if it is not a boot disk, we need
> pass this param to second kernel?
Hi, Dave.
Yes. This patch is to solve the situation 2) non-iBFT iSCSI HBA.
>
> What if there's both 2) and 1) existed?
>
We can inherit this parameter from 1st kernel. Thus we can do nothing to
bring up the iSCSI device, either boot device or non-boot device.
I think 1st kernel parameter is only for boot device. non-boot you still need
pass extra parameter to 2nd kernel cmdline.
Again about the second question, have you consider the situation both 1 and 2 being
used? ie. 1) for crash device, 2) for root device.
Thanks
Minfei
> >
> > 3) iBFT
> > - Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1" to
the kernel to
> > setup the session.