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 pat
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 defi
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
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
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.
If neither you nor the maintainers are readi
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 board/ch
* 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
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
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.
H
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 ... abou
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
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)->s
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 ha
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)
> >
> >
Boaz Harrosh wrote:
> 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.
>>
>
> Jam
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
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
> con
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
> > > > difficul
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 o
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
> >
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?
N
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 cc'd
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 r
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 so
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 w
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
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]>
> ---
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
LS
> > 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
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: Adria
30 matches
Mail list logo