Re: [PATCH]: Final ESP driver rewrite

2007-04-27 Thread Jan Engelhardt
On Apr 27 2007 00:28, David Miller wrote: This is the patch I intend to send to Linus via my sparc-2.6 tree. Thanks to everyone for the review and testing! commit cd9ad58d4061494e7fdd70ded7bcf2418daf356a Author: David S. Miller [EMAIL PROTECTED] Date: Thu Apr 26 21:19:23 2007 -0700 Would

Re: [PATCH]: Final ESP driver rewrite

2007-04-27 Thread David Miller
From: Jan Engelhardt [EMAIL PROTECTED] Date: Fri, 27 Apr 2007 09:57:34 +0200 (MEST) On Apr 27 2007 00:28, David Miller wrote: This is the patch I intend to send to Linus via my sparc-2.6 tree. Thanks to everyone for the review and testing! commit

Re: [PATCH]: Final ESP driver rewrite

2007-04-27 Thread David Miller
From: Jan Engelhardt [EMAIL PROTECTED] Date: Fri, 27 Apr 2007 10:33:30 +0200 (MEST) Well the patch looks like it's done in one commit (rather than two - delete+add), but that's probably just because it's the diff over both commits. I didn't do it in multiple commits, I did it in one. If I do

Re: [PATCH]: Final ESP driver rewrite

2007-04-27 Thread Jan Engelhardt
On Apr 27 2007 01:24, David Miller wrote: On Apr 27 2007 00:28, David Miller wrote: This is the patch I intend to send to Linus via my sparc-2.6 tree. Thanks to everyone for the review and testing! commit cd9ad58d4061494e7fdd70ded7bcf2418daf356a Author: David S. Miller [EMAIL

RE: [PATCH] aacraid: Initialize rx/rkt function pointers before calling them

2007-04-27 Thread Salyzyn, Mark
Reject, this is already covered in aacraid_kexec_5.patch and again separately in aacraid_kexec_fix.patch. Sincerely -- Mark Salyzyn -Original Message- From: Darrick J. Wong [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 6:58 PM To: linux-scsi@vger.kernel.org Cc: Salyzyn,

RE: [PATCH] aacraid: Initialize rx/rkt function pointers before calling them

2007-04-27 Thread Salyzyn, Mark
Just wait a second ... We are not supposed to be calling aac_rx_restart_adapter unless the Adapter has it's interrupts enabled (from a previous driver load in the same warm session such as a kexec) or if the kernel reset_devices flag is set (which is a mandatory kernel flag during kdump or

[PATCH][REPOST] fc_transport: make all rports wait dev_loss_tmo before removing them

2007-04-27 Thread James Smart
Per the comment in the change - it's not always prudent to immediately remove the rport upon first notice of a disconnect. Make all rports wait dev_loss_tmo before being deleted (and each could have a separate dev_loss_tmo value). The original post was:

Re: [2.6 patch] drivers/scsi/nsp32.c: remove kernel 2.4 code

2007-04-27 Thread Robert P. J. Day
On Thu, 26 Apr 2007, James Bottomley wrote: Personally, I don't like to see 2.4 and 2.6 in a new driver, and will tend to try to force it to be 2.6 only. For an existing driver, I tend to be much more tolerant: removing the huge gobs of code to achieve 2.6 only is usually a bit disruptive on

Re: [2.6 patch] drivers/scsi/nsp32.c: remove kernel 2.4 code

2007-04-27 Thread Adrian Bunk
On Fri, Apr 27, 2007 at 10:55:54AM -0400, Robert P. J. Day wrote: On Thu, 26 Apr 2007, James Bottomley wrote: Personally, I don't like to see 2.4 and 2.6 in a new driver, and will tend to try to force it to be 2.6 only. For an existing driver, I tend to be much more tolerant: removing

[PATCH][REPOST] FC Transport support for vports based on NPIV

2007-04-27 Thread James Smart
The repost does not change anything. It simply updates the patch so it can be applied cleanly after the make all rports wait dev_loss_tmo patch which was just posted. -- This patch provides support for FC virtual ports based on NPIV. For information on the interfaces and design, please read

Re: [RFC PATCH]: Rewritten ESP driver, porters needed!

2007-04-27 Thread Christoph Hellwig
Sorry for the late reply. I'll stay in this thead despite the new version beeing posted to not lose the context. On Tue, Apr 24, 2007 at 01:44:40PM -0700, David Miller wrote: I did all of this, and it's fine, but there is one site which is much less pleasant, device reconnect. With the

Re: [PATCH] aacraid: Initialize rx/rkt function pointers before calling them

2007-04-27 Thread Darrick J. Wong
Salyzyn, Mark wrote: In my unit tests of aacraid_kexec_5.patch, restart was not called for normal operations. If you are just doing a normal boot, what conditions are causing restart to be called in your case? Is it a warm restart? Some kind of operation that leaves the Adapter in an

RE: [PATCH] aacraid: Initialize rx/rkt function pointers before calling them

2007-04-27 Thread Salyzyn, Mark
Maybe we should consider something like: 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

Re: [RFC PATCH]: Rewritten ESP driver, porters needed!

2007-04-27 Thread David Miller
From: Christoph Hellwig [EMAIL PROTECTED] Date: Fri, 27 Apr 2007 16:16:58 +0100 aic7xxx might not be the best driver to look at either :) In practice a softirq has short enough latency so this doesn't matter, but you should probably benchmark it on your hardware. 53x700.c which is the most

BAD_SG_DMA panic in aha1542

2007-04-27 Thread Bob Tracy
I previously reported an ISA DMA issue for the 2.6.12 kernel. The issue persists through at least 2.6.18. SCSI controller is an Adaptec AHA-1542B (ISA). The action mount -t iso9660 /dev/scd0 /mnt/cdrom -r produces (cdrom detection messages as various modules autoload, then...) sgpnt[0:1] page

Re: [PATCH] aacraid: Initialize rx/rkt function pointers before calling them

2007-04-27 Thread Darrick J. Wong
Salyzyn, Mark wrote: As an option for a patch (later), what was the actual value of the Munit.OIMR register (on the x3550 and the x3650 please, just in case)? 0xF. --D - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More

[PATCH] esp_scsi.c: fix compilation

2007-04-27 Thread Alexey Dobriyan
irqreturn.h for irqreturn_t and dma_addr_t being u128 warnings ;-) Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- drivers/scsi/esp_scsi.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) --- a/drivers/scsi/esp_scsi.c +++ b/drivers/scsi/esp_scsi.c @@ -13,6 +13,7 @@

Re: BAD_SG_DMA panic in aha1542

2007-04-27 Thread Alan Cox
As before, no problems using the sda hard disk (which is the boot drive): everything works reliably until I touch the cdrom drive. A little quiet contemplation and gnome number 387 suggests trying the following (and providing more detailed information such as the last message printed before the

Re: [PATCH] esp_scsi.c: fix compilation

2007-04-27 Thread David Miller
From: Alexey Dobriyan [EMAIL PROTECTED] Date: Sat, 28 Apr 2007 02:09:01 +0400 irqreturn.h for irqreturn_t and dma_addr_t being u128 warnings ;-) Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] I'll apply this, thanks. - To unsubscribe from this list: send the line unsubscribe linux-scsi in

Re: BAD_SG_DMA panic in aha1542

2007-04-27 Thread James Bottomley
On Fri, 2007-04-27 at 16:47 -0500, Bob Tracy wrote: I previously reported an ISA DMA issue for the 2.6.12 kernel. The issue persists through at least 2.6.18. SCSI controller is an Adaptec AHA-1542B (ISA). The action mount -t iso9660 /dev/scd0 /mnt/cdrom -r produces (cdrom detection

Re: BAD_SG_DMA panic in aha1542

2007-04-27 Thread Bob Tracy
James Bottomley wrote: On Fri, 2007-04-27 at 16:47 -0500, Bob Tracy wrote: I previously reported an ISA DMA issue for the 2.6.12 kernel. The issue persists through at least 2.6.18. SCSI controller is an Adaptec AHA-1542B (ISA). The action mount -t iso9660 /dev/scd0 /mnt/cdrom -r

Re: BAD_SG_DMA panic in aha1542

2007-04-27 Thread Bob Tracy
Alan Cox wrote: As before, no problems using the sda hard disk (which is the boot drive): everything works reliably until I touch the cdrom drive. A little quiet contemplation and gnome number 387 suggests trying the following (and providing more detailed information such as the last