Am Mittwoch, 9. Januar 2008 21:36:20 schrieb Alan Stern:
> On Wed, 9 Jan 2008, Oliver Neukum wrote:
>
> > Am Mittwoch, 9. Januar 2008 18:22:51 schrieb Alan Stern:
> > > On Wed, 9 Jan 2008, Oliver Neukum wrote:
> > >
> > > > This has an interesting implication. As the storage driver can share
> >
On Wed, Jan 09, 2008 at 02:39:23PM +0800, Dave Young wrote:
> On Jan 9, 2008 2:37 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> >
> > On Jan 9, 2008 2:13 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
> > > > On Jan 9, 2008 6:48 AM, G
- Original Message -
*From:* Hans de Goede <[EMAIL PROTECTED]>
*To:* USB Storage list <[EMAIL PROTECTED]>
*CC:* [EMAIL PROTECTED], USB development list
<[EMAIL PROTECTED]>, David Brown
<[EMAIL PROTECTED]>, Guillaume Bedot <[EMAIL PROTECTED]>,
linux-scsi@vger.kernel.org, [EMAIL PROTECTED]
*S
Boaz Harrosh wrote:
- Original Message -
*From:* Hans de Goede <[EMAIL PROTECTED]>
*To:* USB Storage list <[EMAIL PROTECTED]>
*CC:* [EMAIL PROTECTED], USB development list
<[EMAIL PROTECTED]>, David Brown
<[EMAIL PROTECTED]>, Guillaume Bedot <[EMAIL PROTECTED]>,
linux-scsi@vger.kernel.org
On Thu, Jan 10 2008 at 12:52 +0200, Hans de Goede <[EMAIL PROTECTED]> wrote:
> Boaz Harrosh wrote:
>> - Original Message -
>> *From:* Hans de Goede <[EMAIL PROTECTED]>
>> *To:* USB Storage list <[EMAIL PROTECTED]>
>> *CC:* [EMAIL PROTECTED], USB development list
>> <[EMAIL PROTECTED]>, Davi
CC'ed linux-scsi and James,
On Thu, 10 Jan 2008 08:51:50 +
Nick Warne <[EMAIL PROTECTED]> wrote:
>
> Hi everybody - Happy New Year to you all!
>
> OK, updated to git rc7 yesterday - I now see this in syslog:
>
>"Driver 'sd' needs updating - please use bus_type methods"
>
> The warning
Dave Young wrote:
> This is the first one of the series about driver core changes.
Please always provide kerneldoc comments when you add new API elements;
here: exported functions.
It's unfortunate that the driver core's API isn't fully documented yet,
and you shouldn't make it worse.
That's onl
Hi,
could you explain to me why this code can get away with allocating the
sense buffer on the stack?
static int sg_io(struct file *file, struct request_queue *q,
struct gendisk *bd_disk, struct sg_io_hdr *hdr)
{
unsigned long start_time;
int writing = 0, ret = 0,
On Thu, Jan 10 2008 at 14:33 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Hi,
>
> could you explain to me why this code can get away with allocating the
> sense buffer on the stack?
>
> static int sg_io(struct file *file, struct request_queue *q,
> struct gendisk *bd_disk, stru
On Thu, Jan 10 2008, Boaz Harrosh wrote:
> On Thu, Jan 10 2008 at 14:33 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > could you explain to me why this code can get away with allocating the
> > sense buffer on the stack?
> >
> > static int sg_io(struct file *file, struct request_
Am Donnerstag, 10. Januar 2008 14:05:25 schrieb Boaz Harrosh:
> On Thu, Jan 10 2008 at 14:33 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > could you explain to me why this code can get away with allocating the
> > sense buffer on the stack?
> >
> > static int sg_io(struct file *
On Thu, Jan 10 2008, Oliver Neukum wrote:
> Am Donnerstag, 10. Januar 2008 14:05:25 schrieb Boaz Harrosh:
> > On Thu, Jan 10 2008 at 14:33 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > could you explain to me why this code can get away with allocating the
> > > sense buffer
On Thu, 10 Jan 2008 17:48:43 +0800,
Dave Young <[EMAIL PROTECTED]> wrote:
Please add a kerneldoc comment for each of the new interfaces.
> +int class_for_each_device(struct class *class, void *data,
> +int (*fn)(struct device *, void *))
> +{
> + struct device *dev;
>
On Thu, Jan 10 2008 at 15:06 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10 2008, Boaz Harrosh wrote:
>> On Thu, Jan 10 2008 at 14:33 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> could you explain to me why this code can get away with allocating the
>>> sense buffe
On Thu, Jan 10, 2008 at 02:19:08PM +0100, Oliver Neukum wrote:
> Am Donnerstag, 10. Januar 2008 14:05:25 schrieb Boaz Harrosh:
> > On Thu, Jan 10 2008 at 14:33 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > could you explain to me why this code can get away with allocating t
Subject: [PATCH] scsi: upstream arcmsr-1.20.00.15-71224
From: Nick Cheng <[EMAIL PROTECTED]>
Description:
*** add arcmsr_enable_eoi_mode()and readl(reg->iop2drv_doorbell_reg) in
arcmsr_handle_hbb_isr() on adapter Type B in case of the doorbell interrupt
clearance is cached
*** add conditional decla
Subject: [PATCH] scsi: upstream arcmsr-1.20.00.15-71224
From: Nick Cheng <[EMAIL PROTECTED]>
Description:
*** add arcmsr_enable_eoi_mode()and readl(reg->iop2drv_doorbell_reg) in
arcmsr_handle_hbb_isr() on adapter Type B in case of the doorbell interrupt
clearance is cached
*** add conditional decla
I ran into this under RHEL4 and it turned out to be udev and the capi20
declaration. I commented the declaration out in 50-udev.rules (as well
as the capi/%n) and started seeing my sd node appear (i.e. device 68:0).
--
Bob
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED
On Wed, Jan 09, 2008 at 09:55:15PM +0100, Oliver Neukum wrote:
> Hello,
>
> is there a way to distinguish calls to sd_open() from mount() from
> calls to open() ?
No. And there's no way to tell opening external log from either. Or
from swapon. Why the hell would the driver care?
-
To unsubscri
The capi bug is fixed in RHEL 4.6.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ellison, Bob
Sent: Thursday, January 10, 2008 9:19 AM
To: Vinay Venkataraghavan; Andrew Vasquez
Cc: James Bottomley; linux-scsi@vger.kernel.org; Matthew Wilcox
Subject: RE:
On Thu, 10 Jan 2008, Dave Young wrote:
> Hi,
> The patches are done on my side, please help to check.
>
> This is the first one of the series about driver core changes.
> If this one is accepted and there's no other problem I will post the others
> for maintainer's review (they need your comme
This one's a fatal bug in the qla1280 32 bit descriptor handling, since
the unitialised req_cnt variable is used to count the number of
descriptor slots. It turns out that qla1280 only uses 32 bit
descriptors on x86 if HIGHMEM isn't enabled, which is why it's taken so
long to find someone with a c
On Thu, 2008-01-10 at 13:01 +1100, Rusty Russell wrote:
> On Thursday 10 January 2008 09:10:37 James Bottomley wrote:
> > On Tue, 2008-01-08 at 11:39 +1100, Rusty Russell wrote:
> > > On Tuesday 08 January 2008 02:48:23 James Bottomley wrote:
> > > > We're always open to new APIs (or more powerful
On Wed, 2008-01-02 at 20:12 +0900, Tejun Heo wrote:
> Misc ATAPI commands may try to transfer more bytes than requested.
> For PIO which is performed by libata HSM, this is worked around by
> draining extra bytes from __atapi_pio_bytes().
>
> This patch implements drain buffer to perform draining
This just updates the libata slave configure routine to take advantage
of the block layer drain buffers.
I suspect I should also be checking for AHCI as well as ATA_DEV_ATAPI,
but I couldn't see how to do that easily.
James
---
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
On Thu, 10 Jan 2008 20:38:45 +0900
FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> >"Driver 'sd' needs updating - please use bus_type methods"
> >
> > The warning never appeared in RC6, and all google reveals are other
> > peoples logs that are posted about other issues.
> >
> > Do I need to f
On Thu, 2008-01-10 at 20:38 +0900, FUJITA Tomonori wrote:
> CC'ed linux-scsi and James,
>
> On Thu, 10 Jan 2008 08:51:50 +
> Nick Warne <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi everybody - Happy New Year to you all!
> >
> > OK, updated to git rc7 yesterday - I now see this in syslog:
> >
>
[Resent with proper subject and to additional recipients]
This patch against linus-current is compile-tested on x86 and x86-64.
Please review
Andre
---
Change sg.c to use the unlocked_ioctl instead of the ioctl handler.
The patch moves the BKL into sg.c and is thus a first step to get
rid of the
On Thu, Jan 10, 2008 at 05:48:43PM +0800, Dave Young wrote:
> The patches are done on my side, please help to check.
Along with all of the other comments from people, I have a few.
> This is the first one of the series about driver core changes.
> If this one is accepted and there's no other pr
On Thu, 10 Jan 2008 12:27:22 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
> > > OK, updated to git rc7 yesterday - I now see this in syslog:
>
>"Driver 'sd' needs updating - please use bus_type methods"
>
> > > Do I need to fix up something here?
> >
> > No, you don't. It's harmless, a s
On Thu, 2008-01-10 at 19:05 +0100, Andre Noll wrote:
> [Resent with proper subject and to additional recipients]
>
> This patch against linus-current is compile-tested on x86 and x86-64.
>
> Please review
This is rather long. For the utility of what you've just done, what's
wrong with just mak
On Thu, Jan 10, 2008 at 07:59:44PM +0100, Andi Kleen wrote:
> > Really, all this is doing is open coding what the ioctl handler is doing
> > anyway, isn't it? in which case, why bother to change it at all?
>
> Because once it's open coded it is visible and can then be eliminated.
> Does SCSI need
On Thu, 2008-01-10 at 19:59 +0100, Andi Kleen wrote:
> > Really, all this is doing is open coding what the ioctl handler is doing
> > anyway, isn't it? in which case, why bother to change it at all?
>
> Because once it's open coded it is visible and can then be eliminated.
> Does SCSI need the BK
On 19:59, Andi Kleen wrote:
> But perhaps for such a long ioctl handler it would be better to move
> the lock/unlock_kernel()s into the individual case ...: statements;
> then it could be eliminated step by step.
Sure, I can do that if James likes the idea. Since not all case
statements need the
On Thu, Jan 10, 2008 at 12:03:24PM -0700, Matthew Wilcox wrote:
> On Thu, Jan 10, 2008 at 07:59:44PM +0100, Andi Kleen wrote:
> > > Really, all this is doing is open coding what the ioctl handler is doing
> > > anyway, isn't it? in which case, why bother to change it at all?
> >
> > Because once i
On Thu, Jan 10, 2008 at 08:07:48PM +0100, Andre Noll wrote:
> On 19:59, Andi Kleen wrote:
>
> > But perhaps for such a long ioctl handler it would be better to move
> > the lock/unlock_kernel()s into the individual case ...: statements;
> > then it could be eliminated step by step.
>
> Sure, I ca
On Thu, Jan 10, 2008 at 01:03:48PM -0600, James Bottomley wrote:
>
> On Thu, 2008-01-10 at 19:59 +0100, Andi Kleen wrote:
> > > Really, all this is doing is open coding what the ioctl handler is doing
> > > anyway, isn't it? in which case, why bother to change it at all?
> >
> > Because once it's
> Really, all this is doing is open coding what the ioctl handler is doing
> anyway, isn't it? in which case, why bother to change it at all?
Because once it's open coded it is visible and can then be eliminated.
Does SCSI need the BKL at all?
But perhaps for such a long ioctl handler it would be
On Thu, Jan 10, 2008 at 08:32:27PM +0100, Andi Kleen wrote:
> Not many really in the core kernel. Hardly any. Grep for
> lock_kernel to be sure, but there is not much.
>
> It's mostly drivers that still need it.
>
> How about the low level SCSI drivers that might called from the high
> level SCS
> If your goal is to get rid of the BKL everywhere, sure. It's not clear
> to me this is the most productive way of spending our time though.
I believe eventually eliminating ->ioctl (as opposed to ->unlocked_ioctl)
would be a productive thing to do. Still having implicit BKL semantics in
such a
On 20:29, Andi Kleen wrote:
> > Sure, I can do that if James likes the idea. Since not all case
> > statements need the BKL, we could add it only to those for which it
> > isn't clear that it is unnecessary.
> >
> > And this would actually improve something.
>
> I still think it would be a good
On Thu, 2008-01-10 at 20:45 +0100, Andre Noll wrote:
> On 20:29, Andi Kleen wrote:
>
> > > Sure, I can do that if James likes the idea. Since not all case
> > > statements need the BKL, we could add it only to those for which it
> > > isn't clear that it is unnecessary.
> > >
> > > And this woul
On Thu, Jan 10 2008 at 21:45 +0200, Andre Noll <[EMAIL PROTECTED]> wrote:
> On 20:29, Andi Kleen wrote:
>
>>> Sure, I can do that if James likes the idea. Since not all case
>>> statements need the BKL, we could add it only to those for which it
>>> isn't clear that it is unnecessary.
>>>
>>> And
On 22:13, Boaz Harrosh wrote:
> All the scsi calls do not need any locks. The scsi LLDS never
> see these threads since commands are queued through the block
> layer.
That's what everybody believes, but nobody seems to know for sure.
Therefore I did what Andi suggested: Make a zero-semantics chan
On Thu, 2008-01-10 at 15:43 -0500, Pete Wyckoff wrote:
> [EMAIL PROTECTED] wrote on Wed, 09 Jan 2008 09:11 +0900:
> > On Tue, 8 Jan 2008 17:09:18 -0500
> > Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> > > I took another look at the compat approach, to see if it is feasible
> > > to keep the compat ha
[EMAIL PROTECTED] wrote on Wed, 09 Jan 2008 09:11 +0900:
> On Tue, 8 Jan 2008 17:09:18 -0500
> Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> > I took another look at the compat approach, to see if it is feasible
> > to keep the compat handling somewhere else, without the use of #ifdef
> > CONFIG_COMPAT
[EMAIL PROTECTED] wrote on Thu, 10 Jan 2008 14:55 -0600:
> On Thu, 2008-01-10 at 15:43 -0500, Pete Wyckoff wrote:
> > [EMAIL PROTECTED] wrote on Wed, 09 Jan 2008 09:11 +0900:
> > > On Tue, 8 Jan 2008 17:09:18 -0500
> > > Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> > > > I took another look at the com
On Thu, 2008-01-10 at 16:46 -0500, Pete Wyckoff wrote:
> [EMAIL PROTECTED] wrote on Thu, 10 Jan 2008 14:55 -0600:
> > On Thu, 2008-01-10 at 15:43 -0500, Pete Wyckoff wrote:
> > > [EMAIL PROTECTED] wrote on Wed, 09 Jan 2008 09:11 +0900:
> > > > On Tue, 8 Jan 2008 17:09:18 -0500
> > > > Pete Wyckoff
On Wed, 09 Jan 2008 17:51:43 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
> > diff -urp linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c
> > linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c
> > --- linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-12-23
> > 20:39:44.0 +0100
> > +++ linu
On Jan 10, 2008, at 3:46 PM, Pete Wyckoff wrote:
I'm fine with read/write, except Tomo is against handling iovecs
because of the compat complexity with struct iovec being different
on 32- vs 64-bit. There is a standard way to do "compat" ioctl that
hides this handling in a different file (not b
From: Randy Dunlap <[EMAIL PROTECTED]>
WARNING: vmlinux.o(.exit.text+0xc5b5): Section mismatch: reference to
.init.data:_asc_def_iop_base (between 'advansys_isa_remove' and
'advansys_eisa_remove')
_asc_def_iop_base is used in both init and exit code, so it cannot be
marked as __devinitdata.
Si
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatch: qla2x00_remove_one() should not be __devexit.
WARNING: vmlinux.o(.text+0xb014f5): Section mismatch: reference to .exit.text:
(between 'qla2xxx_pci_error_detected' and 'qla2xxx_pci_mmio_enabled')
Signed-off-by: Randy Dunlap <[EMAIL PR
From: Randy Dunlap <[EMAIL PROTECTED]>
Mark cciss_pci_init() as __devinit, to fix section mismatch warning.
WARNING: vmlinux.o(.text+0x601fc9): Section mismatch: reference to .init.text:
(between 'cciss_pci_init' and 'cciss_getgeometry')
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
driv
From: Randy Dunlap <[EMAIL PROTECTED]>
Change megaraid_pci_driver_g variable name so that it matches the modpost
whitelist that allows pointers to init text/data.
WARNING: vmlinux.o(.data+0x1a8e30): Section mismatch: reference to
.init.text:megaraid_probe_one (between 'megaraid_pci_driver_g' and
On Thu, 10 Jan 2008, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix section mismatch: qla2x00_remove_one() should not be __devexit.
>
> WARNING: vmlinux.o(.text+0xb014f5): Section mismatch: reference to
> .exit.text: (between 'qla2xxx_pci_error_detected' and
> 'qla2xxx_p
On Thu, 2008-01-10 at 23:31 +0100, Krzysztof Helt wrote:
> On Wed, 09 Jan 2008 17:51:43 -0600
> James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > > diff -urp linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c
> > > linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c
> > > --- linux-ref/drivers/scsi/sym53c8x
On Thu, 10 Jan 2008 14:33:16 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Change megaraid_pci_driver_g variable name so that it matches the modpost
> whitelist that allows pointers to init text/data.
>
> WARNING: vmlinux.o(.data+0x1a8e30): Section mi
On Jan 10, 2008 8:34 PM, Stefan Richter <[EMAIL PROTECTED]> wrote:
> Dave Young wrote:
> > This is the first one of the series about driver core changes.
>
> Please always provide kerneldoc comments when you add new API elements;
> here: exported functions.
>
> It's unfortunate that the driver core
On Jan 10, 2008 9:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jan 2008 17:48:43 +0800,
> Dave Young <[EMAIL PROTECTED]> wrote:
>
> Please add a kerneldoc comment for each of the new interfaces.
Will do.
>
> > +int class_for_each_device(struct class *class, void *data,
> > +
On Jan 10, 2008 11:41 PM, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jan 2008, Dave Young wrote:
>
> > Hi,
> > The patches are done on my side, please help to check.
> >
> > This is the first one of the series about driver core changes.
> > If this one is accepted and there's no other probl
Ack.
--Sumant
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 10, 2008 2:33 PM
To: DL-MegaRAID Linux; scsi
Cc: jejb; akpm; samr
Subject: [PATCH] megaraid: fix section mismatch
From: Randy Dunlap <[EMAIL PROTECTED]>
Change megaraid_pci_driver_g v
On Jan 11, 2008 2:39 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 05:48:43PM +0800, Dave Young wrote:
> > The patches are done on my side, please help to check.
>
> Along with all of the other comments from people, I have a few.
>
> > This is the first one of the series about dr
Got a weird error message (kernel dmesg output below). Is it likely
this type of error could be caused by a loose cable or connector?
Or is there something else at play here?
The card is a "Adaptec AHA-2940U2/U2W / 7890/7891" (talking to
the 1 SCSI disk, sda).
Earlier today, one of the scsi-bas
On Thu, 2008-01-10 at 16:10 -0800, Andrew Morton wrote:
> On Thu, 10 Jan 2008 14:33:16 -0800
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > Change megaraid_pci_driver_g variable name so that it matches the modpost
> > whitelist that allows pointers
James Bottomley wrote:
On Thu, 2008-01-10 at 16:10 -0800, Andrew Morton wrote:
On Thu, 10 Jan 2008 14:33:16 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:
From: Randy Dunlap <[EMAIL PROTECTED]>
Change megaraid_pci_driver_g variable name so that it matches the modpost
whitelist that allows poin
On Thu, 10 Jan 2008 22:45:35 -0600 James Bottomley <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-01-10 at 16:10 -0800, Andrew Morton wrote:
> > On Thu, 10 Jan 2008 14:33:16 -0800
> > Randy Dunlap <[EMAIL PROTECTED]> wrote:
> >
> > > From: Randy Dunlap <[EMAIL PROTECTED]>
> > >
> > > Change megaraid_
On Fri, 2008-01-04 at 02:18 +0200, Filippos Papadopoulos wrote:
> First of all let me wish a happy new year.
> I come back from the vacations and i compiled the initio driver with
>
> #define DEBUG_INTERRUPT 1
> #define DEBUG_QUEUE 1
> #define DEBUG_STATE 1
> #define INT_DISC1
>
On Thu, 2008-01-10 at 20:57 -0800, Andrew Morton wrote:
> On Thu, 10 Jan 2008 22:45:35 -0600 James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2008-01-10 at 16:10 -0800, Andrew Morton wrote:
> > > On Thu, 10 Jan 2008 14:33:16 -0800
> > > Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > >
> > >
On Thu, 10 Jan 2008 16:46:05 -0500
Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> Is there another async I/O mechanism? Userspace builds the CDBs,
> just needs some way to drop them in SCSI ML. BSG is almost perfect
> for this, but doesn't do iovec, leading to lots of memcpy.
syslets?
-
To unsubscri
This set of patches updates the lpfc driver to revision 8.2.4
All bug fixes are targeted for 2.6.25. Patches cut against scsi-misc-2.6
- Miscellaneous Discovery/ELS Fixes
- Correct Abort handler logic.
- Add parameters to enable and disable heartbeat and hba resets
- Miscellaneous Fixes
- Make lp
Miscellaneous Discovery/ELS Fixes:
- Delay free's of ELS requests if adapter reject conditions
- Fix concurrent PLOGI vs ADISC state handling
- Add retry mechanism for GFF_ID
- Correct some illegal state transitions around RSCN timeouts
- Fix missing return in FAN handling
Signed-off-by: James Sma
Correct Abort handler logic. It was unconditionally waiting a minimum
of 2 seconds rather than looking for abort completion.
Signed-off-by: James Smart <[EMAIL PROTECTED]>
diff -upNr a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
--- a/drivers/scsi/lpfc/lpfc_scsi.c 2007-11-0
Add parameters to enable and disable heartbeat and hba resets
Signed-off-by: James Smart <[EMAIL PROTECTED]>
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2007-11-09 15:54:47.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_attr.c
Miscellaneous Fixes:
- Fix a couple of sparse complaints
- Reset the FCP recovery flag when the node is not a FCP2 device.
- Speed up offline prep delays
- Fixed a memory leak in lpfc_mem_alloc failure path
- Fixed external loopback test.
- Fixed error code returned from the driver when HBA is ove
Fix Drivers Unsolicited CT command handling - we did not handle multiframe
sequences well.
Fix error due to delay in replenishing buffers for unsolicited data.
Signed-off-by: James Smart <[EMAIL PROTECTED]>
diff -upNr a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
--- a/drivers/s
Enhance debugfs to dump HBA SLIM as well as Host SLIM
Signed-off-by: James Smart <[EMAIL PROTECTED]>
diff -upNr a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
--- a/drivers/scsi/lpfc/lpfc_debugfs.c 2007-11-09 15:54:47.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
Rework misplaced reference taking on node structure
Signed-off-by: James Smart <[EMAIL PROTECTED]>
diff -upNr a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
--- a/drivers/scsi/lpfc/lpfc_ct.c 2008-01-11 01:25:48.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_ct.c 2008-01-
Update lpfc driver version to 8.2.4
Signed-off-by: James Smart <[EMAIL PROTECTED]>
diff -upNr a/drivers/scsi/lpfc/lpfc_version.h b/drivers/scsi/lpfc/lpfc_version.h
--- a/drivers/scsi/lpfc/lpfc_version.h 2007-11-09 15:54:48.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_version.h 2008-01-11 01:32
78 matches
Mail list logo
