Kernel panic during configuration
Bart Van Assche
disk, I twice experienced a kernel crash (2.6.22.9 kernel). For the
call stack (typed over from the console), see below. Can I do anything
more to help finding the cause of this, like posting the kernel config
or enabling kernel debug options ?
Call Trace:
<IRQ> [...] send_sig_info+0x53/0xb0
[...] :iscsi_target_mod:iscsi_handle_login_thread_timeout+0x0/0xd0
[...] :iscsi_target_mod:iscsi_handle_login_thread_timeout+0xa3/0xd0
[...] run_timer_softirq+0x163/0x1d0
[...] __do_softirq+0x69/0xe0
[...] call_softirq+0x1c/0x30
[...] smp_apic_timer_interrupt+0x55/0x80
[...] mwait_idle+0x0/0x50
[...] mwait_idle+0x0/0x50
[...] apic_timer_interrupt+0x66/0x70
<EOI> [...] mwait_idle+0x42/0x50
[...] cpu_idle+0x70/0xc0
Code: f0 ff 0f 79 1b a9 00 02 00 00 74 0b fb f3 90 83 3f 00 7e f9
RIP [...] _spin_lock_irqsave+0x3/0x30
RSP <ffff810158f53e88>
CR2: 000000000000000
Kernel panic - not syncing: Aiee, killing interrupt handler!
Bart Van Assche.
Nicholas A. Bellinger
Hmm, smells a possible mismatch between the running kernel and compiled
module. Is there anything particular about your configuration or
kernel..? Does the gcc that is building said modules match the version
string from /proc/version..? Also, what do your
trunk/target/.make_autoconfig look like after generating your local
version with trunk/target/autoconfig --write-to-file..?
--nab
>
> Bart Van Assche.
>
Bart Van Assche
> Hmm, smells a possible mismatch between the running kernel and compiled
> module. Is there anything particular about your configuration or
> kernel..? Does the gcc that is building said modules match the version
> string from /proc/version..? Also, what do your
> trunk/target/.make_autoconfig look like after generating your local
> version with trunk/target/autoconfig --write-to-file..?
I built the kernel myself from the Ubuntu-server kernel source tree,
and I had removed the directory /lib/modules/2.6.22.9 before starting
the build. There were no complaints about version mismatches in the
kernel log.
Note: I had to modify buildtools/ostype.pm before the software built.
--- ../orig/trunk/buildtools/ostype.pm 2008-02-01 16:15:55.000000000 +0100
+++ buildtools/ostype.pm 2008-02-01 13:45:09.000000000 +0100
@@ -37,6 +37,7 @@
$uname =~ s/\n+//g;
$rval->{ARCH}="x86_64" if ($uname =~ /64.*(AMD|Intel)/);
+ $rval->{ARCH}="x86_64" if ($uname =~ /x86-64/);
$rval->{ARCH}="i386" if ($uname =~ /32.*(AMD|Intel)/);
$rval->{ARCH}="ppc" if ($uname =~ /32.*(PowerPC)/);
$rval->{ARCH}="ppc64" if ($uname =~ /64.*(PowerPC)/);
$ cat target/.make_autoconfig
ARCH?=x86_64
AUTO_CFLAGS?= -DHAS_UTS_RELEASE -DUSE_SCSI_H
-I/lib/modules/2.6.22.9/source/drivers/scsi -DUSE_MSLEEP
-DUSE_COMPAT_IOCTL -Dscsi_execute_async_address
-DPYX_ISCSI_VENDOR='"Linux-iSCSI.org"'
-DIQN_PREFIX='"iqn.2003-01.org.linux-iscsi"' -DLINUX
-DLINUX_SCATTERLIST_HAS_PAGE -DSVN_VSN=\"193\"
BASENAME?=.x86_64
DISTRO?=UBUNTU
KERNEL?=26
KERNEL_DIR?=/lib/modules/2.6.22.9/build
KERNEL_INCLUDE_DIR?=/lib/modules/2.6.22.9/source/include
KERNEL_SOURCE_DIR?=/lib/modules/2.6.22.9/source
KERNEL_VERSION_INFO?=LINUX_KERNEL_26
LIBL?=x86_64
OSTYPE?=LINUX
PYX_ISCSI_VERSION?=2.9.0.193
RELEASE?=2.6.22.9
RELEASES?=ARRAY(0x925440)
RPM_DIR?=/usr/src/redhat
VERSION_IPYXD?=2.9.0.193
Bart Van Assche.
Nicholas A. Bellinger
Hmm, everything looks fine here.
On my JeOS VM that I use for LIO-VM kernel builds,
the /lib/modules/2.6.22-14-virtual/ symlinks look like:
lrwxrwxrwx 1 root root 40 2007-11-20 15:44 build -> /usr/src/linux-headers-2.6.22-14-virtual
lrwxrwxrwx 1 root root 5 2007-11-20 15:46 source -> build
I seem to recall having to install a specific package to get the proper
kernel sources for the default kernel, and I don't recall off the top of
my head. These packages are available as 'target-modules' and
'target-source', with the former buildable using module-assistant, from
the LIO ubuntu repository. There is an known issue with the PV-Ops
enabled kernel and mpt-fusion driver with 2.6.22-14-virtual FYI.
Anyways, you should be fine as long as the running kernel's config
matches the kernel source config from the KERNEL_*_DIR values
in .make_autoconfig, and the gcc versions match as mentioned above.
Out of curiousity, are you able to successfully build other out of tree
modules that use KBuild..?
--nab
> Bart Van Assche.
>
Nicholas A. Bellinger
Sorry, this should have been "with the latter buildable ..". The
target-source package is intended to be built using module-assistant in
debian compatible build environments. The target-modules package are
prebuilt kernel modules for the shipping kernels that where built using
module-assistant.
--nab
Bart Van Assche
> I seem to recall having to install a specific package to get the proper
> kernel sources for the default kernel, and I don't recall off the top of
> my head. These packages are available as 'target-modules' and
> 'target-source', with the former buildable using module-assistant, from
> the LIO ubuntu repository. There is an known issue with the PV-Ops
> enabled kernel and mpt-fusion driver with 2.6.22-14-virtual FYI.
>
> Anyways, you should be fine as long as the running kernel's config
> matches the kernel source config from the KERNEL_*_DIR values
> in .make_autoconfig, and the gcc versions match as mentioned above.
> Out of curiousity, are you able to successfully build other out of tree
> modules that use KBuild..?
The kernel I was using was built from the linux-source package. During
the kernel build process (make modules_install) the
/lib/modules/2.6.22.9/build directory was created correctly.
By this time I have build and installed kernel 2.6.23.14 (kernel.org)
and rebuilt the LIO kernel module (iscsi_target_mod). The crash
reappeared a few minutes after I had configured LIO. This excludes
Ubuntu-specific kernel modifications as a possible cause of the crash.
These are the commands I used to configure LIO (not sure that these
are correct):
rmmod iscsi_target_mod
modprobe iscsi_target_mod
target-ctl settargetname targetname=iqn.2007-05.com.example
target-ctl settpgattrib tpgt=1 authentication=0
target-ctl addtpg tpgt=1
target-ctl addnptotpg tpgt=1 dev=eth0 ip=$(ip -family inet addr show
dev eth0 | sed -n 's:.*inet \([0-9.]*\).*:\1:p') port=3260
target-ctl addnptotpg tpgt=1 dev=ib0 ip=$(ip -family inet addr show
dev ib0 | sed -n 's:.*inet \([0-9.]*\).*:\1:p') port=3260
target-ctl addhbatotarget hba_id=0 hba_type=5 scsi_host_id=0 rd_host_id=0
target-ctl createvirtdev hba_id=0 rd_device_id=0 rd_pages=$((2**31/4096))
target-ctl addluntodev tpgt=1 iscsi_lun=0 hba_id=0 fd_device_id=0
target-ctl enabletpg tpgt=1
Bart Van Assche.
Nicholas A. Bellinger
I never have personally tested this with IBoIP, so I am guessing this
may have something to do with it. For the sake of debugging, can do a
run across your ethernet interface first? (I am guessing this will
work).
Note that dev= for target-ctl op coreaddnp and addnptotpg is used to
obtain struct net_device which is used for checking network fabric
dependent PHY status registers via netif_carrier_ok(). In order to
determine link layer failures and notify the initiator via existing
communication paths when available in iSCSI/iSER ERL=2. I had to do
this originally because there was (I believe this is still the case) no
method exists to obtain struct net_device from struct sock.
Anyways, these timeout values are configurable with target-ctl
settpgattrib tpgt=$tpgt netif_timeout=$SECONDS for those interested.
For the sake of debugging this issue, lets set these dev=NULL and
disable the check for now.
> target-ctl addhbatotarget hba_id=0 hba_type=5 scsi_host_id=0 rd_host_id=0
You can remove the extra scsi_host_id= here, as it is only required with
hba_type=1 and PSCSI plugin is used. Also for future reference,
hba_type=5 is the ramdisk_dr and hba_type=6 is ramdisk_mcp. The former
simply sets pointers from frontend iovecs (as with traditional iSCSI) to
struct scatterlist mapped via the SE algoritim. The latter will do the
data copy from SE plugin allocated memory to the frontend memory.
ramdisk_mcp is required to maintain data integrity with shared storage
filesystems from multiple nexuses with ramdisk tests.
Btw, the list of hba_type values can be displayed via target-ctl
listgpluginfo.
> target-ctl createvirtdev hba_id=0 rd_device_id=0 rd_pages=$((2**31/4096))
Looks good.
> target-ctl addluntodev tpgt=1 iscsi_lun=0 hba_id=0 fd_device_id=0
Note that this should be rd_device_id=0, but target-ctl is assuming
rd_device_id=0 for the SE HBA and the LUN is being attached to the SE
object. This would not cause the problem btw.
> target-ctl enabletpg tpgt=1
>
One other thing for future reference; any target-ctl op that accepts
tpgt= as a parameter, can also accept targetname=. If no targetname= is
passed, the default that is registered via settargetname is used. Note
that the default IQN cannot be changed once it is set with the legacy
settargetname, or the new coreaddtiqn.
Also, can you tell me a bit more about your OFED and IB setup..?
Thanks,
--nab
Nicholas A. Bellinger
On Fri, 2008-02-01 at 17:14 +0100, Bart Van Assche wrote:
> On Feb 1, 2008 4:36 PM, Nicholas A. Bellinger <n...@linux-iscsi.org> wrote:
> > I seem to recall having to install a specific package to get the proper
> > kernel sources for the default kernel, and I don't recall off the top of
> > my head. These packages are available as 'target-modules' and
> > 'target-source', with the former buildable using module-assistant, from
> > the LIO ubuntu repository. There is an known issue with the PV-Ops
> > enabled kernel and mpt-fusion driver with 2.6.22-14-virtual FYI.
> >
> > Anyways, you should be fine as long as the running kernel's config
> > matches the kernel source config from the KERNEL_*_DIR values
> > in .make_autoconfig, and the gcc versions match as mentioned above.
> > Out of curiousity, are you able to successfully build other out of tree
> > modules that use KBuild..?
>
> The kernel I was using was built from the linux-source package. During
> the kernel build process (make modules_install) the
> /lib/modules/2.6.22.9/build directory was created correctly.
>
> By this time I have build and installed kernel 2.6.23.14 (kernel.org)
> and rebuilt the LIO kernel module (iscsi_target_mod). The crash
> reappeared a few minutes after I had configured LIO. This excludes
> Ubuntu-specific kernel modifications as a possible cause of the crash.
>
Did the backtrace look similar as the first one..?
--nab
Bart Van Assche
> Did the backtrace look similar as the first one..?
By this time I have modified the LIO configuration as you proposed in
your previous mail. I also found out that just configuring LIO is not
enough to trigger the crash -- the crash is triggered by iSCSI
discovery. This is how the crash can be reproduced on the test system:
* Download and compile Linux kernel 2.6.23.14 from kernel.org.
* Download and compile the Linux iSCSI target (IP: 10.100.100.10).
* Configure LIO (see below).
* Run the following command on another host on which open-iscsi is
installed (10.100.100.12): for ((i=0;i<100;i++)); do iscsiadm -m
discovery -t sendtargets -p 10.100.100.10; done
LIO configuration:
rmmod iscsi_target_mod
modprobe iscsi_target_mod
target-ctl settargetname targetname=iqn.2007-05.com.example
target-ctl addtpg tpgt=1
target-ctl settpgattrib tpgt=1 authentication=0
target-ctl addnptotpg tpgt=1 ip=$(ip -family inet addr show dev eth0
| sed -n 's:.*inet \([0-9.]*\).*:\1:p') port=3260
target-ctl addhbatotarget hba_id=0 hba_type=5 rd_host_id=0
target-ctl createvirtdev hba_id=0 rd_device_id=0 rd_pages=$((2**31/4096))
target-ctl addluntodev tpgt=1 iscsi_lun=0 hba_id=0 rd_device_id=0
target-ctl enabletpg tpgt=1
The following message appears in the kernel log (dmesg) of the target
system. A few seconds later the target system freezes (blinking caps
lock and scroll lock LEDs):
[ 342.716184] ------------------------------------------------------------------
[ 342.716186] HeaderDigest: None
[ 342.716187] DataDigest: None
[ 342.716190] MaxRecvDataSegmentLength: 32768
[ 342.716193] IFMarker: No
[ 342.716195] OFMarker: No
[ 342.716196] ------------------------------------------------------------------
[ 342.716199] ------------------------------------------------------------------
[ 342.716202] InitiatorName:
iqn.1993-08.org.debian:01:b5698b924985
[ 342.716205] TargetAlias: iSBE Target
[ 342.716206] InitiatorAlias: INF012
[ 342.716212] TargetPortalGroupTag: 0
[ 342.716215] DefaultTime2Wait: 2
[ 342.716217] DefaultTime2Retain: 0
[ 342.716219] ErrorRecoveryLevel: 0
[ 342.716221] SessionType: Discovery
[ 342.716224] ------------------------------------------------------------------
[ 342.716233] iSCSI Login successful on CID: 0 from 10.100.100.12 to
10.100.100.10:3260,0
[ 342.716235] Incremented iSCSI Connection count to 1 from node:
iqn.1993-08.org.debian:01:b5698b924985
[ 342.716237] Established iSCSI session from node:
iqn.1993-08.org.debian:01:b5698b924985
[ 342.716239] Incremented number of active iSCSI sessions to 1 on
iSCSI Target Portal Group: 0
[ 342.716293] Cleared np->np_login_tpg
[ 342.720516] Received iSCSI login request from 10.100.100.12 on TCP
Network Portal 10.100.100.10:3260
[ 342.720579] Set np->np_login_tpg to ffff81015a87c600
[ 342.720596] general protection fault: 0000 [1] SMP
[ 342.720756] CPU 0
[ 342.720863] Modules linked in: iscsi_target_mod ib_iser iscsi_tcp
libiscsi scsi_transport_iscsi rdma_ucm rdma_cm iw_cm ib_addr ib_uverbs
ib_ipoib ib_cm ib_sa ipv6 parport_pc lp parport loop af_packet
ib_mthca iTCO_wdt iTCO_vendor_support ib_mad ib_core serio_raw button
psmouse shpchp pci_hotplug pcspkr evdev ext3 jbd mbcache sg sd_mod
sr_mod cdrom ata_generic ata_piix libata scsi_mod ehci_hcd uhci_hcd
e1000 usbcore dm_mirror dm_snapshot dm_mod thermal processor fan fuse
[ 342.723464] Pid: 4911, comm: iscsi_np Not tainted 2.6.23.14 #1
[ 342.723533] RIP: 0010:[<ffffffff802919b0>] [<ffffffff802919b0>]
__kmalloc+0x70/0xc0
[ 342.723669] RSP: 0018:ffff81015341dd40 EFLAGS: 00010006
[ 342.723737] RAX: 0000000000000000 RBX: ffffffff8057c760 RCX: ffffffff88332984
[ 342.723808] RDX: ffff81015fe337a0 RSI: 00000000000000d0 RDI: 0000000000000004
[ 342.723879] RBP: 00000000000000d0 R08: 0000000000000005 R09: ffff810158fc0248
[ 342.723950] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000286
[ 342.724022] R13: 546e6f6973736553 R14: ffff810155a0df00 R15: 0000000000000001
[ 342.724094] FS: 00002b9e0eb5a6e0(0000) GS:ffffffff8052d000(0000)
knlGS:0000000000000000
[ 342.724181] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 342.724249] CR2: 00005555557e2000 CR3: 00000001554c6000 CR4: 00000000000006e0
[ 342.724321] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 342.724392] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 342.724464] Process iscsi_np (pid: 4911, threadinfo
ffff81015341c000, task ffff81015341a000)
[ 342.724551] Stack: ffff810155094c00 ffff810157739810
ffff810155103680 ffff810158fc0248
[ 342.724859] ffff8101552c61c0 ffffffff88332984 ffff81015428eed0
ffff810155094c00
[ 342.725121] ffff81015428ec00 ffff810155094e00 ffff81015341deb0
ffff81015341de00
[ 342.725325] Call Trace:
[ 342.725470] [<ffffffff88332984>]
:iscsi_target_mod:iscsi_copy_param_list+0xf4/0x520
[ 342.725575] [<ffffffff8834a3f5>]
:iscsi_target_mod:iscsi_target_login_thread+0xe45/0x2350
[ 342.725674] [<ffffffff8020cd38>] child_rip+0xa/0x12
[ 342.725759] [<ffffffff883495b0>]
:iscsi_target_mod:iscsi_target_login_thread+0x0/0x2350
[ 342.725847] [<ffffffff8020cd2e>] child_rip+0x0/0x12
[ 342.725915]
[ 342.725976]
[ 342.725976] Code: 49 8b 44 c5 00 48 89 42 10 41 54 9d 66 85 ed 78 1c 4c 89 e8
[ 342.727050] RIP [<ffffffff802919b0>] __kmalloc+0x70/0xc0
[ 342.727163] RSP <ffff81015341dd40>
Bart Van Assche.
Nicholas A. Bellinger
iscsiadm is restarting a new discovery session each time, yes?
There where some changes for N->N mapping between network portals and
and portal groups in the target frontend. I did have to make changes
between v2.8 -> v2.9 for the iSCSI target codebase, so it could be
breakage in Discovery SC/S iSCSI Login -> Discovery Session PDU/RSP ->
Logout -> Repeat statemachine order. I will have a look and see what I
can find.
The same many/constant Login -> PDU/RSP -> Logout statemachine case has
been tested recently against v2.9 with normal (non discovery)
traditional iSCSI sessions and connections and was fine, so I am
guessing this is related to the changes. Thanks for reporting this.
--nab
I updated trunk/target to 2.6.24 btw, and will posting some more details
on the changes to LIO SE, as I think it may be interesting for
discussion purposes of the target mode storage engine. Also have you
been able to move stable SessionType=Normal traffic on your setup with
IPoIB..?
> Bart Van Assche.
>
> >
Bart Van Assche
>
> I updated trunk/target to 2.6.24 btw, and will posting some more details
> on the changes to LIO SE, as I think it may be interesting for
> discussion purposes of the target mode storage engine. Also have you
> been able to move stable SessionType=Normal traffic on your setup with
> IPoIB..?
I have not yet been able to let the open-iscsi initiator talk to the
LIO iSCSI target. Were the LIO configuration commands that I
previously posted correct ?
I'm afraid that it will take some time before I can perform definitive
IPoIB measurements: my impression from the tests I have done with
iperf is that there is still a bug present in the Linux IPoIB
implementation that negatively impacts performance. See also
http://bugzilla.kernel.org/show_bug.cgi?id=9883.
Bart Van Assche.
Nicholas A. Bellinger
> On Feb 4, 2008 1:28 PM, Nicholas A. Bellinger <n...@linux-iscsi.org> wrote:
> >
> > I updated trunk/target to 2.6.24 btw, and will posting some more details
> > on the changes to LIO SE, as I think it may be interesting for
> > discussion purposes of the target mode storage engine. Also have you
> > been able to move stable SessionType=Normal traffic on your setup with
> > IPoIB..?
>
> I have not yet been able to let the open-iscsi initiator talk to the
> LIO iSCSI target. Were the LIO configuration commands that I
> previously posted correct ?
>
>> snip
> * Run the following command on another host on which open-iscsi is
> installed (10.100.100.12): for ((i=0;i<100;i++)); do iscsiadm -m
> discovery -t sendtargets -p 10.100.100.10; done
Can you get up and running with a single discovery session ok..?
> I'm afraid that it will take some time before I can perform definitive
> IPoIB measurements: my impression from the tests I have done with
> iperf is that there is still a bug present in the Linux IPoIB
> implementation that negatively impacts performance. See also
> http://bugzilla.kernel.org/show_bug.cgi?id=9883.
I recall someone getting iWARP + SDP working on a hardware RNIC
OpenIB-General recently. I have a set of the AMSO110 boards that I have
been meaning to give a shot with with the latest OFA code.
--nab
>
> Bart Van Assche.
>
> >
Bart Van Assche
>
> > * Run the following command on another host on which open-iscsi is
> > installed (10.100.100.12): for ((i=0;i<100;i++)); do iscsiadm -m
> > discovery -t sendtargets -p 10.100.100.10; done
>
> Can you get up and running with a single discovery session ok..?
iscsiadm did not report any targets, so I have not yet been able to
log in. Furthermore, the kernel crash reports seem to indicate memory
corruption, so I'd like to see this fixed before performing further
tests.
> > I'm afraid that it will take some time before I can perform definitive
> > IPoIB measurements: my impression from the tests I have done with
> > iperf is that there is still a bug present in the Linux IPoIB
> > implementation that negatively impacts performance. See also
> > http://bugzilla.kernel.org/show_bug.cgi?id=9883.
>
> I recall someone getting iWARP + SDP working on a hardware RNIC
> OpenIB-General recently. I have a set of the AMSO110 boards that I have
> been meaning to give a shot with with the latest OFA code.
There are several reports about unstable performance results for SDP
on the OFED mailing lists. See e.g.
http://lists.openfabrics.org/pipermail/ewg/2007-October/004789.html
Bart Van Assche.
Nicholas A. Bellinger
> On Feb 4, 2008 2:47 PM, Nicholas A. Bellinger <n...@linux-iscsi.org> wrote:
> >
> > > * Run the following command on another host on which open-iscsi is
> > > installed (10.100.100.12): for ((i=0;i<100;i++)); do iscsiadm -m
> > > discovery -t sendtargets -p 10.100.100.10; done
> >
> > Can you get up and running with a single discovery session ok..?
>
> iscsiadm did not report any targets, so I have not yet been able to
> log in. Furthermore, the kernel crash reports seem to indicate memory
> corruption, so I'd like to see this fixed before performing further
> tests.
So this is throwing the general protection fault on the very first
discovery session on your non IPoIB portal..? Also, what does your
open-iscsi version info look like btw..?
I will have a look at this on in VM later today.
>
> > > I'm afraid that it will take some time before I can perform definitive
> > > IPoIB measurements: my impression from the tests I have done with
> > > iperf is that there is still a bug present in the Linux IPoIB
> > > implementation that negatively impacts performance. See also
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9883.
> >
> > I recall someone getting iWARP + SDP working on a hardware RNIC
> > OpenIB-General recently. I have a set of the AMSO110 boards that I have
> > been meaning to give a shot with with the latest OFA code.
>
> There are several reports about unstable performance results for SDP
> on the OFED mailing lists. See e.g.
> http://lists.openfabrics.org/pipermail/ewg/2007-October/004789.html
>
Yeah, I personally like iSER better but we shall have to see how SDP
progresses.
--nab
Bart Van Assche
>
> So this is throwing the general protection fault on the very first
> discovery session on your non IPoIB portal..? Also, what does your
> open-iscsi version info look like btw..?
>
> I will have a look at this on in VM later today.
Sometimes the GPF happens on the first discovery session, sometimes
later on. According to dpkg-query the open-iscsi version is 2.0.865-1:
$ dpkg-query -s open-iscsi
Package: open-iscsi
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 592
Maintainer: Ubuntu MOTU Developers <ubunt...@lists.ubuntu.com>
Architecture: amd64
Version: 2.0.865-1
Depends: libc6 (>= 2.5-5)
Conffiles:
/etc/init.d/open-iscsi 321465094b3226ea4cfce3614da220b5
/etc/iscsi/iscsid.conf 305a0f218fe196cdad62f6ac3a1e7e45
/etc/iscsi/initiatorname.iscsi 300e739ab922027433765db3a88921c1
Description: High performance, transport independent iSCSI implementation
iSCSI is a network protocol standard that allows the use of the SCSI protocol
over TCP/IP networks. This implementation follows RFC3720.
.
Homepage: http://www.open-iscsi.org/
Original-Maintainer: Philipp Hug <deb...@hug.cx>
Bart Van Assche.