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
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
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
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, 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
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, 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
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, 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
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->
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
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
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
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
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:
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 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
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
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 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
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
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
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
> 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
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:
> > >
>
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
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, 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
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
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
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
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
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
- 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
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
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
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
37 matches
Mail list logo
