[PATCH 2/3] cciss: support for more than 8 controllers
This patch adds support for more than 8 controllers. If we run out of
preallocated major numbers we dynamically allocate more.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
cciss.c | 36 +++-
cciss.h |3 +++
2 files changed, 30 insertions(+), 9 deletions(-)
---
diff -burNp lx2611-p001/drivers/block/cciss.c lx2611-p002/drivers/block/cciss.c
--- lx2611-p001/drivers/block/cciss.c 2005-03-08 16:39:01.650427392 -0600
+++ lx2611-p002/drivers/block/cciss.c 2005-03-08 16:50:47.149175280 -0600
@@ -120,7 +120,11 @@ static struct board_type products[] = {
#define READ_AHEAD 1024
#define NR_CMDS 384 /* #commands that can be outstanding */
-#define MAX_CTLR 8
+#define MAX_CTLR 32
+
+/* Originally cciss driver only supports 8 major numbers */
+#define MAX_CTLR_ORIG 8
+
#define CCISS_DMA_MASK 0x /* 32 bit DMA */
@@ -2650,7 +2654,7 @@ static int alloc_cciss_hba(void)
}
}
printk(KERN_WARNING "cciss: This driver supports a maximum"
- " of 8 controllers.\n");
+ " of %d controllers.\n", MAX_CTLR);
goto out;
Enomem:
printk(KERN_ERR "cciss: out of memory.\n");
@@ -2682,13 +2686,14 @@ static int __devinit cciss_init_one(stru
request_queue_t *q;
int i;
int j;
+ int rc;
printk(KERN_DEBUG "cciss: Device 0x%x has been found at"
" bus %d dev %d func %d\n",
pdev->device, pdev->bus->number, PCI_SLOT(pdev->devfn),
PCI_FUNC(pdev->devfn));
i = alloc_cciss_hba();
- if( i < 0 )
+ if(i < 0)
return (-1);
if (cciss_pci_init(hba[i], pdev) != 0)
goto clean1;
@@ -2707,11 +2712,24 @@ static int __devinit cciss_init_one(stru
goto clean1;
}
- if (register_blkdev(COMPAQ_CISS_MAJOR+i, hba[i]->devname)) {
- printk(KERN_ERR "cciss: Unable to register device %s\n",
- hba[i]->devname);
+ /*
+* register with the major number, or get a dynamic major number
+* by passing 0 as argument. This is done for greater than
+* 8 controller support.
+*/
+ if (i < MAX_CTLR_ORIG)
+ hba[i]->major = MAJOR_NR + i;
+ rc = register_blkdev(hba[i]->major, hba[i]->devname);
+ if(rc == -EBUSY || rc == -EINVAL) {
+ printk(KERN_ERR
+ "cciss: Unable to get major number %d for %s "
+ "on hba %d\n", hba[i]->major, hba[i]->devname, i);
goto clean1;
}
+ else {
+ if (i >= MAX_CTLR_ORIG)
+ hba[i]->major = rc;
+ }
/* make sure the board interrupts are off */
hba[i]->access.set_intr_mask(hba[i], CCISS_INTR_OFF);
@@ -2782,7 +2800,7 @@ static int __devinit cciss_init_one(stru
sprintf(disk->disk_name, "cciss/c%dd%d", i, j);
sprintf(disk->devfs_name, "cciss/host%d/target%d", i, j);
- disk->major = COMPAQ_CISS_MAJOR + i;
+ disk->major = hba[i]->major;
disk->first_minor = j << NWD_SHIFT;
disk->fops = &cciss_fops;
disk->queue = hba[i]->queue;
@@ -2811,7 +2829,7 @@ clean4:
hba[i]->errinfo_pool_dhandle);
free_irq(hba[i]->intr, hba[i]);
clean2:
- unregister_blkdev(COMPAQ_CISS_MAJOR+i, hba[i]->devname);
+ unregister_blkdev(hba[i]->major, hba[i]->devname);
clean1:
release_io_mem(hba[i]);
free_hba(i);
@@ -2853,7 +2871,7 @@ static void __devexit cciss_remove_one (
pci_set_drvdata(pdev, NULL);
iounmap(hba[i]->vaddr);
cciss_unregister_scsi(i); /* unhook from SCSI subsystem */
- unregister_blkdev(COMPAQ_CISS_MAJOR+i, hba[i]->devname);
+ unregister_blkdev(hba[i]->major, hba[i]->devname);
remove_proc_entry(hba[i]->devname, proc_cciss);
/* remove it from the disk list */
diff -burNp lx2611-p001/drivers/block/cciss.h lx2611-p002/drivers/block/cciss.h
--- lx2611-p001/drivers/block/cciss.h 2004-12-24 15:33:48.0 -0600
+++ lx2611-p002/drivers/block/cciss.h 2005-03-08 16:50:47.150175128 -0600
@@ -13,6 +13,8 @@
#define IO_OK 0
#define IO_ERROR 1
+#define MAJOR_NR COMPAQ_CISS_MAJOR
+
struct ctlr_info;
typedef struct ctlr_info ctlr_info_t;
@@ -50,6 +52,7 @@ struct ctlr_info
CfgTable_struct __iomem *cfgtable;
unsigned int intr;
int interrupts_enabled;
+ int major;
int max_commands;
int commands_outstanding;
int max_outstanding; /* Debug */
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAI
Re: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
On Wed, Mar 09, 2005 at 05:47:27PM -0500, Bagalkote, Sreenivas wrote: > > > >Even for kernels with a 64bit dma_addr_t you can get 32bit dma > >addresses > >only. As a start check whether the pci_set_dma_mask for the 64bit mask > >failed - in that case you can always use 32bit SGLs. > > > > Please help me understand: If dma_addr_t is 64 bit, I will get 64bit > addresses in scatterlist regardless the outcome of pci_set_dma_mask, > won't I? These addresses may have valid or null high addresses. My idea > was to have 32(64) bit SGLs for 32(64) bit dma_addr_t. if pci_set_dma_mask for the 64bit mask fails the upper 32bit bit of dma_addr_t will guaranteed to be zero, so you don't need to take them into account for your hardware SGL. - 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: How does a SCSI device gets a target ID?
BINGO ! That answered to a lot extent what I was looking for. Yes, I accept my question was a little cloudy. I wanted to ask both the perspectives: How does a SCSI device gets its ID ... And How can the software (kernel / user) find out the target ID of the new disk. I'm using a HS disk (Hot Swappable SCSI disk, they call it). I have 4 slots in the front panel of my computer. And when ever I plug the disk into a different port, the target ID changes. I wanted to confirm that the target Ids are binded to the PORTS in my case. I got my answer, in my case, the target ID depends upon which port you plug the disk into. Every time I plug / unplug the disk, I have to echo "scsi add-single-device"/"scsi remove single-device" (with correct traget ID) to /proc/scsi/scsi. I wanted to automate this process, I wanted the disk to get detected and installed the moment it is inserted / removed. Can I do that? I don't mind writing a kernel module if need be. Currently after reading the mail, what I am planning to do is to write a user level script that would echo "add-single device" to the proc interface, for ALL the possible target Ids on the Bus. But again, I would have to RUN that script manually, and it will have to ITERATE on the the possible target Ids. Is there a better way? Thanx a ton, Rajat -Original Message- From: Bryan Henderson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 12:16 AM To: Rajat Jain, Noida Cc: linux-scsi@vger.kernel.org Subject: Re: How does a SCSI device gets a target ID? It's not clear what you're asking. You start off with the question >When a new SCSI device is added to a SCSI channel, how can we find out what >is the target ID of that device? That's clear enough, except I don't know who "we" is. Depending on who you are, i.e. from what perspective you're looking, you would get this information differently. But then you give two hypotheses that describe how a device comes to have its target ID, not how someone finds out what target ID it has. >1) If a channel supports 8 SCSI devices, then each of the 8 ports will have >a specific Target ID. And any device attached to that port will have >that Target ID. >2) Is it done one the fly? I mean (starting from zero), the SCSI device is >given a target ID that is 1 greater that the last SCSI device's ID. Who >assigns this ID? Others have read a particular question into your question and answered it, but it might not be what you were looking for. Let me give a shot at answering a few of the questions that it might be: A device traditionally gets its target ID from a physical switch on the device. The person who installs the device sets the switch and can tell the target ID by looking at it the switch. That person chooses the target IDs to be anything he wants, but makes sure that no two devices plugged into the same bus have the same target ID. In modern times, some devices (disk devices, anyway) get their target ID by being plugged into a backplane or cable in a certain place. In that case, you can tell the target ID by noting where it's plugged in and knowing how the thing you plugged it into is configured. SCA is one standard for allowing this kind of target ID assignment. Some devices even get their target IDs dynamically with SCAM, but I don't know anything about SCAM. If you're inside the computer and trying to figure out what target ID an attached device has, all you can do is search the namespace. You try each target ID and if a device answers, you can ask it for information about itself (model, serial number, etc.). But you don't necessarily ever know what target ID a particular device has -- you just know that there exists a device with a certain target ID. At various levels of Linux, matching up target IDs with devices is done via various interfaces, most of them quite tortured. - 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: How does a SCSI device gets a target ID?
You said: "And plugging any SE device onto an LVD bus causes the whole bus to fall back to SE. This includes terminators." True, but if your terminator is LVD only, it will get hot!!! Not sure if it can be damaged, but it does get hot (or warm). :) I also believe some LVD devices do not support SE. Guy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Wilcox Sent: Wednesday, March 09, 2005 12:30 PM To: Guy Cc: 'Rajat Jain, Noida'; linux-scsi@vger.kernel.org Subject: Re: How does a SCSI device gets a target ID? On Wed, Mar 09, 2005 at 11:54:57AM -0500, Guy wrote: > A narrow SCSI bus will support 8 devices. > A wide SCSI bus will support 16 devices. > A narrow bus uses 50 pins. > A wide bus uses 68 pins. We need a SCSI Wiki for all this kind of information ... maybe Wikipedia? > There is a standard for auto selecting the SCSI ID. I have never used this. > SCAM (SCSI Configures Auto Magically). I think the SCSI vendors prefer to sell SCA drives rather than SCAM drives ;-) Drives with the SCA connector have power supplied to them and their SCSI ID configured automatically depending on which slot they're plugged into. If you're doing hotplug SCSI, it's probably with SCA drives. > Mixing devices with different electrical standards can be tricky. Some > can't be mixed. HVD is not compatible with any other. And plugging any SE devince onto an LVD bus causes the whole bus to fall back to SE. This includes terminators. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - 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 - 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 0/6] Open-iSCSI High-Performance Initiator for Linux
Lars Marowsky-Bree wrote: On 2005-03-08T22:25:29, Alex Aizman <[EMAIL PROTECTED]> wrote: There's (or at least was up until today) an ongoing discussion on our mailing list at http://groups-beta.google.com/group/open-iscsi. The short and long of it: the problem can be solved, and it will. Couple simple things we already do: mlockall() to keep the daemon un-swapped, and also looking into potential dependency created by syslog (there's one for 2.4 kernel, not sure if this is an issue for 2.6). BTW, to get around the very same issues, heartbeat does much the same: lock itself into memory, reserve a couple of pages more to spare on stack & heap, run at soft-realtime priority. Heartbeat is good for reliability, etc. WRT "getting paged-out" - non-deterministic (things depend on time), right? syslog(), however, sucks. It does. We went down the path of using our non-blocking IPC library to have all our various components log to ha_logd, which then logs to syslog() or writes to disk or wherever. Found ha_logd under http://linux-ha.org. The latter is extemely interesting in the longer term. In the short term, there's quite a bit of information on this site, need time. That works well in our current development series, and if you want to share code, you can either rip it off (Open Source, we love ya ;) or we can spin off these parts into a sub-package for you to depend on... If it's not a big deal :-) let's do the "sub-package" option. The sfnet is a learning experience; it is by no means a proof that it cannot be done. I'd also argue that it MUST be done, because the current way of "Oh, it's somehow related to block stuff, must be in kernel" leads down to hell. We better figure out good ways around it ;-) Yes, it MUST be done. Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> Alex - 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 0/6] Open-iSCSI High-Performance Initiator for Linux
Bryan Henderson wrote: Its fundamental to Unix architecture that user programs sit above the kernel and get services from the kernel, and turning that on its head so that the kernel depends on a user space program to do something as fundamental as a pageout can't come to any good. Agreed. Even if we're able to identify every assumption in Linux design that's being broken and patch it up with something like mlockall, tomorrow someone will change something, using his vast experience with engineering user space programs, and break it again. In the same vein can quote Murphy's laws here, like "things get worse under pressure", etc. Specifics, please! Maybe a more important point is that to the extent that you make a user space process a proxy of the kernel, you lose all those advantages that are supposed to come with user space engineering: you can now totally hose your system by making a mistake in the code; you have to be intimately familiar with kernel internals to get the code right, etc. mlockall is meant to provide performance characteristics to a user space process. If it can be used to create resource ordering correctness, it's an accident. Syslog is one of those things you're not supposed to have to think about. If every time you issue a message you have to visualize the entire syslog system with all of its options to know if you've broken something, the simplicity of user space is gone. The issue with syslog is clear, we are looking into implementation options. I would think as a basic design principle that if kernel code ever has to wait for a user process to do something, Open-iSCSI is designed for this to never happen. The user/kernel interface (see include/iscsi_if.h) is non-blocking. Once the transport connection gets established (by the user) and handed over to the kernel (to transport block data), the rest data path happens without user interaction. Command level error processing is done by the kernel part, _no_ dependency here. Connection-level error processing is _delegated_ to the user, kernel does not block - it just expects the "higher" authority to make the decision wrt faulty connection. it should do it high in a system call, in user context, interruptibly, etc. I don't know if it's possible to arrange to have the ISCSI initiator waiting there, but I think it's the only way having a user space process can do what it's supposed to do. I also don't know whether it is possible (but I know that if it were possible it would by quite ugly); the main thing however is - this is not what's happening. I'd like to remind everyone that user space processes aside, there's still a basic ISCSI initiator resource inversion that needs to be fixed to avoid deadlock: ISCSI initiator driver sits below the memory pool (I..e a pageout involving ISCSI might be prerequisite to getting memory) Socket layer sits below ISCSI (ISCSI initiator driver relies on socket services) Memory pool sits below socket layer (socket layer allocates memory from the main pool) One might say as long as that's there, close is good enough on the user space initiator component. -- Bryan Henderson San Jose California IBM Almaden Research Center Filesystems Alex - 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
Something wrong with latest adaptec aic driver
(Found out not to put aic7xxx in subject line because of spam filter...) Running with latest 2.6.11 bk tree, one of my machines takes for ever to boot. The driver is builtin (not a module). It worked fine until today, and works fine with 2.6.11 or earlier. Looks like it is going into some probing fallback unwind code mess... This is the current driver not the old driver. The scsi controller is: :03:01.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) Subsystem: IBM: Unknown device 00cf Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 20 BIST result: 00 I/O ports at 9000 [disabled] Memory at f2006000 (64-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 :03:01.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) Subsystem: IBM: Unknown device 00cf Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 20 BIST result: 00 I/O ports at 9400 [disabled] Memory at f2005000 (64-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 During boot up the console output is... ACPI: PCI interrupt :03:01.1[B] -> GSI 20 (level, low) -> IRQ 20 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs (scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) (scsi0:A:0): 80.000MB/s transfers (40.000MHz DT, offset 63, 16bit) (scsi0:A:0): 80.000MB/s transfers (40.000MHz, offset 63, 16bit) ahc_intr: HOST_MSG_LOOP bad phase 0x0 (scsi0:A:0): 40.000MB/s transfers (40.000MHz, offset 63) (scsi0:A:0): 66.006MB/s transfers (33.003MHz DT, offset 63, 16bit) (scsi0:A:0): 66.006MB/s transfers (33.003MHz, offset 63, 16bit) (scsi0:A:0): 40.000MB/s transfers (20.000MHz DT, offset 63, 16bit) (scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 63, 16bit) (scsi0:A:0): 33.003MB/s transfers (33.003MHz, offset 63) (scsi0:A:0): 20.000MB/s transfers (20.000MHz, offset 63) (scsi0:A:0): 38.460MB/s transfers (19.230MHz DT, offset 63, 16bit) (scsi0:A:0): 38.460MB/s transfers (19.230MHz, offset 63, 16bit) (scsi0:A:0): 35.714MB/s transfers (17.857MHz DT, offset 63, 16bit) (scsi0:A:0): 35.714MB/s transfers (17.857MHz, offset 63, 16bit) (scsi0:A:0): 33.332MB/s transfers (16.666MHz DT, offset 63, 16bit) (scsi0:A:0): 33.332MB/s transfers (16.666MHz, offset 63, 16bit) (scsi0:A:0): 31.250MB/s transfers (15.625MHz DT, offset 63, 16bit) (scsi0:A:0): 31.250MB/s transfers (15.625MHz, offset 63, 16bit) (scsi0:A:0): 29.410MB/s transfers (14.705MHz DT, offset 63, 16bit) (scsi0:A:0): 29.410MB/s transfers (14.705MHz, offset 63, 16bit) (scsi0:A:0): 27.776MB/s transfers (13.888MHz DT, offset 63, 16bit) (scsi0:A:0): 27.776MB/s transfers (13.888MHz, offset 63, 16bit) (scsi0:A:0): 26.314MB/s transfers (13.157MHz DT, offset 63, 16bit) (scsi0:A:0): 26.314MB/s transfers (13.157MHz, offset 63, 16bit) (scsi0:A:0): 25.000MB/s transfers (12.500MHz DT, offset 63, 16bit) (scsi0:A:0): 25.000MB/s transfers (12.500MHz, offset 63, 16bit) (scsi0:A:0): 23.808MB/s transfers (11.904MHz DT, offset 63, 16bit) (scsi0:A:0): 23.808MB/s transfers (11.904MHz, offset 63, 16bit) (scsi0:A:0): 22.726MB/s transfers (11.363MHz DT, offset 63, 16bit) (scsi0:A:0): 22.726MB/s transfers (11.363MHz, offset 63, 16bit) (scsi0:A:0): 21.738MB/s transfers (10.869MHz DT, offset 63, 16bit) (scsi0:A:0): 21.738MB/s transfers (10.869MHz, offset 63, 16bit) (scsi0:A:0): 20.832MB/s transfers (10.416MHz DT, offset 63, 16bit) (scsi0:A:0): 20.832MB/s transfers (10.416MHz, offset 63, 16bit) (scsi0:A:0): 20.000MB/s transfers (10.000MHz DT, offset 63, 16bit) (scsi0:A:0): 20.000MB/s transfers (10.000MHz, offset 63, 16bit) (scsi0:A:0): 19.230MB/s transfers (9.615MHz, offset 63, 16bit) (scsi0:A:0): 18.518MB/s transfers (9.259MHz, offset 63, 16bit) (scsi0:A:0): 17.856MB/s transfers (8.928MHz, offset 63, 16bit) (scsi0:A:0): 17.240MB/s transfers (8.620MHz, offset 63, 16bit) (scsi0:A:0): 16.666MB/s transfers (8.333MHz, offset 63, 16bit) (scsi0:A:0): 16.128MB/s transfers (8.064MHz, offset 63, 16bit) (scsi0:A:0): 15.624MB/s transfers (7.812MHz, offset 63, 16bit) (scsi0:A:0): 15.150MB/s transfers (7.575MHz, offset 63, 16bit) (scsi0:A:0): 14.704MB/s transfers (7.352MHz, offset 63, 16bit) (scsi0:A:0): 14.284MB/s transfers (7.142MHz, offset 63, 16bit) (scsi0:A:0): 13.888MB/s transfers (6.944MHz, offset 63, 16bit) (scsi0:A:0): 13.512MB/s transfers (6.756MHz, offset 63, 16bit) (scsi0:A:0): 13.156MB/s transfers (6.578MHz, offset 63, 16bit) (scsi0:A:0): 12.820MB/s transfers (6.410MHz, offset 63, 16bit) (scsi0:A:0): 12.500MB/s transfers (6.250MHz, offset 63, 16bit) (scsi0:A:0): 12.194MB/s transfers (6.097MHz, offset 63, 16bit) (scsi0:A:0): 11.904MB/s transfers (5.952MHz, offset 63, 16bit) (scsi0:A:0): 11.626MB/s transfers (5.813MHz, offset 63, 16bit) (scsi0:A:0): 11.362MB/s transfers (5.681MHz, offset 63, 16bit) (scsi0:A:0): 11.110MB/s transfers (5.555MHz, off
RE: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
>> > >> >Even for kernels with a 64bit dma_addr_t you can get 32bit dma >> >addresses >> >only. As a start check whether the pci_set_dma_mask for >the 64bit mask >> >failed - in that case you can always use 32bit SGLs. >> > >> >> Please help me understand: If dma_addr_t is 64 bit, I will get 64bit >> addresses in scatterlist regardless the outcome of pci_set_dma_mask, >> won't I? These addresses may have valid or null high >addresses. My idea >> was to have 32(64) bit SGLs for 32(64) bit dma_addr_t. > >if pci_set_dma_mask for the 64bit mask fails the upper 32bit bit of >dma_addr_t will guaranteed to be zero, so you don't need to take them >into account for your hardware SGL. > Okay. I understood. Thanks. But please consider this also: Arjan pointed out that by basing my 32/64 SGL decision solely on #define IS_DMA64 sizeof(dma_addr_t)==8, I can rely on gcc to optimize the unused portion of the code away. If I take pci_set_dma_mask also into account, I can't do that, can I? Thanks, Sreenivas - 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][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
> >Even for kernels with a 64bit dma_addr_t you can get 32bit dma >addresses >only. As a start check whether the pci_set_dma_mask for the 64bit mask >failed - in that case you can always use 32bit SGLs. > Please help me understand: If dma_addr_t is 64 bit, I will get 64bit addresses in scatterlist regardless the outcome of pci_set_dma_mask, won't I? These addresses may have valid or null high addresses. My idea was to have 32(64) bit SGLs for 32(64) bit dma_addr_t. Thanks, Sreenivas - 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 1/3] cciss: new controller support
This patch adds support for 2 new SAS controllers due out this summer.
It also bumps the version to 2.6.6.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
Documentation/cciss.txt |2 ++
drivers/block/cciss.c | 14 ++
include/linux/pci_ids.h |1 +
3 files changed, 13 insertions(+), 4 deletions(-)
---
diff -burNp lx2611.orig/Documentation/cciss.txt
lx2611-266/Documentation/cciss.txt
--- lx2611.orig/Documentation/cciss.txt 2005-03-03 13:48:36.0 -0600
+++ lx2611-266/Documentation/cciss.txt 2005-03-08 16:39:12.097839144 -0600
@@ -15,6 +15,8 @@ This driver is known to work with the fo
* SA 6400 U320 Expansion Module
* SA 6i
* SA P600
+ * SA P800
+ * SA E400
If nodes are not already created in the /dev/cciss directory, run as root:
diff -burNp lx2611.orig/drivers/block/cciss.c lx2611-266/drivers/block/cciss.c
--- lx2611.orig/drivers/block/cciss.c 2005-03-03 13:48:46.0 -0600
+++ lx2611-266/drivers/block/cciss.c2005-03-08 16:39:01.650427392 -0600
@@ -46,14 +46,14 @@
#include
#define CCISS_DRIVER_VERSION(maj,min,submin) ((maj<<16)|(min<<8)|(submin))
-#define DRIVER_NAME "HP CISS Driver (v 2.6.4)"
-#define DRIVER_VERSION CCISS_DRIVER_VERSION(2,6,4)
+#define DRIVER_NAME "HP CISS Driver (v 2.6.6)"
+#define DRIVER_VERSION CCISS_DRIVER_VERSION(2,6,6)
/* Embedded module documentation macros - see modules.h */
MODULE_AUTHOR("Hewlett-Packard Company");
-MODULE_DESCRIPTION("Driver for HP Controller SA5xxx SA6xxx version 2.6.4");
+MODULE_DESCRIPTION("Driver for HP Controller SA5xxx SA6xxx version 2.6.6");
MODULE_SUPPORTED_DEVICE("HP SA5i SA5i+ SA532 SA5300 SA5312 SA641 SA642 SA6400"
- " SA6i P600");
+ " SA6i P600 P800 E400");
MODULE_LICENSE("GPL");
#include "cciss_cmd.h"
@@ -82,6 +82,10 @@ const struct pci_device_id cciss_pci_dev
0x0E11, 0x4091, 0, 0, 0},
{ PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSA,
0x103C, 0x3225, 0, 0, 0},
+ { PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSB,
+ 0x103c, 0x3223, 0, 0, 0},
+ { PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSB,
+ 0x103c, 0x3231, 0, 0, 0},
{0,}
};
MODULE_DEVICE_TABLE(pci, cciss_pci_device_id);
@@ -103,6 +107,8 @@ static struct board_type products[] = {
{ 0x409D0E11, "Smart Array 6400 EM", &SA5_access},
{ 0x40910E11, "Smart Array 6i", &SA5_access},
{ 0x3225103C, "Smart Array P600", &SA5_access},
+ { 0x3223103C, "Smart Array P800", &SA5_access},
+ { 0x3231103C, "Smart Array E400", &SA5_access},
};
/* How long to wait (in millesconds) for board to go into simple mode */
diff -burNp lx2611.orig/include/linux/pci_ids.h
lx2611-266/include/linux/pci_ids.h
--- lx2611.orig/include/linux/pci_ids.h 2005-03-03 13:49:02.0 -0600
+++ lx2611-266/include/linux/pci_ids.h 2005-03-08 14:16:59.050059584 -0600
@@ -696,6 +696,7 @@
#define PCI_DEVICE_ID_HP_DIVA_EVEREST 0x1282
#define PCI_DEVICE_ID_HP_DIVA_AUX 0x1290
#define PCI_DEVICE_ID_HP_CISSA 0x3220
+#define PCI_DEVICE_ID_HP_CISSB 0x3230
#define PCI_VENDOR_ID_PCTECH 0x1042
#define PCI_DEVICE_ID_PCTECH_RZ10000x1000
-
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 3/3] cciss: per disk queue support
This patch adds per disk queue functionality. It seems that the 2.6 kernel
expects a queue per disk. If you have multiple logical drives on a controller
all of the queues actually point back to the same queue. If a drive is deleted
it blows us out of the water.
We hold the lock during any queue operations and have added what we call a
"fair-enough" algorithm to prevent starving out any drive.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
cciss.c | 52
cciss.h |5 +
2 files changed, 53 insertions(+), 4 deletions(-)
diff -burNp lx2611-p002/drivers/block/cciss.c lx2611-p003/drivers/block/cciss.c
--- lx2611-p002/drivers/block/cciss.c 2005-03-08 16:50:47.149175280 -0600
+++ lx2611-p003/drivers/block/cciss.c 2005-03-08 17:17:50.148441888 -0600
@@ -2090,6 +2090,9 @@ static void do_cciss_request(request_que
drive_info_struct *drv;
int i, dir;
+ /* We call start_io here in case there is a command waiting on the
+* queue that has not been sent.
+ */
if (blk_queue_plugged(q))
goto startio;
@@ -2178,6 +2181,9 @@ queue:
full:
blk_stop_queue(q);
startio:
+ /* We will already have the driver lock here so not need
+* to lock it.
+ */
start_io(h);
}
@@ -2187,7 +2193,8 @@ static irqreturn_t do_cciss_intr(int irq
CommandList_struct *c;
unsigned long flags;
__u32 a, a1;
-
+ int j;
+ int start_queue = h->next_to_run;
/* Is this interrupt for us? */
if (( h->access.intr_pending(h) == 0) || (h->interrupts_enabled == 0))
@@ -2234,13 +2241,50 @@ static irqreturn_t do_cciss_intr(int irq
}
}
- /*
-* See if we can queue up some more IO
+ /* check to see if we have maxed out the number of commands that can
+* be placed on the queue. If so then exit. We do this check here
+* in case the interrupt we serviced was from an ioctl and did not
+* free any new commands.
*/
- blk_start_queue(h->queue);
+ if ((find_first_zero_bit(h->cmd_pool_bits, NR_CMDS)) == NR_CMDS)
+ goto cleanup;
+
+ /* We have room on the queue for more commands. Now we need to queue
+* them up. We will also keep track of the next queue to run so
+* that every queue gets a chance to be started first.
+ */
+ for (j=0; j < NWD; j++){
+ int curr_queue = (start_queue + j) % NWD;
+ /* make sure the disk has been added and the drive is real
+* because this can be called from the middle of init_one.
+ */
+ if(!(h->gendisk[curr_queue]->queue) ||
+ !(h->drv[curr_queue].heads))
+ continue;
+ blk_start_queue(h->gendisk[curr_queue]->queue);
+
+ /* check to see if we have maxed out the number of commands
+* that can be placed on the queue.
+ */
+ if ((find_first_zero_bit(h->cmd_pool_bits, NR_CMDS)) == NR_CMDS)
+ {
+ if (curr_queue == start_queue){
+ h->next_to_run = (start_queue + 1) % NWD;
+ goto cleanup;
+ } else {
+ h->next_to_run = curr_queue;
+ goto cleanup;
+ }
+ } else {
+ curr_queue = (curr_queue + 1) % NWD;
+ }
+ }
+
+cleanup:
spin_unlock_irqrestore(CCISS_LOCK(h->ctlr), flags);
return IRQ_HANDLED;
}
+
/*
* We cannot read the structure directly, for portablity we must use
* the io functions.
Files lx2611-p002/drivers/block/.cciss.c.rej.swp and
lx2611-p003/drivers/block/.cciss.c.rej.swp differ
diff -burNp lx2611-p002/drivers/block/cciss.h lx2611-p003/drivers/block/cciss.h
--- lx2611-p002/drivers/block/cciss.h 2005-03-08 16:50:47.150175128 -0600
+++ lx2611-p003/drivers/block/cciss.h 2005-03-08 17:03:04.279114496 -0600
@@ -84,6 +84,11 @@ struct ctlr_info
int nr_frees;
int busy_configuring;
+ /* This element holds the zero based queue number of the last
+* queue to be started. It is used for fairness.
+ */
+ int next_to_run;
+
// Disk structures we need to pass back
struct gendisk *gendisk[NWD];
#ifdef CONFIG_CISS_SCSI_TAPE
-
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 0/6] Open-iSCSI High-Performance Initiator for Linux
On 2005-03-08T22:25:29, Alex Aizman <[EMAIL PROTECTED]> wrote: > There's (or at least was up until today) an ongoing discussion on our > mailing list at http://groups-beta.google.com/group/open-iscsi. The > short and long of it: the problem can be solved, and it will. Couple > simple things we already do: mlockall() to keep the daemon un-swapped, > and also looking into potential dependency created by syslog (there's > one for 2.4 kernel, not sure if this is an issue for 2.6). BTW, to get around the very same issues, heartbeat does much the same: lock itself into memory, reserve a couple of pages more to spare on stack & heap, run at soft-realtime priority. syslog(), however, sucks. We went down the path of using our non-blocking IPC library to have all our various components log to ha_logd, which then logs to syslog() or writes to disk or wherever. That works well in our current development series, and if you want to share code, you can either rip it off (Open Source, we love ya ;) or we can spin off these parts into a sub-package for you to depend on... > The sfnet is a learning experience; it is by no means a proof that it > cannot be done. I'd also argue that it MUST be done, because the current way of "Oh, it's somehow related to block stuff, must be in kernel" leads down to hell. We better figure out good ways around it ;-) Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business - 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][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
On Wed, Mar 09, 2005 at 09:43:47AM -0500, Bagalkote, Sreenivas wrote: > During the module load time, I allocate 32 bit or 64 bit SGLs based on > whether I can receive 64 bit DMA addresses or not. If size of dma_addr_t > is 4, then I allocate only 32 bit SGLs. During the run time, I prepare > 32/64 bit SGLs based on this variable. And since this is compile time > system-wide property, I kept it as driver global. Even for kernels with a 64bit dma_addr_t you can get 32bit dma addresses only. As a start check whether the pci_set_dma_mask for the 64bit mask failed - in that case you can always use 32bit SGLs. - 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.6.11] ide-scsi: map sg buffers in idescsi_input/output_buffers() to kernel virtual address
This patch will map the sg buffers to kernel virtual memory space in the
functions idescsi_input_buffers() and idescsi_output_buffers(). Without
this patch, idescsi passes a null pointer to atapi_input_bytes() and
atapi_output_bytes() when sg pages are in high memory (i686
architecture).
I'm attaching as a file, too, as the text will certainly be wrapped.
(Sorry for the subject rename--I'm trying to use the correct format for
patch emails.)
Thanks
Stuart
Signed-off-by: Stuart Hayes <[EMAIL PROTECTED]>
--- linux-2.6.11.orig/drivers/scsi/ide-scsi.c 2005-03-09
14:13:48.0 -0500
+++ linux-2.6.11.new/drivers/scsi/ide-scsi.c2005-03-09
13:56:38.0 -0500
@@ -143,6 +143,7 @@ static void idescsi_input_buffers (ide_d
{
int count;
char *buf;
+ unsigned long flags;
while (bcount) {
if (pc->sg - (struct scatterlist *)
pc->scsi_cmd->request_buffer > pc->scsi_cmd->use_sg) {
@@ -151,8 +152,11 @@ static void idescsi_input_buffers (ide_d
return;
}
count = min(pc->sg->length - pc->b_count, bcount);
- buf = page_address(pc->sg->page) + pc->sg->offset;
+ local_irq_save(flags);
+ buf = kmap_atomic(pc->sg->page, KM_USER0) +
pc->sg->offset;
drive->hwif->atapi_input_bytes(drive, buf + pc->b_count,
count);
+ kunmap_atomic(buf - pc->sg->offset, KM_USER0);
+ local_irq_restore(flags);
bcount -= count; pc->b_count += count;
if (pc->b_count == pc->sg->length) {
pc->sg++;
@@ -165,6 +169,7 @@ static void idescsi_output_buffers (ide_
{
int count;
char *buf;
+ unsigned long flags;
while (bcount) {
if (pc->sg - (struct scatterlist *)
pc->scsi_cmd->request_buffer > pc->scsi_cmd->use_sg) {
@@ -173,8 +178,11 @@ static void idescsi_output_buffers (ide_
return;
}
count = min(pc->sg->length - pc->b_count, bcount);
- buf = page_address(pc->sg->page) + pc->sg->offset;
+ local_irq_save(flags);
+ buf = kmap_atomic(pc->sg->page, KM_USER0) +
pc->sg->offset;
drive->hwif->atapi_output_bytes(drive, buf +
pc->b_count, count);
+ kunmap_atomic(buf - pc->sg->offset, KM_USER0);
+ local_irq_restore(flags);
bcount -= count; pc->b_count += count;
if (pc->b_count == pc->sg->length) {
pc->sg++;
ide-scsi.2.6.11.try3.patch
Description: ide-scsi.2.6.11.try3.patch
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
On Wed, Mar 09, 2005 at 11:29:03AM -0800, Bryan Henderson wrote: > I'd like to remind everyone that user space processes aside, there's still > a basic ISCSI initiator resource inversion that needs to be fixed to avoid > deadlock: > > ISCSI initiator driver sits below the memory pool > (I..e a pageout involving ISCSI might be prerequisite to getting memory) > Socket layer sits below ISCSI > (ISCSI initiator driver relies on socket services) > Memory pool sits below socket layer > (socket layer allocates memory from the main pool) > > One might say as long as that's there, close is good enough on the user > space initiator component. This issue is becoming increasingly pressing and hopefully there'll be a plan for addressing it soon. Unfortunately, none of the proposed solutions help the userspace inversion problem. -- 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: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
>The >short and long of it: the problem can be solved, and it will. Couple >simple things we already do: mlockall() to keep the daemon un-swapped, >and also looking into potential dependency created by syslog (there's >one for 2.4 kernel, not sure if this is an issue for 2.6). I think it's probably possible and good to do most of this complex stuff in user space, but it looks to me like it's going down exactly the wrong road. Its fundamental to Unix architecture that user programs sit above the kernel and get services from the kernel, and turning that on its head so that the kernel depends on a user space program to do something as fundamental as a pageout can't come to any good. Even if we're able to identify every assumption in Linux design that's being broken and patch it up with something like mlockall, tomorrow someone will change something, using his vast experience with engineering user space programs, and break it again. Maybe a more important point is that to the extent that you make a user space process a proxy of the kernel, you lose all those advantages that are supposed to come with user space engineering: you can now totally hose your system by making a mistake in the code; you have to be intimately familiar with kernel internals to get the code right, etc. mlockall is meant to provide performance characteristics to a user space process. If it can be used to create resource ordering correctness, it's an accident. Syslog is one of those things you're not supposed to have to think about. If every time you issue a message you have to visualize the entire syslog system with all of its options to know if you've broken something, the simplicity of user space is gone. I would think as a basic design principle that if kernel code ever has to wait for a user process to do something, it should do it high in a system call, in user context, interruptibly, etc. I don't know if it's possible to arrange to have the ISCSI initiator waiting there, but I think it's the only way having a user space process can do what it's supposed to do. I'd like to remind everyone that user space processes aside, there's still a basic ISCSI initiator resource inversion that needs to be fixed to avoid deadlock: ISCSI initiator driver sits below the memory pool (I..e a pageout involving ISCSI might be prerequisite to getting memory) Socket layer sits below ISCSI (ISCSI initiator driver relies on socket services) Memory pool sits below socket layer (socket layer allocates memory from the main pool) One might say as long as that's there, close is good enough on the user space initiator component. -- Bryan Henderson San Jose California IBM Almaden Research Center Filesystems - 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 1/1] Whitelist-Entry (FORCELUN) for SGS Thomson Microelectronics Cytronix 6in1 card reader in scsi_devinfo.c
On Wed, Mar 09, 2005 at 01:03:32AM -0800, Andrew Morton wrote: > > From: Hanno Boeck <[EMAIL PROTECTED]> > > I have a usb-cardreader here that needs some FORCELUN-entries in > scsi_devinfo.c. > > lsusb says about the device: > > Bus 001 Device 003: ID 0483:1307 SGS Thomson Microelectronics Cytronix 6in1 > card reader > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> The problem with these devices is there are so many of them, (The Fedora kernel had over a dozen additions to the whitelist at one point), and there were still devices getting reported that weren't detected. There's no way to stay on top of the amount of these things that are being produced. There are only two sane solutions that I see 1) Have usb-storage tell the scsi layer "Its a card reader, scan all luns" or 2) enable scanning of all luns, and blacklist any devices that misbehave. I chose (2) in the Fedora kernel, and so far, only 1 device got picked up that needed adding to the blacklist. Dave - 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: How does a SCSI device gets a target ID?
It's not clear what you're asking. You start off with the question >When a new SCSI device is added to a SCSI channel, how can we find out what >is the target ID of that device? That's clear enough, except I don't know who "we" is. Depending on who you are, i.e. from what perspective you're looking, you would get this information differently. But then you give two hypotheses that describe how a device comes to have its target ID, not how someone finds out what target ID it has. >1) If a channel supports 8 SCSI devices, then each of the 8 ports will have >a specific Target ID. And any device attached to that port will have that >Target ID. >2) Is it done one the fly? I mean (starting from zero), the SCSI device is >given a target ID that is 1 greater that the last SCSI device's ID. Who >assigns this ID? Others have read a particular question into your question and answered it, but it might not be what you were looking for. Let me give a shot at answering a few of the questions that it might be: A device traditionally gets its target ID from a physical switch on the device. The person who installs the device sets the switch and can tell the target ID by looking at it the switch. That person chooses the target IDs to be anything he wants, but makes sure that no two devices plugged into the same bus have the same target ID. In modern times, some devices (disk devices, anyway) get their target ID by being plugged into a backplane or cable in a certain place. In that case, you can tell the target ID by noting where it's plugged in and knowing how the thing you plugged it into is configured. SCA is one standard for allowing this kind of target ID assignment. Some devices even get their target IDs dynamically with SCAM, but I don't know anything about SCAM. If you're inside the computer and trying to figure out what target ID an attached device has, all you can do is search the namespace. You try each target ID and if a device answers, you can ask it for information about itself (model, serial number, etc.). But you don't necessarily ever know what target ID a particular device has -- you just know that there exists a device with a certain target ID. At various levels of Linux, matching up target IDs with devices is done via various interfaces, most of them quite tortured. - 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: ide-scsi oops with ide tape drive
> Hayes, Stuart wrote:
>> Jens Axboe wrote:
>>> On Tue, Mar 08 2005, [EMAIL PROTECTED] wrote:
Hello!
We're seeing a null pointer dereference with certain IDE tape
drives on
2.6.11 when we use it with ide-scsi (i686 architecture). The
problem is that the scatter-gather pages aren't mapped to kernel
virtual address space in
idescsi_output_buffers()/idescsi_input_buffers(), so, if these
pages are in high memory, page_address() returns a null pointer.
This patch fixes the problem. I'll attach it as a file, too, just
in case it gets mangled. Please let me know if there are any
problems with or questions regarding this patch.
Again, this patch is against 2.6.11.
Thanks!
Stuart Hayes
[EMAIL PROTECTED]
--- ide-scsi.c.orig2005-03-08 13:44:38.0 -0500
+++ ide-scsi.c 2005-03-08 14:02:43.0 -0500
@@ -151,8 +151,9 @@ static void idescsi_input_buffers (ide_d
return; } count = min(pc->sg->length - pc->b_count,
bcount);
- buf = page_address(pc->sg->page) + pc->sg->offset;
+ buf = kmap_atomic(pc->sg->page, KM_USER0) +
pc->sg->offset;
drive->hwif->atapi_input_bytes(drive, buf + pc->b_count,
count);
+ kunmap_atomic(buf - pc->sg->offset, KM_USER0);
bcount -= count; pc->b_count += count;
if (pc->b_count == pc->sg->length) {
pc->sg++;
>>>
>>> You need a local_irq_save(flags); ... local_irq_restore(flags);
>>> around the kmap(atomic), transfer, and kunmap_atomic() for this to
>>> be safe. Interrupts may not be disabled at this point, depends on
>>> drive settings.
>>>
>>
>> Thanks for the quick response! I'll look into this more carefully.
>> --Stuart
>>
>
> Oh, yeah, unmaskirq...
>
> Do you see any problem with masking local IRQs during the transfer?
> If unmask is set, it could be because the device is a slow PIO
> device, so transferring a whole page could take over 2.5ms.
>
> I could check, and if unmask is set && the page is in high memory, I
> could copy the page down to low memory and allow the transfer to the
> drive to proceed with irqs unmasked. Do you think it would be worth
> the extra code complexity?
>
> Thanks
> Stuart
>
>
Oops, it's a worst case of ~1.2ms, not 2.5ms. I guess that would be OK.
I'll rework the patch and send it again in a bit.
@@ -173,8 +174,9 @@ static void idescsi_output_buffers (ide_
return; } count = min(pc->sg->length - pc->b_count,
bcount);
- buf = page_address(pc->sg->page) + pc->sg->offset;
+ buf = kmap_atomic(pc->sg->page, KM_USER0) +
pc->sg->offset;
drive->hwif->atapi_output_bytes(drive, buf +
pc->b_count, count);
+ kunmap_atomic(buf - pc->sg->offset, KM_USER0);
bcount -= count; pc->b_count += count;
if (pc->b_count == pc->sg->length) {
pc->sg++;
>>>
>>> Ditto.
-
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][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
On Wed, 2005-03-09 at 12:44 -0500, Bagalkote, Sreenivas wrote: > >> > > >> >> . And since this is compile time > >> >> system-wide property, I kept it as driver global. > >> > > >> >that step I don't understand... why is it a global > >*VARIABLE* if it's > >> >compile time system-wide property... > >> > > >> > >> I see your point! Are you saying I should use > >if(sizeof(dma_addr_t)==8) > >> instead of the shortcut if(is_dma64)? > >yep > >well you can use a preprocessor define of something to make it slightly > >more readable (eg shortcut) if you want, but that's what I mean yeah.. > > > >gcc will optimize the entire unused code away this way, including the > >actual conditional jump, so for performance and bloat-ness > >point of view > >it's nice and of course generic design beauty ;) > > > > Great. Thanks! I will change it. If I understand you correctly, I should > #define IS_DMA64 (sizeof(dma_addr_t)==8). that's one way to do it yeah. > > Is this better than declaring is_dma64 global variable const? (Excuse the > oxymoron). in C yes; in C "const" doesn't quite mean what you want it to mean with this and as a result gcc I think can't optimize this the way it can with the define. - 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][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
>> > >> >> . And since this is compile time >> >> system-wide property, I kept it as driver global. >> > >> >that step I don't understand... why is it a global >*VARIABLE* if it's >> >compile time system-wide property... >> > >> >> I see your point! Are you saying I should use >if(sizeof(dma_addr_t)==8) >> instead of the shortcut if(is_dma64)? >yep >well you can use a preprocessor define of something to make it slightly >more readable (eg shortcut) if you want, but that's what I mean yeah.. > >gcc will optimize the entire unused code away this way, including the >actual conditional jump, so for performance and bloat-ness >point of view >it's nice and of course generic design beauty ;) > Great. Thanks! I will change it. If I understand you correctly, I should #define IS_DMA64 (sizeof(dma_addr_t)==8). Is this better than declaring is_dma64 global variable const? (Excuse the oxymoron). - 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: How does a SCSI device gets a target ID?
On Wed, Mar 09, 2005 at 11:54:57AM -0500, Guy wrote: > A narrow SCSI bus will support 8 devices. > A wide SCSI bus will support 16 devices. > A narrow bus uses 50 pins. > A wide bus uses 68 pins. We need a SCSI Wiki for all this kind of information ... maybe Wikipedia? > There is a standard for auto selecting the SCSI ID. I have never used this. > SCAM (SCSI Configures Auto Magically). I think the SCSI vendors prefer to sell SCA drives rather than SCAM drives ;-) Drives with the SCA connector have power supplied to them and their SCSI ID configured automatically depending on which slot they're plugged into. If you're doing hotplug SCSI, it's probably with SCA drives. > Mixing devices with different electrical standards can be tricky. Some > can't be mixed. HVD is not compatible with any other. And plugging any SE devince onto an LVD bus causes the whole bus to fall back to SE. This includes terminators. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - 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] SCSI: Add TASK_ABORTED to status_byte macro
Here is a refresh of an update to the status_byte macro.
Previous mail
http://marc.theaimsgroup.com/?l=linux-scsi&m=110322214824566&w=2
-andmike
--
Michael Anderson
[EMAIL PROTECTED]
Add TASK_ABORTED and ACA_ACTIVE to status_byte macro.
Signed-off-by: Mike Anderson <[EMAIL PROTECTED]>
---
linux-2.6.11-andmike/drivers/scsi/scsi_error.c |2 ++
linux-2.6.11-andmike/include/scsi/scsi.h |6 --
2 files changed, 6 insertions(+), 2 deletions(-)
diff -puN drivers/scsi/scsi_error.c~tsk_abrt drivers/scsi/scsi_error.c
--- linux-2.6.11/drivers/scsi/scsi_error.c~tsk_abrt 2005-03-07
15:29:09.0 -0800
+++ linux-2.6.11-andmike/drivers/scsi/scsi_error.c 2005-03-07
15:29:09.0 -0800
@@ -1373,6 +1373,7 @@ int scsi_decide_disposition(struct scsi_
return ADD_TO_MLQUEUE;
case GOOD:
case COMMAND_TERMINATED:
+ case TASK_ABORTED:
return SUCCESS;
case CHECK_CONDITION:
rtn = scsi_check_sense(scmd);
@@ -1386,6 +1387,7 @@ int scsi_decide_disposition(struct scsi_
case CONDITION_GOOD:
case INTERMEDIATE_GOOD:
case INTERMEDIATE_C_GOOD:
+ case ACA_ACTIVE:
/*
* who knows? FIXME(eric)
*/
diff -puN include/scsi/scsi.h~tsk_abrt include/scsi/scsi.h
--- linux-2.6.11/include/scsi/scsi.h~tsk_abrt 2005-03-07 15:29:09.0
-0800
+++ linux-2.6.11-andmike/include/scsi/scsi.h2005-03-07 15:29:09.0
-0800
@@ -169,8 +169,10 @@ static inline int scsi_status_is_good(in
#define RESERVATION_CONFLICT 0x0c
#define COMMAND_TERMINATED 0x11
#define QUEUE_FULL 0x14
+#define ACA_ACTIVE 0x18
+#define TASK_ABORTED 0x20
-#define STATUS_MASK 0x3e
+#define STATUS_MASK 0xfe
/*
* SENSE KEYS
@@ -348,7 +350,7 @@ struct scsi_lun {
* host_byte = set by low-level driver to indicate status.
* driver_byte = set by mid-level.
*/
-#define status_byte(result) (((result) >> 1) & 0x1f)
+#define status_byte(result) (((result) >> 1) & 0x7f)
#define msg_byte(result)(((result) >> 8) & 0xff)
#define host_byte(result) (((result) >> 16) & 0xff)
#define driver_byte(result) (((result) >> 24) & 0xff)
_
-
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: ide-scsi oops with ide tape drive
Hayes, Stuart wrote:
> Jens Axboe wrote:
>> On Tue, Mar 08 2005, [EMAIL PROTECTED] wrote:
>>>
>>> Hello!
>>>
>>> We're seeing a null pointer dereference with certain IDE tape
>>> drives on
>>> 2.6.11 when we use it with ide-scsi (i686 architecture). The
>>> problem is that the scatter-gather pages aren't mapped to kernel
>>> virtual address space in
>>> idescsi_output_buffers()/idescsi_input_buffers(), so, if these
>>> pages are in high memory, page_address() returns a null pointer.
>>>
>>> This patch fixes the problem. I'll attach it as a file, too, just
>>> in case it gets mangled. Please let me know if there are any
>>> problems with or questions regarding this patch.
>>>
>>> Again, this patch is against 2.6.11.
>>>
>>> Thanks!
>>> Stuart Hayes
>>> [EMAIL PROTECTED]
>>>
>>>
>>>
>>> --- ide-scsi.c.orig 2005-03-08 13:44:38.0 -0500
>>> +++ ide-scsi.c 2005-03-08 14:02:43.0 -0500
>>> @@ -151,8 +151,9 @@ static void idescsi_input_buffers (ide_d
>>> return; } count = min(pc->sg->length - pc->b_count,
bcount);
>>> - buf = page_address(pc->sg->page) + pc->sg->offset;
>>> + buf = kmap_atomic(pc->sg->page, KM_USER0) +
>>> pc->sg->offset;
>>> drive->hwif->atapi_input_bytes(drive, buf + pc->b_count,
count);
>>> + kunmap_atomic(buf - pc->sg->offset, KM_USER0);
>>> bcount -= count; pc->b_count += count;
>>> if (pc->b_count == pc->sg->length) {
>>> pc->sg++;
>>
>> You need a local_irq_save(flags); ... local_irq_restore(flags);
>> around the kmap(atomic), transfer, and kunmap_atomic() for this to
>> be safe. Interrupts may not be disabled at this point, depends on
>> drive settings.
>>
>
> Thanks for the quick response! I'll look into this more carefully.
> --Stuart
>
Oh, yeah, unmaskirq...
Do you see any problem with masking local IRQs during the transfer? If
unmask is set, it could be because the device is a slow PIO device, so
transferring a whole page could take over 2.5ms.
I could check, and if unmask is set && the page is in high memory, I
could copy the page down to low memory and allow the transfer to the
drive to proceed with irqs unmasked. Do you think it would be worth the
extra code complexity?
Thanks
Stuart
>>> @@ -173,8 +174,9 @@ static void idescsi_output_buffers (ide_
>>> return; } count = min(pc->sg->length - pc->b_count,
bcount);
>>> - buf = page_address(pc->sg->page) + pc->sg->offset;
>>> + buf = kmap_atomic(pc->sg->page, KM_USER0) +
>>> pc->sg->offset;
>>> drive->hwif->atapi_output_bytes(drive, buf +
>>> pc->b_count, count);
>>> + kunmap_atomic(buf - pc->sg->offset, KM_USER0);
>>> bcount -= count; pc->b_count += count;
>>> if (pc->b_count == pc->sg->length) {
>>> pc->sg++;
>>
>> Ditto.
-
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][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
On Wed, 2005-03-09 at 11:01 -0500, Bagalkote, Sreenivas wrote: > > > >> . And since this is compile time > >> system-wide property, I kept it as driver global. > > > >that step I don't understand... why is it a global *VARIABLE* if it's > >compile time system-wide property... > > > > I see your point! Are you saying I should use if(sizeof(dma_addr_t)==8) > instead of the shortcut if(is_dma64)? yep well you can use a preprocessor define of something to make it slightly more readable (eg shortcut) if you want, but that's what I mean yeah.. gcc will optimize the entire unused code away this way, including the actual conditional jump, so for performance and bloat-ness point of view it's nice and of course generic design beauty ;) - 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: How does a SCSI device gets a target ID?
A narrow SCSI bus will support 8 devices. A wide SCSI bus will support 16 devices. A narrow bus uses 50 pins. A wide bus uses 68 pins. The SCSI card is a device, normally ID 7. The SCSI ID is configured on the device. You will need to look at the manual, some devices may have cryptic notes on the device. Each device must have a unique ID. There is a standard for auto selecting the SCSI ID. I have never used this. SCAM (SCSI Configures Auto Magically). The below speeds assume wide, divide by 2 is narrow. There are many electrical standards. SE - Single ended (20M/s) DF (HVD) High voltage differential (20M/s) U Ultra (40M/s) U2 (LVD, U-80, Ultra 2) Low voltage differential (80M/s) U-160 Ultra 160 (160M/s) U-320 Ultra 320 (320M/s) U-640 Ultra 640 (640M/s) Not sure this is a standard yet. Mixing devices with different electrical standards can be tricky. Some can't be mixed. HVD is not compatible with any other. Both ends of the SCSI bus must be terminated. Some devices have an internal terminator that can be enabled or disabled. The SCSI card normally is a terminator. 1 device must supply terminator power. I believe it is ok if more than 1 device supplies terminator power, but not sure. Normally the SCSI card supplies terminator power. I hope this answers your questions! :) This link may help, but it is very out of date. It stops at Ultra http://www.adaptec.com/worldwide/support/supporteditorial.jsp?sess=no&langua ge=English+US&prodkey=SCSI_glossary Guy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajat Jain, Noida Sent: Wednesday, March 09, 2005 11:04 AM To: linux-scsi@vger.kernel.org Subject: How does a SCSI device gets a target ID? Hi, I'm new to SCSI. I would appreciate if some one can solve my query: When a new SCSI device is added to a SCSI channel, how can we find out what is the target ID of that device? 1) If a channel supports 8 SCSI devices, then each of the 8 ports will have a specific Target ID. And any device attached to that port will have that Target ID. 2) Is it done one the fly? I mean (starting from zero), the SCSI device is given a target ID that is 1 greater that the last SCSI device's ID. Who assigns this ID? TIA, Rajat - 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 - 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: ide-scsi oops with ide tape drive
Jens Axboe wrote:
> On Tue, Mar 08 2005, [EMAIL PROTECTED] wrote:
>>
>> Hello!
>>
>> We're seeing a null pointer dereference with certain IDE tape drives
>> on
>> 2.6.11 when we use it with ide-scsi (i686 architecture). The
>> problem is that the scatter-gather pages aren't mapped to kernel
>> virtual address space in
>> idescsi_output_buffers()/idescsi_input_buffers(), so, if these pages
>> are in high memory, page_address() returns a null pointer.
>>
>> This patch fixes the problem. I'll attach it as a file, too, just in
>> case it gets mangled. Please let me know if there are any problems
>> with or questions regarding this patch.
>>
>> Again, this patch is against 2.6.11.
>>
>> Thanks!
>> Stuart Hayes
>> [EMAIL PROTECTED]
>>
>>
>>
>> --- ide-scsi.c.orig 2005-03-08 13:44:38.0 -0500
>> +++ ide-scsi.c 2005-03-08 14:02:43.0 -0500
>> @@ -151,8 +151,9 @@ static void idescsi_input_buffers (ide_d
>> return; }
>> count = min(pc->sg->length - pc->b_count, bcount);
>> -buf = page_address(pc->sg->page) + pc->sg->offset;
>> +buf = kmap_atomic(pc->sg->page, KM_USER0) +
>> pc->sg->offset;
>> drive->hwif->atapi_input_bytes(drive, buf + pc->b_count,
>> count);
>> +kunmap_atomic(buf - pc->sg->offset, KM_USER0);
>> bcount -= count; pc->b_count += count;
>> if (pc->b_count == pc->sg->length) {
>> pc->sg++;
>
> You need a local_irq_save(flags); ... local_irq_restore(flags); around
> the kmap(atomic), transfer, and kunmap_atomic() for this to be safe.
> Interrupts may not be disabled at this point, depends on drive
> settings.
>
Thanks for the quick response! I'll look into this more carefully.
--Stuart
>> @@ -173,8 +174,9 @@ static void idescsi_output_buffers (ide_
>> return; }
>> count = min(pc->sg->length - pc->b_count, bcount);
>> -buf = page_address(pc->sg->page) + pc->sg->offset;
>> +buf = kmap_atomic(pc->sg->page, KM_USER0) +
>> pc->sg->offset;
>> drive->hwif->atapi_output_bytes(drive, buf +
>> pc->b_count, count);
>> +kunmap_atomic(buf - pc->sg->offset, KM_USER0);
>> bcount -= count; pc->b_count += count;
>> if (pc->b_count == pc->sg->length) {
>> pc->sg++;
>
> Ditto.
-
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][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
> >> . And since this is compile time >> system-wide property, I kept it as driver global. > >that step I don't understand... why is it a global *VARIABLE* if it's >compile time system-wide property... > I see your point! Are you saying I should use if(sizeof(dma_addr_t)==8) instead of the shortcut if(is_dma64)? Are you thinking of "const" modifier? Please advice. - 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
How does a SCSI device gets a target ID?
Hi, I'm new to SCSI. I would appreciate if some one can solve my query: When a new SCSI device is added to a SCSI channel, how can we find out what is the target ID of that device? 1) If a channel supports 8 SCSI devices, then each of the 8 ports will have a specific Target ID. And any device attached to that port will have that Target ID. 2) Is it done one the fly? I mean (starting from zero), the SCSI device is given a target ID that is 1 greater that the last SCSI device's ID. Who assigns this ID? TIA, Rajat - 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 1/1] Whitelist-Entry (FORCELUN) for SGS Thomson Microelectronics Cytronix 6in1 card reader in scsi_devinfo.c
On Wed, Mar 09, 2005 at 01:03:32AM -0800, [EMAIL PROTECTED] wrote: > > From: Hanno Boeck <[EMAIL PROTECTED]> > > I have a usb-cardreader here that needs some FORCELUN-entries in > scsi_devinfo.c. > Hanno - Instead of the patch, try running with CONFIG_SCSI_MULTI_LUN enabled. -- Patrick Mansfield - 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][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
> . And since this is compile time > system-wide property, I kept it as driver global. that step I don't understand... why is it a global *VARIABLE* if it's compile time system-wide property... - 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][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
>> >> I will make this an instance parameter if the idea to reduce as many >> global variables as possible. But if the objection is because each >> adapter >> may have different value for variable, then it is indeed a global >> value. >> "is_dma64" - which is computed using the size of dma_addr_t - is >> telling >> something about the kernel rather than the controller feature. >> > >then having it as variable sounds really really wrong; the size of >dma_addr_t is a compile time property... >(and why do you care about it? you see high dma addresses when >they come >in, right?) > During the module load time, I allocate 32 bit or 64 bit SGLs based on whether I can receive 64 bit DMA addresses or not. If size of dma_addr_t is 4, then I allocate only 32 bit SGLs. During the run time, I prepare 32/64 bit SGLs based on this variable. And since this is compile time system-wide property, I kept it as driver global. - 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][PATCH 2.6.11 1/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
>> > >> >> source "drivers/scsi/megaraid/Kconfig.megaraid" >> >> +source "drivers/scsi/megaraid/Kconfig.megaraid_sas" >> >> >> > >> >why a fully separate file and not add your ONE config option to >> >Kconfig.megaraid instead ?? >> > >> >> Arjan, I didn't want to needlessly couple megaraid and megaraid_sas. >> Since they are in the same directory, I couldn't avoid having single >> Makefile. I thought at least these two should be separate to >be consistent >> with their independent nature. >> >> If this is not a good enough reason, I will merge these two files. > >Please merge them. > >Whether they are in the same Kconfig file or not does not in any way >imply any relation between them. > >E.g. drivers/scsi/Kconfig contains many drivers that are not >in any way >coupled to each other. > Understood. I will merge them. > >BTW: Why does the text say "(New Driver)"? > I thought I saw some new modules being labeled as such. I will remove it in the next update if it not correct. >-- > > "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 > There is a 30% chance of rain here today. Thanks, Sreenivas LSI Logic Corporation - 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] adding per scsi-host workqueues for defered processing
[EMAIL PROTECTED] wrote: > So, is there a reason we aren't just starting the workq thread > upon the first call to queue something to it ? Don't you need to be at task level to create a workq thread? -Brian > -- james s > > >>-Original Message- >>From: Luben Tuikov [mailto:[EMAIL PROTECTED] >>Sent: Tuesday, March 08, 2005 8:12 AM >>To: Andrew Vasquez >>Cc: Smart, James; linux-scsi@vger.kernel.org >>Subject: Re: [RFC] adding per scsi-host workqueues for defered >>processing >> >> >>On 03/08/05 02:00, Andrew Vasquez wrote: >> >>>There were some background tasks I shelved until the remote-ports >>>stuff settled down which I thought could use the deferred processing >>>thread: >>> >>>* Initiate LIP -- several customers have asked for this ability as >>> several topological configurations isolate disruptive FC events. >>>* Initiate LLDD rescan (i.e. ports (fibre channel), devices (iSCSI), >>> etc.) >>> >>>I had originally envisioned these functions residing in the >> >>transport. >> >>Yes, I agree. Domain (target, topology, etc) discovery should be >>"part" of the transport class. >> >>What I'm thinking of is that the LLDD would register a known >>trasport class with the SCSI Core at/after registering a host >>template and then would call something with a name like >>"start_scsi" which would do whatever necessary for the domain >>(SAS, FC, iSCSI, etc) before scanning for targets. Of course >>for some domains no additional work is needed. >> >> Luben >> > > - > 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 > -- Brian King eServer Storage I/O IBM Linux Technology Center - 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] mac_scsi boot crash fix
> Kenn, my macs like your patch :-) Did it make it upstream? Yes. http://linux-scsi.bkbits.net:8080/scsi-misc-2.6/[EMAIL PROTECTED] xrPCoj1REg?nav=index.html|[EMAIL PROTECTED] Later, Kenn - 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] mac_scsi boot crash fix
I found the bus error, the trivial fix is below.
I don't know if this patch will work for others quite yet, since my kernel
has had some work done to slow interrupt handling. I intend to post that
patch soon.
On Tue, 8 Mar 2005, Brad Boyer wrote:
> I notice it got through all the device identify stuff. It dies as soon
> as it actually tries to tranfer a real block of data (the partition map)
> and do something useful with it. Could you see if disabling PDMA helps?
I tested both: my Daystar Mac II now works great with or without PDMA, so
hopefully the IIfx will work too.
Kenn, my macs like your patch :-) Did it make it upstream?
-f
Signed-off-by: Finn Thain <[EMAIL PROTECTED]>
--- a/drivers/scsi/mac_scsi.c 2005-03-09 22:21:01.369397570 +1100
+++ b/drivers/scsi/mac_scsi.c 2005-03-09 22:02:12.594082086 +1100
@@ -302,7 +302,7 @@ int macscsi_detect(Scsi_Host_Template *
if (instance->irq != SCSI_IRQ_NONE)
if (request_irq(instance->irq, NCR5380_intr, IRQ_FLG_SLOW,
- "ncr5380", NCR5380_intr)) {
+ "ncr5380", instance)) {
printk(KERN_WARNING "scsi%d: IRQ%d not free, interrupts disabled\n",
instance->host_no, instance->irq);
instance->irq = SCSI_IRQ_NONE;
-
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 1/1] Whitelist-Entry (FORCELUN) for SGS Thomson Microelectronics Cytronix 6in1 card reader in scsi_devinfo.c
From: Hanno Boeck <[EMAIL PROTECTED]>
I have a usb-cardreader here that needs some FORCELUN-entries in
scsi_devinfo.c.
lsusb says about the device:
Bus 001 Device 003: ID 0483:1307 SGS Thomson Microelectronics Cytronix 6in1
card reader
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/scsi/scsi_devinfo.c |4
1 files changed, 4 insertions(+)
diff -puN
drivers/scsi/scsi_devinfo.c~whitelist-entry-forcelun-for-sgs-thomson-microelectronics-cytronix-6in1-card-reader-in-scsi_devinfoc
drivers/scsi/scsi_devinfo.c
---
25/drivers/scsi/scsi_devinfo.c~whitelist-entry-forcelun-for-sgs-thomson-microelectronics-cytronix-6in1-card-reader-in-scsi_devinfoc
2005-03-09 01:03:19.0 -0800
+++ 25-akpm/drivers/scsi/scsi_devinfo.c 2005-03-09 01:03:19.0 -0800
@@ -149,6 +149,10 @@ static struct {
{"Generic", "USB SD Reader", "1.00", BLIST_FORCELUN | BLIST_INQUIRY_36},
{"Generic", "USB Storage-SMC", "0180", BLIST_FORCELUN |
BLIST_INQUIRY_36},
{"Generic", "USB Storage-SMC", "0207", BLIST_FORCELUN |
BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-SMC", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-CF", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-SD", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"Generic", "USB Reader-MS", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
{"HITACHI", "DF400", "*", BLIST_SPARSELUN},
{"HITACHI", "DF500", "*", BLIST_SPARSELUN},
{"HITACHI", "DF600", "*", BLIST_SPARSELUN},
_
-
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: ide-scsi oops with ide tape drive
On Tue, Mar 08 2005, [EMAIL PROTECTED] wrote:
>
> Hello!
>
> We're seeing a null pointer dereference with certain IDE tape drives on
> 2.6.11 when we use it with ide-scsi (i686 architecture). The problem is
> that the scatter-gather pages aren't mapped to kernel virtual address
> space in idescsi_output_buffers()/idescsi_input_buffers(), so, if these
> pages are in high memory, page_address() returns a null pointer.
>
> This patch fixes the problem. I'll attach it as a file, too, just in
> case it gets mangled. Please let me know if there are any problems with
> or questions regarding this patch.
>
> Again, this patch is against 2.6.11.
>
> Thanks!
> Stuart Hayes
> [EMAIL PROTECTED]
>
>
>
> --- ide-scsi.c.orig 2005-03-08 13:44:38.0 -0500
> +++ ide-scsi.c2005-03-08 14:02:43.0 -0500
> @@ -151,8 +151,9 @@ static void idescsi_input_buffers (ide_d
> return;
> }
> count = min(pc->sg->length - pc->b_count, bcount);
> - buf = page_address(pc->sg->page) + pc->sg->offset;
> + buf = kmap_atomic(pc->sg->page, KM_USER0) +
> pc->sg->offset;
> drive->hwif->atapi_input_bytes(drive, buf + pc->b_count,
> count);
> + kunmap_atomic(buf - pc->sg->offset, KM_USER0);
> bcount -= count; pc->b_count += count;
> if (pc->b_count == pc->sg->length) {
> pc->sg++;
You need a local_irq_save(flags); ... local_irq_restore(flags); around
the kmap(atomic), transfer, and kunmap_atomic() for this to be safe.
Interrupts may not be disabled at this point, depends on drive settings.
> @@ -173,8 +174,9 @@ static void idescsi_output_buffers (ide_
> return;
> }
> count = min(pc->sg->length - pc->b_count, bcount);
> - buf = page_address(pc->sg->page) + pc->sg->offset;
> + buf = kmap_atomic(pc->sg->page, KM_USER0) +
> pc->sg->offset;
> drive->hwif->atapi_output_bytes(drive, buf +
> pc->b_count, count);
> + kunmap_atomic(buf - pc->sg->offset, KM_USER0);
> bcount -= count; pc->b_count += count;
> if (pc->b_count == pc->sg->length) {
> pc->sg++;
Ditto.
--
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
RE: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
On Tue, 2005-03-08 at 18:08 -0500, Bagalkote, Sreenivas wrote: > > I will make this an instance parameter if the idea to reduce as many > global variables as possible. But if the objection is because each > adapter > may have different value for variable, then it is indeed a global > value. > "is_dma64" - which is computed using the size of dma_addr_t - is > telling > something about the kernel rather than the controller feature. > then having it as variable sounds really really wrong; the size of dma_addr_t is a compile time property... (and why do you care about it? you see high dma addresses when they come in, right?) - 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
