On Thu, Nov 23, 2006 at 10:12:17PM -0700, Grant Grundler wrote:
> On Fri, Nov 24, 2006 at 09:38:00AM +0900, Hidetoshi Seto wrote:
> > Grant Grundler wrote:
> > >Hidetoshi,
> > >I have a nearly finished rewrite of Documentation/pci.txt.
> > >Can you drop this patch for now on my promise to integrate
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 5 Dec 2006 21:00:20 -0800 (PST) Luben Tuikov <[EMAIL PROTECTED]>
> > wrote:
> > --- Michael Reed <[EMAIL PROTECTED]> wrote:
> > > Luben Tuikov wrote:
> > > ...snip...
> > > > This statement in scsi_io_completion() causes the infinite retry l
> On Tue, 5 Dec 2006 21:00:20 -0800 (PST) Luben Tuikov <[EMAIL PROTECTED]>
> wrote:
> --- Michael Reed <[EMAIL PROTECTED]> wrote:
> > Luben Tuikov wrote:
> > ...snip...
> > > This statement in scsi_io_completion() causes the infinite retry loop:
> > >if (scsi_end_request(cmd, 1, good_bytes, !!
--- Michael Reed <[EMAIL PROTECTED]> wrote:
> Luben Tuikov wrote:
> ...snip...
> > This statement in scsi_io_completion() causes the infinite retry loop:
> >if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
> > return;
>
> The code in 2.6.19 is "result==0", not "!!result", w
On Mon, Dec 04, 2006 at 09:17:16PM -0500, Dominik Brodowski wrote:
> From: Dominik Brodowski <[EMAIL PROTECTED]>
> Date: Wed, 25 Oct 2006 21:49:27 -0400
> Subject: [PATCH] pcmcia: conf.ConfigBase and conf.Present consolidation
>
> struct pcmcia_device *p_dev->conf.ConfigBase and .Present are set i
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-12-05 at 23:46 +0100, Joerg Schilling wrote:
> > I am afraid, you seem to missunderstand things.
> >
> > This parameter is not related to something you may call "block layer", it
> > is
> > rather related to the low level SCSI transport.
Douglas Gilbert <[EMAIL PROTECTED]> wrote:
> BTW Joerg: SG_SET_RESERVED_SIZE simply makes it extremely
> unlikely that the sg driver will not be able to fetch
> enough memory from the kernel to move data associated with
> a SCSI command. The block layer SG_IO just fudges that.
> While a major conc
Alan Stern <[EMAIL PROTECTED]> wrote:
> I decided to do this by email instead of bugzilla so that it would be
> visible to everyone on the linux-scsi mailing list.
>
> Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
I just put out preliminary support for this ioctl.
Please check:
ftp://ftp
On Tue, 2006-12-05 at 23:46 +0100, Joerg Schilling wrote:
> I am afraid, you seem to missunderstand things.
>
> This parameter is not related to something you may call "block layer", it is
> rather related to the low level SCSI transport. If the value is stored in a
> higher layer, it is not sto
James Bottomley <[EMAIL PROTECTED]> wrote:
> > Is the patch below acceptable?
>
> Really, no. The parameter you're fishing for is a block parameter, not
> a SCSI parameter ... it should really be a block ioctl if we have to
> have an ioctl at all.
I am afraid, you seem to missunderstand things.
On Thursday 09 November 2006 16:59, Wesley J. Landaker wrote:
> On Thursday 09 November 2006 16:40, Matthew Wilcox wrote:
> > On Fri, Nov 10, 2006 at 08:37:23AM +0900, Tejun Heo wrote:
> > > >00:10.0 Mass storage controller [0180]: Silicon Image, Inc. Unknown
> > > > device [1095:2502] (rev 01)
> >
This is quite a mixed bag. The usual driver updates, plus asynchronous
scanning and the new target infrastructure.
The patch is available here:
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
the shortlog is:
Adrian Bunk:
ipr: Make ipr_ioctl static
megaraid_sas
Alan Stern <[EMAIL PROTECTED]> wrote:
> I decided to do this by email instead of bugzilla so that it would be
> visible to everyone on the linux-scsi mailing list.
Thank you, this is a more convenient way of having a discussion.
> Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
>
> To recap
Alan Stern wrote:
I decided to do this by email instead of bugzilla so that it would be
visible to everyone on the linux-scsi mailing list.
Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
To recap: Joerg Schilling needs to be able to retrieve the max_sectors
value for a SCSI device's requ
On Tue, 2006-12-05 at 15:52 -0500, Alan Stern wrote:
> I decided to do this by email instead of bugzilla so that it would be
> visible to everyone on the linux-scsi mailing list.
>
> Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
>
> To recap: Joerg Schilling needs to be able to retrieve th
I decided to do this by email instead of bugzilla so that it would be
visible to everyone on the linux-scsi mailing list.
Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
To recap: Joerg Schilling needs to be able to retrieve the max_sectors
value for a SCSI device's request queue. Doing it
James Bottomley wrote:
> Rather than introduce an extra flag, I think we can key of the protocol
> flag: libata is the only thing that initiates STP tasks. How does this
> look?
ACK.
--D
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL
Luben Tuikov wrote:
...snip...
> This statement in scsi_io_completion() causes the infinite retry loop:
>if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
> return;
The code in 2.6.19 is "result==0", not "!!result", which is logically
the same as "result!=0". Did you mean
Simple patch to add the new PCIe version of the 29320 card.
Signed-off: Mark Salyzyn <[EMAIL PROTECTED]>
ASC-29320LPE.patch
Description: ASC-29320LPE.patch
On Fri, 2006-11-10 at 16:59 -0800, Darrick J. Wong wrote:
> It turns out that libata has already dma_map_sg'd the scatterlist
> entries that go with an ata_queued_cmd by the time it calls
> sas_ata_qc_issue. sas_ata_qc_issue passes this scatterlist to aic94xx.
> Unfortunately, aic94xx assumes tha
From: Dominik Brodowski <[EMAIL PROTECTED]>
Date: Wed, 25 Oct 2006 21:49:27 -0400
Subject: [PATCH] pcmcia: conf.ConfigBase and conf.Present consolidation
struct pcmcia_device *p_dev->conf.ConfigBase and .Present are set in almost
all PCMICA driver right at the beginning, using the same calls but s
From: Dominik Brodowski <[EMAIL PROTECTED]>
Date: Wed, 25 Oct 2006 21:28:53 -0400
Subject: [PATCH] pcmcia: remove manf_id and card_id indirection
As we read out the manufactor and card_id from the PCMCIA device in the
PCMCIA core, and device drivers can access those reliably in struct
pcmcia_devic
On Tue, Dec 05 2006, Boaz Harrosh wrote:
> While working on bidi support at struct request level
> I have found that blk_queue_activity_fn is actually never used.
> The only user is in ide-probe.c with this code:
>
> /* enable led activity for disk drives only */
> if (drive->media ==
While working on bidi support at struct request level
I have found that blk_queue_activity_fn is actually never used.
The only user is in ide-probe.c with this code:
/* enable led activity for disk drives only */
if (drive->media == ide_disk && hwif->led_act)
blk_qu
24 matches
Mail list logo
