Acked-by: Sonic Zhang
On Thu, Mar 7, 2013 at 8:12 PM, Jiri Slaby wrote:
> There are no (and never were any) kgdb fields in uart_ops. Setting
> them produces a build error:
> drivers/tty/serial/bfin_uart.c:1054:2: error: unknown field
> 'kgdboc_port_startup' specified in initializer
>
(2013/03/08 16:33), WANG Chao wrote:
On 03/08/2013 03:27 PM, Yinghai Lu wrote:
On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao wrote:
looks like your system DO have DMAR table, please enable dmar
remapping in your kernel config.
I've already got following config:
CONFIG_DMAR_TABLE=y
On Thu, Mar 7, 2013 at 11:33 PM, WANG Chao wrote:
> On 03/08/2013 03:27 PM, Yinghai Lu wrote:
>> On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao wrote:
looks like your system DO have DMAR table, please enable dmar
remapping in your kernel config.
>>>
>>> I've already got following
Johannes Weiner wrote:
On Thu, Mar 07, 2013 at 04:43:12PM +0100, Jan Kara wrote:
2 questions:
why is there data in the FS cache that isn't owned by (the mmap
of) the process that caused it to be paged in in the first place?
The filesystem cache is shared among processes because the
On Thu, Mar 7, 2013 at 11:01 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:40PM -0800, Yinghai Lu wrote:
>> If node with ram is hotplugable, local node mem for page table and vmemmap
>> should be on that node ram.
>>
>> This patch is some kind of refreshment of
>> | commit
On 08.03.2013 07:42, Hillf Danton wrote:
On Fri, Mar 8, 2013 at 3:37 AM, Jiri Slaby wrote:
On 03/01/2013 03:02 PM, Hillf Danton wrote:
On Fri, Mar 1, 2013 at 1:02 AM, Jiri Slaby wrote:
Ok, no difference, kswap is still crazy. I'm attaching the output of
"grep -vw '0' /proc/vmstat" if you
Steven,
(03/08/2013 12:34 AM), Steven Rostedt wrote:
The second patch, returns success on a reset of the buffer even if
the buffer wasn't allocated. Returning -EINVAL is just confusing.
I realized we should update the snapshot documentation together with
this change.
I attached a patch to
On Thu, Mar 7, 2013 at 11:19 PM, Tejun Heo wrote:
> On Thu, Mar 7, 2013 at 11:18 PM, Yinghai Lu wrote:
>> ia64 like to call in this seqence
>> acpi_numa_init()
>> parse srat
>> parse slit
>> then
>> acpi_numa_arch_fixup()
>>
>> in this arch_fixup, it will try to fill dummy distance_matrix.
>>
>>
On 03/08/2013 03:27 PM, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao wrote:
>>>
>>> looks like your system DO have DMAR table, please enable dmar
>>> remapping in your kernel config.
>>
>> I've already got following config:
>> CONFIG_DMAR_TABLE=y
>> CONFIG_INTEL_IOMMU=y
>>
On 03/08/2013 02:44 PM, Mike Galbraith wrote:
> On Fri, 2013-03-08 at 10:37 +0800, Michael Wang wrote:
>> On 03/07/2013 05:43 PM, Mike Galbraith wrote:
>>> On Thu, 2013-03-07 at 09:36 +0100, Peter Zijlstra wrote:
On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
>
sctp_assoc_lookup_tsn() function searchs which transport a certain TSN
was sent on, if not found in the active_path transport, then go search
all the other transports in the peer's transport_addr_list, however, we
should continue to the next entry rather than break the loop when meet
the
On Thu, Mar 07, 2013 at 01:16:08PM -0800, Andrew Chew wrote:
> The backlight enable regulator is specified in the device tree node for
> backlight.
>
> Signed-off-by: Andrew Chew
This looks good in general. I'd like to see Alex' comment addressed and
perhaps the commit message shouldn't be
On Thu, Mar 07, 2013 at 11:25:14PM -0800, Yinghai Lu wrote:
> >> > Why is this table made a stack variable? What's the benefit of doing
> >> > that?
> >>
> >> so I do need to switch global variables to phys and access it.
> >
> > I can't really understand what your response means. Can you please
On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao wrote:
>>
>> looks like your system DO have DMAR table, please enable dmar
>> remapping in your kernel config.
>
> I've already got following config:
> CONFIG_DMAR_TABLE=y
> CONFIG_INTEL_IOMMU=y
> CONFIG_IRQ_REMAP=y
>
> but I don't have intel_iommu=on in
2013/3/5 Bryan Wu :
> On Sun, Mar 3, 2013 at 11:40 PM, Christian Gmeiner
> wrote:
>> ping
>> --
>> Christian Gmeiner, MSc
>>
>>
>> 2013/2/23 Christian Gmeiner :
>>> 2013/2/15 Bryan Wu :
On Wed, Feb 13, 2013 at 7:58 AM, Christian Gmeiner
wrote:
> During the development of this
On Friday 08 March 2013 04:46 AM, Greg KH wrote:
On Fri, Mar 08, 2013 at 12:57:37AM +0530, Laxman Dewangan wrote:
The alramtimer suspend failed when nearest alarm wakeup time is
less than 2 sec or rtc timer can not start.
In suspend/resume stress testing, we found that sometimes alramtimer
On Wed, Mar 06, 2013 at 02:05:52PM +0100, Thomas Gleixner wrote:
> On Wed, 6 Mar 2013, Simon Horman wrote:
>
> > On Wed, Mar 06, 2013 at 11:01:14AM +0100, Thomas Gleixner wrote:
> > > On Wed, 6 Mar 2013, Simon Horman wrote:
> > > > On Mon, Feb 18, 2013 at 11:28:34PM +0900, Magnus Damm wrote:
> >
On Thu, Mar 7, 2013 at 11:06 PM, Tejun Heo wrote:
> Hello, Yinghai.
>
> On Thu, Mar 07, 2013 at 10:57:21PM -0800, Yinghai Lu wrote:
>> On Thu, Mar 7, 2013 at 9:50 PM, Tejun Heo wrote:
>> > On Thu, Mar 07, 2013 at 08:58:30PM -0800, Yinghai Lu wrote:
>> >> We will find acpi tables in initrd during
On Fri, Mar 08, 2013 at 11:21:04AM +0900, Alex Courbot wrote:
> On 03/08/2013 06:07 AM, Andrew Chew wrote:
> >>From: Thierry Reding [mailto:thierry.red...@avionic-design.de]
> >>Sent: Thursday, March 07, 2013 3:27 AM
> >>To: Alex Courbot
> >>Cc: Andrew Chew; linux-kernel@vger.kernel.org
>
On 03/08/2013 02:36 PM, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 10:32 PM, Yinghai Lu wrote:
>> On Thu, Mar 7, 2013 at 10:03 PM, CAI Qian wrote:
>>> CC'ing kexec ML. Also mentioned that 3.8 has no such issue.
>>>
>>> This message looks suspicious and out of range while 3.8 reservation
>>>
On Fri, 8 Mar 2013, Daniel Lezcano wrote:
> On 03/06/2013 10:48 AM, Thomas Gleixner wrote:
> I was wondering if it would be possible to take the 3/4 and 4/4
> otherwise the flag dependency will prevent to send those to the
> maintainer's tree until they gain visibility on it.
I can take them with
On Thu, Mar 7, 2013 at 11:18 PM, Yinghai Lu wrote:
> ia64 like to call in this seqence
> acpi_numa_init()
> parse srat
> parse slit
> then
> acpi_numa_arch_fixup()
>
> in this arch_fixup, it will try to fill dummy distance_matrix.
>
> so would to keep acpi_numa_init ...
Can't it just call
On Thu, Mar 7, 2013 at 10:46 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:37PM -0800, Yinghai Lu wrote:
>> +void __init acpi_numa_init_only_slit(void)
>> +{
>> + /* SLIT: System Locality Information Table */
>> + acpi_table_parse(ACPI_SIG_SLIT, acpi_parse_slit);
>> +}
>> +
>>
On 03/08/2013 12:40 AM, Marcelo Tosatti wrote:
On Mon, Mar 04, 2013 at 11:31:46PM +0530, Raghavendra K T wrote:
This patch series further filters better vcpu candidate to yield to
in PLE handler. The main idea is to record the preempted vcpus using
preempt notifiers and iterate only those
On Thu, 7 Mar 2013 22:57:21 -0800 Yinghai Lu wrote:
> >
> >> @@ -552,38 +552,47 @@ u8 __init acpi_table_checksum(u8 *buffer, u32 length)
> >> return sum;
> >> }
> >>
> >> -/* All but ACPI_SIG_RSDP and ACPI_SIG_FACS: */
> >> -static const char * const table_sigs[] = {
> >> -
On Thu, Mar 7, 2013 at 10:42 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:36PM -0800, Yinghai Lu wrote:
>> -static int __init numa_check_memblks(struct numa_meminfo *mi)
>> +
>> +int __init numa_check_memblks(struct numa_meminfo *mi)
>> {
>> + nodemask_t tmp_node_map;
>>
On Thu, Mar 7, 2013 at 2:23 PM, Ian Lartey wrote:
> This patchset adds to the support for the Palmas iseries of PMIC chips.
>
> Some of the patches have previously been submitted individually.
> The DT bindings doc has been added first due to comments that it was
> missing.
Can the patches to
On Thu, Mar 7, 2013 at 10:28 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:35PM -0800, Yinghai Lu wrote:
>> Only set memblock nid one time.
>
> Would be awesome if the description explains why we're doing this and
> why we're allowed to do this now.
will add more:
set memblock nid will
On 03/08/2013 12:25 AM, Sören Brinkmann wrote:
> On Thu, Mar 07, 2013 at 11:02:58PM +0100, Lars-Peter Clausen wrote:
>> On 03/07/2013 08:11 PM, Sören Brinkmann wrote:
>>> On Thu, Mar 07, 2013 at 10:36:35AM +0100, Lars-Peter Clausen wrote:
On 03/06/2013 06:27 PM, Sören Brinkmann wrote:
>
> On Wed, 2013-03-06 at 16:41 -0800, dormando wrote:
>
> > Ok... bridge module is loaded but nothing seems to be using it. No
> > bond/tunnels/anything enabled. I couldn't quickly figure out what was
> > causing it to load.
> >
> > We removed the need for macvlan, started machines with a fresh
On Thu, Mar 7, 2013 at 12:09 PM, Kukjin Kim wrote:
> [Me]
>> So shall I merge these three patches to the pinctrl tree or not?
>>
> Hi Linus, this series is already in Samsung tree with your ack.
OK good, thanks!
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe
On Thu, Mar 07, 2013 at 10:49:04PM -0800, Yinghai Lu wrote:
> >> @@ -654,10 +654,13 @@ void __init acpi_initrd_override_copy(void)
> >> arch_reserve_mem_area(acpi_tables_addr, all_tables_size);
> >>
> >> for (no = 0; no < table_nr; no++) {
> >> - size_t size =
On Thu, Mar 07, 2013 at 11:02:15PM -0800, Yinghai Lu wrote:
> > Also, does it really have to be called from head_32.S? No way this
> > can be done after entering C code? It would be great if you can
> > explain overall design choices in the head message (and important
> > patches).
>
> have to
Hello, Yinghai.
On Thu, Mar 07, 2013 at 10:57:21PM -0800, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 9:50 PM, Tejun Heo wrote:
> > On Thu, Mar 07, 2013 at 08:58:30PM -0800, Yinghai Lu wrote:
> >> We will find acpi tables in initrd during head_32.S in 32bit flat mode.
> >>
> >> So need
From: Wei WANG
For some Realtek's card reader, power up sequence can only be executed
when power has been turned off fully.
So rtsx host should not start power up sequence again when set_ios been
called if the power has been turned on.
Signed-off-by: Wei WANG
---
On Thu, Mar 7, 2013 at 10:26 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:34PM -0800, Yinghai Lu wrote:
>> We could use numa_meminfo directly instead of memblock nid.
>>
>> So we could move down set memblock nid down and only do it one time
>> for successful path
>>
>> Move
On Thu, Mar 7, 2013 at 10:04 PM, Tejun Heo wrote:
>> static int __init numa_register_memblks(struct numa_meminfo *mi)
>
> After this patch, the above name is a bit misleading, I think.
later i changed it to numa_check_memblks()
Thanks
Yinghai
--
To unsubscribe from this list: send the line
On Thu, Mar 7, 2013 at 9:57 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:31PM -0800, Yinghai Lu wrote:
>> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
>> index 73afd11..ca08f0e 100644
>> --- a/arch/x86/kernel/head_32.S
>> +++ b/arch/x86/kernel/head_32.S
>> @@ -149,6
On Thu, Mar 07, 2013 at 08:58:40PM -0800, Yinghai Lu wrote:
> If node with ram is hotplugable, local node mem for page table and vmemmap
> should be on that node ram.
>
> This patch is some kind of refreshment of
> | commit 1411e0ec3123ae4c4ead6bfc9fe3ee5a3ae5c327
> | Date: Mon Dec 27 16:48:17
On Thu, Mar 7, 2013 at 7:43 PM, Benson Leung wrote:
> +static void mxt_input_button(struct mxt_data *data, struct mxt_message
> *message)
> +{
> + struct device *dev = >client->dev;
Oops. I missed a warning: unused variable 'dev' here.
> + struct input_dev *input = data->input_dev;
On Thu, Mar 7, 2013 at 9:50 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:30PM -0800, Yinghai Lu wrote:
>> We will find acpi tables in initrd during head_32.S in 32bit flat mode.
>>
>> So need acpi_initrd_override_find could take phys directly.
>
> The patch description doesn't explain
Hi, Bjorn
> >> > Fix system hang issue: if first accessed resource file of BAR0 ~
> >> > BAR4, system will hang after executing lspci command
> >>
> >> This needs more explanation. We've already read the BARs by the time
> >> header quirks are run, so apparently it's not just the mere act of
>
On Thu, Mar 7, 2013 at 9:36 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:29PM -0800, Yinghai Lu wrote:
>> As later 32bit only find table with phys address during 32bit flat mode
>> in head_32.S.
>>
>> To keep 32bit and 64 bit consistent, use phys_addr for all.
>>
>> Use early_ioremap to
(2013/03/07 21:45), oskar.and...@sonymobile.com wrote:
> From: Toby Collett
>
> The symbol lookup can take a long time and kprobes is
> initialised very early in boot, so delay symbol lookup
> until the blacklist is first used.
I like this idea, but the implementation may have to be changed
if
On Thu, Mar 7, 2013 at 9:33 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:28PM -0800, Yinghai Lu wrote:
>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>> index c9e36d7..b9d2ff0 100644
>> --- a/drivers/acpi/osl.c
>> +++ b/drivers/acpi/osl.c
>> @@ -539,6 +539,7 @@
On Thu, Mar 07, 2013 at 08:58:37PM -0800, Yinghai Lu wrote:
> +void __init acpi_numa_init_only_slit(void)
> +{
> + /* SLIT: System Locality Information Table */
> + acpi_table_parse(ACPI_SIG_SLIT, acpi_parse_slit);
> +}
> +
> +static int __init __acpi_numa_init(bool with_slit)
> {
>
On Fri, 2013-03-08 at 10:37 +0800, Michael Wang wrote:
> On 03/07/2013 05:43 PM, Mike Galbraith wrote:
> > On Thu, 2013-03-07 at 09:36 +0100, Peter Zijlstra wrote:
> >> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
> >>
> >>> wake_affine() stuff is trying to bind related tasks closely,
On Fri, Mar 8, 2013 at 3:37 AM, Jiri Slaby wrote:
> On 03/01/2013 03:02 PM, Hillf Danton wrote:
>> On Fri, Mar 1, 2013 at 1:02 AM, Jiri Slaby wrote:
>>>
>>> Ok, no difference, kswap is still crazy. I'm attaching the output of
>>> "grep -vw '0' /proc/vmstat" if you see something there.
>>>
>>
On Thu, Mar 07, 2013 at 08:58:36PM -0800, Yinghai Lu wrote:
> -static int __init numa_check_memblks(struct numa_meminfo *mi)
> +
> +int __init numa_check_memblks(struct numa_meminfo *mi)
> {
> + nodemask_t tmp_node_map;
> unsigned long pfn_align;
>
> /* Account for nodes with
On Wed, Mar 06, 2013 at 05:20:32AM +, Stephen Boyd wrote:
> On 03/05/13 14:03, Stephen Boyd wrote:
> > On 03/05/13 00:34, Will Deacon wrote:
> >> I was looking at this the other day and wondered whether we could set
> >> HWCAP_IDIV in __v7_setup, depending on ID_ISAR0[27:24]. I can't
Hello,
On Tue, Mar 05, 2013 at 03:06:16PM -0800, Andrew Morton wrote:
> On Tue, 5 Mar 2013 20:47:31 +0900 Kyungsik Lee wrote:
>
> > This is the third version. In this version, Some codes are fixed
> > and more description and note are added. I would like to thank David Sterba
> > for his
於 四，2013-03-07 於 11:39 +，Matt Fleming 提到：
> > This patch works on a normal UEFI machine, we will test it on HP
> z220. I
> > will send out it formally after test success.
>
> Has anyone tried contacting HP to tell them their firmware is doing
> bizarre things?
We will try to contact with HP
On Thu, Mar 7, 2013 at 10:32 PM, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 10:03 PM, CAI Qian wrote:
>> CC'ing kexec ML. Also mentioned that 3.8 has no such issue.
>>
>> This message looks suspicious and out of range while 3.8 reservation
>> looks within the range.
>>
>> [0.00]
On Thu, Mar 7, 2013 at 10:03 PM, CAI Qian wrote:
> CC'ing kexec ML. Also mentioned that 3.8 has no such issue.
>
> This message looks suspicious and out of range while 3.8 reservation
> looks within the range.
>
> [0.00] Reserving 128MB of memory at 5216MB for crashkernel
> (System RAM:
On Thu, Mar 07, 2013 at 08:58:35PM -0800, Yinghai Lu wrote:
> Only set memblock nid one time.
Would be awesome if the description explains why we're doing this and
why we're allowed to do this now.
> Also rename numa_register_memblks to numa_check_memblks()
> after move set memblock nid out.
On Thu, Mar 07, 2013 at 08:58:34PM -0800, Yinghai Lu wrote:
> We could use numa_meminfo directly instead of memblock nid.
>
> So we could move down set memblock nid down and only do it one time
> for successful path
>
> Move node_map_pfn_alignment() to arch/x86/mm as no other user for it.
The prepare_transfer_hardware() is called in atomic context and
calling synchronous runtime pm calls can create scheduling deadlock.
Therefore, in place of calling runtime PM calls from prepare/unprepare
message transfer, calling this in transfer_one_message().
Signed-off-by: Laxman Dewangan
This function suffers from not being able to determine if the cleanup is
called in case it returns -ENOMEM. Nobody is using it anymore, so let's
remove it.
Signed-off-by: Lucas De Marchi
---
include/linux/kmod.h | 11 +--
kernel/kmod.c| 31 +--
2
On 03/08/2013 06:16 AM, Andrew Chew wrote:
The backlight enable regulator is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
Renamed en_supply to enable_supply to match the corresponding device tree
property.
Removed unnecessary check for pb->enable_supply
On Thu, Mar 07, 2013 at 01:45:18PM +0100, oskar.and...@sonymobile.com wrote:
> From: Toby Collett
>
> The symbol lookup can take a long time and kprobes is
> initialised very early in boot, so delay symbol lookup
> until the blacklist is first used.
>
> Reviewed-by: Radovan Lekanovic
>
Use call_usermodehelper_setup() + call_usermodehelper_exec() instead of
calling call_usermodehelper_fns(). In case the latter returns -ENOMEM
the cleanup function may had not been called - in this case we would
not free argv and module_name.
Signed-off-by: Lucas De Marchi
---
kernel/kmod.c | 15
Commit "7ff6764 usermodehelper: cleanup/fix __orderly_poweroff() &&
argv_free()" simplified __orderly_poweroff() removing the need to use
call_usermodehelper_fns().
Since we are not passing any callback, it's simpler to use
call_usermodehelper().
Signed-off-by: Lucas De Marchi
---
kernel/sys.c
call_usermodehelper_setup() + call_usermodehelper_exec() need to be
called instead of call_usermodehelper_fns() when the cleanup function
needs to be called even when an ENOMEM error occurs. In this case using
call_usermodehelper_fns() the user can't distinguish if the cleanup
function was called
Changes from v1:
- Remove call_usermodehelper_fns() converting all calling sites to either
call_usermodelper() or call_usermodehelper_setup() +
call_usermodehelper_exec()
- Don't check the return code in call_usermodehelper_freeinfo() - now that
allocating the subprocess_info is
Signed-off-by: Lucas De Marchi
---
fs/coredump.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index c647965..7dfb3b0 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -522,7 +522,7 @@ void do_coredump(siginfo_t *siginfo)
ispipe
Use call_usermodehelper_setup() + call_usermodehelper_exec() instead of
calling call_usermodehelper_fns(). In case there's an OOM in this last
function the cleanup function may not be called - in this case we would
miss a call to key_put().
Signed-off-by: Lucas De Marchi
---
These are the only users of call_usermodehelper_fns(). This function
suffers from not being able to determine if the cleanup is called. Even
if in this places the cleanup pointer is NULL, convert them to use the
separate call_usermodehelper_setup() + call_usermodehelper_exec()
functions so we can
On 03/07/2013 09:28 PM, Tejun Heo wrote:
> On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu wrote:
>> They are not using memblock_find_in_range(), so 1ULL<< will not help.
>>
>> Really hope i915 drm guys could clean that hacks.
>
> The code isn't being used. Just leave it alone. Maybe add a comment.
Hi Viresh
On Fri, 8 Mar 2013, Viresh Kumar wrote:
> On 8 March 2013 05:56, Guennadi Liakhovetski wrote:
> > I like generic drivers :)
>
> Me too :)
>
> > cpufreq-cpu0 is yet another such generic
> > (cpufreq) driver. Now, comparing the functionality of the two:
>
> Great!!
>
> > we see,
> static int __init numa_register_memblks(struct numa_meminfo *mi)
After this patch, the above name is a bit misleading, I think.
> +out:
Maybe register: would fit better?
> + /* Finally register nodes. */
> + for_each_node_mask(nid, node_possible_map) {
> + u64 start =
CC'ing kexec ML. Also mentioned that 3.8 has no such issue.
This message looks suspicious and out of range while 3.8 reservation
looks within the range.
[0.00] Reserving 128MB of memory at 5216MB for crashkernel
(System RAM: 3977MB)
Wondering if anything to do with memblock again...
On Fri, Mar 08, 2013 at 01:23:25PM +0900, Masami Hiramatsu wrote:
> (2013/03/07 19:44), oskar.and...@sonymobile.com wrote:
> > From: Bjorn Davidsson
> >
> > The kprobes blacklist contains x86-specific symbols.
> > Looking for these in kallsyms takes unnecessary time
> > during startup on non-X86
On Thu, Mar 07, 2013 at 08:58:31PM -0800, Yinghai Lu wrote:
> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> index 73afd11..ca08f0e 100644
> --- a/arch/x86/kernel/head_32.S
> +++ b/arch/x86/kernel/head_32.S
> @@ -149,6 +149,10 @@ ENTRY(startup_32)
> call load_ucode_bsp
Currently, in intel_idle.c, there are 5 state_tables array, every
array size is sizeof(struct cpuidle_state) * CPUIDLE_STATE_MAX.
As in intel_idle_cpuidle_driver_init(), we have copied the data into
intel_idle_driver->state[], so do not need to keep state_tables[]
there any more after system
In function intel_idle_cpu_init() and intel_idle_cpuidle_driver_init(),
they are having the same for(;;) loop.
Here in intel_idle_cpu_init(), the dev->state_count can be assigned by
drv->state_count directly.
Signed-off-by: liu chuansheng
---
drivers/idle/intel_idle.c | 30
Hi, All
On 3.9-rc1, I load crash kernel with latest kexec-tools(up to 28d413a), but
2nd kernel panic at early time:
[2.948076] Kernel panic - not syncing: Can not allocate SWIOTLB buffer
earlier and can't now provide you with the DMA bounce buffer
[2.959958] Pid: 53, comm: khubd Not
According to commit e022e7eb9, the .enter == NULL is the last one in
state_tables[].
So just like intel_idle_cpuidle_driver_init(), in case of .enter == NULL,
breaking the for(;;) loop directly.
Signed-off-by: liu chuansheng
---
drivers/idle/intel_idle.c |2 +-
1 files changed, 1
As Daniel suggested, I did some cleanup before setting the state_tables array
into __initdata.
Thanks your help to review them.
[PATCH 1/3] intel_idle: changing the continue to break in intel_idle_cpu_init()
[PATCH 2/3] intel_idle: Removing the redundant calculating for dev->state_count
[PATCH
On Thu, Mar 07, 2013 at 08:58:30PM -0800, Yinghai Lu wrote:
> We will find acpi tables in initrd during head_32.S in 32bit flat mode.
>
> So need acpi_initrd_override_find could take phys directly.
The patch description doesn't explain even half of what's going on.
> @@ -552,38 +552,47 @@ u8
in:
[ 486.529377] Pid: 0, comm: swapper/2 Tainted: GW
3.9.0-rc1-next-20130307-sasha-00047-g0a7d304-dirty #1037
[ 486.530165] Call Trace:
[ 486.530165] [] warn_slowpath_common+0x8c/0xc0
[ 486.530165] [] warn_slowpath_null+0x15/0x20
[ 486.530165] [] irq_work_needs_cpu+0x8a/0xb0
[ 486.530165
On Thu, Mar 07, 2013 at 08:58:29PM -0800, Yinghai Lu wrote:
> As later 32bit only find table with phys address during 32bit flat mode
> in head_32.S.
>
> To keep 32bit and 64 bit consistent, use phys_addr for all.
>
> Use early_ioremap to access during copying.
>
> Signed-off-by: Yinghai Lu
>
On Thu, Mar 07, 2013 at 08:58:28PM -0800, Yinghai Lu wrote:
> To parse srat early, we will need to move acpi table probing early.
> and to keep acpi_initrd_table_override working, we need to move it
> ahead.
>
> But current that is called after init_mem_mapping and relocate_initrd().
>
> Copying
On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu wrote:
> They are not using memblock_find_in_range(), so 1ULL<< will not help.
>
> Really hope i915 drm guys could clean that hacks.
The code isn't being used. Just leave it alone. Maybe add a comment.
The change is just making things more confusing.
On Thu, Mar 7, 2013 at 9:25 PM, Tejun Heo wrote:
> On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu wrote:
>> On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo wrote:
>>> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo wrote:
>> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> index 69d97cb..7f9380b
On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo wrote:
> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> index 69d97cb..7f9380b 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>
On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 69d97cb..7f9380b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -81,7
As later 32bit only find table with phys address during 32bit flat mode
in head_32.S.
To keep 32bit and 64 bit consistent, use phys_addr for all.
Use early_ioremap to access during copying.
Signed-off-by: Yinghai Lu
Cc: Thomas Renninger
Cc: Rafael J. Wysocki
Cc: linux-a...@vger.kernel.org
We need to handle slit later, as it need to allocate buffer.
Also we only need srat info before init_mem_mapping.
x86_acpi_numa_init become x86_acpi_numa_init_only_slit
x86_acpi_numa_init_no_slit.
Signed-off-by: Yinghai Lu
Cc: Tejun Heo
Cc: Rafael J. Wysocki
Cc: linux-a...@vger.kernel.org
We could move setup_node_data() and numa_init_array() calling out
numa_init() to make numa_init() small.
Those functions only need to be called for success path, and only
call them one time in x86_numa_init().
So later we could split parse numa info to two stages.
early one will be before
We will find acpi tables in initrd during head_32.S in 32bit flat mode.
So need acpi_initrd_override_find could take phys directly.
Signed-off-by: Yinghai Lu
Cc: Thomas Renninger
Cc: Pekka Enberg
Cc: Jacob Shin
Cc: Rafael J. Wysocki
Cc: linux-a...@vger.kernel.org
---
It will need to allocate buffer for new numa_meminfo and
distance matrix, so move it down.
Also we change the behavoir:
before this patch, if user input wrong data in command line, it
will fall back to next numa or disabling numa.
after this patch, if user input wrong data in command line, it
Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
be used anymore.
Only user is ACPI_OVERRIDE, and it should not use that, as later
accessing is using early_remap. Change to try to 4G below and
then 4G above.
Other user is in drm/i915, but it is commented out.
Should use
We could use numa_meminfo directly instead of memblock nid.
So we could move down set memblock nid down and only do it one time
for successful path
Move node_map_pfn_alignment() to arch/x86/mm as no other user for it.
Signed-off-by: Yinghai Lu
Cc: Tejun Heo
---
arch/x86/mm/numa.c | 76
To parse srat early, we will need to move acpi table probing early.
and to keep acpi_initrd_table_override working, we need to move it
ahead.
But current that is called after init_mem_mapping and relocate_initrd().
Copying need to be after memblock is ready, because it need to allocate
some
We do not need to use nid in memblock to find out absent pages.
So could move that numa_meminfo_cover_memory() early before set
memblock nid.
Also could make __absent_pages_in_range() to static and use
absent_pages_in_range() directly.
Later will only set memblock nid one time on successful
Parse numa info at first and store info into numa_meminfo.
call early_initmem_init before init_memory_mapping(), will
have numa info ready at first, and will still keep numaq, acpi_numa,
amd_numa, dummy fall back sequence.
SLIT and numa emulation handling are still left in initmem_init().
Only set memblock nid one time.
Also rename numa_register_memblks to numa_check_memblks()
after move set memblock nid out.
Signed-off-by: Yinghai Lu
Cc: Tejun Heo
---
arch/x86/mm/numa.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/numa.c
early_initmem_init() will call early_x86_numa_init().
later will call init_mem_mapping for nodes in it.
Signed-off-by: Yinghai Lu
Cc: Tejun Heo
Cc: Pekka Enberg
Cc: Jacob Shin
---
arch/x86/include/asm/page_types.h |1 +
arch/x86/kernel/setup.c |1 +
arch/x86/mm/init_32.c
head64.c could use #PF handler set page table to access initrd before
mapping and relocating.
head_32.S could use 32bit flat mode to access initrd before mapping
and relocating.
Signed-off-by: Yinghai Lu
Cc: Thomas Renninger
Cc: Pekka Enberg
Cc: Jacob Shin
Cc: Rafael J. Wysocki
Cc:
1 - 100 of 1348 matches
Mail list logo
