Re: [PATCH 2.6.11] ide-scsi: map sg buffers in idescsi_input/output_buffers() to kernel virtual address
On Thu, Mar 17 2005, [EMAIL PROTECTED] wrote: Jens Axboe wrote: On Thu, Mar 17 2005, Jens Axboe wrote: On Thu, Mar 17 2005, [EMAIL PROTECTED] wrote: Jens Axboe wrote: On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote: Jens Axboe wrote: On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote: Hayes, Stuart wrote: 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 And, while there's another high memory/kmap patch question on this list... Is there some reason nobody seems interested in this patch (except Jens--thanks for the help!)? I'm kind of new to sending in patches, and I'm not sure if I'm just not waiting long enough, or if there is a problem with this patch... But really, we're getting a null pointer dereference oops when using ATAPI tape drives (with ide-scsi) without this patch... Sorry, that did seem to get dropped on the floor. Actually I'm wondering why you are seeing highmem pages there in the first place, it would be easier/better just to limit ide-scsi to non-highmem pages. That would remove the need to add any work arounds in the driver. I think we're seeing highmem pages in the sg list because that's where the user memory was when st_write() was called. The sg list is set up when st_write(), which calls setup_buffering(), which calls st_map_user_pages()... this just sets up the sg pages to point directly to the user memory. So, by the time ide-scsi comes into the picture, the sg list is already set up to point to high memory pages. Are you suggesting that ide-scsi should change the dma_mask for the device so that st_map_user_pages() won't let sg pages point to high memory? Or is there something else I'm missing? I think that is a bug, this effectively bypasses whatever restrictions the scsi host adapter has said about memory limits. It is a problem because the request doesn't come from the block layer (which handles all of this). I would much prefer fixing that real issue! By whatever restrictions the scsi host adapter has said about memory limits, are you referring to the dma_boundary or the dma_mask? I'm don't know any other ways a host adapter can specify memory limits. I wasn't complete in my statement above, though--st_map_user_pages() does prevent the sg list from pointing to pages that are above the max_pfn for the device (it gets max_pfn from scsi_calculate_bounce_ limit()), and that appears to be working ok. But, even though max_pfn is 0xf (so that the maximum physical address of any sg page won't be over 4G (0x)), there are apparently high memory pages that are below physical address of 4G (0x), but are still considered high memory. So the entire first 4G of memory isn't low memory... for example, on my box, pfn 0xfbc3c, with physical address 0xfbc3c000, has the PG_highmem bit set in (page)-flags. Because of this, when ide-scsi needs to do PIO, it needs to do a kmap_atomic(). Am I completely missing your point? Ok good, so st isn't broken at least. You are not missing my point, but maybe you don't realize that highmem pages doesn't refer to any specific address in memory - it refers to pages that don't have a virtual mapping, so depending on the kernel config that can be anywhere between ~900MB and 2GB (typicall). ide-scsi should just use blk_max_low_pfn as the bounce limit, that will work all the time. IOW, one way to solve this would be to add an shost-bounce_high flag and add something ala if (shost-bounce_high) return BLK_BOUNCE_HIGH; to scsi_calculate_bounce_limit() Yes, I could easily implement that. I had been trying to figure out how to go about implementing what you said--I was looking at making idescsi_attach change the dma_mask that scsi_calculate_bounce_limit() currently looks at, but it wasn't looking very pretty. Unfortunately, I won't be able to do that fix with a DKMS driver on an existing kernel... but that's not really relevant to this list. For your existing kernel fix, just use the one you sent last using kmap_atomic, it should work for you as well. I'll try this out and send in a patch. Thanks! No problem, thanks for being persistent in getting this fixed :) -- 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
queue - sdev reference counting problem
Hi,
There is a problem with the way sdev is freed currently. The reason is
really that there is a circular referencing problem: the sdev needs to
hold on to the queue, but the queue (through the request function) also
needs to hold on to the sdev.
The easiest way to work-around this problem is to kill the sdev
reference in the queue when the sdev is freed. On invocation of
scsi_request_fn(), kill io to this device.
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
= drivers/scsi/scsi_lib.c 1.151 vs edited =
--- 1.151/drivers/scsi/scsi_lib.c 2005-02-17 20:17:22 +01:00
+++ edited/drivers/scsi/scsi_lib.c 2005-03-18 12:33:09 +01:00
@@ -1233,6 +1233,22 @@ static inline int scsi_host_queue_ready(
}
/*
+ * Kill requests for a dead device
+ */
+static void scsi_kill_requests(request_queue_t *q)
+{
+ struct request *req;
+
+ while ((req = elv_next_request(q)) != NULL) {
+ blkdev_dequeue_request(req);
+ req-flags |= REQ_QUIET;
+ while (end_that_request_first(req, 0, req-nr_sectors))
+ ;
+ end_that_request_last(req);
+ }
+}
+
+/*
* Function:scsi_request_fn()
*
* Purpose: Main strategy routine for SCSI.
@@ -1246,10 +1262,16 @@ static inline int scsi_host_queue_ready(
static void scsi_request_fn(struct request_queue *q)
{
struct scsi_device *sdev = q-queuedata;
- struct Scsi_Host *shost = sdev-host;
+ struct Scsi_Host *shost;
struct scsi_cmnd *cmd;
struct request *req;
+ if (!sdev) {
+ printk(scsi: killing requests for dead queue\n);
+ scsi_kill_requests(q);
+ return;
+ }
+
if(!get_device(sdev-sdev_gendev))
/* We must be tearing the block queue down already */
return;
@@ -1258,6 +1280,7 @@ static void scsi_request_fn(struct reque
* To start with, we keep looping until the queue is empty, or until
* the host is no longer able to accept any more requests.
*/
+ shost = sdev-host;
while (!blk_queue_plugged(q)) {
int rtn;
/*
= drivers/scsi/scsi_sysfs.c 1.69 vs edited =
--- 1.69/drivers/scsi/scsi_sysfs.c 2005-02-17 02:05:37 +01:00
+++ edited/drivers/scsi/scsi_sysfs.c2005-03-18 12:32:57 +01:00
@@ -168,8 +168,10 @@ void scsi_device_dev_release(struct devi
list_del(sdev-starved_entry);
spin_unlock_irqrestore(sdev-host-host_lock, flags);
- if (sdev-request_queue)
+ if (sdev-request_queue) {
+ sdev-request_queue-queuedata = NULL;
scsi_free_queue(sdev-request_queue);
+ }
scsi_target_reap(scsi_target(sdev));
--
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: [PATCH] fix fusion breakage with multiple PCI domains
On Thu, 2005-03-17 at 13:00 -0700, Bjorn Helgaas wrote:
mpt_detect_bound_ports(): Don't assume that two devices with the same
dev-bus-number are on the same bus. With multiple PCI domains,
many buses may have the same number.
Maybe mpt_detect_bound_ports() could be rewritten to use pci_get_slot()
instead? tg3_find_5704_peer() looks like it's doing basically the
same thing; maybe you could copy it.
= drivers/message/fusion/mptbase.c 1.40 vs edited =
--- 1.40/drivers/message/fusion/mptbase.c 2005-03-13 16:30:09 -07:00
+++ edited/drivers/message/fusion/mptbase.c 2005-03-17 12:46:57 -07:00
@@ -1834,14 +1834,14 @@
match_lo = pdev-devfn-1;
match_hi = pdev-devfn+1;
- dprintk((MYIOC_s_INFO_FMT PCI bus/devfn=%x/%x, searching for devfn
match on %x or %x\n,
- ioc-name, pdev-bus-number, pdev-devfn, match_lo,
match_hi));
+ dprintk((MYIOC_s_INFO_FMT PCI device %s devfn=%x/%x, searching for
devfn match on %x or %x\n,
+ ioc-name, pci_name(pdev), pdev-devfn, match_lo,
match_hi));
list_for_each_entry(ioc_srch, ioc_list, list) {
struct pci_dev *_pcidev = ioc_srch-pcidev;
if ((_pcidev-device == pdev-device)
- (_pcidev-bus-number == pdev-bus-number)
+ (_pcidev-bus == pdev-bus)
(_pcidev-devfn == match_lo || _pcidev-devfn == match_hi)
) {
/* Paranoia checks */
if (ioc-alt_ioc != 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
Adaptec SC4100 AltEvo reports 64 bits of LUN - kernel panics (2.6.9-2.6.12)
I have an Adaptec 12 bay U320 scsi disk array. It is divided in this case into 2 sections of 6 drives each. Each string of drives reports a Processor on unit #15. Why would the scsi layer scan unit #15 for LUN's? it reports a HUGE number of LUN's, many times more than 511. 0x908789244a030402 LUNs in some cases. The scsi layer then attempts to ask each of these LUNS what it is doing, overruns the allocated space, and panics the kernel. This is independent of the controller. AIC79XX (39320A-R) or LSI Fusion (LSI22320) all see this device, duly report it to the scsi layer, which 75% of the time panics and then panics during the panic, or OOPSes and then panics in the OOPS. Mar 18 12:01:11 typhoon kernel: Vendor: ADAPTEC Model: AltEvo U320 Rev: 0028 Mar 18 12:01:11 typhoon kernel: Type: Processor ANSI SCSI revision: 03 If the reported LUN count is odd, don't bother scanning it. If the reported unit is NOT a disk, don't scan it. drivers/scsi/scsi_scan.c happily scans ALL the given units, and walks over itself. I used a redhat es4.0 base on an AMD64 dual opteron with vanilla 2.6.9 - 2.6.12-rc1, all will crash with this hardware being present. details are available via email. - 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] scsi_mod: add max_dma_memory and use_zone_normal params
This is all done to work around a bug in the kernel dealing with
ZONE_DMA. I applaud the fix, but so many drivers need to be rewritten to
first try taking memory from the general pool, then dropping back to the
DMA pool if not matching the dma_mask.
Sincerely -- Mark Salyzyn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt Domsch
Sent: Friday, March 18, 2005 2:19 PM
To: linux-scsi@vger.kernel.org
Subject: [PATCH 2.4.30-pre3] scsi_mod: add max_dma_memory and
use_zone_normal params
For review and comment.
Patch adds two new module parameters to scsi_mod:
max_dma_memory=, maximum DMA pool size, in MB (default=32 - 32MB)
makes the hard-coded limit for the DMA pool size be adjustable. This
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
is necessary for systems with large numbers of disks seen (i.e. ~112
LUNs on a SAN as seen by a FC controller), where the size of the
scsi_malloc() pool would consume all of ZONE_DMA, leaving none for
other users. This lets a system admin set a limit on how much memory
to use for the scsi_malloc() pool. If set too low, fewer outstanding
commands can be issued at once, so it's only a performance issue.
use_zone_normal=, 1 if scsi_malloc() can safely use ZONE_NORMAL
instead of ZONE_DMA By default, scsi_malloc() uses ZONE_DMA memory.
On x86 and x86_64, ZONE_DMA is only 16MB, though if you've got a lot
of disks, it could try to consume all of that. This lets
scsi_malloc() use ZONE_NORMAL instead of ZONE_DMA, which of course is
only safe if all your SCSI controllers are 64-bit-address-capable
(most high-end cards today are). This flag lets you have lots more
memory available to scsi_malloc() than would be available if it were
forced to use only ZONE_DMA, and frees up the space it would otherwise
have consumed from ZONE_DMA for other users.
Tested lightly on x86_64 on EM64T systems with 8GB RAM and up to 112
LUNs visible (14x8 paths, 28x4 paths, ...)
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
= drivers/scsi/scsi_dma.c 1.2 vs edited =
--- 1.2/drivers/scsi/scsi_dma.c 2002-02-05 08:10:27 -06:00
+++ edited/drivers/scsi/scsi_dma.c 2005-03-18 11:31:11 -06:00
@@ -46,6 +46,29 @@ unsigned int scsi_dma_free_sectors = 0;
unsigned int scsi_need_isa_buffer = 0;
static unsigned char **dma_malloc_pages = NULL;
+static unsigned int max_dma_memory = 32; /* 32MB */
+MODULE_PARM(max_dma_memory, l);
+MODULE_PARM_DESC(max_dma_memory, maximum DMA pool size, in MB
(default=32 - 32MB));
+
+
+/* This flag is unsafe under these conditions:
+ * - you've got a 64-bit addressable SCSI controller, 4GB RAM, and an
architecture where ZONE_NORMAL
+ * extends above 4GB (any 64-bit architecture)
+ * or
+ * - you've got an old ISA card with host-unchecked_isa_dma=1
+ *
+ * This implies that it is really safe only with 64-bit addressable
SCSI controllers
+ */
+static unsigned int use_zone_normal;
+MODULE_PARM(use_zone_normal, i);
+MODULE_PARM_DESC(use_zone_normal, 1 if scsi_malloc() can safely use
ZONE_NORMAL instead of ZONE_DMA);
+
+static inline unsigned int dma_gfp_flags()
+{
+ return use_zone_normal ? GFP_ATOMIC : GFP_ATOMIC | GFP_DMA;
+}
+
+
/*
* Function:scsi_malloc
*
@@ -287,7 +310,7 @@ void scsi_resize_dma_pool(void)
#endif
/* limit DMA memory to 32MB: */
- new_dma_sectors = (new_dma_sectors + 15) 0xfff0;
+ new_dma_sectors = min(new_dma_sectors + 15, (max_dma_memory *
1024 * 2)) 0xfff0;
/*
* We never shrink the buffers - this leads to
@@ -330,7 +353,7 @@ void scsi_resize_dma_pool(void)
for (i = dma_sectors / SECTORS_PER_PAGE;
i new_dma_sectors / SECTORS_PER_PAGE; i++)
{
new_dma_malloc_pages[i] = (unsigned char
*)
- __get_free_pages(GFP_ATOMIC |
GFP_DMA, 0);
+ __get_free_pages(dma_gfp_flags(),
0);
if (!new_dma_malloc_pages[i])
break;
}
@@ -430,7 +453,7 @@ int scsi_init_minimal_dma_pool(void)
if (dma_malloc_pages) {
memset(dma_malloc_pages, 0, size);
dma_malloc_pages[0] = (unsigned char *)
- __get_free_pages(GFP_ATOMIC | GFP_DMA, 0);
+ __get_free_pages(dma_gfp_flags(), 0);
if (dma_malloc_pages[0])
has_space = 1;
}
-
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
[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
[PATCH] [1/5] Misc Lasi 700 fixes
Misc Lasi 700 fixes
- Use the DMA_32BIT_MASK constants when calling dma_set_mask()
Signed-off-by: Tobias Klauser [EMAIL PROTECTED]
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
- ioremap fixes
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff -urpNX dontdiff linus-2.6/drivers/scsi/lasi700.c
parisc-2.6/drivers/scsi/lasi700.c
--- linus-2.6/drivers/scsi/lasi700.c2005-03-18 06:21:11.324519230 -0700
+++ parisc-2.6/drivers/scsi/lasi700.c 2005-03-18 06:03:01.0 -0700
@@ -111,8 +111,8 @@ lasi700_probe(struct parisc_device *dev)
memset(hostdata, 0, sizeof(struct NCR_700_Host_Parameters));
hostdata-dev = dev-dev;
- dma_set_mask(dev-dev, 0xUL);
- hostdata-base = base;
+ dma_set_mask(dev-dev, DMA_32BIT_MASK);
+ hostdata-base = ioremap(base, 0x100);
hostdata-differential = 0;
if (dev-id.sversion == LASI_700_SVERSION) {
@@ -138,6 +138,7 @@ lasi700_probe(struct parisc_device *dev)
return 0;
out_kfree:
+ iounmap(hostdata-base);
kfree(hostdata);
return -ENODEV;
}
@@ -152,6 +153,7 @@ lasi700_driver_remove(struct parisc_devi
scsi_remove_host(host);
NCR_700_release(host);
free_irq(host-irq, host);
+ iounmap(hostdata-base);
kfree(hostdata);
return 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/5] Improve 53c700 /proc/interrupt output
Improve 53c700 /proc/interrupt output
Request the IRQ in the name of the chip rather than the bus address.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff -urpNX dontdiff linus-2.6/drivers/scsi/53c700.c
parisc-2.6/drivers/scsi/53c700.c
--- linus-2.6/drivers/scsi/53c700.c 2005-03-18 06:21:10.744516094 -0700
+++ parisc-2.6/drivers/scsi/53c700.c2005-03-18 06:02:57.0 -0700
@@ -304,6 +304,7 @@ NCR_700_detect(struct scsi_host_template
__u8 *memory;
__u32 *script;
struct Scsi_Host *host;
+ const char *chipname;
static int banner = 0;
int j;
@@ -408,15 +409,15 @@ NCR_700_detect(struct scsi_host_template
printk(KERN_NOTICE 53c700: Version NCR_700_VERSION By
[EMAIL PROTECTED]);
banner = 1;
}
+ chipname = hostdata-chip710 ? 53c710 : \
+ (hostdata-fast ? 53c700-66 : 53c700);
printk(KERN_NOTICE scsi%d: %s rev %d %s\n, host-host_no,
- hostdata-chip710 ? 53c710 :
- (hostdata-fast ? 53c700-66 : 53c700),
- hostdata-rev, hostdata-differential ?
- (Differential) : );
+ chipname, hostdata-rev,
+ hostdata-differential ? (Differential) : );
/* reset the chip */
NCR_700_chip_reset(host);
- if (request_irq(irq, NCR_700_intr, SA_SHIRQ, dev-bus_id, host)) {
+ if (request_irq(irq, NCR_700_intr, SA_SHIRQ, chipname, host)) {
dev_printk(KERN_ERR, dev, 53c700: irq %lu request failed\n ,
irq);
goto out_put_host;
-
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/5] Zalon updates
Zalon updates - Add KERN_INFO to printk Signed-off-by: Andrew McGregor [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] - Remove iomem-related warnings - Improve printk message - Use cpu_relax() Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] diff -urpNX dontdiff linus-2.6/drivers/scsi/zalon.c parisc-2.6/drivers/scsi/zalon.c --- linus-2.6/drivers/scsi/zalon.c 2005-03-18 06:21:12.604526151 -0700 +++ parisc-2.6/drivers/scsi/zalon.c 2005-03-18 06:03:07.0 -0700 @@ -88,31 +88,30 @@ zalon_probe(struct parisc_device *dev) struct gsc_irq gsc_irq; u32 zalon_vers; int error = -ENODEV; - unsigned long zalon = dev-hpa; - unsigned long io_port = zalon + GSC_SCSI_ZALON_OFFSET; + void __iomem *zalon = ioremap(dev-hpa, 4096); + void __iomem *io_port = zalon + GSC_SCSI_ZALON_OFFSET; static int unit = 0; struct Scsi_Host *host; struct ncr_device device; __raw_writel(CMD_RESET, zalon + IO_MODULE_IO_COMMAND); while (!(__raw_readl(zalon + IO_MODULE_IO_STATUS) IOSTATUS_RY)) - ; + cpu_relax(); __raw_writel(IOIIDATA_MINT5EN | IOIIDATA_PACKEN | IOIIDATA_PREFETCHEN, zalon + IO_MODULE_II_CDATA); /* XXX: Save the Zalon version for bug workarounds? */ - zalon_vers = __raw_readl(dev-hpa + IO_MODULE_II_CDATA) 0x0700; - zalon_vers = 24; + zalon_vers = (__raw_readl(zalon + IO_MODULE_II_CDATA) 24) 0x07; /* Setup the interrupts first. ** Later on request_irq() will register the handler. */ dev-irq = gsc_alloc_irq(gsc_irq); - printk(%s: Zalon vers field is 0x%x, IRQ %d\n, __FUNCTION__, + printk(KERN_INFO %s: Zalon version %d, IRQ %d\n, __FUNCTION__, zalon_vers, dev-irq); - __raw_writel(gsc_irq.txn_addr | gsc_irq.txn_data, dev-hpa + IO_MODULE_EIM); + __raw_writel(gsc_irq.txn_addr | gsc_irq.txn_data, zalon + IO_MODULE_EIM); if (zalon_vers == 0) printk(KERN_WARNING %s: Zalon 1.1 or earlier\n, __FUNCTION__); @@ -120,16 +119,16 @@ zalon_probe(struct parisc_device *dev) memset(device, 0, sizeof(struct ncr_device)); /* The following three are needed before any other access. */ - writeb(0x20, io_port + 0x38); /* DCNTL_REG, EA */ - writeb(0x04, io_port + 0x1b); /* CTEST0_REG, EHP */ - writeb(0x80, io_port + 0x22); /* CTEST4_REG, MUX */ + __raw_writeb(0x20, io_port + 0x38); /* DCNTL_REG, EA */ + __raw_writeb(0x04, io_port + 0x1b); /* CTEST0_REG, EHP */ + __raw_writeb(0x80, io_port + 0x22); /* CTEST4_REG, MUX */ /* Initialise ncr_device structure with items required by ncr_attach. */ device.chip = zalon720_chip; device.host_id = 7; device.dev = dev-dev; - device.slot.base= (u_long)io_port; - device.slot.base_c = (u_long)io_port; + device.slot.base= dev-hpa + GSC_SCSI_ZALON_OFFSET; + device.slot.base_v = io_port; device.slot.irq = dev-irq; device.differential = 2; - 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] [5/5] Fix small bug in scsi_transport_spi
Fix small bug in scsi_transport_spi
reserved was being printed without a trailing \n.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff -urpNX dontdiff linus-2.6/drivers/scsi/scsi_transport_spi.c
parisc-2.6/drivers/scsi/scsi_transport_spi.c
--- linus-2.6/drivers/scsi/scsi_transport_spi.c 2005-03-18 06:21:12.433525226
-0700
+++ parisc-2.6/drivers/scsi/scsi_transport_spi.c2005-03-18
06:12:13.789614671 -0700
@@ -293,9 +293,12 @@ static ssize_t show_spi_transport_period
picosec = tp-period * 4000;
}
- if (picosec == -1)
- return sprintf(buf, reserved);
- len = sprint_frac(buf, picosec, 1000);
+ if (picosec == -1) {
+ len = sprintf(buf, reserved);
+ } else {
+ len = sprint_frac(buf, picosec, 1000);
+ }
+
buf[len++] = '\n';
buf[len] = '\0';
return len;
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [4/5] ncr53c8xx update
ncr53c8xx update
ncr-3.4.3g:
- set the starget in slave_alloc instead of slave_configure to avoid
problems with drives sending negotiation messages before we try to
configure them.
- Implement -get_signalling.
- Pass the scsi_cmnd to ncr_get_ccb() instead of the target lun numbers
- All ncr_show_msg() callers changed to use ncr_print_msg()
- Combine ncr_show_msg() into ncr_print_msg()
- Move ncr_print_msg() to near the top of the file and eliminate prototype
- Change PRINT_ADDR() to take a fmt string
- Make PRINT_ADDR use dev_info()
- Eliminate PRINT_LUN -- all callers can use PRINT_ADDR or dev_info
- Replace PRINT_TARGET() with a direct call to dev_info()
- Whitespace cleanups
- Get rid of superfluous ; after } of if/switch statements
- Use IDENTIFY() instead of M_IDENTIFY | ...
- Convert to use spi_display_xfer_agreement()
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff -urpNX dontdiff linus-2.6/drivers/scsi/ncr53c8xx.c
parisc-2.6/drivers/scsi/ncr53c8xx.c
--- linus-2.6/drivers/scsi/ncr53c8xx.c 2005-03-18 06:21:11.0 -0700
+++ parisc-2.6/drivers/scsi/ncr53c8xx.c 2005-03-18 20:36:10.870367554 -0700
@@ -86,7 +86,7 @@
*/
/* Name and version of the driver */
-#define SCSI_NCR_DRIVER_NAME ncr53c8xx-3.4.3f
+#define SCSI_NCR_DRIVER_NAME ncr53c8xx-3.4.3g
#define SCSI_NCR_DEBUG_FLAGS (0)
@@ -1219,7 +1219,7 @@ staticstruct lcb *ncr_alloc_lcb (struc
static struct lcb *ncr_setup_lcb (struct ncb *np, struct scsi_device
*sdev);
static voidncr_getclock(struct ncb *np, int mult);
static voidncr_selectclock (struct ncb *np, u_char scntl3);
-static struct ccb *ncr_get_ccb (struct ncb *np, u_char tn, u_char ln);
+static struct ccb *ncr_get_ccb (struct ncb *np, struct scsi_cmnd *cmd);
static voidncr_chip_reset (struct ncb *np, int delay);
static voidncr_init(struct ncb *np, int reset, char * msg, u_long
code);
static int ncr_int_sbmc(struct ncb *np);
@@ -1238,8 +1238,6 @@ staticvoidncr_getsync (struct ncb *np,
static voidncr_setsync (struct ncb *np, struct ccb *cp, u_char scntl3,
u_char sxfer);
static voidncr_setup_tags (struct ncb *np, struct scsi_device *sdev);
static voidncr_setwide (struct ncb *np, struct ccb *cp, u_char wide,
u_char ack);
-static int ncr_show_msg(u_char * msg);
-static voidncr_print_msg (struct ccb *cp, char *label, u_char *msg);
static int ncr_snooptest (struct ncb *np);
static voidncr_timeout (struct ncb *np);
static voidncr_wakeup (struct ncb *np, u_long code);
@@ -2746,7 +2744,7 @@ void __init ncr_script_fill (struct scri
for (i=0; iMAX_START; i++) {
*p++ =SCR_CALL;
*p++ =PADDR (idle);
- };
+ }
BUG_ON((u_long)p != (u_long)scrh-tryloop + sizeof (scrh-tryloop));
@@ -2771,7 +2769,7 @@ void __init ncr_script_fill (struct scri
*p++ =PADDR (dispatch);
*p++ =SCR_MOVE_TBL ^ SCR_DATA_IN;
*p++ =offsetof (struct dsb, data[i]);
- };
+ }
BUG_ON((u_long)p != (u_long)scrh-hdata_in + sizeof (scrh-hdata_in));
@@ -2781,7 +2779,7 @@ void __init ncr_script_fill (struct scri
*p++ =PADDR (dispatch);
*p++ =SCR_MOVE_TBL ^ SCR_DATA_IN;
*p++ =offsetof (struct dsb, data[i]);
- };
+ }
BUG_ON((u_long)p != (u_long)scr-data_in + sizeof (scr-data_in));
@@ -2791,7 +2789,7 @@ void __init ncr_script_fill (struct scri
*p++ =PADDR (dispatch);
*p++ =SCR_MOVE_TBL ^ SCR_DATA_OUT;
*p++ =offsetof (struct dsb, data[i]);
- };
+ }
BUG_ON((u_long)p != (u_long)scrh-hdata_out + sizeof
(scrh-hdata_out));
@@ -2801,7 +2799,7 @@ void __init ncr_script_fill (struct scri
*p++ =PADDR (dispatch);
*p++ =SCR_MOVE_TBL ^ SCR_DATA_OUT;
*p++ =offsetof (struct dsb, data[i]);
- };
+ }
BUG_ON((u_long) p != (u_long)scr-data_out + sizeof (scr-data_out));
}
@@ -2842,7 +2840,7 @@ ncr_script_copy_and_bind (struct ncb *np
printk (KERN_ERR %s: ERROR0 IN SCRIPT at %d.\n,
ncr_name(np), (int) (src-start-1));
mdelay(1000);
- };
+ }
if (DEBUG_FLAGS DEBUG_SCRIPT)
printk (KERN_DEBUG %p: %x\n,
@@ -2911,7 +2909,7 @@ ncr_script_copy_and_bind (struct ncb *np
default:
relocs = 0;
break;
- };
+ }
if (relocs) {
while (relocs--) {
@@ -2958,7 +2956,7 @@ ncr_script_copy_and_bind (struct ncb *np
} else
*dst++ = cpu_to_scr(*src++);
- };
+ }
}
/*
@@ -2969,25 +2967,25 @@ struct host_data {
struct ncb *ncb;
};
Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Fri, 2005-03-18 at 15:23 -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. scsi_malloc no longer uses ZONE_DMA nowadays - 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
