Begin forwarded message:
Date: Mon, 27 Nov 2006 23:28:18 +0200
From: Dan Aloni <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Subject: aic94xx breaks with SATA drives that have medium errors
Hello,
I'm currently testing the aic94xx driver from the latest git version of
Linux 2.6.19-rc g
On Mon, 2006-11-27 at 13:13 -0600, Mike Christie wrote:
> I thought they were continguous. I think James has said before that
> they
> can be disjoint. When we converted sg it did not look like sg or st
> supported disjoint. The main non dio path used a buffer from
> get_free_pages so I thought tha
On Mon, 27 Nov 2006, Mike Christie wrote:
> Mike Christie wrote:
> > Boaz Harrosh wrote:
> >> Playing with some tests which I admit are not 100% orthodox I have
> >> stumbled upon a bug that raises a serious question:
> >>
> >> In the call to scsi_execute_async() in the use_sg case, must the
> >>
Mike Christie wrote:
> Boaz Harrosh wrote:
>> Playing with some tests which I admit are not 100% orthodox I have
>> stumbled upon a bug that raises a serious question:
>>
>> In the call to scsi_execute_async() in the use_sg case, must the
>> scatterlist* (pointed to by buffer) map a buffer that's c
Boaz Harrosh wrote:
> Playing with some tests which I admit are not 100% orthodox I have
> stumbled upon a bug that raises a serious question:
>
> In the call to scsi_execute_async() in the use_sg case, must the
> scatterlist* (pointed to by buffer) map a buffer that's contiguous in
> virtual memo
Hi !
> It's a modified linux kernel with hooks for a big binary module that takes
> over part of the control. It's rather hard to argue that it's not a derived
> work. Especially as they reuse various I/O subsystem of the kernel
> that has been parasited.
They have put their modified sources f
Raymond Scholz wrote:
My initial (private) mail didn't contain any specific hardware
versions. So if it helps to track down the reason for the negotiation
problem, here they are:
LTO tape:
Host: scsi2 Channel: 00 Id: 06 Lun: 00
Vendor: CERTANCE Model: ULTRIUM 2Rev: 1823
Type: Seq
ยท Alexander Jolk <[EMAIL PROTECTED]> wrote:
> I have successfully used your procedure in order to get an HP LTO-3
> driver to work that's attached to an LSI/Fusion/MPT controller. That
> would seem to point to the drive or the scsi driver rather than the
> controller.
My initial (private) mail
Playing with some tests which I admit are not 100% orthodox I have stumbled
upon a bug that raises a serious question:
In the call to scsi_execute_async() in the use_sg case, must the scatterlist*
(pointed to by buffer) map a buffer that's contiguous in virtual memory or is
it allowed to map d
From: Randy Dunlap <[EMAIL PROTECTED]>
Use NULL instead of 0 for pointers (sparse warning):
drivers/scsi/qla2xxx/qla_attr.c:393:4: warning: Using plain integer as NULL
pointer
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/scsi/qla2xxx/qla_attr.c |2 +-
1 file changed, 1 insert
On Mon, 27 Nov 2006, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Use NULL instead of 0 for pointers (sparse warning):
> drivers/scsi/qla2xxx/qla_attr.c:393:4: warning: Using plain integer as NULL
> pointer
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Acked-by: Andre
Denny Page wrote:
The problem has to do with the speed negotiation that occurs on driver
initialization.
That I know of, there are 2 ways to address the problem.
For kernel 2.6.17 (and later), you can go into the Adaptec scsi bios
and explicitly limit the transfer speed for the target devic
On Fri, 24 Nov 2006, Adrian Bunk wrote:
> On Thu, Nov 23, 2006 at 02:17:03AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-rc5-mm2:
> >...
> > git-scsi-misc.patch
> >...
> > git trees
> >...
>
> qla2x00_reg_remote_port() can now become static.
>
> Signed-off-by: Adrian Bunk <[EMA
On Mon, Nov 27, 2006 at 10:45:42AM +0100, [EMAIL PROTECTED] wrote:
> > And more. It's in fact one of the most blatant violations of the
> > Linux 2.4 kernel copyrights. Don't expect support if you use such
> > an illegal product.
>
> really?
> this is the first time i hear that ESX is an "illega
> And more. It's in fact one of the most blatant violations of the
> Linux 2.4 kernel copyrights. Don't expect support if you use such
> an illegal product.
really?
this is the first time i hear that ESX is an "illegal" product from the point
of view of the kernel community.
afaik, the esx kern
15 matches
Mail list logo
