"erich" <[EMAIL PROTECTED]> wrote:
>
> Thanks for your doing.
> ARECA Linux RAID driver need to support old linux kerenel version.
> There are a lot of NAS RAID STORAGE SYSTEM development worker still use it
> at old linux kernel.
Well that's a decision which the scsi maintainers will need to
Hi,Andrew Morton
Thanks for your doing.
ARECA Linux RAID driver need to support old linux kerenel version.
There are a lot of NAS RAID STORAGE SYSTEM development worker still use it
at old linux kernel.
Maybe I need to released one package that as cleanly as look like a Linux
driver :) modern tim
"erich" <[EMAIL PROTECTED]> wrote:
>
> I have contact with Andrew Morton about ARECA RAID Linux scsi driver release
> issue.
> I hope this package is as look like a Linux driver.
No, it doesn't look anything like a Linux driver :(
I fed the patch through scripts/Lindent. There's a copy at
http
Noticed that in drivers/scsi/sym53c8xx.c:
sym53c8xx.c:13185: warning: integer constant is too large for "long" type
Since we're not dealing with C99 (yet), this 64 bit integer constant
needs to be suffixed with ULL. Patch included.
Mark F. Haigh
[EMAIL PROTECTED]
--- drivers/scsi/sym53c8xx.c.orig
On Wed, 2005-02-02 at 10:56 -0500, Ju, Seokmann wrote:
> + .sdev_attrs = megaraid_device_attrs,
> + .shost_attrs= megaraid_class_device_attrs,
These are, perhaps, slightly confusing names. The terms device and
class_device have well defined meanings
Cool! A good catch that could only be caught with many eyes looking at
the code.
Wasn't in my branch though, but it looks like a common typo ;-/. But the
sad part of this is that I use casts around voids to improve type
checking (and enforce/document intentions) and it now appears to be a
waste. I
On Wed, 2005-02-02 at 16:32 -0500, Salyzyn, Mark wrote:
> Cool! A good catch that could only be caught with many eyes looking at
> the code.
>
> Wasn't in my branch though, but it looks like a common typo ;-/.
It was my fault. I was asked to take the cast out but when I did I got
a compile warn
This patch does the following cleanups:
- make some needlessly global functions static
- remove qlogicisp.h since it doesn't contain much
- remove the unused functions isp1020_abort and isp1020_reset
Please review especially the latter two points.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
-
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 15 Nov 2004
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/sim710.c.old 2004-11-14
01:27:51.0 +0100
+++ linux-2.6.10-rc1-mm5-full/drivers/scsi/sim710.c
On Wed, 2005-02-02 at 15:55 -0500, [EMAIL PROTECTED] wrote:
> Testing was showing transport devices not being enumerated.
>
> The reason was the wrong attribute container was being compared
> against in the "match" functions. This patch fixes it.
OK, I confess ... I quietly fixed these three bef
Testing was showing transport devices not being enumerated.
The reason was the wrong attribute container was being compared
against in the "match" functions. This patch fixes it.
-- james s
diff -puN a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
--- a/drivers/scsi/scsi_
This patch does the following cleanups:
- make some needlessly global functions static
- remove qlogicfc.h since it doesn't contain much
- remove the unused function isp2x00_reset
Please review especially the latter two points.
---
This patch was already sent on:
- 15 Nov 2004
drivers/scsi/qlo
spot the typo... It's harmless, in a sense that code compiles right,
but...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC11-rc2-bk10-rme9652/drivers/scsi/aacraid/aachba.c
RC11-rc2-bk10-aacraid/drivers/scsi/aacraid/aachba.c
--- RC11-rc2-bk10-rme9652/drivers/scsi/aacraid/aach
On Tuesday, February 01, 2005 1:15 PM, Matt Domsch wrote:
> This patch is mangled. Long lines are wrapped, and appears to be in
> ISO-8859-1, such that spaces (ascii 0x20) appear as hex 0xa0. This
> makes it difficult to review, and impossible to apply.
>
> +// definitions for the device attribu
Hi,
I'm new to the Linux SCSI community. I got a few questions on how SCSI
drivers handle read/write failures.
When there is a latent sector fault (unable to read/write into a
sector), or if the data is corrupted (CRC failed), does the SCSI
drivers reissue the command ?
Does this differ from one
From: Douglas Gilbert [mailto:[EMAIL PROTECTED] writes:
> All may not be lost. If a medium error occurs and the ASC and
> ASCQ imply the sector could be read but
> failed ECC then the READ LONG SCSI command should fetch the
> block (plus ECC and other data). For example a Fujitsu MAM3184
> returns
16 matches
Mail list logo
