headers
Gilbert Wu | 1 Sep 2007 01:44
Favicon

Re: [PATCH] aic94xx: clean up PCI ID table per modern practice

On Fri, 2007-08-31 at 17:57 -0400, Jeff Garzik wrote:
> Gilbert Wu wrote:
> >   
> > On Fri, 2007-08-31 at 14:15 -0400, Jeff Garzik wrote:
> >> Gilbert Wu wrote:
> >>> Subject:  [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
> >>> driver to add new PCI ID for HBA ASC58300.
> >>>
> >>> Contribution:
> >>>    Gilbert Wu <gilbert_wu <at> adaptec.com>
> >>>
> >>>
> >>> Patch: apply to aic94xx-sas-2.6.git development tree
> >>>
> >>> Signed-off-by: Gilbert Wu <gilbert_wu <at> adaptec.com>
> >>>
> >>> Change Log:
> >>>
> >>> 1. Add new HBA PCI ID for ASC58300 which has eight port SAS and
> >>>    SATA PCI-X 133MHz low profile host bus adapter with two mini SAS
> >>>         4x external connectors. 
> >>>
> >>>
> >>>
> >>> diff -urN old/drivers/scsi/aic94xx/aic94xx_hwi.h
> >>> new/drivers/scsi/aic94xx/aic94xx_hwi.h
> >>> --- old/drivers/scsi/aic94xx/aic94xx_hwi.h	2007-08-30 16:34:21.000000000 -0700
> >>> +++ new/drivers/scsi/aic94xx/aic94xx_hwi.h	2007-08-30 16:34:02.000000000 -0700
> >>>  <at>  <at>  -45,6 +45,7  <at>  <at> 
> >>>   */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gilbert Wu | 1 Sep 2007 01:56
Favicon

Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device

On Fri, 2007-08-31 at 17:31 -0400, Douglas Gilbert wrote:
> Gilbert Wu wrote:
> > Subject:  [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
> > driver to fix smartctl utility problem.
> > 
> > Contribution:
> >    Gilbert Wu <gilbert_wu <at> adaptec.com>
> > 
> > Change Log:
> > 
> > 
> > 1. Fixed the problem that "smartctl -a /dev/some_sata_disk -d ata"
> >    does not work on aic94xx device drive with SATA devices.
> >    The smartctl utility send down ATA smart command to aic94xx
> >    driver and fail to get the result which is stored on ATA output
> >    register. 
> >    In normal case, Aic94xx’s firmware does not return the value of
> >    ATA output register to device driver due to performance reason.
> >    To solve this issue then the driver need to turn on internal
> >    flag (CSMI_TASK) for particular ATA command to enable firmware
> >    to return the value of ATA output register.
> 
> Recent versions of smartmontools (say 5.38 from CVS at
> sourceforge) don't need the '-d ata' option any more.
> 
> If smartctl or smartd see /dev/sd<x> in Linux, they will
> assume a SCSI disk, do an INQUIRY and if they see
> "ATA     " in the T10 vendor identification field then an
> ATA (most likely SATA) disk is assumed behind a SAT layer.
> Thereafter ATA commands will be issued, each wrapped in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andi Kleen | 1 Sep 2007 12:18
Picon

Re: [Bug 8942] dac960 driver stopped working with 2.6.22 kernel series


> So anyway, what's actually failing is one of these:

Thanks for the analysis.

In theory we could not fail DAC if the machine has <4GB RAM to work around
such buggy drivers, but then they would fail anyways with >4GB. Also
the failure was intended to allow some drivers to use more efficient non DAC
operation.

> It seems a bit mean to write off *all* VIA bridges as data-corruptors.
> Maybe the people who haven't had problems before can help us start a
> white-list of VIA PCI bridges that don't have a problem with DAC.

The reason I blacklisted all was that there was a small triple of data corruption
reports with VIA bridges. Also it's impossible to get any errata information
out of VIA. And there are not that many >4GB VIA systems because these
chipsets are usually used in lower end systems.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Andreas Koenecke | 1 Sep 2007 13:56
Picon

Re: usb-storage and Motorola Z6

* Freitag, 31. August 2007 um 16:56 (-0400) schrieb Alan Stern:
> 
> All those reset messages are caused by a bug in the device.  Every 
> command sent to the device is labelled with a "Tag" value; it shows up 
> in the debugging log on each "Bulk Command" line as the number 
> following the T.  For example:
> 
> 	Bulk Command S 0x43425355 T 0x4 L 18 F 128 Trg 0 LUN 0 CL 6
> 
> Here the Tag is 0x4.  In its status response, the device must include a
> matching Tag value to indicate which command the status is for.  If you
> look at the debugging log, you'll see the status line for this
> particular command was:
> 
> 	Bulk Status S 0x53425355 T 0x3 R 0 Stat 0x0
> 
> The Tag is 0x3, which doesn't match!  The device made this mistake 15
> times in 410 commands, apparently at random, and each time the computer
> issued a reset to try and fix the problem.  That's a pretty serious 
> bug in the Z6.
> 
> If you want to work around this bug, you can edit the file 
> drivers/usb/storage/transport.c.  In the usb_stor_Bulk_transport() 
> routine, edit this line:
> 
>         if (bcs->Tag != us->tag || bcs->Status > US_BULK_STAT_PHASE) {
> 
> and change it to:
> 
>         if (bcs->Status > US_BULK_STAT_PHASE) {
(Continue reading)

Permalink | Reply | 12 comments |
headers
Steven Hirsch | 1 Sep 2007 16:19
Picon

Problem w/ DLT7000 tape drive

I've been struggling with a Quantum DLT7000 SCSI tape drive for the past 
week, and I'm not sure where else to turn for help.  The problem is 
simple; the drive's hardware compression simply does not work when backing 
up my system.

System particulars:

- 2x Pentium III CPU  <at>  500Mhz.
- 896MB memory
- RAID 5 array on IBM Serveraid 4H controller
- DLT7000 on Adaptec 2940W controller.

I need to backup several logical volumes on the raid controller.  The raid 
controller can easily support continuous reads at > 30MB/s and the tape 
drive (a SCSI2 device) needs about 5MB/s to maintain streaming.

I have (3) of the tape units.  All of them pass the full manufacturer 
diagnostics, which presumably exercise compression.

I am using plain, old tar for backup (but have also tried dump/restore).

Regardless of archive application or block settings (and I've tried 
dozens), the tape runs out of room at 34.9 GB.  This is the uncompressed 
capacity for a DLTIV tape.  Compression is definitely engaged (the panel 
LED on the drive is illuminated).  Granted that the advertised 2:1 
compression is optimistic, but I'd still expect to see _some_ compression 
on a generic spread of data.

For a control, I turned off the hardware compression and ran tar with the 
'z' flag to pipe through gzip.  Everything fits with room to spare.  A
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Stern | 1 Sep 2007 17:30
Picon
Favicon

Re: [Linux-usb-users] usb-storage and Motorola Z6

On Sat, 1 Sep 2007, Andreas Koenecke wrote:

> I' done this, too.
> The non-debug-messages are now:
> ----------------------------------------------------------------------------
> Sep  1 13:09:17 kocom kernel: usb 3-1: new high speed USB device using ehci_hcd and address 12
> Sep  1 13:09:17 kocom kernel: usb 3-1: configuration #1 chosen from 1 choice
> Sep  1 13:09:17 kocom kernel: Initializing USB Mass Storage driver...
> Sep  1 13:09:17 kocom kernel: scsi7 : SCSI emulation for USB Mass Storage devices
> Sep  1 13:09:17 kocom kernel: usb-storage: device found at 12
> Sep  1 13:09:17 kocom kernel: usb-storage: waiting for device to settle before scanning
> Sep  1 13:09:17 kocom kernel: usbcore: registered new interface driver usb-storage
> Sep  1 13:09:17 kocom kernel: USB Mass Storage support registered.
> Sep  1 13:09:22 kocom kernel: usb-storage: device scan complete
> Sep  1 13:09:22 kocom kernel: scsi 7:0:0:0: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
> Sep  1 13:09:22 kocom kernel: scsi 7:0:0:1: Direct-Access     Motorola MSnc.                 PQ: 1 ANSI: 0 CCS
> Sep  1 13:09:22 kocom kernel: sd 7:0:0:0: [sdb] Attached SCSI removable disk
> Sep  1 13:09:22 kocom kernel: sd 7:0:0:0: Attached scsi generic sg2 type 0
> Sep  1 13:09:22 kocom kernel: sd 7:0:0:1: [sdc] Attached SCSI removable disk
> Sep  1 13:09:22 kocom kernel: sd 7:0:0:1: Attached scsi generic sg3 type 0
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] 1983495 512-byte hardware sectors (1016 MB)
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Write Protect is off
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] 1983495 512-byte hardware sectors (1016 MB)
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Write Protect is off
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
> Sep  1 13:09:28 kocom kernel:  sdb:
> Sep  1 13:09:28 kocom kernel: sd 7:0:0:1: [sdc] 128673 512-byte hardware sectors (66 MB)
(Continue reading)

Permalink | Reply | 10 comments |
headers
Gabriele Gorla | 2 Sep 2007 11:28
Picon
Favicon

[PATCH 2.6.22] 3w-xxxx: Fix bad unaligned accesses on alpha SMP

disable packing of the TAG_TW_Device_Extension
structure to prevent kernel unaligned accesses when
accessing ioctl_wqueue.
Fixes smartmontools kernel panic on alpha SMP

Signed-off-by: Gabriele Gorla <gorlik <at> yahoo.com>
---

--- linux-2.6.22/drivers/scsi/3w-xxxx.h.orig
2007-09-01 17:49:22.000000000 -0700
+++ linux-2.6.22/drivers/scsi/3w-xxxx.h 2007-09-01
17:49:45.000000000 -0700
 <at>  <at>  -392,6 +392,8  <at>  <at>  typedef struct TAG_TW_Passthru
        unsigned char padding[12];
 } TW_Passthru;

+#pragma pack()
+
 typedef struct TAG_TW_Device_Extension {
        u32                     base_addr;
        unsigned long
*alignment_virtual_address[TW_Q_LENGTH];
 <at>  <at>  -430,6 +432,4  <at>  <at>  typedef struct
TAG_TW_Device_Extension {
        wait_queue_head_t       ioctl_wqueue;
 } TW_Device_Extension;

-#pragma pack()
-
 #endif /* _3W_XXXX_H */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 2 Sep 2007 13:56

Fw: data disclosure in ioctl sg inquiry


Begin forwarded message:

Date: Mon, 27 Aug 2007 15:01:33 +0100
From: Luciano Rocha <strange <at> nsk.no-ip.org>
To: linux-kernel <at> vger.kernel.org
Subject: data disclosure in ioctl sg inquiry

(Please keep me CC'ed. Thanks.)

Hello,

While testing the SG INQUIRY command to a locked hard drive, connected
with USB, I noted that the command result included garbage that seemed
part of some other's process memory. Like bash functions, command
arguments, etc..

I make sure to memset the buffers before running the ioctl, so this seem
to be data leaked from the kernel.

Most of the code is verbatim from the example in the SCSI Generic HOWTO
(<http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html>).

I include the code I used and sample output with data from running
processes (or files?).

I can't reproduce this on a firewire connected HDD, but I can with
another USB connecte one (not locked).

Regards,
(Continue reading)

Permalink | Reply | 3 comments |
headers
FUJITA Tomonori | 2 Sep 2007 16:14
Picon
Favicon

Re: Fw: data disclosure in ioctl sg inquiry

On Sun, 2 Sep 2007 04:56:01 -0700
Andrew Morton <akpm <at> linux-foundation.org> wrote:

> 
> 
> Begin forwarded message:
> 
> Date: Mon, 27 Aug 2007 15:01:33 +0100
> From: Luciano Rocha <strange <at> nsk.no-ip.org>
> To: linux-kernel <at> vger.kernel.org
> Subject: data disclosure in ioctl sg inquiry
> 
> 
> 
> (Please keep me CC'ed. Thanks.)
> 
> Hello,
> 
> While testing the SG INQUIRY command to a locked hard drive, connected
> with USB, I noted that the command result included garbage that seemed
> part of some other's process memory. Like bash functions, command
> arguments, etc..
> 
> I make sure to memset the buffers before running the ioctl, so this seem
> to be data leaked from the kernel.
> 
> Most of the code is verbatim from the example in the SCSI Generic HOWTO
> (<http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html>).
> 
> I include the code I used and sample output with data from running
(Continue reading)

Permalink | Reply | 2 comments |
headers
Satyam Sharma | 2 Sep 2007 22:13
Favicon

[PATCH -mm] IPS SCSI driver: Check return of scsi_add_host()


drivers/scsi/ips.c: In function ‘ips_register_scsi’:
drivers/scsi/ips.c:6869:
warning: ignoring return value of ‘scsi_add_host’, declared with attribute warn_unused_result

scsi_add_host() is __must_check, so let's check it's return and cleanup
appropriately on errors.

Signed-off-by: Satyam Sharma <satyam <at> infradead.org>

---

 drivers/scsi/ips.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- linux-2.6.23-rc4-mm1/drivers/scsi/ips.c‾fix	2007-09-02 20:21:27.000000000 +0530
+++ linux-2.6.23-rc4-mm1/drivers/scsi/ips.c	2007-09-02 20:25:58.000000000 +0530
 <at>  <at>  -6866,7 +6866,12  <at>  <at>  ips_register_scsi(int index)
 	sh->max_channel = ha->nbus - 1;
 	sh->can_queue = ha->max_cmds - 1;

-	scsi_add_host(sh, NULL);
+	if (scsi_add_host(sh, NULL)) {
+		IPS_PRINTK(KERN_WARNING, ha->pcidev, "Unable to add SCSI host¥n");
+		free_irq(ha->irq, ha);
+		scsi_host_put(sh);
+		return -1;
+	}
 	scsi_scan_host(sh);
(Continue reading)

Permalink | Reply | 0 comments |

Gmane