On Thu, 2005-02-24 at 23:21 -0500, Doug Ledford wrote:
> Don't use cmd->request->nr_hw_segments as it may not be initialized
> (SG_IO in particular bypasses anything that initializes this and just
> uses scsi_do_req to insert a scsi_request directly on the head of the
> queue)
should we fix that
On Thu, 2005-02-24 at 14:51 -0600, AJ Lewis wrote:
> "Nicholas A. Bellinger" <[EMAIL PROTECTED]> writes:
>
> > The following is the first public release of the PyX Technologies iSCSI
> > Initiator Core Stack v1.6.1.20 for Linux 2.6.11-rc4. This is a full
> > featured iSCSI Initiator stack that is
Doug Ledford wrote:
Don't use cmd->request->nr_hw_segments as it may not be initialized
(SG_IO in particular bypasses anything that initializes this and just
uses scsi_do_req to insert a scsi_request directly on the head of the
queue) and a bogus value here can trip up the checks to make sure that
On Thu, 24 Feb 2005, Doug Ledford wrote:
> Don't use cmd->request->nr_hw_segments as it may not be initialized
> (SG_IO in particular bypasses anything that initializes this and just
> uses scsi_do_req to insert a scsi_request directly on the head of the
> queue)
>
I opted to begin to use the nr_
Doug Ledford wrote:
Don't use cmd->request->nr_hw_segments as it may not be initialized
(SG_IO in particular bypasses anything that initializes this and just
uses scsi_do_req to insert a scsi_request directly on the head of the
queue) and a bogus value here can trip up the checks to make sure that
Don't use cmd->request->nr_hw_segments as it may not be initialized
(SG_IO in particular bypasses anything that initializes this and just
uses scsi_do_req to insert a scsi_request directly on the head of the
queue) and a bogus value here can trip up the checks to make sure that
the number of segmen
Matthew Wilcox wrote:
Found a funny in the sym2 driver I'm not sure how to resolve:
cp->sensecmd[0] = REQUEST_SENSE;
cp->sensecmd[1] = 0;
if (tp->tinfo.curr.scsi_version <= 2 && cp->lun <= 7)
cp->sensecmd[1] = c
Changes to the NCR5380 driver between 2.6.9 and 2.6.10 replaced the
driver's home-grown delayed work implementation with a call to
schedule_delayed_work(). However, the delay argument was not passed
correctly, so the work was usually scheduled for _way_ too far in
the future. This patch fixes th
Found a funny in the sym2 driver I'm not sure how to resolve:
cp->sensecmd[0] = REQUEST_SENSE;
cp->sensecmd[1] = 0;
if (tp->tinfo.curr.scsi_version <= 2 && cp->lun <= 7)
cp->sensecmd[1] = cp->lun << 5;
Thing
On Wednesday, February 23, 2005 6:45 AM, Gerhard wrote:
> To: linux-scsi@vger.kernel.org
> Subject: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
>
>
> Kernel: 2.6.10-rc4 w/ 3 tape patches from Kai Makisara
I'm not sure, but have you tried without those patches?
>
> SCSI: 53C1030 con
Since more than half a year ago, drivers/scsi/hosts.h gives a warning,
so it seems to be time to remove it.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 9 Feb 2005
--- linux-2.6.11-rc3-mm1-full/drivers/scsi/hosts.h 2004-12-24
22:34:30.0 +01
"Nicholas A. Bellinger" <[EMAIL PROTECTED]> writes:
> The following is the first public release of the PyX Technologies iSCSI
> Initiator Core Stack v1.6.1.20 for Linux 2.6.11-rc4. This is a full
> featured iSCSI Initiator stack that is capable of mulitplexing coast to
> coast across multiple ind
On Wed, 23 Feb 2005, Gerhard Schneider wrote:
>
> Kernel: 2.6.10-rc4 w/ 3 tape patches from Kai Makisara
>
> SCSI: 53C1030 controller, tape drive is on one channel of the
> controller.
>
> Tape: Overland Changer w/ Seagate LTO-1 drive
> Typical transfer speed: 12MB/s
>
> After adding a Megarai
This patch allows ipr to properly log 2 new RAID 6 related
errors.
Please apply with along the previous batch of ipr patches I sent.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6.11-rc4-bk9-bjking1/drivers/scsi/ipr.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
d
On Tue, Feb 22, 2005 at 03:14:50PM -0800, Greg KH wrote:
> On Tue, Feb 22, 2005 at 11:16:56AM -0600, mikem wrote:
> > I'd also like an (brief) explanation of why ioctls are so bad. I've seen
> > the
> > reasons of them never going away, etc. But from the beginning of time (UNIX)
> > ioctls have b
On Wednesday, February 23, 2005 11:35 AM, Andrew wrote:
> well, i installed SLES 8 and the system found its PERC 2/dc
> as an i2o block device.
> it loads all i2o_core, i2o_block, i2o_config, and i2o_pci
>
> and at i2o_pci it says to wait for more devices in the background
I2O mode is not for
16 matches
Mail list logo
