[2.6 patch] SCSI NCR_D700.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/NCR_D700.c.old 2005-02-27
01:03:50.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/NCR_D700.c 2005-02-27
01:04:25.0 +0100
@@ -106,7 +106,7 @@
#include "53c700.h"
#include "NCR_D700.h"
-char *NCR_D700;/* command line from insmod */
+static char *NCR_D700; /* command line from insmod */
MODULE_AUTHOR("James Bottomley");
MODULE_DESCRIPTION("NCR Dual700 SCSI Driver");
@@ -352,7 +352,7 @@
static short NCR_D700_id_table[] = { NCR_D700_MCA_ID, 0 };
-struct mca_driver NCR_D700_driver = {
+static struct mca_driver NCR_D700_driver = {
.id_table = NCR_D700_id_table,
.driver = {
.name = "NCR_D700",
-
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 patch] drivers/scsi/aacraid/: cleanups
This patch contains the following cleanups:
- make needlessly global functions static
- commsup.c: remove the unused global function aac_consumer_avail
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/scsi/aacraid/aachba.c | 10 +-
drivers/scsi/aacraid/aacraid.h |2 --
drivers/scsi/aacraid/commctrl.c |4 ++--
drivers/scsi/aacraid/comminit.c |2 +-
drivers/scsi/aacraid/commsup.c |7 +--
drivers/scsi/aacraid/linit.c|2 +-
drivers/scsi/aacraid/sa.c |2 +-
7 files changed, 11 insertions(+), 18 deletions(-)
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/aachba.c.old 2005-02-27
01:05:38.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/aachba.c 2005-02-27
01:06:18.0 +0100
@@ -560,10 +560,10 @@
inqstrcpy ("V1.0", str->prl);
}
-void set_sense(u8 *sense_buf, u8 sense_key, u8 sense_code,
- u8 a_sense_code, u8 incorrect_length,
- u8 bit_pointer, u16 field_pointer,
- u32 residue)
+static void set_sense(u8 *sense_buf, u8 sense_key, u8 sense_code,
+ u8 a_sense_code, u8 incorrect_length,
+ u8 bit_pointer, u16 field_pointer,
+ u32 residue)
{
sense_buf[0] = 0xF0;/* Sense data valid, err code 70h (current
error) */
sense_buf[1] = 0; /* Segment number, always zero */
@@ -807,7 +807,7 @@
aac_io_done(scsicmd);
}
-int aac_read(struct scsi_cmnd * scsicmd, int cid)
+static int aac_read(struct scsi_cmnd * scsicmd, int cid)
{
u32 lba;
u32 count;
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/commctrl.c.old
2005-02-27 01:06:31.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/commctrl.c 2005-02-27
01:07:03.0 +0100
@@ -403,7 +403,7 @@
*
*/
-int aac_send_raw_srb(struct aac_dev* dev, void __user * arg)
+static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg)
{
struct fib* srbfib;
int status;
@@ -621,7 +621,7 @@
};
-int aac_get_pci_info(struct aac_dev* dev, void __user *arg)
+static int aac_get_pci_info(struct aac_dev* dev, void __user *arg)
{
struct aac_pci_info pci_info;
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/comminit.c.old
2005-02-27 01:07:25.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/comminit.c 2005-02-27
01:07:34.0 +0100
@@ -204,7 +204,7 @@
* 0 - If there were errors initing. This is a fatal error.
*/
-int aac_comm_init(struct aac_dev * dev)
+static int aac_comm_init(struct aac_dev * dev)
{
unsigned long hdrsize = (sizeof(u32) * NUMBER_OF_COMM_QUEUES) * 2;
unsigned long queuesize = sizeof(struct aac_entry) *
TOTAL_QUEUE_ENTRIES;
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/aacraid.h.old
2005-02-27 01:04:59.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/aacraid.h2005-02-27
01:09:03.0 +0100
@@ -1595,11 +1595,9 @@
void fib_map_free(struct aac_dev *dev);
void fib_free(struct fib * context);
void fib_init(struct fib * context);
-void fib_dealloc(struct fib * context);
void aac_printf(struct aac_dev *dev, u32 val);
int fib_send(u16 command, struct fib * context, unsigned long size, int
priority, int wait, int reply, fib_callback callback, void *ctxt);
int aac_consumer_get(struct aac_dev * dev, struct aac_queue * q, struct
aac_entry **entry);
-int aac_consumer_avail(struct aac_dev * dev, struct aac_queue * q);
void aac_consumer_free(struct aac_dev * dev, struct aac_queue * q, u32 qnum);
int fib_complete(struct fib * context);
#define fib_data(fibctx) ((void *)(fibctx)->hw_fib->data)
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/commsup.c.old
2005-02-27 01:08:23.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/commsup.c2005-02-27
01:09:11.0 +0100
@@ -210,7 +210,7 @@
* caller.
*/
-void fib_dealloc(struct fib * fibptr)
+static void fib_dealloc(struct fib * fibptr)
{
struct hw_fib *hw_fib = fibptr->hw_fib;
if(hw_fib->header.StructType != FIB_MAGIC)
@@ -566,11 +566,6 @@
return(status);
}
-int aac_consumer_avail(struct aac_dev *dev, struct aac_queue * q)
-{
- return (le32_to_cpu(*q->headers.producer) !=
le32_to_cpu(*q->headers.consumer));
-}
-
/**
* aac_consumer_free - free consumer entry
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/linit.c.old 2005-02-27
01:09:30.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/linit.c 2005-02-27
01:09:38.0 +0100
@@ -215,7 +215,7 @@
* Returns a static string describing the device in question
*/
-const char *aac_info(struct Scsi_Host *shost)
+static const char *aac_info(struct Scsi_Host *shost)
{
struct aac_dev *dev = (struct aac_dev *)shost->hostdata;
return aac_drivers[dev->cardtype].name;
--- linux-2.6.11-rc4-mm1-full/d
Re: SYM8xx_2 driver ignores certain EEPROM settings
Greetings! Now that producing another pair of coasters reminded me that this here system has a problem on SCSI branch 1, I'd like to inquire about the current state of affairs regarding this topic. (Also, I've encountered another machine I'd like to upgrade to a newer Linux kernel but can't since it's using this very feature-that-went-missing.) Is there a patch I can install and try out, or anything else I can do? best regards, Peter Missel On Friday 31 December 2004 15:53, Matthew Wilcox wrote: > On Fri, Dec 31, 2004 at 01:43:42PM +0100, Peter Missel wrote: > > Hello Matthew! > > > > I hope I'm turning to the right person with my report. > > Yep, that's me. Best to keep linux-scsi in the loop too. That way > other people prod me when I've been inattentive ;-) > > > After updating to SuSE > > Linux 9.2, kernel 2.6.8, which brought rev. 2.1.18j of the LSI SCSI > > driver, I see that the driver's speed/width negotiation no longer > > considers any limitations configured in the adapter's BIOS. My previous > > installation, using kernel 2.4.20 and its included LSI SCSI driver, did > > that perfectly fine. > > Yes, that's right. I'm not a big fan of dealing with distro kernels > because they make changes without informing me. An earlier SuSE kernel > commented out the domain validation calls from the sym2 driver -- without > putting the previous code back in. However, that problem doesn't seem to > be present in this kernel. > > > For example (and that's why I noticed), if in SCSI BIOS a certain SCSI > > channel (or a single device) has been limited by the user to 10 MT/s, the > > Linux SCSI driver nonetheless negotiates to 20 MT/s. > > > > It is necessary to stick to the settings from BIOS (as read from EEPROM), > > simply because there might be a good reason why the user did that. In my > > particular case, I need to restrict the sym0 channel from doing Ultra (20 > > MT/s) altogether because the total cable length doesn't allow me to, > > The Domain Validation code is supposed to catch problems like this, and > automatically fall back to a setting that works without requiring the > user to set magic bits in their NVRAM. Are you actually experiencing > problems due to the faster speed, or is it just that you know the cable > is out of spec? > > Hm, I see we skip the write tests, presumably because the drive doesn't > support a write buffer. Drat. > > > and I > > have one device restricted further to 5 MT/s because I own a buggy > > Fujitsu MO that claims 10 MT/s capability but (according to Fujitsu's > > support answer back when I bought it) has a SCSI interface chip on that > > can't actually do that. > > Buggy drive firmware keeps on biting us ;-( It does seem worth honouring > the NVRAM settings, but the thing is that we then have to support such > fixes in each driver. > > > Below please see a snippet from /var/log/boot.msg; the external branch > > (including the MO) is disconnected so I can use the system at all. You > > can still see from dev 0.0.1.0 that 20 MT/s are being set up although the > > adapter's EEPROM settings mandate a maximum of 10 MT/s for the entire > > sym0 channel. Also, in line 5 of the snippet, you see the sym0 host is > > being logged as "Fast-40 SE" which should read lower. The "SCAN AT BOOT" > > parameter from the same EEPROM is read correctly. > > > > Being a system BIOS developper, I have the means to do an EEPROM dump of > > my SCSI adapter. So in case this is helpful to you, I'll do that as soon > > as I'm back to work on Jan 10. > > I don't need you to do that -- I know the ability has been removed from the > driver. I bet I can put it back without disturbing things too much. > > > <5>SCSI subsystem initialized > > <6>ACPI: PCI interrupt :00:0a.0[A] -> GSI 18 (level, low) -> IRQ 169 > > <6>sym0: <896> rev 0x5 at pci :00:0a.0 irq 169 > > <6>sym0: using 64 bit DMA addressing > > <4>sym0: Symbios NVRAM, ID 7, Fast-40, SE, parity checking > > <4>sym0: SCAN AT BOOT disabled for targets 2 3 8 9 10 11 12 13 14 15. > > <5>sym0: SCSI BUS has been reset. > > <6>scsi0 : sym-2.1.18j > > <5> Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 > > <5> Type: CD-ROM ANSI SCSI revision: 02 > > <6>scsi(0:0:0:0): Beginning Domain Validation > > <6>sym0:0: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 15) > > <6>scsi(0:0:0:0): Domain Validation skipping write tests > > <6>scsi(0:0:0:0): Ending Domain Validation > > <5> Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 > > <5> Type: CD-ROM ANSI SCSI revision: 02 > > <6>scsi(0:0:0:1): Beginning Domain Validation > > <6>sym0:0: asynchronous. > > <6>sym0:0: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 15) > > <6>scsi(0:0:0:1): Domain Validation skipping write tests > > <6>scsi(0:0:0:1): Ending Domain Validation > > <5> Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02 > > <5> Type: CD-ROM ANSI SCSI revision: 02 > > <6>scsi(0:0:
RE:
- 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
Please, does anybody have BIOS/Firmware for aha1542B/C ?
I apologize for writing to "linux" scsi list asking if anybody has such-and-such that doesnt directly help linux... I have an AHA-1542B (a common model of controller, seemingly) and some AHA-1542CF's (quite different physically), Seems to be one of the best in its' class (AT-bus master!)... I have some SCSI disks whose instructions state that they are not compatible with the AHA-1542B controller (something like that) unless you upgrade the BIOS/microcode pair to have a "B56" version of the controller or something like that. Unfortunately, adaptec USED to list the BIOS+firmware for the AHA1542B at least, but then stopped doing so! aargh!. I'd like to "have it" and will happily give files to others who need it, etc. In short, I would really appreciate if anybody who has AHA-1542 upgrade ROM files (any of them really, B or C etc..., to use I'm not expecting to get over 8gb disk translation facility (i.e. no extended int13-LBA), but particuarly on the AHA-1542B a newer BIOS would be nice... I expect to put this on EPROM/flash IC and stick in, since these cards do not use flashable chip normally). Please, please let me know if you have such rom upgrade files. Somewhere, somebody, out there! Please write to me off this list if you can help... Or point me in the right direction. Thankyou in advance, and apologies for people who aren't interested! --S Iremonger <[EMAIL PROTECTED]> - 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: Problem with tape drive: illegal seek
On Sat, 26 Feb 2005, Christian Iversen wrote: > > Whenever I use --verify for tar, I get problems. Specifically, I get > "Illegal seek" when tar gets to the verify phase. > I looked at tar 1.13.25 sources and this looks like a tar bug: verify from tape does not work for the first file (and I am not sure about other files). After writing, tar tries to skip backwards over two filemarks. When writing the first file, there is no second filemark to skip over: this fails and gives you the error. If you do verify with a second call to tar (tar --compare) after skipping backwards with mt, this should work. ... > Please note that I can restore the data just fine, if I use tar. If I try to > use dd, I get strange errors as well: > > [EMAIL PROTECTED]/tmp #dd if=/dev/tape of=dump > dd: reading `/dev/tape': Cannot allocate memory > 0+0 records in > 0+0 records out > 0 bytes transferred in 3,699040 seconds (0 bytes/sec) > Guy already solved this problem. The message (Cannot allocate memory) is not very clear but this is what other Unices use. -- 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
