On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <[EMAIL PROTECTED]> wrote:
> The real root cause of all of this is that there's no tree I can
> persuade all the interested parties to test that includes all of these
> features. In spite of the fact they've all been incubating in -mm for
> at le
On Mon, Aug 06 2007, FUJITA Tomonori wrote:
> On Tue, 31 Jul 2007 23:12:26 +0300
> Boaz Harrosh <[EMAIL PROTECTED]> wrote:
>
> > The tested Kernels:
> >
> > 1. Jens's sglist-arch
> > I was not able to pass all tests with this Kernel. For some reason when
> > bigger than 256 pages commands are
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Mon, 6 Aug 2007 17:24:58 -0600
> @@ -514,11 +514,14 @@ struct esp {
>
> struct completion *eh_reset;
>
> - struct sbus_dma *dma;
> + union {
> + struct sbus_dma *sbus_dma;
> + unsigned intx86
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/fc4/fc.c | 41 +++--
1 files changed, 15 insertions(+), 26 deletions(-)
diff --g
On Tue, 7 Aug 2007 08:55:49 +0200
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 06 2007, FUJITA Tomonori wrote:
> > On Tue, 31 Jul 2007 23:12:26 +0300
> > Boaz Harrosh <[EMAIL PROTECTED]> wrote:
> >
> > > The tested Kernels:
> > >
> > > 1. Jens's sglist-arch
> > > I was not able to pass
On Mon, 2007-08-06 at 16:19 +0200, Geert Uytterhoeven wrote:
> On Mon, 6 Aug 2007, James Bottomley wrote:
> > On Mon, 2007-08-06 at 15:38 +0200, Geert Uytterhoeven wrote:
> > > On Fri, 3 Aug 2007, Geoff Levand wrote:
> > > > Nicholas A. Bellinger wrote:
> > > > > Thank you for this information. I
Here's a record of driver initialization with debugging enabled. I can't
figure out what goes wrong, but maybe sombody else can...
Any help is appreciated
Fusion MPT base driver 3.04.04
Copyright (c) 1999-2007 LSI Logic Corporation
mptbase: Register for IOC reset notification
Fusion MPT SPI Host
Hommel, Thomas (GE Indust, GE Fanuc) wrote:
> Here's a record of driver initialization with debugging enabled. I can't
> figure out what goes wrong, but maybe sombody else can...
>
> Any help is appreciated
[...]
> mptbase: ioc0: WARNING - mpt_timer_expired complete!
> Unable to handle kernel pagi
In defense of my maintainer, who was working on my behalf! ...
The lpfc mods were the bulk of the +/- counts. We batch our bug fixes
together and then push to James as a large lump. Unfortunately, we had
a change that changed logging from a base object to a subobject. Although
not risky, it did
On Tue, 7 Aug 2007 00:14:29 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > The real root cause of all of this is that there's no tree I can
> > persuade all the interested parties to test that includes all of th
FUJITA Tomonori wrote:
On Tue, 7 Aug 2007 00:14:29 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <[EMAIL PROTECTED]> wrote:
The real root cause of all of this is that there's no tree I can
persuade all the interested parties to test that inc
On Tue, 2007-08-07 at 00:14 -0700, Andrew Morton wrote:
> On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > The real root cause of all of this is that there's no tree I can
> > persuade all the interested parties to test that includes all of these
> > features. I
On Mon, 2007-08-06 at 21:01 -0700, Linus Torvalds wrote:
>
> On Mon, 6 Aug 2007, James Bottomley wrote:
> >
> > Confused ... you did get the first pull request in the first week.
>
> Here's the problem. Let me repeat it again:
>
> > > And after -rc1, I don't want to see crap like this:
> > >
>
> I fully agree, and firmly believe that the current stabilisation works
> incredibly well for shaking out bugs. My problem is that it doesn't
> work for stabilising features. Either we have to get far more people
> doing feature integration testing before the merge window, or we have to
> accept
Alan Cox wrote:
I fully agree, and firmly believe that the current stabilisation works
incredibly well for shaking out bugs. My problem is that it doesn't
work for stabilising features. Either we have to get far more people
doing feature integration testing before the merge window, or we have t
James Bottomley wrote:
> One of the intents of the block prep function was to allow ULDs to use
> it for preprocessing. The original SCSI model was to have a single prep
> function and add a pointer indirect filter to build the necessary
> commands. This patch reverses that, does away with the in
James Bottomley wrote:
The initial bsg submit went via the block git tree ... which I believe
you have in -mm. We only started taking the updates via the scsi tree
Seven hours before you posted this, in
<[EMAIL PROTECTED]>, Andrew already
noted it was not in -mm.
A trivial examination of t
On 08/07/2007 05:55 AM, James Bottomley wrote:
I really, *really* think we need a pre-release tree that consists of all
the upstream targetted features (i.e. all of the for the next merge
window git trees) and nothing else. -mm doesn't really satisfy this,
because it has so much other stuff t
Andrew Morton wrote:
On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <[EMAIL PROTECTED]> wrote:
I really, *really* think we need a pre-release tree that consists of all
the upstream targetted features (i.e. all of the for the next merge
window git trees) and nothing else.
That *is* -mm. Th
On Tue, 2007-08-07 at 11:11 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > The initial bsg submit went via the block git tree ... which I believe
> > you have in -mm. We only started taking the updates via the scsi tree
>
> Seven hours before you posted this, in
> <[EMAIL PROTECTED]>, An
James Bottomley wrote:
It followed the rule of trying to stabilise outside mainline ... it just
didn't get sufficient integration testing.
IMO it's self-evident that pushing to a git tree few ever see or test is
not following the spirit of the rule.
In practice, stabilize outside mainline im
James Bottomley wrote:
OK ... that's arguable. This one is larger than I like because of the
lpfc bug fix patch ... I accept I need to do a better job getting these
into the merge window via the scsi-misc tree. So I will accept the "too
big" criticism and try to manage the driver maintainers be
James Smart wrote:
However, I take issue with looking at line counts as the sole basis
for what's appropriate or not. It can be argued that some bug fixes may be
larger in scope than others, or patch batching so that the bug fix count is
higher will skew this perception. I also believe that more
James Bottomley wrote:
I'm arguing that a too strict an interpretation of bugfix only post -rc1
will damage feature stabilisation. Please think carefully about this.
If we go out in a released kernel with a problematic user space ABI, we
end up being committed to it forever.
IMO you're going
Jeff Garzik wrote:
The lpfc update was probably the biggest thing, LOC-wise. And even
though that was mostly bug fixes -- and notably NOT 100% fixes -- it is
big enough to warrant integration testing and exposure prior to
mainline. Definitely merge-window-open material AFAICS.
FYI - it is i
On Tue, 2007-08-07 at 12:20 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > I'm arguing that a too strict an interpretation of bugfix only post -rc1
> > will damage feature stabilisation. Please think carefully about this.
> > If we go out in a released kernel with a problematic user space
James Smart wrote:
Jeff Garzik wrote:
The lpfc update was probably the biggest thing, LOC-wise. And even
though that was mostly bug fixes -- and notably NOT 100% fixes -- it
is big enough to warrant integration testing and exposure prior to
mainline. Definitely merge-window-open material AFA
Can somebody explain the reason for calling a separate
scsi_sysfs_add_devices() routine in the async scanning code instead of
just calling scsi_sysfs_add_sdev() normally from within scsi_add_lun()?
This peculiar delayed approach has introduced a bug. It evades the
protection provided by shost->
On Tue, 2007-08-07 at 12:54 -0400, Alan Stern wrote:
> Can somebody explain the reason for calling a separate
> scsi_sysfs_add_devices() routine in the async scanning code instead of
> just calling scsi_sysfs_add_sdev() normally from within scsi_add_lun()?
Matthew's away at the moment, so I'll s
FUJITA Tomonori wrote:
Allocating 64K contiguous memory is not good so the next thing to do
is converting sg to use the sg chaining support fully. Or it might be
For LLDs like aic7xxx, I think we are stuck with a small
scsi_host_template->sg_tablesize, so to continue to get large requests
lik
On Tue, 07 Aug 2007 10:21:18 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > On Tue, 7 Aug 2007 00:14:29 -0700
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> >> On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> The real ro
On Tue, 07 Aug 2007 10:38:44 -0500 James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-08-07 at 11:11 -0400, Jeff Garzik wrote:
> > James Bottomley wrote:
> > > The initial bsg submit went via the block git tree ... which I believe
> > > you have in -mm. We only started taking the updates v
On Tue, 7 Aug 2007, James Bottomley wrote:
> On Tue, 2007-08-07 at 12:54 -0400, Alan Stern wrote:
> > Can somebody explain the reason for calling a separate
> > scsi_sysfs_add_devices() routine in the async scanning code instead of
> > just calling scsi_sysfs_add_sdev() normally from within scsi
The default SCSI timeout is 30 seconds for a logical device. The aacraid
based controllers currently have a 35 second timeout for the array. We
are bumping up the default SCSI timeout for array devices, which
typically manage many physical disks, to 45 seconds to provide a small
margin to permit th
On Tue, 07 Aug 2007 12:13:41 -0500
Mike Christie <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > Allocating 64K contiguous memory is not good so the next thing to do
> > is converting sg to use the sg chaining support fully. Or it might be
>
> For LLDs like aic7xxx, I think we are stuck w
This patch fixes the following warning:
drivers/scsi/ips.c: In function 'ips_register_scsi':
drivers/scsi/ips.c:6867: warning: ignoring return value of
'scsi_add_host', declared with attribute warn_unused_result
Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
---
drivers/scsi/ips.c | 16
Hello,
alloc_fcdev() calls alloc_netdev() which uses kzalloc to alloc
all the memory together with dev->priv region hence no zeroing of structs
inside struct mpt_lan_priv needed.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/message/fusion/mptlan.c | 47738 -> 47618 (-120
37 matches
Mail list logo
