linux-kernel - Re: 2.6.21-rc3-mm2 (oops in move

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0703142054170.23208@skynet.skynet.ie>
Date:	Wed, 14 Mar 2007 20:55:46 +0000 (GMT)
From:	Mel Gorman <mel@....ul.ie>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.21-rc3-mm2 (oops in move_freepages)

On Wed, 14 Mar 2007, Bjorn Helgaas wrote:

> On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
>>> <SNIP>
>>> Virtual mem_map starts at 0xa0007fffc7200000
>>> Zone PFN ranges:
>>
>> Total aside, a message should have been printed out here with
>> "sizeof(struct page) = ??" when loglevel was set to 8. I wanted it so I
>> could work out PFNs from the faulting addresses. Can you find such a
>> string in the output of dmesg?
>
> You probably don't need this anymore, but sizeof(struct page) = 56.
>

Thanks, it allowed me to confirm that the fault happened in a definite 
hole based on the output of early_node_map[] so that's good to know. If it 
happened in a location that should have had memory, I would be worried.

>>> BUG: at drivers/pci/pci.c:679 pci_restore_state()
>>>
>>> Call Trace:
>>> [<a000000100014980>] show_stack+0x40/0xa0
>>>                                sp=e000004063a5fb90 bsp=e000004063a58f98
>>> [<a0000001000152b0>] dump_stack+0x30/0x60
>>>                                sp=e000004063a5fd60 bsp=e000004063a58f80
>>> [<a0000001003f8800>] pci_restore_state+0x480/0x4a0
>>>                                sp=e000004063a5fd60 bsp=e000004063a58f38
>>> [<a00000010051a0b0>] tg3_chip_reset+0x6d0/0x1020
>> ...
>> That doesn't look particularly healthy! Is this a known problem?
>
> Yeah, that's ugly, isn't it?  I hadn't got to worrying about that yet.
>

heh, ok.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/