Re: 2.6.24-rc5: tape drive not responding
On Mon, 17 Dec 2007 11:25:51 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Sun, 16 Dec 2007 20:05:51 -0500 John Stoffel [EMAIL PROTECTED] wrote: [ 215.007701] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.008145] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.008678] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.009122] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.009598] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010042] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010516] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010959] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.011403] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.011850] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae . . . [ 232.954629] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 233.035902] scsi 3:0:3:0: DEVICE RESET operation started [ 233.099514] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae . . . These repeat for about 15 seconds or so. They're really annoying and I'd love to see some sort of rate limiting put in here. The messages and end with: . . . [ 238.084175] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.165887] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.247157] scsi 3:0:3:0: DEVICE RESET operation timed-out. [ 238.313892] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.395192] scsi 3:0:3:0: BUS RESET operation started [ 238.455690] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.539216] sym1: SCSI BUS reset detected. [ 238.592552] sym1: SCSI BUS has been reset. [ 238.641576] scsi 3:0:3:0: BUS RESET operation complete. [ 248.700373] target3:0:3: wide asynchronous [ 248.752026] target3:0:3: Wide Transfers Fail [ 248.805220] target3:0:3: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15) [ 248.886729] target3:0:3: Domain Validation skipping write tests [ 248.958666] target3:0:3: Ending Domain Validation [ 252.264086] scsi 3:0:0:0: Attached scsi generic sg2 type 8 [ 252.331257] st 3:0:2:0: Attached scsi tape st0 [ 252.384549] st 3:0:2:0: st0: try direct i/o: yes (alignment 512 B) [ 252.458875] st 3:0:2:0: Attached scsi generic sg3 type 1 [ 252.523963] st 3:0:3:0: Attached scsi tape st1 [ 252.577184] st 3:0:3:0: st1: try direct i/o: yes (alignment 512 B) [ 252.651484] st 3:0:3:0: Attached scsi generic sg4 type 1 I've also got an ATL P1000 SCSI tape library hooked up to this same controller and port, and I can manipulate it properly using the 'mtx' program pointed to the /dev/changer alias, which points to the correct /dev/sg# device. Here's my /proc/scsi/scsi output, as you can see, I've got a bunch of devices on this system: # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: COMPAQ Model: HC01841729 Rev: 3208 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: COMPAQ Model: BD018222CA Rev: B016 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: ATL Model: P10006220051 Rev: 1.20 Type: Medium Changer ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 02 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2565 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 03 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2565 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi4 Channel: 00 Id: 00 Lun: 00 Vendor: SAMSUNG Model: CDRW/DVD SM-352B Rev: T806 Type: CD-ROM ANSI SCSI revision: 05 Host: scsi6 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3320620AS Rev: 3.AA Type: Direct-AccessANSI SCSI revision: 05 Host: scsi7 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD3200AAKS-0 Rev: 12.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi10 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1200JB-00C Rev: 17.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi11 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1200JB-00E Rev: 15.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi12 Channel: 00 Id: 00 Lun: 00 Vendor: Generic Model: STORAGE DEVICE Rev: 0001 Type: Direct-AccessANSI SCSI revision: 00 Host: scsi12 Channel: 00 Id: 00 Lun: 01 Vendor: Generic Model: STORAGE DEVICE Rev:
Re: INITIO scsi driver fails to work properly
On Mon, 17 Dec 2007 11:39:47 +0200 Filippos Papadopoulos [EMAIL PROTECTED] wrote: Hi, I have got an INITIO 9100 UW SCSI Controller with an IBM IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system. Currently i have SUSE 10.1 (Kernel 2.6.16). I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio driver gets loaded during the installation process, yast reports that no hard disk is found. I believe that this isnt a bug in suse's yast but a problem in the initio scsi driver because i also tried to install Fedora 8 (kernel 2.6.23) with the same problem. I have seen the relevant thread Conflict when loading initio driver and i suppose that the initio driver isnt fixed yet. I can help testing the new patches in the initio driver if someone is interested. initio doesn't seem to have a maintainer... Are you able to identify any earlier kernel which worked OK? Maybe it's a new device? If you can get the `lspci -vvxx' output for that device we can take a look. - 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.html
Re: INITIO scsi driver fails to work properly
On Dec 17, 2007 1:18 PM, Andrew Morton [EMAIL PROTECTED] wrote: On Mon, 17 Dec 2007 11:39:47 +0200 Filippos Papadopoulos [EMAIL PROTECTED] wrote: Hi, I have got an INITIO 9100 UW SCSI Controller with an IBM IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system. Currently i have SUSE 10.1 (Kernel 2.6.16). I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio driver gets loaded during the installation process, yast reports that no hard disk is found. I believe that this isnt a bug in suse's yast but a problem in the initio scsi driver because i also tried to install Fedora 8 (kernel 2.6.23) with the same problem. I have seen the relevant thread Conflict when loading initio driver and i suppose that the initio driver isnt fixed yet. I can help testing the new patches in the initio driver if someone is interested. initio doesn't seem to have a maintainer... Are you able to identify any earlier kernel which worked OK? I have this PC configuration since 2002. The initio driver worked perfectly with 2.4 kernel series. With the release of 2.6 kernel series the driver had been marked as BROKEN and fixed at 2.6.9 (see at http://www.gossamer-threads.com/lists/linux/kernel/482582?search_string=SCSI%20updates%20for%202.6.9;#482582 Christoph Hellwig -don't mark the initio 9100 driver broken) Maybe it's a new device? If you can get the `lspci -vvxx' output for that device we can take a look. No its not a new device. - 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.html
Re: INITIO scsi driver fails to work properly
On Mon, Dec 17 2007 at 13:41 +0200, Filippos Papadopoulos [EMAIL PROTECTED]
wrote:
On Dec 17, 2007 1:18 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 11:39:47 +0200 Filippos Papadopoulos [EMAIL
PROTECTED] wrote:
Hi,
I have got an INITIO 9100 UW SCSI Controller with an IBM
IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
Currently i have SUSE 10.1 (Kernel 2.6.16).
I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
driver
gets loaded during the installation process, yast reports that no hard
disk is found. I believe that this isnt a bug in suse's yast but a
problem
in the initio scsi driver because i also tried to install Fedora 8
(kernel 2.6.23) with the same problem.
I have seen the relevant thread Conflict when loading initio driver
and i suppose that the initio driver isnt fixed yet.
I can help testing the new patches in the initio driver if someone is
interested.
initio doesn't seem to have a maintainer...
Are you able to identify any earlier kernel which worked OK?
I have this PC configuration since 2002. The initio driver worked
perfectly with 2.4 kernel series.
With the release of 2.6 kernel series the driver had been marked as
BROKEN and fixed at 2.6.9
(see at
http://www.gossamer-threads.com/lists/linux/kernel/482582?search_string=SCSI%20updates%20for%202.6.9;#482582
Christoph Hellwig -don't mark the initio 9100 driver broken)
Maybe it's a new device? If you can get the `lspci -vvxx' output
for that device we can take a look.
No its not a new device.
-
I have found one problem. Please try patch [2] below and report.
If it still fails try to enable debugging by setting with patch [1]
these values at top of drivers/scsi/initio.c. And send dmsgs.
Boaz
patch [1]
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 4c4465d..61edcd2 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -138,10 +138,10 @@ static struct pci_device_id i91u_pci_devices[] = {
};
MODULE_DEVICE_TABLE(pci, i91u_pci_devices);
-#define DEBUG_INTERRUPT 0
-#define DEBUG_QUEUE 0
-#define DEBUG_STATE 0
-#define INT_DISC 0
+#define DEBUG_INTERRUPT 1
+#define DEBUG_QUEUE 1
+#define DEBUG_STATE 1
+#define INT_DISC 1
/*--- forward references ---*/
static struct scsi_ctrl_blk *initio_find_busy_scb(struct initio_host * host,
u16 tarlun);
---
patch [2]
---
git-diff --stat -p
drivers/scsi/initio.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 4c4465d..61595f6 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2616,6 +2616,7 @@ static void initio_build_scb(struct initio_host * host,
struct scsi_ctrl_blk * c
scsi_for_each_sg(cmnd, sglist, cblk-sglen, i) {
sg-data = cpu_to_le32((u32)sg_dma_address(sglist));
total_len += sg-len =
cpu_to_le32((u32)sg_dma_len(sglist));
+ sg++;
}
cblk-buflen = (scsi_bufflen(cmnd) total_len) ?
-
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.html
Re: INITIO scsi driver fails to work properly
On Mon, Dec 17 2007 at 14:18 +0200, Boaz Harrosh [EMAIL PROTECTED] wrote: On Mon, Dec 17 2007 at 13:41 +0200, Filippos Papadopoulos [EMAIL PROTECTED] wrote: On Dec 17, 2007 1:18 PM, Andrew Morton [EMAIL PROTECTED] wrote: On Mon, 17 Dec 2007 11:39:47 +0200 Filippos Papadopoulos [EMAIL PROTECTED] wrote: Hi, I have got an INITIO 9100 UW SCSI Controller with an IBM IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system. Currently i have SUSE 10.1 (Kernel 2.6.16). I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio driver gets loaded during the installation process, yast reports that no hard disk is found. I believe that this isnt a bug in suse's yast but a problem in the initio scsi driver because i also tried to install Fedora 8 (kernel 2.6.23) with the same problem. I have seen the relevant thread Conflict when loading initio driver and i suppose that the initio driver isnt fixed yet. I can help testing the new patches in the initio driver if someone is interested. initio doesn't seem to have a maintainer... Are you able to identify any earlier kernel which worked OK? I have this PC configuration since 2002. The initio driver worked perfectly with 2.4 kernel series. With the release of 2.6 kernel series the driver had been marked as BROKEN and fixed at 2.6.9 (see at http://www.gossamer-threads.com/lists/linux/kernel/482582?search_string=SCSI%20updates%20for%202.6.9;#482582 Christoph Hellwig -don't mark the initio 9100 driver broken) Maybe it's a new device? If you can get the `lspci -vvxx' output for that device we can take a look. No its not a new device. - I have found one problem. Please try patch [2] below and report. If it still fails try to enable debugging by setting with patch [1] these values at top of drivers/scsi/initio.c. And send dmsgs. Boaz I forgot to ask. 2.6.22 should work. If still fails could you try this 2.6.22.xx kernel? Boaz - 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.html
[PATCH 0/1] limit recovery retries
Hi, the next mail has a patch to offline a device when eh is activated again and again. Presently I have a system stopping to boot because one of the scsi-devices is in something like a zombie state. Without the patch, the eh is called in an endless loop, with the patch, it now deactivates the device, but still doesn't proceed to boot. Probably since the last scsi command never returns? [ 216.469912] Sending BRST chan: 0 [ 216.473241] sd 4:0:2:0: trying bus reset [ 216.477283] mptscsih: ioc2: attempting bus reset! (sc=810127db1500) [ 216.484041] sd 4:0:2:0: [sdg] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [ 216.865628] mptscsih: ioc2: bus reset: SUCCESS (sc=810127db1500) [ 256.835540] sd 4:0:2:0: Activating scsi error recovery [ 256.840812] Starting device recovery 2 [ 256.844676] sd 4:0:2:0: trying to abort command [ 256.849337] mptscsih: ioc2: attempting task abort! (sc=810127db1500) [ 256.856195] sd 4:0:2:0: [sdg] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [ 259.029233] mptbase: Initiating ioc2 recovery [ 272.175398] mptscsih: ioc2: Issue of TaskMgmt failed! [ 272.180587] mptscsih: ioc2: task abort: FAILED (sc=810127db1500) [ 272.187093] sd 4:0:2:0: Sending BDR 0x810129d9b960 [ 272.192351] sd 4:0:2:0: trying device reset [ 272.196757] mptscsih: ioc2: attempting target reset! (sc=810127db1500) [ 272.203790] sd 4:0:2:0: [sdg] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [ 274.377074] mptbase: Initiating ioc2 recovery [ 287.523243] mptscsih: ioc2: Issue of TaskMgmt failed! [ 287.528430] mptscsih: ioc2: target reset: FAILED (sc=810127db1500) [ 287.535103] Sending BRST chan: 0 [ 287.538438] sd 4:0:2:0: trying bus reset [ 287.542473] mptscsih: ioc2: attempting bus reset! (sc=810127db1500) [ 287.549239] sd 4:0:2:0: [sdg] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [ 287.930806] mptscsih: ioc2: bus reset: SUCCESS (sc=810127db1500) [ OK ] * Setting the system clock * Loading kernel modules... [ 291.296696] ACPI: Processor [CPU0] (supports 8 throttling states) [ 291.303304] ACPI: Processor [CPU1] (supports 8 throttling states) [ 291.309852] ACPI: Processor [CPU2] (supports 8 throttling states) [ 291.316407] ACPI: Processor [CPU3] (supports 8 throttling states) [ 291.322969] ACPI: Processor [CPU4] (supports 8 throttling states) [ 291.329522] ACPI: Processor [CPU5] (supports 8 throttling states) [ 291.336086] ACPI: Processor [CPU6] (supports 8 throttling states) [ 291.342644] ACPI: Processor [CPU7] (supports 8 throttling states) [ 327.896734] sd 4:0:2:0: Activating scsi error recovery [ 327.902005] Too many errors for this scsi host, deactivating its devices [ 327.908859] sd 4:0:2:0: scsi: Device offlined - not ready after error recovery [generate break] [ 2349.520917] SysRq : Show Blocked State [ 2349.524763] [ 2349.524764] free sibling [ 2349.533816] task PCstack pid father child younger older [ 2349.541612] modprobe D 001bdcb18803 0 2331 1 (NOTLB) [ 2349.548396] 810127015218 0086 810128c7 [ 2349.555997] 81012b5f8810 810127d04100 0005880e7bf8 [ 2349.563606] fffeff19 810001053400 0005 [ 2349.570994] Call Trace: [ 2349.573720] [804f070b] io_schedule+0x28/0x36 [ 2349.579040] [80263565] sync_page+0x4c/0x58 [ 2349.584181] [804f09f5] __wait_on_bit_lock+0x3c/0x6b [ 2349.590112] [80263e9d] __lock_page+0xa7/0xad [ 2349.595427] [8026522d] read_cache_page_async+0x114/0x17c [ 2349.601792] [8026529b] read_cache_page+0x6/0x3e [ 2349.607358] [802d3d33] read_dev_sector+0x2d/0x86 [ 2349.613020] [802d4688] read_lba+0x76/0xd1 [ 2349.618074] [802d477f] is_gpt_valid+0x9c/0x244 [ 2349.623572] [802d4a69] efi_partition+0x142/0x709 [ 2349.629252] [802d3bdc] rescan_partitions+0x161/0x28b [ 2349.635279] [802b49c6] do_open+0x10e/0x2e1 [ 2349.640420] [802b4c35] __blkdev_get+0x9c/0xd4 [ 2349.645823] [802b4c7b] blkdev_get+0xe/0x13 [ 2349.650955] [802d39ff] register_disk+0x1cb/0x247 [ 2349.656628] [80371de8] add_disk+0x37/0x41 [ 2349.661684] [8043e4dd] sd_probe+0x35c/0x442 [ 2349.666905] [803dab38] driver_probe_device+0xfa/0x18d [ 2349.673010] [803dabd4] __device_attach+0x9/0xe [ 2349.678505] [803d9d03] bus_for_each_drv+0x46/0x82 [ 2349.684271] [803dac4f] device_attach+0x76/0x9a [ 2349.689751] [803da083] bus_attach_device+0x3c/0xa1 [ 2349.695588] [803d8183] device_add+0x408/0x643 [ 2349.700990] [80435660] scsi_sysfs_add_sdev+0x40/0x2bf [ 2349.707095] [8043354a] scsi_probe_and_add_lun+0x946/0xa96
Re: [PATCH 1/1] limit recovery retries
Index: linux-2.6.22/drivers/scsi/scsi_error.c
===
--- linux-2.6.22.orig/drivers/scsi/scsi_error.c 2007-12-17 13:51:15.0
+0100
+++ linux-2.6.22/drivers/scsi/scsi_error.c 2007-12-17 13:56:25.0
+0100
@@ -1444,6 +1444,9 @@ static void scsi_restart_operations(stru
wake_up(shost-host_wait);
+ /* before starting the queues save the time of recovery */
+ shost-last_recovery = jiffies;
+
/*
* finally we need to re-initiate requests that may be pending. we will
* have had everything blocked while error handling is taking place, and
@@ -1550,6 +1553,30 @@ static void scsi_unjam_host(struct Scsi_
}
/**
+ * deactivate_host - deactiave all devices.
+ * @shost:Host for which we are deactivating the devices
+ *
+ */
+static void deactivate_host (struct Scsi_Host *shost)
+{
+ unsigned long flags;
+ LIST_HEAD(eh_work_q);
+ LIST_HEAD(eh_done_q);
+
+ spin_lock_irqsave(shost-host_lock, flags);
+ list_splice_init(shost-eh_cmd_q, eh_work_q);
+ spin_unlock_irqrestore(shost-host_lock, flags);
+
+ printk (KERN_WARNING Too many errors for this scsi host,
+ deactivating its devices\n);
+
+ scsi_eh_offline_sdevs (eh_work_q, eh_done_q);
+
+ wake_up(shost-host_wait);
+ scsi_run_host_queues(shost);
+}
+
+/**
* scsi_error_handler - SCSI error handler thread
* @data: Host for which we are running.
*
@@ -1586,6 +1613,19 @@ int scsi_error_handler(void *data)
printk(Error handler scsi_eh_%d waking up\n,
shost-host_no));
+ if (shost-last_recovery jiffies + 300 * HZ)
+ shost-n_errors++;
+ else
+ shost-n_errors = 1;
+
+ if (shost-n_errors 5) {
+ deactivate_host(shost);
+ goto out;
+ }
+
+ printk (KERN_WARNING Starting device recovery %d\n,
+ shost-n_errors);
+
/*
* We have a host that is failing for some reason. Figure out
* what we need to do to get it up and online again (if we can).
@@ -1603,6 +1643,8 @@ int scsi_error_handler(void *data)
* restart, we restart any I/O to any other devices on the bus
* which are still online.
*/
+
+out:
scsi_restart_operations(shost);
set_current_state(TASK_INTERRUPTIBLE);
}
Index: linux-2.6.22/include/scsi/scsi_host.h
===
--- linux-2.6.22.orig/include/scsi/scsi_host.h 2007-12-17 13:56:49.0
+0100
+++ linux-2.6.22/include/scsi/scsi_host.h 2007-12-17 13:57:55.0
+0100
@@ -518,6 +518,9 @@ struct Scsi_Host {
struct task_struct* ehandler; /* Error recovery thread. */
struct completion * eh_action; /* Wait for specific actions on the
host. */
+ time_t last_recovery; /* last time eh completed */
+ int n_errors; /* number failures within
+time limit */
wait_queue_head_t host_wait;
struct scsi_host_template *hostt;
struct scsi_transport_template *transportt;
--
Bernd Schubert
Q-Leap Networks GmbH
-
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.html
Re: INITIO scsi driver fails to work properly
initio doesn't seem to have a maintainer... Are you able to identify any earlier kernel which worked OK? Maybe it's a new device? If you can get the `lspci -vvxx' output for that device we can take a look. If I remember rightly the fixes for this went into the scsi tree a couple of months ago. The patch is in the -mm tree as well. No idea why its gotten stuck as an obvious one liner. Alan - 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.html
Re: FC-LTO4 tape drive: Sense Key : Illegal Request
James Smart [EMAIL PROTECTED] writes: This sounds like the recent lpfc bug found on the LTO-3 or LTO-4. The lpfc driver had messed up tag handling (a long time bug). The patch was posted at http://marc.info/?l=linux-scsim=119367024313743w=2 and has been pulled into scsi-rc-fixes, and I believe will be in 2.6.24. I use the patch with 2.6.23.8 and it works now. Thank you! Sven - 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.html
Re: INITIO scsi driver fails to work properly
On Mon, Dec 17 2007 at 15:05 +0200, Alan Cox [EMAIL PROTECTED] wrote: initio doesn't seem to have a maintainer... Are you able to identify any earlier kernel which worked OK? Maybe it's a new device? If you can get the `lspci -vvxx' output for that device we can take a look. If I remember rightly the fixes for this went into the scsi tree a couple of months ago. The patch is in the -mm tree as well. No idea why its gotten stuck as an obvious one liner. Alan - You mean this one: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=ba2c270154cc90c9a8bfc45b7bed4cca78c75aaf It's only queued for 2.6.25 via scsi-misc. I have found another bug. (See other mail in thread). I Will wait for testing and submit a proper patch. Boaz - 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.html
Re: INITIO scsi driver fails to work properly
On Mon, 17 Dec 2007 16:40:53 +0200 Boaz Harrosh [EMAIL PROTECTED] wrote: On Mon, Dec 17 2007 at 15:05 +0200, Alan Cox [EMAIL PROTECTED] wrote: initio doesn't seem to have a maintainer... Are you able to identify any earlier kernel which worked OK? Maybe it's a new device? If you can get the `lspci -vvxx' output for that device we can take a look. If I remember rightly the fixes for this went into the scsi tree a couple of months ago. The patch is in the -mm tree as well. No idea why its gotten stuck as an obvious one liner. Alan - You mean this one: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=ba2c270154cc90c9a8bfc45b7bed4cca78c75aaf It's only queued for 2.6.25 via scsi-misc. I have found another bug. (See other mail in thread). I Will wait for testing and submit a proper patch. That one yes - which really should have gone straight into the main tree as the initio driver has been broken all the time it sits queued for future patches. It can't make the problem any worse - the driver does not work. - 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.html
Re: INITIO scsi driver fails to work properly
On Mon, 2007-12-17 at 14:36 +, Alan Cox wrote: On Mon, 17 Dec 2007 16:40:53 +0200 Boaz Harrosh [EMAIL PROTECTED] wrote: On Mon, Dec 17 2007 at 15:05 +0200, Alan Cox [EMAIL PROTECTED] wrote: initio doesn't seem to have a maintainer... Are you able to identify any earlier kernel which worked OK? Maybe it's a new device? If you can get the `lspci -vvxx' output for that device we can take a look. If I remember rightly the fixes for this went into the scsi tree a couple of months ago. The patch is in the -mm tree as well. No idea why its gotten stuck as an obvious one liner. Alan - You mean this one: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=ba2c270154cc90c9a8bfc45b7bed4cca78c75aaf It's only queued for 2.6.25 via scsi-misc. I have found another bug. (See other mail in thread). I Will wait for testing and submit a proper patch. That one yes - which really should have gone straight into the main tree as the initio driver has been broken all the time it sits queued for future patches. It can't make the problem any worse - the driver does not work. Well, the change log isn't very committal for rush me immediately into main line plus, as far as I could dig out, there was no confirmation that it actually worked. This way, I can now say please try the current -mm kernel to the bug reporter and we get to see if this fixes the problem. James - 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.html
Re: INITIO scsi driver fails to work properly
On Mon, Dec 17 2007 at 17:03 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-17 at 14:36 +, Alan Cox wrote:
On Mon, 17 Dec 2007 16:40:53 +0200
Boaz Harrosh [EMAIL PROTECTED] wrote:
On Mon, Dec 17 2007 at 15:05 +0200, Alan Cox [EMAIL PROTECTED] wrote:
initio doesn't seem to have a maintainer...
Are you able to identify any earlier kernel which worked OK?
Maybe it's a new device? If you can get the `lspci -vvxx' output
for that device we can take a look.
If I remember rightly the fixes for this went into the scsi tree a couple
of months ago. The patch is in the -mm tree as well. No idea why its
gotten stuck as an obvious one liner.
Alan
-
You mean this one:
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=ba2c270154cc90c9a8bfc45b7bed4cca78c75aaf
It's only queued for 2.6.25 via scsi-misc.
I have found another bug. (See other mail in thread). I Will wait for
testing
and submit a proper patch.
That one yes - which really should have gone straight into the main tree
as the initio driver has been broken all the time it sits queued for
future patches. It can't make the problem any worse - the driver does not
work.
Well, the change log isn't very committal for rush me immediately into
main line plus, as far as I could dig out, there was no confirmation
that it actually worked. This way, I can now say please try the current
-mm kernel to the bug reporter and we get to see if this fixes the
problem.
James
Below fixes a deadly typo. Might as well be included in 2.6.24
Boaz
From fdf8ca414f9bb9a5a2cab602991cbac0b128ea65 Mon Sep 17 00:00:00 2001
From: Boaz Harrosh [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 18:04:11 +0200
Subject: [PATCH] initio: bugfix for accessors patch
patch: [SCSI] initio: convert to use the data buffer accessors
had a small but fatal bug. Fixed here.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/initio.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 769a7a8..01bf018 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2616,6 +2616,7 @@ static void initio_build_scb(struct initio_host * host,
struct scsi_ctrl_blk * c
scsi_for_each_sg(cmnd, sglist, cblk-sglen, i) {
sg-data = cpu_to_le32((u32)sg_dma_address(sglist));
total_len += sg-len =
cpu_to_le32((u32)sg_dma_len(sglist));
+ ++sg;
}
cblk-buflen = (scsi_bufflen(cmnd) total_len) ?
--
1.5.3.3
-
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.html
Re: INITIO scsi driver fails to work properly
On Mon, Dec 17, 2007 at 06:08:59PM +0200, Boaz Harrosh wrote:
Below fixes a deadly typo. Might as well be included in 2.6.24
You're sure ? scsi_for_each_sg includes a (sg)++ already...
scsi_for_each_sg(cmnd, sglist, cblk-sglen, i) {
sg-data = cpu_to_le32((u32)sg_dma_address(sglist));
total_len += sg-len =
cpu_to_le32((u32)sg_dma_len(sglist));
+ ++sg;
}
OG.
-
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.html
Re: INITIO scsi driver fails to work properly
On Mon, Dec 17 2007 at 18:20 +0200, Olivier Galibert [EMAIL PROTECTED] wrote:
On Mon, Dec 17, 2007 at 06:08:59PM +0200, Boaz Harrosh wrote:
Below fixes a deadly typo. Might as well be included in 2.6.24
You're sure ? scsi_for_each_sg includes a (sg)++ already...
scsi_for_each_sg(cmnd, sglist, cblk-sglen, i) {
sg-data = cpu_to_le32((u32)sg_dma_address(sglist));
total_len += sg-len =
cpu_to_le32((u32)sg_dma_len(sglist));
+++sg;
}
OG.
--
Don't mix up between the here sg that points to a driver specific struct
sg_entry
and the here sglist which points to struct scatterlist, and is named sg inside
the scsi_for_each_sg() macro. Please inspect the full code, the patch does not
show the complete information. I admit it's confusing.
Boaz
-
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.html
Re: 2.6.24-rc5: tape drive not responding
Andrew == Andrew Morton [EMAIL PROTECTED] writes: Andrew On Mon, 17 Dec 2007 11:25:51 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Sun, 16 Dec 2007 20:05:51 -0500 John Stoffel [EMAIL PROTECTED] wrote: [ 215.007701] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.008145] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.008678] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.009122] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.009598] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010042] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010516] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010959] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.011403] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.011850] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae . . . [ 232.954629] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 233.035902] scsi 3:0:3:0: DEVICE RESET operation started [ 233.099514] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae . . . These repeat for about 15 seconds or so. They're really annoying and I'd love to see some sort of rate limiting put in here. The messages and end with: . . . [ 238.084175] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.165887] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.247157] scsi 3:0:3:0: DEVICE RESET operation timed-out. [ 238.313892] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.395192] scsi 3:0:3:0: BUS RESET operation started [ 238.455690] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.539216] sym1: SCSI BUS reset detected. [ 238.592552] sym1: SCSI BUS has been reset. [ 238.641576] scsi 3:0:3:0: BUS RESET operation complete. [ 248.700373] target3:0:3: wide asynchronous [ 248.752026] target3:0:3: Wide Transfers Fail [ 248.805220] target3:0:3: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15) [ 248.886729] target3:0:3: Domain Validation skipping write tests [ 248.958666] target3:0:3: Ending Domain Validation [ 252.264086] scsi 3:0:0:0: Attached scsi generic sg2 type 8 [ 252.331257] st 3:0:2:0: Attached scsi tape st0 [ 252.384549] st 3:0:2:0: st0: try direct i/o: yes (alignment 512 B) [ 252.458875] st 3:0:2:0: Attached scsi generic sg3 type 1 [ 252.523963] st 3:0:3:0: Attached scsi tape st1 [ 252.577184] st 3:0:3:0: st1: try direct i/o: yes (alignment 512 B) [ 252.651484] st 3:0:3:0: Attached scsi generic sg4 type 1 I've also got an ATL P1000 SCSI tape library hooked up to this same controller and port, and I can manipulate it properly using the 'mtx' program pointed to the /dev/changer alias, which points to the correct /dev/sg# device. Here's my /proc/scsi/scsi output, as you can see, I've got a bunch of devices on this system: # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: COMPAQ Model: HC01841729 Rev: 3208 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: COMPAQ Model: BD018222CA Rev: B016 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: ATL Model: P10006220051 Rev: 1.20 Type: Medium Changer ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 02 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2565 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 03 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2565 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi4 Channel: 00 Id: 00 Lun: 00 Vendor: SAMSUNG Model: CDRW/DVD SM-352B Rev: T806 Type: CD-ROM ANSI SCSI revision: 05 Host: scsi6 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3320620AS Rev: 3.AA Type: Direct-AccessANSI SCSI revision: 05 Host: scsi7 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD3200AAKS-0 Rev: 12.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi10 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1200JB-00C Rev: 17.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi11 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1200JB-00E Rev: 15.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi12 Channel: 00 Id: 00 Lun: 00 Vendor: Generic Model: STORAGE DEVICE Rev: 0001 Type: Direct-AccessANSI
[PATCH] drivers/message/: Spelling fixes
Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
drivers/message/fusion/mptctl.c |8
drivers/message/fusion/mptscsih.c |2 +-
drivers/message/i2o/iop.c |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/message/fusion/mptctl.c b/drivers/message/fusion/mptctl.c
index 6029509..e630b50 100644
--- a/drivers/message/fusion/mptctl.c
+++ b/drivers/message/fusion/mptctl.c
@@ -1708,7 +1708,7 @@ mptctl_replace_fw (unsigned long arg)
*
* Outputs:None.
* Return: 0 if successful
- * -EBUSY if previous command timout and IOC reset is not
complete.
+ * -EBUSY if previous command timeout and IOC reset is not
complete.
* -EFAULT if data unavailable
* -ENODEV if no such device/adapter
* -ETIME if timer expires
@@ -1748,7 +1748,7 @@ mptctl_mpt_command (unsigned long arg)
*
* Outputs:None.
* Return: 0 if successful
- * -EBUSY if previous command timout and IOC reset is not
complete.
+ * -EBUSY if previous command timeout and IOC reset is not
complete.
* -EFAULT if data unavailable
* -ENODEV if no such device/adapter
* -ETIME if timer expires
@@ -2316,7 +2316,7 @@ done_free_mem:
* Outputs:None.
* Return: 0 if successful
* -EFAULT if data unavailable
- * -EBUSY if previous command timout and IOC reset is not
complete.
+ * -EBUSY if previous command timeout and IOC reset is not
complete.
* -ENODEV if no such device/adapter
* -ETIME if timer expires
* -ENOMEM if memory allocation error
@@ -2553,7 +2553,7 @@ mptctl_hp_hostinfo(unsigned long arg, unsigned int
data_size)
* Outputs:None.
* Return: 0 if successful
* -EFAULT if data unavailable
- * -EBUSY if previous command timout and IOC reset is not
complete.
+ * -EBUSY if previous command timeout and IOC reset is not
complete.
* -ENODEV if no such device/adapter
* -ETIME if timer expires
* -ENOMEM if memory allocation error
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
index 626bb3c..7d3d2de 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -1736,7 +1736,7 @@ mptscsih_IssueTaskMgmt(MPT_SCSI_HOST *hd, u8 type, u8
channel, u8 id, int lun, i
fail_out:
/*
-* Free task managment mf, and corresponding tm flags
+* Free task management mf, and corresponding tm flags
*/
mpt_free_msg_frame(ioc, mf);
hd-tmPending = 0;
diff --git a/drivers/message/i2o/iop.c b/drivers/message/i2o/iop.c
index 7814a06..da715e1 100644
--- a/drivers/message/i2o/iop.c
+++ b/drivers/message/i2o/iop.c
@@ -916,7 +916,7 @@ static int i2o_parse_hrt(struct i2o_controller *c)
* status block. The status block could then be accessed through
* c-status_block.
*
- * Returns 0 on sucess or negative error code on failure.
+ * Returns 0 on success or negative error code on failure.
*/
int i2o_status_get(struct i2o_controller *c)
{
--
1.5.3.7.949.g2221a6
-
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.html
[PATCH] drivers/scsi/: Spelling fixes
Signed-off-by: Joe Perches [EMAIL PROTECTED] --- drivers/scsi/NCR53C9x.h |2 +- drivers/scsi/aic7xxx/aic79xx_inline.h |2 +- drivers/scsi/aic7xxx/aic79xx_osm.c|2 +- drivers/scsi/aic7xxx/aic79xx_pci.c|4 ++-- drivers/scsi/aic7xxx/aic7xxx_inline.h |2 +- drivers/scsi/aic7xxx/aic7xxx_osm.c|2 +- drivers/scsi/ipr.c|2 +- drivers/scsi/ips.c|2 +- drivers/scsi/iscsi_tcp.c |4 ++-- drivers/scsi/lpfc/lpfc.h |2 +- drivers/scsi/lpfc/lpfc_mbox.c |2 +- drivers/scsi/megaraid/megaraid_mbox.c | 10 +- drivers/scsi/psi240i.c|2 +- drivers/scsi/qla2xxx/qla_gs.c |2 +- drivers/scsi/qla4xxx/ql4_def.h|2 +- drivers/scsi/qla4xxx/ql4_init.c |2 +- drivers/scsi/scsi_tgt_lib.c |2 +- drivers/scsi/scsi_transport_sas.c |2 +- 18 files changed, 24 insertions(+), 24 deletions(-) diff --git a/drivers/scsi/NCR53C9x.h b/drivers/scsi/NCR53C9x.h index d85cb73..00a0ba0 100644 --- a/drivers/scsi/NCR53C9x.h +++ b/drivers/scsi/NCR53C9x.h @@ -1,6 +1,6 @@ /* NCR53C9x.c: Defines and structures for the NCR53C9x generic driver. * - * Originaly esp.h: Defines and structures for the Sparc ESP + * Originally esp.h: Defines and structures for the Sparc ESP * (Enhanced SCSI Processor) driver under Linux. * * Copyright (C) 1995 David S. Miller ([EMAIL PROTECTED]) diff --git a/drivers/scsi/aic7xxx/aic79xx_inline.h b/drivers/scsi/aic7xxx/aic79xx_inline.h index 2ceb67f..45e5557 100644 --- a/drivers/scsi/aic7xxx/aic79xx_inline.h +++ b/drivers/scsi/aic7xxx/aic79xx_inline.h @@ -417,7 +417,7 @@ ahd_targetcmd_offset(struct ahd_softc *ahd, u_int index) - (uint8_t *)ahd-qoutfifo); } -/*** Miscelaneous Support Functions ***/ +/*** Miscellaneous Support Functions ***/ static __inline struct ahd_initiator_tinfo * ahd_fetch_transinfo(struct ahd_softc *ahd, char channel, u_int our_id, diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c index 2d02040..500b0b7 100644 --- a/drivers/scsi/aic7xxx/aic79xx_osm.c +++ b/drivers/scsi/aic7xxx/aic79xx_osm.c @@ -325,7 +325,7 @@ MODULE_PARM_DESC(aic79xx, verbose Enable verbose/diagnostic logging\n allow_memio Allow device registers to be memory mapped\n debug Bitmask of debug values to enable\n - no_resetSupress initial bus resets\n + no_resetSuppress initial bus resets\n extendedEnable extended geometry on all controllers\n periodic_otag Send an ordered tagged transaction\n periodically to prevent tag starvation.\n diff --git a/drivers/scsi/aic7xxx/aic79xx_pci.c b/drivers/scsi/aic7xxx/aic79xx_pci.c index 7a203a9..dd71995 100644 --- a/drivers/scsi/aic7xxx/aic79xx_pci.c +++ b/drivers/scsi/aic7xxx/aic79xx_pci.c @@ -977,7 +977,7 @@ ahd_aic790X_setup(struct ahd_softc *ahd) | AHD_FAINT_LED_BUG; /* -* IO Cell paramter setup. +* IO Cell parameter setup. */ AHD_SET_PRECOMP(ahd, AHD_PRECOMP_CUTBACK_29); @@ -1004,7 +1004,7 @@ ahd_aic790X_setup(struct ahd_softc *ahd) ahd-bugs |= AHD_INTCOLLISION_BUG|AHD_ABORT_LQI_BUG; /* -* IO Cell paramter setup. +* IO Cell parameter setup. */ AHD_SET_PRECOMP(ahd, AHD_PRECOMP_CUTBACK_29); AHD_SET_SLEWRATE(ahd, AHD_SLEWRATE_DEF_REVB); diff --git a/drivers/scsi/aic7xxx/aic7xxx_inline.h b/drivers/scsi/aic7xxx/aic7xxx_inline.h index 8e1954c..cba2f23 100644 --- a/drivers/scsi/aic7xxx/aic7xxx_inline.h +++ b/drivers/scsi/aic7xxx/aic7xxx_inline.h @@ -229,7 +229,7 @@ ahc_name(struct ahc_softc *ahc) return (ahc-name); } -/*** Miscelaneous Support Functions ***/ +/*** Miscellaneous Support Functions ***/ static __inline void ahc_update_residual(struct ahc_softc *ahc, struct scb *scb); diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c b/drivers/scsi/aic7xxx/aic7xxx_osm.c index 390b0fc..50058e8 100644 --- a/drivers/scsi/aic7xxx/aic7xxx_osm.c +++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c @@ -347,7 +347,7 @@ MODULE_PARM_DESC(aic7xxx, debug Bitmask of debug values to enable\n no_probeToggle EISA/VLB controller probing\n probe_eisa_vl Toggle EISA/VLB controller probing\n - no_resetSupress initial bus resets\n + no_reset
[PATCH] include/scsi/: Spelling fixes
Signed-off-by: Joe Perches [EMAIL PROTECTED] --- include/scsi/scsi_transport_fc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h index e466d88..4769efd 100644 --- a/include/scsi/scsi_transport_fc.h +++ b/include/scsi/scsi_transport_fc.h @@ -176,7 +176,7 @@ struct class_device_attribute class_device_attr_vport_##_name = \ * ports has a unique presense on the SAN, and may be instantiated via * NPIV, Virtual Fabrics, or via additional ALPAs. As the vport is a * unique presense, each vport has it's own view of the fabric, - * authentication priviledge, and priorities. + * authentication privilege, and priorities. * * A virtual port may support 1 or more FC4 roles. Typically it is a * FCP Initiator. It could be a FCP Target, or exist sole for an IP over FC -- 1.5.3.7.949.g2221a6 - 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.html
Re: [PATCH] drivers/scsi/: Spelling fixes
Joe Perches wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c index 57ce225..3cc21f5 100644 --- a/drivers/scsi/iscsi_tcp.c +++ b/drivers/scsi/iscsi_tcp.c @@ -1121,7 +1121,7 @@ iscsi_send(struct iscsi_conn *conn, struct iscsi_buf *buf, int size, int flags) * iscsi_sendhdr - send PDU Header via tcp_sendpage() * @conn: iscsi connection * @buf: buffer to write from - * @datalen: lenght of data to be sent after the header + * @datalen: length of data to be sent after the header * * Notes: * (Tx, Fast Path) @@ -1724,7 +1724,7 @@ send_hdr: * XMSTATE_BIT_SOL_DATA - send solicit data * *iscsi_tcp_ctask_xmit - * XMSTATE_BIT_IMM_DATA - xmit managment data (??) + * XMSTATE_BIT_IMM_DATA - xmit management data (??) **/ static int iscsi_tcp_ctask_xmit(struct iscsi_conn *conn, struct iscsi_cmd_task *ctask) Olaf rewrote this code and it will not exist when James merges the patches, so you can drop the iscsi bits. - 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.html
Re: 2.6.24-rc5: tape drive not responding
Andrew == Andrew Morton [EMAIL PROTECTED] writes: Andrew On Mon, 17 Dec 2007 11:25:51 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Sun, 16 Dec 2007 20:05:51 -0500 John Stoffel [EMAIL PROTECTED] wrote: [ 273.382057] sd 12:0:0:3: Attached scsi generic sg13 type 0 [ 276.244872] [ cut here ] [ 276.300215] kernel BUG at include/linux/scatterlist.h:59! [ 276.364873] invalid opcode: [#1] SMP [ 276.414346] Modules linked in: [ 276.451148] [ 276.469036] Pid: 1824, comm: stinit Not tainted (2.6.24-rc5 #2) [ 276.539940] EIP: 0060:[c0343c30] EFLAGS: 00010213 CPU: 0 [ 276.605651] EIP is at st_do_scsi+0x2e0/0x340 [ 276.656788] EAX: EBX: ECX: c16ef780 EDX: f7c4f050 [ 276.731847] ESI: f7c4f7d0 EDI: 1000 EBP: f7c4f000 ESP: f712bdf8 [ 276.806904] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 276.871568] Process stinit (pid: 1824, ti=f712b000 task=f750a030 task.ti=f712b000) [ 276.960139] Stack: 0003 f7c4f050 00d59f80 f776fe20 c03468a0 [ 277.062012]00d0 f712be9c f7d2a000 f776fe20 f7d2a018 0006 f712be9c [ 277.163890]f7d2a000 f712beac f7c4f000 c0345790 0006 0002 000dbba0 [ 277.265771] Call Trace: [ 277.297383] [c03468a0] st_sleep_done+0x0/0x70 [ 277.352894] [c0345790] check_tape+0x510/0x640 [ 277.408414] [c0346cfb] st_open+0x18b/0x220 [ 277.460803] [c01707e0] exact_match+0x0/0x10 [ 277.514237] [c0346b70] st_open+0x0/0x220 [ 277.564553] [c0170ebf] chrdev_open+0x9f/0x190 [ 277.620069] [c0170e20] chrdev_open+0x0/0x190 [ 277.674543] [c016c86f] __dentry_open+0xaf/0x1b0 [ 277.732136] [c016ca25] nameidata_to_filp+0x35/0x40 [ 277.792847] [c016ca7b] do_filp_open+0x4b/0x60 [ 277.848364] [c016c732] get_unused_fd_flags+0x52/0xd0 [ 277.911153] [c016cadc] do_sys_open+0x4c/0xe0 [ 277.965629] [c016cbac] sys_open+0x1c/0x20 I think that you need the following patch for the scatterlist problem: http://marc.info/?l=linux-scsim=119770154127770w=2 Andrew err, you sent that patch to John a day earlier too. Andrew John, can you please apply, test and report? Happily, this seems to fix the problem with the above crash on 2.6.24-rc5-mm1, I've also left the fix in 2.6.24-rc5 and I'll be testing that in my next reboot. It's looking good! So, this regression is fixed in 2.6.24-rc5-mm1. Next, it would be nice to rate limit the Parity error detected... messages from the Symbios driver, I'll see if I can hack something up in the next day or so. Thanks, John - 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.html
Re: 2.6.24-rc5: tape drive not responding
Just to confirm, the propsed patch to st.c fixes the issue with 2.6.24-rc5 as well at 2.6.24-rc5-mm1 with access to my DLT tape drives. Thanks! John - 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.html
Re: 2.6.24-rc5: tape drive not responding
On Mon, 17 Dec 2007 16:02:02 -0500 John Stoffel [EMAIL PROTECTED] wrote: Just to confirm, the propsed patch to st.c fixes the issue with 2.6.24-rc5 as well at 2.6.24-rc5-mm1 with access to my DLT tape drives. err, what patch to st.c? So it seems that 2.6.24 (and presumably 2.6.23?) need 1: Alan's initio: fix conflict when loading driver (currently stocuk in git-scsi-misc) 2: Boaz's initio: initio_build_scb() fix (my name for it) 3: The mystery st.c fix. yes? - 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.html
Re: 2.6.24-rc5: tape drive not responding
On Mon, 2007-12-17 at 13:43 -0800, Andrew Morton wrote: On Mon, 17 Dec 2007 16:02:02 -0500 John Stoffel [EMAIL PROTECTED] wrote: Just to confirm, the propsed patch to st.c fixes the issue with 2.6.24-rc5 as well at 2.6.24-rc5-mm1 with access to my DLT tape drives. err, what patch to st.c? That's this one: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=acdd0b1c371b2fbb4b6110a51ba69cb0af9e6f45 So it seems that 2.6.24 (and presumably 2.6.23?) need Not 2.6.23 .. the scatterlist changes causing the st problems are local to 2.6.24. 1: Alan's initio: fix conflict when loading driver (currently stocuk in git-scsi-misc) Yes, I'm moving this into scsi-rc-fixes 2: Boaz's initio: initio_build_scb() fix (my name for it) And applying this ... although I'd still appreciate confirmation from someone that the initio driver works after this. 3: The mystery st.c fix. yes? James - 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.html
Re: 2.6.24-rc5: tape drive not responding
http://marc.info/?l=linux-scsim=119770154127770w=2 There is the patch for st.c Andrew Morton schreef: On Mon, 17 Dec 2007 16:02:02 -0500 John Stoffel [EMAIL PROTECTED] wrote: Just to confirm, the propsed patch to st.c fixes the issue with 2.6.24-rc5 as well at 2.6.24-rc5-mm1 with access to my DLT tape drives. err, what patch to st.c? So it seems that 2.6.24 (and presumably 2.6.23?) need 1: Alan's initio: fix conflict when loading driver (currently stocuk in git-scsi-misc) 2: Boaz's initio: initio_build_scb() fix (my name for it) 3: The mystery st.c fix. yes? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - 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.html
Re: [PATCH] drivers/scsi/: Spelling fixes
On Mon, 17 Dec 2007, Joe Perches wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] --- drivers/scsi/NCR53C9x.h |2 +- drivers/scsi/aic7xxx/aic79xx_inline.h |2 +- drivers/scsi/aic7xxx/aic79xx_osm.c|2 +- drivers/scsi/aic7xxx/aic79xx_pci.c|4 ++-- drivers/scsi/aic7xxx/aic7xxx_inline.h |2 +- drivers/scsi/aic7xxx/aic7xxx_osm.c|2 +- drivers/scsi/ipr.c|2 +- drivers/scsi/ips.c|2 +- drivers/scsi/iscsi_tcp.c |4 ++-- drivers/scsi/lpfc/lpfc.h |2 +- drivers/scsi/lpfc/lpfc_mbox.c |2 +- drivers/scsi/megaraid/megaraid_mbox.c | 10 +- drivers/scsi/psi240i.c|2 +- drivers/scsi/qla2xxx/qla_gs.c |2 +- qla2xxx bits: Acked-by: Andrew Vasquez [EMAIL PROTECTED] - 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.html
Re: [PATCH] drivers/scsi/: Spelling fixes
On Mon, 17 Dec 2007, Joe Perches wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] --- drivers/scsi/NCR53C9x.h |2 +- drivers/scsi/aic7xxx/aic79xx_inline.h |2 +- drivers/scsi/aic7xxx/aic79xx_osm.c|2 +- drivers/scsi/aic7xxx/aic79xx_pci.c|4 ++-- drivers/scsi/aic7xxx/aic7xxx_inline.h |2 +- drivers/scsi/aic7xxx/aic7xxx_osm.c|2 +- drivers/scsi/ipr.c|2 +- drivers/scsi/ips.c|2 +- drivers/scsi/iscsi_tcp.c |4 ++-- drivers/scsi/lpfc/lpfc.h |2 +- drivers/scsi/lpfc/lpfc_mbox.c |2 +- drivers/scsi/megaraid/megaraid_mbox.c | 10 +- drivers/scsi/psi240i.c|2 +- drivers/scsi/qla2xxx/qla_gs.c |2 +- For the lpfc bits: Acked-by: James Smart [EMAIL PROTECTED] - 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.html
Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
On Sun, 16 Dec 2007 21:55:20 + Mel Gorman wrote: Just using cp to read the file is enough to cause problems but I included a very basic program below that produces the BUG_ON checks. Is this a known issue or am I using the interface incorrectly? I'd say you're using it correctly but you've found a hitherto unknown bug. On i386 highmem machines with CONFIG_HIGHPTE (at least) pte_offset_map() takes kmap_atomic(), so pagemap_pte_range() can't do copy_to_user() as it presently does. Drat. Still, that shouldn't really disrupt the testing which you're doing. You could disable CONFIG_HIGHPTE to shut it up. Yes, that did the trick. Using pagemap, it was trivial to show that the 2.6.24-rc5-mm1 kernel was placing pages in reverse physical order like the following output shows b: 32763 v: 753091 p:65559 . 65558 contig: 1 b: 32764 v: 753092 p:65558 . 65557 contig: 1 b: 32765 v: 753093 p:65557 . 65556 contig: 1 b: 32766 v: 753094 p:65556 . 6 contig: 1 b: 32767 v: 753095 p:6 . 6 contig: 1 p: is the PFN of the page v: is the page offset within an anonymous mapping and b: is the number of non-contiguous blocks in the anonymous mapping. With the patch applied, it looks more like; b: 1232 v: 752964 p:58944 87328 contig: 15 b: 1233 v: 752980 p:87328 91200 contig: 15 b: 1234 v: 752996 p:91200 40272 contig: 15 b: 1235 v: 753012 p:40272 85664 contig: 15 b: 1236 v: 753028 p:85664 87312 contig: 15 so mappings are using contiguous pages again. This was the final test program I used in case it's of any interest. Thanks /* * showcontiguous.c * * Use the /proc/pid/pagemap interface to give an indication of how contiguous * physical memory is in an anonymous virtual memory mapping */ Matt, Did you ever make your python pagemap scripts available? If not, would you? --- ~Randy - 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.html
Re: [PATCH] drivers/scsi/: Spelling fixes
On Mon, Dec 17, 2007 at 11:40:14AM -0800, Joe Perches wrote: drivers/scsi/scsi_transport_sas.c |2 +- SAS bits are Acked-by: Darrick J. Wong [EMAIL PROTECTED] - 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.html
[no subject]
To whom it may concern, My name is Jason and I am with a company called GC InfoTech, I am working with a server that has the integrated LSI MegaRaid 1068e (M1068e.01.08221427R). I am trying to build a module using the vanilla kernel, from your source drivers, that we will be able to use with Gentoo Linux. I am currently not having any luck, as the compile breaks every time. I have tried the precompiled driver for RHEL with CentOS and was unsuccessful getting it to work as well. #make modules CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CC [M] drivers/message/fusion/mptsas.o drivers/message/fusion/mptsas.c: In function `mptsas_hotplug_work': drivers/message/fusion/mptsas.c:3605: warning: passing arg 1 of `schedule_delayed_work' from incompatible pointer type drivers/message/fusion/mptsas.c:3651: warning: passing arg 1 of `schedule_delayed_work' from incompatible pointer type drivers/message/fusion/mptsas.c: In function `mptsas_broadcast_primative_work': drivers/message/fusion/mptsas.c:4141: error: structure has no member named `work' drivers/message/fusion/mptsas.c:4141: warning: type defaults to `int' in declaration of `__mptr' drivers/message/fusion/mptsas.c:4141: warning: initialization from incompatible pointer type drivers/message/fusion/mptsas.c:4141: error: structure has no member named `work' drivers/message/fusion/mptsas.c: In function `mptsas_reprobe_lun': drivers/message/fusion/mptsas.c:3289: warning: ignoring return value of `scsi_device_reprobe', declared with attribute warn_unused_result make[3]: *** [drivers/message/fusion/mptsas.o] Error 1 make[2]: *** [drivers/message/fusion] Error 2 make[1]: *** [drivers/message] Error 2 make: *** [drivers] Error 2 # I am assuming that the sources I am using are for RHLE or SLES only. Is this assumption correct? Is there any way that I can get this working? I have invested a great deal of money into these servers and it would be great to be able to use them with Gentoo. Do you have any ideas, maybe an unreleased driver? Any help is greatly appreciated and if there is anything else you need to know, please let me know and I will get whatever you need. Thanks, -- Jason Semon GC InfoTech Work: (203) 327-5700 Cell: (203) 964-7356 - 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.html
Small cleanups for scsi_host.h
Small cleanups in scsi_host.h. Few #defines make me wonder if their description is still up to date..? Signed-off-by: Pavel Machek [EMAIL PROTECTED] --- commit f37d85c2619d02ca383962e588417b9eacae366d tree 4f2b2e93717c2f434e91ba32115a3801212e5e3d parent 9918d25acff9540d86ccd93f6e8e536f1cb0a281 author Pavel [EMAIL PROTECTED] Mon, 17 Dec 2007 15:32:49 +0100 committer Pavel [EMAIL PROTECTED] Mon, 17 Dec 2007 15:32:49 +0100 include/scsi/scsi_host.h | 46 ++ 1 files changed, 26 insertions(+), 20 deletions(-) diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h index 0fd4746..69e5a4a 100644 --- a/include/scsi/scsi_host.h +++ b/include/scsi/scsi_host.h @@ -283,39 +283,45 @@ #endif * If the host wants to be called before the scan starts, but * after the midlayer has set up ready for the scan, it can fill * in this function. +* +* Status: OPTIONAL */ void (* scan_start)(struct Scsi_Host *); /* -* fill in this function to allow the queue depth of this host -* to be changeable (on a per device basis). returns either +* Fill in this function to allow the queue depth of this host +* to be changeable (on a per device basis). Returns either * the current queue depth setting (may be different from what * was passed in) or an error. An error should only be * returned if the requested depth is legal but the driver was * unable to set it. If the requested depth is illegal, the * driver should set and return the closest legal queue depth. * +* Status: OPTIONAL */ int (* change_queue_depth)(struct scsi_device *, int); /* -* fill in this function to allow the changing of tag types +* Fill in this function to allow the changing of tag types * (this also allows the enabling/disabling of tag command * queueing). An error should only be returned if something * went wrong in the driver while trying to set the tag type. * If the driver doesn't support the requested tag type, then * it should set the closest type it does support without * returning an error. Returns the actual tag type set. +* +* Status: OPTIONAL */ int (* change_queue_type)(struct scsi_device *, int); /* -* This function determines the bios parameters for a given +* This function determines the BIOS parameters for a given * harddisk. These tend to be numbers that are made up by * the host adapter. Parameters: * size, device, list (heads, sectors, cylinders) * -* Status: OPTIONAL */ +* Status: OPTIONAL +*/ int (* bios_param)(struct scsi_device *, struct block_device *, sector_t, int []); @@ -354,7 +360,7 @@ #endif /* * This determines if we will use a non-interrupt driven -* or an interrupt driven scheme, It is set to the maximum number +* or an interrupt driven scheme. It is set to the maximum number * of simultaneous commands a given host adapter will accept. */ int can_queue; @@ -375,12 +381,12 @@ #endif unsigned short sg_tablesize; /* -* If the host adapter has limitations beside segment count +* Set this if the host adapter has limitations beside segment count. */ unsigned short max_sectors; /* -* dma scatter gather segment boundary limit. a segment crossing this +* DMA scatter gather segment boundary limit. A segment crossing this * boundary will be split in two. */ unsigned long dma_boundary; @@ -389,7 +395,7 @@ #endif * This specifies machine infinity for host templates which don't * limit the transfer size. Note this limit represents an absolute * maximum, and may be over the transfer limits allowed for -* individual devices (e.g. 256 for SCSI-1) +* individual devices (e.g. 256 for SCSI-1). */ #define SCSI_DEFAULT_MAX_SECTORS 1024 @@ -416,12 +422,12 @@ #define SCSI_DEFAULT_MAX_SECTORS 1024 unsigned supported_mode:2; /* -* true if this host adapter uses unchecked DMA onto an ISA bus. +* True if this host adapter uses unchecked DMA onto an ISA bus. */ unsigned unchecked_isa_dma:1; /* -* true if this host adapter can make good use of clustering. +* True if this host adapter can make good use of clustering. * I originally thought that if the tablesize was large that it * was a waste of CPU cycles to prepare a cluster list, but * it works out that the Buslogic is faster if you use a smaller @@ -431,7 +437,7 @@ #define SCSI_DEFAULT_MAX_SECTORS1024
Re: 2.6.24-rc5: tape drive not responding
James == James Bottomley [EMAIL PROTECTED] writes: James On Mon, 2007-12-17 at 13:43 -0800, Andrew Morton wrote: On Mon, 17 Dec 2007 16:02:02 -0500 John Stoffel [EMAIL PROTECTED] wrote: Just to confirm, the propsed patch to st.c fixes the issue with 2.6.24-rc5 as well at 2.6.24-rc5-mm1 with access to my DLT tape drives. err, what patch to st.c? James That's this one: James http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=acdd0b1c371b2fbb4b6110a51ba69cb0af9e6f45 So it seems that 2.6.24 (and presumably 2.6.23?) need James Not 2.6.23 .. the scatterlist changes causing the st problems James are local to 2.6.24. Correct, I ran 2.6.23 for 47+ days of uptime without any problems. I jumped to 2.6.24-rc5-mm1 to do my best to help out with finding problems. Happy to have found one. :] 1: Alan's initio: fix conflict when loading driver (currently stocuk in git-scsi-misc) James Yes, I'm moving this into scsi-rc-fixes I have nothing to do with this issue. 2: Boaz's initio: initio_build_scb() fix (my name for it) James And applying this ... although I'd still appreciate confirmation from James someone that the initio driver works after this. Sorry, I don't have of this hardware at all. 3: The mystery st.c fix. yes? James James Here's the simple one liner patch for the st.c problem: --- orig/drivers/scsi/st.c 2007-12-16 20:08:45.0 -0500 +++ patched/drivers/scsi/st.c 2007-12-17 13:55:30.0 -0500 @@ -3611,6 +3611,7 @@ tb-dma = need_dma; tb-buffer_size = got; + sg_init_table(tb-sg, max_sg); return tb; } Hopefully it's not whitespace damaged. John - 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.html
Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
On Mon, Dec 17, 2007 at 11:24:57AM -0800, Randy Dunlap wrote: On Sun, 16 Dec 2007 21:55:20 + Mel Gorman wrote: Just using cp to read the file is enough to cause problems but I included a very basic program below that produces the BUG_ON checks. Is this a known issue or am I using the interface incorrectly? I'd say you're using it correctly but you've found a hitherto unknown bug. On i386 highmem machines with CONFIG_HIGHPTE (at least) pte_offset_map() takes kmap_atomic(), so pagemap_pte_range() can't do copy_to_user() as it presently does. Drat. Still, that shouldn't really disrupt the testing which you're doing. You could disable CONFIG_HIGHPTE to shut it up. Yes, that did the trick. Using pagemap, it was trivial to show that the 2.6.24-rc5-mm1 kernel was placing pages in reverse physical order like the following output shows b: 32763 v: 753091 p:65559 . 65558 contig: 1 b: 32764 v: 753092 p:65558 . 65557 contig: 1 b: 32765 v: 753093 p:65557 . 65556 contig: 1 b: 32766 v: 753094 p:65556 . 6 contig: 1 b: 32767 v: 753095 p:6 . 6 contig: 1 p: is the PFN of the page v: is the page offset within an anonymous mapping and b: is the number of non-contiguous blocks in the anonymous mapping. With the patch applied, it looks more like; b: 1232 v: 752964 p:58944 87328 contig: 15 b: 1233 v: 752980 p:87328 91200 contig: 15 b: 1234 v: 752996 p:91200 40272 contig: 15 b: 1235 v: 753012 p:40272 85664 contig: 15 b: 1236 v: 753028 p:85664 87312 contig: 15 so mappings are using contiguous pages again. This was the final test program I used in case it's of any interest. Thanks /* * showcontiguous.c * * Use the /proc/pid/pagemap interface to give an indication of how contiguous * physical memory is in an anonymous virtual memory mapping */ Matt, Did you ever make your python pagemap scripts available? If not, would you? There's a collection of them at http://selenic.com/repo/pagemap. They're largely proof of concept, and I'm not sure I finished adapting them all to the final 64-bit interface. As it happens, the above regression I actually spotted immediately by doing a simple hexdump on my very first test of the interface - lots of pfns counting backwards. Mentioned it a few times to various people in the cc: list and on lkml but never got around to tracking it down myself.. -- Mathematics is the supreme nostalgia of our time. - 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.html
Re: [PATCH] MAINTAINERS: remove Adam Fritzler, update his email address in other sources
On Mon, 17 Dec 2007 20:12:06 -0800 Joe Perches [EMAIL PROTECTED] wrote: Adam isn't a maintainer anymore. His old email address bounces. Update to new email address. On Mon, Dec 17, 2007 at 01:03:48PM -0800, Joe Perches wrote: You seem to have an old email address in the linux-kernel MAINTAINERS file. Should it be deleted or changed? On Mon, 2007-12-17 at 19:27 -0800, Adam Fritzler wrote: I am no longer actively involved. If you can mark me as a former point of contact, that's fine, or you can just delete the entry. My name is still in the source, but with the old address. It'd great if the address in source was updated. ... -TMS380 TOKEN-RING NETWORK DRIVER -P: Adam Fritzler -M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -W: http://www.auk.cx/tms380tr/ -S: Maintained ... - * Added MCA support Adam Fritzler [EMAIL PROTECTED] + * Added MCA support Adam Fritzler [EMAIL PROTECTED] This is fairly pointless - it'll just break again when Adam moves again. Every problem can be solved with another layer of... Please: just replace all instances with plain old Adam Fritzler and then ensure that the lookup key Adam Fritzler has an accurate (and non-duplicated anywhere else!) entry in MAINTAINERS or CREDITS or whatever. btw, I cheerfully skipped all your spelling-fixes patches. Some will have stuck via subsystem maintainers but I have a secret no spelling fixes unless they're end-user-visible policy. That means I'll take spelling fixes only if they're in printks or in Documentation/*. This is a little defense mechanism to avoid getting buried in micropatches. I'd suggest that you find out if Adrian is still running the trivial tree and if so, patchbomb him. - 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.html
Re: [PATCH] MAINTAINERS: remove Adam Fritzler, update his email address in other sources
On Mon, 2007-12-17 at 20:28 -0800, Andrew Morton wrote: Please: just replace all instances with plain old Adam Fritzler and then ensure that the lookup key Adam Fritzler has an accurate (and non-duplicated anywhere else!) entry in MAINTAINERS or CREDITS or whatever. Sure. See new patch below btw, I cheerfully skipped all your spelling-fixes patches. No worries. I was just avoiding doing useful stuff. Some will have stuck via subsystem maintainers but I have a secret no spelling fixes unless they're end-user-visible policy. I think there were 15-20 printks in that lot. Do you want them separately? I'd suggest that you find out if Adrian is still running the trivial tree and if so, patchbomb him. OK. Adrian? Do you want the spelling fixes? Back to Adam Fritzler... Signed-off-by: Joe Perches [EMAIL PROTECTED] --- CREDITS |3 +++ MAINTAINERS |7 --- drivers/net/eexpress.c |2 +- drivers/net/tokenring/abyss.c|2 +- drivers/net/tokenring/abyss.h|2 +- drivers/net/tokenring/madgemc.c |2 +- drivers/net/tokenring/madgemc.h |2 +- drivers/net/tokenring/proteon.c |2 +- drivers/net/tokenring/skisa.c|2 +- drivers/net/tokenring/tms380tr.c |2 +- drivers/net/tokenring/tms380tr.h |2 +- drivers/net/tokenring/tmspci.c |2 +- drivers/scsi/aha1542.c |2 +- 13 files changed, 14 insertions(+), 18 deletions(-) diff --git a/CREDITS b/CREDITS index ee909f2..449ec7f 100644 --- a/CREDITS +++ b/CREDITS @@ -1124,6 +1124,9 @@ S: 1150 Ringwood Court S: San Jose, California 95131 S: USA +N: Adam Fritzler +E: [EMAIL PROTECTED] + N: Fernando Fuganti E: [EMAIL PROTECTED] E: [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 9507b42..690f172 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3758,13 +3758,6 @@ W: http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/ T: git kernel.org:/pub/scm/linux/kernel/git/bunk/trivial.git S: Maintained -TMS380 TOKEN-RING NETWORK DRIVER -P: Adam Fritzler -M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -W: http://www.auk.cx/tms380tr/ -S: Maintained - TULIP NETWORK DRIVER L: [EMAIL PROTECTED] W: http://sourceforge.net/projects/tulip/ diff --git a/drivers/net/eexpress.c b/drivers/net/eexpress.c index 70509ed..283fc8f 100644 --- a/drivers/net/eexpress.c +++ b/drivers/net/eexpress.c @@ -9,7 +9,7 @@ * Many modifications, and currently maintained, by * Philip Blundell [EMAIL PROTECTED] * Added the Compaq LTE Alan Cox [EMAIL PROTECTED] - * Added MCA support Adam Fritzler [EMAIL PROTECTED] + * Added MCA support Adam Fritzler * * Note - this driver is experimental still - it has problems on faster * machines. Someone needs to sit down and go through it line by line with diff --git a/drivers/net/tokenring/abyss.c b/drivers/net/tokenring/abyss.c index 124cfd4..7a7de04 100644 --- a/drivers/net/tokenring/abyss.c +++ b/drivers/net/tokenring/abyss.c @@ -10,7 +10,7 @@ * - Madge Smart 16/4 PCI Mk2 * * Maintainer(s): - *AF Adam Fritzler [EMAIL PROTECTED] + *AF Adam Fritzler * * Modification History: * 30-Dec-99 AF Split off from the tms380tr driver. diff --git a/drivers/net/tokenring/abyss.h b/drivers/net/tokenring/abyss.h index 0ee6e4f..b0a473b 100644 --- a/drivers/net/tokenring/abyss.h +++ b/drivers/net/tokenring/abyss.h @@ -2,7 +2,7 @@ * abyss.h: Header for the abyss tms380tr module * * Authors: - * - Adam Fritzler [EMAIL PROTECTED] + * - Adam Fritzler */ #ifndef __LINUX_MADGETR_H diff --git a/drivers/net/tokenring/madgemc.c b/drivers/net/tokenring/madgemc.c index 5a41513..c9c5a2b 100644 --- a/drivers/net/tokenring/madgemc.c +++ b/drivers/net/tokenring/madgemc.c @@ -11,7 +11,7 @@ * - Madge Smart 16/4 Ringnode MC32 (??) * * Maintainer(s): - *AF Adam Fritzler [EMAIL PROTECTED] + *AF Adam Fritzler * * Modification History: * 16-Jan-00 AF Created diff --git a/drivers/net/tokenring/madgemc.h b/drivers/net/tokenring/madgemc.h index 2dd8222..fe88e27 100644 --- a/drivers/net/tokenring/madgemc.h +++ b/drivers/net/tokenring/madgemc.h @@ -2,7 +2,7 @@ * madgemc.h: Header for the madgemc tms380tr module * * Authors: - * - Adam Fritzler [EMAIL PROTECTED] + * - Adam Fritzler */ #ifndef __LINUX_MADGEMC_H diff --git a/drivers/net/tokenring/proteon.c b/drivers/net/tokenring/proteon.c index ca6b659..00ea945 100644 --- a/drivers/net/tokenring/proteon.c +++ b/drivers/net/tokenring/proteon.c @@ -12,7 +12,7 @@ * - Proteon 1392, 1392+ * * Maintainer(s): - *AFAdam Fritzler [EMAIL PROTECTED] + *AFAdam Fritzler *JF Jochen Friedrich[EMAIL PROTECTED] * * Modification History: diff --git a/drivers/net/tokenring/skisa.c b/drivers/net/tokenring/skisa.c index 32e8d5a..41b6999 100644 ---
Re: [PATCH] MAINTAINERS: remove Adam Fritzler, update his email address in other sources
On Mon, Dec 17, 2007 at 08:28:00PM -0800, Andrew Morton wrote: ... I'd suggest that you find out if Adrian is still running the trivial tree and if so, patchbomb him. I do. Simply Cc [EMAIL PROTECTED] for trivial patches and they might magically appear in Linus' tree during the next merge window. :) cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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.html
Re: [rfc][patch 1/3] block: non-atomic queue_flags prep
On Sat, Dec 15 2007, Nick Piggin wrote: Hi, This is just an idea I had, which might make request processing a little bit cheaper depending on queue behaviour. For example if it is getting plugged unplugged frequently (as I think is the case for some database workloads), then we might save one or two atomic operations per request. Anyway, I'm not completely sure if I have ensured all queue_flags users are safe (I think md may need a bit of help). But overall it seems quite doable. Looks ok to me, I'll throw it into the testing mix. Thanks Nick! -- Jens Axboe - 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.html
