aic79xx in scsi-misc would oops when no hardware was present.
Reason was a duplicated call to free the spi transport object -
it was done both in ahd_linux_exit and in the cleanup part
of ahd_linux_init.
Just remove the superfluous call.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linu
I'm not on this list but I thought someone here might be interested.
(please cc me if you respond)
I was tracking down a problem where some USB flash disks could not be
used with a 2.4.21 kernel. Apparently lots of "READ CAPACITY failed"
messages are generated.
It turns out the problem was caus
On Wed, 2005-08-31 at 10:45 +0200, Andi Kleen wrote:
> aic79xx in scsi-misc would oops when no hardware was present.
> Reason was a duplicated call to free the spi transport object -
> it was done both in ahd_linux_exit and in the cleanup part
> of ahd_linux_init.
>
> Just remove the superfluous c
This patch fixes in st.c the bug in the signed/unsigned int comparison
reported by Doug Gilbert and fixed by him in sg.c (see [PATCH] sg direct
io/mmap oops). Doug fixed the comparison in sg.c. This fix for st.c does not
touch the comparison but makes both arguments signed to remove the
problem. Th
On Mon, 29 Aug 2005, Frank Borich wrote:
> I have a controller with a firmware bug that mishandles
> underrun situations for inquiry commands. It correctly
> sets the FCP_RESID_UNDER flag however it miscalculates
> the FCP_RESID count. The 7.05.00 Qlogic driver for 2.4.x
> kernels thinks frame(s
> > --- a/drivers/scsi/qla2xxx/qla_attr.c
> > +++ b/drivers/scsi/qla2xxx/qla_attr.c
> > @@ -345,6 +345,15 @@ struct class_device_attribute *qla2x00_h
> >
> > /* Host attributes. */
> >
> > +static u64
> > +wwn_to_u64(uint8_t *wwn)
> > +{
> > + return (u64)wwn[0] << 56 | (u64)wwn[1] << 48 |
>
Signed-off-by: Andrew Vasquez <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -360,16 +360,16 @@ qla2x00_get_starget_node_name(struct scs
struct Scsi_Host
Signed-off-by: Andrew Vasquez <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -965,21 +965,21 @@ static void
lpfc_get_host_fabric_name (struct Scsi_Host *shost)
{
On Wed, 31 Aug 2005, Rudolph Pereira wrote:
> Aug 31 15:55:16 baku kernel: scsi(0): Sending Login IOCB (a0005000) to
> [81/0b1132].
> Aug 31 15:55:16 baku kernel: scsi(0): Process IODesc -- processing a0005000.
> Aug 31 15:55:16 baku kernel: scsi(0): Login IOCB -- status=0 mb1=0
> pn=21d0236
On Tue, 2005-08-30 at 22:33 -0700, Ravikiran G Thirumalai wrote:
> Are drivers/sources available for Adaptec's AIC-94XX SAS controllers
> someplace? I am trying to run 2.6.13 on a x460. Any pointers to the latest
> driver sources appreciated.
There is no driver source for Adaptec SATA hardware.
On Wed, 2005-08-31 at 16:08 -0400, James Bottomley wrote:
> On Tue, 2005-08-30 at 22:33 -0700, Ravikiran G Thirumalai wrote:
> > Are drivers/sources available for Adaptec's AIC-94XX SAS controllers
> > someplace? I am trying to run 2.6.13 on a x460. Any pointers to the latest
> > driver sources a
On Wed, Aug 31, 2005 at 04:08:32PM -0400, James Bottomley wrote:
> On Tue, 2005-08-30 at 22:33 -0700, Ravikiran G Thirumalai wrote:
> > Are drivers/sources available for Adaptec's AIC-94XX SAS controllers
> > someplace? I am trying to run 2.6.13 on a x460. Any pointers to the latest
> > driver so
On Thu, Aug 18, 2005 at 02:50:19PM -0500, Dmitry Torokhov wrote:
> On 8/18/05, Greg KH <[EMAIL PROTECTED]> wrote:
> > @@ -500,9 +519,13 @@ int class_device_add(struct class_device
> >}
> >
> >class_device_add_attrs(class_dev);
> > - if (class_dev->dev)
> > + if (class_d
Luben Tuikov wrote:
On 08/30/05 06:26, Tejun Heo wrote:
Albert Lee wrote:
4. Corresponding scmd's result code is set to
SAM_STAT_CHECK_CONDITION and qc->scsidone() callback is called
directly. As we haven't filled sense data,
scsi_determine_disposition() will return FAILED and SCSI EH wi
Tejun Heo wrote:
IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command
mapping as long as possible. And, in the suggested framework, it's
guaranteed that no other command can come inbetween CHECK_SENSE and
REQUEST_SENSE.
Requesting sense from EH, calling scsi_decide_dispositio
BTW I still have three of your documents to review and comment on.
Haven't forgotten about them.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.htm
Hello, Jeff.
On Wed, Aug 31, 2005 at 10:22:17PM -0400, Jeff Garzik wrote:
> Tejun Heo wrote:
> > IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command
> >mapping as long as possible. And, in the suggested framework, it's
> >guaranteed that no other command can come inbetween CHECK
On Wed, Aug 31, 2005 at 03:44:09PM -0700, Andrew Vasquez wrote:
> Hmm, could you try the attached small patch? This should close that
> whole where the fc_remote_port state is restored to a correct state.
This seems to fix the problem. The debug now shows:
...
Sep 1 10:05:15 baku kernel: scsi(0)
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command
> mapping as long as possible. And, in the suggested framework, it's
Yes, that makes sense.
> guaranteed that no other command can come inbetween CHECK_SENSE and
> REQUEST_SENSE.
T
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Tejun Heo wrote:
> > IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command
> > mapping as long as possible. And, in the suggested framework, it's
> > guaranteed that no other command can come inbetween CHECK_SENSE and
> > REQUEST_SENSE
Hi, Luben.
On Wed, Aug 31, 2005 at 08:30:27PM -0700, Luben Tuikov wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
> > IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command
> > mapping as long as possible. And, in the suggested framework, it's
>
> Yes, that makes sense.
>
> >
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> As implementing autosensing will probably need rewriting failed qc
> for REQUEST SENSE command, I'm opposing it. My proposal is to do the
> following, which, in effect, should be equivalent to autosensing.
>
> 1. ATAPI CHECK SENSE occurs
> 2. libata f
Hello, Luben.
Luben Tuikov wrote:
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
As implementing autosensing will probably need rewriting failed qc
for REQUEST SENSE command, I'm opposing it. My proposal is to do the
following, which, in effect, should be equivalent to autosensing.
1. ATAPI CHEC
On Thu, Sep 01, 2005 at 02:44:00PM +0900, Tejun Heo wrote:
> Can you please elaborate why getting sense data from EH is bad idea
> for ATAPI? For more advanced SCSI transports, I agree with you that
> autosensing is necessary with queueing and multiple initiator and etc,
> but I don't really s
On Wednesday 31 August 2005 16:43, Greg KH wrote:
> On Thu, Aug 18, 2005 at 02:50:19PM -0500, Dmitry Torokhov wrote:
> > On 8/18/05, Greg KH <[EMAIL PROTECTED]> wrote:
> > > @@ -500,9 +519,13 @@ int class_device_add(struct class_device
> > >}
> > >
> > >class_device_add_attrs(class
25 matches
Mail list logo
