[Scst-devel] system crash

[Brad J. <bjo...@pr...>]

The system running scst crashes when doing I/O to target from remote
system.

Here is my setup:
My target system has 2 Intel Xeon processors (3.2 MHz) and 1 GB RAM.
It is running Linux 2.6.15.7.
It has scst-0.9.4 and qla2x00-target-26-0.9.3.8 installed.
It has a Qlogic 2312 HBA connected to a switch. This is my FC target
host. (My FC Initiator is another x86 system with a Qlogic HBA also
connected to the switch.)
For back-end devices it has an LSI FC949X HBA connected to a Hitachi
Fibre-channel drive.

Here is my start script:
--------------------------------------------------------
modprobe -v qla2x00tgt
modprobe -v scst_disk
echo "add 2:0:3:0 0" >/proc/scsi_tgt/groups/Default/devices
echo "1" >/sys/class/scsi_host/host5/target_mode_enabled
--------------------------------------------------------

In the script, 2:0:3:0 refers to my Hitachi drive, host5 refers to my
Qlogic target-mode port. Everything starts successfully (including
scsi_tgt module since it is a dependency of scst_disk).

>From my initiator system I see the one drive I have exposed. I
successfully partition that drive and do mkfs. At this point everything
is still fine. I then mount the file system and copy a big file to it.
The copy seems to work fine but at some point shortly after that my
target system crashes. There is no oops output to the system log. So I
did it again with a remote kgdb attached. Here is the gdb output:


Program received signal SIGILL, Illegal instruction.
__free_pages (page=0xc190a22c, order=0) at mm/page_alloc.c:1055
1055            if (put_page_testzero(page)) {
(gdb) bt
#0  __free_pages (page=0xc190a22c, order=0) at mm/page_alloc.c:1055
#1  0xf8d61efd in scst_release_space (cmd=0xf40a4e58)
    at /root/mid-level/scst-0.9.4/src/scst_lib.c:1430
#2  0xf8d60b2a in scst_free_cmd (cmd=0xf40a4e58, check_retry=1)
    at /root/mid-level/scst-0.9.4/src/scst_lib.c:956
#3  0xf8d599ee in scst_finish_cmd (cmd=0xf40a4e58)
    at /root/mid-level/scst-0.9.4/src/scst_targ.c:2212
#4  0xf8d5a7df in __scst_process_active_cmd (cmd=0xf40a4e58,
    context=<value optimized out>, pflags=0xc046cfb8,
    left_locked=<value optimized out>)
    at /root/mid-level/scst-0.9.4/src/scst_targ.c:2461
#5  0xf8d5aa81 in scst_do_job_active (active_cmd_list=0xf8d756d0,
    pflags=0xc046cfb8, context=268435457)
    at /root/mid-level/scst-0.9.4/src/scst_targ.c:54
#6  0xf8d5af99 in scst_cmd_tasklet (p=<value optimized out>)
    at /root/mid-level/scst-0.9.4/src/scst_targ.c:2672
#7  0xc012d905 in tasklet_action (a=<value optimized out>)
    at kernel/softirq.c:267
#8  0xc012d552 in __do_softirq () at kernel/softirq.c:95
#9  0xc010619e in do_softirq () at arch/i386/kernel/irq.c:187
#10 0xc012d689 in irq_exit () at kernel/softirq.c:169
#11 0xc010604e in do_IRQ (regs=0xc1cf4f48) at arch/i386/kernel/irq.c:110
#12 0xc010499e in common_interrupt () at thread_info.h:91
#13 0xc1cf4000 in ?? ()
#14 0x00000000 in ?? ()


I can reproduce this easily every time. Let me know if you want any
further information about this.

...Brad Johnson