Re: Add ACCUSYS RAID driver for Linux i386/x86-64
On Thu, 30 Aug 2007 13:45:06 +0800 Peter Chan 詹家昌 <[EMAIL PROTECTED]> wrote:
> Dear Morton
>
> ACCUSYS Inc dedicated to design PCI-e RAID HBA, hence we would like to
> provide our driver bundle in kernel 2.6 for user.
Thank you!
> Could you kindly take a look attached file if it looks like Linux Driver?
It looks a bit like a Linux driver ;) More on this below.
> If you need the RAID card to verify please let me know.
I personally am unlikely to make the time to test a specific HBA driver.
But perhaps James or one of the other scsi developers (or any developer at
all) might like to volunteer to help out with testing, in which case yes,
please do send out a card or two.
First up, please become familar with the way in which we handle code patches.
I'd suggest that you subscribe to the linux-kernel or linux-scsi mailing
lists for a while, watch how other people prepare and present their patches.
Download, install and become familiar with quilt
(http://savannah.nongnu.org/projects/quilt) and use that to prepare patches.
quilt can also be used to email patches which might prove useful: new
kernel developers frequently have trouble with wordwrapping, tab-to-space
conversion and other ways in which mail clients corrupt patches.
Once you have quilt up and running you should convert this driver into a
single patch against Linus's latest kernel. At this time, that is
2.6.23-rc4.
That patch should include the appropriate changes to drivers/scsi/Kconfig
and drivers/scsi/Makefile to wire this driver up to the kernel
configuration and build system. (You may choose to create a separate
directory drivers/scsi/acs_ame/ for this driver).
Once we reach this stage, we have a patch which others can apply, test and
review. Review will be the first step.
Your driver isn't ready for review yet. There are a number of minor but
often-repeated problems which will require extensive changes to correct.
They're silly little things and they won't change the operation of the driver
at all, but it is best to get the driver looking and feeling like a typical
driver before we ask reviewers to start taking a serious look at the code.
- No c++-style comments, please. Replace all // with /* .. */
- there's some commented-out and obviously dead code. Things like
//#include //void sema_init
//DECLARE_MUTEX(name)
//DECLARE_MUTEX_LOCKED(name)
//#include // read /write semaphore
// Why lock_kernel
//#include
//lock_kernel();
//#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,60)
daemonize();
//#else
//daemonize("arcmsr kernel thread");
//#endif
// unlock_kernel();
//Use unsigned long as a pointer
// cause of size(unsigend long) always equal to pointer size under all linux
compatible platform
just delete all that, please.
- CHAR_DEV and EVENTSWITCH_ON should probably become CONFIG variables
(set in drivers/scsi/Kconfig)
- try to keep the code fitting nicely in an 80-column display
- Identifiers like RequestNode and RemapPCIMem should be renamed
request_node and remap_pci_mem if at all possible. We use underscores to
separate "words" within an identifier, not capital letters.
- Once you have a cleaned up patch, please pass that patch through
scripts/checkpatch.pl.
I just turned acs_ame.c, acs_ame.h and ame.h into a patch and fed it
through checkpatch.pl. Please see the result at
http://userweb.kernel.org/~akpm/x.txt.
(For those who are curious, the patch is at
http://userweb.kernel.org/~akpm/a.patch)
We have about 4,000 warnings there ;) Actually, a huge number of those
warnings are incorrect (trailing whitespace). checkpatch is still under
development a bit.
But still, there are a lot of things in the checkpatch output which can
and should be fixed up.
All together I expect that after one or maybe two days work, you will have
a driver patch which is ready to be applied to the kernel and is ready to
be reviewed by kernel and scsi experts.
At that stage we will be able to get into more substantial details such as
the use of the scsi APIs, the DMA APIs, locking, commenting, design, etc.
I'd expect that further changes will be made to the driver as a result of
that discussion, but they will improve the code.
When sending new versions of the patch, please send them to
Andrew Morton <[EMAIL PROTECTED]>
James Bottomley <[EMAIL PROTECTED]>
linux-scsi@vger.kernel.org
[EMAIL PROTECTED]
The way this driver will enter the 2.6 kernel is from you, into James's
scsi-misc git tree and then from James's scsi-misc tree into Linus's git
tree. It is possible that I'll take a copy into my -mm tree for some early
testing but it is unlikely that I would send a scsi patch directly into
Linus - James does that.
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] SCSI: Remove references to dead "st0x" and "tmc8xx" kernel parms.
Since these two kernel parameters don't appear to be supported, remove the useless references to them. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |6 -- drivers/scsi/seagate.c | 11 --- 2 files changed, 17 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index b41cde3..9f2638c 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1766,9 +1766,6 @@ and is between 256 and 4096 characters. It is defined in the file st= [HW,SCSI] SCSI tape parameters (buffers, etc.) See Documentation/scsi/st.txt. - st0x= [HW,SCSI] - See header of drivers/scsi/seagate.c. - sti=[PARISC,HW] Format: Set the STI (builtin display/keyboard on the HP-PARISC @@ -1853,9 +1850,6 @@ and is between 256 and 4096 characters. It is defined in the file tipar.delay=[HW,PPT] Set inter-bit delay in microseconds (default 10). - tmc8xx= [HW,SCSI] - See header of drivers/scsi/seagate.c. - tmscsim=[HW,SCSI] See comment before function dc390_setup() in drivers/scsi/tmscsim.c. diff --git a/drivers/scsi/seagate.c b/drivers/scsi/seagate.c index ce80fa9..900f7d6 100644 --- a/drivers/scsi/seagate.c +++ b/drivers/scsi/seagate.c @@ -32,17 +32,6 @@ * Configuration : * To use without BIOS -DOVERRIDE=base_address -DCONTROLLER=FD or SEAGATE * -DIRQ will override the default of 5. - * Note: You can now set these options from the kernel's "command line". - * The syntax is: - * - * st0x=ADDRESS,IRQ(for a Seagate controller) - * or: - * tmc8xx=ADDRESS,IRQ (for a TMC-8xx or TMC-950 controller) - * eg: - * tmc8xx=0xC8000,15 - * - * will configure the driver for a TMC-8xx style controller using IRQ 15 - * with a base address of 0xC8000. * * -DARBITRATE * Will cause the host adapter to arbitrate for the -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - 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.22 oops kernel BUG at block/elevator.c:366!
On Wednesday 29 of August 2007, Arkadiusz Miskiewicz wrote: > On Wednesday 29 of August 2007, Arkadiusz Miskiewicz wrote: > > Hello, > > > > I'm trying to get stable kernel for Promise SuperTrak > > X16350 hardware. So far 2.6.20, 2.6.21 and 2.6.22 oopsed > > like this (while doing rsync): > > With anticipatory: > > berta login: [ cut here ] > kernel BUG at block/as-iosched.c:1084! One more information: I'm currently running 2.6.19 for few hours and the oops doesn't happen. Looks like some regression introduced between 2.6.19 and 2.6.20. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ - 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: [Linux-usb-users] usb-storage and Motorola Z6
On Tue, 28 Aug 2007, Andreas Koenecke wrote: > * Dienstag, 28. August 2007 um 14:48 (-0600) schrieb Matthew Wilcox: > > > > On Tue, Aug 28, 2007 at 04:45:59PM -0400, Alan Stern wrote: > > > Can any SCSI experts explain what's going wrong here? > > > > It's the PQ 1 -- the device is telling us that it's not actually there > > right now. > > Is anything I can try? You can edit the source code of the SCSI core to make it ignore the PQ value. In the file drivers/scsi/scsi_sysfs.c, find the scsi_bus_match() routine and change the last line from: return (sdp->inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0; to return 1; Alan Stern - 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.22 oops kernel BUG at block/elevator.c:366!
On Wednesday 29 of August 2007, Arkadiusz Miskiewicz wrote: > Hello, > > I'm trying to get stable kernel for Promise SuperTrak > X16350 hardware. So far 2.6.20, 2.6.21 and 2.6.22 oopsed > like this (while doing rsync): With anticipatory: berta login: [ cut here ] kernel BUG at block/as-iosched.c:1084! invalid opcode: [1] SMP CPU 1 Modules linked in: softdog sch_sfq forcedeth ext3 jbd mbcache dm_mod xfs scsi_wait_scan sd_mod stex scsi_mod Pid: 32:#0, comm: kblockd/1 Not tainted 2.6.22.5-0.2 #1 RIP: 0010:[] [] as_dispatch_request+0x438/0x460 RSP: 0018:81007d1fddc0 EFLAGS: 00010046 RAX: RBX: 81007c765a00 RCX: RDX: 81007c765a28 RSI: RDI: 81007c54ad08 RBP: R08: R09: 81006a289d80 R10: R11: 0001 R12: R13: 0001 R14: R15: 81007cf85048 FS: 2ba4421e8b00() GS:81007d0a5b40() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2ba46298f000 CR3: 50951000 CR4: 06e0 Process kblockd/1 (pid: 32[#0], threadinfo 81007d1fc000, task 81007d1db040) Stack: 81007c54ad08 81007cf85000 81007cf7e000 81007d1fde00 81006a289cc0 8033f11f 0287 88000fa8 81001646a6f8 81007cf85000 81007cf7e000 Call Trace: [] elv_next_request+0x3f/0x150 [] :scsi_mod:scsi_dispatch_cmd+0x1c8/0x310 [] :scsi_mod:scsi_request_fn+0x69/0x3d0 [] as_work_handler+0x0/0x50 [] as_work_handler+0x2c/0x50 [] run_workqueue+0xcc/0x170 [] worker_thread+0x0/0x110 [] worker_thread+0x0/0x110 [] worker_thread+0xa3/0x110 [] autoremove_wake_function+0x0/0x30 [] worker_thread+0x0/0x110 [] worker_thread+0x0/0x110 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 Code: 0f 0b eb fe 0f 0b eb fe 31 ed c7 83 b8 00 00 00 01 00 00 00 RIP [] as_dispatch_request+0x438/0x460 RSP -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ - 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] Prefix each line of multiline printk(KERN_ "foo\nbar") with KERN_
On Sun, 26 Aug 2007, Geert Uytterhoeven wrote:
> What I mean is that probably there used to be a printk() call starting with
> `\n'. Then someone added a `KERN_ERR' in front of it.
I gather '\n' at the beginning is to assure the following line is output
on a separate line rather than as a continuation of another one which may
have been output without a trailing '\n'. A situation where printk() is
called with a string containing no trailing '\n' may be discouraged, but
there are some more or less justified exceptions. For example the SCSI
disk spin-up code is one.
Therefore it may be reasonable for more critical messages -- perhaps not
ones at KERN_ERR, but certainly KERN_CRIT and higher ones -- that may
potentially happen asynchronously to start with '\n'. In this case a call
would look like this:
printk("\n" KERN_CRIT "The actual message.\n");
Of course based on "console_loglevel" and "default_message_level" the
leading '\n' may still get swallowed from what gets printed to the console
terminal, but in reality I do not think that poses a problem, as these
both can be set by a system administrator according to the local policy.
Maciej
-
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.22 oops kernel BUG at block/elevator.c:366!
Hello, I'm trying to get stable kernel for Promise SuperTrak X16350 hardware. So far 2.6.20, 2.6.21 and 2.6.22 oopsed like this (while doing rsync): kernel BUG at block/elevator.c:366! invalid opcode: [1] SMP CPU 1 Modules linked in: softdog sch_sfq forcedeth ext3 jbd mbcache dm_mod xfs scsi_wait_scan sd_mod stex scsi_mod Pid: 1139:#0, comm: xfsbufd Not tainted 2.6.22.5-0.2 #1 RIP: 0010:[] [] elv_rb_del+0x3a/0x40 RSP: :8100759b1c00 EFLAGS: 00010046 RAX: 81000d1f5428 RBX: 81000d1f5428 RCX: 81007c1a1a00 RDX: RSI: 81000d1f53b0 RDI: 81007c102af0 RBP: 81000d1f53b0 R08: 81004a9dab50 R09: R10: R11: 880072c0 R12: 81007c102ac0 R13: 81007c1a1a00 R14: 0004 R15: 81007c102b18 FS: 2ba2cafc9be0() GS:81007d0a5b40() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2ba2cab5a158 CR3: 3c5ce000 CR4: 06e0 Process xfsbufd (pid: 1139[#0], threadinfo 8100759b, task 81007cac1040) Stack: 0001 81007c102ac0 81000d1f53b0 8034abe8 0246 81000d1f53b0 81007c1a1a00 81007c102ac0 81007c0f2d08 0004 81007c102b18 8034ad55 Call Trace: [] cfq_remove_request+0x78/0x1b0 [] cfq_dispatch_insert+0x35/0x70 [] cfq_dispatch_requests+0x1bf/0x3a0 [] elv_next_request+0x3f/0x150 [] lock_timer_base+0x34/0x70 [] :scsi_mod:scsi_request_fn+0x69/0x3d0 [] __make_request+0xe6/0x5d0 [] generic_make_request+0x18b/0x230 [] submit_bio+0x5a/0xf0 [] :xfs:_xfs_buf_ioapply+0x199/0x340 [] :xfs:xfs_buf_iorequest+0x29/0x80 [] :xfs:xfs_bdstrat_cb+0x3b/0x50 [] :xfs:xfsbufd+0x92/0x140 [] :xfs:xfsbufd+0x0/0x140 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 Code: 0f 0b eb fe 66 90 48 83 ec 08 49 89 f8 48 89 f8 31 c9 eb 09 RIP [] elv_rb_del+0x3a/0x40 RSP I can reproduce it without bigger problem. Here are the same oopses on 2.6.20: http://paste.stgraber.org/3138 This is 1 x dual core athlon64 on asus m2npv mainboard, 2GB RAM. There is hw raid on fasttrack 16350 only (no software one). Has anyone seen this ? Going to try without cfq. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ - 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] hptiop: adding new firmware interface and more PCI device IDs
HighPoint Linux Team wrote:
+ if (hba->firmware_version > 0x0102 || hba->interface_version >
0x0102) {
[...]
+ if (hba->firmware_version > 0x0102 ||
+ hba->interface_version > 0x0102) {
Rather than repeating this test, you should do it once at probe time,
and set a "new interface" single-bit flag in some hptiop_hba field.
Less maintenance intensive, less prone to error, and removes expensive
tests from the driver hotpath.
static struct pci_device_id hptiop_id_table[] = {
- { PCI_DEVICE(0x1103, 0x3220) },
- { PCI_DEVICE(0x1103, 0x3320) },
+ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x3220) },
+ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x3320) },
+ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x3520) },
+ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x4320) },
{},
Using the PCI_VDEVICE() macro can make this even shorter:
{ PCI_VDEVICE(TTI, 0x4320) }
Regards,
Jeff
-
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] hptiop: adding new firmware interface and more PCI device IDs
- check adapter firmware version and using appropriate interface accordingly
- add new PCI device IDs
- update driver version string
Signed-off-by: HighPoint Linux Team <[EMAIL PROTECTED]>
---
hptiop.c | 57 +++--
hptiop.h |9 +++--
2 files changed, 50 insertions(+), 16 deletions(-)
diff -uprN a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
--- a/drivers/scsi/hptiop.c 2007-08-29 13:52:20.0 +0800
+++ b/drivers/scsi/hptiop.c 2007-08-29 13:52:39.0 +0800
@@ -1,6 +1,6 @@
/*
* HighPoint RR3xxx controller driver for Linux
- * Copyright (C) 2006 HighPoint Technologies, Inc. All Rights Reserved.
+ * Copyright (C) 2006-2007 HighPoint Technologies, Inc. All Rights Reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -42,7 +42,7 @@ MODULE_DESCRIPTION("HighPoint RocketRAID
static char driver_name[] = "hptiop";
static const char driver_name_long[] = "RocketRAID 3xxx SATA Controller
driver";
-static const char driver_ver[] = "v1.0 (060426)";
+static const char driver_ver[] = "v1.2 (070810)";
static void hptiop_host_request_callback(struct hptiop_hba *hba, u32 tag);
static void hptiop_iop_request_callback(struct hptiop_hba *hba, u32 tag);
@@ -76,7 +76,7 @@ static int iop_wait_ready(struct hpt_iop
static void hptiop_request_callback(struct hptiop_hba *hba, u32 tag)
{
- if ((tag & IOPMU_QUEUE_MASK_HOST_BITS) == IOPMU_QUEUE_ADDR_HOST_BIT)
+ if (tag & IOPMU_QUEUE_ADDR_HOST_BIT)
return hptiop_host_request_callback(hba,
tag & ~IOPMU_QUEUE_ADDR_HOST_BIT);
else
@@ -323,12 +323,22 @@ static inline void free_req(struct hptio
hba->req_list = req;
}
-static void hptiop_host_request_callback(struct hptiop_hba *hba, u32 tag)
+static void hptiop_host_request_callback(struct hptiop_hba *hba, u32 _tag)
{
struct hpt_iop_request_scsi_command *req;
struct scsi_cmnd *scp;
+ u32 tag;
+
+ if (hba->firmware_version > 0x0102 || hba->interface_version >
0x0102) {
+ tag = _tag & ~ IOPMU_QUEUE_REQUEST_RESULT_BIT;
+ req = (struct hpt_iop_request_scsi_command
*)hba->reqs[tag].req_virt;
+ if (likely(_tag & IOPMU_QUEUE_REQUEST_RESULT_BIT))
+ req->header.result = IOP_RESULT_SUCCESS;
+ } else {
+ tag = _tag;
+ req = (struct hpt_iop_request_scsi_command
*)hba->reqs[tag].req_virt;
+ }
- req = (struct hpt_iop_request_scsi_command *)hba->reqs[tag].req_virt;
dprintk("hptiop_host_request_callback: req=%p, type=%d, "
"result=%d, context=0x%x tag=%d\n",
req, req->header.type, req->header.result,
@@ -521,8 +531,20 @@ static int hptiop_queuecommand(struct sc
memcpy(req->cdb, scp->cmnd, sizeof(req->cdb));
- writel(IOPMU_QUEUE_ADDR_HOST_BIT | _req->req_shifted_phy,
- &hba->iop->inbound_queue);
+ if (hba->firmware_version > 0x0102 ||
+ hba->interface_version > 0x0102) {
+ u32 size_bits;
+ if (req->header.size < 256)
+ size_bits = IOPMU_QUEUE_REQUEST_SIZE_BIT;
+ else if (req->header.size < 512)
+ size_bits = IOPMU_QUEUE_ADDR_HOST_BIT;
+ else
+ size_bits = IOPMU_QUEUE_REQUEST_SIZE_BIT |
+ IOPMU_QUEUE_ADDR_HOST_BIT;
+ writel(_req->req_shifted_phy | size_bits,
&hba->iop->inbound_queue);
+ } else
+ writel(_req->req_shifted_phy | IOPMU_QUEUE_ADDR_HOST_BIT,
+ &hba->iop->inbound_queue);
return 0;
@@ -722,6 +744,7 @@ static int __devinit hptiop_probe(struct
hba->max_request_size = le32_to_cpu(iop_config.request_size);
hba->max_sg_descriptors = le32_to_cpu(iop_config.max_sg_count);
hba->firmware_version = le32_to_cpu(iop_config.firmware_version);
+ hba->interface_version = le32_to_cpu(iop_config.interface_version);
hba->sdram_size = le32_to_cpu(iop_config.sdram_size);
host->max_sectors = le32_to_cpu(iop_config.data_transfer_length) >> 9;
@@ -731,8 +754,15 @@ static int __devinit hptiop_probe(struct
host->cmd_per_lun = le32_to_cpu(iop_config.max_requests);
host->max_cmd_len = 16;
- set_config.vbus_id = cpu_to_le32(host->host_no);
+ req_size = sizeof(struct hpt_iop_request_scsi_command)
+ + sizeof(struct hpt_iopsg) * (hba->max_sg_descriptors - 1);
+ if ((req_size & 0x1f) != 0)
+ req_size = (req_size + 0x1f) & ~0x1f;
+
+ memset(&set_config, 0, sizeof(struct hpt_iop_request_set_config));
set_config.iop_id = cpu_to_le32(host->host_no)
