>Agreed, that's almost sure _not_ random memory corruption of the page
>structure. It looks like a VM bug (if you can reproduce trivially I'd give
a
>try to test8 too since test8 is rock solid for me while test10 lockups in
VM
>core at the second bonnie if using emulated highmem).
I was lucky. S
On Fri, 17 Nov 2000, Andrea Arcangeli wrote:
> Plus I add that the "if (!order) goto try_again" is an obvious
> deadlock prone bug introduce in test9 that should be removed.
1) how would this cause deadlocks?
2) how would this somehow be worse than the
unconditional 'goto try_again' we had be
On Fri, 17 Nov 2000, Andrea Arcangeli wrote:
> Actually memory balancing in 2.4.x doesn't get any information,
> not even the information about which _classzone_ where to free
> the memory (NOTE: both 2.2.x and 2.0.x _always_ got the
> classzone where to free memory at least). This classzone miss
On Fri, Nov 17, 2000 at 05:35:53PM +0100, [EMAIL PROTECTED] wrote:
> I did a little closer investigation. The BUG was triggered by a page with
> page->mapping pointing to an address space of a mapped ext2 file
> (page->mapping->a_ops == &ext2_aops). The page had PG_locked, PG_uptodate,
> PG_active
On Fri, 17 Nov 2000 [EMAIL PROTECTED] wrote:
>
> >> Whats the reasoning behind these ifs ?
> >
> >To catch memory corruption or things running out of control in the kernel.
> I was refering to the "if (!order) goto try_again" ifs in alloc_pages, not
> the "if (something) BUG()" ifs.
Basically,
>> before I hit yet another BUG in swap_state.c:60.
>
>The bug in swap_state:60 shows a kernel bug in the VM or random memory
>corruption. Make sure you can reproduce on x86 to be sure it's not a s390
>that is randomly corrupting memory. If you read the oops after the BUG
message
>with asm at ha
On Fri, Nov 17, 2000 at 11:41:58AM +0100, [EMAIL PROTECTED] wrote:
> [..] But low on memory
> does mean low on real memory + swap space, doesn't it ? [..]
No. Low on memory here means that `grep MemFree enough swap space but it isn't using any of it when the BUG hits. I think
This is normal.
>
>>
>> If they absolutely needs 4 pages for pmd pagetables due hardware
constraints
>> I'd recommend to use _four_ hardware pages for each softpage, not two.
>
>Yes.
>
>However, it definitely is an issue of making trade-offs. Most 64-bit MMU
>models tend to have some flexibility in how you set up
On Thu, 16 Nov 2000, Andrea Arcangeli wrote:
>
> If they absolutely needs 4 pages for pmd pagetables due hardware constraints
> I'd recommend to use _four_ hardware pages for each softpage, not two.
Yes.
However, it definitely is an issue of making trade-offs. Most 64-bit MMU
models tend to h
On Thu, Nov 16, 2000 at 09:01:07AM -0800, Linus Torvalds wrote:
> "Linux pages" be _two_ hardware pages, and make a Linux pte contain two
If they absolutely needs 4 pages for pmd pagetables due hardware constraints
I'd recommend to use _four_ hardware pages for each softpage, not two.
The issue
On Thu, 16 Nov 2000 [EMAIL PROTECTED] wrote:
>
> Ok, the BUG() hit in get_pmd_slow:
>
> pmd_t *
> get_pmd_slow(pgd_t *pgd, unsigned long offset)
> {
> pmd_t *pmd;
> int i;
>
> pmd = (pmd_t *) __get_free_pages(GFP_KERNEL,2);
You really need 4 pages?
There's no way to
>What happens if you just replace all places that would use a bad page
>table with a BUG()? (Ie do _not_ add the bug to the place where you
>added the test: by that time it's too late. I'm talking about the
>places where the bad page tables are used, like in the error cases of
>"get_pte_kernel_
In article <[EMAIL PROTECTED]>,
>After some trickery with some special hardware feature (storage
>keys) I found out that empty_bad_pmd_table and empty_bad_pte_table have
>been put to the page table quicklists multiple(!) times.
This is definitely bad, and means that something else really
>> +extern pte_t empty_bad_pte_table[];
>> extern __inline__ void free_pte_fast(pte_t *pte)
>> {
>> + if (pte == empty_bad_pte_table)
>> + return;
>
>I guess that should be BUG() instead of return, so that the callers can be
>fixed.
Not really. pte_free and pmd_free are cal
On Wed, Nov 15, 2000 at 01:39:13PM +0100, [EMAIL PROTECTED] wrote:
> +extern pte_t empty_bad_pte_table[];
> extern __inline__ void free_pte_fast(pte_t *pte)
> {
> + if (pte == empty_bad_pte_table)
> + return;
I guess that should be BUG() instead of return, so that the caller
15 matches
Mail list logo
