On 09/30/15 at 01:07pm, Dave Young wrote:
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.
I tested both boot and non-boot device as dumping target, and it works
on beaker machine.
Thanks
Minfei
> > >
> > > 3) iBFT
> > > - Pass "rd.iscsi.ibft=1" and "rd.iscsi.firmware=1"
to the kernel to
> > > setup the session.