RE: SG_IO with >4k buffer size to iscsi sg device causes "Bad page" panic

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Herbert Xu > Sent: Wednesday, May 09, 2007 6:39 PM > To: Qi, Yanling > Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; open- > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Qi, > Y

RE: SG_IO with >4k buffer size to iscsi sg device causes "Bad page" panic

> -Original Message- > From: Mike Christie [mailto:[EMAIL PROTECTED] > Qi, Yanling wrote: > Yeah, this problem should occur in the upstream open-iscsi iscsi code. > open-iscsi works very similar to linux-scsi where it just sends pages > around with sock->ops-sendpage,

SG_IO with >4k buffer size to iscsi sg device causes "Bad page" panic

Hi All, This panic is related to the interactions between scsi/sg.c, iscsi initiator and tcp on the RHEL 2.6.9-42 kernel. But we may also have the similar problem with open-iscsi initiator. I will explain why we see the Bad page panic first. I did a patch to the sg driver to workaround the problem

panic in sd_rw_initr of SLSE10 PPC

Hi All, We have a 4GB Emulex HBA with 8.1.6 lpfc driver. The distribution is SLES10 on PowerPc. When we do a number of target-storage-system reboots, we see the following panic. Has any one seen this before? Thanks, Yanling Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=128 NUMA PSERIE

RE: [PATCH 0/2] : definion, code, and use of new SCSI ML hoststatus DID_COND_REQUEUE

I agree with Eric. RDAC/MPP will survive with the straight SAM BUSY status. --yanling > -Original Message- > From: Moore, Eric > Sent: Friday, February 02, 2007 5:59 PM > To: Edward Goggin; James Bottomley; Qi, Yanling > Cc: linux-scsi@vger.kernel.org > Subject: RE: [PAT

RE: [PATCH 0/2] : definion, code, and use of new SCSI ML hoststatus DID_COND_REQUEUE

e case, it > appears to allow an additional 30 seconds (beyond what DID_BUSY_BUSY > would allow) for a retry. [Qi, Yanling] The following code in the scsi_lib.c will be enough for RDAC/MPP. BTW, why do we do "wait_for = (cmd->allowed + 1) * cmd->timeout_per_command". With a

mptfc parallel device scan and modprobe

Hi All, I didn't follow the thread and progress of the parallel device scan at FC LLD driver module loading time in the list. I would like to understand the expected behavior of the parallel scan and insmod/modprobe. I have a configuration where I have 4 LSI FC ports. When I insmod the mptf

remove_on_dev_loss module parameter in scsi_transport_fc

Hi All, I saw SLES10 2.6.16.21-0.8-smp kernel supports a new module parameter "remove_on_dev_loss" in scsi_transport_fc. The parameter description is remove_on_dev_loss:Boolean. When the device loss timer fires, this variable controls whether the scsi infrastructure for the target device i