From: Johannes Berg
commit 71826654ce40112f0651b6f4e94c422354f4adb6 upstream.
Recompiling with the new extended version of struct rfkill_event
broke systemd in *two* ways:
- It used "sizeof(struct rfkill_event)" to read the event, but
then complained if it actually got something != 8, this b
-...@vger.kernel.org; mcg...@kernel.org; Zhang, ShanshanX
; Jia, Pei P
Subject: Re: [PATCH] Revert "block: revert back to synchronous request_queue
removal"
Hello Haifeng,
On Wed, Sep 09, 2020 at 02:11:20AM +, Zhao, Haifeng wrote:
> Ming, Christoph,
> Could you point out th
Hello Haifeng,
On Wed, Sep 09, 2020 at 02:11:20AM +, Zhao, Haifeng wrote:
> Ming, Christoph,
> Could you point out the patch aimed to fix this issue ? I would like to
> try it. This issue blocked my other PCI patch developing and verification
> work,
> I am not a BLOCK/NVMe expert, wo
rg;
Zhang, ShanshanX ; Jia, Pei P ;
Ming Lei
Subject: Re: [PATCH] Revert "block: revert back to synchronous request_queue
removal"
On Tue, Sep 08, 2020 at 03:50:48AM -0400, Ethan Zhao wrote:
> From: Ethan Zhao
>
> 'commit e8c7d14ac6c3 ("block: revert back
On Tue, Sep 08, 2020 at 03:50:48AM -0400, Ethan Zhao wrote:
> From: Ethan Zhao
>
> 'commit e8c7d14ac6c3 ("block: revert back to synchronous request_queue
> removal")' introduced panic issue to NVMe hotplug as following(hit
> after just 2 times NVMe SSD hotplug
On 2020-09-08 00:50, Ethan Zhao wrote:
> From: Ethan Zhao
>
> 'commit e8c7d14ac6c3 ("block: revert back to synchronous request_queue
> removal")' introduced panic issue to NVMe hotplug as following(hit
> after just 2 times NVMe SSD hotplug under stable 5.9
From: Ethan Zhao
'commit e8c7d14ac6c3 ("block: revert back to synchronous request_queue
removal")' introduced panic issue to NVMe hotplug as following(hit
after just 2 times NVMe SSD hotplug under stable 5.9-RC2):
BUG: sleeping function called from invalid context a
Committer: Ingo Molnar
CommitterDate: Wed, 19 Aug 2020 10:49:47 +02:00
ARM, sched/topology: Revert back to default scheduler topology
The ARM-specific GMC level is meant to be built using the thread sibling
mask, but no devicetree in arch/arm/boot/dts uses the 'thread' cpu-map
bin
The ARM-specific GMC level is meant to be built using the thread sibling
mask, but no devicetree in arch/arm/boot/dts uses the 'thread' cpu-map
binding. With SD_SHARE_POWERDOMAIN gone, this topology level can be
removed, at which point ARM no longer benefits from having a custom defined
topology ta
On 13/08/20 20:16, Ingo Molnar wrote:
> * Valentin Schneider wrote:
>
>> The ARM-specific GMC level is meant to be built using the thread sibling
>> mask, but no devicetree in arch/arm/boot/dts uses the 'thread' cpu-map
>> binding. With SD_SHARE_POWERDOMAIN gone, this topology level can be
>> re
* Valentin Schneider wrote:
> The ARM-specific GMC level is meant to be built using the thread sibling
> mask, but no devicetree in arch/arm/boot/dts uses the 'thread' cpu-map
> binding. With SD_SHARE_POWERDOMAIN gone, this topology level can be
> removed, at which point ARM no longer benefits
The ARM-specific GMC level is meant to be built using the thread sibling
mask, but no devicetree in arch/arm/boot/dts uses the 'thread' cpu-map
binding. With SD_SHARE_POWERDOMAIN gone, this topology level can be
removed, at which point ARM no longer benefits from having a custom defined
topology ta
The ARM-specific GMC level is meant to be built using the thread sibling
mask, but no devicetree in arch/arm/boot/dts uses the 'thread' cpu-map
binding. With SD_SHARE_POWERDOMAIN gone, this topology level can be
removed, at which point ARM no longer benefits from having a custom defined
topology ta
27;s take the opportunity to document when that is expected to
happen and also document the context of the related calls as best as
possible so we can avoid future issues, and with the hopes that the
synchronous request_queue removal sticks.
We revert back to synchronous request_queue removal bec
On Fri, Jun 12, 2020 at 06:53:40PM -0700, Bart Van Assche wrote:
> On 2020-06-08 10:01, Luis Chamberlain wrote:
> > + * Drivers exist which depend on the release of the request_queue to be
> > + * synchronous, it should not be deferred.
>
> This sounds mysterious. Which drivers? Why do these depen
On 2020-06-08 10:01, Luis Chamberlain wrote:
> + * Drivers exist which depend on the release of the request_queue to be
> + * synchronous, it should not be deferred.
This sounds mysterious. Which drivers? Why do these depend on this
function being synchronous? Anyway:
Reviewed-by: Bart Van Assche
27;s take the opportunity to document when that is expected to
happen and also document the context of the related calls as best as possible
so we can avoid future issues, and with the hopes that the synchronous
request_queue removal sticks.
We revert back to synchronous request_queue removal bec
27;s take the opportunity to document when that is expected to
happen and also document the context of the related calls as best as possible
so we can avoid future issues, and with the hopes that the synchronous
request_queue removal sticks.
We revert back to synchronous request_queue removal bec
;s take the opportunity to document when that is expected to
> > happen and also document the context of the related calls as best as
> > possible
> > so we can avoid future issues, and with the hopes that the synchronous
> > request_queue removal sticks.
> >
&g
ble
> so we can avoid future issues, and with the hopes that the synchronous
> request_queue removal sticks.
>
> We revert back to synchronous request_queue removal because asynchronous
> removal creates a regression with expected userspace interaction with
> several drivers. An example is whe
On 2020-05-08 20:10, Luis Chamberlain wrote:
> We revert back to synchronous request_queue removal because asynchronous
> removal creates a regression with expected userspace interaction with
> several drivers. An example is when removing the loopback driver, one
> uses ioctls from use
27;s take the opportunity to document when that is expected to
happen and also document the context of the related calls as best as possible
so we can avoid future issues, and with the hopes that the synchronous
request_queue removal sticks.
We revert back to synchronous request_queue removal bec
On Sun, May 03, 2020 at 03:32:45AM -0700, Matthew Wilcox wrote:
> On Fri, May 01, 2020 at 05:22:12PM -0700, Bart Van Assche wrote:
> > > expected behaviour before and it now fails as the device is still present
> >^
> >behavior?
>
> That's UK/US spelling. We do not
On Fri, May 01, 2020 at 05:22:12PM -0700, Bart Van Assche wrote:
> Please fix the spelling errors. Otherwise this patch looks good to me.
Fixed, thanks for the review.
Luis
On Fri, May 01, 2020 at 05:22:12PM -0700, Bart Van Assche wrote:
> > expected behaviour before and it now fails as the device is still present
>^
>behavior?
That's UK/US spelling. We do not "correct" one to the other.
Documentation/doc-guide/contributing.rst: - Bo
ed to
> happen and also document the context of the related calls as best as possible
> so we can avoid future issues, and with the hopes that the synchronous
> request_queue removal sticks.
>
> We revert back to synchronous request_queue removal because asynchronous
> removal cr
Looks good,
Reviewed-by: Christoph Hellwig
s take the opportunity to document when that is expected to
happen and also document the context of the related calls as best as possible
so we can avoid future issues, and with the hopes that the synchronous
request_queue removal sticks.
We revert back to synchronous request_queue removal bec
From: Jani Nikula
commit 21635d7311734d2d1b177f8a95e2f9386174b76d upstream.
Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
and narrow") started to optize the eDP 1.4+ link config, both per spec
and as preparation for display stream compression support.
Sadly, we again fac
Hi Charles,
On 2018-11-22 18:30, Charles Keepax wrote:
> This reverts commit 466affa06703 ("regulator: wm8994: Don't
> use devres for enable GPIOs"). Whilst that did work around the
> issue in question there are complications on the error paths of
> regulator_register. In the success case clearly
This reverts commit 466affa06703 ("regulator: wm8994: Don't
use devres for enable GPIOs"). Whilst that did work around the
issue in question there are complications on the error paths of
regulator_register. In the success case clearly the regulator
core owns the GPIO, however, in the failure case i
3.19.8-ckt6 -stable review patch. If anyone has any objections, please let me
know.
--
From: David Milburn
commit af34d637637eabaf49406eb35c948cd51ba262a6 upstream.
Since no longer limiting max_sectors to BLK_DEF_MAX_SECTORS (commit
34b48db66e08),
data corruption may occur o
4.1-stable review patch. If anyone has any objections, please let me know.
--
From: David Milburn
commit af34d637637eabaf49406eb35c948cd51ba262a6 upstream.
Since no longer limiting max_sectors to BLK_DEF_MAX_SECTORS (commit
34b48db66e08),
data corruption may occur on ST380013
Reverts commit d26b17edafc45187c30cae134a5e5429d58ad676
ARM: sa1100: collie.c: fall back to jedec_probe flash detection
Unfortunately the detection was challenged on the defective unit used for tests:
one of the NOR chips did not respond to the CFI query.
Moreover that bad device needed extra dela
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
At Thu, 19 Dec 2013 18:29:09 +0100,
Takashi Iwai wrote:
>
> At Thu, 19 Dec 2013 16:48:24 +,
> Lee Jones wrote:
> >
> > > > Commit '166a34d ASoC: ab8500: Fix invalid cast to long pointer'
> > > > rather carelessly converts find_next_bit() to fls() (find last
> > > > bit set), which are not the
At Fri, 20 Dec 2013 14:02:11 +,
Lee Jones wrote:
>
> > > > > Commit '166a34d ASoC: ab8500: Fix invalid cast to long pointer'
> > > > > rather carelessly converts find_next_bit() to fls() (find last
> > > > > bit set), which are not the same.
> > > >
> > > > Does it break on the real machines?
> > > > Commit '166a34d ASoC: ab8500: Fix invalid cast to long pointer'
> > > > rather carelessly converts find_next_bit() to fls() (find last
> > > > bit set), which are not the same.
> > >
> > > Does it break on the real machines?
> >
> > It does, that's how I found the bug.
> >
> > > fls() be
At Thu, 19 Dec 2013 16:48:24 +,
Lee Jones wrote:
>
> > > Commit '166a34d ASoC: ab8500: Fix invalid cast to long pointer'
> > > rather carelessly converts find_next_bit() to fls() (find last
> > > bit set), which are not the same.
> >
> > Does it break on the real machines?
>
> It does, that'
> > Commit '166a34d ASoC: ab8500: Fix invalid cast to long pointer'
> > rather carelessly converts find_next_bit() to fls() (find last
> > bit set), which are not the same.
>
> Does it break on the real machines?
It does, that's how I found the bug.
> fls() behaves differently from find_next_bit
At Thu, 19 Dec 2013 15:54:59 +,
Lee Jones wrote:
>
> Commit '166a34d ASoC: ab8500: Fix invalid cast to long pointer'
> rather carelessly converts find_next_bit() to fls() (find last
> bit set), which are not the same.
Does it break on the real machines?
fls() behaves differently from find_ne
Commit '166a34d ASoC: ab8500: Fix invalid cast to long pointer'
rather carelessly converts find_next_bit() to fls() (find last
bit set), which are not the same.
Although this implementation may not be portable, the alternative
breaks audio on anything using the AB8500 CODEC, which is a much
greate
On 12.11.2013 22:55, Joe Mario wrote:
> Given there are 5 other locations in the code that need to be changed
> from [128] to [KSYM_NAME_LEN], and that we still haven't found Fengguang's
> problem yet, I'd be in favor of letting Michal's revert patch 2/2 go
> forward.
It's in kbuild.git#kbu
On 11/11/2013 09:17 AM, Andi Kleen wrote:
On Mon, Nov 11, 2013 at 02:40:36PM +0100, Michal Marek wrote:
This reverts commits
f3462aa (Kbuild: Handle longer symbols in kallsyms.c) and
eea0e9c (kbuild: Increase kallsyms max symbol length)
except for the added overflow check. The reason is a regres
On Mon, Nov 11, 2013 at 06:17:15AM -0800, Andi Kleen wrote:
> On Mon, Nov 11, 2013 at 02:40:36PM +0100, Michal Marek wrote:
> > This reverts commits
> > f3462aa (Kbuild: Handle longer symbols in kallsyms.c) and
> > eea0e9c (kbuild: Increase kallsyms max symbol length)
> > except for the added overf
On Mon, Nov 11, 2013 at 02:40:36PM +0100, Michal Marek wrote:
> This reverts commits
> f3462aa (Kbuild: Handle longer symbols in kallsyms.c) and
> eea0e9c (kbuild: Increase kallsyms max symbol length)
> except for the added overflow check. The reason is a regression caused
> by increasing the buffe
This reverts commits
f3462aa (Kbuild: Handle longer symbols in kallsyms.c) and
eea0e9c (kbuild: Increase kallsyms max symbol length)
except for the added overflow check. The reason is a regression caused
by increasing the buffer:
http://marc.info/?l=linux-kernel&m=138387700415675.
Reported-by: Fen
Confirm receipt of this email..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 12/21/2012 12:22 AM, Dave Young wrote:
On Thu, Nov 29, 2012 at 5:47 AM, Yinghai Lu wrote:
Hi, Yinghai and HPA
What's the staus of this patch, will it go for 3.8? Is there anything
blocking this patch?
It's 3.9 material at this point. The sheer size and messiness of the
whole set has b
On Fri, Dec 21, 2012 at 12:22 AM, Dave Young wrote:
>
> What's the staus of this patch, will it go for 3.8? Is there anything
> blocking this patch?
no.
Now it is in tip:x86/mm2.
it should be go with for-x86-boot for 3.9
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe lin
On Thu, Nov 29, 2012 at 5:47 AM, Yinghai Lu wrote:
> After
>
> | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> | Author: Takashi Iwai
> | Date: Sun Oct 23 23:19:12 2011 +0200
> |
> |x86: Fix S4 regression
> |
> |Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
|regression since 2.6.39, namely the machine reboots occasionally
Commit-ID: 28b6ff667013735dd2e68edd105d17cdf3835dcb
Gitweb: http://git.kernel.org/tip/28b6ff667013735dd2e68edd105d17cdf3835dcb
Author: Yinghai Lu
AuthorDate: Fri, 16 Nov 2012 19:38:42 -0800
Committer: H. Peter Anvin
CommitDate: Sat, 17 Nov 2012 11:59:04 -0800
x86, mm: Revert back
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
|regression since 2.6.39, namely the machine reboots occasionally
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
|regression since 2.6.39, namely the machine reboots occasionally
On Fri, Oct 5, 2012 at 7:58 AM, Yinghai Lu wrote:
> On Fri, Oct 5, 2012 at 4:27 AM, Stefano Stabellini
> wrote:
>> On Fri, 5 Oct 2012, Yinghai Lu wrote:
>>> On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin wrote:
>>> >
>>> > See my other post. This is bringing up the Kernel Summit algorithm again
That disappeared 10 years ago...
ebied...@xmission.com wrote:
>"H. Peter Anvin" writes:
>
>> On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
>>> Yinghai Lu writes:
>>>
with bzImage or vmlinux?
>>>
>>> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
>>> which is where u
"H. Peter Anvin" writes:
> On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
>> Yinghai Lu writes:
>>
>>> with bzImage or vmlinux?
>>
>> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
>> which is where ultimiately the 896M limite came from.
>>
>
> ~896M (actually comes from i
On 10/05/2012 05:28 PM, Eric W. Biederman wrote:
Seriously, any case where we can't load anywhere in physical ram on x86-64 is a
bug. i386 is another matter.
As I recall there are data structures like the IDT that only have a
32bit base address.
Not true. The only one I know of is memory
"H. Peter Anvin" writes:
> On 10/05/2012 02:32 PM, Eric W. Biederman wrote:
>> Yinghai Lu writes:
>>
>>> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman
>>> wrote:
>> Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently teste
On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
Yinghai Lu writes:
with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
~896M (actually comes from i386, not from bzImage...
-hpa
--
H.
On 10/05/2012 02:32 PM, Eric W. Biederman wrote:
Yinghai Lu writes:
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman wrote:
Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and anywhere below 4G is
good, and there is a patch
I am going to see about merging these two threads.
Yinghai Lu writes:
> On Fri, Oct 5, 2012 at 2:41 PM, Eric W. Biederman
> wrote:
>> Yinghai Lu writes:
>>
>>> with bzImage or vmlinux?
>>
>> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
>> which is where ultimiately the
On Fri, Oct 5, 2012 at 2:41 PM, Eric W. Biederman wrote:
> Yinghai Lu writes:
>
>> with bzImage or vmlinux?
>
> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
> which is where ultimiately the 896M limite came from.
they are using updated kexec-tools ?
last time when i check
Yinghai Lu writes:
> with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ker
On Fri, Oct 5, 2012 at 2:32 PM, Eric W. Biederman wrote:
> Yinghai Lu writes:
>
>> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman
>> wrote:
> Is there a git commit that explains what the 'big range' problem is?
>>>
>>> At least on x86_64 this was recently tested and anywhere below 4G is
Yinghai Lu writes:
> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman
> wrote:
Is there a git commit that explains what the 'big range' problem is?
>>
>> At least on x86_64 this was recently tested and anywhere below 4G is
>> good, and there is a patch floating around somewhere to remove
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman wrote:
>>> Is there a git commit that explains what the 'big range' problem is?
>
> At least on x86_64 this was recently tested and anywhere below 4G is
> good, and there is a patch floating around somewhere to remove this
> issue.
patch for kerne
Yinghai Lu writes:
> On Thu, Oct 4, 2012 at 9:46 AM, Konrad Rzeszutek Wilk
> wrote:
>>> then kdump may have problem get big range again.
>>
>> Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and anywhere below 4G is
good, and ther
On Fri, Oct 5, 2012 at 4:27 AM, Stefano Stabellini
wrote:
> On Fri, 5 Oct 2012, Yinghai Lu wrote:
>> On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin wrote:
>> >
>> > See my other post. This is bringing up the Kernel Summit algorithm again.
>> >
>>
>> sure. please check if you are ok with attached
On Fri, 5 Oct 2012, Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin wrote:
> >
> > See my other post. This is bringing up the Kernel Summit algorithm again.
> >
>
> sure. please check if you are ok with attached one on top of x86/mm2
>
> Subject: [PATCH] x86: get early page t
On Thu, 4 Oct 2012, Yinghai Lu wrote:
> On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini
> wrote:
> > On Sun, 30 Sep 2012, Yinghai Lu wrote:
> >> After
> >>
> >> | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> >> | Author: Takashi Iwai
> >> | Date: Sun Oct 23 23:19:12 2011 +0200
> >> |
>
On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin wrote:
>
> See my other post. This is bringing up the Kernel Summit algorithm again.
>
sure. please check if you are ok with attached one on top of x86/mm2
Thanks
Yinghai
fix_max_pfn_xx_11.patch
Description: Binary data
On 10/04/2012 02:46 PM, Yinghai Lu wrote:
or let xen map that page table by itself at first?
See my other post. This is bringing up the Kernel Summit algorithm again.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
T
On 10/04/2012 06:56 AM, Konrad Rzeszutek Wilk wrote:
What Peter had in mind is a nice system where we get rid of
this linear allocation of page-tables (so pgt_buf_start -> pgt_buf
_end are linearly allocated). His thinking (and Peter if I mess
up please correct me), is that we can stick the vari
On Thu, Oct 4, 2012 at 2:41 PM, H. Peter Anvin wrote:
> On 10/04/2012 02:40 PM, Yinghai Lu wrote:
>> On Thu, Oct 4, 2012 at 2:21 PM, Yinghai Lu wrote:
>>> On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
>>> wrote:
> So could use ram under 1M to map that page table at first.
C
On 10/04/2012 02:40 PM, Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 2:21 PM, Yinghai Lu wrote:
>> On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
>> wrote:
So could use ram under 1M to map that page table at first.
>>>
>>> Could or does this patch do it? And why 1MB?
>>
>> can you or st
On Thu, Oct 4, 2012 at 2:21 PM, Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
> wrote:
>>> So could use ram under 1M to map that page table at first.
>>
>> Could or does this patch do it? And why 1MB?
>
> can you or stefano could test attached patch on xen ?
>
on top o
On Thu, Oct 4, 2012 at 9:46 AM, Konrad Rzeszutek Wilk
wrote:
>> then kdump may have problem get big range again.
>
> Is there a git commit that explains what the 'big range' problem is?
commit 7f8595bfacef279f06c82ec98d420ef54f2537e0
Author: H. Peter Anvin
Date: Thu Dec 16 19:20:41 2010 -0800
On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
wrote:
>> So could use ram under 1M to map that page table at first.
>
> Could or does this patch do it? And why 1MB?
can you or stefano could test attached patch on xen ?
that will map the page table buffer that will be used.
under 1M, stil
On Thu, Oct 04, 2012 at 09:19:08AM -0700, Yinghai Lu wrote:
> On Wed, Oct 3, 2012 at 9:51 AM, Jacob Shin wrote:
> > Any comments, thoughts? hpa? Yinghai?
> >
> > So it seems that during init_memory_mapping Xen needs to modify page table
> > bits and the memory where the page tables live needs to b
On Thu, Oct 04, 2012 at 08:57:55AM -0700, Yinghai Lu wrote:
> On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini
> wrote:
> > On Sun, 30 Sep 2012, Yinghai Lu wrote:
> >> After
> >>
> >> | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> >> | Author: Takashi Iwai
> >> | Date: Sun Oct 23 23:19:1
On Wed, Oct 3, 2012 at 9:51 AM, Jacob Shin wrote:
> Any comments, thoughts? hpa? Yinghai?
>
> So it seems that during init_memory_mapping Xen needs to modify page table
> bits and the memory where the page tables live needs to be direct mapped at
> that time.
>
> Since we now call init_memory_mapp
On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini
wrote:
> On Sun, 30 Sep 2012, Yinghai Lu wrote:
>> After
>>
>> | commit 8548c84da2f47e71bbbe300f55edb768492575f7
>> | Author: Takashi Iwai
>> | Date: Sun Oct 23 23:19:12 2011 +0200
>> |
>> |x86: Fix S4 regression
>> |
>> |Commit 4b239f4
On Wed, Oct 03, 2012 at 11:51:06AM -0500, Jacob Shin wrote:
> On Mon, Oct 01, 2012 at 12:00:26PM +0100, Stefano Stabellini wrote:
> > On Sun, 30 Sep 2012, Yinghai Lu wrote:
> > > After
> > >
> > > | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> > > | Author: Takashi Iwai
> > > | Date: Sun O
On 10/03/2012 09:51 AM, Jacob Shin wrote:
Any comments, thoughts? hpa? Yinghai?
So it seems that during init_memory_mapping Xen needs to modify page table
bits and the memory where the page tables live needs to be direct mapped at
that time.
Since we now call init_memory_mapping for every E820
On Mon, Oct 01, 2012 at 12:00:26PM +0100, Stefano Stabellini wrote:
> On Sun, 30 Sep 2012, Yinghai Lu wrote:
> > After
> >
> > | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> > | Author: Takashi Iwai
> > | Date: Sun Oct 23 23:19:12 2011 +0200
> > |
> > |x86: Fix S4 regression
> > |
> >
On Sun, 30 Sep 2012, Yinghai Lu wrote:
> After
>
> | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> | Author: Takashi Iwai
> | Date: Sun Oct 23 23:19:12 2011 +0200
> |
> |x86: Fix S4 regression
> |
> |Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
> |regre
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
|regression since 2.6.39, namely the machine reboots occasionally
So we could put page table high again for 64bit.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 15a6a38..cca9b7d 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> So we could put page table high again for 64bit.
>
> Signed-off-by: Yinghai Lu
The changelog for this is too terse for me to actually understand why
this is needed.
> ---
> arch/x86/mm/init.c |2 +-
> 1 files changed, 1 insertions(+), 1
So we could put page table high again for 64bit.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 15a6a38..cca9b7d 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -
So we could put page table high again for 64bit.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 15a6a38..cca9b7d 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -
93 matches
Mail list logo
