Re: [patch 4/6] ps3: Disk Storage Driver
From: Christoph Hellwig [EMAIL PROTECTED] Date: Tue, 19 Jun 2007 07:53:58 +0200 On Fri, Jun 15, 2007 at 02:19:17PM -0700, David Miller wrote: Another quirk I have to deal with is that under LDOMs you can export full disks and also just slices. So I'll have to get down into the partition machinery to support that somehow. What's the problem with that? Partition machinery is perfectly fine with just getting a raw disk without a partition table, and it obviously doesn't care if the raw disk it sees is part of a partition on the storage server. Applications care :-) One way of managing the partition table is by asking the storage server for it. It supports giving back something that looks like the Sun partition table layout, and also something that's EFI based. But the client can ignore that and read/write the partition table itself. What I really care about is what will work transparently for existing userspace. In particular, distribution installers and existing tools like fdisk. When a slice it being exported, it's not being exported like that so that the client can just spam a disk label into it, it's for exporting one slice. So we might want (using the scsi naming as an arbitrary example case) /dev/sda1 to be created but not /dev/sda How exactly do you envision this kind of thing working? Supporting the disk-server-provided partition table management means providing ioctls() or whatever interface to get/set the table. I had one idea to intercept reads/writes to the first block(s) and translating those into partition management commands to the disk server, but that is just too ugly to live. :-) - 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 4/6] ps3: Disk Storage Driver
From: Christoph Hellwig [EMAIL PROTECTED] Date: Tue, 19 Jun 2007 07:56:29 +0200 A SCSI pass through is of course perfectly fine. If you have a separate block passthrough that has additional magic a separate block driver is the way to go because it actually is simpler than a scsi driver decoding command blocks and translating them to deep magic. The ps3 storage drivers this thread discussed are a good example for that. We now have a very nice and simple disk, scsi and flash chardev driver each that don't include abstractions layers and cruft. Combine that with their initial scsi layer driver that was full of internal dispatches because each of these device types speaks a completely different command set. That's how I'm currently writing my virtual disk client driver for the Sun LDOMS stuff, as a block device. The remaining issues are the partitioning (which we're discussing in another thread) and how to export the scsi passthru support in such a non-scsi block driver. The main disk I/O block read and write is done using descriptors sent to the disk server. SCSI pass-through is provided (optionally) so that disk analysis tools can do things like MODE_SENSE on the disk. - 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 4/6] ps3: Disk Storage Driver
On Mon, 18 Jun 2007, David Miller wrote: What I really care about is what will work transparently for existing userspace. In particular, distribution installers and existing tools like fdisk. When a slice it being exported, it's not being exported like that so that the client can just spam a disk label into it, it's for exporting one slice. So we might want (using the scsi naming as an arbitrary example case) /dev/sda1 to be created but not /dev/sda How exactly do you envision this kind of thing working? How do distribution installers handle USB disks and memory cards? Some tend to be partitioned, some don't. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: [patch 0/5] m68k 53c700 SCSI
Hi James,
On Sun, 17 Jun 2007, Geert Uytterhoeven wrote:
These patches add support for m68k to the 53c700 SCSI core and introduce new
drivers for various m68k hardware using this 53c700 SCSI core, to replace the
just removed drivers using the old 53c7xx SCSI core.
[1] [PATCH] 53c700 scsi: m68k support for the 53c700 SCSI core
[2] [PATCH] 53c700 scsi: m68k BVME6000 NCR53C710 SCSI
[3] [PATCH] 53c700 scsi: m68k MVME16x NCR53C710 SCSI
[4] [PATCH] 53c700 scsi: Amiga 4000T NCR53c710 SCSI
[5] [PATCH] 53c700 scsi: Amiga Zorro NCR53c710 SCSI
Please apply for 2.6.23. Thx!
Apparently I made some major mistakes when preparing these patches.
Here are the fixes.
---
Fixup m68k 53c700 drivers:
- a4000t.c: Add missing include, needed in some configurations
- bvme6000_scsi.c: Kill bogus opening brace
- zorro7xx.c: Remove MODULE_DEVICE_TABLE, it should be part of another
patch
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/scsi/a4000t.c|1 +
drivers/scsi/bvme6000_scsi.c |2 +-
drivers/scsi/zorro7xx.c |1 -
3 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/scsi/a4000t.c
+++ b/drivers/scsi/a4000t.c
@@ -12,6 +12,7 @@
#include linux/platform_device.h
#include linux/init.h
#include linux/interrupt.h
+#include asm/amigahw.h
#include asm/amigaints.h
#include scsi/scsi_host.h
#include scsi/scsi_transport_spi.h
--- a/drivers/scsi/bvme6000_scsi.c
+++ b/drivers/scsi/bvme6000_scsi.c
@@ -112,7 +112,7 @@ static int __init bvme6000_scsi_init(voi
int err;
err = driver_register(bvme6000_scsi_driver);
- if (err) {
+ if (err)
return err;
bvme6000_scsi_device = platform_device_register_simple(bvme6000-scsi,
--- a/drivers/scsi/zorro7xx.c
+++ b/drivers/scsi/zorro7xx.c
@@ -65,7 +65,6 @@ static struct zorro_device_id zorro7xx_z
},
{ 0 }
};
-MODULE_DEVICE_TABLE(zorro, zorro7xx_zorro_tbl);
static int __devinit zorro7xx_init_one(struct zorro_dev *z,
const struct zorro_device_id *ent)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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 4/6] ps3: Disk Storage Driver
On Mon, Jun 18, 2007 at 11:07:31PM -0700, David Miller wrote: The main disk I/O block read and write is done using descriptors sent to the disk server. SCSI pass-through is provided (optionally) so that disk analysis tools can do things like MODE_SENSE on the disk. SG_IO can easily be implemented for block devices. See cciss in current mainline for an example. - 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] zfcp: Report FCP LUN to SCSI midlayer
From: Christof Schmitt [EMAIL PROTECTED]
When reporting SCSI devices to the SCSI midlayer, use the FCP LUN as
LUN reported to the SCSI layer. With this approach, zfcp does not have
to create unique LUNS, and this code can be removed.
Signed-off-by: Christof Schmitt [EMAIL PROTECTED]
Signed-off-by: Swen Schillig [EMAIL PROTECTED]
---
drivers/s390/scsi/zfcp_aux.c | 22 --
drivers/scsi/scsi_scan.c |3 ++-
include/scsi/scsi_device.h |1 +
3 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_aux.c b/drivers/s390/scsi/zfcp_aux.c
index 821cde6..c631cf7 100644
--- a/drivers/s390/scsi/zfcp_aux.c
+++ b/drivers/s390/scsi/zfcp_aux.c
@@ -815,9 +815,7 @@ zfcp_get_adapter_by_busid(char *bus_id)
struct zfcp_unit *
zfcp_unit_enqueue(struct zfcp_port *port, fcp_lun_t fcp_lun)
{
- struct zfcp_unit *unit, *tmp_unit;
- unsigned int scsi_lun;
- int found;
+ struct zfcp_unit *unit;
/*
* check that there is no unit with this FCP_LUN already in list
@@ -863,22 +861,10 @@ zfcp_unit_enqueue(struct zfcp_port *port, fcp_lun_t
fcp_lun)
}
zfcp_unit_get(unit);
-
- scsi_lun = 0;
- found = 0;
+ unit-scsi_lun = scsilun_to_int((struct scsi_lun *)unit-fcp_lun);
+
write_lock_irq(zfcp_data.config_lock);
- list_for_each_entry(tmp_unit, port-unit_list_head, list) {
- if (tmp_unit-scsi_lun != scsi_lun) {
- found = 1;
- break;
- }
- scsi_lun++;
- }
- unit-scsi_lun = scsi_lun;
- if (found)
- list_add_tail(unit-list, tmp_unit-list);
- else
- list_add_tail(unit-list, port-unit_list_head);
+ list_add_tail(unit-list, port-unit_list_head);
atomic_clear_mask(ZFCP_STATUS_COMMON_REMOVE, unit-status);
atomic_set_mask(ZFCP_STATUS_COMMON_RUNNING, unit-status);
write_unlock_irq(zfcp_data.config_lock);
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 662577f..cf95ad9 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1213,7 +1213,7 @@ static void scsi_sequential_lun_scan(struct scsi_target
*starget,
* Given a struct scsi_lun of: 0a 04 0b 03 00 00 00 00, this function
returns
* the integer: 0x0b030a04
**/
-static int scsilun_to_int(struct scsi_lun *scsilun)
+int scsilun_to_int(struct scsi_lun *scsilun)
{
int i;
unsigned int lun;
@@ -1224,6 +1224,7 @@ static int scsilun_to_int(struct scsi_lun *scsilun)
scsilun-scsi_lun[i + 1]) (i * 8));
return lun;
}
+EXPORT_SYMBOL(scsilun_to_int);
/**
* int_to_scsilun: reverts an int into a scsi_lun
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 2f3c5b8..6fe1cf6 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -287,6 +287,7 @@ extern void scsi_target_block(struct device *);
extern void scsi_target_unblock(struct device *);
extern void scsi_remove_target(struct device *);
extern void int_to_scsilun(unsigned int, struct scsi_lun *);
+extern int scsilun_to_int(struct scsi_lun *);
extern const char *scsi_device_state_name(enum scsi_device_state);
extern int scsi_is_sdev_device(const struct device *);
extern int scsi_is_target_device(const struct device *);
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zfcp: Report FCP LUN to SCSI midlayer
Swen Schillig wrote: From: Christof Schmitt [EMAIL PROTECTED] When reporting SCSI devices to the SCSI midlayer, use the FCP LUN as LUN reported to the SCSI layer. With this approach, zfcp does not have to create unique LUNS, and this code can be removed. Signed-off-by: Christof Schmitt [EMAIL PROTECTED] Signed-off-by: Swen Schillig [EMAIL PROTECTED] Grand. Another zfcp-ism removed. FWIW: Signed-off-by: Hannes Reinecke [EMAIL PROTECTED] Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - 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] zfcp: Report FCP LUN to SCSI midlayer
Swen Schillig wrote:
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1213,7 +1213,7 @@ static void scsi_sequential_lun_scan(struct scsi_target
*starget,
* Given a struct scsi_lun of: 0a 04 0b 03 00 00 00 00, this function
returns
* the integer: 0x0b030a04
**/
-static int scsilun_to_int(struct scsi_lun *scsilun)
+int scsilun_to_int(struct scsi_lun *scsilun)
{
int i;
unsigned int lun;
@@ -1224,6 +1224,7 @@ static int scsilun_to_int(struct scsi_lun *scsilun)
scsilun-scsi_lun[i + 1]) (i * 8));
return lun;
}
+EXPORT_SYMBOL(scsilun_to_int);
This export will be useful for fw-sbp2 too.
--
Stefan Richter
-=-=-=== -==- =--==
http://arcgraph.de/sr/
-
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 4/6] ps3: Disk Storage Driver
On Tue, 19 Jun 2007, Christoph Hellwig wrote: On Fri, Jun 15, 2007 at 01:39:23PM +0200, Geert Uytterhoeven wrote: From: Geert Uytterhoeven [EMAIL PROTECTED] Add a Disk Storage Driver for the PS3: - Implemented as a block device driver with a dynamic major - Disk names (and partitions) are of the format ps3d%c(%u) - Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor doesn't support scatter-gather Looks good to me. Only nitpicks are: - ps3disk_priv should probably be an inline function instead of a macro I used a macro because you can do ps3disk_pri(dev) = ...; With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
strange queue_if_no_path behavior
Hi! Reposting a shorter version. I have a question regarding queue_if_no_path behavior. I tried Red Hat 5.0 2.6.18-8.el5 kernel and more or less recent multipath-tools. Set no_path_retry queue in multipath.conf and tried losing all paths to a SAN device, while I'm dd-ing from /dev/zero to /dev/mapper/... What's strange is that not only ios to that device got blocked, but also ios to /tmp and /var/log/messages etc that reside on local drive. When I return some paths to the SAN device, all ios resume, both ios to that device and those unexpectedly blocked. Please tell me if this is an expected behavior and if not, how could we find a source of the problem and fix it? # ps aux | grep D USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 2872 0.0 0.0 10064 748 ?Ds 21:58 0:00 syslogd -m 0 root 3800 24.9 0.0 63300 1592 ttyS0D22:01 0:22 dd if /dev/zero of /dev/mapper/... root 3990 0.0 0.0 58020 476 ttyS0D22:02 0:00 tail -f /var/log/messages Thanks much, Maxim. Can't include here the full sysrq output as the message doesn't reach the mailing list. Sometimes (maybe it depends if root is on lvm or not) it tells BUG: soft lockup detected on CPU#3! BUG: soft lockup detected on CPU#0! BUG: soft lockup detected on CPU#1! BUG: soft lockup detected on CPU#2! But I always see [800613c7] schedule_timeout+0x8a/0xad [80092de7] process_timeout+0x0/0x5 [80060d55] io_schedule_timeout+0x4b/0x79 [8003a9c4] blk_congestion_wait+0x66/0x80 for all processes in D state. syslogd D 810075f779c8 0 15395 1 15398 15380 (NOTLB) 810075f779c8 8100022c7750 810002667068 0009 81007fbe5080 810037d1b100 006b91ee3bd1 14f4 81007fbe5268 0003 810037d1b100 Call Trace: [800613c7] schedule_timeout+0x8a/0xad [80092de7] process_timeout+0x0/0x5 [80060d55] io_schedule_timeout+0x4b/0x79 [8003a9c4] blk_congestion_wait+0x66/0x80 [8009b666] autoremove_wake_function+0x0/0x2e [8004ece5] writeback_inodes+0xa8/0xd8 [800bc61b] balance_dirty_pages_ratelimited_nr+0x183/0x1fa [8000fc69] generic_file_buffered_write+0x5a4/0x6d8 [80030dd5] skb_copy_datagram_iovec+0x4f/0x237 [8000dd98] current_fs_time+0x3b/0x40 [80251b9e] unix_dgram_recvmsg+0x240/0x25e [80015d10] __generic_file_aio_write_nolock+0x36d/0x3b8 [800b9744] __generic_file_write_nolock+0x8f/0xa8 [800d8408] core_sys_select+0x1f9/0x265 [8009b666] autoremove_wake_function+0x0/0x2e [80061622] mutex_lock+0xd/0x1d [800b97a5] generic_file_writev+0x48/0xa2 [8001770b] do_sync_write+0x0/0x104 [800d0f6c] do_readv_writev+0x176/0x295 [8001770b] do_sync_write+0x0/0x104 [800b1cca] audit_syscall_entry+0x14d/0x180 [800d1115] sys_writev+0x45/0x93 [8005b2c1] tracesys+0xd1/0xdc klogd S 8100757e5be8 0 15398 1 15410 15395 (NOTLB) 8100757e5be8 81007fbe5080 80086480 000a 810037fe37a0 81007c30a7e0 00690912dbde 0003fc7a 810037fe3988 80044d16 fffe Call Trace: [80086480] enqueue_task+0x41/0x56 [80044d16] try_to_wake_up+0x407/0x418 [8005a534] cache_alloc_refill+0x106/0x186 [8006135b] schedule_timeout+0x1e/0xad [80045be5] prepare_to_wait_exclusive+0x38/0x61 [80250e8f] unix_wait_for_peer+0x90/0xac [8009b666] autoremove_wake_function+0x0/0x2e [80251422] unix_dgram_sendmsg+0x3de/0x4cf [80037264] do_sock_write+0xc4/0xce [8004543e] sock_aio_write+0x4f/0x5e [80060ab8] thread_return+0x0/0xea [800177d2] do_sync_write+0xc7/0x104 [8009b666] autoremove_wake_function+0x0/0x2e [8009b666] autoremove_wake_function+0x0/0x2e [80016134] vfs_write+0xe1/0x174 [800169b2] sys_write+0x45/0x6e [8005b2c1] tracesys+0xd1/0xdc irqbalanceS 810074c05eb8 0 15410 1 15432 15398 (NOTLB) 810074c05eb8 810074c05e58 810074c05e58 0007 81007d6bb7a0 802d1ae0 006b8b7abaa3 0007f864 81007d6bb988 8100 810002c384e0 Call Trace: [80061804] do_nanosleep+0x3f/0x70 [800587ce] hrtimer_nanosleep+0x58/0x118 [8009d5e0] hrtimer_wakeup+0x0/0x22 [800526e5] sys_nanosleep+0x4c/0x62 [8005b2c1] tracesys+0xd1/0xdc multipathdS 810074031d48 0 15432 1 15436 15410 (NOTLB) 810074031d48 810075f5c140 fff0 0001 81007dbd2080 810037fe9080 00290837b6b9 00091d38 81007dbd2268 8100 0044 8100fc10 Call Trace: [800baea2]
[PATCH] aacraid: change srb status busy return
This patch is more like a spelling correction than a fix. It was discovered that if we had a busy status return from the Adapter for the SCSI srb command to a physical component, that we returned DID_NO_CONNECT rather than what one would expect DID_BUS_BUSY. This attached patch is against current scsi-misc-2.6 ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] drivers/scsi/aacraid/aachba.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) aacraid_srb_status_busy.patch Description: aacraid_srb_status_busy.patch
[PATCH] aacraid: add support for long serial number information
Support displaying long serial number information. Reuse sysfs handler internally as helper. This attached patch is against current scsi-misc-2.6 ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] drivers/scsi/aacraid/aachba.c |9 + drivers/scsi/aacraid/aacraid.h |4 drivers/scsi/aacraid/linit.c | 12 +--- 3 files changed, 18 insertions(+), 7 deletions(-) aacraid_serial_number.patch Description: aacraid_serial_number.patch
[PATCH] fix req-cmd == INT cases
From 6f4641911701cbdbe01516305b682012d8c6982a Mon Sep 17 00:00:00 2001
Date: Tue, 19 Jun 2007 18:54:54 +0300
I have unearthed very old bugs in stale drivers that still
used request-cmd as a READ|WRITE int.
This patch is maybe a proof that these drivers have not been
used for a long time. Should they be removed completely?
If you are CCed it means your name was in one of these drivers
source files, or in the MAINTAINERS file. Please acknowledge
the possible removal of this old driver.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
drivers/acorn/block/fd1772.c
Jens Axboe
Paul Bristow [EMAIL PROTECTED]
Dave Gilbert ([EMAIL PROTECTED])
drivers/acorn/block/mfmhd.c
TO: Russell King [EMAIL PROTECTED]
TO: Dave Alan Gilbert [EMAIL PROTECTED]
drivers/block/amiflop.c
Greg Harp
Joerg Dorchain
drivers/block/nbd.c
Paul Clements [EMAIL PROTECTED]
Pavel Machek [EMAIL PROTECTED]
Steven Whitehouse [EMAIL PROTECTED]
drivers/cdrom/aztcd.c
Eberhard Moenkeberg [EMAIL PROTECTED]
Werner Zimmermann([EMAIL PROTECTED])
drivers/cdrom/cm206.c
David van Leeuwen [EMAIL PROTECTED]
drivers/cdrom/gscd.c
Oliver Raupach [EMAIL PROTECTED]
drivers/cdrom/mcdx.c
Heiko Schlittermann [EMAIL PROTECTED]
drivers/cdrom/optcd.c
Leo Spiekman [EMAIL PROTECTED]
drivers/cdrom/sjcd.c
Vadim V. Model [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
drivers/ide/legacy/hd.c
Linus Trovalds
---
drivers/acorn/block/fd1772.c |2 +-
drivers/acorn/block/mfmhd.c |9 +
drivers/block/amiflop.c |2 +-
drivers/block/nbd.c |2 +-
drivers/cdrom/aztcd.c|2 +-
drivers/cdrom/cm206.c|2 +-
drivers/cdrom/gscd.c |2 +-
drivers/cdrom/mcdx.c |2 +-
drivers/cdrom/optcd.c|2 +-
drivers/cdrom/sjcd.c |2 +-
drivers/ide/legacy/hd.c |4 ++--
11 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/acorn/block/fd1772.c b/drivers/acorn/block/fd1772.c
index 674bf81..423ed08 100644
--- a/drivers/acorn/block/fd1772.c
+++ b/drivers/acorn/block/fd1772.c
@@ -1246,7 +1246,7 @@ repeat:
del_timer(motor_off_timer);
ReqCnt = 0;
-ReqCmd = CURRENT-cmd;
+ReqCmd = rq_data_dir(CURRENT);
ReqBlock = CURRENT-sector;
ReqBuffer = CURRENT-buffer;
setup_req_params(drive);
diff --git a/drivers/acorn/block/mfmhd.c b/drivers/acorn/block/mfmhd.c
index 689a4c3..7a4e12b 100644
--- a/drivers/acorn/block/mfmhd.c
+++ b/drivers/acorn/block/mfmhd.c
@@ -439,7 +439,7 @@ static void mfm_rw_intr(void)
a choice of command end or some data which is ready to be
collected */
/* I think we have to transfer data while the interrupt line is on
and its
not any other type of interrupt */
-if (CURRENT-cmd == WRITE) {
+if (rq_data_dir(CURRENT) == WRITE) {
extern void hdc63463_writedma(void);
if ((hdc63463_dataleft = 0) (!(mfm_status STAT_CED))) {
printk(mfm_rw_intr: Apparent DMA write request when no
more to DMA\n);
@@ -799,7 +799,7 @@ static void issue_request(unsigned int block,
unsigned int nsect,
raw_cmd.head = start_head;
raw_cmd.cylinder = track / p-heads;
raw_cmd.cmdtype = CURRENT-cmd;
-raw_cmd.cmdcode = CURRENT-cmd == WRITE ? CMD_WD : CMD_RD;
+raw_cmd.cmdcode = rq_data_dir(CURRENT) == WRITE ? CMD_WD : CMD_RD;
raw_cmd.cmddata[0] = dev + 1;/* DAG: +1 to get US */
raw_cmd.cmddata[1] = raw_cmd.head;
raw_cmd.cmddata[2] = raw_cmd.cylinder 8;
@@ -830,7 +830,7 @@ static void issue_request(unsigned int block,
unsigned int nsect,
hdc63463_dataleft = nsect * 256;/* Better way? */
DBG(mfm%c: %sing: CHS=%d/%d/%d, sectors=%d, buffer=0x%08lx (%p)\n,
- raw_cmd.dev + 'a', (CURRENT-cmd == READ) ? read : writ,
+ raw_cmd.dev + 'a', rq_data_dir(CURRENT) == READ ? read : writ,
raw_cmd.cylinder,
raw_cmd.head,
raw_cmd.sector, nsect, (unsigned long) Copy_buffer, CURRENT);
@@ -917,7 +917,8 @@ static void mfm_request(void)
DBG(mfm_request: block after offset=%d\n, block);
-if (CURRENT-cmd != READ CURRENT-cmd != WRITE) {
+if (rq_data_dir(CURRENT) != READ
+rq_data_dir(CURRENT) != WRITE) {
printk(unknown mfm-command %d\n, CURRENT-cmd);
end_request(CURRENT, 0);
Busy = 0;
diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c
index 27a1390..6ce8b89 100644
--- a/drivers/block/amiflop.c
+++ b/drivers/block/amiflop.c
@@ -1363,7 +1363,7 @@ static void redo_fd_request(void)
#ifdef DEBUG
printk(fd: sector %ld + %d requested for %s\n,
CURRENT-sector,cnt,
- (CURRENT-cmd==READ)?read:write);
+ (rq_data_dir(CURRENT) == READ) ? read : write);
#endif
block = CURRENT-sector + cnt;
if ((int)block floppy-blocks) {
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 069ae39..c575fb1 100644
--- a/drivers/block/nbd.c
[PATCH] Remove of not compiling acsi.c
This drivers has not been compiling for a very long time and is not a
part of
any Makefile. Proof:
bh = CURRENT-bh;
Sign-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/block/acsi.c | 1825
--
1 files changed, 0 insertions(+), 1825 deletions(-)
delete mode 100644 drivers/block/acsi.c
diff --git a/drivers/block/acsi.c b/drivers/block/acsi.c
deleted file mode 100644
index e3d9152..000
--- a/drivers/block/acsi.c
+++ /dev/null
@@ -1,1825 +0,0 @@
-/*
- * acsi.c -- Device driver for Atari ACSI hard disks
- *
- * Copyright 1994 Roman Hodek [EMAIL PROTECTED]
- *
- * Some parts are based on hd.c by Linus Torvalds
- *
- * This file is subject to the terms and conditions of the GNU General
Public
- * License. See the file COPYING in the main directory of this archive for
- * more details.
- *
- */
-
-/*
- * Still to in this file:
- * - If a command ends with an error status (!= 0), the following
- *REQUEST SENSE commands (4 to fill the ST-DMA FIFO) are done by
- *polling the _IRQ signal (not interrupt-driven). This should be
- *avoided in future because it takes up a non-neglectible time in
- *the interrupt service routine while interrupts are disabled.
- *Maybe a timer interrupt will get lost :-(
- */
-
-/*
- * General notes:
- *
- * - All ACSI devices (disks, CD-ROMs, ...) use major number 28.
- *Minors are organized like it is with SCSI: The upper 4 bits
- *identify the device, the lower 4 bits the partition.
- *The device numbers (the upper 4 bits) are given in the same
- *order as the devices are found on the bus.
- * - Up to 8 LUNs are supported for each target (if CONFIG_ACSI_MULTI_LUN
- *is defined), but only a total of 16 devices (due to minor
- *numbers...). Note that Atari allows only a maximum of 4 targets
- *(i.e. controllers, not devices) on the ACSI bus!
- * - A optimizing scheme similar to SCSI scatter-gather is implemented.
- * - Removable media are supported. After a medium change to device
- *is reinitialized (partition check etc.). Also, if the device
- *knows the PREVENT/ALLOW MEDIUM REMOVAL command, the door should
- *be locked and unlocked when mounting the first or unmounting the
- *last filesystem on the device. The code is untested, because I
- *don't have a removable hard disk.
- *
- */
-
-#include linux/module.h
-#include linux/errno.h
-#include linux/signal.h
-#include linux/timer.h
-#include linux/fs.h
-#include linux/kernel.h
-#include linux/genhd.h
-#include linux/delay.h
-#include linux/mm.h
-#include linux/major.h
-#include linux/slab.h
-#include linux/interrupt.h
-#include scsi/scsi.h /* for SCSI_IOCTL_GET_IDLUN */
-#include scsi/scsi_ioctl.h
-#include linux/hdreg.h /* for HDIO_GETGEO */
-#include linux/blkpg.h
-#include linux/buffer_head.h
-#include linux/blkdev.h
-
-#include asm/setup.h
-#include asm/pgtable.h
-#include asm/system.h
-#include asm/uaccess.h
-#include asm/atarihw.h
-#include asm/atariints.h
-#include asm/atari_acsi.h
-#include asm/atari_stdma.h
-#include asm/atari_stram.h
-
-static void (*do_acsi)(void) = NULL;
-static struct request_queue *acsi_queue;
-#define QUEUE (acsi_queue)
-#define CURRENT elv_next_request(acsi_queue)
-
-#define DEBUG
-#undef DEBUG_DETECT
-#undef NO_WRITE
-
-#define MAX_ERRORS 8/* Max read/write errors/sector */
-#define MAX_LUN8/* Max LUNs per target */
-#define MAX_DEV 16
-
-#define ACSI_BUFFER_SIZE(16*1024) /* normal ACSI buffer
size */
-#define ACSI_BUFFER_MINSIZE(2048) /* min. buf size if
ext. DMA */
-#define ACSI_BUFFER_SIZE_ORDER 2 /* order size for
above */
-#define ACSI_BUFFER_MINSIZE_ORDER0 /* order size for
above */
-#define ACSI_BUFFER_SECTORS(ACSI_BUFFER_SIZE/512)
-
-#define ACSI_BUFFER_ORDER \
-(ATARIHW_PRESENT(EXTD_DMA) ? \
- ACSI_BUFFER_MINSIZE_ORDER : \
- ACSI_BUFFER_SIZE_ORDER)
-
-#define ACSI_TIMEOUT(4*HZ)
-
-/* minimum delay between two commands */
-
-#define COMMAND_DELAY 500
-
-typedef enum {
-NONE, HARDDISK, CDROM
-} ACSI_TYPE;
-
-struct acsi_info_struct {
-ACSI_TYPEtype;/* type of device */
-unsignedtarget;/* target number */
-unsignedlun;/* LUN in target controller */
-unsignedremovable : 1;/* Flag for removable media */
-unsignedread_only : 1;/* Flag for read only devices */
-unsignedold_atari_disk : 1; /* Is an old Atari disk */
-unsignedchanged : 1;/* Medium has been changed */
-unsigned long size;/* #blocks */
-int access_count;
-} acsi_info[MAX_DEV];
-
-/*
- *SENSE KEYS
- */
-
-#define NO_SENSE0x00
-#define RECOVERED_ERROR 0x01
-#define NOT_READY0x02
-#define MEDIUM_ERROR0x03
-#define HARDWARE_ERROR0x04
-#define ILLEGAL_REQUEST
[PATCH] Remove of not compiling acsi.c
This drivers has not been compiling for a very long time and is not a
part of
any Makefile. Proof:
bh = CURRENT-bh;
Sign-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/block/acsi.c | 1825
--
1 files changed, 0 insertions(+), 1825 deletions(-)
delete mode 100644 drivers/block/acsi.c
diff --git a/drivers/block/acsi.c b/drivers/block/acsi.c
deleted file mode 100644
index e3d9152..000
--- a/drivers/block/acsi.c
+++ /dev/null
@@ -1,1825 +0,0 @@
-/*
- * acsi.c -- Device driver for Atari ACSI hard disks
- *
- * Copyright 1994 Roman Hodek [EMAIL PROTECTED]
- *
- * Some parts are based on hd.c by Linus Torvalds
- *
- * This file is subject to the terms and conditions of the GNU General
Public
- * License. See the file COPYING in the main directory of this archive for
- * more details.
- *
- */
-
-/*
- * Still to in this file:
- * - If a command ends with an error status (!= 0), the following
- *REQUEST SENSE commands (4 to fill the ST-DMA FIFO) are done by
- *polling the _IRQ signal (not interrupt-driven). This should be
- *avoided in future because it takes up a non-neglectible time in
- *the interrupt service routine while interrupts are disabled.
- *Maybe a timer interrupt will get lost :-(
- */
-
-/*
- * General notes:
- *
- * - All ACSI devices (disks, CD-ROMs, ...) use major number 28.
- *Minors are organized like it is with SCSI: The upper 4 bits
- *identify the device, the lower 4 bits the partition.
- *The device numbers (the upper 4 bits) are given in the same
- *order as the devices are found on the bus.
- * - Up to 8 LUNs are supported for each target (if CONFIG_ACSI_MULTI_LUN
- *is defined), but only a total of 16 devices (due to minor
- *numbers...). Note that Atari allows only a maximum of 4 targets
- *(i.e. controllers, not devices) on the ACSI bus!
- * - A optimizing scheme similar to SCSI scatter-gather is implemented.
- * - Removable media are supported. After a medium change to device
- *is reinitialized (partition check etc.). Also, if the device
- *knows the PREVENT/ALLOW MEDIUM REMOVAL command, the door should
- *be locked and unlocked when mounting the first or unmounting the
- *last filesystem on the device. The code is untested, because I
- *don't have a removable hard disk.
- *
- */
-
-#include linux/module.h
-#include linux/errno.h
-#include linux/signal.h
-#include linux/timer.h
-#include linux/fs.h
-#include linux/kernel.h
-#include linux/genhd.h
-#include linux/delay.h
-#include linux/mm.h
-#include linux/major.h
-#include linux/slab.h
-#include linux/interrupt.h
-#include scsi/scsi.h /* for SCSI_IOCTL_GET_IDLUN */
-#include scsi/scsi_ioctl.h
-#include linux/hdreg.h /* for HDIO_GETGEO */
-#include linux/blkpg.h
-#include linux/buffer_head.h
-#include linux/blkdev.h
-
-#include asm/setup.h
-#include asm/pgtable.h
-#include asm/system.h
-#include asm/uaccess.h
-#include asm/atarihw.h
-#include asm/atariints.h
-#include asm/atari_acsi.h
-#include asm/atari_stdma.h
-#include asm/atari_stram.h
-
-static void (*do_acsi)(void) = NULL;
-static struct request_queue *acsi_queue;
-#define QUEUE (acsi_queue)
-#define CURRENT elv_next_request(acsi_queue)
-
-#define DEBUG
-#undef DEBUG_DETECT
-#undef NO_WRITE
-
-#define MAX_ERRORS 8/* Max read/write errors/sector */
-#define MAX_LUN8/* Max LUNs per target */
-#define MAX_DEV 16
-
-#define ACSI_BUFFER_SIZE(16*1024) /* normal ACSI buffer
size */
-#define ACSI_BUFFER_MINSIZE(2048) /* min. buf size if
ext. DMA */
-#define ACSI_BUFFER_SIZE_ORDER 2 /* order size for
above */
-#define ACSI_BUFFER_MINSIZE_ORDER0 /* order size for
above */
-#define ACSI_BUFFER_SECTORS(ACSI_BUFFER_SIZE/512)
-
-#define ACSI_BUFFER_ORDER \
-(ATARIHW_PRESENT(EXTD_DMA) ? \
- ACSI_BUFFER_MINSIZE_ORDER : \
- ACSI_BUFFER_SIZE_ORDER)
-
-#define ACSI_TIMEOUT(4*HZ)
-
-/* minimum delay between two commands */
-
-#define COMMAND_DELAY 500
-
-typedef enum {
-NONE, HARDDISK, CDROM
-} ACSI_TYPE;
-
-struct acsi_info_struct {
-ACSI_TYPEtype;/* type of device */
-unsignedtarget;/* target number */
-unsignedlun;/* LUN in target controller */
-unsignedremovable : 1;/* Flag for removable media */
-unsignedread_only : 1;/* Flag for read only devices */
-unsignedold_atari_disk : 1; /* Is an old Atari disk */
-unsignedchanged : 1;/* Medium has been changed */
-unsigned long size;/* #blocks */
-int access_count;
-} acsi_info[MAX_DEV];
-
-/*
- *SENSE KEYS
- */
-
-#define NO_SENSE0x00
-#define RECOVERED_ERROR 0x01
-#define NOT_READY0x02
-#define MEDIUM_ERROR0x03
-#define HARDWARE_ERROR0x04
-#define ILLEGAL_REQUEST
Re: [patch 0/5] m68k 53c700 SCSI
On Sun, Jun 17, 2007 at 02:47:04PM +0200, Geert Uytterhoeven wrote: Hi James, These patches add support for m68k to the 53c700 SCSI core and introduce new drivers for various m68k hardware using this 53c700 SCSI core, to replace the just removed drivers using the old 53c7xx SCSI core. [1] [PATCH] 53c700 scsi: m68k support for the 53c700 SCSI core [2] [PATCH] 53c700 scsi: m68k BVME6000 NCR53C710 SCSI [3] [PATCH] 53c700 scsi: m68k MVME16x NCR53C710 SCSI [4] [PATCH] 53c700 scsi: Amiga 4000T NCR53c710 SCSI [5] [PATCH] 53c700 scsi: Amiga Zorro NCR53c710 SCSI Please apply for 2.6.23. Thx! The patches all look very nice to me, thanks a lot. - 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] aacraid: change srb status busy return
On Tue, 2007-06-19 at 11:41 -0400, Salyzyn, Mark wrote: This patch is more like a spelling correction than a fix. It was discovered that if we had a busy status return from the Adapter for the SCSI srb command to a physical component, that we returned DID_NO_CONNECT rather than what one would expect DID_BUS_BUSY. Are you sure you want DID_BUS_BUSY? I'm just asking because I'm not sure of the firmware ramifications. DID_BUS_BUSY will turn the command around for an immediate retry. If there's a firmware resource issue, you should return something like DID_REQUEUE which will throttle the queue and reissue this command when another one returns (I'm afraid it throttles the device queue, not the host queue, which may not be what you want but we can add another DID_HOST_REQUEUE or something). James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] cciss: add new controller support for P700m
On Tue, Jun 19 2007, Mike Miller (OS Dev) wrote: PATCH 1/1 This patch adds support for the Smart Array P700m SAS controller. This new controller will ship Fall 2008. Please consider this for inclusion. Fall 2007? Queued for 2.6.23. -- 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] aacraid: change srb status busy return
James Bottomley mailto:[EMAIL PROTECTED] sez: On Tue, 2007-06-19 at 11:41 -0400, Salyzyn, Mark wrote: It was discovered that if we had a busy status return from the Adapter for the SCSI srb command to a physical component, that we returned DID_NO_CONNECT rather than what one would expect DID_BUS_BUSY. Are you sure you want DID_BUS_BUSY? I'm just asking because I'm not sure of the firmware ramifications. DID_BUS_BUSY will turn the command around for an immediate retry. If there's a firmware resource issue, you should return something like DID_REQUEUE which will throttle the queue and reissue this command when another one returns. Thanks for noting this. I believe that this is the behavior we want. This is related to a SCSI pass-through to the physical targets. I see no dummied-up returns of SRB_STATUS_BUSY from the top all the way down to the CHIM. This is a report from the physical bus or end device and thus does not represent an Adapter resource limit. Immediate re-queuing is indicated. I noticed this issue when we were talking internally about mitigating the sequential queuing of commands to SATA ATAPI devices at the CHIM level. A long command (erase CD for example) issued by an application was followed by a test unit ready with a short timeout issued by the Linux device class layer for media checking and we ended up timing out the test unit ready. I had suggested, in violation of the sat specification, to return the test unit ready with SRB_STATUS_BUSY when timed out prior to even making it to the physical transport while sitting in the sequential queue. Thus I noticed the shortcoming in the driver regarding the recent ( 2.6.10) addition of this return value. The CHIM folks balked at a spoofed SRB_STATUS_BUSY response. Even though the workaround was not accepted, this scenario would still be acceptable for immediate re-queuing. Sincerely -- Mark Salyzyn - 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
