Re: [patch 02/25] drivers/scsi/advansys.c: cleanups

2007-05-24 Thread Christoph Hellwig
On Wed, May 23, 2007 at 08:22:07PM -0500, James Bottomley wrote: On Wed, 2007-05-23 at 16:33 -0700, Andrew Morton wrote: On Wed, 23 May 2007 18:21:31 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2007-05-23 at 14:41 -0700, [EMAIL PROTECTED] wrote: From: Adrian Bunk [EMAIL

Re: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Alan Cox
That didn't used to work right on the AMD boards when I tried it last as we ended up with a buffer that was mapped by the IOMMU for some reason and that was not below 2GB. The physical address you mean? If that is still happening then it needs to get fixed. The allocation should not

Re: SMART support for SATA drives in SAS enclosures

2007-05-24 Thread Pim Zandbergen
Doug, /dev/sdc is indeed a physical SATA disk. sg_sat_identify says: ATA PASS-THROUGH (16) not supported I'll look into a firmware update. Thanks, Pim Douglas Gilbert wrote: Pim Zandbergen wrote: Is SMART support available for SATA drives in SAS enclosures? I'm testing this setup LSI

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

2007-05-24 Thread Andrew Vasquez
On Wed, 23 May 2007, [EMAIL PROTECTED] wrote: Subject: [patch 14/25] SCSI: use irq_handler_t where appropriate Message-Id: [EMAIL PROTECTED] From: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] ---

RE: [patch 16/25] drivers/scsi/ips.c: remove kernel 2.4 code

2007-05-24 Thread Salyzyn, Mark
Looks fine, totally inert. Inspected, could see no flaws. Disclaimer: Resisting application to Adaptec version of the sources since we still have to support legacy distributions, will keep synchronized none-the-less. Sincerely -- Mark Salyzyn -Original Message- From: [EMAIL PROTECTED]

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Salyzyn, Mark
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

RE: [patch 14/25] SCSI: use irq_handler_t where appropriate

2007-05-24 Thread Salyzyn, Mark
I ACK the portion that resides in aacraid.h, and will track and push it in the future if it does not stick ;- I will comment for any dpt_i2o, ips or aacraid patches posted to the SCSI list from submissions from folks not working at Adaptec once unit tested, accepted into the Adaptec upstreamed

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

2007-05-24 Thread James Bottomley
On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote: James Bottomley wrote: It's not a bug fix or even an enhancement. Historically, it is quite difficult to get maintainers to ack these ... particularly if you don't cc them. If neither you nor the maintainers are reading and

RE: [patch 14/25] SCSI: use irq_handler_t where appropriate

2007-05-24 Thread Salyzyn, Mark
Not being defensive. This is not just a maintainer's issue. We see the silent ACK treatment all the time from all avenues of inspection whether they be maintainers, illuminati, interested parties or JAFO. There is a little bit of a volunteer in every one of us. Requiring the maintainer to be

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread James Bottomley
On Thu, 2007-05-24 at 09:24 -0400, Salyzyn, Mark wrote: 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? No,

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

2007-05-24 Thread Randy Dunlap
On Thu, 24 May 2007 09:04:06 -0500 James Bottomley wrote: On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote: James Bottomley wrote: It's not a bug fix or even an enhancement. Historically, it is quite difficult to get maintainers to ack these ... particularly if you don't cc them.

RE: [patch 14/25] SCSI: use irq_handler_t where appropriate

2007-05-24 Thread James Bottomley
On Thu, 2007-05-24 at 10:28 -0400, Salyzyn, Mark wrote: This is not just a maintainer's issue. We see the silent ACK treatment all the time from all avenues of inspection whether they be maintainers, illuminati, interested parties or JAFO. There is a little bit of a volunteer in every one of

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

2007-05-24 Thread James Bottomley
On Thu, 2007-05-24 at 08:17 -0700, Randy Dunlap wrote: On Thu, 24 May 2007 09:04:06 -0500 James Bottomley wrote: On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote: James Bottomley wrote: It's not a bug fix or even an enhancement. Historically, it is quite difficult to get

Re: [PATCH 0/8] qla4xxx: Resubmission of patches to add IPv6 support etc

2007-05-24 Thread James Bottomley
On Wed, 2007-05-23 at 17:45 -0700, David C Somayajulu wrote: This series of patches is a resubmission of the previous patch under the title [RFC] [PATCH] qla4xxx: Updated add IPv6 and misc support bugfixes cleanup as set of smaller patches per Mike Christie's advice/feedback. They contain

Re: [PATCH v2] add bidi support for block pc requests

2007-05-24 Thread Boaz Harrosh
FUJITA Tomonori wrote: FUJITA Tomonori wrote: One thing that I found is: +#define scsi_resid(cmd) ((cmd)-sg_table-resid) This doesn't work for some drivers (at least ipr) since they set cmd-resid even with commands without data transfer. James, Tomo. the last accessor: +#define

Re: [PATCH v2] add bidi support for block pc requests

2007-05-24 Thread FUJITA Tomonori
From: Boaz Harrosh [EMAIL PROTECTED] Subject: Re: [PATCH v2] add bidi support for block pc requests Date: Thu, 24 May 2007 19:37:06 +0300 FUJITA Tomonori wrote: FUJITA Tomonori wrote: One thing that I found is: +#define scsi_resid(cmd) ((cmd)-sg_table-resid) This doesn't work

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Christoph Lameter
On Thu, 24 May 2007, Salyzyn, Mark wrote: 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? Only if you have less

Re: [PATCH v2] add bidi support for block pc requests

2007-05-24 Thread Boaz Harrosh
FUJITA Tomonori wrote: From: Boaz Harrosh [EMAIL PROTECTED] Subject: Re: [PATCH v2] add bidi support for block pc requests Date: Thu, 24 May 2007 19:37:06 +0300 FUJITA Tomonori wrote: FUJITA Tomonori wrote: One thing that I found is: +#define scsi_resid(cmd) ((cmd)-sg_table-resid)

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Christoph Lameter
On Thu, 24 May 2007, James Bottomley wrote: Going to ensure that we have a 31 bit (not 32 bit) physical address? No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was something I said I'd do ... about two years ago. Tell me more about these ideas. - To unsubscribe from

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread James Bottomley
On Thu, 2007-05-24 at 10:00 -0700, Christoph Lameter wrote: On Thu, 24 May 2007, James Bottomley wrote: Going to ensure that we have a 31 bit (not 32 bit) physical address? No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was something I said I'd do ... about two

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Christoph Lameter
On Thu, 24 May 2007, James Bottomley wrote: The idea was basically to match an allocation to a device mask. I was going to do a generic implementation (which would probably kmalloc, check the physaddr and fall back to GFP_DMA if we were unlucky) but allow the architectures to override.

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread James Bottomley
On Thu, 2007-05-24 at 10:22 -0700, Christoph Lameter wrote: On Thu, 24 May 2007, James Bottomley wrote: The idea was basically to match an allocation to a device mask. I was going to do a generic implementation (which would probably kmalloc, check the physaddr and fall back to GFP_DMA if

Re: [Stgt-devel] Question for pass-through target design

2007-05-24 Thread Robert Jennings
* Vladislav Bolkhovitin ([EMAIL PROTECTED]) wrote: Robert Jennings wrote: What I meant that is that the kernel tgt code (scsi_tgt*) receives SCSI commands from one lld and send them to another lld instead of sending them to user space. Although the approach of passing SCSI commands from a

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

2007-05-24 Thread Jeff Garzik
James Bottomley wrote: SCSI is a slightly different subsystem from almost any other in the kernel. It has something like 15 active driver maintainers plus at least another 15-25 periodically active ones. Most (but not all) driver maintainers are employed by the company who produces the

Re: [AIC7xxx] tree things to report

2007-05-24 Thread Emmanuel Fusté
Hello, While trying to obtain scsi log to debug a driver problem, I tried to use netconsole on an old smp system with a 10Mbits pcnet32 ethernet device. But few seconds after enabling netconsole, before launching my scsi test, but after a few console activity the computer freeze hard. Is it a know

[PATCH] [REPOST] fc_transport: fix sysfs deadlock on vport delete

2007-05-24 Thread James Smart
Repost, patch cut against latest scsi-misc-2.6 When the vport attribute delete is used to delete the vport, sysfs deadlocks waiting for the write to complete, which is waiting for the sysfs teardown to complete. Moved this effort to a work_q element. Took the opportunity to make some other

Re: [patch 0/7] Asynchronous Notification for ATAPI devices (resend)

2007-05-24 Thread Jeff Garzik
Kristen Carlson Accardi wrote: Hi Jeff, Here are the AN patches again, they have not changed with the exception of patch #1, which does set the host flag in board_ahci and board_ahci_pi now (thanks Tejun). This patch series implements Asynchronous Notification (AN) for SATA ATAPI devices as

Re: [patch 1/7] libata: check for AN support

2007-05-24 Thread Jeff Garzik
Kristen Carlson Accardi wrote: Check to see if an ATAPI device supports Asynchronous Notification. If so, enable it. Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED] --- Andrew, I cleaned up the function header to properly comply with kernel doc requirements. Other than that, this