On Fri, 14 Dec 2007 18:05:56 -0500
"John Stoffel" <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Just fired up 2.6.24-rc5-mm1 on a Dual CPU PIII 550mhz system with 2gb
> of RAM. Got the following error. Let me know if you need more
> details or want me to run tests or make changes. Looks like somethi
On Fri, Dec 14, 2007 at 06:02:06PM -0800, Andrew Morton wrote:
> On Sat, 15 Dec 2007 01:09:41 + Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> > On (13/12/07 14:29), Andrew Morton didst pronounce:
> > > > The simple way seems to be to malloc a large area, touch every page and
> > > > then look at t
bsg SG_IO needs to return -EFAULT for the response field in struct
sg_io_v4.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
block/bsg.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/block/bsg.c b/block/bsg.c
index 8e181ab..7781e63 100644
--- a/block/bsg.c
++
Introduce queue_ accessors to set and clear queue_flags, which include debug
checks to ensure queue_lock is held. Non-checking versions are provided where
it is known that there can be no parallelism on queue_flags.
Index: linux-2.6/block/elevator.c
===
All queue_flag manipulations are performed under queue_lock (or eg. during
allocation-time where parallelism isn't a problem). So we can use non-atomic
bitops for these.
Index: linux-2.6/block/elevator.c
===
--- linux-2.6.orig/block/
Hi,
This is just an idea I had, which might make request processing a little
bit cheaper depending on queue behaviour. For example if it is getting plugged
unplugged frequently (as I think is the case for some database workloads),
then we might save one or two atomic operations per request.
Anywa
On Sat, 15 Dec 2007 01:09:41 + Mel Gorman <[EMAIL PROTECTED]> wrote:
> On (13/12/07 14:29), Andrew Morton didst pronounce:
> > > The simple way seems to be to malloc a large area, touch every page and
> > > then look at the physical pages assigned ... they now mostly seem to be
> > > descendin
On (13/12/07 14:29), Andrew Morton didst pronounce:
> > The simple way seems to be to malloc a large area, touch every page and
> > then look at the physical pages assigned ... they now mostly seem to be
> > descending in physical address.
> >
>
> OIC. -mm's /proc/pid/pagemap can be used to get
Hi,
Just fired up 2.6.24-rc5-mm1 on a Dual CPU PIII 550mhz system with 2gb
of RAM. Got the following error. Let me know if you need more
details or want me to run tests or make changes. Looks like something
in the SCSI st driver, which makes sense since I have a pair of DLT 7k
drives hooked up
Patch 3 of 3
This patch bumps the driver version to 3.6.18 to reflect support for the
P700m. This matches the HP released driver version for hardware support.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/Documentation/cciss.txt b/Documentation/c
Patch 2 of 3
This patch modifies our /proc entries to display information about only
the first logical volume on each controller. Primary reason is for hardware
that can support many LUNs (128 or more). In this case we can step on memory
and crash the system trying to display so much information.
Patch 1 of 3
Sorry to take so long to repost.
This patch exports more attributes to /sys so we can work work better with
udev. Some distros use unique_id among other attributes. This patch attempts
to provide that and other attributes to reveal more information about cciss
devices in /sys. It's a
On Fri, Dec 14, 2007 at 03:45:16PM -0500, Tony Battersby wrote:
> After this happens, the kernel disables the IRQ, causing the SCSI card
> to stop working until the next reboot. The problem is caused by the
> interrupt handler returning IRQ_NONE instead of IRQ_HANDLED after
> handling an interrupt
The patch described by the following excerpt from ChangeLog-2.6.24-rc1
eventually causes a "irq X: nobody cared" error after a while:
commit 99c9e0a1d6cfe1ba1169a7a81435ee85bc00e4a1
Author: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Fri Oct 5 15:55:12 2007 -0400
[SCSI] sym53c8xx: Make interru
On Fri, 14 Dec 2007 12:04:54 -0500 (EST), Kiyoshi Ueda <[EMAIL PROTECTED]>
wrote:
> I have investigated all code paths which call ub_end_rq() in ub.c,
> and confirmed that ub_end_rq() is always called with the queue lock
> held. (sc->lock is registered as a queue lock.)
Thanks for reminding me
Matthew Wilcox wrote:
On Fri, Dec 14, 2007 at 05:42:37PM +, Mel Gorman wrote:
Regrettably this interferes with anti-fragmentation because the "next" page
on the list on return from rmqueue_bulk is not guaranteed to be of the right
mobility type. I fixed it as an additional patch but it adds
On Fri, 14 Dec 2007, Andrew Morton wrote:
> > Could you drop this patch from your queue. I'll carry it in my tree
> > (along with additional code removals) for 2.6.25 submission.
> >
>
> I'll normally carry patches until they turn up in a subsystem tree or
> mainline and will drop them then. T
On Fri, Dec 14, 2007 at 05:42:37PM +, Mel Gorman wrote:
> Regrettably this interferes with anti-fragmentation because the "next" page
> on the list on return from rmqueue_bulk is not guaranteed to be of the right
> mobility type. I fixed it as an additional patch but it adds additional cost
> t
Mel Gorman wrote:
On (13/12/07 19:46), Mark Lord didst pronounce:
"Improved version", more similar to the 2.6.23 code:
Fix page allocator to give better chance of larger contiguous segments
(again).
Signed-off-by: Mark Lord <[EMAIL PROTECTED]
Regrettably this interferes with anti-fragmenta
On Fri, 14 Dec 2007 07:37:24 -0800 Andrew Vasquez <[EMAIL PROTECTED]> wrote:
> On Thu, 13 Dec 2007, [EMAIL PROTECTED] wrote:
>
> > From: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > - make the following needlessly global code static:
> > - qla_attr.c: qla24xx_vport_delete()
> > - qla_attr.c: qla2
On (13/12/07 19:46), Mark Lord didst pronounce:
>
> "Improved version", more similar to the 2.6.23 code:
>
> Fix page allocator to give better chance of larger contiguous segments
> (again).
>
> Signed-off-by: Mark Lord <[EMAIL PROTECTED]
Regrettably this interferes with anti-fragmentation bec
Hi Pete,
On Thu, 13 Dec 2007 13:59:16 -0800, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > > > - end_that_request_first(rq, uptodate, rq->hard_nr_sectors);
> > > > - end_that_request_last(rq, uptodate);
> > > > + if (__blk_end_request(rq, error, blk_rq_bytes(rq)))
> > > > +
On Thu, 13 Dec 2007, [EMAIL PROTECTED] wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
>
> - make the following needlessly global code static:
> - qla_attr.c: qla24xx_vport_delete()
> - qla_attr.c: qla24xx_vport_disable()
> - qla_mid.c: qla24xx_allocate_vp_id()
> - qla_mid.c: qla24xx_find_
On Friday 14 December 2007 15:35:01 James Bottomley wrote:
> > > This is some type of ioc internal error. What we do on DID_SOFT_ERROR
> > > is retry for the usual number of times up to the timeout limit.
> > > Unfortunately, the retries are fixed at SD_MAX_RETRIES in sd.c.
> > > Without diagnosi
On Fri, 2007-12-14 at 13:04 +0100, Bernd Schubert wrote:
> Hello James,
>
> On Thursday 13 December 2007 15:18:33 James Bottomley wrote:
> > On Wed, 2007-12-12 at 18:54 +0100, Bernd Schubert wrote:
> > > [Hmm, resending since mail after more than 30min still not on the ML,
> > > maybe the attachm
On Fri, 2007-12-14 at 10:00 +0100, Hannes Reinecke wrote:
> James Bottomley wrote:
> > On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> >> OK, thanks. I'll assume that James and Hannes have this in hand (or will
> >> have, by mid-week) and I won't do anything here.
> >
> > Just to confi
Mel Gorman wrote:
On (13/12/07 16:37), Andrew Morton didst pronounce:
On Thu, 13 Dec 2007 19:30:00 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
Here's the commit that causes the regression:
...
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone
On Friday 14 December 2007 13:22:55 Matthew Wilcox wrote:
> On Fri, Dec 14, 2007 at 01:04:12PM +0100, Bernd Schubert wrote:
> > PS: Do you have some links to scsi and SPI specs?
>
> The final versions are available for a fee from ANSI. However,
> you can download the final draft versions for free
On Fri, Dec 14, 2007 at 01:04:12PM +0100, Bernd Schubert wrote:
> PS: Do you have some links to scsi and SPI specs?
The final versions are available for a fee from ANSI. However,
you can download the final draft versions for free from
http://www.t10.org/drafts.htm You probably want:
http://www
Hello James,
On Thursday 13 December 2007 15:18:33 James Bottomley wrote:
> On Wed, 2007-12-12 at 18:54 +0100, Bernd Schubert wrote:
> > [Hmm, resending since mail after more than 30min still not on the ML,
> > maybe the attachment was too large? I have uploaded the log to
> > http://www.pci.uni-h
On (13/12/07 16:37), Andrew Morton didst pronounce:
> On Thu, 13 Dec 2007 19:30:00 -0500
> Mark Lord <[EMAIL PROTECTED]> wrote:
>
> > Here's the commit that causes the regression:
> >
> > ...
> >
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -760,7 +760,8 @@ static int rmqueue_bulk(s
On Thursday 13 December 2007 15:18:33 James Bottomley wrote:
> On Wed, 2007-12-12 at 18:54 +0100, Bernd Schubert wrote:
> > [Hmm, resending since mail after more than 30min still not on the ML,
> > maybe the attachment was too large? I have uploaded the log to
> > http://www.pci.uni-heidelberg.de/t
James Bottomley wrote:
> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
>> OK, thanks. I'll assume that James and Hannes have this in hand (or will
>> have, by mid-week) and I won't do anything here.
>
> Just to confirm what I think I'm going to be doing: rebasing the
> scsi-misc tree t
33 matches
Mail list logo
