HELLO MY NEW FRIEND
Hello, How are you doing? I guess you would be surprise to receive this message from a total stranger like myself, Well my name is Nathalie, I am a female Swedish national and a temporary staff of Qatar Development Bank (QDB) Please i need your attention to share a business deal with you. The success of this business depends on your cooperation. I will give you more details and also will share my pictures and private telephone number with you once you indicate interest by replying back to me. Have a good day, Regards, Nathalie J. Theodor -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
On 14.04.2014 12:01, Michael Schmitz wrote:
Hi Dave,
When this bit is set, the 53CF94/96 can receive 3-byte messages during
bus-initiated Select With ATN. This feature is also enabled by setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
Agreed. ESP_CONFIG2_SCSI2ENAB might do more than we intend, and have
unintended side effects. It's just easier to test whether this fixes
our problem.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
That's what I understood from the bits Kars quoted, yes. And in the
Amiga driver cases, it will always be the 3 byte message feature
controlled by that bit, as far as I can see.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
That would be even easier than setting it explicitly in the Zorro
driver, thanks,
Michael
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong jo...@linux-m68k.org
Reported-by: Michael Schmitz schmitz...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp-rev = ESP100;
} else {
-esp-config2 = 0;
+esp-config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp-rev = ESP236;
}
-esp-config2 = 0;
-esp_write8(esp-config2, ESP_CFG2);
}
}
}
Hello,
The patch above doesn't work. I've attached a log. Looks like the same
problem we've had all along.
The gzipped logs have all esp_scsi debug messages enabled for a
non-patched and patched versions.
-Tuomas
modprobe zorro_esp
zorro_esp: Blizzard 1230 found at address 0xea.
esp: esp0, regs[80ea8000:80eb] irq[2]
esp: esp0 is a FAS236, 40 MHz (ccf=0), SCSI ID 7
scsi0 : esp
scsi 0:0:2:0: Direct-Access SEAGATE ST51080N 0913 PQ: 0 ANSI: 2
scsi target0:0:2: Beginning Domain Validation
scsi target0:0:2: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
scsi target0:0:2: Domain Validation skipping write tests
scsi target0:0:2: Ending Domain Validation
sd 0:0:2:0: [sda] 2109840 512-byte logical blocks: (1.08 GB/1.00 GiB)
sd 0:0:2:0: [sda] Write Protect is off
sd 0:0:2:0: [sda] Write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
sd 0:0:2:0: Attached scsi generic sg0 type 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
Dev sda: unable to read RDB block 0
sda: unable to read partition table
sd 0:0:2:0: [sda] Attached SCSI disk
root@amiga:~# esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 20 31 00 00 00 08 00
end_request: I/O error, dev sda, sector 2109696
Buffer I/O error on device sda, logical block 263712
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 20 31 00 00 00 08 00
end_request: I/O error, dev sda, sector 2109696
Buffer I/O error on device sda, logical block 263712
esp: esp0: Reconnect IRQ2 timeout
Re: [PATCH v1.0 14/16] arcmsr: fix sparse checking error
Hi Dan,
In this patch, there are several replace of call readl() or writel()
by direct access to memory.
Because in main memory, we allocated a block of memory for
post_qbuffer and done_qbuffer.
These memory are access by both of CPU and IOP, they are not hardware registers.
This change will not introduce a bug. I have verified it.
Thanks for your comment.
Regards,
Ching
2014-05-02 17:13 GMT+08:00 Dan Carpenter dan.carpen...@oracle.com:
On Wed, Apr 30, 2014 at 07:38:26PM +0800, ching wrote:
From: Chingching2...@areca.com.tw
Fix sparse utility checking errors.
I was expecting that this patch would add __iomem annotations throughout
but in several places it actually removes calls to readl() and writel()
as well.
case ACB_ADAPTER_TYPE_C:{
- struct MessageUnit_C *reg = (struct MessageUnit_C *)acb-pmuC;
+ struct MessageUnit_C __iomem *reg = acb-pmuC;
/* disable all outbound interrupt */
orig_mask = readl(reg-host_int_mask); /* disable outbound
message0 int */
writel(orig_mask|ARCMSR_HBCMU_ALL_INTMASKENABLE,
reg-host_int_mask);v
@@ -1085,8 +1085,9 @@ static void arcmsr_done4abort_postqueue(
/*clear all outbound posted Q*/
writel(ARCMSR_DOORBELL_INT_CLEAR_PATTERN,
reg-iop2drv_doorbell); /* clear doorbell interrupt */
for (i = 0; i ARCMSR_MAX_HBB_POSTQUEUE; i++) {
- if ((flag_ccb = readl(reg-done_qbuffer[i])) != 0) {
- writel(0, reg-done_qbuffer[i]);
+ flag_ccb = reg-done_qbuffer[i];
+ if (flag_ccb != 0) {
+ reg-done_qbuffer[i] = 0;
pARCMSR_CDB = (struct ARCMSR_CDB
*)(acb-vir2phy_offset+(flag_ccb 5));/*frame must be 32 bytes aligned*/
pCCB = container_of(pARCMSR_CDB, struct
CommandControlBlock, arcmsr_cdb);
error = (flag_ccb
ARCMSR_CCBREPLY_FLAG_ERROR_MODE0) ? true : false;
I don't know the hardware, but it doesn't even seem to make sense to me.
if reg is an __iomem pointer surely an offset into reg is an iomem
pointer as well.
I am worried that this introduces a bug.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.0 12/16] arcmsr: revise alloction of second dma_coherent_handle for type B adapter
Hi Dan, This patch is not a bugfix. It is a simplification and consistency of coding for both adapter type B and D. Regards, Ching 2014-05-02 16:57 GMT+08:00 Dan Carpenter dan.carpen...@oracle.com: On Wed, Apr 30, 2014 at 07:30:29PM +0800, ching wrote: From: Chingching2...@areca.com.tw Revise allocation of second dma_coherent_handle for type_B adapter. Is this a bugfix? I think it is. Do you know what the user visible effects are? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MAINTAINERS: add an entry for all the NCR5380 drivers
Signed-off-by: Finn Thain fth...@telegraphics.com.au Cc: Michael Schmitz schmitz...@gmail.com --- As requested: http://marc.info/?l=linux-arm-kernelm=139853302724112w=2 diff --git a/MAINTAINERS b/MAINTAINERS index e67ea24..60ea600 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5996,6 +5996,28 @@ M: Petr Vandrovec p...@vandrovec.name S: Odd Fixes F: fs/ncpfs/ +NCR 5380 SCSI DRIVERS +M: Finn Thain fth...@telegraphics.com.au +M: Michael Schmitz schmitz...@gmail.com +L: linux-scsi@vger.kernel.org +S: Maintained +F: Documentation/scsi/g_NCR5380.txt +F: drivers/scsi/NCR5380.* +F: drivers/scsi/arm/cumana_1.c +F: drivers/scsi/arm/oak.c +F: drivers/scsi/atari_NCR5380.c +F: drivers/scsi/atari_scsi.* +F: drivers/scsi/dmx3191d.c +F: drivers/scsi/dtc.* +F: drivers/scsi/g_NCR5380.* +F: drivers/scsi/g_NCR5380_mmio.c +F: drivers/scsi/mac_scsi.* +F: drivers/scsi/pas16.* +F: drivers/scsi/sun3_NCR5380.c +F: drivers/scsi/sun3_scsi.* +F: drivers/scsi/sun3_scsi_vme.c +F: drivers/scsi/t128.* + NCR DUAL 700 SCSI DRIVER (MICROCHANNEL) M: James E.J. Bottomley james.bottom...@hansenpartnership.com L: linux-scsi@vger.kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
