RE: [PATCH] scsi: le*_add_cpu conversion
ACK
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 12, 2008 6:06 PM
> To: LKML
> Cc: Marcin Slusarz; [EMAIL PROTECTED]; AACRAID;
> [EMAIL PROTECTED]
> Subject: [PATCH] scsi: le*_add_cpu conversion
>
> From: Marcin Slusarz <[EMAIL PROTECTED]>
>
> replace all:
> little_endian_variable =
> cpu_to_leX(leX_to_cpu(little_endian_variable) +
> expression_in_cpu_byteorder);
> with:
> leX_add_cpu(&little_endian_variable,
> expression_in_cpu_byteorder);
> generated with semantic patch
>
> Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> ---
> drivers/scsi/aacraid/commsup.c |2 +-
> drivers/scsi/ips.c |8 ++--
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/scsi/aacraid/commsup.c
> b/drivers/scsi/aacraid/commsup.c
> index 81b3692..3ac8c82 100644
> --- a/drivers/scsi/aacraid/commsup.c
> +++ b/drivers/scsi/aacraid/commsup.c
> @@ -594,7 +594,7 @@ void aac_consumer_free(struct aac_dev *
> dev, struct aac_queue *q, u32 qid)
> if (le32_to_cpu(*q->headers.consumer) >= q->entries)
> *q->headers.consumer = cpu_to_le32(1);
> else
> - *q->headers.consumer =
> cpu_to_le32(le32_to_cpu(*q->headers.consumer)+1);
> + le32_add_cpu(q->headers.consumer, 1);
>
> if (wasfull) {
> switch (qid) {
> diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
> index bb152fb..f45770a 100644
> --- a/drivers/scsi/ips.c
> +++ b/drivers/scsi/ips.c
> @@ -3696,9 +3696,7 @@ ips_send_cmd(ips_ha_t * ha, ips_scb_t * scb)
> scb->cmd.basic_io.sg_count = scb->sg_len;
>
> if (scb->cmd.basic_io.lba)
> - scb->cmd.basic_io.lba =
> - cpu_to_le32(le32_to_cpu
> -
> (scb->cmd.basic_io.lba) +
> + le32_add_cpu(&scb->cmd.basic_io.lba,
>
> le16_to_cpu(scb->cmd.basic_io.
>
> sector_count));
> else
> @@ -3744,9 +3742,7 @@ ips_send_cmd(ips_ha_t * ha, ips_scb_t * scb)
> scb->cmd.basic_io.sg_count = scb->sg_len;
>
> if (scb->cmd.basic_io.lba)
> - scb->cmd.basic_io.lba =
> - cpu_to_le32(le32_to_cpu
> -
> (scb->cmd.basic_io.lba) +
> + le32_add_cpu(&scb->cmd.basic_io.lba,
>
> le16_to_cpu(scb->cmd.basic_io.
>
> sector_count));
> else
> --
> 1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Adaptec AACRAID: convert fibctx->wait_sem to completion
linux/completion is already included in commctrl.c, in the patch fragment it is
noted two lines below the addition. Please explain in the description the
need/advantages for the change from semaphore to completion.
Sincerely -- Mark Salyzyn
> -Original Message-
> From: Matthias Kaehlcke [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 13, 2008 1:35 PM
> To: AACRAID; [EMAIL PROTECTED]
> Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
> Subject: [PATCH] Adaptec AACRAID: convert fibctx->wait_sem to
> completion
>
> Adaptec AACRAID driver: The semaphore fibctx->wait_sem is used for
> signalling an event. Convert it to a completion.
>
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
>
> --
> diff --git a/drivers/scsi/aacraid/aacraid.h
> b/drivers/scsi/aacraid/aacraid.h
> index 3195d29..eef4939 100644
> --- a/drivers/scsi/aacraid/aacraid.h
> +++ b/drivers/scsi/aacraid/aacraid.h
> @@ -717,7 +717,7 @@ struct aac_fib_context {
> u32 unique; // unique
> value representing this context
> ulong jiffies;// used for
> cleanup - dmb changed to ulong
> struct list_headnext; // used to
> link context's into a linked list
> - struct semaphorewait_sem; // this is
> used to wait for the next fib to arrive.
> + struct completion compl; // this is
> used to wait for the next fib to arrive.
> int wait; // Set to
> true when thread is in WaitForSingleObject
> unsigned long count; // total
> number of FIBs on FibList
> struct list_headfib_list; // this holds
> fibs and their attachd hw_fibs
> diff --git a/drivers/scsi/aacraid/commctrl.c
> b/drivers/scsi/aacraid/commctrl.c
> index abef051..98efda6 100644
> --- a/drivers/scsi/aacraid/commctrl.c
> +++ b/drivers/scsi/aacraid/commctrl.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -177,9 +178,9 @@ static int open_getadapter_fib(struct
> aac_dev * dev, void __user *arg)
> */
> fibctx->unique = (u32)((ulong)fibctx & 0x);
> /*
> -* Initialize the mutex used to wait for
> the next AIF.
> +* Initialize the completion used to
> wait for the next AIF.
> */
> - init_MUTEX_LOCKED(&fibctx->wait_sem);
> + init_completion(&fibctx->compl);
> fibctx->wait = 0;
> /*
> * Initialize the fibs and set the count
> of fibs on
> @@ -310,7 +311,7 @@ return_fib:
> ssleep(1);
> }
> if (f.wait) {
> -
> if(down_interruptible(&fibctx->wait_sem) < 0) {
> +
> if(wait_for_completion_interruptible(&fibctx->compl) < 0) {
> status = -EINTR;
> } else {
> /* Lock again and retry */
> diff --git a/drivers/scsi/aacraid/commsup.c
> b/drivers/scsi/aacraid/commsup.c
> index 81b3692..486bdb3 100644
> --- a/drivers/scsi/aacraid/commsup.c
> +++ b/drivers/scsi/aacraid/commsup.c
> @@ -1440,7 +1440,7 @@ int aac_check_health(struct aac_dev * aac)
> * Set the event to wake up the
> * thread that will waiting.
> */
> - up(&fibctx->wait_sem);
> + complete(&fibctx->compl);
> } else {
> printk(KERN_WARNING "aifd: didn't
> allocate NewFib.\n");
> kfree(fib);
> @@ -1671,7 +1671,7 @@ int aac_command_thread(void *data)
> * Set the
> event to wake up the
> * thread
> that is waiting.
> */
> - up(&fibctx->wait_sem);
> +
> complete(&fibctx->compl);
> } else {
>
> printk(KERN_WARNING "aifd: didn't allocate NewFib.\n");
> }
> --
> Matthias Kaehlcke
> Linux System Developer
> Barcelona
>
> Si deseas mantener tu libertad, debes estar preparado para
> defenderla
> (Richard Stallman)
> .''`.
> using free software / Debian GNU/Linux |
> http://debian.org : :' :
> `. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid: Host adapter reset request. SCSI hang ?
This 'Host adapter reset request. SCSI hang ?' message hides a rather complicated-to-explain underlying hardware behavior. Aacraid based controllers have an underlying timeout/recovery cycle that is 35 seconds long, there is a driver patch for this POST RHEL5 (but is going into RHEL5.2) that increases the default Linux per-device timeout to 45 seconds. The default in some SCSI subsystems was 60 seconds in the past, but is now standardized at 30 seconds which results in an interference pattern between the controller and Linux' SCSI subsystem. The alternate workaround is for the user to adjust the timeout in sysfs if it is shorter than this value. This is the only likely Linux driver issue that you may be having, everything is out of the scope for Linux or the aacraid driver; and needs to be addressed separately. This is not the panacea, so do NOT get your hopes up, and do NOT feel that the warning behavior is in fact a problem that needs to be solved (!) Keep in mind that I/O completions on these controllers when everything is working is typically in the millisecond region or less. The 3405 (or generically any aacraid based controller) is likely going through an error correction cycle on the SAS/SATA bus that is delaying the completion of I/O beyond the Linux default timeout set for the device, this may be a hardware issue (i.e.: driver or OS will not change anything) and typically will be of little concern to the Linux Kernel or Distribution folks. Or this may be a problem with an overly aggressive default timeout value as outlined immediately above. The fact that all you get are these messages and I/O continues indicates that everything is working as-designed dealing with or working around whatever the hardware issue is. That does not mean the driver is free and clear, perhaps we are reaching a fundamental resource limit in the controller, on the bus, on the enclosure or in the drives. You may be able to mitigate this by adjusting the maximum queue depth down somewhat. You can adjust this in sysfs or indirectly through driver's controller-wide limit using insmod parameter numacb. If you find this to be the case and it is prevalent, we may need to adjust the rules within the driver regarding load balancing and queue depths to improve the general reliability and responsiveness of the system. A balance between reliability, performance, responsiveness and periodic warning messages in your logs? Target devices typically have the ability to handle at least 32 outstanding commands, often more. My guess is that if the drives, enclosure and the controllers are all up to date (latest Firmware on all) and swapping components has not resulted in any changes in behavior, and this problem persists at per-device queue depths below 32 and timeouts of 60 seconds, that you likely have a drive compatibility problem. One of the first incompatibilities that needs to be reconciled that comes to mind is the use of desktop class (typically self correcting, which can take more than ten seconds to respond to I/O requests) or off-spec (i.e., higher error rate drives often shipped into low-budget markets) drives. The controller needs to work with these drives, and it does, and is dealing with them in an as-designed manner. If these are the drives you have, then you are getting what you paid for. If this is the case, you can reduce the annoyance by increasing the component's timeout by programming an updated value in sysfs. Keep in mind that if the purchaser has in their mind that they wanted an enterprise class drive, and the supplier (or the manufacturer) supplied you desktop class drives; that they are often very willing to swap out the desktop class drives in exchange for the enterprise class drives. The difference is often merely as simple as a Drive Firmware behavior. I would not increase this timeout much beyond 120 seconds, for anything larger starts affecting your rough guarantee of I/O delivery required for server network connections. The timeout results in a quescing of I/O to the device and results in the servicing of any starved requests that may be backed up behind resource limits in the components and thus also has an affect on dealing with the fundamental resource limit issues indicated above. The messages you are seeing, although annoying, are actually a desirable, albeit clunky, handshake somewhat ensuring the guarantee of I/O delivery. It is clunky because it also leads to a pause in more recently submitted I/O as it offers up ten seconds of silence in it's honor :-( Another problem can arise surrounding the enclosure compatibility, for it may be negotiating in bad faith with the components, or has an incompatibility with the enclosure services in the controller. Especially if the enclosure has not been certified for use with the controller. Another is that the drive is server/enterprise class and because it is a late-model unit, specifically has n
RE: aacraid: Host adapter reset request. SCSI hang ?
Alan Cox [mailto:[EMAIL PROTECTED] sez: > Sent: Monday, February 18, 2008 9:54 AM > To: Salyzyn, Mark > Cc: Omar Kilani; linux-kernel@vger.kernel.org > Subject: Re: aacraid: Host adapter reset request. SCSI hang ? > > > pattern between the controller and Linux' SCSI subsystem. > > The alternate workaround is for the user to adjust the > > timeout in sysfs if it is shorter than this value. > Does that actually work. I consistently see libata reporting > 60 seconds but the commands are on 30 second timeouts and I've > yet to get to the bottom of this I 'assumed' it worked, the customer that reported a related problem went silent after I suggested the change. libata's relationship with scsi may be different than aacraid's relationship? Sincerely -- Mark Salyzyn Eeek (a scientific term) - v - realization that a unit test was not performed. - See 'Scre' for more critical definition. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [2.6 patch] drivers/scsi/dpt*: remove version.h dependencies
You can not remove the entries in sys_info.h (osMajorVersion & friends),
this communicates information to the application via the ioctls and the
structure shape is important. Change the code to zero the values, leave
osType set to OS_LINUX.
Sincerely -- Mark Salyzyn
-Original Message-
From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 14, 2005 8:49 PM
To: James Bottomley
Cc: Andrew Morton; SCSI Mailing List; Linux Kernel;
[EMAIL PROTECTED]; Salyzyn, Mark
Subject: [2.6 patch] drivers/scsi/dpt*: remove version.h dependencies
On Sat, Apr 02, 2005 at 07:49:38AM -0600, James Bottomley wrote:
> On Sun, 2005-03-27 at 16:34 +0200, Adrian Bunk wrote:
> > This patch removes #if's for kernel 2.2 .
>
> this one looks like it's not quite complete:
>
> > -#ifndef LINUX_VERSION_CODE
> > #include
> > -#endif
>
> Once there are no more KERNEL_VERSION dependencies in a file, it's
> inclusion of linux/version.h can be removed also (and that should
> prevent it getting rebuilt every time the kernel version changes).
>
> So it looks like there's an additional KERNEL_VERSION to remove in
> dpt/dpti_i2o.h version.h includes in dpti_i2o.h and dpt_i2o.c
Is the patch below what you want, or do I misunderstand your comment?
> Then when you have a final patch, could you cc Markus Lidel
> <[EMAIL PROTECTED]> and
>
> [EMAIL PROTECTED]
>
> Thanks,
>
> James
cu
Adrian
<-- snip -->
This patch removes version.h dependencies.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
drivers/scsi/dpt/sys_info.h |4
drivers/scsi/dpt_i2o.c |5 -
drivers/scsi/dpti.h | 12
3 files changed, 21 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpti.h.old 2005-04-15
01:21:04.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpti.h 2005-04-15
01:21:26.0 +0200
@@ -20,15 +20,7 @@
#ifndef _DPT_H
#define _DPT_H
-#ifndef LINUX_VERSION_CODE
-#include
-#endif
-
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,00)
-#define MAX_TO_IOP_MESSAGES (210)
-#else
#define MAX_TO_IOP_MESSAGES (255)
-#endif
#define MAX_FROM_IOP_MESSAGES (255)
@@ -321,10 +313,6 @@
static void adpt_delay(int millisec);
#endif
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-static struct pci_dev* adpt_pci_find_device(uint vendor, struct
pci_dev* from);
-#endif
-
#if defined __ia64__
static void adpt_ia64_info(sysInfo_S* si);
#endif
--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt/sys_info.h.old
2005-04-15 01:23:52.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt/sys_info.h
2005-04-15 01:24:13.0 +0200
@@ -146,10 +146,6 @@
uSHORT flags; /* See bit definitions above */
uSHORT conventionalMemSize;/* in KB */
uLONGextendedMemSize;/* in KB */
- uLONGosType; /* Same as DPTSIG's definition
*/
- uCHARosMajorVersion;
- uCHARosMinorVersion; /* The OS version */
- uCHARosRevision;
#ifdef _SINIX_ADDON
uCHARbusType;/* See defininitions above */
uSHORT osSubRevision;
--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt_i2o.c.old
2005-04-15 01:21:48.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt_i2o.c2005-04-15
01:25:20.0 +0200
@@ -34,7 +34,6 @@
#define ADDR32 (0)
-#include
#include
MODULE_AUTHOR("Deanna Bonds, with _lots_ of help from Mark Salyzyn");
@@ -1824,10 +1823,6 @@
memset(&si, 0, sizeof(si));
- si.osType = OS_LINUX;
- si.osMajorVersion = (u8) (LINUX_VERSION_CODE >> 16);
- si.osMinorVersion = (u8) (LINUX_VERSION_CODE >> 8 & 0x0ff);
- si.osRevision = (u8) (LINUX_VERSION_CODE & 0x0ff);
si.busType = SI_PCI_BUS;
si.processorFamily = DPTI_sig.dsProcessorFamily;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: AACRAID failure with 2.6.13-rc1
Martin may be overplaying the performance angle. A previous patch took the adapter from 64K to 4MB transaction sizes across the board. This caused Martin's adapter and drive combination to tip-over. We had to scale back to 128KB sized transactions to get stability on his system. All systems handled the 4MB I/O size in our tests, but the tests that were done some time ago were not performed with the latest kernel, which contributed to a change in testing corners. Future patches associated with the 'new comm' interface will be able to get finer grained performance tuning based on the adapter model rather than the coarse method that currently resides in the more stable kernels. Sincerely -- Mark Salyzyn -Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED] Sent: Friday, July 29, 2005 2:07 PM To: Martin Drab Cc: linux-kernel@vger.kernel.org; Salyzyn, Mark; [EMAIL PROTECTED] Subject: Re: AACRAID failure with 2.6.13-rc1 . . . ah, thanks. A temporary workaround which might affct performance sounds better than a dead box though. Mark, do you think that many systems are likely to be affected this way? Do you think we should do something temporary for 2.6.13? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: AACRAID failure with 2.6.13-rc1
Yes, please put the workaround into 2.6.13! Sincerely -- Mark Salyzyn -Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED] Sent: Friday, July 29, 2005 3:59 PM To: Salyzyn, Mark Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: AACRAID failure with 2.6.13-rc1 "Salyzyn, Mark" <[EMAIL PROTECTED]> wrote: > > Martin may be overplaying the performance angle. > > A previous patch took the adapter from 64K to 4MB transaction sizes > across the board. This caused Martin's adapter and drive combination to > tip-over. We had to scale back to 128KB sized transactions to get > stability on his system. All systems handled the 4MB I/O size in our > tests, but the tests that were done some time ago were not performed > with the latest kernel, which contributed to a change in testing > corners. Confused. The above appears to indicate that we should put the workaround into 2.6.13, yes? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry indirectory) (fwd)
Miquel van Smoorenburg sez: > I got the 64-bit dpt_i2o driver from Adaptec some time ago, and I have > added 64-bit support to the 2.6.23.1 dpt_i2o driver based on that > driver. I intended to submit it for 2.6.25 or so ... if I > have some time > later today or tomorrow I'll try that next to see if that makes a > difference. Thanks, Mike, I will be watching your progress and offer my support! I submitted a patch to move to 64 bit (which also drops the virt_to_bus code) several years ago and it was rejected because of the focus on the time to make i2o_block the driver of choice for this line of controllers. I then reacted to the rejection by working with Markus Lidel to move the 64 bit capabilities into the i2o driver. Sincerely -- Mark Salyzyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry indirectory) (fwd)
ACK, patch looks good. Thanks for composing this patch. Glad to hear of successful test results. Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Miquel > van Smoorenburg . . . > > I just recompiled 2.6.23.9 with the 64 bit patch for dpt_i2o > and now it > boots just fine. > > The patch is here: > http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch > > It's not the final version - it needs a few cleanups before it can be > submitted, but perhaps you can test if it also works for you. > > Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Communication between user process and kernel modules
Other means of communications include sysfs and procfs. These have the advantage of supporting scripting and can survive ABI changes that can plague the other interfaces; but are meant for low-bandwidth or out-of-band configuration or simple status reporting. Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > linux-os (Dick Johnson) > Sent: Friday, January 18, 2008 9:59 AM > To: mokhtar > Cc: linux-kernel@vger.kernel.org > Subject: Re: Communication between user process and kernel modules > > > On Fri, 18 Jan 2008, mokhtar wrote: > > > > > Hi > > > > What are the different solution to make a user process > communicate with a > > kernel modules? > > > > Whatis the the advantages and disadvanteges of each solutions ? > > > > ioctl() is the universal Unix mechanism for control of drivers > (modules). open(), close(), read(), write(), mmap() are the other > common methods. Some drivers may use sockets for communications. > I such a case, you use setsockopt() to change things. > > Drivers can signal user-space processes as well. Such programs > use select() and poll(). > > > > > -- > > Cheers, > Dick Johnson > Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 > BogoMips). > My book : http://www.AbominableFirebug.com/ > _ > > > > The information transmitted in this message is confidential > and may be privileged. Any review, retransmission, > dissemination, or other use of this information by persons or > entities other than the intended recipient is prohibited. If > you are not the intended recipient, please notify Analogic > Corporation immediately - by replying to this message or by > sending an email to [EMAIL PROTECTED] - and destroy > all copies of this information, including any attachments, > without reading or disclosing them. > > Thank you. > -- > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: AACRAID driver broken in 2.6.22.x (and beyond?) [WAS: Re: 2.6.22.16 MD raid1 doesn't mark removed disk faulty, MD thread goes UN]
At which version of the kernel did the aacraid driver allegedly first go broken? At which version did it get fixed? (Since 1.1.5-2451 is older than latest represented on kernel.org) How is the SATA disk'd arrayed on the aacraid controller? The controller is limited to generating 24 arrays and since /dev/sdac is the 29th target, it would appear we need more details on your array's topology inside the aacraid controller. If you are using the driver with aacraid.physical=1 and thus using the physical drives directly (in the case of a SATA disk, a SATr0.9 translation in the Firmware), this is not a supported configuration and was added only to enable limited experimentation. If there is a problem in that path in the driver, I will glad to fix it, but still unsupported. You may need to acquire a diagnostic dump from the controller (Adaptec technical support can advise, it will depend on your application suite) and a report of any error recovery actions reported by the driver in the system log as initiated by the SCSI subsystem. There are no changes in the I/O path for the aacraid driver. Due to the simplicity of the I/O path to the processor based controller, it is unlikely to be an issue in this path. There have been several changes in the driver to deal with error recovery actions initiated by the SCSI subsystem. One likely candidate was to extend the default SCSI layer timeout because it was shorter than the adapter's firmware timeout. You can check if this is the issue by manually increasing the timeout for the target(s) via sysfs. There were recent patches to deal with orphaned commands resulting from devices being taken offline by the SCSI layer. There has been changes in the driver to reset the controller should it go into a BlinkLED (Firmware Assert) state. The symptom also acts like a condition in the older drivers (pre 08/08/2006 on scsi-misc-2.6, showing up in 2.6.20.4) which did not reset the adapter when it entered the BlinkLED state and merely allowed the system to lock, but alas you are working with a driver with this reset fix in the version you report. A BlinkLED condition generally indicates a serious hardware problem or target incompatibility; and is generally rare as they are a result of corner case conditions within the Adapter Firmware. The diagnostic dump reported by the Adaptec utilities should be able to point to the fault you are experiencing if these appear to be the root causes. Sincerely -- Mark Salyzyn > -Original Message- > From: Mike Snitzer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 22, 2008 7:10 PM > To: [EMAIL PROTECTED]; NeilBrown > Cc: linux-kernel@vger.kernel.org; K. Tanaka; AACRAID; > [EMAIL PROTECTED] > Subject: AACRAID driver broken in 2.6.22.x (and beyond?) > [WAS: Re: 2.6.22.16 MD raid1 doesn't mark removed disk > faulty, MD thread goes UN] > > On Jan 22, 2008 12:29 AM, Mike Snitzer <[EMAIL PROTECTED]> wrote: > > cc'ing Tanaka-san given his recent raid1 BUG report: > > http://lkml.org/lkml/2008/1/14/515 > > > > > > On Jan 21, 2008 6:04 PM, Mike Snitzer <[EMAIL PROTECTED]> wrote: > > > Under 2.6.22.16, I physically pulled a SATA disk > (/dev/sdac, connected to > > > an aacraid controller) that was acting as the local raid1 > member of > > > /dev/md30. > > > > > > Linux MD didn't see an /dev/sdac1 error until I tried > forcing the issue by > > > doing a read (with dd) from /dev/md30: > > > The raid1d thread is locked at line 720 in raid1.c > (raid1d+2437); aka > > freeze_array: > > > > (gdb) l *0x2539 > > 0x2539 is in raid1d (drivers/md/raid1.c:720). > > 715 * wait until barrier+nr_pending match nr_queued+2 > > 716 */ > > 717 spin_lock_irq(&conf->resync_lock); > > 718 conf->barrier++; > > 719 conf->nr_waiting++; > > 720 wait_event_lock_irq(conf->wait_barrier, > > 721 > conf->barrier+conf->nr_pending == > > conf->nr_queued+2, > > 722 conf->resync_lock, > > 723 > raid1_unplug(conf->mddev->queue)); > > 724 spin_unlock_irq(&conf->resync_lock); > > > > Given Tanaka-san's report against 2.6.23 and me hitting > what seems to > > be the same deadlock in 2.6.22.16; it stands to reason this affects > > raid1 in 2.6.24-rcX too. > > Turns out that the aacraid driver in 2.6.22.x is HORRIBLY BROKEN (when > you pull a drive); it responds to MD's write requests with uptodate=1 > (in raid1_end_write_request) for the drive that was pulled! I've not > looked to see if aacraid has been fixed in newer kernels... are others > aware of any crucial aacraid fixes in 2.6.23.x or 2.6.24? > > After the drive was physically pulled, and small periodic writes > continued to the associated MD device, the raid1 MD driver did _NOT_ > detect the pulled drive's writes as having failed (verified this with > systemtap). MD happily thought the write completed to both members > (so MD had no reason to mark the pulled drive "f
RE: kdump detection in SCSI drivers
Pavel Machek sez: > > Other suggestion which came about was to parse the kernel > > command line and look for "elfcorehdr=". Is this ok? Is > > kernel command line visible to the SCSI drivers? > Kernel command line probably is visible, but I'd recommend > against doing that. Probably just as pregnant of a plan, what about looking for the reset_devices being none-zero? It was introduced for kdump to address the problem with devices that maintain state outside of the driver and the intent is to have it always set in the kdump kernel context. Personally, I'd code the driver to acquire memory normally, and have a backup plan to acquire less should the allocation fail in a memory limited environment ;-/ Sincerely -- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Unify sysfs filenames for firmware version
Jonathan McDowell sez: > On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote: > > The hearburn I have with these patches is that you are changing > > driver-specific attributes, not common ones as > > enforced/requested by a > > subsystem. As such, you are breaking a management interface for > > existing tools/scripts. > Yes, that's true. Though at present we have the heartburn that anyone > wanting to write a script to pull out firmware revisions has to know > exactly where every driver stores this information. The aacraid cards, which uses hba_monitor_version, hba_kernel_version and hba_bios_version for each piece does not fit into the single 'firmware revision' common ideal and were noticeably missing from this patch set. Fortunately (?), Adaptec has not bought into using sysfs for their management applications to pull these pieces and continues to pick them up directly by issuing ioctl pass-through calls to the card's firmware, so we have some leeway to change them to mold to a developing standard. The fact that sysfs is a developing standard will confirm the management application folks reasoning for shying away from sysfs ;-/ Sincerely -- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Unify sysfs filenames for firmware version
Jonathan McDowell [mailto:[EMAIL PROTECTED] sez: > On Tue, Nov 20, 2007 at 12:49:49PM -0500, Salyzyn, Mark wrote: > > The aacraid cards, which uses hba_monitor_version, > > hba_kernel_version and hba_bios_version for each piece > > does not fit into the single 'firmware revision' common ideal > While I've used the aacraid cards in the past I think I agree > with you that no 1 of those 3 pieces of information represents > the firmware. Perhaps it could export a triplet though? A single can be used in 99% of all cases, OEM or users can muck it up. I would 'vote' for hba_kernel_version == fw_version. Maybe add a companion standard for hba_bios_version == bios_version and hba_monitor_version == exec_version (executive_version) if other cards can supply such info ... > Management stuff always seems to be tied to a single card. It's one of > the things that puts me off hardware RAID. There are 113 cards this driver works for in concert. Maybe my tail feathers are showing ;-> > Do the management folks actually have some ideas about what sort of > interface they'd like in sysfs? Simple answer: No Detailed answer (I digress): They love ioctls as a commonality across all operating systems and a pass-through to proprietary firmware portals: binary, bidirectional, atomic and freely formatted migrating structures that do not herd the cats into just one specification. These are all eventually presented as documented stable objects exported by a sizeable C++ StorLib(tm) library that provides the consistent interface that the OEMs and Adaptec use to the higher level install, event, GUI and CLI applications. Driver is only involved as a transport. Sincerely -- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] aacraid: driver feature flags?
Feature enhancement.
Do we have a developing standard on how a driver may report to user tools via
sysfs what features are supported or not by the driver? In the following I am
proposing a 'flags' entry that will reside in the host controllers tree, with a
newline separated list of arbitrary ascii named features that indicate whether
the combination of driver and controller has support for said feature. Breaking
from the one-line output typical of sysfs entries, newline was added to tailor
for grep, or simple gets line by line string match within an application. I
added one for a compiler time check for existence of debug print output, one
for an optional manifest defined enhanced status reporting in the logs, and one
for runtime reporting whether the controller and driver supports arrays larger
than 2TB to my example below.
Suggestions?
This following patch is against current scsi-misc-2.6
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling
of patch attachments, so one can NOT use the following to patch, it is only
present to demonstrate the idea.
drivers/scsi/aacraid/linit.c | 25 +
1 file changed, 25 insertions(+)
diff -ru a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
--- a/drivers/scsi/aacraid/linit.c 2008-01-11 11:19:11.378159940 -0500
+++ b/drivers/scsi/aacraid/linit.c 2008-01-11 11:23:19.040145945 -0500
@@ -788,6 +788,23 @@
return len;
}
+static ssize_t aac_show_flags(struct class_device *class_dev, char *buf)
+{
+ int len = 0;
+ struct aac_dev *dev = (struct
aac_dev*)class_to_shost(class_dev)->hostdata;
+
+ if (nblank(dprintk(x)))
+ len = snprintf(buf, PAGE_SIZE, "dprintk\n");
+# ifdef AAC_DETAILED_STATUS_INFO
+ len += snprintf(buf + len, PAGE_SIZE - len,
+ "AAC_DETAILED_STATUS_INFO\n");
+# endif
+ if (dev->raw_io_interface && dev->raw_io_64)
+ len += snprintf(buf + len, PAGE_SIZE - len,
+ "SAI_READ_CAPACITY_16\n");
+ return len;
+}
+
static ssize_t aac_show_kernel_version(struct class_device *class_dev,
char *buf)
{
@@ -897,6 +914,13 @@
},
.show = aac_show_vendor,
};
+static struct class_device_attribute aac_flags = {
+ .attr = {
+ .name = "flags",
+ .mode = S_IRUGO,
+ },
+ .show = aac_show_flags,
+};
static struct class_device_attribute aac_kernel_version = {
.attr = {
.name = "hba_kernel_version",
@@ -951,6 +975,7 @@
static struct class_device_attribute *aac_attrs[] = {
&aac_model,
&aac_vendor,
+ &aac_flags,
&aac_kernel_version,
&aac_monitor_version,
&aac_bios_version,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Checkpatch.pl failure
Suppress one of the bogus checkpatch.pl error, the side-effect of the error
highlighted that this constant should be replaced by an existing manifest.
checkpatch.pl needs to be corrected to accept the comment style to deal with
the other cases should they ever be touched by future patches. This is a
tangled set of coat hangers, tug on one and never know how complicated of a
mess might follow!
This attached patch is against current scsi-misc-2.6.
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling
of patch attachments, use the attachment, not the inline patch.
Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
drivers/scsi/dpt_i2o.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -ru a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
--- a/drivers/scsi/dpt_i2o.c2008-01-14 13:39:11.086600955 -0500
+++ b/drivers/scsi/dpt_i2o.c2008-01-14 13:41:44.813246497 -0500
@@ -2296,7 +2296,7 @@
// copy over the request sense data if it was a check
// condition status
- if (dev_status == 0x02 /*CHECK_CONDITION*/) {
+ if (dev_status == SAM_STAT_CHECK_CONDITION) {
u32 len = min(SCSI_SENSE_BUFFERSIZE, 40);
// Copy over the sense data
memcpy_fromio(cmd->sense_buffer, (reply+28) , len);
This geek joke brought to you by -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> James Bottomley
> Sent: Monday, January 14, 2008 10:49 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: linux-kernel
> Subject: Checkpatch.pl failure
>
> This error:
>
> ERROR: no space before that close parenthesis ')'
> #501: FILE: drivers/scsi/dpt_i2o.c:2299:
> + if (dev_status == 0x02 /*CHECK_CONDITION*/) {
>
> Is definitely wrong. I think it's stripped the comments so now the if
> looks to have a space before the bracket, but stylistically the
> complaint it has errored out for is wrong.
>
> James
dpt_i2o_CHECK_CONDITION.patch
Description: dpt_i2o_CHECK_CONDITION.patch
RE: [PATCH] drivers/scsi/: Spelling fixes
ACK ips line change.
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Joe Perches
> Sent: Monday, December 17, 2007 2:40 PM
> To: linux-kernel@vger.kernel.org
> Cc: Andrew Morton; AACRAID; Andrew Vasquez; Brian King;
> IpsLinux; Hannes Reinecke; James E.J. Bottomley; James Smart;
> Mike Christie; Neela Syam Kolli; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: [PATCH] drivers/scsi/: Spelling fixes
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> ---
. . .
> drivers/scsi/ips.c|2 +-
. . .
> diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
> index 5c5a9b2..901e14b 100644
> --- a/drivers/scsi/ips.c
> +++ b/drivers/scsi/ips.c
> @@ -1313,7 +1313,7 @@ ips_intr_copperhead(ips_ha_t * ha)
> cstatus.value = (*ha->func.statupd) (ha);
>
> if (cstatus.fields.command_id > (IPS_MAX_CMDS - 1)) {
> - /* Spurious Interupt ? */
> + /* Spurious Interrupt ? */
> continue;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: EBDA Question
EBDA is safe to use during lilo and grub as part of a BIOS. As long as the EBDA is properly formed. However, it is considered 'bad behavior' to allocate much more than 4k of EBDA as we find others (not Linux) that depend on the 640K region of memory run out of this precious resource. Beware of several add-in BIOSii that each allocate EBDA; nest/size/relocate/offset properly. Sincerely -- Mark Salyzyn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Moore, Eric Dean Sent: Monday, February 07, 2005 2:45 PM To: linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org Subject: EBDA Question EBDA - Extended Bios Data Area Does Linux and various boot loaders(lilo/grub/etc) having any restrictions on where and how big memory allocated in EBDA is? Is this handled for 2.4/2.6 Kernels? Reason I ask is we are considering having BIOS(for a SCSI HBA Controller) allocating memory in EBDA for Firmware use. We are concerned whether Linux would be writing over this region of memory during the handoff of BIOS to scsi lower layer driver loading. Eric Moore LSI Logic - 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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid fails under kernel 2.6
Then turn off both read and write cache on the card ... You should contact Dell Technical support as there are many reasons for the adapter to fail ranging from bad power supply, cables, drives etc. Sincerely -- Mark Salyzyn -Original Message- From: Jonathan Knight [mailto:[EMAIL PROTECTED] Sent: Friday, February 11, 2005 11:01 AM To: Mark Haverkamp Cc: Jonathan Knight; linux-kernel; Salyzyn, Mark Subject: Re: aacraid fails under kernel 2.6 > A number of people have seen problems like this going from 2.4 to 2.6. > Mark Salyzyn from Adaptec has suggested in those cases to make sure that > the board firmware is up to date. I've copied Mark on this mail. We think we're on the latest everything. The BIOS is A07 and the firmware on the controller is 2.8.0 build 6092 -- __[EMAIL PROTECTED]Jonathan Knight, / Department of Computer Science / _ __ Telephone: +44 1782 583437 University of Keele, Keele, (_/ (_) / / Fax : +44 1782 713082 Staffordshire. ST5 5BG. U.K. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid fails under kernel 2.6
A significant portion of the operations reside in the Adapter Firmware, the driver report is essentially telling us the Adapter is locking up. In the Adaptec branch of the driver there is an AAC_DETAILED_STATUS_INFO manifest in aacraid.h that would enable firmware prints. The Firmware that exists in the ROMB occasionally reports conditions via that channel. The in-box driver has this debug channel turned on by default. Sometimes this can be used to isolate the condition of failure down. The logs supplied started with the driver report that the Adapter was hung, messages prior to that would contain the firmware prints. Sincerely -- Mark Salyzyn -Original Message- From: Jonathan Knight [mailto:[EMAIL PROTECTED] Sent: Monday, February 14, 2005 5:31 AM To: Salyzyn, Mark Cc: Jonathan Knight; Mark Haverkamp; linux-kernel Subject: Re: aacraid fails under kernel 2.6 > Then turn off both read and write cache on the card ... We've tried with no cache and we had multiple failures over the weekend. We are running 2.4.20 on some of these boxes and it is stable. We're only having problems with the 2.6 kernel. These systems did stay running for a few hours and then started dying every few minutes and then stable again for a few hours. They are in a air conditioned machine room with UPS power supplies and we have 11 identical 2500 systems. Only the ones running 2.6 have issues and those issues start the moment 2.6 is installed so we're convinced its software. What's puzzling me is that the aacraid driver isn't so different between 2.4.20 and 2.6. Is there a debugging run or something that I can get that would help diagnose the problem? -- __[EMAIL PROTECTED]Jonathan Knight, / Department of Computer Science / _ __ Telephone: +44 1782 583437 University of Keele, Keele, (_/ (_) / / Fax : +44 1782 713082 Staffordshire. ST5 5BG. U.K. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [2.6 patch] drivers/scsi/aacraid/: cleanups
I approve this, please apply to kernel.org branch.
Second time this has been submitted, been integrated since November 24th
in 1.1.5-2370 of the Adaptec Branch of the driver.
Sincerely -- Mark Salyzyn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adrian Bunk
Sent: Saturday, February 26, 2005 7:54 PM
To: linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: [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.h
2005-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.c
2005-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/dri
RE: [2.6 patch] SCSI: possible cleanups
Christoph Hellwig writes: >> - scsi_scan.c: scsi_rescan_device >aacraid was going to use that one, Mark, any chance to get a patch anytime soon? >> - scsi_scan.c: scsi_scan_single_target >as mentioned above we'll need this one soon. Yup, we use both of them in our branch of the driver. I submit a patch to MarkH for the Hot-Add calls soon. Sincerely -- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drivers/scsi/dpt_i2o: Convert to generic boolean
ACK
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Richard Knutsson
> Sent: Tuesday, October 30, 2007 6:54 AM
> To: [EMAIL PROTECTED]
> Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
> Richard Knutsson
> Subject: [PATCH] drivers/scsi/dpt_i2o: Convert to generic boolean
>
> Convert to use the generic boolean.
>
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
> ---
> Diffed against linus-git
> Checked with script/checkpatch.pl
> (warned about long lines, but it is not introduced by this patch)
>
> dpt_i2o.c | 22 +++---
> dpti.h|9 ++---
> 2 files changed, 13 insertions(+), 18 deletions(-)
>
>
> diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
> index 8258506..bd3a82d 100644
> --- a/drivers/scsi/dpt_i2o.c
> +++ b/drivers/scsi/dpt_i2o.c
> @@ -252,7 +252,7 @@ rebuild_sys_tab:
> adpt_i2o_delete_hba(pHba);
> continue;
> }
> - pHba->initialized = TRUE;
> + pHba->initialized = true;
> pHba->state &= ~DPTI_STATE_RESET;
> scsi_scan_host(pHba->host);
> }
> @@ -519,7 +519,7 @@ static int adpt_proc_info(struct
> Scsi_Host *host, char *buffer, char **start, of
> int unit;
>
> *start = buffer;
> - if (inout == TRUE) {
> + if (inout) {
> /*
>* The user has done a write and wants us to take the
>* data in the buffer and do something with it.
> @@ -893,7 +893,7 @@ static int adpt_install_hba(struct pci_dev* pDev)
> void __iomem *base_addr_virt = NULL;
> void __iomem *msg_addr_virt = NULL;
>
> - int raptorFlag = FALSE;
> + bool raptorFlag = false;
>
> if(pci_enable_device(pDev)) {
> return -EINVAL;
> @@ -926,7 +926,7 @@ static int adpt_install_hba(struct pci_dev* pDev)
> // Use BAR1 in this configuration
> base_addr1_phys = pci_resource_start(pDev,1);
> hba_map1_area_size = pci_resource_len(pDev,1);
> - raptorFlag = TRUE;
> + raptorFlag = true;
> }
>
> base_addr_virt = ioremap(base_addr0_phys,hba_map0_area_size);
> @@ -936,7 +936,7 @@ static int adpt_install_hba(struct pci_dev* pDev)
> return -EINVAL;
> }
>
> -if(raptorFlag == TRUE) {
> + if (raptorFlag) {
> msg_addr_virt = ioremap(base_addr1_phys,
> hba_map1_area_size );
> if (!msg_addr_virt) {
> PERROR("dpti: adpt_config_hba: io remap
> failed on BAR1\n");
> @@ -996,7 +996,7 @@ static int adpt_install_hba(struct pci_dev* pDev)
> spin_lock_init(&pHba->state_lock);
> spin_lock_init(&adpt_post_wait_lock);
>
> - if(raptorFlag == 0){
> + if (!raptorFlag) {
> printk(KERN_INFO"Adaptec I2O RAID controller %d
> at %p size=%x irq=%d\n",
> hba_count-1, base_addr_virt,
> hba_map0_area_size, pDev->irq);
> } else {
> @@ -1273,7 +1273,7 @@ static s32 adpt_i2o_reset_hba(adpt_hba* pHba)
> u32 m = EMPTY_QUEUE ;
> ulong timeout = jiffies + (TMOUT_IOPRESET*HZ);
>
> - if(pHba->initialized == FALSE) { // First time
> reset should be quick
> + if (!pHba->initialized) { /* First time reset
> should be quick */
> timeout = jiffies + (25*HZ);
> } else {
> adpt_i2o_quiesce_hba(pHba);
> @@ -1576,7 +1576,7 @@ static int adpt_open(struct inode
> *inode, struct file *file)
> // return -EBUSY;
> // }
>
> - pHba->in_use = 1;
> + pHba->in_use = true;
> mutex_unlock(&adpt_configuration_lock);
>
> return 0;
> @@ -1602,7 +1602,7 @@ static int adpt_close(struct inode
> *inode, struct file *file)
> return -ENXIO;
> }
>
> - pHba->in_use = 0;
> + pHba->in_use = false;
>
> return 0;
> }
> @@ -2433,8 +2433,8 @@ static s32 adpt_i2o_reparse_lct(adpt_hba* pHba)
> pDev->tid = tid;
>
> memcpy(&d->lct_data, &lct->lct_entry[i], sizeof(i2o_lct_entry));
> if (pDev->pScsi_dev) {
> -
> pDev->pScsi_dev->changed = TRUE;
> -
> pDev->pScsi_dev->removable = TRUE;
> +
> pDev->pScsi_dev->changed = true;
> +
> pDev->pScsi_dev->removable = true;
> }
> }
> // Found it - mark it scanned
> diff --git a/drivers/scsi/dpti.h b/drivers/scsi/dpti.h
> index 0892f6c..5eb7274 100644
> --- a/drivers/scsi/dpti.h
> +++ b/drivers/scsi/dpti.h
RE: [PATCH] aacraid: don't assign cpu_to_le32(constant) to u8
ACK Sincerely -- Mark Salyzyn > -Original Message- > From: Stephen Rothwell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 31, 2007 12:02 AM > To: AACRAID > Cc: [EMAIL PROTECTED]; LKML > Subject: [PATCH] aacraid: don't assign cpu_to_le32(constant) to u8 > > Noticed on PowerPC allmod config build: > > drivers/scsi/aacraid/commsup.c:1342: warning: large integer > implicitly truncated to unsigned type > drivers/scsi/aacraid/commsup.c:1343: warning: large integer > implicitly truncated to unsigned type > drivers/scsi/aacraid/commsup.c:1344: warning: large integer > implicitly truncated to unsigned type > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> > --- > drivers/scsi/aacraid/commsup.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > -- > Cheers, > Stephen Rothwell[EMAIL PROTECTED] > > diff --git a/drivers/scsi/aacraid/commsup.c > b/drivers/scsi/aacraid/commsup.c > index 240a0bb..b9682a8 100644 > --- a/drivers/scsi/aacraid/commsup.c > +++ b/drivers/scsi/aacraid/commsup.c > @@ -1339,9 +1339,9 @@ int aac_check_health(struct aac_dev * aac) > aif = (struct aac_aifcmd *)hw_fib->data; > aif->command = cpu_to_le32(AifCmdEventNotify); > aif->seqnum = cpu_to_le32(0x); > - aif->data[0] = cpu_to_le32(AifEnExpEvent); > - aif->data[1] = cpu_to_le32(AifExeFirmwarePanic); > - aif->data[2] = cpu_to_le32(AifHighPriority); > + aif->data[0] = AifEnExpEvent; > + aif->data[1] = AifExeFirmwarePanic; > + aif->data[2] = AifHighPriority; > aif->data[3] = cpu_to_le32(BlinkLED); > > /* > -- > 1.5.3.4 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv2] aacraid: don't assign cpu_to_le32(constant) to u8
ACK v2 Sincerely -- Mark Salyzyn > -Original Message- > From: Stephen Rothwell [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 01, 2007 2:32 AM > To: AACRAID > Cc: [EMAIL PROTECTED]; LKML > Subject: [PATCHv2] aacraid: don't assign cpu_to_le32(constant) to u8 > > Noticed on PowerPC allmod config build: > > drivers/scsi/aacraid/commsup.c:1342: warning: large integer > implicitly truncated to unsigned type > drivers/scsi/aacraid/commsup.c:1343: warning: large integer > implicitly truncated to unsigned type > drivers/scsi/aacraid/commsup.c:1344: warning: large integer > implicitly truncated to unsigned type > > Also fix some whitespace on the changed lines. > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> > --- > drivers/scsi/aacraid/commsup.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > This version just fixes a couple of whitespace anomolies on > the lines I > changed. > > -- > Cheers, > Stephen Rothwell[EMAIL PROTECTED] > > diff --git a/drivers/scsi/aacraid/commsup.c > b/drivers/scsi/aacraid/commsup.c > index 240a0bb..3c2dbc0 100644 > --- a/drivers/scsi/aacraid/commsup.c > +++ b/drivers/scsi/aacraid/commsup.c > @@ -1339,9 +1339,9 @@ int aac_check_health(struct aac_dev * aac) > aif = (struct aac_aifcmd *)hw_fib->data; > aif->command = cpu_to_le32(AifCmdEventNotify); > aif->seqnum = cpu_to_le32(0x); > - aif->data[0] = cpu_to_le32(AifEnExpEvent); > - aif->data[1] = cpu_to_le32(AifExeFirmwarePanic); > - aif->data[2] = cpu_to_le32(AifHighPriority); > + aif->data[0] = AifEnExpEvent; > + aif->data[1] = AifExeFirmwarePanic; > + aif->data[2] = AifHighPriority; > aif->data[3] = cpu_to_le32(BlinkLED); > > /* > -- > 1.5.3.4 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] aacraid: Resend, Fix security hole
ACK.
Unit tested with Adaptec RAID management applications with apparently no
issue. Will push this into matrix testing in the coming week.
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Cox
> Sent: Monday, July 23, 2007 9:51 AM
> To: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: [PATCH] aacraid: Resend, Fix security hole
>
> On the SCSI layer ioctl path there is no implicit permissions
> check for
> ioctls (and indeed other drivers implement unprivileged
> ioctls). aacraid
> however allows all sorts of very admin only things to be done
> so should
> check.
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
>
> diff -u --new-file --recursive --exclude-from
> /usr/src/exclude
> linux.vanilla-2.6.23rc1/drivers/scsi/aacraid/linit.c
> linux-2.6.23rc1/drivers/scsi/aacraid/linit.c
> --- linux.vanilla-2.6.23rc1/drivers/scsi/aacraid/linit.c
> 2007-07-23 12:56:12.0 +0100
> +++ linux-2.6.23rc1/drivers/scsi/aacraid/linit.c
> 2007-07-23 12:57:45.0 +0100
> @@ -636,6 +636,8 @@
> static int aac_cfg_ioctl(struct inode *inode, struct file *file,
> unsigned int cmd, unsigned long arg)
> {
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> return aac_do_ioctl(file->private_data, cmd, (void
> __user *)arg);
> }
>
> @@ -689,6 +691,8 @@
>
> static long aac_compat_cfg_ioctl(struct file *file, unsigned
> cmd, unsigned long arg)
> {
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> return aac_compat_do_ioctl((struct aac_dev
> *)file->private_data, cmd, arg);
> }
> #endif
> -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: integer overflow in i2o_block
I would change tid from an int to an unsigned instead, he is the culprit that is promoting the unsigned to an signed. Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Meelis Roos > Sent: Thursday, July 26, 2007 4:30 PM > To: Linux Kernel list > Subject: integer overflow in i2o_block > > > Got this warning on 32-bit ppc, seems real? And it seems I2O > subsystem has no maintainer (only DPT_I2O has one)? > > CC [M] drivers/message/i2o/i2o_block.o > drivers/message/i2o/i2o_block.c: In function 'i2o_block_transfer': > drivers/message/i2o/i2o_block.c:837: warning: integer > overflow in expression > > The line in question is > msg->u.head[1] = cpu_to_le32(I2O_CMD_PRIVATE << 24 | HOST_TID > << 12 | tid); > and I2O_CMD_PRIVATE is defined as 0xFF. This gets "0xFF0100 | > tid" and > fits into 32-bit unsigned but not into 32-bit signed integer properly. > Target value head[*] is defined as u32 so the claculation > does not fit > during computation? Should we mark the shiftable inputas as unsigned? > > -- > Meelis Roos ([EMAIL PROTECTED]) > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] aacraid: fix Sunrise Lake reset handling
The patch is *much* smaller than the description. I am attempting to answer to those that want to understand an issue that was reported in May this year. If a Sunrise Lake based card that requires an alternate reset mechanism is set up to ignore the commanded IOP_RESET it reports 0x0010 (IOP_RESET ignored) instead of 0x3803000F (use alternate reset mechanism to reset all cores), and thus the reset platform function decides to switch to IOP_RESET_ALWAYS because the reset platform function parameters indicate that we *need* to reset the card. IOP_RESET_ALWAYS then responds with the 0x3803000F return code, but alas we treat this as an error instead of using the alternate reset mechanism (put a 0x03 into the register offset 0x38). The reset fails, but the fact that the IOP_RESET_ALWAYS command was issued has put the card in a purposeful shutdown state in preparation for the alternate hardware reset to be applied. Yuck. IOP_RESET is ignored in internal production cards, typically to ensure that we catch all adapter lockup issues without the driver progressing further, so this would not appear to be a field issue and thus this patch was destined to be only in the internal Adaptec source tree. IOP_RESET_ALWAYS is reserved for kexec/kdump/FirmwareUpdate/AutomatedTestFrames so we did not function as expected in any case. Also in the past we have had OEMs specifically request that cards not be resetable after a BlinkLED/FirmwareAssert for one reason or another and To head off the possibility that the Sunrise Lake based cards would suffer a similar fate, we propose the enclosed fix. Yinghai Lu of SUN had a pre-production card with IOP_RESET disabled when he reported an issue to the linux kernel list back in May regarding a kexec problem resulting from this reset being ignore. His fix was to update the Firmware to one that did not ignore the IOP_RESET. Previous kernels did not attempt to reset the adapter and that is why it surfaced as a regression in his hands. The current list of aacraid based cards that use Sunrise Lake: 9005:0285:9005:02b5 Adaptec 5445 9005:0285:9005:02b6 Adaptec 5805 9005:0285:9005:02b7 Adaptec 5085 9005:0285:9005:02c3 Adaptec 51205 9005:0285:9005:02c4 Adaptec 51605 9005:0285:9005:02ce Adaptec 51245 9005:0285:9005:02cf Adaptec 51645 9005:0285:9005:02d0 Adaptec 52445 9005:0285:9005:02d1 Adaptec 5405 9005:0285:9005:02b8 ICP ICP5445SL 9005:0285:9005:02b9 ICP ICP5085SL 9005:0285:9005:02ba ICP ICP5805SL 9005:0285:9005:02c5 ICP ICP5125SL 9005:0285:9005:02c6 ICP ICP5165SL 9005:0285:108e:7aac SUN STK RAID REM 9005:0285:108e:0286 SUN STK RAID INT 9005:0285:108e:0287 SUN STK RAID EXT 9005:0285:108e:7aae SUN STK RAID EM All of these are publicly released with IOP_RESET enabled. So there is no immediate need for this patch. This attached patch is against July 11 2007 scsi-misc-2.6, still applies today. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> /drivers/scsi/aacraid/rx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Sincerely -- Mark Salyzyn -Original Message- From: Yinghai Lu [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 29, 2007 10:00 PM To: Andrew Morton; Vivek Goyal; Eric W. Biederman; AACRAID Cc: Linux Kernel Mailing List Subject: kexec and aacraid broken latest tree, can not use kexec to load 2.6.22-rc3 at least. got: AAC0: adapter kernel panic'd fffd AAC0: adapter kernel failed to start, init status=0 but can load 2.6.21.3 YH aacraid_voodoo_reset.patch Description: aacraid_voodoo_reset.patch
RE: [PATCH 21] drivers/scsi/dpt_i2o.c: kmalloc + memset conversion to kzalloc
ACK Looks good and ultra-light on side effects! Sincerely -- Mark Salyzyn > -Original Message- > From: Mariusz Kozlowski [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 31, 2007 1:35 PM > To: linux-kernel@vger.kernel.org > Cc: [EMAIL PROTECTED]; Andrew Morton; > [EMAIL PROTECTED]; AACRAID > Subject: [PATCH 21] drivers/scsi/dpt_i2o.c: kmalloc + memset > conversion to kzalloc > > Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]> > > drivers/scsi/dpt_i2o.c | 87632 -> 87457 (-175 bytes) > drivers/scsi/dpt_i2o.o | 213064 -> 212324 (-740 bytes) > > drivers/scsi/dpt_i2o.c | 27 +++ > 1 file changed, 11 insertions(+), 16 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [20/2many] MAINTAINERS - DPT_I2O SCSI RAID DRIVER
ACK Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, August 13, 2007 2:22 AM > To: [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED]; AACRAID > Subject: [PATCH] [20/2many] MAINTAINERS - DPT_I2O SCSI RAID DRIVER > > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 71e09b7..7d58f6b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -232,6 +232,8 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://www.adaptec.com/ > S: Maintained > +F: drivers/scsi/dpt* > +F: drivers/scsi/dpt/ > > AACRAID SCSI RAID DRIVER > P: Adaptec OEM Raid Solutions - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [21/2many] MAINTAINERS - AACRAID SCSI RAID DRIVER
ACK Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, August 13, 2007 2:22 AM > To: [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED]; AACRAID > Subject: [PATCH] [21/2many] MAINTAINERS - AACRAID SCSI RAID DRIVER > > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7d58f6b..1162fb7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -241,6 +241,7 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://www.adaptec.com/ > S: Supported > +F: drivers/scsi/aacraid/ > > ACPI > P: Len Brown > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [19/2many] MAINTAINERS - IPS SCSI RAID DRIVER
ACK Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, August 13, 2007 2:22 AM > To: [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED]; AACRAID > Subject: [PATCH] [19/2many] MAINTAINERS - IPS SCSI RAID DRIVER > > > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 141b08a..71e09b7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -224,6 +224,7 @@ M:[EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://www.adaptec.com/ > S: Maintained > +F: drivers/scsi/ips* > > DPT_I2O SCSI RAID DRIVER > P: Adaptec OEM Raid Solutions > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [21/2many] MAINTAINERS - AACRAID SCSI RAID DRIVER
Second thoughts ... Add the documentation file as well. F: drivers/scsi/aacraid/ +F: Documentation/scsi/aacraid.txt Sincerely -- Mark Salyzyn > -Original Message- > From: Salyzyn, Mark > Sent: Monday, August 13, 2007 9:34 AM > To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; > '[EMAIL PROTECTED]'; 'linux-kernel@vger.kernel.org'; > '[EMAIL PROTECTED]'; AACRAID > Subject: RE: [PATCH] [21/2many] MAINTAINERS - AACRAID SCSI RAID DRIVER > > ACK > > Sincerely -- Mark Salyzyn > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 13, 2007 2:22 AM > > To: [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > > [EMAIL PROTECTED]; AACRAID > > Subject: [PATCH] [21/2many] MAINTAINERS - AACRAID SCSI RAID DRIVER > > > > Add file pattern to MAINTAINER entry > > > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 7d58f6b..1162fb7 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -241,6 +241,7 @@ M: [EMAIL PROTECTED] > > L: [EMAIL PROTECTED] > > W: http://www.adaptec.com/ > > S: Supported > > +F: drivers/scsi/aacraid/ > > > > ACPI > > P: Len Brown > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [21/2many] MAINTAINERS - AACRAID SCSI RAID DRIVER
Please do not collapse AACRAID with DPT_I2O and IPS yet. IMHO Just because today the maintainer email is the same is not a reason to collapse, I am only 'paid' to look after aacraid and that one is provided continued Adaptec support, the others are legacy and maintenance-only. Sincerely -- Mark Salyzyn > -Original Message- > From: Joe Perches [mailto:[EMAIL PROTECTED] > Sent: Monday, August 13, 2007 1:20 PM > To: Salyzyn, Mark > Cc: [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: RE: [PATCH] [21/2many] MAINTAINERS - AACRAID SCSI RAID DRIVER > > > On Mon, 2007-08-13 at 10:16 -0400, Salyzyn, Mark wrote: > > Second thoughts ... Add the documentation file as well. > > +F: Documentation/scsi/aacraid.txt > > AACRAID SCSI RAID DRIVER > P:Adaptec OEM Raid Solutions > M:[EMAIL PROTECTED] > L:[EMAIL PROTECTED] > W:http://www.adaptec.com/ > S:Supported > F:Documentation/scsi/aacraid.txt > F:drivers/scsi/aacraid/ > > Maybe all 3 entries should be collapsed into > > ADAPTEC SCSI RAID (AACRAID, DPT_I2O, IPS)? > P:Adaptec OEM Raid Solutions > M:[EMAIL PROTECTED] > L:[EMAIL PROTECTED] > W:http://www.adaptec.com/ > S:Supported > F:Documentation/scsi/aacraid.txt > F:drivers/scsi/aacraid/ > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH -mm 11/11] aacraid: use pci_set_dma_max_seg_size
ACK
Based on the presence of the call. 2.6.22, for instance, does not have
this capability...
I did not test this change, just accepting on the principals. How much
testing of the change did you do Fujita?
Sincerely -- Mark Salyzyn
> -Original Message-
> From: FUJITA Tomonori [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 24, 2007 6:49 AM
> To: [EMAIL PROTECTED]
> Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; AACRAID; [EMAIL PROTECTED]
> Subject: [PATCH -mm 11/11] aacraid: use pci_set_dma_max_seg_size
>
> This sets the segment size limit properly via pci_set_dma_max_seg_size
> and remove blk_queue_max_segment_size because scsi-ml calls it.
>
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---
> drivers/scsi/aacraid/linit.c |9 ++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/aacraid/linit.c
> b/drivers/scsi/aacraid/linit.c
> index 038980b..04d6a65 100644
> --- a/drivers/scsi/aacraid/linit.c
> +++ b/drivers/scsi/aacraid/linit.c
> @@ -435,9 +435,6 @@ static int aac_slave_configure(struct
> scsi_device *sdev)
> else if (depth < 2)
> depth = 2;
> scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, depth);
> - if (!(((struct aac_dev
> *)host->hostdata)->adapter_info.options &
> - AAC_OPT_NEW_COMM))
> -
> blk_queue_max_segment_size(sdev->request_queue, 65536);
> } else
> scsi_adjust_queue_depth(sdev, 0, 1);
>
> @@ -1045,6 +1042,12 @@ static int __devinit
> aac_probe_one(struct pci_dev *pdev,
> if (error < 0)
> goto out_deinit;
>
> + if (!(aac->adapter_info.options & AAC_OPT_NEW_COMM)) {
> + error = pci_set_dma_max_seg_size(pdev, 65536);
> + if (error)
> + goto out_deinit;
> + }
> +
> /*
>* Lets override negotiations and drop the maximum SG
> limit to 34
>*/
> --
> 1.5.2.4
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH -mm 11/11] aacraid: use pci_set_dma_max_seg_size
Jeff Garzik [mailto:[EMAIL PROTECTED] writes: > is this needed, given that the default is already 65536? Apparently so, as we had to add it in the past, mainly because the feature to limit was not part of the SCSI layer when the original limit code was added. At that time it replaced a complicated sg breakup algorithm. Does your statement guarantee that the default will not change to a large value? If not, then we need to enforce it in perpetuity... Sincerely -- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH -mm 11/11] aacraid: use pci_set_dma_max_seg_size
Not requesting you to test (aacraid), just scoping any effort. The cards in question are the (old) Dell PERC variety that would trigger the need. I will notify our Dell liaison to see what they can do. Sincerely -- Mark Salyzyn > -Original Message- > From: FUJITA Tomonori [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 24, 2007 12:22 PM > To: Salyzyn, Mark > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; AACRAID; [EMAIL PROTECTED] > Subject: RE: [PATCH -mm 11/11] aacraid: use pci_set_dma_max_seg_size > > On Wed, 24 Oct 2007 09:34:23 -0400 > "Salyzyn, Mark" <[EMAIL PROTECTED]> wrote: > > > ACK > > Thanks. > > > Based on the presence of the call. 2.6.22, for instance, > does not have > > this capability... > > > > I did not test this change, just accepting on the > principals. How much > > testing of the change did you do Fujita? > > Unfortunately, I tested only the main component (device and pci > changes) with ppc64 IOMMU. I don't have the other IOMMUs. > > I didn't test the aacraid patch but I guess that I have aacraid in the > workplace so I can test the patch (without the IOMMU chages). > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/4] [SCSI] ips: remove ips_ha members that duplicate struct pci_dev members
ACK. Inspected; Mechanical, precise and no introduction of bugs. Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik > Sent: Wednesday, October 24, 2007 7:48 PM > To: LKML; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [PATCH 1/4] [SCSI] ips: remove ips_ha members that > duplicate struct pci_dev members > > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> > --- > drivers/scsi/ips.c | 178 > > drivers/scsi/ips.h | 20 +++ > 2 files changed, 91 insertions(+), 107 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/4] [SCSI] ips: trim trailing whitespace
ACK. Inspected; trivial, clean and no sign of any code changes. Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik > Sent: Wednesday, October 24, 2007 7:48 PM > To: LKML; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [PATCH 2/4] [SCSI] ips: trim trailing whitespace > > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> > --- > drivers/scsi/ips.c | 44 > ++-- > drivers/scsi/ips.h | 12 ++-- > 2 files changed, 28 insertions(+), 28 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/4] [SCSI] ips: PCI API cleanups
ACK. Inspected only. Looks ok.
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik
> Sent: Wednesday, October 24, 2007 7:49 PM
> To: LKML; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [PATCH 3/4] [SCSI] ips: PCI API cleanups
>
> * pass Scsi_Host to ips_remove_device() via pci_set_drvdata(),
> allowing us to eliminate the ips_ha[] search loop and call
> ips_release() directly.
>
> * call pci_{request,release}_regions() and eliminate individual
> request/release_[mem_]region() calls
>
> * call pci_disable_device(), paired with pci_enable_device()
>
> * s/0/NULL/ in a few places
>
> * check ioremap() return value
>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
> ---
> drivers/scsi/ips.c | 72
> ++-
> 1 files changed, 31 insertions(+), 41 deletions(-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/4] [SCSI] ips: handle scsi_add_host() failure, and other err cleanups
ACK. Inspected. cleanup with zero risk. Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik > Sent: Wednesday, October 24, 2007 7:49 PM > To: LKML; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [PATCH 4/4] [SCSI] ips: handle scsi_add_host() > failure, and other err cleanups > > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> > --- > drivers/scsi/ips.c | 18 +- > 1 files changed, 13 insertions(+), 5 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] aacraid: don't assign cpu_to_le32(int) to u8
Christoph Hellwig [mailto:[EMAIL PROTECTED] sez: > Did anyone run the driver through sparse to see if we have > more issues like this? There are some warnings from sparse, none like this one. I will deal with the warnings ... Sincerely -- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] aacraid: don't assign cpu_to_le32(int) to u8
Good point, thanks. The intent of the management applications utilization of this AIF report is to observe the LSB of the value of integer value in BlinkLED. The actions of the cpu_to_le32 actually breaks this and reports the wrong content in swapped architectures. This attached follow-up patch is against current scsi-misc-2.6 *after* the application of the 'don't assign cpu_to_le32(constant) to u8' patch submitted by Stephen Rothwell which has already been taken by the -mm tree. Inspection of other areas of the aacraid driver came up blank for similar style bugs. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments (inline gets damaged, use attachment). Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> drivers/scsi/aacraid/commsup.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -ru a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c --- a/drivers/scsi/aacraid/commsup.c2007-11-07 10:35:16.603727464 -0500 +++ b/drivers/scsi/aacraid/commsup.c2007-11-07 10:37:50.540311107 -0500 @@ -1342,7 +1342,7 @@ aif->data[0] = AifEnExpEvent; aif->data[1] = AifExeFirmwarePanic; aif->data[2] = AifHighPriority; - aif->data[3] = cpu_to_le32(BlinkLED); + aif->data[3] = BlinkLED; /* * Put the FIB onto the Sincerely -- Mark Salyzyn > -Original Message- > From: Andreas Schwab [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 01, 2007 9:31 AM > To: Stephen Rothwell > Cc: AACRAID; [EMAIL PROTECTED]; LKML > Subject: Re: [PATCHv2] aacraid: don't assign > cpu_to_le32(constant) to u8 > > Stephen Rothwell <[EMAIL PROTECTED]> writes: > > > diff --git a/drivers/scsi/aacraid/commsup.c > b/drivers/scsi/aacraid/commsup.c > > index 240a0bb..3c2dbc0 100644 > > --- a/drivers/scsi/aacraid/commsup.c > > +++ b/drivers/scsi/aacraid/commsup.c > > @@ -1339,9 +1339,9 @@ int aac_check_health(struct aac_dev * aac) > > aif = (struct aac_aifcmd *)hw_fib->data; > > aif->command = cpu_to_le32(AifCmdEventNotify); > > aif->seqnum = cpu_to_le32(0x); > > - aif->data[0] = cpu_to_le32(AifEnExpEvent); > > - aif->data[1] = cpu_to_le32(AifExeFirmwarePanic); > > - aif->data[2] = cpu_to_le32(AifHighPriority); > > + aif->data[0] = AifEnExpEvent; > > + aif->data[1] = AifExeFirmwarePanic; > > + aif->data[2] = AifHighPriority; > > aif->data[3] = cpu_to_le32(BlinkLED); > > What about the last line? > > Andreas. aacraid_BlinkLED.patch Description: aacraid_BlinkLED.patch
RE: [PATCH 1/1] aacraid: don't assign cpu_to_le32(int) to u8
Resounding ACK. I just finished *exactly* the same set of changes, composed the patch and was about to hit send when this one came over the wire from you! There was absolutely no differences between our patches (save for the fact I did not place the AIF ones in as they are already in the queue, one is already on -mm). I am going to return to this at some future date and figure out the problems surrounding the context imbalances that are present, making code that determines which context it is called from (sysfs, error recovery or from the background thread) and plays with the various locks confuses sparse. Rewriting so that the contexts are less programmatic is in order... Sincerely -- Mark Salyzyn > -Original Message- > From: Christoph Hellwig [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 08, 2007 12:28 PM > To: Salyzyn, Mark > Cc: Christoph Hellwig; Andreas Schwab; Stephen Rothwell; > [EMAIL PROTECTED]; LKML > Subject: Re: [PATCH 1/1] aacraid: don't assign cpu_to_le32(int) to u8 > > On Wed, Nov 07, 2007 at 01:51:44PM -0500, Salyzyn, Mark wrote: > > Christoph Hellwig [mailto:[EMAIL PROTECTED] sez: > > > Did anyone run the driver through sparse to see if we have > > > more issues like this? > > > > There are some warnings from sparse, none like this one. I will deal > > with the warnings ... > > Actually there are a lot of endianess warnings, fortunately > most of them > harmless. The patch below fixes all of them up (including the ones in > the patch I replied to), except for aac_init_adapter which is > really odd > and I don't know what to do. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: udev/aacraid interaction - should aacraid set 'removable'?
The ips driver, indirectly via Firmware as it spoofs it's own inquiry data, reports the Removable bit set in the inquiry response for the arrays. The dpt_i2o driver similarly has the firmware constructing the bit set. Some of the Array Bridges and external RAID boxes do the same thing. I think the aacraid driver is the only RAID driver that has it's own SCSI interpreter such that this coded activity surrounding the removable status is visible, however it currently responds by setting the removable scsi_device field when the READ_CAPACITY is reported. About four years ago and before it would actually set the RMB bit in the Inquiry response like the other array drivers. If a new interface was added to tell the scsi layer to re-read the partition table, then the aacraid driver, at least, could stop reporting the array as removable. However, we loose the 'busy check' that results from the upper layers doing media locking when the removable device is mounted; the array management applications would then be permitted to change an array while it is in use. We would need some other way of asking the upper layers if the device is in use (open or mounted), that apparently is impossible given the new design of the scsi layers (Christoph?). Sincerely -- Mark Salyzyn > -Original Message- > From: dann frazier [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 03, 2007 10:58 AM > To: Salyzyn, Mark; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > debian-kernel@lists.debian.org > Subject: udev/aacraid interaction - should aacraid set 'removable'? > > > (lkml readers: this concerns a security issue reported to debian by a > user of udev/aacraid. udev gives the aacraid devices the floppy group > because it reports block devices as 'removable'. See > http://bugs.debian.org/404927 for the entire thread). > > On Wed, Jan 03, 2007 at 11:49:51AM +0100, Marco d'Itri wrote: > > On Jan 03, dann frazier <[EMAIL PROTECTED]> wrote: > > > > > Can you elaborate on what you believe the kernel is doing > > > incorrectly? My first guess would be the setting of the removable > > > flag, but aacraid claims to be setting this to prevent > partition table > > > caching - do you believe that to be an incorrect usage? > > Yes, this looks like an abuse of the interface to me. > > Ok, let's ask lkml > > > > It seems like there is precedence for workarounds for > older kernels in > > > permissions.rules, so would it be appropriate to add an > override of > > > the default floppy rule for aacraid devices for > compatability even if > > > this is a kernel bug? > > There are workarounds for bugs which are going to be fixed, > but looks > > like this is going to stay forever... > > Are there other drivers in this situation? > > I didn't turn up any otherwise when I was grepping yesterday, but my > search terms may have been too naive. I also checked a machine I had > w/ cciss - it did not have the removable flag set. > > I found a message from Mark Salyzyn from last year that suggested this > was more pervasive: > http://www.ussg.iu.edu/hypermail/linux/kernel/0602.2/1231.html > Mark: Can you identify some of these other drivers? > > > -- > dann frazier > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: udev/aacraid interaction - should aacraid set 'removable'?
I do not have any close at hand (cleaned out the hardware closet to hazardous waste) :-( But, as far as I am concerned :-), if it says 'DPT' or 'Adaptec' as the manufacturer's name portion of the inquiry field, or has 'RAID' or 'Array' somewhere in the product name inquiry field, you have covered most, if not all, of the possibilities I can come up with! Hope that helps. Sincerely -- Mark Salyzyn > -Original Message- > From: dann frazier [mailto:[EMAIL PROTECTED] > Sent: Friday, January 05, 2007 3:14 PM > To: Salyzyn, Mark > Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > debian-kernel@lists.debian.org > Subject: Re: udev/aacraid interaction - should aacraid set > 'removable'? > > > On Wed, Jan 03, 2007 at 12:17:47PM -0500, Salyzyn, Mark wrote: > > The ips driver, indirectly via Firmware as it spoofs it's > own inquiry > > data, reports the Removable bit set in the inquiry response for the > > arrays. The dpt_i2o driver similarly has the firmware > constructing the > > bit set. Some of the Array Bridges and external RAID boxes > do the same > > thing. > > Thanks Mark. If you have any of these devices, could you help supply > the udevinfo information? Our udev maintainer has asked for this so > that he can workaround this issue by special casing these > devices. (See http://bugs.debian.org/404927 for details). > > -- > dann frazier > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: howto create partitions bigger than 2TB
Put a file system on the entire device, stop trying to partition it. The standard DOS partition table is of no use to you above 2TB. Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ingo Freund > Sent: Friday, July 13, 2007 8:55 AM > To: linux-kernel@vger.kernel.org > Subject: howto create partitions bigger than 2TB > > Hi > > I've got a RAID5 (driver aacraid for an ICP9047MA) with four > 750GB hdds which provides a 2.25TB sized device. > None of the until now used tools will work with that device. > fdisk complains about missing cylinder count. > cfdisk misses the device size. > parted shows the right device size but only creates a partion > with 51GB. > What am I supposed to do to work with this device? > Which fs can handle it? > (CONFIG LARGE BLOCK is on) > We are talking about a 32Bit machine with vanilla kernel 2.6.21.5. > > Thanks in advance, > Regards - Ingo. > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kexec and aacraid broken
I believe this issue is a result of the aacraid_commit_reset patch (as posted for scsi-misc-2.6, enclosed to permit testing) not yet propagated to the 2.6.22-rc3 tree. This is the adapter taking longer than 3 minutes to start after a reset. I seriously doubt either of these patches suggested below will have an affect. And if they do, they are not root cause, one reduces the chances that the card will be reset during initialization (thus applied would likely mitigate this problem), the other prevents a panic when the Adapter is reset (removed, would result in dogs and cats sleeping with each other). Please use kernel parameter aacraid.startup_timeout=540 (merely larger than the default 180 seconds) when spawning the kexec or see if the aacraid_commit_reset.patch resolves the issue to confirm my hunch. Sincerely -- Mark Salyzyn > -Original Message- > From: Andrew Morton [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 29, 2007 10:14 PM > To: Yinghai Lu > Cc: Vivek Goyal; Eric W. Biederman; AACRAID; Linux Kernel > Mailing List; [EMAIL PROTECTED]; Michal Piotrowski > Subject: Re: kexec and aacraid broken > > > On Tue, 29 May 2007 18:59:32 -0700 "Yinghai Lu" > <[EMAIL PROTECTED]> wrote: > > > latest tree, can not use kexec to load 2.6.22-rc3 at least. > > > > got: > > > > AAC0: adapter kernel panic'd fffd > > AAC0: adapter kernel failed to start, init status=0 > > One of the two diffs below, I guess. Please do a `patch -R > -p1' of this > email and retest? > > > > > but can load 2.6.21.3 > > > > Michal, can you please add this to the regression list? > > > > > commit 9e4d4a5d71d673901d9c1df5146ce545c2cc0cc0 > Author: Salyzyn, Mark <[EMAIL PROTECTED]> > Date: Tue May 1 11:43:06 2007 -0400 > > [SCSI] aacraid: superfluous adapter reset for IBM 8 > series ServeRAID controllers > > The kexec patch introduced a superfluous (and otherwise > inert) reset of > some adapters. The register can have a hardware default > value that has > zeros for the undefined interrupts. This patch refines > the test of the > interrupt enable register to focus on only the interrupts > that affect > the driver in order to detect if an incomplete shutdown > of the Adapter > had occurred (kdump). > > Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> > Signed-off-by: James Bottomley <[EMAIL PROTECTED]> > > diff --git a/drivers/scsi/aacraid/rx.c b/drivers/scsi/aacraid/rx.c > index b6ee3c0..291cd14 100644 > --- a/drivers/scsi/aacraid/rx.c > +++ b/drivers/scsi/aacraid/rx.c > @@ -542,7 +542,7 @@ int _aac_rx_init(struct aac_dev *dev) > dev->a_ops.adapter_sync_cmd = rx_sync_cmd; > dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt; > dev->OIMR = status = rx_readb (dev, MUnit.OIMR); > - if status & 0xff) != 0xff) || reset_devices) && > + if status & 0x0c) != 0x0c) || reset_devices) && > !aac_rx_restart_adapter(dev, 0)) > ++restart; > /* > commit a5694ec545a880f9d23463fddc894f5096cc68fa > Author: Salyzyn, Mark <[EMAIL PROTECTED]> > Date: Mon Apr 30 13:22:24 2007 -0400 > > [SCSI] aacraid: kexec fix (reset interrupt handler) > > Another layer on this onion also discovered by Duane, the > interrupt enable handler also needed to be set ... The > interrupt enable > was called from within the synchronous command handler. > > Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> > Signed-off-by: James Bottomley <[EMAIL PROTECTED]> > > diff --git a/drivers/scsi/aacraid/rx.c b/drivers/scsi/aacraid/rx.c > index 0c71315..b6ee3c0 100644 > --- a/drivers/scsi/aacraid/rx.c > +++ b/drivers/scsi/aacraid/rx.c > @@ -539,6 +539,8 @@ int _aac_rx_init(struct aac_dev *dev) > } > > /* Failure to reset here is an option ... */ > + dev->a_ops.adapter_sync_cmd = rx_sync_cmd; > + dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt; > dev->OIMR = status = rx_readb (dev, MUnit.OIMR); > if status & 0xff) != 0xff) || reset_devices) && > !aac_rx_restart_adapter(dev, 0)) > > aacraid_commit_reset.patch Description: aacraid_commit_reset.patch
RE: kexec and aacraid broken
This is clouding the issue, Vivek. There should be no harm, except to time, resetting the adapter. I do want to optimize for boot time, but do not view this as a 'bug' if the Adapter should reset during the initialization procedure. We need instead to harden the driver to deal with Adapters that behave in an untimely manner as a result of the reset since this generically deals with all possible transitions (boot w/o BIOS, w/BIOS, kexec and kdump). I will look into a possibility the driver is not performing the clean shutdown as a result of a kexec, but that is a refinement and should not be considered a fix for *this* reported problem; it merely moves the problem to a kdump. The driver only disables the interrupts when the driver is .remove'd (aac_remove_one) and not for .shutdown (aac_shutdown). The later merely tells the firmware to stop performing builds if in progress, flush the cache, and all subsequent writes are performed in write-through mode; it does not clear out the driver resources and leaves that to the .remove function only. The failure of .remove being called may be a result of this being a boot driver? Also, the code: dev->OIMR = status = rx_readb (dev, MUnit.OIMR); if status & 0x0c) != 0x0c) . . . detects if the adapter's interrupts were disabled, as would happen on a clean shutdown. Some of the Adapters can NOT disable their interrupts, and some have a default state with the interrupts enabled. If the Adapter still has active interrupts, then there is no telling what transpired before and it is considered a safety measure to reset the Adapter in these cases. I'd prefer to err on the side of resetting the Adapter superfluously than deal with a condition where the Adapter could be in an unknown state with a possibility of sustaining an outstanding command and associated interrupt (which was the whole reason this code was introduced). In time I am sure, I will refine this code to incorporate Quirks for adapters that have unusual conditions for the above stated interrupt and remove the possible superfluous reset. Yinghai, can you please provide the Adapter designation just in case it could be the first in this refined list. I will NOT consider this refinement a bugfix for the same reasons stated above. Sincerely -- Mark Salyzyn > -Original Message- > From: Vivek Goyal [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 9:25 AM > To: Salyzyn, Mark > Cc: Andrew Morton; Yinghai Lu; Eric W. Biederman; Linux > Kernel Mailing List; [EMAIL PROTECTED]; Michal Piotrowski > Subject: Re: kexec and aacraid broken > > > On Wed, May 30, 2007 at 07:44:02AM -0400, Salyzyn, Mark wrote: > > I believe this issue is a result of the > aacraid_commit_reset patch (as > > posted for scsi-misc-2.6, enclosed to permit testing) not > yet propagated > > to the 2.6.22-rc3 tree. > > > > This is the adapter taking longer than 3 minutes to start > after a reset. > > I seriously doubt either of these patches suggested below > will have an > > affect. And if they do, they are not root cause, one > reduces the chances > > that the card will be reset during initialization (thus > applied would > > likely mitigate this problem), the other prevents a panic when the > > Adapter is reset (removed, would result in dogs and cats > sleeping with > > each other). > > > > Please use kernel parameter aacraid.startup_timeout=540 > (merely larger > > than the default 180 seconds) when spawning the kexec or see if the > > aacraid_commit_reset.patch resolves the issue to confirm my hunch. > > > > Hi Mark, > > During a normal kexec (not kdump) adapter reset should not have taken > place at all. device_shutdown() routines should have taken care to > bring the device to a known sane state in first kernel so that second > kernel can initialize it without doing a reset. > > With reset patch, now reset triggers on every kexec. Previously > that was not the case with kexec and adapter used to come up. I think > this needs to be looked into. > > Thanks > Vivek > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kexec and aacraid broken
Vivek Goyal [mailto:[EMAIL PROTECTED] writes: > So most likely if we start disabling the interrupts > in .shutdown routine we might skip resetting adapter > on every kexec without any side affects? Not that simple. The .shutdown would need to perform more resource cleanups of the .remove call to prevent side effects. I need to move some of the .remove activity into the .shutdown handler to make sure the adapter is quiesced. I will hold off on submitting any of these changes until they are evaluated and tested; I am waiting for feedback from Yinghai on the other mitigations that I feel are closer to the root cause. Sincerely -- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] aacraid: fix shutdown handler to also disable interrupts.
Moves quiesce, thread and interrupt shutdown into aacraid drivers' .shutdown handler. This fix to the aac_shutdown handler will remove the superfluous reset of the adapter during a (clean) kexec. This fix may mitigate the active investigation 'kexec and aacraid broken' but it is unlikely to affect the root cause (issue likely present in both kexec and kdump). This patch reduces the chance the problem will occur with a kexec. The fix for root cause is currently expected to be the minimum value check to the aacraid.startup_timeout driver variable after an adapter reset within aacraid_commit_reset.patch submitted on 05/22/2007 and awaiting testing by Yinghai to confirm. 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]> Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Salyzyn, Mark > Sent: Wednesday, May 30, 2007 10:31 AM > To: [EMAIL PROTECTED] > Cc: Andrew Morton; Yinghai Lu; Eric W. Biederman; Linux > Kernel Mailing List; [EMAIL PROTECTED]; Michal Piotrowski > Subject: RE: kexec and aacraid broken > > Vivek Goyal [mailto:[EMAIL PROTECTED] writes: > > So most likely if we start disabling the interrupts > > in .shutdown routine we might skip resetting adapter > > on every kexec without any side affects? > > Not that simple. The .shutdown would need to perform more resource > cleanups of the .remove call to prevent side effects. I need to move > some of the .remove activity into the .shutdown handler to > make sure the > adapter is quiesced. > > I will hold off on submitting any of these changes until they are > evaluated and tested; I am waiting for feedback from Yinghai on the > other mitigations that I feel are closer to the root cause. > > Sincerely -- Mark Salyzyn aacraid_shutdown.patch Description: aacraid_shutdown.patch
RE: kexec and aacraid broken
Yinghai Lu [mailto:[EMAIL PROTECTED] writes: > aacraid_commit_reset.patch is in the mainline already. But aacraid_commit_reset.patch is not in 2.6.22-rc3 (to which you report the issue). Does the aacraid_commit_reset.patch work to resolve this issue all by itself in the kexec'd kernel? Or alternatively did you try aacraid.startup_timeout=540 as one of the kernel parameters passed to the kexec'd kernel? The '[PATCH] aacraid: fix shutdown handler to also disable interrupts' patch (you refer to this as patch 4) is not to be in the picture because it will hide the root cause. I believe I have you correct in stating that this patch (4) resolves the problem... but I expect the problem to remain with kdump. Sincerely -- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kexec and aacraid broken
> No, still get adapter kernel panic Which adapter are you using? Sincerely -- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kexec and aacraid broken
A. explains why I am having troubles duping this issue thus far. This is prerelease Firmware on a yet to be released card and thus should not get any driver workarounds if this issue can be resolved in Firmware. If this can be duped on a released card with released Firmware, then the story changes of course; but still does not preclude a Firmware/Hardware/Drive Compatibility bug ;-} . Until then, please work this issue via SUN channels so that we get all the necessary card debug information for our teams to work this. I will ensure Adaptec will remain on top of this issue since it is clearly a problem with the Adapter Hardware interfacing. The adapter is not surviving an IOP_RESET and is going into an Adapter Firmware Kernel Panic or taking an excessively long period (in the testing thus far > 540 seconds) of time to complete it's reset. Sincerely -- Mark Salyzyn Yinghai Lu [mailto:[EMAIL PROTECTED] sez: > SUN coguar with 11731 > > On 5/31/07, Salyzyn, Mark <[EMAIL PROTECTED]> wrote: > > > No, still get adapter kernel panic > > > > Which adapter are you using? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] aacraid: fix shutdown handler to also disable interrupts.
Yes, this patch makes sure that the Adapter is shut down correctly, and thus when the kexec driver loads, it does not automatically reset the adapter during initialization. This regression was a result of adding code to the driver to detect if the adapter needed a reset as a result of an unclean shutdown in order to deal with an issue that came up with kdump. Kdump does not issue a clean shutdown. As you see, it was the process of making the driver smarter to find out if it needed to reset the adaptec fw that triggered the problem. As noted before, please be advised to go through SUN channels. Upgrade your Drive(s), SES, Motherboard and Card Firmware to the latest versions; and make sure you are using compatible drives and drive bays to see if this problem dealing with the superfluous reset on your pre-release system goes away. You will be able to trigger this by trying to perform a kdump on the system, OR by reverting this patch and running your kexec test. The superfluous reset has yet to cause an issue with a released card beyond noticing a superfluous Firmware reset as Vivek has pointed out. Sincerely -- Mark Salyzyn From: Yinghai Lu [mailto:[EMAIL PROTECTED] sez: > On 6/1/07, Vivek Goyal <[EMAIL PROTECTED]> wrote: > > Thanks Mark. This does fix the issue of unnecessary reset of aacraid > > adapter over kexec on my machine. > i'm little confused about that. > this patch is some clear shutdown, so even next start will have tight > condition will not try to reset the adapter fw. right Mark? > Maybe the driver could be smart to find out if it need to > reset adaptec fw. > > YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [2/3] 2.6.22-rc3: known regressions v2
Agree, but overstated somewhat. The card in question that the regression is reported against is not a released card and as such could have a flawed environment, Hardware, Firmware or other Incompatibility. The fix for the root cause will likely not touch the driver or the kernel. It does raise the specter of a possible follow-on patch to address the root cause under kdump should we determine that the problem can not be solved in time of release of the Firmware of the current pre-released card or if we discover that other released cards have a similar Firmware or Hardware bug. Speculation such as these do not belong on kernel regression reports IMHO. Sincerely -- Mark Salyzyn > -Original Message- > From: Vivek Goyal [mailto:[EMAIL PROTECTED] > Sent: Friday, June 01, 2007 1:54 PM > To: Andrew Morton > Cc: Michal Piotrowski; Linus Torvalds; LKML; > [EMAIL PROTECTED]; Robert de Rooy; Alan Cox; > Tejun Heo; [EMAIL PROTECTED]; Jeff Garzik; Gregor > Jasny; [EMAIL PROTECTED]; James Bottomley; AACRAID; > Yinghai Lu; Vivek Goyal; [EMAIL PROTECTED]; David > Miller; Mikael Pettersson > Subject: Re: [2/3] 2.6.22-rc3: known regressions v2 > > > On Fri, Jun 01, 2007 at 09:01:15AM -0700, Andrew Morton wrote: > > On Fri, 01 Jun 2007 14:20:55 +0200 Michal Piotrowski > <[EMAIL PROTECTED]> wrote: > > > > > SCSI > > > > > > Subject: aacraid: adapter kernel panic'd fffd (kexec) > > > References : http://lkml.org/lkml/2007/5/29/491 > > > Submitter : Yinghai Lu <[EMAIL PROTECTED]> > > > Handled-By : Salyzyn, Mark <[EMAIL PROTECTED]> > > > Vivek Goyal <[EMAIL PROTECTED]> > > > Status : problem is being debugged > > > > Mark's > aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is > > known to fix this, so we can move this to "known > regressions with patches" > > Hi Andrew, > > aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is meant > to ensure that we don't perform an unnecessary reset of the device > during a kexec boot. During kexec, we perform the device_shutdown() > which should bring the device to a known sane state and a reset is > not required while next kernel is coming up. > > I think this fix just masks Yinghai's problem and as such does not > fix the root cause of the problem. In his case a software reset > of the card is not successful and this is a problem. This problem > will become visible during kdump. > > So I would think that this regression is still there just that got > shifted from kexec to kdump. > > But we do need above patch to make sure kexec boot is fast and does > not perform any unrequired device reset. > > Thanks > Vivek > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [stable] [patch 37/54] SCSI: aacraid: Correct sa platformsupport. (Was: [Bug 8469] Bad EIP value on pentium3 SMPkernel-2.6.21.1)
Yes, split the patch into the two pieces for 2.6.21.1/2.6.21.4
Sincerely -- Mark Salyzyn
> -Original Message-
> From: Chris Wright [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 08, 2007 1:46 PM
> To: Stefan Lippers-Hollmann
> Cc: Chris Wright; James Bottomley; AACRAID; Greg
> Kroah-Hartman; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
> Subject: Re: [stable] [patch 37/54] SCSI: aacraid: Correct sa
> platformsupport. (Was: [Bug 8469] Bad EIP value on pentium3
> SMPkernel-2.6.21.1)
>
>
> * Stefan Lippers-Hollmann ([EMAIL PROTECTED]) wrote:
> > This patch fails to compile on amd64 and i386 with the
> attached config
> > (CONFIG_SCSI_AACRAID=m, 2.6.21.5-rc1):
> > CC [M] drivers/scsi/aacraid/linit.o
> > CC [M] drivers/scsi/aacraid/aachba.o
> > CC [M] drivers/scsi/aacraid/commctrl.o
> > CC [M] drivers/scsi/aacraid/comminit.o
> > CC [M] drivers/scsi/aacraid/commsup.o
> > CC [M] drivers/scsi/aacraid/dpcsup.o
> > CC [M] drivers/scsi/aacraid/rx.o
> > CC [M] drivers/scsi/aacraid/sa.o
> > drivers/scsi/aacraid/sa.c: In function 'aac_sa_init':
> > drivers/scsi/aacraid/sa.c:375: error: 'struct adapter_ops'
> has no member
> > named 'adapter_restart'
>
> Mark, this patch is apparently against a slightly newer kernel which
> includes 8418852d11f0bbaeebeedd4243560d8fdc85410d:
> [SCSI] aacraid: add restart adapter platform function
>
> See any issue with this against 2.6.21.4 (simply drops adapter_restart
> bits).
>
> thanks,
> -chris
> --
>
> From: Salyzyn, Mark <[EMAIL PROTECTED]>
> Subject: SCSI: aacraid: Correct sa platform support. (Was:
> [Bug 8469] Bad EIP value on pentium3 SMP kernel-2.6.21.1)
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8469
>
> As discussed in the bugzilla outlined below, we have an sa based
> (Mustang) RAID adapter on the system, a Dell PERC2/QC. Affected
> controllers are HP NetRAID, Adaptec AAC-364, Dell PERC2/QC or Adaptec
> 5400S. This problem coincides with the introduction of the
> adapter_comm
> and adapter_deliver platform functions (Message [PATCH 1/4] aacraid:
> rework communication support code, January 23 2007, which initially
> migrated to 2.6.21)
>
> The panic occurs with an uninitialized adapter_deliver
> platform function
> pointer. The enclosed patch, unmodified as tested by Rainer,
> solves the
> problem.
>
> Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
> Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> [chrisw: backport to 2.6.21.4]
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
>
> ---
> drivers/scsi/aacraid/aacraid.h |1 +
> drivers/scsi/aacraid/rx.c |2 +-
> drivers/scsi/aacraid/sa.c |3 ++-
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> --- linux-2.6.21.4.orig/drivers/scsi/aacraid/aacraid.h
> +++ linux-2.6.21.4/drivers/scsi/aacraid/aacraid.h
> @@ -1840,6 +1840,7 @@ struct aac_driver_ident* aac_get_driver_
> int aac_get_adapter_info(struct aac_dev* dev);
> int aac_send_shutdown(struct aac_dev *dev);
> int aac_probe_container(struct aac_dev *dev, int cid);
> +int aac_rx_deliver_producer(struct fib * fib);
> extern int numacb;
> extern int acbsize;
> extern char aac_driver_version[];
> --- linux-2.6.21.4.orig/drivers/scsi/aacraid/rx.c
> +++ linux-2.6.21.4/drivers/scsi/aacraid/rx.c
> @@ -378,7 +378,7 @@ static int aac_rx_check_health(struct aa
> *
> * Will send a fib, returning 0 if successful.
> */
> -static int aac_rx_deliver_producer(struct fib * fib)
> +int aac_rx_deliver_producer(struct fib * fib)
> {
> struct aac_dev *dev = fib->dev;
> struct aac_queue *q = &dev->queues->queue[AdapNormCmdQueue];
> --- linux-2.6.21.4.orig/drivers/scsi/aacraid/sa.c
> +++ linux-2.6.21.4/drivers/scsi/aacraid/sa.c
> @@ -5,7 +5,7 @@
> * based on the old aacraid driver that is..
> * Adaptec aacraid device driver for Linux.
> *
> - * Copyright (c) 2000 Adaptec, Inc. ([EMAIL PROTECTED])
> + * Copyright (c) 2000-2007 Adaptec, Inc. ([EMAIL PROTECTED])
> *
> * 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
> @@ -368,6 +368,7 @@ int aac_sa_init(struct aac_dev *dev)
> dev->a_ops.adapter_sync_cmd = sa_sync_cmd;
> dev->a_ops.adapter_check_health = aac_sa_check_health;
> dev->a_ops.adapter_intr = aac_sa_intr;
> + dev->a_ops.adapter_deliver = aac_rx_deliver_producer;
> dev->a_ops.adapter_ioremap = aac_sa_ioremap;
>
> /*
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [stable] [patch 37/54] SCSI: aacraid: Correct saplatformsupport. (Was: [Bug 8469] Bad EIP value on pentium3SMPkernel-2.6.21.1)
Drop the setting of restart, drop the dummy restart handler in sa.c. I will send you what I mean later when I have time ... Sincerely -- Mark Salyzyn > -Original Message- > From: Chris Wright [mailto:[EMAIL PROTECTED] > Sent: Friday, June 08, 2007 2:29 PM > To: Salyzyn, Mark > Cc: Chris Wright; Stefan Lippers-Hollmann; James Bottomley; > AACRAID; Greg Kroah-Hartman; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: Re: [stable] [patch 37/54] SCSI: aacraid: Correct > saplatformsupport. (Was: [Bug 8469] Bad EIP value on > pentium3SMPkernel-2.6.21.1) > > > * Salyzyn, Mark ([EMAIL PROTECTED]) wrote: > > Yes, split the patch into the two pieces for 2.6.21.1/2.6.21.4 > > Sorry, didn't parse. Are you suggesting to use the patch I included > (which simply drops the ->adapter_restart init), or the original patch > plus Mark Havercamp's patch to add ->adapter_restart? > > thanks, > -chris > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [stable] [patch 37/54] SCSI: aacraid: Correctsaplatformsupport. (Was: [Bug 8469] Bad EIP value onpentium3SMPkernel-2.6.21.1)
Poifect (for earlier kernels without the restart adapter function added)
Sincerely -- Mark Salyzyn
> -Original Message-
> From: Chris Wright [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 08, 2007 2:41 PM
> To: Salyzyn, Mark
> Cc: Chris Wright; Stefan Lippers-Hollmann; James Bottomley;
> AACRAID; Greg Kroah-Hartman; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [stable] [patch 37/54] SCSI: aacraid:
> Correctsaplatformsupport. (Was: [Bug 8469] Bad EIP value
> onpentium3SMPkernel-2.6.21.1)
>
>
> * Salyzyn, Mark ([EMAIL PROTECTED]) wrote:
> > Drop the setting of restart, drop the dummy restart handler in sa.c.
>
> Yup, OK. That's exactly the updated patch I included. Here
> it is again:
>
> From: Salyzyn, Mark <[EMAIL PROTECTED]>
> Subject: SCSI: aacraid: Correct sa platform support. (Was:
> [Bug 8469] Bad EIP value on pentium3 SMP kernel-2.6.21.1)
>
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8469
>
> As discussed in the bugzilla outlined below, we have an sa based
> (Mustang) RAID adapter on the system, a Dell PERC2/QC. Affected
> controllers are HP NetRAID, Adaptec AAC-364, Dell PERC2/QC or Adaptec
> 5400S. This problem coincides with the introduction of the
> adapter_comm
> and adapter_deliver platform functions (Message [PATCH 1/4] aacraid:
> rework communication support code, January 23 2007, which initially
> migrated to 2.6.21)
>
> The panic occurs with an uninitialized adapter_deliver
> platform function
> pointer. The enclosed patch, unmodified as tested by Rainer,
> solves the
> problem.
>
> Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
> Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> [chrisw: backport to 2.6.21.4]
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
>
> ---
> drivers/scsi/aacraid/aacraid.h |1 +
> drivers/scsi/aacraid/rx.c |2 +-
> drivers/scsi/aacraid/sa.c |3 ++-
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> --- linux-2.6.21.4.orig/drivers/scsi/aacraid/aacraid.h
> +++ linux-2.6.21.4/drivers/scsi/aacraid/aacraid.h
> @@ -1840,6 +1840,7 @@ struct aac_driver_ident* aac_get_driver_
> int aac_get_adapter_info(struct aac_dev* dev);
> int aac_send_shutdown(struct aac_dev *dev);
> int aac_probe_container(struct aac_dev *dev, int cid);
> +int aac_rx_deliver_producer(struct fib * fib);
> extern int numacb;
> extern int acbsize;
> extern char aac_driver_version[];
> --- linux-2.6.21.4.orig/drivers/scsi/aacraid/rx.c
> +++ linux-2.6.21.4/drivers/scsi/aacraid/rx.c
> @@ -378,7 +378,7 @@ static int aac_rx_check_health(struct aa
> *
> * Will send a fib, returning 0 if successful.
> */
> -static int aac_rx_deliver_producer(struct fib * fib)
> +int aac_rx_deliver_producer(struct fib * fib)
> {
> struct aac_dev *dev = fib->dev;
> struct aac_queue *q = &dev->queues->queue[AdapNormCmdQueue];
> --- linux-2.6.21.4.orig/drivers/scsi/aacraid/sa.c
> +++ linux-2.6.21.4/drivers/scsi/aacraid/sa.c
> @@ -5,7 +5,7 @@
> * based on the old aacraid driver that is..
> * Adaptec aacraid device driver for Linux.
> *
> - * Copyright (c) 2000 Adaptec, Inc. ([EMAIL PROTECTED])
> + * Copyright (c) 2000-2007 Adaptec, Inc. ([EMAIL PROTECTED])
> *
> * 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
> @@ -368,6 +368,7 @@ int aac_sa_init(struct aac_dev *dev)
> dev->a_ops.adapter_sync_cmd = sa_sync_cmd;
> dev->a_ops.adapter_check_health = aac_sa_check_health;
> dev->a_ops.adapter_intr = aac_sa_intr;
> + dev->a_ops.adapter_deliver = aac_rx_deliver_producer;
> dev->a_ops.adapter_ioremap = aac_sa_ioremap;
>
> /*
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [scsi] Remove __GFP_DMA
The 31 bit limit for some of these cards is a problem, we currently only do __GFP_DMA for bounce buffer sg elements allocated for user supplied references in ioctls. I figure we should be using pci_alloc_consistent calls for these allocations to more accurately acquire memory within the 31 bit limit if necessary, we could switch to these to remove the need for the __GFP_DMA flag in the aacraid driver? -- Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Bottomley Sent: Wednesday, May 23, 2007 11:18 AM To: Aubrey Li Cc: Christoph Lameter; Bernhard Walle; [EMAIL PROTECTED]; Andrew Morton; linux-kernel@vger.kernel.org Subject: Re: [PATCH] [scsi] Remove __GFP_DMA On Wed, 2007-05-23 at 10:41 +0800, Aubrey Li wrote: > On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > > On Mon, 21 May 2007, Bernhard Walle wrote: > > > > > [PATCH] [scsi] Remove __GFP_DMA > > > > > > After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate a > > > DMA buffer any more in sd.c. > > > > > > Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> > > > > Great that avoids a DMA kmalloc slab. Any other GFP_DMAs left in the scsi > > layer? > > > > Acked-by: Christoph Lameter <[EMAIL PROTECTED]> > > Yes, here is another patch I'll defer to Mark on this one. However, please remember that you can't just blindly remove GFP_DMA ... there are some cards which require it. Aacraid is one example ... it has a set of cards that can only DMA to 31 bits. For them, the GFP_DMA is necessary: The allocation in question is a scatterlist, which must be within the device DMA mask. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [scsi] Remove __GFP_DMA
So, is the sequence:
p = kmalloc(upsg->sg[i].count,GFP_KERNEL);
. . .
addr = pci_map_single(dev->pdev, p, upsg->sg[i].count,
data_dir);
Going to ensure that we have a 31 bit (not 32 bit) physical address?
If not, then I reject this patch. We can not consider replacement with
pci_alloc_consistent until it works on AMD respecting the DMA masks.
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Aubrey Li
> Sent: Tuesday, May 22, 2007 10:41 PM
> To: Christoph Lameter
> Cc: Bernhard Walle; [EMAIL PROTECTED]; Andrew
> Morton; linux-kernel@vger.kernel.org; James Bottomley
> Subject: Re: [PATCH] [scsi] Remove __GFP_DMA
>
>
> On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > On Mon, 21 May 2007, Bernhard Walle wrote:
> >
> > > [PATCH] [scsi] Remove __GFP_DMA
> > >
> > > After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not
> necessary to alloate a
> > > DMA buffer any more in sd.c.
> > >
> > > Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
> >
> > Great that avoids a DMA kmalloc slab. Any other GFP_DMAs
> left in the scsi
> > layer?
> >
> > Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
>
> Yes, here is another patch
>
> Signed-off-by: Aubrey.Li <[EMAIL PROTECTED]>
> ---
> drivers/scsi/aacraid/commctrl.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/aacraid/commctrl.c
> b/drivers/scsi/aacraid/commctrl.c
> index 72b0393..405722d 100644
> --- a/drivers/scsi/aacraid/commctrl.c
> +++ b/drivers/scsi/aacraid/commctrl.c
> @@ -580,8 +580,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
> void __user * arg)
> for (i = 0; i < upsg->count; i++) {
> u64 addr;
> void* p;
> - /* Does this really need to be
> GFP_DMA? */
> - p =
> kmalloc(upsg->sg[i].count,GFP_KERNEL|__GFP_DMA);
> +
> + p =
> kmalloc(upsg->sg[i].count,GFP_KERNEL);
> if(p == 0) {
>
> dprintk((KERN_DEBUG"aacraid: Could not allocate SG buffer - size
> = %d buffer number %d of %d\n",
>
> upsg->sg[i].count,i,upsg->count));
> @@ -624,8 +624,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
> void __user * arg)
> for (i = 0; i < usg->count; i++) {
> u64 addr;
> void* p;
> - /* Does this really need to be
> GFP_DMA? */
> - p =
> kmalloc(usg->sg[i].count,GFP_KERNEL|__GFP_DMA);
> +
> + p =
> kmalloc(usg->sg[i].count,GFP_KERNEL);
> if(p == 0) {
> kfree (usg);
>
> dprintk((KERN_DEBUG"aacraid: Could not allocate SG buffer - size
> = %d buffer number %d of %d\n",
> @@ -666,8 +666,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
> void __user * arg)
> for (i = 0; i < upsg->count; i++) {
> u64 addr;
> void* p;
> - /* Does this really need to be
> GFP_DMA? */
> - p =
> kmalloc(usg->sg[i].count,GFP_KERNEL|__GFP_DMA);
> +
> + p =
> kmalloc(usg->sg[i].count,GFP_KERNEL);
> if(p == 0) {
>
> dprintk((KERN_DEBUG"aacraid: Could not allocate SG buffer - size
> = %d buffer number %d of %d\n",
>
> usg->sg[i].count,i,usg->count));
> --
> 1.5.1.1
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] aacraid: 2.6.21-rc6-mm1 aacraid not finding device
Thanks for the help from Steve Fox and Duane Cox investigating this issue, I'd like to report that we found the problem. The issue is with the patch Steve Fox isolated below, by not accommodating older adapters properly and issuing a command they do not support when retrieving storage parameters about the arrays. This simple patch resolves the problem (and more accurately mimics the logic of the original code before the patch). ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patches. This attached patch is against current scsi-misc-2.6 and can apply to 2.6.21-rc6-mm1. Please consider it for expedited inclusion. Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> --- Sincerely -- Mark Salyzyn > -Original Message- > From: Steve Fox [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 10, 2007 6:21 PM > To: Andrew Morton > Cc: [EMAIL PROTECTED]; Salyzyn, Mark; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: 2.6.21-rc6-mm1 aacraid not finding device > > > On Sun, 2007-04-08 at 14:35 -0700, Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6 /2.6.21-rc6-mm1/ Since 2.6.21-rc5-mm1, one of the test.kernel.org machines (elm3b239) has not been able to boot because it cannot find the SCSI device. You can view http://test.kernel.org/abat/82623/debug/console.log for the latest boot log (rc6-mm1). I tracked this down to the git-scsi-misc patch in the -mm tree and then bisected the scsi-misc git tree until I reached the commit below from Mark Salyzyn: fe76df4235986cfacc2d3b71cef7c42bc1a6dd6c [SCSI] aacraid: Fix blocking issue with container probing function (cast update) This is a pretty big patch, so hopefully Mark can take a look at it. lspci shows 01:02.0 RAID bus controller: Adaptec AAC-RAID (rev 02) 0f:02.0 SCSI storage controller: Adaptec AIC-9410W SAS (Razor ASIC non-RAID) (rev 08) 1d:02.0 SCSI storage controller: Adaptec AIC-9410W SAS (Razor ASIC non-RAID) (rev 08) 2b:02.0 SCSI storage controller: Adaptec AIC-9410W SAS (Razor ASIC non-RAID) (rev 08) on 2.6.21-rc6. Let me know if I can provide more details. -- Steve Fox IBM Linux Technology Center aacraid_logical_bugfix.patch Description: aacraid_logical_bugfix.patch
