Date: Wed, 02 Jul 2003 15:57:13 -0700
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrew Morton <akpm@digeo.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: Yet another SDET hang (73-mm3) ... yawn
Message-ID: <575880000.1057186633@flay>
In-Reply-To: <20030702155330.7d879299.akpm@digeo.com>
References: <570860000.1057184743@flay> <20030702155330.7d879299.akpm@digeo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1417
Lines: 44

--On Wednesday, July 02, 2003 15:53:30 -0700 Andrew Morton <akpm@digeo.com> wrote:

> "Martin J. Bligh" <mbligh@aracnet.com> wrote:
>> 
>> 2.5.73-mm3 + feral + highpte (ext2)
>> 
>> Seems to be all wedged up on io_schedule. Not sure if it was
>> highpte that caused this or not, but I'd done one run on ext2
>> and one on ext3 without it, and they worked fine.
> 
> highpte, or highpmd?
> 
> I assume the latter.  But either way, it would be an odd correlation.

The former, I think. I turned on "3rd level pagetables in high memory". Presumably that's still just highpte.

larry:~/linux/2.5.73-mm3# grep HIGH .config
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
# CONFIG_DEBUG_HIGHMEM is not set

But yes, it's probably coincidence.

> It looks more like the block layer or device driver blew a fuse.  The usual
> deal: make it repeatable, then try `elevator=deadline', then try a
> different driver..

Yeah, I'll beat her some more later.

> Oh, and write OpenSDET while you're at it.  grr.

Use reaim7. But maybe I should write open-16-way-hardware with a
subtext of race-conditions-we-find? ;-)

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/