Mark McLoughlin wrote:
@@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
}
}
else {
+ if (e820_all_mapped(0xF, 0xF+0x1, E820_RAM))
+ goto out;
One issue with using the e820 map for this is that a
On Fri, 2008-02-22 at 07:25 +, Ian Campbell wrote:
> On Thu, 2008-02-21 at 14:58 -0800, H. Peter Anvin wrote:
> >
> > Which it is on real hardware, because although it's not *reserved*
> > (type 2), it is certainly not made available as *normal memory* (type
> > 1). If Xen maps this as type
On Fri, 2008-02-22 at 07:25 +, Ian Campbell wrote:
On Thu, 2008-02-21 at 14:58 -0800, H. Peter Anvin wrote:
Which it is on real hardware, because although it's not *reserved*
(type 2), it is certainly not made available as *normal memory* (type
1). If Xen maps this as type 1 then I
Mark McLoughlin wrote:
@@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
}
}
else {
+ if (e820_all_mapped(0xF, 0xF+0x1, E820_RAM))
+ goto out;
One issue with using the e820 map for this is that a
On Fri 2008-02-22 11:15:59, Andi Kleen wrote:
> Alan Cox wrote:
> >> Actually I switched 64bit over to trust e820 completely and not
> >> reserve 640k-1MB explicitly some time ago
> >> and AFAIK there hasn't been any reports that it causes problems.
> >>
> >> So presumably trusting e802 is ok on
Andi Kleen wrote:
Alan Cox wrote:
Actually I switched 64bit over to trust e820 completely and not
reserve 640k-1MB explicitly some time ago
and AFAIK there hasn't been any reports that it causes problems.
So presumably trusting e802 is ok on modern systems (2003+)
Apparently so - at least
Alan Cox wrote:
>> Actually I switched 64bit over to trust e820 completely and not
>> reserve 640k-1MB explicitly some time ago
>> and AFAIK there hasn't been any reports that it causes problems.
>>
>> So presumably trusting e802 is ok on modern systems (2003+)
>
> Apparently so - at least 64bit
> Actually I switched 64bit over to trust e820 completely and not
> reserve 640k-1MB explicitly some time ago
> and AFAIK there hasn't been any reports that it causes problems.
>
> So presumably trusting e802 is ok on modern systems (2003+)
Apparently so - at least 64bit capable ones. We do
Alan Cox wrote:
>> I'd been meaning to ask this. So the machines you have which don't
>> describe 0xf as reserved also don't describe it as RAM? (I guess
>> it's either a hole in the table or one of the other e820 types).
>
> Making 0xf bus addresses RAM is probably a bad idea anyway.
> I'd been meaning to ask this. So the machines you have which don't
> describe 0xf as reserved also don't describe it as RAM? (I guess
> it's either a hole in the table or one of the other e820 types).
Making 0xf bus addresses RAM is probably a bad idea anyway. Most OS's
treat the E820
I'd been meaning to ask this. So the machines you have which don't
describe 0xf as reserved also don't describe it as RAM? (I guess
it's either a hole in the table or one of the other e820 types).
Making 0xf bus addresses RAM is probably a bad idea anyway. Most OS's
treat the E820 map
Actually I switched 64bit over to trust e820 completely and not
reserve 640k-1MB explicitly some time ago
and AFAIK there hasn't been any reports that it causes problems.
So presumably trusting e802 is ok on modern systems (2003+)
Apparently so - at least 64bit capable ones. We do still
Alan Cox wrote:
Actually I switched 64bit over to trust e820 completely and not
reserve 640k-1MB explicitly some time ago
and AFAIK there hasn't been any reports that it causes problems.
So presumably trusting e802 is ok on modern systems (2003+)
Apparently so - at least 64bit capable
Alan Cox wrote:
I'd been meaning to ask this. So the machines you have which don't
describe 0xf as reserved also don't describe it as RAM? (I guess
it's either a hole in the table or one of the other e820 types).
Making 0xf bus addresses RAM is probably a bad idea anyway. Most OS's
Andi Kleen wrote:
Alan Cox wrote:
Actually I switched 64bit over to trust e820 completely and not
reserve 640k-1MB explicitly some time ago
and AFAIK there hasn't been any reports that it causes problems.
So presumably trusting e802 is ok on modern systems (2003+)
Apparently so - at least
On Fri 2008-02-22 11:15:59, Andi Kleen wrote:
Alan Cox wrote:
Actually I switched 64bit over to trust e820 completely and not
reserve 640k-1MB explicitly some time ago
and AFAIK there hasn't been any reports that it causes problems.
So presumably trusting e802 is ok on modern systems
On Thu, 2008-02-21 at 14:58 -0800, H. Peter Anvin wrote:
>
> Which it is on real hardware, because although it's not *reserved*
> (type 2), it is certainly not made available as *normal memory* (type
> 1). If Xen maps this as type 1 then I definitely see the problem.
>
> We can exclude type 1
Jeremy Fitzhardinge wrote:
>>
>> Available RAM is type 1.
>
> OK. Well, perhaps Ian's patch could be amended to test to see if the
> e820 map marks the ISA ROM region as normal RAM, and skip it if so?
>
That would work, at least for this particular case. I expect you'll
have a neverending
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
It seems to me that those pages are being handed out as heap pages by
the early allocator. In the Xen case this is OK because there's
nothing magic about them. But if real hardware doesn't reserve these
pages in the E820 map, then they
On Feb 21 2008 14:43, Greg KH wrote:
>On Fri, Feb 22, 2008 at 01:33:03AM +0300, Alexey Dobriyan wrote:
>> On Thu, Feb 21, 2008 at 01:14:55PM -0800, Linus Torvalds wrote:
>> > Quite frankly, I've several times been *this* close (holds up fingers so
>> > you can't even see between them) to just
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Still curious about why a pagetable page is ending up in that range
though. Seems like it shouldn't be possible, since we shouldn't be
allowed to allocate from those pages, at least until the DMI probe
has happened... Unless the early
H. Peter Anvin wrote:
Still curious about why a pagetable page is ending up in that range
though. Seems like it shouldn't be possible, since we shouldn't be
allowed to allocate from those pages, at least until the DMI probe
has happened... Unless the early allocator is only excluded from
Jeremy Fitzhardinge wrote:
Ian Campbell wrote:
I'll see if I can track down where the page is getting used and have a
go at getting in there first. It must be pretty early to be allocated
already when dmi_scan_machine gets called.
It's possible that the domain builder might have already
Ian Campbell wrote:
I'll see if I can track down where the page is getting used and have a
go at getting in there first. It must be pretty early to be allocated
already when dmi_scan_machine gets called.
It's possible that the domain builder might have already allocated a PT
at this address. I
Ian Campbell wrote:
I'll see if I can track down where the page is getting used and have a
go at getting in there first. It must be pretty early to be allocated
already when dmi_scan_machine gets called.
It's possible that the domain builder might have already allocated a PT
at this address. I
Jeremy Fitzhardinge wrote:
Ian Campbell wrote:
I'll see if I can track down where the page is getting used and have a
go at getting in there first. It must be pretty early to be allocated
already when dmi_scan_machine gets called.
It's possible that the domain builder might have already
H. Peter Anvin wrote:
Still curious about why a pagetable page is ending up in that range
though. Seems like it shouldn't be possible, since we shouldn't be
allowed to allocate from those pages, at least until the DMI probe
has happened... Unless the early allocator is only excluded from
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Still curious about why a pagetable page is ending up in that range
though. Seems like it shouldn't be possible, since we shouldn't be
allowed to allocate from those pages, at least until the DMI probe
has happened... Unless the early
On Feb 21 2008 14:43, Greg KH wrote:
On Fri, Feb 22, 2008 at 01:33:03AM +0300, Alexey Dobriyan wrote:
On Thu, Feb 21, 2008 at 01:14:55PM -0800, Linus Torvalds wrote:
Quite frankly, I've several times been *this* close (holds up fingers so
you can't even see between them) to just remove
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
It seems to me that those pages are being handed out as heap pages by
the early allocator. In the Xen case this is OK because there's
nothing magic about them. But if real hardware doesn't reserve these
pages in the E820 map, then they
Jeremy Fitzhardinge wrote:
Available RAM is type 1.
OK. Well, perhaps Ian's patch could be amended to test to see if the
e820 map marks the ISA ROM region as normal RAM, and skip it if so?
That would work, at least for this particular case. I expect you'll
have a neverending list of
On Thu, 2008-02-21 at 14:58 -0800, H. Peter Anvin wrote:
Which it is on real hardware, because although it's not *reserved*
(type 2), it is certainly not made available as *normal memory* (type
1). If Xen maps this as type 1 then I definitely see the problem.
We can exclude type 1 memory
On Wed, 2008-02-20 at 13:42 -0800, Joel Becker wrote:
> What changed to make this not work in the first place? New dmi
> code?
I don't think so -- this code is present even in the 2.6.18-xen.hg tree
(where it's gated with is_initial_domain() which isn't suitable for the
upstream tree).
I
On Wed, 2008-02-20 at 13:58 -0800, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
> >
> >> Ian Campbell wrote:
> >>
> >>> On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
> >>>
> On Sun, Feb 17, 2008 at
Ian Campbell wrote:
On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
x86/xen: Do not scan for DMI unless the DMI region is
On Wed, Feb 20, 2008 at 08:51:50AM +, Ian Campbell wrote:
>
> On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
> > NAK!
>
> As far as the actual change goes I was assuming that any machine that
> has DMI/SMBIOS would easily be new enough to have an E820 which could be
> expected to
On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
> Ian Campbell wrote:
> > On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
> >> On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
> >
> >>> x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
> >
> >>
On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
This fixed it.
On Wed, Feb 20, 2008 at 08:51:50AM +, Ian Campbell wrote:
On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
NAK!
As far as the actual change goes I was assuming that any machine that
has DMI/SMBIOS would easily be new enough to have an E820 which could be
expected to reserve
Ian Campbell wrote:
On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
x86/xen: Do not scan for DMI unless the DMI region is
On Wed, 2008-02-20 at 13:58 -0800, Jeremy Fitzhardinge wrote:
Ian Campbell wrote:
On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell
On Wed, 2008-02-20 at 13:42 -0800, Joel Becker wrote:
What changed to make this not work in the first place? New dmi
code?
I don't think so -- this code is present even in the 2.6.18-xen.hg tree
(where it's gated with is_initial_domain() which isn't suitable for the
upstream tree).
I
Ian Campbell wrote:
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
This fixed it. I'm now booting successfully. Thank you!
Excellent.
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
> On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
> > x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
> This fixed it. I'm now booting successfully. Thank you!
Excellent. Jeremy, are you happy
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
> On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
> > I've been seeing similar attempts to map 0xf0 but so far I was the only
> > one (although that made no sense to me). Does the patch below help at
> > all? The problem seems to
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
I've been seeing similar attempts to map 0xf0 but so far I was the only
one (although that made no sense to me). Does the patch below help at
all? The problem seems to be
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
This fixed it. I'm now booting successfully. Thank you!
Excellent. Jeremy, are you happy for
Ian Campbell wrote:
On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
This fixed it. I'm now booting successfully. Thank you!
Excellent.
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
> I've been seeing similar attempts to map 0xf0 but so far I was the only
> one (although that made no sense to me). Does the patch below help at
> all? The problem seems to be that the kernel is trying to map pages at
> 0xf but
On Sun, Feb 17, 2008 at 06:49:21PM +, Ian Campbell wrote:
I've been seeing similar attempts to map 0xf0 but so far I was the only
one (although that made no sense to me). Does the patch below help at
all? The problem seems to be that the kernel is trying to map pages at
0xf but these
On Fri, 2008-02-15 at 12:23 -0800, Joel Becker wrote:
> On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
> >>I'm seeing the same problem, with no messages at all from xen
> >> other than "domain crashed, restart disabled" in xend.log. I got a
> >> different commit in my
Joel Becker wrote:
Unfortunately that doesn't narrow down what the kernel was actually
trying to do at the time. Clearly a set_pte; looks like someone is
trying to create a writable mapping of an existing pte page.
Does "console=hvc0 earlyprintk=xen" on the kernel command line give any
Joel Becker wrote:
Unfortunately that doesn't narrow down what the kernel was actually
trying to do at the time. Clearly a set_pte; looks like someone is
trying to create a writable mapping of an existing pte page.
Does console=hvc0 earlyprintk=xen on the kernel command line give any
On Fri, 2008-02-15 at 12:23 -0800, Joel Becker wrote:
On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
I'm seeing the same problem, with no messages at all from xen
other than domain crashed, restart disabled in xend.log. I got a
different commit in my bisect,
On Sat, Feb 16, 2008 at 10:46:23PM +1100, Jeremy Fitzhardinge wrote:
>>> What does this EIP correspond to in your kernel? Also:
>>>
>>> c01687f0 c0417ab6 c040288f c040299a c0403270
>>>
>>> (as guesses of potential callers to try and work out a stack trace).
>>>
>>
> (My usual technique is
On Sat, Feb 16, 2008 at 10:46:23PM +1100, Jeremy Fitzhardinge wrote:
> Joel Becker wrote:
>> ksymoops is no help at all, but I got these from objdump of
>> vmlinux:
>>
>> c04040bd xen_set_pte
>> c0417ab6 set_pte_present
>> c040288f set_bit
>> c040299a __raw_spin_unlock
>> c0403270 __set_64bit
Joel Becker wrote:
On Sat, Feb 16, 2008 at 01:44:26PM +1100, Jeremy Fitzhardinge wrote:
Joel Becker wrote:
(XEN) mm.c:1825:d109 Bad type (saw 2801 != exp
e000) for mfn 3a2f0f (pfn f0)
(XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry
On Sat, Feb 16, 2008 at 01:44:26PM +1100, Jeremy Fitzhardinge wrote:
> Joel Becker wrote:
>
>> (XEN) mm.c:1825:d109 Bad type (saw 2801 != exp
>> e000) for mfn 3a2f0f (pfn f0)
>> (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry
>> 0003a2f0f063 for
On Sat, Feb 16, 2008 at 01:44:26PM +1100, Jeremy Fitzhardinge wrote:
Joel Becker wrote:
(XEN) mm.c:1825:d109 Bad type (saw 2801 != exp
e000) for mfn 3a2f0f (pfn f0)
(XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry
0003a2f0f063 for dom109
Joel Becker wrote:
On Sat, Feb 16, 2008 at 01:44:26PM +1100, Jeremy Fitzhardinge wrote:
Joel Becker wrote:
(XEN) mm.c:1825:d109 Bad type (saw 2801 != exp
e000) for mfn 3a2f0f (pfn f0)
(XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry
On Sat, Feb 16, 2008 at 10:46:23PM +1100, Jeremy Fitzhardinge wrote:
Joel Becker wrote:
ksymoops is no help at all, but I got these from objdump of
vmlinux:
c04040bd xen_set_pte
c0417ab6 set_pte_present
c040288f set_bit
c040299a __raw_spin_unlock
c0403270 __set_64bit
(My usual
On Sat, Feb 16, 2008 at 10:46:23PM +1100, Jeremy Fitzhardinge wrote:
What does this EIP correspond to in your kernel? Also:
c01687f0 c0417ab6 c040288f c040299a c0403270
(as guesses of potential callers to try and work out a stack trace).
(My usual technique is use gdb vmlinux and x/i
Joel Becker wrote:
On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
I'm seeing the same problem, with no messages at all from xen
other than "domain crashed, restart disabled" in xend.log. I got a
different commit in my bisect,
On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
>> I'm seeing the same problem, with no messages at all from xen
>> other than "domain crashed, restart disabled" in xend.log. I got a
>> different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
>> (i386
On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
I'm seeing the same problem, with no messages at all from xen
other than domain crashed, restart disabled in xend.log. I got a
different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
(i386 boot: replace
Joel Becker wrote:
On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
I'm seeing the same problem, with no messages at all from xen
other than domain crashed, restart disabled in xend.log. I got a
different commit in my bisect,
Joel Becker wrote:
On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct feedback (I
On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
>> I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
>> Unfortunately, I didn't get very far very fast, as the domain just crashed
>> immediately upon booting, without any direct feedback (I did have
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Although I'm on vacation, I happened to download a recent copy of
> x86.git and found that it crashes early. Here's a couple of patches
> to apply; I don't know if they apply to current git, but I hope it
> helps.
thanks Jeremy, applied.
On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
> Hi,
>
> Although I'm on vacation, I happened to download a recent copy of
> x86.git and found that it crashes early. Here's a couple of patches to
> apply; I don't know if they apply to current git, but I hope it helps.
>
Jody Belka wrote:
Hi all,
I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct feedback (I did have messages
on the xen message buffer, which helped). This
Jody Belka wrote:
Hi all,
I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct feedback (I did have messages
on the xen message buffer, which helped). This
On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
Hi,
Although I'm on vacation, I happened to download a recent copy of
x86.git and found that it crashes early. Here's a couple of patches to
apply; I don't know if they apply to current git, but I hope it helps.
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Although I'm on vacation, I happened to download a recent copy of
x86.git and found that it crashes early. Here's a couple of patches
to apply; I don't know if they apply to current git, but I hope it
helps.
thanks Jeremy, applied.
On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct feedback (I did have messages
on
Joel Becker wrote:
On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct feedback (I
Hi all,
I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct feedback (I did have messages
on the xen message buffer, which helped). This even with
Hi all,
I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct feedback (I did have messages
on the xen message buffer, which helped). This even with
78 matches
Mail list logo
