[2.6 patch] drivers/scsi/dpt*: remove version.h dependencies
On Sat, Apr 02, 2005 at 07:49:38AM -0600, James Bottomley wrote:
> On Sun, 2005-03-27 at 16:34 +0200, Adrian Bunk wrote:
> > This patch removes #if's for kernel 2.2 .
>
> this one looks like it's not quite complete:
>
> > -#ifndef LINUX_VERSION_CODE
> > #include
> > -#endif
>
> Once there are no more KERNEL_VERSION dependencies in a file, it's
> inclusion of linux/version.h can be removed also (and that should
> prevent it getting rebuilt every time the kernel version changes).
>
> So it looks like there's an additional KERNEL_VERSION to remove in
> dpt/dpti_i2o.h version.h includes in dpti_i2o.h and dpt_i2o.c
Is the patch below what you want, or do I misunderstand your comment?
> Then when you have a final patch, could you cc Markus Lidel
> <[EMAIL PROTECTED]> and
>
> [EMAIL PROTECTED]
>
> Thanks,
>
> James
cu
Adrian
<-- snip -->
This patch removes version.h dependencies.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
drivers/scsi/dpt/sys_info.h |4
drivers/scsi/dpt_i2o.c |5 -
drivers/scsi/dpti.h | 12
3 files changed, 21 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpti.h.old 2005-04-15
01:21:04.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpti.h 2005-04-15
01:21:26.0 +0200
@@ -20,15 +20,7 @@
#ifndef _DPT_H
#define _DPT_H
-#ifndef LINUX_VERSION_CODE
-#include
-#endif
-
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,00)
-#define MAX_TO_IOP_MESSAGES (210)
-#else
#define MAX_TO_IOP_MESSAGES (255)
-#endif
#define MAX_FROM_IOP_MESSAGES (255)
@@ -321,10 +313,6 @@
static void adpt_delay(int millisec);
#endif
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-static struct pci_dev* adpt_pci_find_device(uint vendor, struct pci_dev* from);
-#endif
-
#if defined __ia64__
static void adpt_ia64_info(sysInfo_S* si);
#endif
--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt/sys_info.h.old 2005-04-15
01:23:52.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt/sys_info.h 2005-04-15
01:24:13.0 +0200
@@ -146,10 +146,6 @@
uSHORT flags; /* See bit definitions above */
uSHORT conventionalMemSize;/* in KB */
uLONGextendedMemSize;/* in KB */
- uLONGosType; /* Same as DPTSIG's definition */
- uCHARosMajorVersion;
- uCHARosMinorVersion; /* The OS version */
- uCHARosRevision;
#ifdef _SINIX_ADDON
uCHARbusType;/* See defininitions above */
uSHORT osSubRevision;
--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt_i2o.c.old2005-04-15
01:21:48.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt_i2o.c2005-04-15
01:25:20.0 +0200
@@ -34,7 +34,6 @@
#define ADDR32 (0)
-#include
#include
MODULE_AUTHOR("Deanna Bonds, with _lots_ of help from Mark Salyzyn");
@@ -1824,10 +1823,6 @@
memset(&si, 0, sizeof(si));
- si.osType = OS_LINUX;
- si.osMajorVersion = (u8) (LINUX_VERSION_CODE >> 16);
- si.osMinorVersion = (u8) (LINUX_VERSION_CODE >> 8 & 0x0ff);
- si.osRevision = (u8) (LINUX_VERSION_CODE & 0x0ff);
si.busType = SI_PCI_BUS;
si.processorFamily = DPTI_sig.dsProcessorFamily;
-
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: Question about scsi_device_online() usage in mptscsih
Masao Fukuchi reported an issue when the outstanding mf queue was being flushed in contents of slave_destroy, the scsi dev was offlined already by the mid-layer. They may not be an issue anymore since I removed the error handling timers from mptscsih. Masao can you validate this pls? Christoph Hellwig, wrote: > > On Sat, Apr 02, 2005 at 02:35:57PM +0900, Tejun Heo wrote: > > Hello, Eric. > > Hello, James. > > > > I've been working on new SCSI state model and was checking on > > scsi_device_online() users. As the state model is going to > change, I > > need to audit device state usages in lldd's and I'm having difficult > > time understanding why scsi_device_online() is used in mptscsih. > > > > In mptscsih.c, mptscsih_flush_running_cmds() uses > > scsi_device_online() to determine whether or not dma-unmap data area > > of active commands. This was added in the changeset 1.1371.776.1 by > > Eric Moore with the comment "MPT Fusion add back FC909 > support". Can > > you please explain me why and how scsi_device_online() condition is > > used here? > > I brought that issue up a while ago, but we didn't really get > anywhere, > see the "fix dma mapping leak in fusion" thread on linux-scsi. > - 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 2.6.11-rc2] Linux SCSI hotplug infrastructure
On Thu, Apr 14, 2005 at 01:24:33PM -0500, Matt Domsch wrote: > I posted this back in February, with no response (good or bad). > I still think this is useful, and would appreciate feedback. I don't like this at all. It's adding a kernel roundtrip for things that should be handled in userland. - 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: Question about scsi_device_online() usage in mptscsih
On Sat, Apr 02, 2005 at 02:35:57PM +0900, Tejun Heo wrote: > Hello, Eric. > Hello, James. > > I've been working on new SCSI state model and was checking on > scsi_device_online() users. As the state model is going to change, I > need to audit device state usages in lldd's and I'm having difficult > time understanding why scsi_device_online() is used in mptscsih. > > In mptscsih.c, mptscsih_flush_running_cmds() uses > scsi_device_online() to determine whether or not dma-unmap data area > of active commands. This was added in the changeset 1.1371.776.1 by > Eric Moore with the comment "MPT Fusion add back FC909 support". Can > you please explain me why and how scsi_device_online() condition is > used here? I brought that issue up a while ago, but we didn't really get anywhere, see the "fix dma mapping leak in fusion" thread on linux-scsi. - 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: Fw: [SCSI] Driver broken in 2.6.x?
> I've recently switched form 2.4.x kernel series to 2.6.x, and I've > encourted a problem with my old scanner card, lspci shows it as: > > > 00:0c.0 SCSI storage controller: DTC Technology Corp. Domex 536 > Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium > >TAbort- SERR- Interrupt: pin A routed to IRQ 11 > Region 0: I/O ports at d800 [size=32] > > > It worked flawlessly under 2.4 kernels, but now it hangs xsane, and logs > show this: Unfortunately this driver is known broken under 2.6. I tried to debug it with Mark Morschha\"user who has such a card aswell, but we didn't manage to find out what's wrong. - 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
[RFC][PATCH 2.6.11-rc2] Linux SCSI hotplug infrastructure
I posted this back in February, with no response (good or bad).
I still think this is useful, and would appreciate feedback.
Thanks,
Matt
Date: Mon, 7 Feb 2005 12:27:53 -0600
From: Matt Domsch <[EMAIL PROTECTED]>
To: linux-scsi@vger.kernel.org, [EMAIL PROTECTED]
Subject: [RFC][PATCH 2.6.11-rc2] Linux SCSI hotplug infrastructure
Below is a patch to add some hotplug infrastructure to the Linux SCSI
subsystem.
New files:
include/scsi/scsi_hotplug.h
drivers/scsi/scsi_hotplug.c
implements a new exported function:
extern int scsi_topology_hctl_action(struct Scsi_Host *shost, unsigned int
channel,
unsigned int id, unsigned int lun, enum
scsi_topology_action action);
which invokes kobject_hotplug() on a temporary "scsi_topology"
device. This device represents a target that exists on a topology
(i.e. was just inserted into a hot plug enclosure, or was just created
by a RAID controller management application) but is not yet hooked
into the kernel.
Modified files:
drivers/scsi/Kconfig
drivers/scsi/Makefile
drivers/scsi/megaraid/megaraid_mbox.c
(will follow in a separate patch)
is the user of this new function.
In addition, two more infrastructure pieces are necessary:
udev-050-scsi_topology.patch - adds the subsystem name "scsi_topology"
to the list of devices *not* to wait for the creation of files in
sysfs for - scsi_topology devices aren't to be registered in sysfs.
/etc/hotplug/scsi_topology.agent
handles the hotplug call, and invokes /sys/class/scsi_host/hostX/scan
and /sys/class/scsi_device/H:C:T:L:/device/delete as appropriate.
The flow is as follows:
# echo "2" > /sys/class/scsi_host/host2/logical_drive_created
(to be done by a management application that knows it just created
logical drive #2 on the controller)
megaraid_mbox.c sysfs method converts logical drive number to HCTL
value, calls scsi_topology_hctl_action().
scsi_topology_hctl_action() invokes kobject_hotplug() with a
scsi_topology subsystem device.
kobject_hotplug() calls /sbin/hotplug or /sbin/udevsend (more likely
the latter), which invokes /etc/hotplug/scsi_topology.agent with the
ACTION={add,remove}.
scsi_topology.agent invokes /sys/class/scsi_host/hostX/scan or
/sys/class/scsi_device/H:C:T:L:/device/delete as appropriate.
>From this point, we're back into known territory, with the device
being made known, or deleted from, the kernel's view.
Thoughts?
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= drivers/scsi/Kconfig 1.95 vs edited =
--- 1.95/drivers/scsi/Kconfig 2005-01-28 11:14:29 -06:00
+++ edited/drivers/scsi/Kconfig 2005-02-05 13:58:45 -06:00
@@ -185,6 +185,16 @@
there should be no noticeable performance impact as long as you have
logging turned off.
+config SCSI_HOTPLUG
+ bool "Hot Plug SCSI devices"
+ depends on SCSI && EXPERIMENTAL
+ default y
+ help
+ If your driver or management applications know about
+ device hot plugging (insertion/removal of physical disks in
+ a topology, or creation/deletion of logical disks on a RAID
+ controller), say Y here. Otherwise, say N.
+
menu "SCSI Transport Attributes"
depends on SCSI
= drivers/scsi/Makefile 1.72 vs edited =
--- 1.72/drivers/scsi/Makefile 2004-11-20 14:26:17 -06:00
+++ edited/drivers/scsi/Makefile2005-02-05 13:58:15 -06:00
@@ -147,6 +147,7 @@
scsi_devinfo.o
scsi_mod-$(CONFIG_SYSCTL) += scsi_sysctl.o
scsi_mod-$(CONFIG_SCSI_PROC_FS)+= scsi_proc.o
+scsi_mod-$(CONFIG_SCSI_HOTPLUG)+= scsi_hotplug.o
sd_mod-objs:= sd.o
sr_mod-objs:= sr.o sr_ioctl.o sr_vendor.o
--- /dev/null Thu Apr 11 09:25:15 2002
+++ include/scsi/scsi_hotplug.h Sun Feb 6 23:29:51 2005
@@ -0,0 +1,41 @@
+/*
+ * SCSI Hotplug
+ *
+ * Copyright (c) 2005 Dell, Inc <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef _SCSI_SCSI_HOTPLUG_H
+#define _SCSI_SCSI_HOTPLUG_H
+
+#include
+#include
+#include
+
+enum scsi_topology_action {
+ SCSI_TOPOLOGY_ADDED= 1, /* device added in the topology */
+ SCSI_TOPOLOGY_REM
Re: Heads up on 2.6.12-rc1 and later
Tom Duffy wrote: On Thu, 2005-04-14 at 12:29 -0400, [EMAIL PROTECTED] wrote: In testing with 2.6.12-rc1 and -rc2, we've been encountering an issue on SMP machines with the loading of scsi_mod and sd_mod modules. The sd_mod load fails with unresolved symbols. It appears to be a race condition based on how quickly the modules load. This works fine on uni systems and on 2.6.11. Evidently, this problem has been before and is resolved by a short delay between module loads. http://seclists.org/lists/linux-kernel/2005/Apr/0383.html BTW. I haven't had time to debug this any further myself, but for me adding a one second delay between module loads DOES NOT WORK for me. Given it's been around for 2 -rc itterations, I expect it needed some highlighting. Ah, so it is not just me (thought I was going crazy -- couldn't get a kernel to boot on my SMP system): Mounting sysfs Creating /dev Starting udev Loading scsi_modSCSI subsystem initialized .ko module LoadFusion MPT base driver 3.01.20 ing sd_mod.ko momptscsih: Unknown symbol mpt_deregister mptscsih: Unknown symbol mpt_reset_deregister mptscsih: Unknown symbol mpt_config mptscsih: Unknown symbol mpt_device_driver_deregister mptscsih: Unknown symbol mpt_free_msg_frame mptscsih: Unknown symbol scsi_remove_host mptscsih: Unknown symbol mpt_print_ioc_summary mptscsih: Unknown symbol mpt_GetIocState mptscsih: Unknown symbol mpt_put_msg_frame mptscsih: Unknown symbol mpt_register mptscsih: Unknown symbol mpt_add_sge mptscsih: Unknown symbol mpt_event_deregister mptscsih: Unknown symbol scsi_host_put mptscsih: Unknown symbol mpt_read_ioc_pg_3 mptscsih: Unknown symbol scsi_scan_host mptscsih: Unknown symbol mpt_event_register mptscsih: Unknown symbol mpt_send_handshake_request mptscsih: Unknown symbol scsi_add_host mptscsih: Unknown symbol mpt_device_driver_register mptscsih: Unknown symbol scsi_adjust_queue_depth mptscsih: Unknown symbol mpt_get_msg_frame mptscsih: Unknown symbol mpt_reset_register mptscsih: Unknown symbol mpt_HardResetHandler mptscsih: Unknown symbol scsi_host_alloc mptscsih: Unknown symbol ioc_list dule Loading mpinput: ImPS/2 Generic Wheel Mouse on isa0060/serio1 sd_mod: Unknown symbol scsi_device_get sd_mod: Unknown symbol scsi_wait_req sd_mod: Unknown symbol scsi_get_sense_info_fld sd_mod: Unknown symbol scsicam_bios_param sd_mod: Unknown symbol scsi_command_normalize_sense sd_mod: Unknown symbol scsi_test_unit_ready sd_mod: Unknown symbol scsi_block_when_processing_errors sd_mod: Unknown symbol scsi_register_driver sd_mod: Unknown symbol scsi_ioctl sd_mod: Unknown symbol scsi_nonblockable_ioctl sd_mod: Unknown symbol scsi_device_put sd_mod: Unknown symbol scsi_request_normalize_sense sd_mod: Unknown symbol __scsi_mode_sense sd_mod: Unknown symbol scsi_logging_level sd_mod: Unknown symbol scsi_print_req_sense sd_mod: Unknown symbol scsi_release_request sd_mod: Unknown symbol scsi_print_sense sd_mod: Unknown symbol scsi_allocate_request sd_mod: Unknown symbol scsi_io_completion sd_mod: Unknown symbol scsi_set_medium_removal Loading mptscsiCopyright (c) 1999-2004 LSI Logic Corporation h.ko module LoaACPI: PCI Interrupt :05:05.0[A] -> ding dm-mod.ko mGSI 72 (level, low) -> IRQ 185 odule Loading jmptbase: Initiating ioc0 bringup bd.ko module Lodevice-mapper: 4.4.0-ioctl (2005-01-12) initialised: [EMAIL PROTECTED] ading ext3.ko moext3: Unknown symbol journal_force_commit dule insmod: erext3: Unknown symbol journal_dirty_data ror inserting '/tK3e:r Unenkl npowann iscy -m bonlo t jsouynrncailn_gf: oArctete_mcopmtemdit t_no eskitledl iniext!t3 Unknown symbol journal_init_dev -- kr - 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: Heads up on 2.6.12-rc1 and later
On Thu, 2005-04-14 at 12:29 -0400, [EMAIL PROTECTED] wrote: > In testing with 2.6.12-rc1 and -rc2, we've been encountering an issue > on SMP machines with the loading of scsi_mod and sd_mod modules. The > sd_mod load fails with unresolved symbols. It appears to be a race > condition based on how quickly the modules load. This works fine on > uni systems and on 2.6.11. > > Evidently, this problem has been before and is resolved by a short > delay between module loads. > http://seclists.org/lists/linux-kernel/2005/Apr/0383.html > > Given it's been around for 2 -rc itterations, I expect it needed some > highlighting. Ah, so it is not just me (thought I was going crazy -- couldn't get a kernel to boot on my SMP system): Mounting sysfs Creating /dev Starting udev Loading scsi_modSCSI subsystem initialized .ko module LoadFusion MPT base driver 3.01.20 ing sd_mod.ko momptscsih: Unknown symbol mpt_deregister mptscsih: Unknown symbol mpt_reset_deregister mptscsih: Unknown symbol mpt_config mptscsih: Unknown symbol mpt_device_driver_deregister mptscsih: Unknown symbol mpt_free_msg_frame mptscsih: Unknown symbol scsi_remove_host mptscsih: Unknown symbol mpt_print_ioc_summary mptscsih: Unknown symbol mpt_GetIocState mptscsih: Unknown symbol mpt_put_msg_frame mptscsih: Unknown symbol mpt_register mptscsih: Unknown symbol mpt_add_sge mptscsih: Unknown symbol mpt_event_deregister mptscsih: Unknown symbol scsi_host_put mptscsih: Unknown symbol mpt_read_ioc_pg_3 mptscsih: Unknown symbol scsi_scan_host mptscsih: Unknown symbol mpt_event_register mptscsih: Unknown symbol mpt_send_handshake_request mptscsih: Unknown symbol scsi_add_host mptscsih: Unknown symbol mpt_device_driver_register mptscsih: Unknown symbol scsi_adjust_queue_depth mptscsih: Unknown symbol mpt_get_msg_frame mptscsih: Unknown symbol mpt_reset_register mptscsih: Unknown symbol mpt_HardResetHandler mptscsih: Unknown symbol scsi_host_alloc mptscsih: Unknown symbol ioc_list dule Loading mpinput: ImPS/2 Generic Wheel Mouse on isa0060/serio1 sd_mod: Unknown symbol scsi_device_get sd_mod: Unknown symbol scsi_wait_req sd_mod: Unknown symbol scsi_get_sense_info_fld sd_mod: Unknown symbol scsicam_bios_param sd_mod: Unknown symbol scsi_command_normalize_sense sd_mod: Unknown symbol scsi_test_unit_ready sd_mod: Unknown symbol scsi_block_when_processing_errors sd_mod: Unknown symbol scsi_register_driver sd_mod: Unknown symbol scsi_ioctl sd_mod: Unknown symbol scsi_nonblockable_ioctl sd_mod: Unknown symbol scsi_device_put sd_mod: Unknown symbol scsi_request_normalize_sense sd_mod: Unknown symbol __scsi_mode_sense sd_mod: Unknown symbol scsi_logging_level sd_mod: Unknown symbol scsi_print_req_sense sd_mod: Unknown symbol scsi_release_request sd_mod: Unknown symbol scsi_print_sense sd_mod: Unknown symbol scsi_allocate_request sd_mod: Unknown symbol scsi_io_completion sd_mod: Unknown symbol scsi_set_medium_removal Loading mptscsiCopyright (c) 1999-2004 LSI Logic Corporation h.ko module LoaACPI: PCI Interrupt :05:05.0[A] -> ding dm-mod.ko mGSI 72 (level, low) -> IRQ 185 odule Loading jmptbase: Initiating ioc0 bringup bd.ko module Lodevice-mapper: 4.4.0-ioctl (2005-01-12) initialised: [EMAIL PROTECTED] ading ext3.ko moext3: Unknown symbol journal_force_commit dule insmod: erext3: Unknown symbol journal_dirty_data ror inserting '/tK3e:r Unenkl npowann iscy -m bonlo t jsouynrncailn_gf: oArctete_mcopmtemdit t_no eskitledl iniext!t3 Unknown symbol journal_init_dev signature.asc Description: This is a digitally signed message part
Re: [linux-iscsi-devel] [ANNOUNCE] open-iscsi and linux-iscsi project teams have merged!
On Thu, 2005-04-14 at 18:19 +0200, Christoph Hellwig wrote: > On Thu, Apr 14, 2005 at 09:18:32AM -0700, Dmitry Yusupov wrote: > > Consider linux-iscsi-5.x CVS branch as a "mainline". Current open-iscsi > > SVN repository is the place where all hard-core development will happen > > at least for the nearest future. > > > > I really hope sf.net will provide SVN hosting very soon. than we will > > see how it goes. and may be we might just migrate current berlios.de > > hosting to the sf.net. > > sf.net hosting is total crap for all services. I'd really prefer to see > things hosted somewhere sane.. FWIW, Sourceforge sent out an email just the other day announcing that they've replaced the CVS servers, and promising that these issues will go away. We'll see how that works out... Lee - 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: [Announce] Emulex lpfcdriver v8.0.28 available
> We have been working with Christoph over the last few weeks to address > some last comments, and believe that this release is ready for > inclusion with the upstream kernel. A first look at it looks nice indeed. Care to submit it in patch form? - 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
Heads up on 2.6.12-rc1 and later
Folks, FYI: In testing with 2.6.12-rc1 and -rc2, we've been encountering an issue on SMP machines with the loading of scsi_mod and sd_mod modules. The sd_mod load fails with unresolved symbols. It appears to be a race condition based on how quickly the modules load. This works fine on uni systems and on 2.6.11. Evidently, this problem has been before and is resolved by a short delay between module loads. http://seclists.org/lists/linux-kernel/2005/Apr/0383.html Given it's been around for 2 -rc itterations, I expect it needed some highlighting. -- james s - 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: [linux-iscsi-devel] [ANNOUNCE] open-iscsi and linux-iscsi project teams have merged!
On Thu, Apr 14, 2005 at 09:18:32AM -0700, Dmitry Yusupov wrote: > Consider linux-iscsi-5.x CVS branch as a "mainline". Current open-iscsi > SVN repository is the place where all hard-core development will happen > at least for the nearest future. > > I really hope sf.net will provide SVN hosting very soon. than we will > see how it goes. and may be we might just migrate current berlios.de > hosting to the sf.net. sf.net hosting is total crap for all services. I'd really prefer to see things hosted somewhere sane.. - 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: [linux-iscsi-devel] [ANNOUNCE] open-iscsi and linux-iscsi project teams have merged!
On Thu, 2005-04-14 at 13:16 +0200, Christoph Hellwig wrote: > On Mon, Apr 11, 2005 at 10:30:58PM -0400, linux-iscsi development team wrote: > > The linux-iscsi and open-iscsi developers would like to announce > > that they have combined forces on a single iSCSI initiator effort! > > What SCM will the code be in? I must admit I really, really prefer the > SVN hosting of open-iscsi over the sf.net CVS mess. Consider linux-iscsi-5.x CVS branch as a "mainline". Current open-iscsi SVN repository is the place where all hard-core development will happen at least for the nearest future. I really hope sf.net will provide SVN hosting very soon. than we will see how it goes. and may be we might just migrate current berlios.de hosting to the sf.net. - 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
[Announce] Emulex lpfcdriver v8.0.28 available
All, I'd like to announce the availability of the Emulex lpfc driver revision 8.0.28 on SourceForge: http://prdownloads.sourceforge.net/lpfc/lpfcdriver-2.6-8.0.28.tar.gz?download We are extremely pleased that the FC Remote Port support is now part of the kernel for 2.6.12 (as of -rc1). We now have sufficient kernel support for the integration of our driver. We have been working with Christoph over the last few weeks to address some last comments, and believe that this release is ready for inclusion with the upstream kernel. Thank You. -- James S - 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] remove old scsi data direction macros
On Thu, Apr 14, 2005 at 12:56:39PM +0200, Christoph Hellwig wrote:
> these have been wrappers for the generic dma direction bits since 2.5.x.
> This patch converts the few remaining drivers and removes the macros.
Arjan noticed there's some hunk in here that shouldn't. Updated patch
below:
--- 1.24/Documentation/DMA-mapping.txt 2004-07-30 04:35:43 +02:00
+++ edited/Documentation/DMA-mapping.txt2005-04-12 23:52:31 +02:00
@@ -443,15 +443,9 @@
implicitly have a direction attribute setting of
PCI_DMA_BIDIRECTIONAL.
-The SCSI subsystem provides mechanisms for you to easily obtain
-the direction to use, in the SCSI command:
-
- scsi_to_pci_dma_dir(SCSI_DIRECTION)
-
-Where SCSI_DIRECTION is obtained from the 'sc_data_direction'
-member of the SCSI command your driver is working on. The
-mentioned interface above returns a value suitable for passing
-into the streaming DMA mapping interfaces below.
+The SCSI subsystem tells you the direction to use in the
+'sc_data_direction' member of the SCSI command your driver is
+working on.
For Networking drivers, it's a rather simple affair. For transmit
packets, map/unmap them with the PCI_DMA_TODEVICE direction
= Documentation/scsi/scsi_mid_low_api.txt 1.23 vs edited =
--- 1.23/Documentation/scsi/scsi_mid_low_api.txt2004-11-20 21:25:56
+01:00
+++ edited/Documentation/scsi/scsi_mid_low_api.txt 2005-04-12 23:52:31
+02:00
@@ -389,8 +389,6 @@
scsi_remove_host - detach and remove all SCSI devices owned by host
scsi_report_bus_reset - report scsi _bus_ reset observed
scsi_set_device - place device reference in host structure
- scsi_to_pci_dma_dir - convert SCSI subsystem direction flag to PCI
- scsi_to_sbus_dma_dir - convert SCSI subsystem direction flag to SBUS
scsi_track_queue_full - track successive QUEUE_FULL events
scsi_unblock_requests - allow further commands to be queued to given host
scsi_unregister - [calls scsi_host_put()]
@@ -754,48 +752,6 @@
* Defined in: include/scsi/scsi_host.h .
**/
void scsi_set_device(struct Scsi_Host * shost, struct device * dev)
-
-
-/**
- * scsi_to_pci_dma_dir - convert SCSI subsystem direction flag to PCI
- * @scsi_data_direction: SCSI subsystem direction flag
- *
- * Returns DMA_TO_DEVICE given SCSI_DATA_WRITE,
- * DMA_FROM_DEVICE given SCSI_DATA_READ
- * DMA_BIDIRECTIONAL given SCSI_DATA_UNKNOWN
- * else returns DMA_NONE
- *
- * Might block: no
- *
- * Notes: The SCSI subsystem now uses the same values for these
- * constants as the PCI subsystem so this function is a nop.
- * The recommendation is not to use this conversion function anymore
- * (in the 2.6 kernel series) as it is not needed.
- *
- * Defined in: drivers/scsi/scsi.h .
- **/
-int scsi_to_pci_dma_dir(unsigned char scsi_data_direction)
-
-
-/**
- * scsi_to_sbus_dma_dir - convert SCSI subsystem direction flag to SBUS
- * @scsi_data_direction: SCSI subsystem direction flag
- *
- * Returns DMA_TO_DEVICE given SCSI_DATA_WRITE,
- * FROM_DEVICE given SCSI_DATA_READ
- * DMA_BIDIRECTIONAL given SCSI_DATA_UNKNOWN
- * else returns DMA_NONE
- *
- * Notes: The SCSI subsystem now uses the same values for these
- * constants as the SBUS subsystem so this function is a nop.
- * The recommendation is not to use this conversion function anymore
- * (in the 2.6 kernel series) as it is not needed.
- *
- * Might block: no
- *
- * Defined in: drivers/scsi/scsi.h .
- **/
-int scsi_to_sbus_dma_dir(unsigned char scsi_data_direction)
/**
--- 1.64/drivers/scsi/aic7xxx_old.c 2005-01-25 22:50:18 +01:00
+++ edited/drivers/scsi/aic7xxx_old.c 2005-04-12 23:52:31 +02:00
@@ -2700,12 +2700,12 @@
struct scatterlist *sg;
sg = (struct scatterlist *)cmd->request_buffer;
-pci_unmap_sg(p->pdev, sg, cmd->use_sg,
scsi_to_pci_dma_dir(cmd->sc_data_direction));
+pci_unmap_sg(p->pdev, sg, cmd->use_sg, cmd->sc_data_direction);
}
else if (cmd->request_bufflen)
pci_unmap_single(p->pdev, aic7xxx_mapping(cmd),
cmd->request_bufflen,
- scsi_to_pci_dma_dir(cmd->sc_data_direction));
+ cmd->sc_data_direction);
if (scb->flags & SCB_SENSE)
{
pci_unmap_single(p->pdev,
@@ -10228,7 +10228,7 @@
sg = (struct scatterlist *)cmd->request_buffer;
scb->sg_length = 0;
-use_sg = pci_map_sg(p->pdev, sg, cmd->use_sg,
scsi_to_pci_dma_dir(cmd->sc_data_direction));
+use_sg = pci_map_sg(p->pdev, sg, cmd->use_sg, cmd->sc_data_direction);
/*
* Copy the segments into the SG array. NOTE!!! - We used to
* have the first entry both in the data_pointer area and the first
@@ -10256,7 +10256,7 @@
{
unsigned int address = pci_map_single(p->pdev, cmd->request_buffer,
cmd->request_bufflen,
-
Re: [linux-iscsi-devel] [ANNOUNCE] open-iscsi and linux-iscsi project teams have merged!
On Mon, Apr 11, 2005 at 10:30:58PM -0400, linux-iscsi development team wrote: > The linux-iscsi and open-iscsi developers would like to announce > that they have combined forces on a single iSCSI initiator effort! What SCM will the code be in? I must admit I really, really prefer the SVN hosting of open-iscsi over the sf.net CVS mess. - 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] remove old scsi data direction macros
these have been wrappers for the generic dma direction bits since 2.5.x.
This patch converts the few remaining drivers and removes the macros.
--- 1.24/Documentation/DMA-mapping.txt 2004-07-30 04:35:43 +02:00
+++ edited/Documentation/DMA-mapping.txt2005-04-12 23:52:31 +02:00
@@ -443,15 +443,9 @@
implicitly have a direction attribute setting of
PCI_DMA_BIDIRECTIONAL.
-The SCSI subsystem provides mechanisms for you to easily obtain
-the direction to use, in the SCSI command:
-
- scsi_to_pci_dma_dir(SCSI_DIRECTION)
-
-Where SCSI_DIRECTION is obtained from the 'sc_data_direction'
-member of the SCSI command your driver is working on. The
-mentioned interface above returns a value suitable for passing
-into the streaming DMA mapping interfaces below.
+The SCSI subsystem tells you the direction to use in the
+'sc_data_direction' member of the SCSI command your driver is
+working on.
For Networking drivers, it's a rather simple affair. For transmit
packets, map/unmap them with the PCI_DMA_TODEVICE direction
= Documentation/scsi/scsi_mid_low_api.txt 1.23 vs edited =
--- 1.23/Documentation/scsi/scsi_mid_low_api.txt2004-11-20 21:25:56
+01:00
+++ edited/Documentation/scsi/scsi_mid_low_api.txt 2005-04-12 23:52:31
+02:00
@@ -389,8 +389,6 @@
scsi_remove_host - detach and remove all SCSI devices owned by host
scsi_report_bus_reset - report scsi _bus_ reset observed
scsi_set_device - place device reference in host structure
- scsi_to_pci_dma_dir - convert SCSI subsystem direction flag to PCI
- scsi_to_sbus_dma_dir - convert SCSI subsystem direction flag to SBUS
scsi_track_queue_full - track successive QUEUE_FULL events
scsi_unblock_requests - allow further commands to be queued to given host
scsi_unregister - [calls scsi_host_put()]
@@ -754,48 +752,6 @@
* Defined in: include/scsi/scsi_host.h .
**/
void scsi_set_device(struct Scsi_Host * shost, struct device * dev)
-
-
-/**
- * scsi_to_pci_dma_dir - convert SCSI subsystem direction flag to PCI
- * @scsi_data_direction: SCSI subsystem direction flag
- *
- * Returns DMA_TO_DEVICE given SCSI_DATA_WRITE,
- * DMA_FROM_DEVICE given SCSI_DATA_READ
- * DMA_BIDIRECTIONAL given SCSI_DATA_UNKNOWN
- * else returns DMA_NONE
- *
- * Might block: no
- *
- * Notes: The SCSI subsystem now uses the same values for these
- * constants as the PCI subsystem so this function is a nop.
- * The recommendation is not to use this conversion function anymore
- * (in the 2.6 kernel series) as it is not needed.
- *
- * Defined in: drivers/scsi/scsi.h .
- **/
-int scsi_to_pci_dma_dir(unsigned char scsi_data_direction)
-
-
-/**
- * scsi_to_sbus_dma_dir - convert SCSI subsystem direction flag to SBUS
- * @scsi_data_direction: SCSI subsystem direction flag
- *
- * Returns DMA_TO_DEVICE given SCSI_DATA_WRITE,
- * FROM_DEVICE given SCSI_DATA_READ
- * DMA_BIDIRECTIONAL given SCSI_DATA_UNKNOWN
- * else returns DMA_NONE
- *
- * Notes: The SCSI subsystem now uses the same values for these
- * constants as the SBUS subsystem so this function is a nop.
- * The recommendation is not to use this conversion function anymore
- * (in the 2.6 kernel series) as it is not needed.
- *
- * Might block: no
- *
- * Defined in: drivers/scsi/scsi.h .
- **/
-int scsi_to_sbus_dma_dir(unsigned char scsi_data_direction)
/**
--- 1.64/drivers/scsi/aic7xxx_old.c 2005-01-25 22:50:18 +01:00
+++ edited/drivers/scsi/aic7xxx_old.c 2005-04-12 23:52:31 +02:00
@@ -2700,12 +2700,12 @@
struct scatterlist *sg;
sg = (struct scatterlist *)cmd->request_buffer;
-pci_unmap_sg(p->pdev, sg, cmd->use_sg,
scsi_to_pci_dma_dir(cmd->sc_data_direction));
+pci_unmap_sg(p->pdev, sg, cmd->use_sg, cmd->sc_data_direction);
}
else if (cmd->request_bufflen)
pci_unmap_single(p->pdev, aic7xxx_mapping(cmd),
cmd->request_bufflen,
- scsi_to_pci_dma_dir(cmd->sc_data_direction));
+ cmd->sc_data_direction);
if (scb->flags & SCB_SENSE)
{
pci_unmap_single(p->pdev,
@@ -10228,7 +10228,7 @@
sg = (struct scatterlist *)cmd->request_buffer;
scb->sg_length = 0;
-use_sg = pci_map_sg(p->pdev, sg, cmd->use_sg,
scsi_to_pci_dma_dir(cmd->sc_data_direction));
+use_sg = pci_map_sg(p->pdev, sg, cmd->use_sg, cmd->sc_data_direction);
/*
* Copy the segments into the SG array. NOTE!!! - We used to
* have the first entry both in the data_pointer area and the first
@@ -10256,7 +10256,7 @@
{
unsigned int address = pci_map_single(p->pdev, cmd->request_buffer,
cmd->request_bufflen,
-
scsi_to_pci_dma_dir(cmd->sc_data_direction));
+cmd->sc_data_direction);
aic7xxx_map
