Bug 768214

Created attachment 547586 [details]
File: var_log_messages

Created attachment 547587 [details]
File: maps

Created attachment 547588 [details]
File: backtrace

*** Bug 768215 has been marked as a duplicate of this bug. ***

scsi-target-utils-1.0.18-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/scsi-target-utils-1.0.18-4.fc16

*** Bug 766617 has been marked as a duplicate of this bug. ***

Package scsi-target-utils-1.0.18-4.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing scsi-target-utils-1.0.18-4.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-17331/scsi-target-utils-1.0.18-4.fc16
then log in and leave karma (feedback).

scsi-target-utils-1.0.18-4.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

My server is freezing whenever I try to boot a client off of an iscsi-drive (I  have to hold the power button in to reboot the server).  I'm currently running scsi-target-utils-1.0.18-4.fc16.  I'm running the 3.1.6-1.fc16.i686.PAE kernel on an old Dell PowerEdge 1400 server.  The iscsi drive mounts and starts to boot but the iscsi server will completely freeze at some random time usually before the kernel on the client system is finished loading.  I had the same problem with the previous version of scsi-target-utils.  The only hint that I get of a problem in the log files is "Failed to read PID file /var/run/tgtd.pid after start. The service might be broken.".  Can/will anyone here help me to debug this problem?

P.S. Here is my current configuration:

cat /etc/tgt/targets.conf
<target iqn.2011-12.edu.siue.cs:boot.target1>
   backing-store /snap.img
</target>

tgtadm --lld iscsi --mode target --op show
Target 1: iqn.2011-12.edu.siue.cs:boot.target1
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Readonly: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 8590 MB, Block size: 512
            Online: Yes
            Removable media: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /snap.img
            Backing store flags: 
    Account information:
    ACL information:
        ALL

Is there a way that I can send an abrt report?

Probably doesn't matter, but just in case, the client is using syslinux's "sanboot" command to access and boot the iscsi target.  I used the following commands to create the client's boot floppy:

git clone git://git.etherboot.org/scm/gpxe.git
cd gpxe/src
make NO_WERROR=1 EMBEDDED_IMAGE=./static.gpxe bin/rtl8139.lkrn
dd if=/dev/zero of=floppy.img bs=1024 count=1440
mkfs.msdos floppy.img
syslinux --install floppy.img
mount -o loop floppy.img /mnt
cp bin/rtl8139.lkrn /mnt/rtl8139
umount /mnt
dd if=floppy.img of=/dev/fd0

And here are the contents of static.gpxe and the syslinux.cfg file on the root of the boot floppy:

cat static.gpxe 
#!gpxe
ifopen net0
set net0/ip 192.168.0.1
set net0/netmask 255.255.255.0
sanboot iscsi:192.168.0.254:::1:iqn.2011-12.edu.siue.cs:boot.target1

cat /mnt/syslinux.cfg 
default rtl8139

gb

Never mind.  It looks like it is a hardware problem.  I just tried scp'ing a large file through the NIC that I'm using for iSCSI and the server froze again.  It's probably a shared IRQ between the NIC and the RAID controller -- Dells are known for that sort of problem.

gb