Re: [PATCH] minimal SAS transport class
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote: - There are some real challenges in supporting a udev-named boot device. For the most part, it's a distro issue, which is becoming better. PS: for $10, name a 2.6 distro that uses udev out of the box for disk names and its installation. For $10 more, can it install/boot from one? I won't get your $10, but RHEL4 has a mechanism to specify install onto BIOS disk N, where N is typically 80h (it's an int13 number, what BIOS typically boots from). EDD in anaconda handles the mapping of BIOS disk number to /dev/whatever. And a few folks at Dell are working on a udev helper to let udev know this mapping too, and incorporating the same capability into SLES in the future. After install, file system labels have been working great for years. root=LABEL=/ syntax for example, and you can get as complex as you like with that label. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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] embryonic RAID class
On Wed, Aug 17, 2005 at 06:45:25PM -0400, James Bottomley wrote: Add hotspare-0, hotspare-1 ... to the list? Yes ... I only have two disks though, so I've reached the limit of what I can do with my current fusion setup. The whole of the component display has to be reworked anyway (I only provide add, but obviously delete should be allowed as well as component type). I'll add it to the list. Probably we also need a component state model as well (and perhaps spare would be one of the states). Different controllers have different hot spare capabilities. Some hot spares are global to the whole array and can fill in if any disk fails. Others are tied to either a group of logical volumes, or to a single logical volume. The first and third associations are easy, the second association will require a new group concept. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 22/82] remove linux/version.h from drivers/message/fus ion
On Wed, Jul 20, 2005 at 12:54:09PM -0500, Nathan Lynch wrote:
Matt Domsch wrote:
On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
In general, this construct:
-#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,6))
-static int inline scsi_device_online(struct scsi_device *sdev)
-{
- return sdev-online;
-}
-#endif
is better tested as:
#ifndef scsi_device_inline
static int inline scsi_device_online(struct scsi_device *sdev)
{
return sdev-online;
}
#endif
when you can. It cleanly eliminates the version test, and tests for
exactly what you're looking for - is this function defined.
What you illustrated above is not going to work.
If your doing #ifndef around a function, such as scsi_device_online, it's
not going to compile
when scsi_device_online is already implemented in the kernel tree.
The routine scsi_device_online is a function, not a define. For a define
this would work.
Sure it does, function names are defined symbols.
$ cat foo.c
static int foo(void) { return 0; }
#ifndef foo
static int foo(void) { return 0; }
#endif
$ gcc -c foo.c
foo.c:3: error: redefinition of 'foo'
foo.c:1: error: previous definition of 'foo' was here
I believe #ifdef/#ifndef can test only preprocessor symbols.
I was mistaken. Christoph explained to me that it worked on 2.4 due to
the way module symbol versions worked, but isn't that way on 2.6
anymore. My apologies.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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 22/82] remove linux/version.h from drivers/message/fus ion
On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
In general, this construct:
-#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,6))
-static int inline scsi_device_online(struct scsi_device *sdev)
-{
- return sdev-online;
-}
-#endif
is better tested as:
#ifndef scsi_device_inline
static int inline scsi_device_online(struct scsi_device *sdev)
{
return sdev-online;
}
#endif
when you can. It cleanly eliminates the version test, and tests for
exactly what you're looking for - is this function defined.
What you illustrated above is not going to work.
If your doing #ifndef around a function, such as scsi_device_online, it's
not going to compile
when scsi_device_online is already implemented in the kernel tree.
The routine scsi_device_online is a function, not a define. For a define
this would work.
Sure it does, function names are defined symbols.
I'm doing exactly this in my backport of the openipmi drivers to RHEL4
and SLES9.
I'm trying your example around msleep, msleep_interruptible, and
msecs_to_jiffies, and
my code simply won't compile in SLES9 SP2(-191). In SLES9 SP1(-139), these
three routines were not implemented and
your suggestion works. I won't be able to to a linux version check as this
change occurred between service packs
of the 2.6.5 kernel suse tree. Anybody on the linux forums have any ideas?
Example:
#ifdef msleep
#ifndef you mean.
static void inline msleep(unsigned long msecs)
{
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(msecs_to_jiffies(msecs) + 1);
}
#endif
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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: PE1800 S-ATA RAID CERC6 with RHEL 3 / 4 ???
On Mon, Jul 11, 2005 at 08:02:47AM -0400, Salyzyn, Mark wrote: One of the problems with this class (2.4.* based 64 bit) is the Software IOMMU. You may have to boot with 'swiotlb=12288' in order to free enough mapping resources for the card. And if you're running RHEL3 Update 5 or higher, the swiotlb no longer is mapped into ZONE_DMA space, so you can safely make it larger (as Mark describes above) without depleating the 16MB ZONE_DMA. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 linux/config.h
+#include scsi/scsi_host.h
+#include scsi/scsi_device.h
+
+enum scsi_topology_action {
+ SCSI_TOPOLOGY_ADDED= 1, /* device added in the topology
Re: How to find which (physical) SCSI HBA corresponds to which ho st n umber?
On Fri, Apr 01, 2005 at 03:07:02PM -0600, James Bottomley wrote: On Fri, 2005-04-01 at 09:47 -0800, Bryan Henderson wrote: If you and Linux could identify the host in common terms, you wouldn't have to do this. But the question is open as to in what terms you personally identify the host to which you attached the device. Is it the controller to the west? The red one? The new one? The one with serial number 8436547? The one at PCI address X:Y:Z? The one that has your disk drives on it? I'm not very good on 2.4, but I believe it has a SCSI_IOCTL_GET_PCI. Yes, but that only works when called on a Scsi_Device attached to the controller. So each controller needs at least one scsi device (disk, cdrom, whatever) attached, such that there's a /dev/sd* file to open and call this ioctl. That'll get you the pci bus:dev.fn tuple. Then on x86 systems at least, the PCI IRQ Routing Table ($PIR table in BIOS) can tell you if your device is embedded or add-in, and which slot number BIOS calls it. A copy of David A. Hinds' dump_pirq script can be found here: http://linux.dell.com/files/tools/dump_pirq Device 00:04.0 (slot 0): Ethernet controller Device 00:06.0 (slot 0): Device 00:08.0 (slot 1): Class ff00 Device 00:0f.0 (slot 0): Host bridge Device 01:08.0 (slot 0): PCI bridge Device 01:06.0 (slot 0): Ethernet controller Device 02:06.0 (slot 0): SCSI storage controller Device 03:06.0 (slot 2): Device 03:08.0 (slot 3): Device 08:06.0 (slot 4): Device 08:08.0 (slot 5): Device 0d:06.0 (slot 6): RAID bus controller Device 0d:08.0 (slot 7): Slot 0 lines are embedded, the other values should pretty closely correspond to the silkscreen text on the motherboards. That's about as close as you get. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: Dell 2850 build in (LSI) PERC4/Di 2.6 kernel driver.
On Tue, Mar 29, 2005 at 02:11:20PM +0200, Paul Veldema wrote: Hello developers, For the last two months I've been strugling with a driver problem. Our company bought two Dell PowerEdge 2850's to try our production kernel version 2.6.8 (debian sarge) on since the 2650 are no longer sold. The Dell PE 2650's had Perc4/DC cards in them (which work fine with the drivers and kernel 2.6.X) supposedly the same thing as the build in Perc4/Di controllers in the PE2850's. According to Dell the LSI chipset in the PERC4 is de LSI53C1020. However, the megaraid drivers don't detect the Perc4/Di controllers resulting in a kernel panic when linux wants to start load stuff from disk (can't find file bla). I don't have the debian sarge source handy, but the kernel.org 2.6.8 kernel's drivers/scsi/megaraid.[ch] driver indeed does not have the PCI IDs for these controllers present. Looks like I misremembered when I put that text on linux.dell.com, I've corrected it. kernel.org 2.6.9 drivers/scsi/megaraid/megaraid_mbox.c does have the PCI IDs for this adapter. [snip] From source *megaraid_mbox*: #define MEGARAID_VERSION2.20.3.1 ... #define PCI_DEVICE_ID_PERC4E_DI_KOBUK 0x0013 #define PCI_SUBSYS_ID_PERC4E_DI_KOBUK 0x016d Right, this are the right IDs, as your working 2.4 scenario shows: megaraid: found 0x1028:0x0013:bus 2:slot 14:func 0 so your 2.6.9 kernel should work. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Sat, Mar 19, 2005 at 08:26:45PM +0100, Andi Kleen wrote:
On Fri, Mar 18, 2005 at 03:23:44PM -0600, Matt Domsch wrote:
For review and comment.
On x86_64 systems with no IOMMU and with 4GB RAM (in fact, whenever
there are any pages mapped above 4GB), pci_alloc_consistent() falls
back to using ZONE_DMA for all allocations, even if the device's
dma_mask could have supported using memory from other zones. Problems
can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.
Patch below makes pci_alloc_consistent() for the nommu case (EM64T
processors) match the 2.6 implementation of dma_alloc_coherent(), with
the exception that this continues to use GFP_ATOMIC.
You fixed the wrong code. The pci-nommu code is only used
when IOMMU is disabled in the Kconfig. But most kernels have
it enabled. You would need to change it in pci-gart.c too.
OK, then how's this for review? Compiles clean, can't test it myself
for a few days.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= arch/x86_64/kernel/pci-gart.c 1.12 vs edited =
--- 1.12/arch/x86_64/kernel/pci-gart.c 2004-06-03 05:29:36 -05:00
+++ edited/arch/x86_64/kernel/pci-gart.c2005-03-19 15:56:34 -06:00
@@ -154,27 +154,37 @@ void *pci_alloc_consistent(struct pci_de
int gfp = GFP_ATOMIC;
int i;
unsigned long iommu_page;
+ dma_addr_t dma_mask;
- if (hwdev == NULL || hwdev-dma_mask 0x || no_iommu)
+ if (hwdev == NULL || hwdev-dma_mask 0x)
gfp |= GFP_DMA;
+ dma_mask = hwdev ? hwdev-dma_mask : 0xULL;
+ if (dma_mask == 0)
+ dma_mask = 0xULL;
+
/*
-* First try to allocate continuous and use directly if already
-* in lowmem.
+* First try to allocate continuous and use directly if
+* our device supports it
*/
size = round_up(size, PAGE_SIZE);
+ again:
memory = (void *)__get_free_pages(gfp, get_order(size));
if (memory == NULL) {
return NULL;
} else {
- int high = 0, mmu;
- if (((unsigned long)virt_to_bus(memory) + size) 0xUL)
- high = 1;
- mmu = high;
+ int high = (((unsigned long)virt_to_bus(memory) + size)
~dma_mask) != 0;
+ int mmu = high;
if (force_mmu !(gfp GFP_DMA))
mmu = 1;
if (no_iommu) {
- if (high) goto error;
+ if (high (gfp GFP_DMA))
+ goto error;
+ if (high) {
+ free_pages((unsigned long)memory,
get_order(size));
+ gfp |= GFP_DMA;
+ goto again;
+ }
mmu = 0;
}
memset(memory, 0, size);
-
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 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
For review and comment.
On x86_64 systems with no IOMMU and with 4GB RAM (in fact, whenever
there are any pages mapped above 4GB), pci_alloc_consistent() falls
back to using ZONE_DMA for all allocations, even if the device's
dma_mask could have supported using memory from other zones. Problems
can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.
Patch below makes pci_alloc_consistent() for the nommu case (EM64T
processors) match the 2.6 implementation of dma_alloc_coherent(), with
the exception that this continues to use GFP_ATOMIC.
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
--- linux-2.4/arch/x86_64/kernel/pci-nommu.cFri Feb 25 13:01:44 2005
+++ linux-2.4/arch/x86_64/kernel/pci-nommu.cFri Feb 25 06:56:55 2005
@@ -13,18 +13,28 @@ void *pci_alloc_consistent(struct pci_de
dma_addr_t *dma_handle)
{
void *ret;
+ u64 mask;
+ int order = get_order(size);
int gfp = GFP_ATOMIC;
-
- if (hwdev == NULL ||
- end_pfn (hwdev-dma_maskPAGE_SHIFT) || /* XXX */
- (u32)hwdev-dma_mask 0x)
- gfp |= GFP_DMA;
- ret = (void *)__get_free_pages(gfp, get_order(size));
- if (ret != NULL) {
- memset(ret, 0, size);
+ if (hwdev)
+ mask = hwdev-dma_mask;
+ else
+ mask = 0xULL;
+
+ for (;;) {
+ ret = (void *)__get_free_pages(gfp, order);
+ if (ret == NULL)
+ return NULL;
*dma_handle = virt_to_bus(ret);
+ if ((*dma_handle ~mask) == 0)
+ break;
+ free_pages((unsigned long)ret, order);
+ if (gfp GFP_DMA)
+ return NULL;
+ gfp |= GFP_DMA;
}
+ memset(ret, 0, size);
return ret;
}
-
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: Defect list size ?
On Wed, Mar 16, 2005 at 11:47:09AM -0800, Jean Tourrilhes wrote: Hi, What is a reasonable defect list size for an almost new disk (3 weeks - 146 GB). scscinfo -d gives me : Data from Defect Lists -- 3060 entries in manufacturer table. ... [truncated] Which is way more than my older and smaller disk. I'm wondering if this is acceptable or if I have a bad disk. 306184192 sectors (give or take a few) on that disk. 3060 sectors bad at low-level format time. While it may feel like a large number, it really isn't for the size disk you've got. Now, if the number of Grown defects starts increasing, then yes, be worried. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.4.30-pre1] aic7xxx: don't reset chip on pause]
(resend) Patch below taken from RHEL3 Update 4 kernel 2.4.21-27.EL, fixes a bug in the aic79xx and aic7xxx drivers, where upon trying to pause the controller chip, it is accidentally hard-reset. This causes PCI Parity errors to appear on Dell PowerEdge 4600 servers as the inb() immediately after accidental reset receives corrupted data. Patch was submitted by Justin Gibbs many moons ago, but never applied to mainline 2.4. It's in mainlin 2.6. Marcelo, please apply. 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 diff -urNp --exclude-from=/home/mdomsch/excludes --minimal ./aic79xx_pci.c /home/mdomsch/kernels/linux-2.4.21-27.EL/drivers/scsi/aic7xxx/aic79xx_pci.c --- ./aic79xx_pci.c Fri Feb 18 14:38:22 2005 +++ linux/drivers/scsi/aic7xxx/aic79xx_pci.cWed Dec 1 20:49:28 2004 @@ -451,8 +457,10 @@ ahd_pci_test_register_access(struct ahd_ * or read prefetching could be initiated by the * CPU or host bridge. Our device does not support * either, so look for data corruption and/or flaged -* PCI errors. +* PCI errors. First pause without causing another +* chip reset. */ + hcntrl = ~CHIPRST; ahd_outb(ahd, HCNTRL, hcntrl|PAUSE); while (ahd_is_paused(ahd) == 0) ; diff -urNp --exclude-from=/home/mdomsch/excludes --minimal ./aic7xxx_pci.c /home/mdomsch/kernels/linux-2.4.21-27.EL/drivers/scsi/aic7xxx/aic7xxx_pci.c --- ./aic7xxx_pci.c Fri Feb 18 14:38:22 2005 +++ /home/mdomsch/kernels/linux-2.4.21-27.EL/drivers/scsi/aic7xxx/aic7xxx_pci.c Wed Dec 1 20:49:28 2004 @@ -1284,8 +1284,10 @@ ahc_pci_test_register_access(struct ahc_ * or read prefetching could be initiated by the * CPU or host bridge. Our device does not support * either, so look for data corruption and/or flagged -* PCI errors. +* PCI errors. First pause without causing another +* chip reset. */ + hcntrl = ~CHIPRST; ahc_outb(ahc, HCNTRL, hcntrl|PAUSE); while (ahc_is_paused(ahc) == 0) ; - 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 2.4.30-pre1] aic7xxx: don't reset chip on pause
Patch below taken from RHEL3 Update 4 kernel 2.4.21-27.EL, fixes a bug in the aic79xx and aic7xxx drivers, where upon trying to pause the controller chip, it is accidentally hard-reset. This causes PCI Parity errors to appear on Dell PowerEdge 4600 servers as the inb() immediately after accidental reset receives corrupted data. Patch was submitted by Justin Gibbs many moons ago, but never applied to mainline 2.4. Marcelo, please apply. 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 diff -urNp --exclude-from=/home/mdomsch/excludes --minimal ./aic79xx_pci.c /home/mdomsch/kernels/linux-2.4.21-27.EL/drivers/scsi/aic7xxx/aic79xx_pci.c --- ./aic79xx_pci.c Fri Feb 18 14:38:22 2005 +++ linux/drivers/scsi/aic7xxx/aic79xx_pci.cWed Dec 1 20:49:28 2004 @@ -451,8 +457,10 @@ ahd_pci_test_register_access(struct ahd_ * or read prefetching could be initiated by the * CPU or host bridge. Our device does not support * either, so look for data corruption and/or flaged -* PCI errors. +* PCI errors. First pause without causing another +* chip reset. */ + hcntrl = ~CHIPRST; ahd_outb(ahd, HCNTRL, hcntrl|PAUSE); while (ahd_is_paused(ahd) == 0) ; diff -urNp --exclude-from=/home/mdomsch/excludes --minimal ./aic7xxx_pci.c /home/mdomsch/kernels/linux-2.4.21-27.EL/drivers/scsi/aic7xxx/aic7xxx_pci.c --- ./aic7xxx_pci.c Fri Feb 18 14:38:22 2005 +++ /home/mdomsch/kernels/linux-2.4.21-27.EL/drivers/scsi/aic7xxx/aic7xxx_pci.c Wed Dec 1 20:49:28 2004 @@ -1284,8 +1284,10 @@ ahc_pci_test_register_access(struct ahc_ * or read prefetching could be initiated by the * CPU or host bridge. Our device does not support * either, so look for data corruption and/or flagged -* PCI errors. +* PCI errors. First pause without causing another +* chip reset. */ + hcntrl = ~CHIPRST; ahc_outb(ahc, HCNTRL, hcntrl|PAUSE); while (ahc_is_paused(ahc) == 0) ; - 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: LUN discovery by SCSI midlayer?
On Mon, Feb 14, 2005 at 08:35:25PM -0800, Joe Scsi wrote: Hi, I'm working on a driver for a SCSI protocol that is transported over a network. My basic plan is that when the driver is loaded, it will create a SCSI host structure for its initiator port. Then target ports will be discovered asynchronously (and may appear/disappear as target devices come and go on the network). I'm wondering what the best way to handle LUN discovery is. Unfortunately it seems that scsi_add_device() can only add a single LUN at a time. However, for my protocol, I see target ports and then need to find the LUNs. So far I've come up with a couple of ideas but I'm not totally happy with either: (ugly) Do all the REPORT_LUNs stuff in my driver every time I find a new target port, or (ab)use the channel index and call scsi_scan_single_target() every time I connect to a new target port. This seems OK but I'm a little put off by the fact that a quick grep shows no callers of scsi_scan_single_target in the current kernel tree. So what is the correct way to handle this? I'm sure the FC and iSCSI people must have dealt with a similar issue. Can you take a look at the patches I posted last week and see if that would work for you? http://marc.theaimsgroup.com/?l=linux-scsim=110780092314985w=2 See then the megaraid_mbox.c driver patch in the thread for how it converts logical drive numbers into HCTL values and invokes the hotplug subsystem. In your case, you'd use whatever your addressing mechanism is, and convert it into HCTL before invoking the hotplug calls. Then you've got 2 options: 1) if you have a userspace app that knows when LUNs appear and disappear, then you write to /sys/class/scsi_host/hostN/lun_found (akin to logical_drive_created). 2) if your driver is what sees LUN arrivals/removals on the topology, then the driver just invokes the hotplug calls directly rather than expecting the event to originate via a sysfs file. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 Mon, Feb 07, 2005 at 12:27:53PM -0600, Matt Domsch wrote:
Below is a patch to add some hotplug infrastructure to the Linux SCSI
subsystem.
I've added and reworked the megaraid_mbox driver to make use of this
new infrastructure. I'll send that patch next. The rest is unchanged
from yesterday.
I've put this work into a bkbits repo. This is a clone of Linus's
linux-2.6, not of James' scsi-misc-2.6.
bk pull http://mdomsch.bkbits.net/linux-2.6-scsi-hotplug
This will update the following files:
Documentation/scsi/ChangeLog.megaraid | 130
drivers/scsi/Kconfig | 10
drivers/scsi/Makefile |1
drivers/scsi/megaraid/Kconfig.megaraid |1
drivers/scsi/megaraid/mega_common.h|3
drivers/scsi/megaraid/megaraid_ioctl.h |1
drivers/scsi/megaraid/megaraid_mbox.c | 500 +++--
drivers/scsi/megaraid/megaraid_mbox.h | 28 +
drivers/scsi/megaraid/megaraid_mm.c| 39 ++
drivers/scsi/megaraid/megaraid_mm.h|5
drivers/scsi/scsi_hotplug.c| 138 +
include/scsi/scsi_hotplug.h| 41 ++
12 files changed, 867 insertions, 30 deletions
through these ChangeSets:
[EMAIL PROTECTED] (05/02/08 1.2132.2.3)
Release Date : Tue Feb 08 12:27:22 EST 2005 - Matt Domsch [EMAIL PROTECTED]
Current Version : 2.20.4.6 (scsi module), 2.20.2.5 (cmm module)
Older Version: 2.20.4.5 (scsi module), 2.20.2.5 (cmm module)
1. Added two new megaraid_shost_attrs
/sys/class/scsi_host
|-- host0
| |-- logical_drive_created
| |-- logical_drive_destroyed
and helper functions for them. Written to from userspace by
a management application, these invoke SCSI hotplug
infrastructure for informing the kernel that a logical drive
has been created, or will be destroyed quite soon.
echo 2 logical_drive_created
after creating logical drive #2 in the management app
echo 4 logical_drive_destroyed
immediately before destroying logical drive #4 in the
management app. Eventually these functions should be called
directly from the management app.
2. Made class_device_megaraid_mbox_app_hndl and
dev_attr_megaraid_mbox_ld static.
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
[EMAIL PROTECTED] (05/02/08 1.2132.2.2)
megaraid_2.20.4.5.patch
[EMAIL PROTECTED] (05/02/07 1.2048.2.1)
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.
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.
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
-
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 Tue, Feb 08, 2005 at 05:19:23PM -0600, Matt Domsch wrote: I've added and reworked the megaraid_mbox driver to make use of this new infrastructure. I'll send that patch next. The rest is unchanged from yesterday. This is the megaraid_mbox 2.20.4.5 patch as submitted by LSI on-list last week. 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 You can import this changeset into BK by piping this whole message to '| bk receive [path to repository]' or apply the patch as usual. === [EMAIL PROTECTED], 2005-02-08 14:53:12-06:00, [EMAIL PROTECTED] megaraid_2.20.4.5.patch Documentation/scsi/ChangeLog.megaraid | 104 drivers/scsi/megaraid/Kconfig.megaraid |1 drivers/scsi/megaraid/mega_common.h|3 drivers/scsi/megaraid/megaraid_ioctl.h |1 drivers/scsi/megaraid/megaraid_mbox.c | 403 - drivers/scsi/megaraid/megaraid_mbox.h | 24 + drivers/scsi/megaraid/megaraid_mm.c| 39 +++ drivers/scsi/megaraid/megaraid_mm.h|5 8 files changed, 561 insertions, 19 deletions diff -Nru a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid --- a/Documentation/scsi/ChangeLog.megaraid 2005-02-08 17:16:50 -06:00 +++ b/Documentation/scsi/ChangeLog.megaraid 2005-02-08 17:16:50 -06:00 @@ -1,3 +1,105 @@ +Release Date : Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju [EMAIL PROTECTED] +Current Version: 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) +Older Version : 2.20.4.4 (scsi module), 2.20.2.4 (cmm module) + +1. Modified name of two attributes in scsi_host_template. + On Wed, 2005-02-02 at 10:56 -0500, Ju, Seokmann wrote: ++ .sdev_attrs = megaraid_device_attrs, ++ .shost_attrs= megaraid_class_device_attrs, + + These are, perhaps, slightly confusing names. + The terms device and class_device have well defined meanings in the + generic device model, neither of which is what you mean here. + Why not simply megaraid_sdev_attrs and megaraid_shost_attrs? + + Other than this, it looks fine to me too. + +Release Date : Thu Jan 27 00:01:03 EST 2005 - Atul Mukker [EMAIL PROTECTED] +Current Version: 2.20.4.4 (scsi module), 2.20.2.5 (cmm module) +Older Version : 2.20.4.3 (scsi module), 2.20.2.4 (cmm module) + +1. Bump up the version of scsi module due to its conflict. + +Release Date : Thu Jan 21 00:01:03 EST 2005 - Atul Mukker [EMAIL PROTECTED] +Current Version: 2.20.4.3 (scsi module), 2.20.2.5 (cmm module) +Older Version : 2.20.4.2 (scsi module), 2.20.2.4 (cmm module) + +1. Remove driver ioctl for logical drive to scsi address translation and + replace with the sysfs attribute. To remove drives and change + capacity, application shall now use the device attribute to get the + logical drive number for a scsi device. For adding newly created + logical drives, class device attribute would be required to uniquely + identify each controller. + - Atul Mukker [EMAIL PROTECTED] + + James, I've been thinking about this a little more, and you may be on + to something here. Let each driver add files as such: + + - Matt Domsch [EMAIL PROTECTED], 12.15.2004 +linux-scsi mailing list + + + Then, if you simply publish your LD number as an extra parameter of + the device, you can look through /sys to find it. + + - James Bottomley [EMAIL PROTECTED], 01.03.2005 +linux-scsi mailing list + + + I don't see why not ... it's your driver, you can publish whatever + extra information you need as scsi_device attributes; that was one of + the designs of the extensible attribute system. + + - James Bottomley [EMAIL PROTECTED], 01.06.2005 +linux-scsi mailing list + +2. Add AMI megaraid support - Brian King [EMAIL PROTECTED] + PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3, + PCI_VENDOR_ID_AMI, PCI_SUBSYS_ID_PERC3_DC, + +3. Make some code static - Adrian Bunk [EMAIL PROTECTED] + Date: Mon, 15 Nov 2004 03:14:57 +0100 + + The patch below makes some needlessly global code static. + -wait_queue_head_t wait_q; + +static wait_queue_head_t wait_q; + + Signed-off-by: Adrian Bunk [EMAIL PROTECTED] + +4. Added NEC ROMB support - NEC MegaRAID PCI Express ROMB controller + PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_MEGARAID_NEC_ROMB_2E, + PCI_SUBSYS_ID_NEC, PCI_SUBSYS_ID_MEGARAID_NEC_ROMB_2E, + +5. Fixed Tape drive issue : For any Direct CDB command to physical device + including tape, timeout value set by driver was 10 minutes
Re: [RFC][PATCH 2.6.11-rc2] Linux SCSI hotplug infrastructure
On Tue, Feb 08, 2005 at 05:19:23PM -0600, Matt Domsch wrote: On Mon, Feb 07, 2005 at 12:27:53PM -0600, Matt Domsch wrote: Below is a patch to add some hotplug infrastructure to the Linux SCSI subsystem. I've added and reworked the megaraid_mbox driver to make use of this new infrastructure. I'll send that patch next. The rest is unchanged from yesterday. And these are the changes megaid_mbox to use the new infrastructure. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com You can import this changeset into BK by piping this whole message to '| bk receive [path to repository]' or apply the patch as usual. === [EMAIL PROTECTED], 2005-02-08 16:46:03-06:00, [EMAIL PROTECTED] Release Date : Tue Feb 08 12:27:22 EST 2005 - Matt Domsch [EMAIL PROTECTED] Current Version : 2.20.4.6 (scsi module), 2.20.2.5 (cmm module) Older Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) 1.Added two new megaraid_shost_attrs /sys/class/scsi_host |-- host0 | |-- logical_drive_created | |-- logical_drive_destroyed and helper functions for them. Written to from userspace by a management application, these invoke SCSI hotplug infrastructure for informing the kernel that a logical drive has been created, or will be destroyed quite soon. echo 2 logical_drive_created after creating logical drive #2 in the management app echo 4 logical_drive_destroyed immediately before destroying logical drive #4 in the management app. Eventually these functions should be called directly from the management app. 2.Made class_device_megaraid_mbox_app_hndl and dev_attr_megaraid_mbox_ld static. Signed-off-by: Matt Domsch [EMAIL PROTECTED] Documentation/scsi/ChangeLog.megaraid | 26 + drivers/scsi/megaraid/megaraid_mbox.c | 97 ++ drivers/scsi/megaraid/megaraid_mbox.h |4 - 3 files changed, 116 insertions, 11 deletions diff -Nru a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid --- a/Documentation/scsi/ChangeLog.megaraid 2005-02-08 17:16:27 -06:00 +++ b/Documentation/scsi/ChangeLog.megaraid 2005-02-08 17:16:27 -06:00 @@ -1,3 +1,29 @@ +Release Date : Tue Feb 08 12:27:22 EST 2005 - Matt Domsch [EMAIL PROTECTED] +Current Version: 2.20.4.6 (scsi module), 2.20.2.5 (cmm module) +Older Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) + +1. Added two new megaraid_shost_attrs + /sys/class/scsi_host + |-- host0 + | |-- logical_drive_created + | |-- logical_drive_destroyed + + and helper functions for them. Written to from userspace by + a management application, these invoke SCSI hotplug + infrastructure for informing the kernel that a logical drive + has been created, or will be destroyed quite soon. + echo 2 logical_drive_created +after creating logical drive #2 in the management app + echo 4 logical_drive_destroyed + immediately before destroying logical drive #4 in the + management app. Eventually these functions should be called + directly from the management app. + +2. Made class_device_megaraid_mbox_app_hndl and +dev_attr_megaraid_mbox_ld static. + + + Release Date : Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju [EMAIL PROTECTED] Current Version: 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) Older Version : 2.20.4.4 (scsi module), 2.20.2.4 (cmm module) diff -Nru a/drivers/scsi/megaraid/megaraid_mbox.c b/drivers/scsi/megaraid/megaraid_mbox.c --- a/drivers/scsi/megaraid/megaraid_mbox.c 2005-02-08 17:16:27 -06:00 +++ b/drivers/scsi/megaraid/megaraid_mbox.c 2005-02-08 17:16:27 -06:00 @@ -69,6 +69,7 @@ * For history of changes, see Documentation/ChangeLog.megaraid */ +#include scsi/scsi_hotplug.h #include megaraid_mbox.h static int megaraid_init(void); @@ -470,29 +471,107 @@ } }; +/* + * sysfs class device support + * creates two files: + * /sys/class/scsi_host + * |-- host0 + * | |-- logical_drive_created + * | |-- logical_drive_destroyed + * + * These make the midlayer invoke /sbin/hotplug, which then calls back into sysfs + * /sys/class/scsi_host + * |-- host0 + * | |-- scan + * + * and + * + * /sys/devices/pci:0x/:0x:0x.0/host0 + * |-- 0:0:0:0 + * | |-- delete + * + * respectively. This allows userspace applications to work + * using their logical drive number, and lets the driver translate + * that into host, channel, id, and lun values which the other + * mechanisms require. This is similar to how hot plug CPU works. + */ +/** + * lda_to_hcil() + * @adapter + * @lda - logical drive address + * @host_no
[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 linux/config.h
+#include scsi/scsi_host.h
+#include scsi/scsi_device.h
+
+enum scsi_topology_action {
+ SCSI_TOPOLOGY_ADDED= 1, /* device added in the topology */
+ SCSI_TOPOLOGY_REMOVED = 2, /* device removed from the topology */
+};
+
+#if defined (CONFIG_SCSI_HOTPLUG) || defined(CONFIG_SCSI_HOTPLUG_MODULE)
+extern int scsi_topology_hctl_action(struct Scsi_Host *shost, unsigned int
channel,
+ unsigned int id, unsigned int lun, enum
Re: [RFC][PATCH 2.6.11-rc2] Linux SCSI hotplug infrastructure
On Mon, Feb 07, 2005 at 12:27:53PM -0600, Matt Domsch wrote:
Modified files:
drivers/scsi/megaraid/megaraid_mbox.c
(will follow in a separate patch)
is the user of this new function.
For example. I will rework this to follow the patch submitted last
week by LSI to accomplish something similar in their driver.
--
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/megaraid/megaraid_mbox.c 1.12 vs edited =
--- 1.12/drivers/scsi/megaraid/megaraid_mbox.c 2005-01-31 00:33:46 -06:00
+++ edited/drivers/scsi/megaraid/megaraid_mbox.c2005-02-06 23:35:08
-06:00
@@ -70,6 +70,7 @@
* For history of changes, see Documentation/ChangeLog.megaraid
*/
+#include scsi/scsi_hotplug.h
#include megaraid_mbox.h
static int megaraid_init(void);
@@ -455,6 +456,100 @@
/*
+ * sysfs class device support
+ * creates three files:
+ * /sys/class/scsi_host
+ * |-- host0
+ * | |-- logical_drive_created
+ * | |-- logical_drive_destroyed
+ *
+ * These make the midlayer invoke /sbin/hotplug, which then calls back into
sysfs
+ * /sys/class/scsi_host
+ * |-- host0
+ * | |-- scan
+ *
+ * and
+ *
+ * /sys/devices/pci:0x/:0x:0x.0/host0
+ * |-- 0:0:0:0
+ * | |-- delete
+ *
+ * respectively. This allows userspace applications to work
+ * using their logical drive number, and lets the driver translate
+ * that into host, channel, id, and lun values which the other
+ * mechanisms require. This is similar to how hot plug CPU works.
+ */
+
+/**
+ * lda_to_hcil()
+ * @adapter
+ * @lda - logical drive address
+ * @host_no
+ * @channel
+ * @id
+ * @lun
+ *
+ * converts a logical drive address into a host, channel id, lun tuple.
+ */
+
+static inline int megaraid_lda_to_hcil(struct Scsi_Host *shost, u32 lda,
+ u32 *host_no, u32 *channel, u32 *id, u32
*lun)
+{
+ if (lda MAX_LOGICAL_DRIVES_40LD)
+ return -EINVAL;
+ *host_no = shost-host_no;
+ *channel = shost-max_channel;
+ *id = (lda shost-this_id) ? lda : lda + 1;
+ *lun = 0;
+ return 0;
+}
+
+static int megaraid_host_store(struct class_device *class_dev, const char
*buf, size_t count,
+ enum scsi_topology_action action)
+{
+struct Scsi_Host *shost = class_to_shost(class_dev);
+ int fields=0, rc=-EINVAL;
+ u32 lda=0, host_no=0, channel=0, id=0, lun=0;
+ fields = sscanf(buf, %u, lda);
+ if (fields != 1)
+ return rc;
+ if (lda MAX_LOGICAL_DRIVES_40LD)
+ return rc;
+ rc = megaraid_lda_to_hcil(shost, lda, host_no, channel, id, lun);
+ if (rc)
+ return rc;
+
+ rc = scsi_topology_hctl_action(shost, channel, id, lun, action);
+
+ if (rc)
+ return rc;
+ return count;
+}
+
+static ssize_t megaraid_host_store_ld_created(struct class_device *class_dev,
const char *buf, size_t count)
+{
+ return megaraid_host_store(class_dev, buf, count, SCSI_TOPOLOGY_ADDED);
+}
+static ssize_t megaraid_host_store_ld_destroyed(struct class_device
*class_dev, const char *buf, size_t count)
+{
+ return megaraid_host_store(class_dev, buf, count,
SCSI_TOPOLOGY_REMOVED);
+}
+
+
+#define MEGARAID_HOST_WOATTR(_name,_store) \
+CLASS_DEVICE_ATTR(_name, S_IWUSR|S_IWGRP, NULL, _store)
+
+static MEGARAID_HOST_WOATTR(logical_drive_created,
megaraid_host_store_ld_created);
+static MEGARAID_HOST_WOATTR(logical_drive_destroyed,
megaraid_host_store_ld_destroyed);
+
+/* Host attributes initializer */
+static struct class_device_attribute *megaraid_host_attrs[] = {
+ class_device_attr_logical_drive_created,
+ class_device_attr_logical_drive_destroyed,
+ NULL,
+};
+
+/*
* Scsi host template for megaraid unified driver
*/
static struct scsi_host_template megaraid_template_g = {
@@ -467,6 +562,7 @@
.eh_bus_reset_handler = megaraid_reset_handler,
.eh_host_reset_handler = megaraid_reset_handler,
.use_clustering = ENABLE_CLUSTERING,
+ .shost_attrs= megaraid_host_attrs,
};
-
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 Mon, Feb 07, 2005 at 12:27:53PM -0600, Matt Domsch wrote:
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.
Patch follows.
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
--- udev-050/udev_sysfs.c.~1~ 2004-12-17 23:53:07.0 -0600
+++ udev-050/udev_sysfs.c 2005-02-07 10:58:45.0 -0600
@@ -56,6 +56,7 @@
{ .subsystem = fc_host, .file = port_id },
{ .subsystem = spi_transport, .file = width },
{ .subsystem = spi_host, .file = width },
+ { .subsystem = scsi_topology, .file = NULL },
{ NULL, NULL }
};
-
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 Mon, Feb 07, 2005 at 12:27:53PM -0600, Matt Domsch wrote:
/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.
And here's scsi_topology.agent.
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
#!/bin/bash
#
# SCSI Topology hotplug agent.
# Copyright (C) 2005 Dell, Inc. [EMAIL PROTECTED]
#
# This is invoked when a device, not currently known to the system, is
# added or removed from a SCSI topology. This includes creation of a
# logical drive on a RAID controller, or manually inserting a disk
# into a SCSI disk enclosure. This script then invokes the scan
# method of the scsi_host, or the delete method of the scsi_device, to
# inform the kernel of the change made on the topology.
#
# SCSI_TOPOLOGY_EVENT_HCTL is used to know that the data to pass to
# scan is a Host:Controller:Target ID:LUN tuple. This is to provide
# for future SCSI implmentations that may use a native addressing
# scheme rather than only HCTL.
[ ${SCSI_TOPOLOGY_EVENT} != 1 ] exit
[ ${SCSI_TOPOLOGY_EVENT_HCTL} != 1 ] exit
if [ ${ACTION} = add ]; then
MYPATH=/sys/class/scsi_host/host${SCSI_HOST}/scan
[ -f ${MYPATH} ] echo ${SCSI_CHANNEL} ${SCSI_ID} ${SCSI_LUN}
${MYPATH}
fi
if [ ${ACTION} = remove ]; then
MYPATH=/sys/class/scsi_device/${SCSI_HOST}:${SCSI_CHANNEL}:${SCSI_ID}:${SCSI_LUN}/device/delete
[ -f ${MYPATH} ] echo 1 ${MYPATH}
fi
-
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] megaraid_mbox 2.20.4.3 patch
On Tue, Jan 25, 2005 at 07:52:42PM -0500, Ju, Seokmann wrote: Hello, Here is a patch for megaraid_mbox 2.20.4.3 and megaraid_mm 2.20.2.5. The patch includes following changes/fixes - sysfs support for drive addition/removal - Tape drive timeout issue - Made some code static I am attaching and inlining the patch. This patch is mangled. Long lines are wrapped, and appears to be in ISO-8859-1, such that spaces (ascii 0x20) appear as hex 0xa0. This makes it difficult to review, and impossible to apply. +// definitions for the device attributes for exporting logical drive number +// for a scsi address (Host, Channel, Id, Lun) + +CLASS_DEVICE_ATTR(megaraid_mbox_app_hndl, S_IRUSR, megaraid_sysfs_show_app_hndl, + NULL); How is this being used by your apps please? Otherwise the patch looks sane. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: Disk errors
On Tue, Feb 01, 2005 at 12:41:13AM +0100, Kit Gerrits wrote: But if the PERC (controller) handles disk errors, what could cause: I/O Error Dev 08:05 Sector 529712 I would assume that this error is generated by the harddrive, but shouldn't the controller catch SCSI errors (and relocate sectors automagically)? In this case, the RAID controller is reporting the I/O error. It may be that you've got bad sectors on more than one physical disk, in the same stripe, and the RAID controller can't fix them. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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] drop some attibutes from the FC transport class
On Wed, Jan 19, 2005 at 03:42:19PM -0800, Greg KH wrote: Here it was against 2.6.9. Odds are it doesn't apply anymore due to some recent changes in this area. If anyone wants to take it and fix it up, please do so. Note, this patch needs the evil strdup() function to work properly. That's one of the main reasons I decided to not submit it to the main kernel tree... How would you feel if instead, we just didn't drop the .modinfo section? That would eliminate the need to copy the strings, and then the field##_get_function would just use the string from the .modinfo section directly? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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
