[PATCH] dc395x: fix section references
dc395x scsi driver makes many references to __init functions &
__initdata that should be __devinit & __devinitdata.
Error: ./drivers/scsi/dc395x.o .text refers to 21ef R_X86_64_PC32
.init.text+0x00b4
Error: ./drivers/scsi/dc395x.o .text refers to 220e R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 222e R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 22f4 R_X86_64_PC32
.init.text+0x0177
Error: ./drivers/scsi/dc395x.o .text refers to 2301 R_X86_64_32S
.init.data
Error: ./drivers/scsi/dc395x.o .text refers to 2307 R_X86_64_32S
.init.data+0x0004
Error: ./drivers/scsi/dc395x.o .text refers to 230f R_X86_64_32S
.init.data+0x0008
Error: ./drivers/scsi/dc395x.o .text refers to 2317 R_X86_64_32S
.init.data+0x000c
Error: ./drivers/scsi/dc395x.o .text refers to 231d R_X86_64_32S
.init.data
Error: ./drivers/scsi/dc395x.o .text refers to 232d R_X86_64_PC32
.init.text+0xfffc
Error: ./drivers/scsi/dc395x.o .text refers to 237a R_X86_64_PC32
.init.text+0x00b4
Error: ./drivers/scsi/dc395x.o .text refers to 238c R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 23ac R_X86_64_PC32
.init.text+0x00b4
Error: ./drivers/scsi/dc395x.o .text refers to 23d6 R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 23e6 R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 23fe R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 240b R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 2418 R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 242f R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 243f R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 2469 R_X86_64_PC32
.init.text+0x00b4
Error: ./drivers/scsi/dc395x.o .text refers to 2476 R_X86_64_PC32
.init.text+0x009c
Error: ./drivers/scsi/dc395x.o .text refers to 2489 R_X86_64_PC32
.init.data+0x0060
Error: ./drivers/scsi/dc395x.o .text refers to 2494 R_X86_64_PC32
.init.text+0x0177
Error: ./drivers/scsi/dc395x.o .text refers to 24a3 R_X86_64_32S
.init.data+0x0078
Error: ./drivers/scsi/dc395x.o .text refers to 24ac R_X86_64_PC32
.init.text+0xfffc
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
drivers/scsi/dc395x.c | 42 +-
1 files changed, 21 insertions(+), 21 deletions(-)
diff -Naurp ./drivers/scsi/dc395x.c~dc395x_sections ./drivers/scsi/dc395x.c
--- ./drivers/scsi/dc395x.c~dc395x_sections 2004-12-24 13:34:00.0
-0800
+++ ./drivers/scsi/dc395x.c 2005-02-27 20:30:11.539816904 -0800
@@ -488,7 +488,7 @@ struct ParameterData {
int def;/* default value */
int safe; /* safe value */
};
-static struct ParameterData __initdata cfg_data[] = {
+static struct ParameterData __devinitdata cfg_data[] = {
{ /* adapter id */
CFG_PARAM_UNSET,
0,
@@ -573,7 +573,7 @@ MODULE_PARM_DESC(reset_delay, "Reset del
* set_safe_settings - if the use_safe_settings option is set then
* set all values to the safe and slow values.
**/
-static void __init set_safe_settings(void)
+static void __devinit set_safe_settings(void)
{
if (use_safe_settings)
{
@@ -592,7 +592,7 @@ static void __init set_safe_settings(voi
* fix_settings - reset any boot parameters which are out of range
* back to the default values.
**/
-static void __init fix_settings(void)
+static void __devinit fix_settings(void)
{
int i;
@@ -619,7 +619,7 @@ static void __init fix_settings(void)
* Mapping from the eeprom delay index value (index into this array)
* to the the number of actual seconds that the delay should be for.
*/
-static char __initdata eeprom_index_to_delay_map[] =
+static char __devinitdata eeprom_index_to_delay_map[] =
{ 1, 3, 5, 10, 16, 30, 60, 120 };
@@ -629,7 +629,7 @@ static char __initdata eeprom_index_to_d
*
* @eeprom: The eeprom structure in which we find the delay index to map.
**/
-static void __init eeprom_index_to_delay(struct NvRamType *eeprom)
+static void __devinit eeprom_index_to_delay(struct NvRamType *
Re: [2.6.11-rc4-mm1 patch] drivers/scsi/arcmsr/arcmsr.c cleanups
On Sun, Feb 27, 2005 at 04:48:10PM +0100, Adrian Bunk wrote: > - aren't the "if defined(__x86_64__)" wrong for other 64bit > architectures? Yes. Having arch or 64bit ifdefs is pretty wrong pretty much always. In one case it's only used to make a typedef a 32bit or 64bit integeger, that should be using unsigned long directly always, but the other uses looks like real problems. - 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: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Fri, 25 Feb 2005, Gerhard Schneider wrote: > On Thu, 2005-02-24 at 23:00 +0200, Kai Makisara wrote: > > > > > > Sounds strange but the following things come into my mind: > > - Check from the dmesg output and/or system logs what SCSI transfer > > settings the tape drive and the SCSI adapter negotiate. The speed should > > not change when you add the Megaraid controller. If you don't find the > > value before adding it, you can check that the current value is at least > > 40 MB/s (probably more). > Not so easy. The megaraid driver doesn't tell you that > I hope Seokmann can give you some information about this. ... > > - Enable debugging in the st driver (change DEBUG to 1 in st.c, recompile, > > reload the module). In the normal case st should not print many debugging > > message (some when the device is opened at some when it is closed). > > Now the full story: > > st: Version 20050213, fixed bufsize 32768, s/g segs 256 > Attached scsi tape st0 at scsi0, channel 0, id 6, lun 0 normal output cut > st0: Number of r/w requests 127685, dio used in 127685, pages 383055 This shows that your application is not using very large block size (3 pages, 10 kB?). You might get better throughput with larger block size (32 kB or 64 kB is usually large enough). If the Megaraid command processing speed is not fast enough, this might explain the problem (not probable but I can't see any probable problems ;-) The messages look OK. There is nothing that should not be there. -- Kai - 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] iSCSI Initiator Core Stack v1.6.1.20
AJ Lewis wrote: "Nicholas A. Bellinger" <[EMAIL PROTECTED]> writes: > The following is the first public release of the PyX Technologies iSCSI > Initiator Core Stack v1.6.1.20 for Linux 2.6.11-rc4. This is a full > featured iSCSI Initiator stack that is capable of mulitplexing coast to > coast across multiple independant backbone providers using various > network transports _TODAY_. This is the first release of the core stack > and assoicated userspace tools, the accompanying authentication daemon > will be released shortly. Very cool - glad you're releasing this. I've gotten this setup and running, but I can't seem to talk to my iscsi target. The initiator detects it, but it can't recognize the type: iCHANNEL[0] - No defined iSCSI Authentication Methods, skipping SecurityNegotiation phase. iCHANNEL[0] - iSCSI login successful on CID: 0 to 192.168.44.19:3260,2 iCHANNEL[0] - Incremented iSCSI connection count to 1 to node: iqn.1992-08.com.netapp:sn.33615311 iCHANNEL[0] - Established iSCSI session to node: iqn.1992-08.com.netapp:sn.33615311 iSCSI Core Stack[1] - Incremented number of active iSCSI sessions to 1. scsi: unknown device type 31 Vendor: NETAPPModel: LUN Rev: 0.2 Type: UnknownANSI SCSI revision: 04 Any ideas on why this wouldn't be working? Is there a configuration step I'm missing? Make sure the initiator name is in the igroup on the filer for any luns that you want mapped to the intiator. I think what you're seeing is not a real LUN, but the config LUN or something like that, probably the result of the initiator name not being in the igroup (see "igroup add" command on the filer). Also, are you planning on updating the docs for the user tools at all? There are several steps missing in the current README, and the man page lists some parameters incorrectly and misses other entirely. I'm looking forward to getting this working. -- AJ Lewis Voice: 612-638-0500 Red Hat Inc. E-Mail: [EMAIL PROTECTED] 720 Washington Ave. SE, Suite 200 Minneapolis, MN 55414 Current GPG fingerprint = D9F8 EDCE 4242 855F A03D 9B63 F50C 54A8 578C 8715 Grab the key at: http://people.redhat.com/alewis/gpg.html or one of the many keyservers out there... - 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
[2.6.11-rc4-mm1 patch] drivers/scsi/arcmsr/arcmsr.c cleanups
On Wed, Feb 23, 2005 at 01:42:33AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc3-mm1:
>...
> +areca-raid-linux-scsi-driver-fix.patch
>
> New RAID driver (this patch is having a hard life and needs a re-review)
>...
This patch contains the following cleanups:
- make needlessly global functions static
- move arcmsr_scsi_host_template from arcmsr.h to arcmsr.c
(code doesn't belong into header files)
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Some notes:
- BOOLEAN/TRUE/FALSE, own get_min/get_max aren't kernel coding style
- the own subdirectory for this driver seems to be overkill
- aren't the "if defined(__x86_64__)" wrong for other 64bit
architectures?
drivers/scsi/arcmsr/arcmsr.c | 110 +++
drivers/scsi/arcmsr/arcmsr.h | 34 --
2 files changed, 73 insertions(+), 71 deletions(-)
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/arcmsr/arcmsr.h.old 2005-02-27
16:06:56.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/arcmsr/arcmsr.h 2005-02-27
16:06:25.0 +0100
@@ -4802,38 +4802,4 @@
**(E) Checksum : checksum of length and status or data byte
**
*/
-extern int arcmsr_proc_info(struct Scsi_Host *host, char *buffer, char **start,
- off_t offset, int length, int inout);
-extern int arcmsr_bios_param(struct scsi_device *sdev,
-struct block_device *bdev, sector_t capacity,
-int *info);
-extern int arcmsr_release(struct Scsi_Host *);
-extern int arcmsr_queue_command(Scsi_Cmnd * cmd, void (*done) (Scsi_Cmnd *));
-extern int arcmsr_cmd_abort(Scsi_Cmnd *);
-extern int arcmsr_bus_reset(Scsi_Cmnd *);
-extern int arcmsr_ioctl(Scsi_Device * dev, int ioctl_cmd, void *arg);
-extern const char *arcmsr_info(struct Scsi_Host *);
-static Scsi_Host_Template arcmsr_scsi_host_template = {
- .module = THIS_MODULE,
- .proc_name = "arcmsr",
- .proc_info = arcmsr_proc_info,
- .name = "ARCMSR ARECA SATA RAID HOST Adapter" ARCMSR_DRIVER_VERSION,
/* *name */
- .release = arcmsr_release,
- .info = arcmsr_info,
- .ioctl = arcmsr_ioctl,
- .queuecommand = arcmsr_queue_command,
- .eh_strategy_handler = NULL,
- .eh_abort_handler = arcmsr_cmd_abort,
- .eh_device_reset_handler = NULL,
- .eh_bus_reset_handler = arcmsr_bus_reset,
- .eh_host_reset_handler = NULL,
- .bios_param = arcmsr_bios_param,
- .can_queue = ARCMSR_MAX_OUTSTANDING_CMD,
- .this_id = ARCMSR_SCSI_INITIATOR_ID,
- .sg_tablesize = ARCMSR_MAX_SG_ENTRIES,
- .max_sectors = ARCMSR_MAX_XFER_SECTORS,
- .cmd_per_lun = ARCMSR_MAX_CMD_PERLUN,
- .unchecked_isa_dma = 0,
- .use_clustering = DISABLE_CLUSTERING,
-};
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/arcmsr/arcmsr.c.old 2005-02-27
16:06:52.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/arcmsr/arcmsr.c 2005-02-27
16:06:25.0 +0100
@@ -121,15 +121,26 @@
static int arcmsr_halt_notify(struct notifier_block *nb, unsigned long event,
void *buf);
static void arcmsr_free_pci_pool(PACB pACB);
-void arcmsr_pcidev_disattach(PACB pACB);
-BOOLEAN arcmsr_wait_msgint_ready(PACB pACB);
-void arcmsr_iop_init(PACB pACB);
-int arcmsr_iop_ioctlcmd(PACB pACB, int ioctl_cmd, void *arg);
-int arcmsr_initialize(PACB pACB, struct pci_dev *pPCI_DEV);
+static void arcmsr_pcidev_disattach(PACB pACB);
+static void arcmsr_iop_init(PACB pACB);
+static int arcmsr_iop_ioctlcmd(PACB pACB, int ioctl_cmd, void *arg);
+static int arcmsr_initialize(PACB pACB, struct pci_dev *pPCI_DEV);
static irqreturn_t arcmsr_HwInterrupt(PACB pACB);
static int arcmsr_device_probe(struct pci_dev *pPCI_DEV,
const struct pci_device_id *id);
static void arcmsr_device_remove(struct pci_dev *pPCI_DEV);
+static int arcmsr_bios_param(struct scsi_device *sdev,
+struct block_device *bdev,
+sector_t capacity, int *geom);
+static int arcmsr_bus_reset(Scsi_Cmnd * cmd);
+static int arcmsr_cmd_abort(Scsi_Cmnd * cmd);
+static const char *arcmsr_info(struct Scsi_Host *host);
+static int arcmsr_ioctl(Scsi_Device * dev, int ioctl_cmd, void *arg);
+static int arcmsr_proc_info(struct Scsi_Host *host, char *buffer, char **start,
+ off_t offset, int length, int inout);
+static int arcmsr_queue_command(Scsi_Cmnd * cmd, void (*done) (Scsi_Cmnd *));
+static int arcmsr_release(struct Scsi_Host *host);
+
/*
**
**
@@ -169,13 +180,37 @@
};
MODULE_DEVICE_TABLE(pci, arcmsr_device_id_table);
-struct pci_driver arcmsr_pci_driver = {
+static struct pci_driver arcmsr_pci_driver = {
.name = "arcmsr",
.id_table = arcmsr_device_id_table,
.probe = arcmsr_device_pr
Re: Problem with tape drive: illegal seek
Thanks to you both! Indeed, "dd" works when bs=10k, and tar works as long as you don't try to auto-compare it. I'll look into using --compare instead, thanks. I wonder if this is a bug or feature in tar? Should I report it? -- Regards, Christian Iversen - 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
